非常規資料恢復的幾種場景（利用AUL恢復資料）
阿新 • • 發佈：2019-01-23
<<INTRO>>
同Oracle內部資料恢復工具DUL一樣，利用AUL可以直接讀取資料檔案內容，當有壞塊出現且無備份或者有備份但常規方法無法恢復資料庫時，一旦常規手段無法解決問題，可以通過此工具拯救資料。
當然，備份重於一切，DUL、ODU、AUL等資料恢復方式只作為最後手段
<<STEPS>>
1)建立配置檔案，如 aul.cfg，該檔案資料來自 v$datafile的file#,rfile#,name列
# this is a demo AUL config file, wanna use it, create it manually
11D:\Oracle\product\10.2.0\oradata\orcl\SYSTEM01.DBF
44D:\Oracle\product\10.2.0\oradata\orcl\USERS01.DBF
2)在aul中開啟配置檔案並提取system表空間資訊，如：
AUL>open aul.cfg
AUL>unload table user$;
AUL>unload table obj$;
AUL>unload table tab$;
AUL>unload table col$;
此時會生成 auluser.txtaulobj.txt aultab.txt aulcol.txt 四個檔案
3.1)此時可在aul中查詢表結構也可以開始恢復，如
AUL>list table scott
可得到恢復scott使用者下的表的指令碼（亦可輸入list table scott to recover_scott.sql可把該輸出做成指令碼執行，通過執行該sql指令碼來生成恢復指令碼）執行生成的指令碼，如：unload table scott.e to scott.e 即可在AUL目錄下生成要恢復的sqlldr指令碼[e.txt，e_sqlldr.ctl E_syntax.sql]
4) 利用sqlldr生成資料[e_sqlldr.ctl中可能需要修改成絕對路徑，及新增表字首為使用者名稱]
<<Done>>
用AUL恢復truncate：
由於是對資料檔案直接讀取，故AUL等工具都是假定所有資料檔案中的資料都是已經提交了的，沒有對資料檔案進行資料一致性的校驗，做的實際上是髒讀。不過關於這一點也是有點好處的，可以用此恢復truncate/drop誤操作的表。
鑑於truncate只是將相應塊頭(segment的第一個塊)格式化, segment中儲存資料的部分都還存在, 到下次用時到才真正地重新格式化
方法類似，不同之處在第3步
<<STEPS>>
3.2）
AUL>desc scott.d --得到其OBJD=52598 BLOCK=435
由於truncate表時，segment header被格式化，extent map可能丟失，可先掃描整個資料檔案並將extent分配資訊輸出到文字中，如
AUL>scan extent file 4 --將結果輸出到aulext.txt中
本例中，segment header是(4,435) --(檔案號,塊號)
AUL>oradump file 4 block 443 --得到新的OBJD=52598，老的OBJD可以從segment header後面一個數據塊得出，即OBJD=52597。若該表有多個Free List Group則可能還需要後面幾個塊，以此類推。使用oradump檢視前一個塊442資訊，如下
AUL>oradump file 4 block 442
得出seg/obj=0x000cd7f=52607 即OBJD=52606
4)根據得出的OBJD生成恢復指令碼，如：
AUL>unload table scott.d object 52606
5)利用sqlldr將資料注入到要恢復的表中完成恢復。
<<Done>>
<<SUMMARY>>
相對於Oracle內部恢復工具DUL，AUL更好地支援中文字元及大物件等（如DUL恢復CLOB物件會造成亂碼）
主要用於資料庫宕機後，無法啟動例項，為最後拯救資料的手段；
要恢復相關DML操作而資料庫無法閃回資料，或未啟用閃回日誌時要無停機恢復被truncate的表[比較適用於資料量不大的情況，若是資料量較大建議停機後用備份恢復]
最後手段。DUL的我朝山寨增強版。可能存在髒讀。
切記：第一守則--備份重於一切！僅在常規手段無法恢復資料時採用
參考：http://www.anysql.net/download
同Oracle內部資料恢復工具DUL一樣，利用AUL可以直接讀取資料檔案內容，當有壞塊出現且無備份或者有備份但常規方法無法恢復資料庫時，一旦常規手段無法解決問題，可以通過此工具拯救資料。
當然，備份重於一切，DUL、ODU、AUL等資料恢復方式只作為最後手段
<<STEPS>>
1)建立配置檔案，如 aul.cfg，該檔案資料來自 v$datafile的file#,rfile#,name列
# this is a demo AUL config file, wanna use it, create it manually
11D:\Oracle\product\10.2.0\oradata\orcl\SYSTEM01.DBF
44D:\Oracle\product\10.2.0\oradata\orcl\USERS01.DBF
2)在aul中開啟配置檔案並提取system表空間資訊，如：
AUL>open aul.cfg
AUL>unload table user$;
AUL>unload table obj$;
AUL>unload table tab$;
AUL>unload table col$;
此時會生成 auluser.txtaulobj.txt aultab.txt aulcol.txt 四個檔案
3.1)此時可在aul中查詢表結構也可以開始恢復，如
AUL>list table scott
可得到恢復scott使用者下的表的指令碼（亦可輸入list table scott to recover_scott.sql可把該輸出做成指令碼執行，通過執行該sql指令碼來生成恢復指令碼）執行生成的指令碼，如：unload table scott.e to scott.e 即可在AUL目錄下生成要恢復的sqlldr指令碼[e.txt，e_sqlldr.ctl E_syntax.sql]
4) 利用sqlldr生成資料[e_sqlldr.ctl中可能需要修改成絕對路徑，及新增表字首為使用者名稱]
<<Done>>
用AUL恢復truncate：
由於是對資料檔案直接讀取，故AUL等工具都是假定所有資料檔案中的資料都是已經提交了的，沒有對資料檔案進行資料一致性的校驗，做的實際上是髒讀。不過關於這一點也是有點好處的，可以用此恢復truncate/drop誤操作的表。
鑑於truncate只是將相應塊頭(segment的第一個塊)格式化, segment中儲存資料的部分都還存在, 到下次用時到才真正地重新格式化
方法類似，不同之處在第3步
<<STEPS>>
3.2）
AUL>desc scott.d --得到其OBJD=52598 BLOCK=435
由於truncate表時，segment header被格式化，extent map可能丟失，可先掃描整個資料檔案並將extent分配資訊輸出到文字中，如
AUL>scan extent file 4 --將結果輸出到aulext.txt中
本例中，segment header是(4,435) --(檔案號,塊號)
AUL>oradump file 4 block 443 --得到新的OBJD=52598，老的OBJD可以從segment header後面一個數據塊得出，即OBJD=52597。若該表有多個Free List Group則可能還需要後面幾個塊，以此類推。使用oradump檢視前一個塊442資訊，如下
AUL>oradump file 4 block 442
得出seg/obj=0x000cd7f=52607 即OBJD=52606
4)根據得出的OBJD生成恢復指令碼，如：
AUL>unload table scott.d object 52606
5)利用sqlldr將資料注入到要恢復的表中完成恢復。
<<Done>>
<<SUMMARY>>
相對於Oracle內部恢復工具DUL，AUL更好地支援中文字元及大物件等（如DUL恢復CLOB物件會造成亂碼）
主要用於資料庫宕機後，無法啟動例項，為最後拯救資料的手段；
要恢復相關DML操作而資料庫無法閃回資料，或未啟用閃回日誌時要無停機恢復被truncate的表[比較適用於資料量不大的情況，若是資料量較大建議停機後用備份恢復]
最後手段。DUL的我朝山寨增強版。可能存在髒讀。
切記：第一守則--備份重於一切！僅在常規手段無法恢復資料時採用
參考：http://www.anysql.net/download