一個朋友11.2.0.1的數據庫因為斷電,出現不能正常open問題,自己嘗試恢復,折騰了幾天,最后讓我幫忙的時候錯誤如下

SQL> startup

ORACLE 例程已經啟動。

Total System Global Area 778387456 bytes

Fixed Size 1374808 bytes

Variable Size 545260968 bytes

Database Buffers 226492416 bytes

Redo Buffers 5259264 bytes

數據庫裝載完畢。

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00604: error occurred at recursive SQL level 1

ORA-01578: ORACLE data block corrupted (file # 1, block # 225)

ORA-01110: data file 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

進程 ID: 5964

會話 ID: 1144 序列號: 5

從啟動的日志提示看初步判斷就是悲劇了,因為根據經驗值在11gr2版本中,該錯誤就是undo$(分析trace文件進步一確定是undo$),該block出現異常,數據庫在啟動的時候要掃描該表，把相關的回滾段給online起來,現在他異常了,數據庫肯定無法正常啟動

dbv檢查數據庫文件

F:\>dbv file='F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

DBVERIFY: Release 11.2.0.1.0 - Production on 星期三 5月 22 11:06:00 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

DBVERIFY - 開始驗證: FILE = F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF

頁 225 流入 - 很可能是介質損壞

Corrupt block relative dba: 0x004000e1 (file 1, block 225)

Fractured block found during dbv:

Data in bad block:

type: 6 format: 2 rdba: 0x004000e1

last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0xb98e0601

check value in block header: 0xb307

computed block checksum: 0xe8ae

DBVERIFY - 驗證完成

檢查的頁總數: 134400

處理的頁總數 (數據): 98226

失敗的頁總數 (數據): 0

處理的頁總數 (索引): 14189

失敗的頁總數 (索引): 0

處理的頁總數 (其他): 4178

處理的總頁數 (段) : 1

失敗的總頁數 (段) : 0

空的頁總數: 17806

標記為損壞的總頁數: 1

流入的頁總數: 1

加密的總頁數 : 0

最高塊 SCN : 14045769 (0.14045769)

看到這里,可以確定壞塊的存在，根據上面的提示,我們發現tailchk值不正確,應該是5120+06+01,而不該是b98e0601,通過bbed查看

BBED> p kcbh

struct kcbh, 20 bytes @0

ub1 type_kcbh @0 0x06

ub1 frmt_kcbh @1 0xa2

ub1 spare1_kcbh @2 0x00

ub1 spare2_kcbh @3 0x00

ub4 rdba_kcbh @4 0x004000e1

ub4 bas_kcbh @8 0x00d65120

ub2 wrp_kcbh @12 0x0000

ub1 seq_kcbh @14 0x01

ub1 flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV)

ub2 chkval_kcbh @16 0x5ba9

ub2 spare3_kcbh @18 0x0000

BBED> p tailchk

ub4 tailchk @8188 0xb98e0601

進一步證明是tailchk異常導致,分析alert日志,數據庫異常斷電,然后啟動的時候發現如下錯誤

Recovery of Online Redo Log: Thread 1 Group 2 Seq 431 Reading mem 0

Mem# 0: F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\REDO02.LOG

RECOVERY OF THREAD 1 STUCK AT BLOCK 451 OF FILE 3

Aborting crash recovery due to error 1172

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc:

ORA-01172: 線程 1 的恢復停止在塊 451 (在文件 3 中)

ORA-01151: 如果需要, 請使用介質恢復以恢復塊和還原備份

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc:

ORA-01172: 線程 1 的恢復停止在塊 451 (在文件 3 中)

ORA-01151: 如果需要, 請使用介質恢復以恢復塊和還原備份

ORA-1172 signalled during: alter database open...

Tue May 21 14:27:29 2013

ALTER DATABASE RECOVER datafile 3

Media Recovery Start

Serial Media Recovery started

Recovery of Online Redo Log: Thread 1 Group 2 Seq 431 Reading mem 0

Mem# 0: F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\REDO02.LOG

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_772.trc (incident=112164):

ORA-00600: 內部錯誤代碼, 參數: [3020], [3], [451], [12583363], [], [], [], [], [], [], [], []

ORA-10567: Redo is inconsistent with data block (file# 3, block# 451, file offset is 3694592 bytes)

ORA-10564: tablespace UNDOTBS1

ORA-01110: 數據文件 3: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\UNDOTBS01.DBF'

ORA-10560: block type 'KTU UNDO BLOCK'

Media Recovery failed with error 600

ORA-283 signalled during: ALTER DATABASE RECOVER datafile 3 ...

因為file# 3, block# 451和redo信息不一致,出現ora-600[3020]錯誤,而file# 3為undo文件,朋友從而設置undo_management=’manual’并設置了_allow_resetlogs_corruption=true,然后進行不完全恢復,從而出現了如下錯誤提示

Tue May 21 14:41:23 2013

SMON: enabling cache recovery

Corrupt block relative dba: 0x004000e1 (file 1, block 225)

Fractured block found during buffer read

Data in bad block:

type: 6 format: 2 rdba: 0x004000e1

last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0xb98e0601

check value in block header: 0xb307

computed block checksum: 0xe8ae

Reading datafile 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

for corruption at rdba: 0x004000e1 (file 1, block 225)

Reread (file 1, block 225) found same corrupt data

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc (incident=120165):

ORA-01578: ORACLE 數據塊損壞 (文件號 1, 塊號 225)

ORA-01110: 數據文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc:

ORA-00604: 遞歸 SQL 級別 1 出現錯誤

ORA-01578: ORACLE 數據塊損壞 (文件號 1, 塊號 225)

ORA-01110: 數據文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

Errors in file f:\app\administrator\diag\rdbms\yfcloud\yfcloud\trace\yfcloud_ora_4892.trc:

ORA-00604: 遞歸 SQL 級別 1 出現錯誤

ORA-01578: ORACLE 數據塊損壞 (文件號 1, 塊號 225)

ORA-01110: 數據文件 1: 'F:\APP\ADMINISTRATOR\ORADATA\YFCLOUD\SYSTEM01.DBF'

Error 604 happened during db open, shutting down database

USER (ospid: 4892): terminating the instance due to error 604

從而的原因基本上可以從操作過程中了解到:數據庫是因為file# 3 block# 451和redo不一致導致問題,而恢復的操作人員沖動的使用了_allow_resetlogs_corruption參數,從而使得數據庫出現了不一致性,也就是導致file# 1 block# 225壞塊的根本原因,針對這樣的情況,完全沒有到使用_allow_resetlogs_corruption隱含參數地步

使用bbed修改tailchk

BBED> p tailchk

ub4 tailchk @8188 0xb98e0601

BBED> verify

DBVERIFY - Verification starting

FILE = system01.dbf

BLOCK = 225

Block 225 is corrupt

***

Corrupt block relative dba: 0x004000e1 (file 0, block 225)

Fractured block found during verification

Data in bad block -

type: 6 format: 2 rdba: 0x004000e1

last change scn: 0x0000.00d65120 seq: 0x1 flg: 0x06

consistency value in tail: 0xb98e0601

check value in block header: 0x5ba9, computed block checksum: 0x0

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

DBVERIFY - Verification complete

Total Blocks Examined : 1

Total Blocks Processed (Data) : 0

Total Blocks Failing (Data) : 0

Total Blocks Processed (Index): 0

Total Blocks Failing (Index): 0

Total Blocks Empty : 0

Total Blocks Marked Corrupt : 1

Total Blocks Influx : 2

BBED> m /x 01062051

File: system01.dbf (0)

Block: 226 Offsets: 8188 to 8191 Dba:0x00000000

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

01062051

<32 bytes per line>

BBED> p tailchk

ub4 tailchk @8188 0x51200601

BBED> sum apply

Check value for File 0, Block 226:

current = 0xb307, required = 0xb307

BBED> verify

DBVERIFY - Verification starting

FILE = system01.dbf

BLOCK = 225

DBVERIFY - Verification complete

Total Blocks Examined : 1

Total Blocks Processed (Data) : 1

Total Blocks Failing (Data) : 0

Total Blocks Processed (Index): 0

Total Blocks Failing (Index): 0

Total Blocks Empty : 0

Total Blocks Marked Corrupt : 0

Total Blocks Influx : 0

bbed修改block之后,數據庫直接正常打開,完成數據庫恢復任務,在這里很明顯是因為錯誤的使用了_allow_resetlogs_corruption參數,屏蔽了redo前滾導致了相關的壞塊,所以大家在數據庫異常恢復的時候,需要知道各個參數的意義,而不要亂使用,很可能導致不可控結果

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的oracle 执行sql参数混乱,乱用_allow_resetlogs_corruption参数导致悲剧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。