從dataguard備份的恢復機制
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.2Information 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
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/756652/viewspace-730112/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【備份恢復】從備份恢復資料庫資料庫
- Oracle備份恢復之熱備份恢復及異機恢復Oracle
- Oracle SCN機制———在備份與恢復中Oracle
- Oracle 9i的備份和恢復機制(轉)Oracle
- 備份與恢復--從備份的歸檔日誌中恢復資料
- 我對備份與恢復的內部機制的理解
- 控制檔案恢復—從自動或二進位制備份中恢復
- oracle冷備份、恢復和異機恢復Oracle
- Oracle 聯機備份 離線備份 物理備份 恢復Oracle
- 備份與恢復--利用備份的控制檔案恢復
- 【管理篇備份恢復】備份恢復基礎
- ORACLE DG從庫 Rman備份恢復Oracle
- 備份與恢復系列 十一 控制檔案的備份與恢復
- MySQL備份與恢復——基於Xtrabackup物理備份恢復MySql
- 同平臺異機備份恢復
- Mysql備份恢復MySql
- Postgresql 備份恢復SQL
- redis備份恢復Redis
- mysql 備份恢復MySql
- 備份&恢復之四:非歸檔模式下的備份與恢復模式
- 資料庫備份與異機恢復——熱備份方式資料庫
- 一次dataguard備份恢復到單例項的故障記錄單例
- 備份與恢復:polardb資料庫備份與恢復資料庫
- 【備份恢復】Oracle 資料備份與恢復微實踐Oracle
- 第5章:從開啟的資料庫備份與恢復之從開啟的資料庫備份中完全恢復資料庫
- Mysql的備份與恢復MySql
- 揭密備份恢復的原理
- 如何透過rman的增量備份恢復dataguard中standby端的資料
- Backup And Recovery User's Guide-備份和恢復概覽-備份和恢復介紹-備份和恢復的目的GUIIDE
- 從nub備份恢復(同平臺)恢復RAC至單例項單例
- 備份與恢復系列 十 引數檔案spfile的備份與恢復
- Oracle DG從庫 Rman備份恢復測試Oracle
- RMAN備份異機恢復流程總結
- 【物理熱備】(下)備份恢復系統表空間 手工備份恢復
- 詳解叢集級備份恢復:物理細粒度備份恢復
- 【備份恢復】noarchive模式下使用增量備份恢復資料庫Hive模式資料庫
- windwos server 路由備份和恢復 路由表備份和恢復Server路由
- 【備份恢復】資料恢復指導資料恢復