ADSM-L

Re: [ADSM-L] backed up nodes

2008-03-16 22:56:54
Subject: Re: [ADSM-L] backed up nodes
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 16 Mar 2008 19:55:45 -0700
I just noticed my verbiage was not in sync with my examples, e.g., I wrote
about "30 days" but SELECT examples use 60 days. Let's just pretend I was
talking about 60 days all along.... :-)

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
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 2008-03-16
19:25:42:

> I'm not sure there is any comprehensive method to do this simply by
> querying the TSM environment. For example, you mght have a node that
> archives files only once a year. The idea here is that just looking at
> what nodes are registered, what files spaces exist, and when data was
last
> backed up is not necessarily a comprehensive means of determining how
many
> nodes "back up" to the TSM server.
>
> But it seems to me that if you are trying to get a good idea from
> examining TSM activity, it might be easier to just query the NODES table
> and compare the last access times. For example, if it is reasonable in
> your environment for "active" nodes to store data on the TSM server at
> least once every 30 days, you could use a query like this:
>
>   select count(*) from nodes where current_timestamp - lastacc_time<=60
> days
>
> (note: you have to pick the number of days that works for you.)
>
> Then you could do this to identify nodes that have not contacted the
> server within the past 60 days:
>
>   select node_name, contact from nodes where current_timestamp -
> lastacc_time>60 days
>
> and ask the owners of those systems whether they still use TSM. You can
> also specify other columns from the NODES table that might help identify
> machines, such as TCP_ADDRESS.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Product Development
> Level 3 Team Lead
> 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 2008-03-16
> 18:51:11:
>
> > What started my question to ask this forum's expert is suddenly I was
> told
> > that I have to keep track of all the nodes being backed up on tivoli.
> > I still have to clarify with IBM licensing if this is to do with nodes
> > currently being backed up on tivoli based on processes? ip, or node
> names
> > etc.. We have so many nodes moving on and off tivoli, that if
currently
> > being backed up is the key, then there has to be a way that running a
> > simple command can help me get an idea.  I thought simply 'q occupancy
'
> > just tells you the total storage occupied on each node. The node could
> > easily occupied storage space but no longer being backed up. Sorry
about
> > the confusion.
> >
> > Avy Wong
> > Business Continuity Administrator
> > Mohegan Sun
> > 1 Mohegan Sun Blvd
> > Uncasville, CT 06382
> > (860)862-8164
> > (cell) (860)961-6976
> >
> >
> >
> >
> >              Shawn Drew
> >              <shawn.drew@AMERI
> >              CAS.BNPPARIBAS.CO To
> >              M>                        ADSM-L AT VM.MARIST DOT EDU
> >              Sent by: "ADSM: cc
> >              Dist Stor
> >              Manager" Subject
> >              <[email protected]         Re: [ADSM-L] backed up nodes
> >              .EDU>
> >
> >
> >              03/15/2008 07:13
> >              PM
> >
> >
> >              Please respond to
> >              "ADSM: Dist Stor
> >                  Manager"
> >              <[email protected]
> >                    .EDU>
> >
> >
> >
> >
> >
> >
> > I think Avy's question should be rephrased to "Which nodes are
currently
> > scheduled to be backed up?"  (Avy, correct me if I'm wrong)
> > In which case the select statement should be against the associations
> > table.
> >
> > ________________________________________________
> > Shawn Drew
> > Data Protection Engineer
> > Core IT Production
> > BNP Paribas RCC, Inc.
> >
> >
> >
> >
> > Internet
> > rbs AT BU DOT EDU
> >
> > Sent by: ADSM-L AT VM.MARIST DOT EDU
> > 03/15/2008 03:04 PM
> > Please respond to
> > ADSM-L AT VM.MARIST DOT EDU
> >
> >
> > To
> > ADSM-L
> > cc
> >
> > Subject
> > Re: [ADSM-L] backed up nodes
> >
> >
> >
> >
> >
> > On Mar 15, 2008, at 2:36 PM, Roger Deschner wrote:
> >
> > > That occupancy table can be REALLY slow to process if your system
> > > is at
> > > all large. I prefer to search the summary table which is fast, even
> > > with
> > > my 275gb database.
> >
> > Roger - Are you thinking of the Contents table?
> >
> > I have a large system, and it takes about 3 seconds to get results
> > from that Select of the Occupancy table.  It takes about 20 times
> > longer to go through the Summary table, where the retention is 30
days.
> >
> > Richard Sims
> >
> >
> > This message and any attachments (the "message") is intended solely
for
> > the addressees and is confidential. If you receive this message in
> error,
> > please delete it and immediately notify the sender. Any use not in
> accord
> > with its purpose, any dissemination or disclosure, either whole or
> partial,
> > is prohibited except formal approval. The internet can not guarantee
the
> > integrity of this message. BNP PARIBAS (and its subsidiaries) shall
> (will)
> > not therefore be liable for the message if modified. Please note that
> > certain
> > functions and services for BNP Paribas may be performed by BNP Paribas
> RCC,
> > Inc.