ADSM-L

Re: [ADSM-L] tsm tdp oracle rman backups

2009-12-29 12:49:34
Subject: Re: [ADSM-L] tsm tdp oracle rman backups
From: Steve Stackwick <sstackwick AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Dec 2009 12:48:02 -0500
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