ADSM-L

Re: [ADSM-L] SQL queries and TSM Server/platform performance measurement

2007-07-25 18:29:48
Subject: Re: [ADSM-L] SQL queries and TSM Server/platform performance measurement
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Jul 2007 14:32:43 -0500
I don't understand the relevance of the pgs per hour query on Expiration. 
My understanding from an STE presentation is that TSM doesn't necessarily
walk all the pages in the DB during expiration; it knows when it has
nothing to expire in a given area and doesn't go there.

Anybody got evidence to the contrary?



> Hi Guys,
>
> Every now and then I come across a SQL query and a benchmark such as the
> following which purports to be useful in high-level performance problem
> spotting. For example:
>
> select activity, cast((end_time) as date) as "Date", (examined/cast
> ((end_time-start_time) seconds as decimal(18,13))*3600) "Pages backed
> up/Hr" from summary where activity='FULL_DBBACKUP' and days(end_time) -
> days(start_time)=0
>
> or
>
> select activity, cast((end_time) as date) as "Date", (examined/cast
> ((end_time-start_time) seconds as decimal(24,2))*3600) "Objects Examined
> Up/Hr" from summary where activity='EXPIRATION'
>
> alongside statements that values of less than 5,000,000 pages per hour
> and 3,800,000 pages per hour respectively might indicate a performance
> issue somewhere in the stack. Has anyone else seen these, or similar
> ones, as well?
>
> My concern is that the article I've just come across which contains the
> above, quoted from an IBM White Paper, might be a little on the old
> side, and particularly with the later expiration query, I'm getting
> figures for one system which suggest it should be crawling on its knees
> when instead I'd tend to think it's a pretty damn good performer. As I'm
> sure TSM Server code improves the expiration algorithm with each
> revision, then it's more likely that this later query, and as
> importantly the benchmark which goes with it, might get obsoleted.
>
> Does any one have any thoughts on these? Does anyone else have any other
> queries or benchmarks which they run from time to time for
> 'tip-of-the-iceberg' performance troubleshooting.
>
> Rgds,
>
> David McClelland
> London, UK
>
>
>
>
>
>
>
>
>
> This email was sent to you by Reuters, the global news and information
> company.
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Reuters Limited.
>
> Reuters Limited is part of the Reuters Group of companies, of which
> Reuters Group PLC is the ultimate parent company.
> Reuters Group PLC - Registered office address: The Reuters Building, South
> Colonnade, Canary Wharf, London E14 5EP, United Kingdom
> Registered No: 3296375
> Registered in England and Wales
>

<Prev in Thread] Current Thread [Next in Thread>