ADSM-L

Re: Script check requested.

2006-10-26 18:32:10
Subject: Re: Script check requested.
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 26 Oct 2006 16:31:04 -0600
Off the top of my head, I don't see anything inherently wrong with the
script (syntax-wise).

However, if you are going after just backup or archive info, then you are
gboing to pick up a lot more than that. Try adding a WHERE clause like
this:

   ... where activity in ('ARCHIVE', 'BACKUP')

Or if you want to split them out, add the ACTIVITY column to the SELECT
output, and add this after the WHERE clause:

   ... group by activity

Thus:

select activity, \
       cast((cast(sum(bytes) as double) / 1024 / 1024 /1024) as
decimal(10,2)) as "Gigabytes" \
   from summary \
   where activity in ('ARCHIVE', 'BACKUP') and \
         start_time>current_timestamp - 1 day \
   group by activity

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 10/26/2006
03:08:02 PM:

>    Folks,
>    I have a script I have run forever to see how much data has been
> backed-up/archived to my TSM servers over the last 24 hours.
>
>    Lately, this command is returning a number that seems to be too
> high, compared to what I see the clients doing.
>
>
> select cast((cast(sum(summary.bytes) as float) / 1024 / 1024 /1024)
>                                  as decimal(10,2)) as Gigabytes from
> summary where start_time
>                                  >current_timestamp - 1 day
>
>
>    I recently upgraded my TSM servers from 5.2 to 5.3 and was
> wondering if that had anything to do with it.
>
>    This SQL statement looks OK to me. Can anyone point out any
> problems with that select statement?
>
> Thanks,
> Ben

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