I frequently find the culprit to be Oracle backups made via TDP/RMAN
(but it could be any backup made via TDP).  Something happens and they
stop deleting old backups.  I look at likely candidates using:

set sqldisplaymode wide
select NODE_NAME,cast(BACKUP_DATE as date) as
"BACKUP_DATE",STATE,cast(DEACTIVATE_DATE as date) \
as "DEACTIVATE_DATE",HL_NAME,LL_NAME from BACKUPS where
NODE_NAME='Client's Node Name' order by BACKUP_DATE 

If it shows old backups then I have the DBAs correct the problem and use
tdposync to remove the old backups.

Milton Johnson

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bell, Charles (Chip)
Sent: Friday, March 23, 2007 9:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
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.