And another thing....the end of backup statistics message that gets pumped
up to the server is real long. So if you use a SQL query to get it from the
activity log, you only get the first 250-chars. The real meat of the stats
is past that. So trying to monitor/automate the backup stats for a TDP
backup won't work. (found this one out the hard way...still got the
teeth-marks on my butt where it bit me!!) I extracted the data using a SQL,
piped it to a file -COMMA and brought it back to my office for analysis.
Found I couln't analyze anything from the output. Everything was truncated
at 250-chars.

Just my rant-of-the-day.

Bill Boyer
DSS, Inc.
"There are 10 kinds of people in the world those who understand binary and
those who don't." - ??

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Mr. Lindsay Morris
Sent: Wednesday, November 13, 2002 11:27 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: SQL 2.2.1


Bill's right (as usual).  The lack of backup start-end times on individual
filespaces is pretty crucial.

The way I'd like to see reporting of databases (if I were king) would be
similar to client nodes:
        a client node has filespaces
        a database has tablespaces
        both of those things have (in concept at least)
           - a last-backup end time
           - a size in GB
           - a percent-full reading

Presently, TDP for XXX agents don't tell you this at the filespace level.
But there's a fairly easy way around it....

----------------------------------------------------------------------------
--------------------
(OK, the below MIGHT be construed as advertising - be warned and hang up now
if you're offended)
sure seems like a problem-solver to me though...
----------------------------------------------------------------------------
--------------------

But there's a fairly easy way around it, if you're using Servergraph anyway:
        -- run a daily SQL script on the database clients, to generate a
table like
this:
                databasename    tablespacename  size    percent-full
backup-end(maybe)
           You can probably get the backup-end date by scanning the TDP
client
logs.
        -- use "sgdwrite" to pump that into the Servergraph database over
the
network.
           (We'll be glad to do this if somebody will write the
Oracle/Informix/etc
SQL.)

Now Servergraph will treat the database and its tablespaces as just another
client node with filespaces, and use the same logic as for client nodes to
determine whether the DB was currently backed up.

A great incidental benefit: since we keep trending history on all
measurements, the percent-full reading will generate  predictions and/or
alerts on when each individual tablespace INSIDE the database will fill up!

Your DBA's ought to love that.


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Bill Boyer
> Sent: Wednesday, November 13, 2002 10:13 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: SQL 2.2.1
>
>
> Del,
>         The filespace information only shows be the backup
> start/end for the
> INSTANCE. I could go in an backup a single database and the filespace
> information will change? It doesn't tell me that there is a database in an
> instance that hasn't backed up in xx-days, like I could get that
> information
> from B/A client filespaces. I believe Mr. Lindsay Morris says that
> ServerGraph uses the filespace information to list filespaces that haven't
> been backed up in x-days, or even last night. He uses this information
> instead of the client completion or event records for
> successfully backups.
>
>         Take DB2 for example...there is a filespace for each
> database backed up.
> Now the backup start/end times aren't maintained, but if they
> were this type
> of information would be of more benefit in tracking backups, cleanup,...
>
>         Now I love the strides taken in the TDP agent reporting,
> but there are
> still some things I would like to see. Makes central monitoring a bit
> easier...
>
> Bill Boyer
> DSS, Inc.
> "There are 10 kinds of people in the world those who understand binary and
> those who don't." - ??
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Del Hoobler
> Sent: Wednesday, November 13, 2002 9:28 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: SQL 2.2.1
>
>
> Mehdi,
>
> What "filespace information" are you referring to?
>
> DP for SQL will not update:
>    Capacity (MB)
>    Pct Util
> because it is ambiguous in the context of DP for SQL.
> Remember, those numbers correlate back to a "volume"
> capacity and how much of it is utilized.
>
> but DP for SQL will update:
>    Node Name
>    Filespace Name
>    FSID
>    Platform
>    Filespace Type
>    Last Backup Start Date/Time
>    Last Backup Completion Date/Time
>
> Thanks,
>
> Del
>
> ----------------------------------------------------
>
> Del Hoobler
> IBM Corporation
> hoobler AT us.ibm DOT com
>
> - Never cut what can be untied.
> - Commit yourself to constant improvement.
>
> ====================================================================
>
> > Can someone email me a good example of DSM.OPT, SQLFULL.CMD for
> SQL 2.2.1
> as
> > well as the batch file they use to start SQL Scheduler Service.
>  I do run
> my
> > SQLFULL.CMD successfully and the log shows me Number of bites sent but
> TSM
> > Server does not update its FileSpace information.
>