Steve is correct. (this is valid for TSM 5.x anyway) For Oracle RMAN
Backups using the Data Protection Agent TSM is basically just a data
repository. Since every file that comes to TSM is unique, and TSM
doesn't and can't "scan the drive" as it would a file system, it can't
tell if the file has been deleted, or changed. So, the Policy should be
set as follows (per admin guide and Redbook):
Versions Data Exists: 1
Versions Data Deleted: 0
Retain Extra Versions: 0
Retain Only Version: 0
Then the client has to be allowed to delete backup and archive data.
The expiration then happens in RMAN when it runs its cleanup/expire
scripts, otherwise you'll have major discrepancies between the catalog
and the actual backups.
Your Oracle DBA (or you if they are the same) will need to setup expire
scripts to run each night after the backups run so that you don't just
keep piling up data. Then you will also want to run the tdposync
utility every now and then to clean up what didn't get properly expired.
Of course, you'll want to make sure you're Oracle Catalog is in good
shape.
Now, if you are somehow backing up the db files directly after shutting
down the db, then they are basically just files and TSM will handle
expiration at that point. Some do this through volume mirrors and
snapshots, etc.
See Ya'
Howard
> -----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 11:48 AM
> 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
> >
> >
>
>
>
> --
> 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
|
