DROP TABLESPACEのOracle特別なリカバリ

ORACLEデータベースを正常にオープンできない場合やマウントできない場合、データベースが損傷した場合等にオラクルデータベースファイル(~.dbf)を直接読み込むことによって、ファイルから有効なデータを抽出するツールです。

Oracleデータベース救済-リカバリ-運用とメンテナンス-オプティマイザサビースは詩檀ソフトに訪ねてください。

自分でうまくいかないときに詩檀ソフトORACLEデータベースリカバリチームに助けを求めてください。

携帯番号: +86 13764045638    メール:[email protected]

ある企業に一番大事な業務は誤操作で、複数の業務テーブルスペースがDROPされた。これらの業務テーブルスペースには300あまりのテーブルを格納している。それにどんなバックアップもない。

詩檀ソフトエンジニアが現場に赴いて、トラブルについての詳しい情報を理解する:

  1. データベースはアーカイブモードだが、有効なバックアップがない。
  2. 複数のテーブルスペースがDROPされたが、DROP TABLESPACEがinlucding datafilesを指定していないから、関連するデータファイルがまだ削除されていない。
  3. flashback queryでOBJ$、TAB$などのテーブルを検索して、DROP TABLESPACEに削除されたディクショナリー情報を獲得するときに、ORA-01555エラが現れる。これはUNDOデータも期限切りと意味している。flashback queryで、DROP TABLESPACEについてのディクショナリーデータをリカバリできない。
  4. bbedでdbfのディクショナリーテーブルを観察して、OBJ$、TAB$などのディクショナリーテーブルが削除されたわずかのデータしか残っていない。特別なリカバリで削除されたデータ行をリカバリするという方法でディクショナリーデータをリカバリできない。

以上のシーン情報で、DROP TABLESPACEしたあとでflashback queryあるいはbbedなどの手段で該当するデータディクショナリーをリカバリできないから、データディクショナリーをリカバリすることでdrop tablespace操作をロールバックするには不可能である。

この場合に対して、有効な物理あるいはロジックバックアップもない場合に、ORACLE PRM-DULを使わないとリカバリできない。

 

注意:このような有効なバックアップがない場合に対して、100%にデータをリカバリできることを保障できない。データをリカバリする比率はデータスペースがOracleに回収された後に再び使われるかあるいは上書きされるかということで決める。DROP TABLESPACE操作自身には一連の再帰操作を含んでいるから。つまり、そのテーブルスペースにあるすべてのデータテーブルを再帰的にDROPして、すべてのデータテーブルを完全にDROPしたこそホントのDROP TABLESPACEが始められる。持続期間で回収したスペースが再び利用され、上書きされる。

 

ディクショナリーデータは既になくしたから、ORACLE PRM-DULに非ディクショナリーモード(NON-SYSTEM TABLESPACE)で作業を進行する。つまり、DROP TABLESPACEされたデータファイルのSEGMENT HEADERあるいはSEGMENT EXTENTSデータを直にスキャンする。これらのデータにはテーブルの行データを含んでいるが、TABLE_NAMEあるいはCOLUMN_NAMEなどのメータデータを含んでいない。非ディクショナリーモードで抽出したテーブルのテーブルの名前はOBJ+で、そのDATA_OBJECT_ID形式は、例えばOBJ9999、そのテーブルがDATA_OBJECT_ID=9999のデータテーブルと意味している。故に、非ディクショナリーモードでUNLOADされたテーブルはそのデータはどこのテーブルに属しているかを人工的に識別する必要がある。

 

PRM-DUL非ディクショナリーモードで、二つのスキャン方法がある:SEGMENT HEADERあるいはEXTENTモード。テーブルスペースが何のデータファイルもなくしていない上にテーブルヘッダもなくしていない場合に、SEGMENT HEADERモードを使ってください。PRM-DULはテーブルヘッダモードでDATABASEとTABLES;をSCANして、190を超えたテーブルを見つけ出した。一部の業務テーブルをリカバリできたが、SEGMENT HEADERモードで五つ肝心な業務テーブルを見つけ出せない。

 

これは五つのテーブルのSEGMENT HEADERがもうDROP TABLESPACEされてこわれたと意味している。これはDROP TABLESPACEプロセスで一部の回収スペースが上書きされたと意味する。SEGMENT HEADERモードで必要なテーブルを見つけ出せないから、後はEXTENTモードで実行する。

 

EXTENTモードはデータファイルにあるすべての行のデータブロックを見つけ出すから、SEGMENT HEADERを必要としていない。故に、EXTENTモードで大量なデータを獲得できる。スキャンした範囲がより広くなるので、リカバリする必要としていないデータテーブルもより多く現れるから、前の方法よりずっと時間をかかる。


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *