Oracle數(shù)據庫恢復教程之resetlogs操作的示例分析
這篇文章給大家分享的是有關Oracle數(shù)據庫恢復教程之resetlogs操作的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
成都創(chuàng)新互聯(lián)專注于企業(yè)全網整合營銷推廣、網站重做改版、太谷網站定制設計、自適應品牌網站建設、H5網站設計、購物商城網站建設、集團公司官網建設、成都外貿網站制作、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為太谷等各大城市提供網站開發(fā)制作服務。
實驗環(huán)境：RHEL 5.4 + Oracle 11.2.0.3
如果是一名合格的Oracle DBA，對resetlogs這種關鍵字都應該是極其敏感的，當確認需要這種操作時一定要三思而后行，如果自己不是特別確認，哪怕多花些時間申請去讓高級DBA人員協(xié)助你一起確認，也不要擅自去嘗試執(zhí)行，避免誤操作造成既定損失后追悔莫及。
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小伙伴們在實際工作中遇到這樣的場景時卻總是有些困惑，甚至誤操作引發(fā)災難。
我這里以一個實驗來具體說明常見場景：
需求：A機數(shù)據庫PROD1，現(xiàn)需在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機做了一次數(shù)據庫備份： 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/arch2_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/arch2_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ù)據庫的日志前后都自動歸檔了當前的redolog（57和58），所以備份完成后，當前日志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ù)紹機，比如/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"
--嘗試恢復數(shù)據庫：
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/arch2_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 先查看控制文件和數(shù)據文件頭記錄的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 重點來了，現(xiàn)在可以open resetlogs嗎？
當然不行！記得一定要確認好路徑??！
--查詢發(fā)現(xiàn)臨時文件以及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.
感謝各位的閱讀！關于“Oracle數(shù)據庫恢復教程之resetlogs操作的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
網站標題：Oracle數(shù)據庫恢復教程之resetlogs操作的示例分析
本文路徑：http://muchs.cn/article46/picoeg.html
成都網站建設公司_創(chuàng)新互聯(lián)，為您提供移動網站建設、企業(yè)建站、網站設計、電子商務、品牌網站設計、做網站
聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)
- 堅持執(zhí)行seo優(yōu)化流程，網站排名會持續(xù)穩(wěn)定 2023-04-03
- 簡單說說網站排名綜合評估與友情鏈接 2021-07-28
- 定期更新文章對網站排名的作用 2022-05-30
- 網站優(yōu)化時如何保持網站排名的穩(wěn)定性 2022-12-09
- SEO優(yōu)化網站排名下降的原因有哪些？ 2013-06-30
- 聊城網站排名在smatr原則的指導下，擬定可行性sep優(yōu)化方針 2023-01-06
- 網站排名不穩(wěn)定的4個主要原因 2017-02-11
- 網站排名推廣有利于企業(yè)獲取更多的用戶 2020-10-26
- 網站基礎結構決定網站排名 2015-12-18
- SEO怎么優(yōu)化，網站排名怎么快速提升? 2023-01-01
- 網站排名優(yōu)化工作每天都做什么呢？ 2016-12-15
- 用戶需求是網站排名的基礎 2021-02-27