Ｄ社のアプリ開發者がASMの環境で、なんのバックアップもないのに、システムの肝心なアプリテーブルをDROPした。そのときに、ＰＲＭですぐに大部分のデータをリカバリできる。10gのあと、recyclebinゴミ箱を追加した。まずはDBA_RECYCLEBINSビューを確認して、DROPしたテーブルがそこにあるか否かをたしかめる。もしそこにもなかったら、ＰＲＭでリカバリしてください。
リカバリの流れは以下の通り：
まずはDROPされたデータテーブルを含むテーブルスペースを見つけ出す。
ディクショナリーをけんさくして、あるいはLOGMINERでDROPされたデータテーブルのDATA_OBJECT_IDを見つけ出す。DATA_OBJECT_IDを得られない場合にはNON-DICTモードでＰＲＭを起動する。DROPされたデータテーブルを含むテーブルスペースにすべてのフィルタを追加したら、SCAN DATABASE+SCAN TABLE from Extent MAP。
DATA_OBJECT_IDによって、データテーブルを見つけて、DataBridgeモードでもとのデータベースに伝送する。
| SQL> select count(*) from “MACLEAN”.”TORDERDETAIL_HIS”;
COUNT(*)
———-
984359
SQL>
SQL> create table maclean.TORDERDETAIL_HIS1 as select * from maclean.TORDERDETAIL_HIS;
Table created.
SQL> drop table maclean.TORDERDETAIL_HIS;
Table dropped. |
Logminerに通って、あるいはリカバリシーン9の方法で大抵なDATA_OBJECT_IDを得られる、LOGMINERを利用するスクリプトは以下の通り：
| EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log1.f’, OPTIONS => DBMS_LOGMNR.NEW);
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log2.f’, OPTIONS => DBMS_LOGMNR.ADDFILE);
Execute DBMS_LOGMNR.START_LOGMNR(DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG+DBMS_LOGMNR.COMMITTED_DATA_ONLY);
SELECT * FROM V$LOGMNR_CONTENTS ;
EXECUTE DBMS_LOGMNR.END_LOGMNR; |
たとえここでDATA_OBJECT_ID得られなくとも、データテーブルが多くない場合に人工的にリカバリしたいデータテーブルを見つけ出すことができる。
まずはDROPされたデータテーブルを含むテーブルスペースをOFFLINEする。
| SQL> select tablespace_name from dba_segments where segment_name=’TPAYMENT';
TABLESPACE_NAME
——————————
USERS
SQL> select file_name from dba_data_files where tablespace_name=’USERS';
FILE_NAME
—————————————————————-
+DATA1/parnassus/datafile/users.263.843694795
SQL> alter tablespace users offline;
Tablespace altered. |
ＰＲＭを起動して、NON-DICTモードに入って、該当するデータフィルタを追加し、SCAN DATABASE+SCAN TABLE From Extentsを選んでください。
ASM DiskgroupにあるすべてのASM Disks追加したら、ASM analyzeをクリックしてください。
非ディクショナリーモードなので、必要な文字セットを入力してください。
DROPされたデータテーブルを含むテーブルフィルタをクリックすればいい、ほかのフィルタはどうでもいい。そしてSCANをクリックする。
生成したデータベースの名前をクリックし、右ボタンでscan tables from extentsを選んでください。
人工的にDATA_OBJECT_ID=82641のデータはDROPされたTORDERDETAIL_HISテーブルに該当し、DataBridge技術でモートのリポジトリに伝送する。
