How to Offload Primary Database Controlfile backup in Dataguard Environment [ID 1160223.1]
		修改时间 20-JAN-2011     类型 HOWTO     状态 MODERATED

In this Document
  Goal
  Solution
  References

---

Platforms: 1-914CU;

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

Applies to:

Oracle Server - Enterprise Edition - Version: 11.1.0.6 to 11.2.0.2 - Release: 11.1 to 11.2
Information in this document applies to any platform.

Goal

From 11G onwards controlfile backups are interchangible. This is applicable for Physical standby only.

For example the controlfile backup taken on standby(the control file type is STANDBY) can be restored directly on primary and the controlfile type automatically converted as CURRENT.

The below note will explain how to restore backup of standby contrilfe on primary and what are the steps need to be taken care in order to make the standby in SYNC.

Solution

Example:

1. Connect to RMAN from standby,

RMAN> list backup of controlfile;


List of Backup Sets
===================


BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1 Full 9.33M DISK 00:00:05 26-JUL-10
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20100726T200849
Piece Name: D:\APP\NSELVAKU\FLASH_RECOVERY_AREA\CHICAGO\BACKUPSET\2010_07_26\O
1_MF_NCNNF_TAG20100726T200849_64V7HX4D_.BKP
Standby Control File Included: Ckp SCN: 1330245 Ckp time: 26-JUL-10

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2 Full 9.33M DISK 00:00:06 26-JUL-10
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20100726T212054
Piece Name: D:\APP\NSELVAKU\FLASH_RECOVERY_AREA\CHICAGO\BACKUPSET\2010_07_26\O
1_MF_NCNNF_TAG20100726T212054_64VCQ33X_.BKP
Standby Control File Included: Ckp SCN: 1353840 Ckp time: 26-JUL-10

2. On Primary connect to RMAN. Now we can directly move the backup of controlfile to primary and restore.

RMAN> restore controlfile from 'D:\APP\NSELVAKU\FLASH_RECOVERY_
2010_07_26\O1_MF_NCNNF_TAG20100726T212054_64VCQ33X_.BKP';

Starting restore at 26-JUL-10
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=153 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
output file name=D:\APP\NSELVAKU\ORADATA\BOSTON\CONTROL01.CTL
output file name=D:\APP\NSELVAKU\ORADATA\BOSTON\CONTROL02.CTL
output file name=D:\APP\NSELVAKU\ORADATA\BOSTON\CONTROL03.CTL
Finished restore at 26-JUL-10

RMAN> alter database mount;

using target database control file instead of recovery catalog
database mounted

3. Once restore done we can check the controlfile type on primary.

SQL> select database_role,controlfile_type from v$database;

DATABASE_ROLE CONTROL
---------------- -------
PRIMARY BACKUP

4.  Open the primary,

RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 07/26/2010 21:27:53
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\APP\NSELVAKU\ORADATA\BOSTON\SYSTEM01.DBF'

RMAN> recover database;

Starting recover at 26-JUL-10
Starting implicit crosscheck backup at 26-JUL-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=152 device type=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 26-JUL-10

Starting implicit crosscheck copy at 26-JUL-10
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 26-JUL-10

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: D:\APP\NSELVAKU\FLASH_RECOVERY_AREA\BOSTON\ARCHIVELOG\2010_06_03\O1_MF_1_3_
60HOTO3F_.ARC

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 16 is already on disk as file D:\APP\NSELVAKU\
ORADATA\BOSTON\REDO01.LOG
archived log for thread 1 with sequence 17 is already on disk as file D:\APP\NSELVAKU\
ORADATA\BOSTON\REDO02.LOG
archived log for thread 1 with sequence 18 is already on disk as file D:\APP\NSELVAKU\
ORADATA\BOSTON\REDO03.LOG
archived log file name=D:\APP\NSELVAKU\ORADATA\BOSTON\ARCH\ARC00014_0725401684.001 thr
ead=1 sequence=14
archived log file name=D:\APP\NSELVAKU\ORADATA\BOSTON\ARCH\ARC00015_0725401684.001 thr
ead=1 sequence=15
archived log file name=D:\APP\NSELVAKU\ORADATA\BOSTON\REDO01.LOG thread=1 sequence=16
archived log file name=D:\APP\NSELVAKU\ORADATA\BOSTON\REDO02.LOG thread=1 sequence=17
archived log file name=D:\APP\NSELVAKU\ORADATA\BOSTON\REDO03.LOG thread=1 sequence=18
media recovery complete, elapsed time: 00:00:04
Finished recover at 26-JUL-10

RMAN> alter database open resetlogs;

database opened

RMAN> exit

5.  When we opened the primary with RESETLOGS option the below points need to be taken care on standby, otherwise standby will fail with ORA-00328,

<>

MRP0: Background Media Recovery terminated with error 328
Errors in file d:\app\nselvaku\diag\rdbms\chicago\chicago\trace\chicago_mrp0_1528.trc:
ORA-00328: archived log ends at change 1330388, need later change 1330389
ORA-00334: archived log: 'D:\APP\NSELVAKU\ORADATA\CHICAGO\ARCH\ARC00016_0618886229.001'
Shutting down recovery slaves due to error 328
Recovery interrupted!


1. If standby was lagging behind the primary at the time of this issue then standby MRP will continue to apply RESETLOGS changes on subsequent logs.

2. If standby was in SYNC just before the time we restored the primary controlfile, then flashback the standby for the MRP to continue apply the RESETLOGS changes if flashback is enabled.

3. If no flashback then follow the below note,

<< Note 864364.1 >> -   How to resolve ORA:00328 in a standby database