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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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@VM.MARIST.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 > <[EMAIL PROTECTED] > CAS.BNPPARIBAS.CO To > M> ADSM-L@VM.MARIST.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 > [EMAIL PROTECTED] > > Sent by: ADSM-L@VM.MARIST.EDU > 03/15/2008 03:04 PM > Please respond to > ADSM-L@VM.MARIST.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.
