I'm having similar TDP (Oracle & SharePoint) file space expiration problems as
well. I'm about to open a call with IBM on this, but can you check the act log
to see what I'm seeing? You'll need to dig into the actual expiration process.
Try running this (replace NODE_NAME and adsmorc with your tdp file space name)
'q act begind=-14 endd=today s=expir*NODE_NAME*adsmorc'
and also to verify inventory expiration is completing:
'q act begind=-14 endd=today s=expir*invent*succ'
For one particular Oracle node, the \adsmorc file space is flat out skipped
during expiration while another identical Oracle node has \adsmorc file space
processed. The occupancy of the \adsmorc file space on the skipped node
constantly grows while the processed node holds relatively steady.
The other UNIX Oracle node I have shows that _sometimes_ expire inventory
processes it's /Oracle_FS file space but most days it skips it! Now, I track
occupancy daily. On the days expire inventory processes the /Oracle_FS
(evidence in the act log), the occupancy shrinks indicating this the TSM server
is doing it's job. All the other days that it skips it, it grows. To me at
this point, this is a bug. We're at Server v5.4.3.0, BAC 5.5.1.0, DP for
Oracle 5.4.1.0. And if you're wondering, yes, backdel is enabled on all the
nodes.
It would be great to see what you guys find on your systems. In the mean time,
I'm opening up that ETR.
Richard Rhodes wrote:
> We have the same setup. TDPO backups go to separate nodes that have use
> their own pool. We have ongoing problems with RMAN deletes not changing
> the file in TSM (rman backup pieces) to inactive status, which are then
> removed during expiration. We don't know if it's RMAN, TDPO, or us with
> the problem. Our DBA's run TDPOSYNC fairly often to fix things up.
> Something is wrong and we just haven't had time to track it down. I
> have a script that queries the TSM backups table for files (rman backup
> pieces) that are older than our retension period. I run it once a week.
>
> Rick
>
>
>
>
>
>
>
>
> "Gee, Norman"
> <Norman.Gee < at > LC.CA
> .GOV> To
> Sent by: "ADSM: ADSM-L < at > VM.MARIST.EDU
> Dist Stor cc
> Manager"
> <ADSM-L < at > VM.MARIST Subject
> .EDU> Re: TSM TDP Oracle - Expiration
> Opinions
>
> 03/20/2009 01:27
> PM
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <ADSM-L < at > VM.MARIST
> .EDU>
>
>
>
>
>
>
> You will have to let RMAN do its job. Every RMAN backup piece and sets
> have unique file names and will never place a prior backup into an
> inactive status.
>
> How would you expire a RMAN backup since every backup piece is still
> active? Short of mass delete on filespace.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf
> Of
> Hart, Charles A
> Sent: Friday, March 20, 2009 9:30 AM
> To: ADSM-L < at > VM.MARIST.EDU
> Subject: TSM TDP Oracle - Expiration Opinions
>
> We currently have your Oracle TDP Clients setup as a Separate node in
> separate a separate domain down to the storage pool hierarchy. That
> said we are having challenges with DBA's and their RMAN delete scripts
> for various reasons. According to the TDP for DB manual its recommended
> to have the RMAN catalog maintain retention which I would agree with but
> we are little success, and end up filling up virtual tape subsystems,
> orphaning data etc.
>
> The enough now is to have TSM maintain the RMAN retention and the DBA's
> would just clean their RMAN catalog with a crosscheck and delete
> process.
>
> What do you? Do you let RMAN maintain Retention or TSM maintain
> pitfalls of either?
>
>
> Best Regards,
>
> Charles Hart
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the
> intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.
+----------------------------------------------------------------------
|This was sent by sam.wozniak AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
|
