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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rainer Holzinger
Sent: Wednesday, March 28, 2007 11:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
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:    rainer.holzinger AT t-online DOT de

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:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Johnson, Milton [CCC-OT_IT]
> Sent: Wednesday, March 28, 2007 11:23 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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: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.