Hi Morris,
I use TSMOR for may things (b.t.w. Servergraph can do the same but TSMOR
is free).
One of the subjects in the report is "Node Activity Summary"
It gives you an overview of the amount of data backed up per client
sorted on "Bytes Transferred" over a certain period (eg. 24 hours)
It helped me to find storage abusers .
Eg. this morning I noticed that one client had sent more than 100GB to
TSM while the average size for this client is only a few MB.
It is one of the things to check (together with all the other suggestion
made by others) .
I also support the suggestion to check for volumes with status " Private"
but no owner and where the " Last use" column is blank for the volume.
(q libv).
If you have many of these, update these vols to scratch status and search
the actlog for an explanation why these empty tapes are in private mode.
You see, there are many things to check .
Google for
"TSM operational reporting tool site:ibm.com" and the first hit will take
you to the IBM support site where you can read about the tool and down
load it.
Success.
Best regards / Mit freundlichen Grüßen / Sincères salutations
Ronald Le Large
"Morris.Marshael" <Morris.Marshael AT MCCG DOT ORG>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
23-03-2007 18:14
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: [ADSM-L] Shrinking scratch pools - tips?
How would you use TSM Operation Reporting Tool with this?
Also is there some docs for setting up some TSMOR?
Thanks,
Marshael
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Ronald Le Large
Sent: Friday, March 23, 2007 11:03 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Shrinking scratch pools - tips?
Hi ,
I hope I understood your question well: you are wandering why your TSM is
using so many tapes ? Correct ?
I should start finding out how many bytes per client is sent per backup
cycle.
You could run sql's for that (some of them have been reported here today
or yesterday) but personally I use the TSM Operation Reporting Tool for
that.
You could also run "q actlog begind=-1 search=[client_name] msg=4961
Then look more in detail into this big consumers and determine
a. if it is normal that they send NNN GB per night
b. check the filesystem (q filespace [client name] ;
do you see filespaces that should have been excluded/ is you client
perhaps backing up SAN disks while it shouldn't ?
c. q occ [client] tells you where this client is storing its data (LTO,
disk, LTO2 etc)
Start there and based on the outcome, continue searching. Don't be
surprised if you don't find any abnormalities. Maybe you need more
tapes/libraries because your data has grown enormously over the year.....
Best regards / Mit freundlichen Grüßen / Sincères salutations
Ronald Le Large
Administrative Employee Operational Services/Storage Team | Dir. 2.6.3
TSM admin
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 2592
Mobile +31 (0)6 42 72 46 86
rlelarge AT epo DOT org
http://www.epo.org
"Bell, Charles (Chip)" <Chip.Bell AT BHSALA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
23-03-2007 15:42
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
[ADSM-L] Shrinking scratch pools - tips?
Since this a GREAT place for info, etc., I though I would ask for
tips/how-to's on tracking down why my scratch pools are dwindling, for
LTO/LTO2/VTL. My guess is I have a couple of clients that are sending out
a
vast amount of data to primary/copy. But without a good reporting tool,
how
can I tell? Expiration/reclamation runs fine, and I am going to run a
check
against my Iron Mountain inventory to see if there is anything there that
should be here. What else would you guys/gals look at? :-) Thanks in
advance!
God bless you!!!
Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional
Baptist Health System
Birmingham, AL
-----------------------------------------
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.
"MMS eMail Firewall <mccg.org>" made the following annotations.
------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: The information transmitted in this e-mail
message, including any attachments, is for the sole
use of the intended recipient(s) or entity to which it is addressed and
may contain confidential, privileged and/or proprietary information.
Any unauthorized review, retransmission, use, disclosure, dissemination or
other use of, or taking any action in reliance upon this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, you are hereby
notified that any reading, dissemination, distribution, copying, or other
use of this message or its attachments is strictly prohibited.
If you have received this message in error, please notify the sender
immediately by reply e-mail, or by calling (478) 633-7272, and
destroy the original message, attachments and all copies thereof on all
computers and in any other form.
Thank you. The Medical Center Of Central Georgia.
==============================================================================
03/23/07, 13:14:24
|