Oracle資料庫恢復之resetlogs

AlfredZhao發表於2019-05-19

實驗環境：RHEL 5.4 + Oracle 11.2.0.3
如果是一名合格的Oracle DBA，對resetlogs這種關鍵字都應該是極其敏感的，當確認需要這種操作時一定要三思而後行，如果自己不是特別確認，哪怕多花些時間申請去讓高階DBA人員協助你一起確認，也不要擅自去嘗試執行，避免誤操作造成既定損失後追悔莫及。

1.哪些場景可以resetlogs

首先要明確resetlogs操作非常危險的，也只有在進行不完全恢復開庫時會使用到。

SQL> alter database open resetlogs;
-> open the database and reset the online logs

官方的描述如下：

Incomplete recovery, also called database point-in-time recovery, results in a noncurrent version of the database. In this case, you do not apply all of the redo generated after the restored backup. Typically, you perform point-in-time database recovery to undo a user error when Flashback Database is not possible.
To perform incomplete recovery, you must restore all data files from backups created before the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. Resetting the logs creates a new stream of log sequence numbers starting with log sequence 1.

官方的描述其實很清晰，但是實際很多初級DBA小夥伴們在實際工作中遇到這樣的場景時卻總是有些困惑，甚至誤操作引發災難。
我這裡以一個實驗來具體說明常見場景：
需求：A機資料庫PROD1，現需在B機不同目錄下用A機的備份集恢復出來；

A機：

--A機當前current redolog的sequence是57:
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
         1          1         55   52428800        512          1 YES INACTIVE               2051572 19-MAY-19      2060361 19-MAY-19
         2          1         56   52428800        512          1 YES INACTIVE               2060361 19-MAY-19      2060436 19-MAY-19
         3          1         57   52428800        512          1 NO  CURRENT                2060436 19-MAY-19   2.8147E+14

--A機做了一次資料庫備份：
RMAN> backup database include current controlfile plus archivelog delete all input;


Starting backup at 19-MAY-19
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=23 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=189 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=21 device type=DISK
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=57 RECID=3 STAMP=1008670991
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0cu1u68l_1_1.bak tag=TAG20190519T102315 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_57_860888149.dbf RECID=3 STAMP=1008670991
Finished backup at 19-MAY-19

Starting backup at 19-MAY-19
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/u01/app/oracle/oradata/PROD1/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_2: starting compressed full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/PROD1/system01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/PROD1/users01.dbf
channel ORA_DISK_2: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: starting compressed full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/PROD1/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/PROD1/undotbs01.dbf
channel ORA_DISK_3: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0fu1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:26
channel ORA_DISK_3: starting compressed full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_3: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0gu1u69j_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0du1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:03
channel ORA_DISK_2: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0eu1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:01:23
Finished backup at 19-MAY-19

Starting backup at 19-MAY-19
current log archived
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=58 RECID=4 STAMP=1008671084
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0hu1u6bg_1_1.bak tag=TAG20190519T102446 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_58_860888149.dbf RECID=4 STAMP=1008671084
Finished backup at 19-MAY-19

Starting Control File and SPFILE Autobackup at 19-MAY-19
piece handle=/home/oracle/backup/control/c-2082231315-20190519-01 comment=NONE
Finished Control File and SPFILE Autobackup at 19-MAY-19

RMAN> 

--可以看到備份資料庫的日誌前後都自動歸檔了當前的redolog（57和58），所以備份完成後，當前日誌sequence變為59.
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
         1          1         58   52428800        512          1 YES INACTIVE               2060691 19-MAY-19      2060767 19-MAY-19
         2          1         59   52428800        512          1 NO  CURRENT                2060767 19-MAY-19   2.8147E+14
         3          1         57   52428800        512          1 YES INACTIVE               2060436 19-MAY-19      2060691 19-MAY-19

此時把備份集傳輸到B機，比如/u03/backup目錄下，期望恢復到/u03/oradata/PROD1目錄下。如果最終只是根據這個備份集去恢復，那最多恢復完sequence 58就結束了，找不到sequence 59（因為59還是當前current的redolog）。Oracle認為這就是最基本的不完全恢復，需要resetlogs操作。

--指定恢復到/u03/oradata/
RMAN> run {
2> set newname for database to '/u03/oradata/PROD1/%U';
3> restore database;
4> }

--切換到上步恢復出來的copy複本：
RMAN> switch database to copy;

datafile 1 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-SYSTEM_FNO-1"
datafile 2 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-SYSAUX_FNO-2"
datafile 3 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-UNDOTBS1_FNO-3"
datafile 4 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-USERS_FNO-4"
datafile 5 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-EXAMPLE_FNO-5"

--嘗試恢復資料庫：
RMAN> recover database;

Starting recover at 19-MAY-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=102 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=9 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=112 device type=DISK

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=58
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0hu1u6bg_1_1.bak
channel ORA_DISK_1: errors found reading piece handle=/home/oracle/backup/0hu1u6bg_1_1.bak
channel ORA_DISK_1: failover to piece handle=/u03/backup/0hu1u6bg_1_1.bak tag=TAG20190519T102446
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_58_860888149.dbf thread=1 sequence=58
unable to find archived log
archived log thread=1 sequence=59
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/19/2019 11:04:21
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 59 and starting SCN of 2060767

RMAN>

可以看到最後有報錯資訊，就是告訴你找不到sequence 59的日誌，這是必然的，因為59還是A機current的redo日誌。

2.resetlogs前必須確認路徑正確

2.1 先檢視控制檔案和資料檔案頭記錄的scn是否一致

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#
------------------
           2060767
           2060767
           2060767
           2060767
           2060767

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#
------------------
           2060767
           2060767
           2060767
           2060767
           2060767

2.2 此時如果嘗試直接OPEN會報錯

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

提示我們開庫必須使用RESETLOGS或者NORESETLOGS選項。

2.3 重點來了，現在可以open resetlogs嗎？
當然不行！記得一定要確認好路徑！！

--查詢發現臨時檔案以及redo日誌的路徑都不是我們所期望的：
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u03/oradata/PROD1/data_D-PROD1_TS-SYSTEM_FNO-1
/u03/oradata/PROD1/data_D-PROD1_TS-SYSAUX_FNO-2
/u03/oradata/PROD1/data_D-PROD1_TS-UNDOTBS1_FNO-3
/u03/oradata/PROD1/data_D-PROD1_TS-USERS_FNO-4
/u03/oradata/PROD1/data_D-PROD1_TS-EXAMPLE_FNO-5

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/PROD1/temp01.dbf

SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/PROD1/redo03.log
/u01/app/oracle/oradata/PROD1/redo02.log
/u01/app/oracle/oradata/PROD1/redo01.log

--rename重新命名為我們期望的目錄：
SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/temp01.dbf' to '/u03/oradata/PROD1/temp01.dbf';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo01.log' to '/u03/oradata/PROD1/redo01.log';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo02.log' to '/u03/oradata/PROD1/redo02.log';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo03.log' to '/u03/oradata/PROD1/redo03.log';

Database altered.

--再次檢查確認：
SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
/u03/oradata/PROD1/temp01.dbf

SQL>  select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u03/oradata/PROD1/redo03.log
/u03/oradata/PROD1/redo02.log
/u03/oradata/PROD1/redo01.log

--最終嘗試open開庫：
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL> alter database open resetlogs;

Database altered.

總結：很多初級人員有可能是對set newname for database這個有誤解，以為這裡的database包括了臨時檔案，redo日誌檔案，誤以為自己已經把新庫所有路徑都指向到了期望位置。但實際並不是這樣，這也說明了不確認的操作一定要在測試環境測試驗證後才可以在生產環境操作。大家可以想象一下，如果是理解有誤沒確認日誌路徑直接執行了resetlogs，那麼如果B機正好有別的庫用到同名的這些路徑，亦或是整個恢復操作就是直接在A機的本機其他目錄臨時基於某個時間點恢復出一套庫，那將會是一場大的生產事故。

10可以穿越resetlogs恢復資料庫！
2006-12-27
資料庫
oracle之rman恢復資料庫
2010-09-17
Oracle資料庫
open resetlogs後資料恢復
2013-11-10
資料恢復
使用RESETLOGS重建控制檔案恢復資料庫
2013-11-21
資料庫
資料庫resetlogs後進行rman恢復7
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復6
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復5
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復4
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復3
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復2
2013-08-03
資料庫
資料庫resetlogs後進行rman恢復1
2013-08-03
資料庫
Oracle資料恢復:強制Resetlogs的可能資料損失
2010-07-13
Oracle資料恢復
使用RESETLOGS重建控制檔案恢復資料庫（二）
2013-11-22
資料庫
【資料庫資料恢復】如何恢復Oracle資料庫truncate表的資料
2022-10-24
資料庫資料恢復Oracle
Oracle資料庫備份與恢復之RMAN
2008-12-27
Oracle資料庫
Oracle資料庫RMAN小結之恢復部分
2011-12-23
Oracle資料庫
【資料庫資料恢復】Oracle資料庫誤truncate table的資料恢復案例
2022-05-17
資料庫資料恢復Oracle
【資料庫資料恢復】oracle資料庫誤truncate table怎麼恢復資料？
2022-12-27
資料庫資料恢復Oracle
【資料庫資料恢復】誤truncate table的Oracle資料庫資料恢復方案
2023-03-24
資料庫資料恢復Oracle
缺少歸檔日誌，ORACLE資料庫恢復使用_allow_resetlogs_corruption引數
2014-10-29
Oracle資料庫
【資料庫資料恢復】Oracle資料庫ASM磁碟組掉線如何恢復資料？
2023-03-03
資料庫資料恢復OracleASM
Oracle異地資料庫恢復
2016-11-07
Oracle資料庫
Oracle資料庫終極恢復
2013-12-13
Oracle資料庫
nbu恢復oracle資料庫案例
2013-12-08
Oracle資料庫
ORACLE資料庫恢復技術
2007-07-25
Oracle資料庫
恢復之RAC資料庫RECOVER
2008-09-18
資料庫
【資料庫資料恢復】ASM磁碟組掉線的Oracle資料庫資料恢復案例
2022-10-11
資料庫資料恢復ASMOracle
【資料庫資料恢復】SAP資料庫資料恢復案例
2022-05-05
資料庫資料恢復
恢復之資料庫關閉時的完全恢復
2009-02-11
資料庫
oracle 資料庫全庫恢復實驗
2008-09-23
Oracle資料庫
資料庫資料恢復-oracle資料庫報錯無法開啟的如何恢復資料？
2023-10-12
資料庫資料恢復Oracle
【資料庫資料恢復】ASM例項不能掛載的Oracle資料庫資料恢復案例
2024-02-01
資料庫資料恢復ASMOracle
寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復寶塔mysql資料庫恢復
2020-11-10
資料庫MySql
Oracle資料庫備份與恢復之RMAN2
2008-12-27
Oracle資料庫
【資料庫資料恢復】斷電導致Oracle資料庫資料丟失的資料恢復案例
2022-09-08
資料庫資料恢復Oracle
【資料庫資料恢復】Sql Server資料庫資料恢復案例
2022-05-27
資料庫資料恢復SQLServer
Oracle資料庫冷備和恢復
2018-11-22
Oracle資料庫
Oracle & MySQL & PostgreSQL資料庫恢復支援
2021-11-22
OracleMySql資料庫

Oracle資料庫恢復之resetlogs

1.哪些場景可以resetlogs

2.resetlogs前必須確認路徑正確

相關文章