ADSM-L

Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions

2009-04-14 09:42:31
Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions
From: "Hart, Charles A" <charles_hart AT UHC DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 14 Apr 2009 08:18:02 -0500
Thank you for the detailed response, Grigori.  So if you have to
maintain 3 diff retentions per DB can you have multiple Recovery Windows
per DB in RMAN?  Unfortunately we need a 21Day, 90Day and yes 10YR (I
know - recover what?) 

Regards, 

Charles 

 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Grigori Solonovitch
Sent: Tuesday, April 14, 2009 1:26 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM TDP Oracle - Expiration Opinions

Hello Everybody,

I have no problems at all with Oracle+RMAN+TDPO+TSM environment. I have:

1) dedicated nodes for database backups, separated from file system
backups (for example, LPAR05 for files and LPAR05_ORA for databases on
logical partition LPAR05);

2) dedicated management class and copy group for database backups:
Policy        Policy          Mgmt              Copy
Ver            Ver         Retain     Retain
Domain     Set               Class                Group
Data           Data       Extra       Only
Name         Name          Name               Name                Exists
Deleted   Ver         Version
---------     ---------         ---------             ---------
-----------    --------    --------     -------
AIX         ACTIVE       DBLPAR05      STANDARD    No Limit    0
31           0
Note that exact setup for copy group is important.

3) "CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31" ones for each
database from RMAN prompt (very important);

4) full online backup for each database twice per month and incremental
backups all other days (just to reduce recovery time - less number of
incremental backups is required);

5) "delete noprompt obsolete;" in RMAN backup script (after completion
of full or incremental backups);

6) daily for each database in RMAN script (activated as cron-job)
    "crosscheck backup;
      list expired backup summary;
      delete noprompt expired backup;
      delete noprompt obsolete;"
 after completion of all full or incremental backups.

RMAN and TSM are maintaining data expiry period 31 days carefully for
each database.
I am really able to recover any database to any point in time up to 31
days back and I never run tdposync to remove obsolete or expired
backups.

Kindest regards,

Grigori G. Solonovitch

Senior Technical Architect

Information Technology  Bank of Kuwait and Middle East
http://www.bkme.com

Phone: (+965) 2231-2274  Mobile: (+965) 99798073  E-Mail:
G.Solonovitch AT bkme DOT com

Please consider the environment before printing this Email


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
antwoneeter
Sent: Friday, April 10, 2009 8: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.
+----------------------------------------------------------------------

Please consider the environment before printing this Email.

"This email message and any attachments transmitted with it may contain
confidential and proprietary information, intended only for the named
recipient(s). If you have received this message in error, or if you are
not the named recipient(s), please delete this email after notifying the
sender immediately. BKME cannot guarantee the integrity of this
communication and accepts no liability for any damage caused by this
email or its attachments due to viruses, any other defects, interception
or unauthorized modification. The information, views, opinions and
comments of this message are those of the individual and not necessarily
endorsed by BKME."

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.

<Prev in Thread] Current Thread [Next in Thread>