使用FLASHCOPY+資料庫歸檔日誌檔案進行資料庫不完整恢復技術實施方案(2 /2)
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
#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:
{
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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 使用FLASHCOPY+資料庫歸檔日誌檔案進行資料庫不完整恢復技術實施方案(1 /2)資料庫
- 使用冷備份與冷備份後的資料庫歸檔日誌檔案進行資料庫不完整恢復資料庫
- 丟失已歸檔日誌檔案下恢復資料庫資料庫
- Oracle叢集資料庫中恢復歸檔日誌Oracle資料庫
- 分析Oracle資料庫日誌檔案(2)Oracle資料庫
- 只有.dbf資料檔案進行資料庫恢復資料庫
- oracle歸檔日誌丟失後的資料庫恢復Oracle資料庫
- SQL Server資料庫多資料檔案恢復技術SQLServer資料庫
- 無歸檔日誌恢復rman資料
- 兩個日誌組未能歸檔之後恢復資料庫資料庫
- Oracle資料庫恢復：歸檔日誌損壞案例一則Oracle資料庫
- 建立資料庫檔案-日誌檔案-次要資料庫檔案資料庫
- REDO日誌損壞,非歸檔模式資料檔案恢復模式
- 非歸檔模式恢復資料庫模式資料庫
- 使用RMAN備份集和過時的控制檔案進行資料庫的恢復(2/2)資料庫
- 資料庫資料恢復-SQL SERVER資料庫檔案大小變為“0”的資料恢復方案資料庫資料恢復SQLServer
- 對歸檔模式下CLEAR 未歸檔日誌後恢復資料庫的一點看法模式資料庫
- Sqlserver系統資料庫和使用者資料庫日誌檔案全部丟失的恢復SQLServer資料庫
- MySQL資料庫中的日誌檔案---(2)普通查詢日誌MySql資料庫
- 缺少歸檔日誌，ORACLE資料庫恢復使用_allow_resetlogs_corruption引數Oracle資料庫
- oracle RMAN 非歸檔資料庫恢復Oracle資料庫
- 測試在丟失歸檔日誌的情況下，跳過部分歸檔日誌進行資料恢復資料恢復
- 沒備份，歸檔日誌存在，丟失資料檔案的恢復
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- DATA GUARD主庫丟失資料檔案的恢復(2)
- 歸檔路徑更改後，如何對資料庫進行恢復(轉)資料庫
- SQL資料庫怎麼進行資料歸檔和歸檔管理？SQL資料庫
- Oralce資料庫關閉歸檔日誌並且刪除歸檔日誌資料庫
- RMAN資料庫恢復 之歸檔模式有(無)備份-丟失資料檔案的恢復資料庫模式
- 教你自動恢復MySQL資料庫的日誌檔案(binlog)MySql資料庫
- 丟失當前current重做日誌檔案下恢復資料庫資料庫
- 解決Oracle資料庫日誌檔案丟失恢復問題Oracle資料庫
- RAC環境備份歸檔日誌和RMAN恢復啟動資料庫資料庫
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 資料庫備份與恢復（使用歸檔後滾）資料庫
- 使用RMAN備份集和過時的控制檔案進行資料庫的恢復(1/2)資料庫
- Bak檔案恢復到資料庫資料庫
- 歸檔資料庫中的不可恢復操作資料庫