Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RMAN backups to NFS OR FS 'snapshots'

Re: RMAN backups to NFS OR FS 'snapshots'

From: Patrick Boulay <boulayp_at_free.fr>
Date: Sat, 31 Mar 2007 18:07:31 -0700
Message-ID: <460e8774$0$26513$426a74cc@news.free.fr> 





sybrandb_at_hccnet.nl wrote:


> On Fri, 30 Mar 2007 13:49:02 -0400, NetComrade

> <netcomradeNSPAM_at_bookexchange.net> wrote:

> 


>> But biggest quesion:
>> How does rman work with snapshots :)




> 

> There is an article on Metalink for 10g.




Note:302615.1




> PURPOSE







Instruction using RMAN with split mirror backups.



SCOPE & APPLICATION






Customers using split mirror snapshot backup technology and wish
to utilize RMAN to backup from the snapshot copy.




RMAN and Split Mirror Disk Backups





Introduction



With databases growing from gigabytes to terabytes, taking backups to 
tape from


the production system can overload the system and their completion time can
exceed the backup window. Utilizing a split mirrored solution is 
becoming more


popular because of higher performance disk to disk snapshot technology. 
There


are several vendors that have certified their snapshot technology for 
use with


Oracle databases. The list of Oracle Storage Compatibility Program (OSCP)
snapshot vendors can be found on OTN.



In this article, we leave the snapshot instructions from the production 
to the


remote mirror up to the snapshot vendor and concentrate on the remote mirror
backup and the primary volumes maintenance for server managed recovery (SMR)
files using RMAN.



    I.    Register the Primary Production with the Recovery Catalog
    II.   Configure RMAN at the Production Database
    III.  Backup database from the split mirror disk
    IV.   Perform maintenance on the primary
    V.    Recovery Catalog Backup




I. Register the Primary Production with the Recovery Catalog



Register the production target volume database with the recovery 
catalog. This


is the only current controlfile to be used during RMAN operations.



  RMAN> register database;



If you connect to the recovery catalog after the snapshot while the mirror
database is mounted, the controlfile is still a current controlfile but is
a different version from the production current controlfile. We'll discuss
this more in the backup.



II.        Configure RMAN for backup



Update the controlfile persistent configuration parameters with the 
production


target database. The snapshot will overwrite the split mirror volume 
controlfile


each time a new snapshot is made. The configuration will be maintained 
in the


backup controlfile on the 3rd mirror and the recovery catalog.



DO NOT configure autobackup controlfile with this environment. The 
autobackup


cannot be made from the mirror volumes' backup controlfile; if configured,
autobackup will raise an error. Oracle never backs up a backup controlfile.
With a backup we know the information is not the most current. In this
configuration, "Oracle disk API" it configured to simulate writing to
tape. (Note: this is not supported for production backups.)




  CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;


  CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';


  CONFIGURE CONTROLFILE AUTOBACKUP OFF;


  CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO

  '/flash_recovery_area/V10P/%F';



  CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F';


  CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COPY;


  CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET;


  CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 

'SBT_LIBRARY=oracle.disksbt,


  ENV=(BACKUP_DIR=/n01/backup/V10P/TAPE)';



  CONFIGURE SNAPSHOT CONTROLFILE NAME TO

  '/app/oracle/product/10.1.0_64/dbs/snapcf_V10P.f';




III.             Backup database from the 3rd mirror



After the snapshot is complete, the controlfiles, datafiles, and archivelog
files should have been transferred to the 3rd mirror. As previously stated,
the controlfile is a current controlfile and we DO NOT want this copy to be
capable of full resync with the recovery catalog. When the database is 
mounted,


the timestamp will be from a CURRENT controlfile so we want to convert this
controlfile to a type BACKUP, and shutdown and startup mount again to 
obtain a new


timestamp for the backup controlfile.



  SQL> select controlfile_type from v$database;



  SQL> recover database using backup controlfile until cancel;


       Cancel



  SQL> shutdown



  SQL> startup mount



  SQL> select controlfile_type from v$database;



Now the 3rd mirror volume database controlfile is converted to a backup
controlfile and can safely connect to the recovery catalog without affecting
the behavior of the production database current controlfile. We can backup
using RMAN from the 3rd volume as if it's the production database.



A few points to keep in mind:



The result of connecting two versions of the same database current 
controlfile


is an RMAN-20035 'invalid high recid' error which is outlined in the RMAN
documentation.


  RMAN-3014: Implicit resync of recovery catalog failed
  RMAN-6038: Recovery catalog package detected an error
  RMAN-20035: Invalid high RECID error





This error has been documented in the RMAN Troubleshooting section of the
Recovery Manager Users Guide.



  ? If the V$DATABASE.CONTROLFILE_TYPE is current and is used from
    the primary and mirror volume databases and a full resync occurs,
    then all subsequent resync will fail. The solution in this case is
    to recreate the current controlfile from the primary production
    database. The recovery catalog still contains all the current
    backup and archivelog information from each system.



  ? Oracle Database 10g RMAN has a CATALOG BACKUPPIECE command. Rather
    then impacting the production database with an outage to rebuild
    the controlfile for the recovery catalog, the database can be
    unregistered from the recovery catalog. Register again and then
    catalog the backup directory on disk with RMAN. More information
    on the command can be found in documentation.



  ? You cannot catalog backups that reside on tape.



Connect to the mirror database as the target using RMAN. It is now using a
backup controlfile and will display all the information that was available
at the primary at the time the snapshot was taken. Since the controlfile was
converted to a backup and a shutdown and startup mount was already 
performed,


the backup controlfile has a new timestamp.



Since the controlfile is a backup controlfile, not all record sections will
resync with the recovery catalog. RMAN updates physical schema information
in the recovery catalog only when the target database has the current 
control


file mounted. If the target database has mounted a backup control file, a
freshly created control file, or a control file that is less current than a
control file that was used previously, then RMAN does not update physical
schema information in the recovery catalog. This deficiency is addressed in
section IV below.



A backup schedule could be scripted as follows:



Daily:



  DELETE BACKUP OF DATABASE COMPLETED BEFORE 'SYSDATE-14' DEVICE TYPE DISK;


  DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-2' BACKED UP 2 TIMES

  TO DEVICE TYPE SBT;


  BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 0 DATABASE;


  BACKUP DEVICE TYPE SBT ARCHIVELOG ALL NOT BACKED UP 2 TIMES;


Weekly:



  BACKUP DEVICE TYPE SBT BACKUPSET ALL;


The daily backups can be level 0 or greater if you want to have an 
incremental


strategy. The delete of the archivelog when using a backup controlfile 
is not


resynced with the recovery catalog because these files may still exist 
on the


primary.



IV.          Performing maintenance from the primary database



At the primary, we need to backup the controlfile and resync periodically so
that the recovery catalog has the most current information about the 
database.


The resync should be setup so that after a pre-determined number of 
archivelogs


are created, a resync should be performed to update the recovery catalog 
of the


most current information. This resync will also update any physical 
changes to


the database.



Daily:



  DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-2' BACKED UP 2 TIMES

  TO DEVICE TYPE SBT;


  BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE;


Periodically: (e.g. should be done after x logs are archived, datafile
autoextention, addition of tablespaces or rbs...)



  RESYNC CATALOG;


The DELETE commands using the current controlfile will perform a full resync
of the SMR files and the physical schema, updating the control file records
with the correct values. The resync propagates the data from the controlfile
to the recovery catalog, but does not send any data from the recovery 
catalog


to the controlfile. This makes the recovery catalog the brain behind your
backup and recovery scheme.



V.            Recovery Catalog Backup



You can backup the RMAN recovery catalog using export. An export of the 
recovery


catalog schema can be imported into any like version Oracle database and 
used


for database recovery. Another method is to create another recovery 
catalog and


register the catalog database there. Connect to the catalog as the 
target and


the new recovery catalog as the RMAN recovery catalog. Then backup up the
catalog database using RMAN.



Summary:





Using an OSCP member's snapshot technology can decrease the overall time for
backup of the primary production database. Making RMAN backups from the 
mirrored


volume takes the load of tape backup off the primary server.



Using a backup controlfile on the mirror volume allows you to use the 
primary


production controlfile to backup the current controlfile, resync the 
database


schema, and perform maintenance on archivelog files. It is important to 
use RMAN


to cleanup these SMR files on the primary and mirror volumes, as they are
tracked by Oracle in the controlfile and recovery catalog.



Split mirror backups offer more options for restore and recovery in snapshot
environments. If the production database requires restore and recovery, the
latest snapshot can be copied back to the production volume. In the event of
disaster recovery of production and mirror volumes, the RMAN backups can be
utilized to restore and recover the database to the primary volume.
Received on Sat Mar 31 2007 - 20:07:31 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US