Online Redo Log損壞處理實驗(下)

路途中的人2012發表於2017-11-30

最後我們一起來看一下非一致性關閉條件下當前日誌組刪除的處理。 

 

 

6、非一致性關閉當前日誌組處理

 

我們回到10g Windows版本進行實驗。

 

 

 

SQL> select group#, archived, status, first_change#,sequence# from v$log;

 

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#  SEQUENCE#

---------- -------- ---------------- ------------- ----------

         1 NO       CURRENT                 605509          8

         2 YES      ACTIVE                  604411          7

         3 YES      INACTIVE                604371          6

 

SQL> shutdown abort;

ORACLE 例程已經關閉。

SQL>

 

 

E:\oracle\product\10.2.0\oradata\orcl>rename REDO01B.LOG REDO01B.LOG_bak

E:\oracle\product\10.2.0\oradata\orcl>rename REDO01A.LOG REDO01A.LOG_bak

 

 

SQL> startup

ORACLE 例程已經啟動。

 

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

資料庫裝載完畢。

ORA-00313: 無法開啟日誌組 1 (用於執行緒 1) 的成員

ORA-00312: 聯機日誌 1 執行緒 1:

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_1_85TNYSWS_.L

OG'

ORA-27041: 無法開啟檔案

OSD-04002: ??????

O/S-Error: (OS 2) ???????????????

ORA-00312: 聯機日誌 1 執行緒 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_85TNYS8S_.LOG'

ORA-27041: 無法開啟檔案

OSD-04002: ??????

O/S-Error: (OS 2) ???????????????

 

 

 

之後,使用常規方法很難開啟資料庫。

 

 

SQL> recover database until cancel;

ORA-00279: 更改 605036 ( 09/23/2012 09:01:03 生成) 對於執行緒 1 是必需的

ORA-00289: 建議:

E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1_

7_%U_.ARC

ORA-00280: 更改 605036 (用於執行緒 1) 在序列 #7

 

 

指定日誌: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: 更改 605509 ( 09/23/2012 09:02:53 生成) 對於執行緒 1 是必需的

ORA-00289: 建議:

E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1_

8_%U_.ARC

ORA-00280: 更改 605509 (用於執行緒 1) 在序列 #8

ORA-00278: 此恢復不再需要日誌檔案

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1

_7_85WQXX8S_.ARC'

 

 

ORA-00308: 無法開啟歸檔日誌

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1

_8_%U_.ARC'

ORA-27041: 無法開啟檔案

OSD-04002: ??????

O/S-Error: (OS 2) ???????????????

 

 

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 將出現如下錯誤

ORA-01194: 檔案 1 需要更多的恢復來保持一致性

ORA-01110: 資料檔案 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_SYSTEM_85TSQFJM_.DBF'

 

 

SQL> alter database open resetlogs;

alter database open resetlogs

*

1 行出現錯誤:

ORA-01194: 檔案 1 需要更多的恢復來保持一致性

ORA-01110: 資料檔案 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_SYSTEM_85TSQFJM_.DBF'

 

 

 

在處理這個問題上,處理上節介紹的備份還原的手段,我們沒有太多很好的選擇。但是,如果沒有備份的時候,我們就需要進行冒險操作。

 

之所以我們無法從mount進入open狀態,主要是源於無法透過檔案頭完整性檢驗步驟。在Oracle中,我們可以利用一些後門來讓Oracle不進行檢查,透過open階段。下面我們就需要在引數中新增這些配置。

 

 

SQL> shutdown abort;

ORACLE 例程已經關閉。

SQL> startup nomount;

ORACLE 例程已經啟動。

 

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

SQL>

 

--生成PFILE

SQL> create pfile='d:\pfile.ora' from spfile;

 

檔案已建立。

 

 

隱含引數_allow_resetlogs_corruption可以讓我們避開一致性檢查。在pfile中加入引數行。

 

 

(引數檔案內容)

_allow_resetlogs_corruption=TRUE

orcl.__db_cache_size=377487360

orcl.__java_pool_size=4194304

orcl.__large_pool_size=4194304

orcl.__shared_pool_size=209715200

orcl.__streams_pool_size=0

 

 

之後,嘗試開啟資料庫。

 

 

SQL> shutdown abort

ORACLE 例程已經關閉。

SQL> startup pfile='d:\pfile.ora';

ORACLE 例程已經啟動。

 

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

資料庫裝載完畢。

ORA-01589: 要開啟資料庫則必須使用 RESETLOGS NORESETLOGS 選項

 

 

SQL> alter database open resetlogs;

 

資料庫已更改。

 

SQL> conn sys/oracle@orcl as sysdba

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

 

SQL> select group#, archived, status, first_change#,sequence# from v$log;

 

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#  SEQUENCE#

---------- -------- ---------------- ------------- ----------

         1 NO       CURRENT                 605510          1

         2 YES      UNUSED                       0          0

         3 YES      UNUSED                       0          0

 

 

注意:這種方法是有很多的問題的。加入引數可以讓我們繞開一致性驗證,但是很多場景下,特別是檔案損壞的場景下,啟動可能還會遇到其他錯誤資訊。一旦我們開啟資料庫,要明白這個庫是處在危險之中,我們能做的就是將重要資料儘快的備份出來。

 

7、結論

 

我們本系列中,一直在討論Online Redo Log的損壞情況。一般來說,對Online Redo Log和控制檔案,我們都採用多路徑儲存的方法,安全係數是比較高的。DBA和運維人員只要不發生人為故障,這兩類檔案損壞的情況是很少出現的。

 

最後,筆者想強調一下備份的重要意義。無論發生何種型別的錯誤,可用、完整的備份都是我們的救命草。要制定完備的備份策略,經常性的檢查備份有效性,防患於未燃。

 

 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29067253/viewspace-2148095/,如需轉載,請註明出處,否則將追究法律責任。

相關文章