Well Response from IBM in Regards to TDPO and RMAN .....
When the TDPOracle backup is performed, the objects are saved on the TSM
Server into the backup copy group. Each backup objects will have a
unique name as this is a requirement of Oracle. This causes each object
to be active on the TSM Server and as you are aware, an active backup
object will never expire or be removed by any of the TSM processing.
Since these objects are unique and they are never automatically expired
from the TSM server (no versioning occurs), RMAN is utilized to delete
the unwanted backup objects from the TSM server.. The BackDelete
parameter for the TDP node should be set to Yes so that the TDP client
can delete the backup files from the TSM server for the node.
When performing deletions of the backups with RMAN and using the Data
Protection for Oracle, there are various ways that the deletions can be
performed. The TDP Oracle works with RMAN and thus it is possible to use
the RMAN Global parameters for RECOVERY WINDOW or REDUNDANCY. It is also
viable to use the Oracle DELETE OBSOLETE and DELETE EXPIRED and/or an
RMAN script to CHANGE the backuppiece for deletion. It is very important
to ensure that the same environment variables are used for the deletion
as were specified for the backups. Specifically the TDPO_OPTFILE= would
need to be the same as what was used during the backup, so that the
TDPO_NODE, TDPO_FS and TDPO_OWNER are the same.
The TDPOSYNC SYNCDB utility can be utilized when old objects remain on
the TSM Server but have been removed from the RMAN catalog. Once an
object is removed from the RMAN catalog, any deletion attempt will not
find the object in the catalog and thus the deletion request is not
processed. In this case it is necessary to run the tdposync to
synchronize the RMAN repository with the data that exists on the TSM
Server.
During the TDPOSYNC processing, it will initially connect to SQLPLUS in
order to query the RMAN catalog and pull the entire list of backuppieces
stored there (placing the list within a temporary file in the temp
directory). There is no specification for the target database. The query
list will be for all the objects stored in the RMAN catalog. The
TDPOSYNC will then connect to the TSM Server and verify the list of
objects from there based on the NodeName and Filespace and Owner. The
comparison is only one direction, which checks if the object that is on
the TSM Server exists in the RMAN catalog. A list is output of those
items that are on TSM but not within the RMAN catalog (additional
objects may exist in the RMAN catalog). These objects can then be
selected within TDPOSYNC and deleted from the TSM Server (note that the
object are only removed from the TSM Server after expiration has been
performed).
When removing an Oracle database it is necessary to also remove this
from the RMAN catalog. If the database and associated backups still
exist within the RMAN catalog, the TDPOSYNC processing (as I noted
above) will still see these backup objects as existing and thus not
remove them from the TSM Server. This same scenario can exist if a
database restore has occurred that causes a reset of the DB within the
RMAN catalog, thus leaving the older backups within the catalog but no
longer viable for restore. Again, in this case, it will be necessary to
cleanup the RMAN catalog to remove these older references that are no
longer valid.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
antwoneeter
Sent: Friday, April 10, 2009 12:37 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM TDP Oracle - Expiration Opinions
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.
+----------------------------------------------------------------------
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.
|
