Unfortunately there are many reasons why an Oracle backup does not get deleted. My point was to examine your nodes backing up via TDP. A 100GB database that is deleting old back ups can eat up a TB fairly quickly.
Thanks, Milton Johnson -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Holzinger Sent: Wednesday, March 28, 2007 11:54 PM To: [email protected] Subject: Re: [ADSM-L] Shrinking scratch pools - tips? Hi Milton, one reason, 'old' TDPO/RMAN backups will not be expired anymore could be that your Oracle DBA's are using a different RMAN recovery catalog now. So every TDPO/RMAN backup which would be part of the 'old' RMAN recovery catalog wouldn't be expired anymore. Another reason could be that your Oracle databases are having a different DBID now for some reason. This is most likely if an Oracle database has been 'cloned' from another one. I have noticed both situations a couple of times in our installation. best regards, Rainer -------------------------------- RHo-Consulting Alter Bahnhof 13 D-93093 Donaustauf phone: +49 9403 969174 mobile: +49 162 2807 888 email: [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify the sender IMMEDIATELY; you should not copy the e-mail or use it for any purpose or disclose its contents to any other person. VIRUSES: Although there have been taken steps to ensure that this e-mail and attachments are free from any viruses, the recipient should at its sole discretion take the necessary measures to ensure that the received messages are actually virus free > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Johnson, Milton [CCC-OT_IT] > Sent: Wednesday, March 28, 2007 11:23 PM > To: [email protected] > Subject: Re: [ADSM-L] Shrinking scratch pools - tips? > > 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.
