ITPub博客

首页 > Linux操作系统 > Linux操作系统 > RMAN and Split Mirror Disk Backups [ID 302615.1]

RMAN and Split Mirror Disk Backups [ID 302615.1]

原创 Linux操作系统 作者:fulzu 时间:2009-12-01 20:24:57 0 删除 编辑

对于数据库采用第三方软件备份的技术,使用rman备份需要注意的东西如下metalink文档

"Checked for relevance on 28-Jun-2009"

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.

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 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.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10805681/viewspace-621104/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-03-28

  • 博文量
    68
  • 访问量
    72368