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:[EMAIL PROTECTED] On Behalf Of Bell, Charles (Chip) Sent: Friday, March 23, 2007 9:41 AM To: [email protected] 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.
