Agreed, I can't see how a RETEXTRA of above 0 will benefit you as, without some 
hacking around, you wouldn't be able to use RMAN to recover that data from TSM. 
Depending upon the size of your database backups, it could be substantially 
adding to your storage footprint. 

Has anyone else come across practical instances where it is beneficial to have 
anything other than the recommended 1 0 0 0 for TDP Oracle backup copygroups?

Cheers,

/David Mc
London, UK
Sent from my BlackBerry® wireless device

-----Original Message-----
From: Steve Stackwick <sstackwick AT JASI DOT COM>
Date:         Wed, 30 Dec 2009 08:12:09 
To: <ADSM-L AT VM.MARIST DOT EDU>
Subject: Re: [ADSM-L] tsm tdp oracle rman backups

Grigori,

No, I probably just read your original post wrong and thought you were
setting RMAN's retention policy to REDUNDANCY 31, instead of RECOVERY
WINDOW 31, which would be preferable. And, as you say, with RECOVERY
WINDOW 31, RMAN should keep all backups that will allow you to
recovery to 31 days ago, even if the backups are older than 31 days.

As for TSM RETEXTRA 31, you are right, that does no harm, but it is unnecessary.

Steve

On Wed, Dec 30, 2009 at 12:21 AM, Grigori Solonovitch
<G.Solonovitch AT bkme DOT com> wrote:
> Hello Steve,
>
> I am setting in RMAN Recovery Catalog for each database:
>
> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 31 DAYS;
>
> In my opinion, this instructs RMAN to keep all required backups (full + 
> incremental + archived redo logs) to be able to recover database to any point 
> of time for the last 31 days.
>
> It does not mean, RMAN is keeping backups only for last 31 days. It depends 
> on frequency of full backups. I am running full backup twice per month and I 
> see backups from last 31 to 47 days.
>
> Status of files is maintained by RMAN. Of course, you are right - all of TDPO 
> backups are unique from TSM point of view (it means always active). But RMAN 
> expires backups which are not required more for 31 days recovery window. Note 
> RMAN does not remove backups. I was trying to find in documentation, what is 
> correct setup in copy group for TDPO backups. But I did not find anything 
> useful, except verdeleted 0 and retonly 0, which are very clear - TSM removes 
> TDPO backups immediately after expiration. In addition, I have decided to set 
> retextra 31. Maybe I am wrong, but there is nothing dangerous in this case.
>
> 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 Steve Stackwick
> Sent: Tuesday, December 29, 2009 8:48 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] tsm tdp oracle rman backups
>
>
>
> Grigori,
>
>
>
> Don't you mean RMAN "recovery window"? Redundancy means how many backup
>
> versions RMAN will keep, recovery window means for how many days back. And I
>
> don't think RETAIN EXTRA does much for you, since each version is unique
>
> from RMAN (i.e, they're all named differently).
>
>
>
> AFAIK, the only policy definitions that need to be set are:
>
>
>
> verdeleted 0
>
> retonly 0
>
>
>
> to allow RMAN to control expiration and deletion of backups.
>
>
>
> Steve
>
>
>
> On Sun, Dec 20, 2009 at 10:34 AM, Grigori Solonovitch <
>
> G.Solonovitch AT bkme DOT com> wrote:
>
>
>
>> Hello Tim,
>
>> For RMAN redundancy policy 31 days I have in copy group:
>
>> tsm: BKME>q copy aix aix dblpar05 f=d
>
>>                        Policy Domain Name: AIX
>
>>                               Policy Set Name: AIX
>
>>                            Mgmt Class Name: DBLPAR05
>
>>                           Copy Group Name: STANDARD
>
>>                            Copy Group Type: Backup
>
>>                         Versions Data Exists: No Limit
>
>>                      Versions Data Deleted: 0
>
>>                        Retain Extra Versions: 31
>
>>                          Retain Only Version: 0
>
>>                                      Copy Mode: Modified
>
>>                             Copy Serialization: Shared Static
>
>>                               Copy Frequency: 0
>
>>                              Copy Destination: DAILY_2
>
>> Table of Contents (TOC) Destination:
>
>>          Last Update by (administrator): SA25577
>
>>                     Last Update Date/Time: 08/04/09   16:27:32
>
>>                               Managing profile:
>
>>                              Changes Pending: No
>
>> tsm: BKME>
>
>> I hope you have requested this information.
>
>> Grigori
>
>>
>
>>________________________________________
>
>> From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tim
>
>> Brown [tbrown AT CENHUD DOT COM]
>
>> Sent: Sunday, December 20, 2009 5:53 PM
>
>> To: ADSM-L AT VM.MARIST DOT EDU
>
>> Subject: Re: [ADSM-L] tsm tdp oracle rman backups
>
>>
>
>> Grigori
>
>>
>
>> Thanks , can you tell me what you have for TSM copygroup settings
>
>>
>
>> Tim
>
>> ----- Original Message -----
>
>> From: "Grigori Solonovitch" <G.Solonovitch AT BKME DOT COM>
>
>> To: <ADSM-L AT VM.MARIST DOT EDU>
>
>> Sent: Friday, December 18, 2009 10:22 PM
>
>> Subject: Re: tsm tdp oracle rman backups
>
>>
>
>>
>
>> Hello Tim,
>
>> I see "RMAN retention policy is set to redundancy 3" in provided log.
>
>> This means that you requested RMAN to provide a possibility to
>
>> restore/recover database for only 3 last days. In my opinion, this value is
>
>> too low. I have full backup every 2 weeks and daily incremental backups
>
>> between full baqckups. Retention policy is set to redundancy 31. As a
>
>> result, I can restore database to any point in time for the last month.
>
>> Note
>
>> that amount of data is only a little more than for your case, because I am
>
>> keeping only 3 full backups like you.
>
>> By the way, everything is correct if 3 days is your target and you are
>
>> running full backup every night. It does not matter how many additional
>
>> incremental backups you are performing every day and which level. RMAN will
>
>> keep last 3 full backups and all incremental backups between them.
>
>> Incremetal backups between full backups can only reduce recovery time,
>
>> because it is much faster to restore incremental backup than to restore and
>
>> apply appropriate archived redo logs. At the same, tine it means RMAN will
>
>> expire one full backup and all incrementals between this full backup and
>
>> next one every day.
>
>>
>
>> For example, If you have:
>
>>
>
>> 15/12/2009 Full Backup
>
>> 15/12/2009 Incremental backup level 1
>
>> 16/12/2009 Full Backup
>
>> 16/12/2009 Incremental backup level 1
>
>> 16/12/2009 Incremental backup level 2
>
>> 16/12/2009 Incremental backup level 1
>
>> 17/12/2009 Full Backup
>
>> 17/12/2009 Incremental backup level 1
>
>> 17/12/2009 Incremental backup level 1
>
>> 18/12/2009 Full Backup
>
>>
>
>> If you run:
>
>>
>
>> 19/12/2009 Full Backup
>
>> 19/12/2009 Expire Inventory
>
>>
>
>> all next backups:
>
>>
>
>> 15/12/2009 Full Backup
>
>> 15/12/2009 Incremental backup level 1
>
>>
>
>> will be removed definately, because they are not required more to be able
>
>> to
>
>> restore for requested 3 days:
>
>>
>
>> 16/12/2009 Full Backup
>
>> 16/12/2009 Incremental backup level 1
>
>> 16/12/2009 Incremental backup level 2
>
>> 16/12/2009 Incremental backup level 1
>
>> 17/12/2009 Full Backup
>
>> 17/12/2009 Incremental backup level 1
>
>> 17/12/2009 Incremental backup level 1
>
>> 18/12/2009 Full Backup
>
>> 19/12/2009 Full Backup
>
>>
>
>> Of course, I suppose you have correct setting for related copy group for
>
>> your case, at least 0 0 4 4.
>
>>
>
>> Kindets regards,
>
>> Grigori
>
>>
>
>>________________________________________
>
>> From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Tim
>
>> Brown
>
>> [tbrown AT CENHUD DOT COM]
>
>> Sent: Friday, December 18, 2009 11:46 PM
>
>> To: ADSM-L AT VM.MARIST DOT EDU
>
>> Subject: [ADSM-L] tsm tdp oracle rman backups
>
>>
>
>> Anyone performing full and incrmental backups of Oracle
>
>>
>
>> We run a level 0 on Friday night and a combination of level 1's and 2's
>
>> the othter nights.
>
>>
>
>> We just started inc backups, prior to that we were doing fulls each night.
>
>>
>
>> We would run a delete obsolete rman command after the full backps to keep 3
>
>> levels
>
>> This wasnt changed when we went to incremental. I noticed in one of the log
>
>> files
>
>> this morning that rman deleted one the backup pieces created during the
>
>> level 0 backup
>
>>
>
>> I dont think this should be the case. If we wanted to restore the level 0
>
>> we
>
>> would be missing files
>
>>
>
>> What are the optimum RMAN retention policies and TSM retention policies for
>
>> Oracle
>
>>
>
>> They must be different between using always full backups or a combination
>
>> of
>
>> full and inc
>
>>
>
>>
>
>> RMAN retention policy will be applied to the command
>
>> RMAN retention policy is set to redundancy 3
>
>> Deleting the following obsolete backups and copies:
>
>> Type                 Key    Completion Time    Filename/Handle
>
>> -------------------- ------ ------------------ --------------------
>
>> Backup Set           31844  12-DEC-09
>
>>  Backup Piece       31844  12-DEC-09          df_705420601_31958_1  <=full
>
>> Backup Set           32011  15-DEC-09
>
>>  Backup Piece       32011  15-DEC-09          bul0ucfs_1_1   <== inc
>
>> deleted backup piece
>
>> backup piece handle=df_705420601_31958_1 recid=31844 stamp=705420603
>
>> deleted backup piece
>
>> backup piece handle=bul0ucfs_1_1 recid=32011 stamp=705638909
>
>> Deleted 2 objects
>
>>
>
>> Tim Brown
>
>> Systems Specialist - Project Leader
>
>> Central Hudson Gas & Electric
>
>> 284 South Ave
>
>> Poughkeepsie, NY 12601
>
>> Email: tbrown AT cenhud DOT com <mailto:tbrown AT cenhud DOT com>
>
>> Phone: 845-486-5643
>
>> Fax: 845-486-5921
>
>> Cell: 845-235-4255
>
>>
>
>>
>
>> This message contains confidential information and is only for the intended
>
>> recipient.  If the reader of this message is not the intended recipient, or
>
>> an employee or agent responsible for delivering this message to the
>
>> intended
>
>> recipient, please notify the sender immediately by replying to this note
>
>> and
>
>> deleting all copies and attachments.  Thank you.
>
>>
>
>> 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 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."
>
>>
>
>
>
>
>
>
>
> --
>
> Stephen Stackwick
>
> ICF Jacob & Sundstrom
>
> 401 East Pratt St., Suite 2214
>
> Baltimore, MD 21202-3003
>
> (410) 539-1135 * (866) 539-1135
>
> sstackwick AT icfi DOT com
>
>________________________________
> "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."
>



-- 
Stephen Stackwick
ICF Jacob & Sundstrom
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick AT icfi DOT com