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.
|
