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