在上篇中，我們進行了環境準備。（http://blog.itpub.net/17203031/viewspace-2126665/）下面就可以進行問題修復動作。

3、故障修復

總體修復的思路是：使用BBED，將檔案頭的SCN等關鍵資訊修改到與控制檔案control file相匹配即可。

當前，控制檔案各個檔案SCN相同，而資料檔案上SCN不同。

--控制檔案上資訊

SQL> select file#, CHECKPOINT_CHANGE# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

1 1714543

2 1714543

3 1714543

4 1714543

5 1714543

6 1714543

7 1714543

7 rows selected

SQL> select CHECKPOINT_CHANGE# from v$database;

CHECKPOINT_CHANGE#

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

1714543

--資料檔案頭資訊

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

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

1 NO NO 1714543

2 NO NO 1714543

3 NO NO 1714543

4 NO NO 1714543

5 NO NO 1714543

6 NO NO 1714543

7 YES YES 1713752

7 rows selected

一種最簡單的策略，是將File 7對應的SCN修改為其他檔案相同。首先，我們可以先使用BBED看一下那些正確檔案的內容是什麼。

[oracle@TESTlife datafile]$ bbed

Password:

BBED: Release 2.0.0.0.0 - Limited Production on Tue Oct 18 22:33:26 2016

************* !!! For Oracle Internal Use only !!! ***************

BBED> set filename '/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf' –一號檔案

FILENAME /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf

BBED> set block 1

BLOCK# 1

BBED> map

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

Block: 1 Dba:0x00000000

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

Data File Header

struct kcvfh, 860 bytes @0

ub4 tailchk @8188

針對這個案例，我們通常需要關注四個偏移量offset點，分別為484、492、140和148。

BBED> p kcvfh

struct kcvfh, 860 bytes @0

struct kcvfhbfh, 20 bytes @0

ub1 type_kcbh @0 0x0b

（篇幅原因，有省略……）

ub2 kcvfhbth @136 0x0000

ub2 kcvfhsta @138 0x2000 (NONE)

struct kcvfhckp, 36 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas @484 0x001a296f --SCN：1714543與檔案一致

ub2 kscnwrp @488 0x0000

ub4 kcvcptim @492 0x372b7d00 --最後一次Check Point Time

ub2 kcvcpthr @496 0x0001

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x00000043

ub4 kcrbabno @504 0x0000005b

ub2 kcrbabof @508 0x0010

ub1 kcvcpetb[0] @512 0x02

ub1 kcvcpetb[1] @513 0x00

ub1 kcvcpetb[2] @514 0x00

ub1 kcvcpetb[3] @515 0x00

ub1 kcvcpetb[4] @516 0x00

ub1 kcvcpetb[5] @517 0x00

ub1 kcvcpetb[6] @518 0x00

ub1 kcvcpetb[7] @519 0x00

ub4 kcvfhcpc @140 0x000000c8 --Check Point Count

ub4 kcvfhrts @144 0x372b5d94

ub4 kcvfhccc @148 0x000000c7 --比檢查點計數少1

struct kcvfhbcp, 36 bytes @152

struct kcvcpscn, 8 bytes @152

ub4 kscnbas @152 0x00000000

ub2 kscnwrp @156 0x0000

ub4 kcvcptim @160 0x00000000

（篇幅原因，有省略……）

其中，位於484和488偏移量的是資料檔案對應的SCN編號。在Oracle內部，SCN是使用wrap*4*1024*1024*1024+base來進行標示的。通常我們看到的資料庫wrap都是0。位於492偏移量的是最後一次檢查點對應的時間資訊。位於140和148偏移量的是檢查點次數。這些資訊都是會由於時間推動和檢查點動作引起變化，我們嚴格情況下，需要保證檔案頭塊的資訊和控制檔案資訊一致。

另外一點，由於Linux是Little位元組系統，要關注寫入時候的格式問題。最簡單的方式是dump一下偏移量，看看是怎麼儲存的。

BBED> set offset 484

OFFSET 484

（0x001a296f）

BBED> dump

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

Block: 1 Offsets: 484 to 995 Dba:0x00000000

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

6f291a00 00000000 007d2b37 01000000 43000000 5b000000 10009e33 02000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

BBED> set offset 492

OFFSET 492

（0x372b7d00）

BBED> dump

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

Block: 1 Offsets: 492 to 1003 Dba:0x00000000

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

007d2b37 01000000 43000000 5b000000 10009e33 02000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 0d000d00 0d000100

BBED> set offset 140

OFFSET 140

（0x000000c8）

BBED> dump

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

Block: 1 Offsets: 140 to 651 Dba:0x00000000

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

c8000000 945d2b37 c7000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

BBED> set offset 144

OFFSET 144

（0x000000c7)

BBED> dump

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

Block: 1 Offsets: 144 to 655 Dba:0x00000000

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

945d2b37 c7000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

實施修改檔案塊動作：

BBED> set filename '/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf'

FILENAME /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

BBED> set block 1

BLOCK# 1

BBED> set mode edit

MODE Edit

修改對應檔案塊的位數。

BBED> m /x 6f291a00 offset 484

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf (0)

Block: 1 Offsets: 484 to 995 Dba:0x00000000

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

6f291a00 00000000 79792b37 01005e7d 3c000000 02000000 10000000 02000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

BBED> m /x 007d2b37 offset 492

File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf (0)

Block: 1 Offsets: 492 to 1003 Dba:0x00000000

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

007d2b37 01005e7d 3c000000 02000000 10000000 02000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

注意：Oracle資料塊中使用冗餘校驗功能，修改資料塊之後，要使用sum apply重新計算校驗位。

BBED> sum apply

Check value for File 0, Block 1:

current = 0xc606, required = 0xc606

BBED> verify

DBVERIFY - Verification starting

FILE = /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

BLOCK = 1

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 : 0

Total Blocks Influx : 0

Message 531 not found; product=RDBMS; facility=BBED

此時在mount狀態的資料庫中看一下，可以發現檔案SCN已經發生變化。

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

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

1 NO NO 1714543

2 NO NO 1714543

3 NO NO 1714543

4 NO NO 1714543

5 NO NO 1714543

6 NO NO 1714543

7 YES YES 1714543

7 rows selected

啟動資料庫，嘗試open。

[oracle@TESTlife datafile]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 18 23:02:18 2016

SQL> conn / as sysdba

Connected.

SQL> select open_mode from v$database;

OPEN_MODE

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

MOUNTED

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7:

'/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf'

使用recover命令進行還原，此時需要的online redo log就可以支援了。

SQL> recover datafile 7;

Media recovery complete.

SQL> alter database open;

Database altered

啟動過程的alert log資訊：

Tue Oct 18 23:02:35 2016

alter database open

Errors in file /u01/app/oracle/diag/rdbms/TESTdb/TESTdb/trace/TESTdb_ora_16545.trc:

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7: '/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf'

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

Tue Oct 18 23:02:49 2016

ALTER DATABASE RECOVER datafile 7

Media Recovery Start

Serial Media Recovery started

WARNING! Recovering data file 7 from a fuzzy backup. It might be an online

backup taken without entering the begin backup command.

Media Recovery Complete (TESTdb)

Completed: ALTER DATABASE RECOVER datafile 7

alter database open

Oracle在recover的時候發現有一些問題，但是還是讓透過了。此時，資料整體正常。

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

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

（篇幅原因，有省略……）

5 NO YES 1714546

6 NO YES 1714546

7 NO YES 1714546

7 rows selected

4、結論

Oracle啟動Open是一個極其複雜的過程。單獨透過open過程，我們就可以學習到很多的知識和技能。在解決故障的時候，應用多種途徑，找到最適當的策略，是我們需要掌握的工作手段。

使用BBED修改檔案頭解決資料庫Open驗證問題（下）

相關文章