Oracle數(shù)據(jù)庫恢復(fù)教程之resetlogs操作
更新時(shí)間：2019年05月19日 15:39:42 作者：AlfredZhao
這篇文章主要給大家介紹了關(guān)于Oracle數(shù)據(jù)庫恢復(fù)教程之resetlogs操作的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家學(xué)習(xí)或者使用Oracle數(shù)據(jù)庫具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧
實(shí)驗(yàn)環(huán)境：RHEL 5.4 + Oracle 11.2.0.3
如果是一名合格的Oracle DBA，對(duì)resetlogs這種關(guān)鍵字都應(yīng)該是極其敏感的，當(dāng)確認(rèn)需要這種操作時(shí)一定要三思而后行，如果自己不是特別確認(rèn)，哪怕多花些時(shí)間申請(qǐng)去讓高級(jí)DBA人員協(xié)助你一起確認(rèn)，也不要擅自去嘗試執(zhí)行，避免誤操作造成既定損失后追悔莫及。
1.哪些場(chǎng)景可以resetlogs
首先要明確resetlogs操作非常危險(xiǎn)的，也只有在進(jìn)行不完全恢復(fù)開庫時(shí)會(huì)使用到。
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.
官方的描述其實(shí)很清晰，但是實(shí)際很多初級(jí)DBA小伙伴們?cè)趯?shí)際工作中遇到這樣的場(chǎng)景時(shí)卻總是有些困惑，甚至誤操作引發(fā)災(zāi)難。
我這里以一個(gè)實(shí)驗(yàn)來具體說明常見場(chǎng)景：
需求：A機(jī)數(shù)據(jù)庫PROD1，現(xiàn)需在B機(jī)不同目錄下用A機(jī)的備份集恢復(fù)出來；
A機(jī)：
--A機(jī)當(dāng)前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機(jī)做了一次數(shù)據(jù)庫備份： 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> --可以看到備份數(shù)據(jù)庫的日志前后都自動(dòng)歸檔了當(dāng)前的redolog（57和58），所以備份完成后，當(dāng)前日志sequence變?yōu)?9. 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
此時(shí)把備份集傳輸?shù)紹機(jī)，比如/u03/backup目錄下，期望恢復(fù)到/u03/oradata/PROD1目錄下。如果最終只是根據(jù)這個(gè)備份集去恢復(fù)，那最多恢復(fù)完sequence 58就結(jié)束了，找不到sequence 59（因?yàn)?9還是當(dāng)前current的redolog）。Oracle認(rèn)為這就是最基本的不完全恢復(fù)，需要resetlogs操作。
--指定恢復(fù)到/u03/oradata/
RMAN> run {
2> set newname for database to '/u03/oradata/PROD1/%U';
3> restore database;
4> }
--切換到上步恢復(fù)出來的copy復(fù)本：
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"
--嘗試恢復(fù)數(shù)據(jù)庫：
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>
可以看到最后有報(bào)錯(cuò)信息，就是告訴你找不到sequence 59的日志，這是必然的，因?yàn)?9還是A機(jī)current的redo日志。
2.resetlogs前必須確認(rèn)路徑正確
2.1 先查看控制文件和數(shù)據(jù)文件頭記錄的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 此時(shí)如果嘗試直接OPEN會(huì)報(bào)錯(cuò)
SQL> alter database open; alter database open * ERROR at line 1: ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
提示我們開庫必須使用RESETLOGS或者NORESETLOGS選項(xiàng)。
2.3 重點(diǎn)來了，現(xiàn)在可以open resetlogs嗎？
當(dāng)然不行！記得一定要確認(rèn)好路徑?。?/p>
--查詢發(fā)現(xiàn)臨時(shí)文件以及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. --再次檢查確認(rèn)： 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.
總結(jié)：
很多初級(jí)人員有可能是對(duì)set newname for database這個(gè)有誤解，以為這里的database包括了臨時(shí)文件，redo日志文件，誤以為自己已經(jīng)把新庫所有路徑都指向到了期望位置。但實(shí)際并不是這樣，這也說明了不確認(rèn)的操作一定要在測(cè)試環(huán)境測(cè)試驗(yàn)證后才可以在生產(chǎn)環(huán)境操作。大家可以想象一下，如果是理解有誤沒確認(rèn)日志路徑直接執(zhí)行了resetlogs，那么如果B機(jī)正好有別的庫用到同名的這些路徑，亦或是整個(gè)恢復(fù)操作就是直接在A機(jī)的本機(jī)其他目錄臨時(shí)基于某個(gè)時(shí)間點(diǎn)恢復(fù)出一套庫，那將會(huì)是一場(chǎng)大的生產(chǎn)事故。
好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。
相關(guān)文章
Oracle數(shù)據(jù)庫失效對(duì)象處理詳情
這篇文章主要介紹了Oracle數(shù)據(jù)庫失效對(duì)象處理，數(shù)據(jù)庫業(yè)務(wù)用戶（非 SYS/Public）下存在失效對(duì)象。對(duì)失效對(duì)象進(jìn)行分析，主要包括失效的視圖、物化視圖、函數(shù)、包、觸發(fā)器等，下面帶著些許了解一起深入學(xué)習(xí)下面文章學(xué)習(xí)內(nèi)容吧2021-10-10
Oracle19c最新版保姆級(jí)別最詳細(xì)的安裝配置教程(2023年)
這篇文章主要給大家介紹了關(guān)于Oracle19c最新版保姆級(jí)別安裝配置教程的相關(guān)資料,19c作為原有序列的12c最后一個(gè)版本,可以說是集大成的版本,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-07-07
怎么才能限制SQL Server只能讓指定的機(jī)器連接
怎么才能限制SQL Server只能讓指定的機(jī)器連接...2007-03-03
解決navicat 鏈接oracle時(shí)出現(xiàn)的各種問題
這篇文章主要介紹了解決navicat 鏈接oracle時(shí)出現(xiàn)的各種問題,非常不錯(cuò)，具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2018-08-08
oracle數(shù)據(jù)匹配merge into的實(shí)例詳解
這篇文章主要介紹了oracle數(shù)據(jù)匹配merge into的實(shí)例詳解的相關(guān)資料,希望通過本文能幫助到大家，需要的朋友可以參考下2017-10-10
Oracle 數(shù)據(jù)顯示 橫表轉(zhuǎn)縱表
橫表轉(zhuǎn)縱表亦可用與decode意義相似的case語句實(shí)現(xiàn)，原理同該語句，這里不再過多描述。2009-07-07
關(guān)于使用PLSQL Developer時(shí)出現(xiàn)報(bào)錯(cuò)ora-12514的問題
這篇文章主要介紹了關(guān)于使用PLSQL Developer時(shí)出現(xiàn)報(bào)錯(cuò)ora-12514的問題,本文給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-11-11
如果Oracle卸載不干凈就會(huì)導(dǎo)致下次安裝失敗，這篇文章主要為大家詳細(xì)介紹了Oracle完美卸載的全部過程，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2016-12-12
oracle定時(shí)任務(wù)定時(shí)無效的原因分析與解決
發(fā)現(xiàn)系統(tǒng)數(shù)據(jù)沒有更新,查看oracle定時(shí)任務(wù),估計(jì)沒有執(zhí)行,下面這篇文章主要給大家介紹了關(guān)于oracle定時(shí)任務(wù)定時(shí)無效的原因分析與解決方法,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2022-06-06
如何確定Oracle數(shù)據(jù)庫表重復(fù)的記錄
如何確定Oracle數(shù)據(jù)庫表重復(fù)的記錄...2007-03-03