【原創】模擬狀態為active的日誌損壞的資料恢復實驗（不完全恢復）
更多精彩內容盡在
首先我們先看看Active日誌特點
Active：表示日誌是活動的但不是當前正在使用的redolog，active意味著checkpoint動作尚未完成（髒資料還沒有完全刷到磁碟上）or 歸檔模式下該日誌的內容還沒有完全歸檔，這兩種情況下都會讓日誌為active狀態，在例項恢復時也會用到此日誌檔案，因此該日誌檔案不能被覆蓋。
Active和Currentredolog日誌有一個共同之處就是例項恢復時會用到這個日誌檔案 ，它們都是checkpoint檢查點還沒有完成時保護資料安全的最後屏障，如果它們損壞or勿刪除了會導致資料的丟失，這是非常危險的，就算有RMAN備份也不能恢復current 狀態的資料。
有的朋友會很奇怪不是說有全庫備份就可以完事大吉了嘛！這是一種完美主義，沒有一種四海皆准的備份，如果你在RMAN備份時候仔細檢視了備份日誌就會發現一個驚奇的秘密，RMAN是不會備份
Redolog的，但會備份archivelog，redolog是用多路複用方式映象備份的，因此如果刪除了current 重做日誌那麼就會丟失資料，我們要警惕這種場景，做一名優秀的DBA！
注：基本上，如果是當前線上日誌受損壞，很難不丟資料。但最差的情況下是可以恢復到上一個可用的歸檔日誌時間點的。
恢復方法：
A 使用映象檔案來恢復，不會丟失資料
B 隱含引數_allow_resetlogs_corruption=TRUE 進行不一致性恢復，會丟失資料
C RMAN不完全恢復，有全備，有歸檔，可以保證資料的一致性，會丟失資料
###################################################################################
A 使用映象檔案來恢復，不會丟失資料
SYS@LEO1>selectgroup#,members,bytes,archived,sequence#,status from v$log;
GROUP# MEMBERS BYTES ARC SEQUENCE# STATUS
-------------------- ---------- --- ---------- ----------------
1 2 52428800 YES 7 INACTIVE
2 2 52428800 NO 9 CURRENT
5 2 52428800 YES 8 INACTIVE
第二組為當前正在使用的redo組
[oracle@leonarding1LEO1]$ mv redo02.log redo02.log.bak 我們改個名字
SYS@LEO1>shutdownabort 我們強制關庫，按理說應該使用current log進行例項恢復，但current log備我們刪除了，連庫都起不來，如何恢復呢
SYS@LEO1>startup 啟動的時候是可以正常啟動的，但在告警日誌裡面會報錯
ORACLE instancestarted.
Total SystemGlobal Area 471830528 bytes
Fixed Size 2214456 bytes
Variable Size 171967944 bytes
DatabaseBuffers 289406976 bytes
Redo Buffers 8241152 bytes
Database mounted.
Database opened.
DDE:Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
ORA-00313:open failed for members of log group 2 of thread 1
ORA-00313:open failed for members of log group 2 of thread 1
我們很奇怪為什麼我們可以啟動呢？
SYS@LEO1>selectgroup#,member,status from v$logfile;
GROUP# MEMBER STATUS
------------------------------------------------------------ -------
1/u02/app/oracle/oradata/LEO1/redo01.log
2 /u02/app/oracle/oradata/LEO1/redo02.log INVALID
5 /u02/app/oracle/oradata/LEO1/redo05.log
1/u02/app/oracle/oradata/LEO1/disk2/redo01_b.log
2/u02/app/oracle/oradata/LEO1/disk2/redo02_b.log
5/u02/app/oracle/oradata/LEO1/disk2/redo05_b.log
哦原來第二組有2個成員互為映象如果第一個成員不可用時oracle就會標記為invalid，把redo資料寫入到redo02_b.log第二個成員中繼續支援oracle正常執行
SYS@LEO1>altersystem switch logfile;
System altered.
SYS@LEO1>selectgroup#,members,bytes,archived,sequence#,status from v$log;
GROUP# MEMBERS BYTES ARC SEQUENCE# STATUS
-------------------- ---------- --- ---------- ----------------
1 2 52428800 YES 16 INACTIVE
2 2 52428800 NO 18 CURRENT
5 2 52428800 YES 17 ACTIVE
看還可以正常切換，正常使用，但目前只有一個成員可用，也是非常危險的，我們要恢復原狀
SYS@LEO1>alterdatabase drop logfile member '/u02/app/oracle/oradata/LEO1/redo02.log';
Database altered.
SYS@LEO1>alterdatabase add logfile member '/u02/app/oracle/oradata/LEO1/redo02.log' to group2;
Database altered.
我們先刪除在建立，然後多切換幾次，redolog就恢復了
SYS@LEO1>altersystem switch logfile;
System altered.
SYS@LEO1>selectgroup#,member,status from v$logfile;
GROUP# MEMBER STATUS
------------------------------------------------------------ -------
1/u02/app/oracle/oradata/LEO1/redo01.log
2/u02/app/oracle/oradata/LEO1/redo02.log
5 /u02/app/oracle/oradata/LEO1/redo05.log
1/u02/app/oracle/oradata/LEO1/disk2/redo01_b.log
2/u02/app/oracle/oradata/LEO1/disk2/redo02_b.log
5/u02/app/oracle/oradata/LEO1/disk2/redo05_b.log
小結：使用映象檔案來恢復，不會丟失資料，因為沒有影響到oracle正常的執行
################################################################################
B 隱含引數_allow_resetlogs_corruption=true 進行不一致性恢復，會丟失資料
第二種方法，我把所有的current log全部改名，看看能否恢復
SYS@LEO1>shutdownabort 強制關庫
ORACLE instanceshut down.
[oracle@leonarding1LEO1]$ mv redo02.log redo02.log.bak 修改第一個成員
[oracle@leonarding1disk2]$ mv redo02_b.log redo02_b.log.bak 修改第二個成員
SYS@LEO1>startup 啟動庫
ORACLE instancestarted.
Total SystemGlobal Area 471830528 bytes
Fixed Size 2214456 bytes
Variable Size 171967944 bytes
DatabaseBuffers 289406976 bytes
Redo Buffers 8241152 bytes
Database mounted.
ORA-00313: openfailed for members of log group 2 of thread 1 開啟redo日誌失敗
ORA-00312: onlinelog 2 thread 1: '/u02/app/oracle/oradata/LEO1/redo02.log' 指明哪個日誌
ORA-27037: unableto obtain file status 獲取不到日誌狀態
Linux-x86_64Error: 2: No such file or directory 因為沒有這個檔案
Additional information:3
ORA-00312: onlinelog 2 thread 1:
'/u02/app/oracle/oradata/LEO1/disk2/redo02_b.log' 第一個成員找不到我們看看第二個成員有沒有
ORA-27037: unableto obtain file status
Linux-x86_64Error: 2: No such file or directory 也是沒有這個檔案對吧
Additionalinformation: 3
SYS@LEO1>selectstatus from v$instance; 現在例項正在處於mount狀態
STATUS
------------
MOUNTED
我們可以使用隱含引數_allow_resetlogs_corruption=true 進行不一致恢復，這是oracle給予我們提供的一種臨時急救方法，一般不到萬不得已不建議使用，因為這樣會丟失資料的，而丟失資料是不能接受的。我們繼續
SYS@LEO1>altersystem set "_allow_resetlogs_corruption"=true scope=spfile; 靜態修改需重啟生效
System altered.
SYS@LEO1>shutdownimmediate
ORA-01109:database not open
Databasedismounted.
ORACLE instanceshut down.
SYS@LEO1>startupmount 啟動到mount狀態
ORACLE instancestarted.
Total SystemGlobal Area 471830528 bytes
Fixed Size 2214456 bytes
Variable Size 171967944 bytes
DatabaseBuffers 289406976 bytes
Redo Buffers 8241152 bytes
Database mounted.
SYS@LEO1>recoverdatabase until cancel;
until cancel：一直恢復到資料庫能夠恢復的最後一個日誌，盡最大努力恢復
場景：current/active log有丟失情況下或者有歸檔日誌丟失的情況下，一直可恢復到丟失前的最後一個日誌，則中止。
SYS@LEO1>recoverdatabase until cancel;
ORA-00279: change1056653 generated at 04/30/2013 08:35:09 needed for thread 1
ORA-00289:suggestion : /u02/app/oracle/archdata/1_19_813790699.dbf
ORA-00280: change1056653 for thread 1 is in sequence #19
Specify log:{
cancel 這時需手工輸入cancel
ORA-10879: errorsignaled in parallel recovery slave
ORA-01547:warning: RECOVER succeeded but OPEN RESETLOGS wouldget error below
ORA-01194: file 1needs more recovery to be consistent
ORA-01110: datafile 1: '/u02/app/oracle/oradata/LEO1/system01.dbf'
需要resetlogs方式開打資料庫，也就是非一致性開啟
Resetlogs做的幾件事：
1）資料檔案頭scn號為準，同步控制檔案和線上日誌檔案scn號
2）重新建立redolog日誌（建立一個空日誌），重置為unused
3）重置歸檔日誌序號從1開始編碼
-rw-r----- 1oracle asmadmin 222720 Apr 26 21:051_1_813790699.dbf
-rw-r----- 1oracle asmadmin 7168 Apr 30 10:25 1_1_814098124.dbf
4）讓資料庫重新進入一個新的生命週期
SYS@LEO1>alterdatabase open resetlogs;
alter databaseopen resetlogs
*
ERROR at line 1:
ORA-00603: ORACLEserver session terminated by fatal error 當前會話被終止
ORA-00600:internal error code, arguments: [2662], [0], [1056672], [0],
[1056735],[12583120], [], [], [], [], [], []
ORA-00600:internal error code, arguments: [2662], [0], [1056671], [0],
[1056735],[12583120], [], [], [], [], [], []
ORA-01092: ORACLEinstance terminated. Disconnection forced
ORA-00600:internal error code, arguments: [2662], [0], [1056668], [0],
[1056735],[12583120], [], [], [], [], [], []
Process ID: 9651
Session ID: 125Serial number: 5
SYS@LEO1>startup
ORACLE instancestarted.
Total SystemGlobal Area 471830528 bytes
Fixed Size 2214456 bytes
Variable Size 171967944 bytes
DatabaseBuffers 289406976 bytes
Redo Buffers 8241152 bytes
Database mounted.
Database opened.
SYS@LEO1>selectstatus from v$instance;
STATUS
------------
OPEN
SYS@LEO1>colmember for a50
SYS@LEO1>selectgroup#,member,status from v$logfile;
GROUP# MEMBER STATUS
------------------------------------------------------------ -------
1/u02/app/oracle/oradata/LEO1/disk2/redo01_b.log
2/u02/app/oracle/oradata/LEO1/disk2/redo02_b.log
5/u02/app/oracle/oradata/LEO1/redo05.log
1 /u02/app/oracle/oradata/LEO1/redo01.log
2 /u02/app/oracle/oradata/LEO1/redo02.log
5 /u02/app/oracle/oradata/LEO1/disk2/redo05_b.log
6 rows selected.
SYS@LEO1>selectgroup#,members,bytes,archived,sequence#,status from v$log;
GROUP# MEMBERS BYTES ARC SEQUENCE# STATUS
-------------------- ---------- --- ---------- ----------------
1 2 52428800 YES 1 INACTIVE
2 2 52428800 NO 2 CURRENT
5 2 52428800 YES 0 UNUSED
小結：這種方式開啟後的資料庫要立刻全備一次，之前的備份已經無效，保證資料的安全性
C RMAN不完全恢復，有全備，有歸檔，可以保證資料的一致性，會丟失資料，這種方法我們在下面的實驗中證明
2013.4.30
天津&spring
分享技術~成就夢想
Blog：
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26686207/viewspace-759603/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 資料底層損壞的恢復方法—拼碎片恢復資料
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- 資料恢復工具Recoverit使用教程:如何修復損壞的影片資料恢復
- 資料庫資料恢復—NTFS分割槽損壞如何恢復SqlServer資料庫資料資料庫資料恢復SQLServer
- 【伺服器資料恢復】斷電導致ProLiant伺服器RAID模組損壞的資料恢復案例伺服器資料恢復AI
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- MySQL重做日誌恢復資料的流程MySql
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料
- 【vSAN資料恢復案例】異常斷電導致vSAN底層資料損壞的資料恢復資料恢復
- 隨身碟顆粒損壞資料恢復資料恢復
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 資料庫資料恢復-SQL SERVER資料庫MDF (NDF)或LDF損壞如何恢復資料？資料庫資料恢復SQLServer
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫
- 利用binlog日誌恢復mysql資料MySql
- Oracle資料庫不同損壞級別的恢復詳解Oracle資料庫
- 【北亞資料恢復】誤操作分割槽損壞導致SqlServer資料庫資料丟失的資料恢復資料恢復SQLServer資料庫
- 【北亞資料恢復】硬碟壞道故障如何恢復資料？資料恢復硬碟
- 如何恢復SSD NVME固態硬碟的資料恢復硬碟資料恢復
- 【虛擬機器資料恢復】EXSI虛擬機器誤還原快照的資料恢復案例虛擬機資料恢復
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 【虛擬機器資料恢復】ESXI虛擬機器被誤還原快照的資料恢復案例虛擬機資料恢復
- 電腦進水導致硬碟損壞資料恢復硬碟資料恢復
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- Oracle asm磁碟損壞異常恢復OracleASM
- Oracle Database 12c RAC損壞ocr和votedisk恢復實驗OracleDatabase
- 資料恢復記錄：硬碟分割槽損壞修復SqlServer資料庫過程資料恢復硬碟SQLServer資料庫
- 如何恢復行動硬碟損壞的資料？先找原因後解決硬碟
- sqlsever處理資料庫的恢復掛起狀態SQL資料庫
- 【伺服器資料恢復】EqualLogic儲存磁碟出現壞道的資料恢復案例伺服器資料恢復
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫
- PostgreSQL 恢復大法 - 恢復部分資料庫、跳過壞塊、修復無法啟動的資料庫SQL資料庫
- Oracle 不完全恢復Oracle
- 【北亞資料恢復】異常斷電導致linux伺服器無法啟動，資料庫損壞的資料恢復資料恢復Linux伺服器資料庫
- 資料恢復：AMDU資料抽取恢復資料恢復
- 伺服器資料恢復-VMwave虛擬化資料恢復案例伺服器資料恢復
- 【虛擬機器資料恢復】FreeNAS+ESXi資料恢復案例虛擬機資料恢復
- 【虛擬機器資料恢復】VMware ESX SERVER資料恢復案例虛擬機資料恢復Server
- 杭州資料恢復之雜牌U優盤損壞電腦不識別拆解晶片怎麼恢復資料資料恢復晶片