ADSM-L

Re: [ADSM-L] size of objects in the backups table

2015-02-03 11:12:16
Subject: Re: [ADSM-L] size of objects in the backups table
From: Nick Laflamme <nick AT LAFLAMME DOT US>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 3 Feb 2015 10:10:09 -0600
I used to work with BACKUPS and CONTENTS a lot when auditing how well some
DBAs were policing their own backups. I don't have those scripts any
longer, but my recollection is that techniques I developed using those
tables in TSM 5.5 were unusable on TSM 6.1 and early TSM 6.2 servers. They
were usable again on TSM 6.3, and I thought they were usable again on later
TSM 6.2 releases -- but I probably was using repeated small queries, not
large joins.

I'd think you'd already be seeing this improvement if you're on 6.2.5, but
if not, it might be worth the effort to get to TSM 6.3.

Nick


On Tue, Feb 3, 2015 at 8:25 AM, Rhodes, Richard L. <
rrhodes AT firstenergycorp DOT com> wrote:

> We are on TSM v6.2.5.
>
> We keep running into the normal question that seems to come up when we
> start analyzing our backups.  We can tell the number of active/inactive
> files from the backups table, but not the size, which is in the contents
> table.  Does anyone have a way to get the active/inactive objects and their
> size without killing your system with a massive SQL join?  Maybe some kind
> of SQL join for a specific node.
>
> I just can't believe TSM doesn't provide this info easily from the server!
> (I suppose this belongs under the "Rant" thread!)
>
>
> Rick
>
>
> -----------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are hereby
> notified that you have received this document in error and that any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately, and delete the original message.
>