使用FLASHCOPY+資料庫歸檔日誌檔案進行資料庫不完整恢復技術實施方案(2 /2)

djb1008發表於2011-05-19
資料庫

1.1.10 在主機上識別8000－8100等LUN,匯入VG,設定lv的訪問許可權

#cfgmgr –v

# datapath query device

Total Devices : 6

DEV#: 0 DEVICE NAME: vpath0 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8000

DEV#: 1 DEVICE NAME: vpath1 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8001

DEV#: 2 DEVICE NAME: vpath2 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8002

DEV#: 3 DEVICE NAME: vpath3 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8100

DEV#: 4 DEVICE NAME: vpath4 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8101

DEV#: 5 DEVICE NAME: vpath5 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8102

[@more@]

#lspv

hdisk0 00c87badb8db2ba6 rootvg active

hdisk1 00c87bad75ee70a9 rootvg active

hdisk2 none None

。。。。。。

hdisk49 none None

vpath0 00c87badd701de12 None

vpath1 00c87badd701dff1 None

vpath2 00c87badd701e1a2 None

vpath3 00c87badd701e362 None

vpath4 00c87badd701e514 None

vpath5 00c87badd701e6de None

注意flashcopy 的目標盤與源盤的PVID是相同的，所以最好不要同時將源盤和目標盤都賦予主機訪問。

# importvg -y testvg vpath0

testvg

# chown oracle:dba /dev/rora*

# chmod 755 /dev/rora*

# lsvg -l testvg

testvg:

LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT

ora_system raw 6 6 6 closed/syncd N/A

ora_sysaux raw 6 6 6 closed/syncd N/A

ora_data01 raw 30 30 6 closed/syncd N/A

ora_data02 raw 30 30 6 closed/syncd N/A

ora_data03 raw 30 30 6 closed/syncd N/A

ora_index01 raw 30 30 6 closed/syncd N/A

ora_index02 raw 30 30 6 closed/syncd N/A

ora_redo01 raw 6 6 6 closed/syncd N/A

ora_redo02 raw 6 6 6 closed/syncd N/A

ora_redo03 raw 6 6 6 closed/syncd N/A

ora_control02 raw 6 6 6 closed/syncd N/A

ora_control03 raw 6 6 6 closed/syncd N/A

ora_control01 raw 6 6 6 closed/syncd N/A

ora_temp01 raw 30 30 6 closed/syncd N/A

ora_undotbs01 raw 30 30 6 closed/syncd N/A

1.1.11 進行資料庫恢復操作

1.1.11.1 啟動資料庫到mount狀態(注意千萬不要啟動到open狀態)

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 2101912 bytes

Variable Size 545262952 bytes

Database Buffers 524288000 bytes

Redo Buffers 2088960 bytes

Database mounted.

生成的Flashcopy目標盤相當於資料庫的冷備份，使用flashcopy目標盤啟動資料庫到mount狀態，應該沒有任何問題。

啟動到mount狀態而不是open狀態,是為了不更改資料檔案的SCN。(曾經嘗試啟動資料庫到open狀態,然後進行後面的恢復,結果失敗,分析一下原因,發現問題出在了啟動資料庫後,很多資料庫檔案的SCN發生了變化,導致與歸檔日誌裡的記錄不吻合,從而導致恢復失敗)

1.1.11.2 建立生成controlfile的trace檔案,編輯建立控制檔案的指令碼

SQL> alter database backup controlfile to trace;

Database altered.

開啟$ORACLE_BASE/admin/udump/目錄下最新的trace檔案,找出該檔案中建立controlfile檔案的指令碼(注意選擇resetlogs那一節的指令碼).

$cd /oracle/admin/test1/udump

$more test1_ora_5570654.trc

……

CREATE CONTROLFILE REUSE DATABASE "TEST1" RESETLOGS ARCHIVELOG

MAXLOGFILES 30

MAXLOGMEMBERS 5

MAXDATAFILES 200

MAXINSTANCES 2

MAXLOGHISTORY 292

LOGFILE

GROUP 1 '/dev/rora_redo01' SIZE 256M,

GROUP 2 '/dev/rora_redo02' SIZE 256M,

GROUP 3 '/dev/rora_redo03' SIZE 256M

-- STANDBY LOGFILE

DATAFILE

'/dev/rora_system',

'/dev/rora_undotbs01',

'/dev/rora_sysaux',

'/dev/rora_data01',

'/dev/rora_data02',

'/dev/rora_index01',

'/dev/rora_index02'

CHARACTER SET ZHS16GBK

;

該trace檔案中有兩個地方存在建立controlfile的指令碼，分別為noresetlogs和resetlogs，我們這裡應該選擇resetlogs的那段，如上所示。

1.1.11.3 關閉資料庫

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

1.1.11.4 啟動資料庫到nomount狀態,建立新的控制檔案

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 2101912 bytes

Variable Size 545262952 bytes

Database Buffers 524288000 bytes

Redo Buffers 2088960 bytes

SQL> CREATE CONTROLFILE REUSE DATABASE "TEST1" RESETLOGS ARCHIVELOG

2 MAXLOGFILES 30

3 MAXLOGMEMBERS 5

4 MAXDATAFILES 200

5 MAXINSTANCES 2

6 MAXLOGHISTORY 292

7 LOGFILE

8 GROUP 1 '/dev/rora_redo01' SIZE 256M,

9 GROUP 2 '/dev/rora_redo02' SIZE 256M,

10 GROUP 3 '/dev/rora_redo03' SIZE 256M

11 -- STANDBY LOGFILE

12 DATAFILE

13 '/dev/rora_system',

14 '/dev/rora_undotbs01',

15 '/dev/rora_sysaux',

16 '/dev/rora_data01',

17 '/dev/rora_data02',

18 '/dev/rora_index01',

19 '/dev/rora_index02'

20 CHARACTER SET ZHS16GBK

21 ;

Control file created.

SQL> select open_mode,checkpoint_change# from v$database;

OPEN_MODE CHECKPOINT_CHANGE#

MOUNTED 0

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

454267

454267

。。。。。。

7 rows selected.

1.1.11.5 進行資料庫恢復

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 454517 generated at 05/18/2011 10:09:44 needed for thread 1

ORA-00289: suggestion : /archivelog/1_18_750759569.dbf

ORA-00280: change 454517 for thread 1 is in sequence #18

Specify log: {=suggested | filename | AUTO | CANCEL}

AUTO

ORA-00279: change 454599 generated at 05/18/2011 10:13:07 needed for thread 1

ORA-00289: suggestion : /archivelog/1_19_750759569.dbf

ORA-00280: change 454599 for thread 1 is in sequence #19

ORA-00278: log file '/archivelog/1_18_750759569.dbf' no longer needed for this

recovery

ORA-00279: change 454634 generated at 05/18/2011 10:13:49 needed for thread 1

ORA-00289: suggestion : /archivelog/1_20_750759569.dbf

ORA-00280: change 454634 for thread 1 is in sequence #20

ORA-00278: log file '/archivelog/1_19_750759569.dbf' no longer needed for this

recovery

ORA-00308: cannot open archived log '/archivelog/1_20_750759569.dbf'

ORA-27037: unable to obtain file status

IBM AIX RISC System/6000 Error: 2: No such file or directory

Additional information: 3

最終以找不到新的歸檔日誌序列檔案的錯誤提示結束,這屬於正常的情況,因為ORACLE 會在auto方式下窮盡尋找,直至最後,然後報一個找不到下一個歸檔日誌的錯誤。

SQL> alter database open resetlogs; ###以resetlogs的方式開啟資料庫，完成不完整恢復

Database altered.

1.1.11.6 新增臨時表空間檔案

因為恢復資料庫的時候，臨時表空間的檔案不會自動建立和恢復，所以需要在恢復資料庫後，進行手工的建立。

SQL>ALTER TABLESPACE TEMP ADD TEMPFILE '/dev/rora_temp01' reuse;

Tablespace altered.

1.1.12 檢驗資料庫是否恢復到最新的資料狀態.

u 檢查恢復後的資料庫SCN

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

454638 ####大於停庫前的454267

u 檢查特徵表的記錄

SQL> conn aidu/aidu****

Connected.

SQL> select count(1) from test01;

COUNT(1)

1024 ####與恢復前的資料記錄數完全相同,恢復成功.

我們可以看到這裡只恢復了1024條記錄，即恢復到最後一個日誌檔案包含的內容，最後插入的1024條記錄因為沒有做日誌切換，只保留在redo檔案中，所以這裡不能夠恢復回來。本實驗是不完整恢復的例子，redo檔案的內容無法恢復回來。

1.2 總結

當我們開始使用IBM DS8100高階儲存存放資料庫資料時,我們可以使用儲存的flash copy來獲取某個時間點的資料。IBM DS8100的FLASH COPY 還支援增量備份,而且FLASH COPY的複製速度很快,複製工作直接在儲存內部完成,不消耗網路的頻寬.(筆者測試過,1.2T容量的在投運資料庫，完成一次flashcopy，耗時1個小時零5分鐘),而且FLASHCOPY 是隨時都可以做的,不需要停止資料庫和掛起資料庫（如果不需要結合資料庫歸檔日誌檔案進行不完整恢復的話）。

使用FLASHCOPY 進行資料庫恢復，只需要將相應的FBVOL配置給主機訪問，在主機端認到這些vpath，匯入vg資訊，設定lv訪問屬性，就可以啟動資料庫了，前後時間不超過10分鐘。（如果使用rman進行恢復，1.2T的內容應該在4個小時以上）。而且結合本案例，我們可以使用FLASHCOPY +歸檔日誌檔案，將資料庫恢復到最新的狀態，用時20分種以內。（這裡需要短暫地將資料庫設定到online backup模式,僅僅幾秒種而已）。

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

相關文章