前の数日にPRM-DULで(http://www.parnassusdata.com/)お客様のOracleデータベースをリカバリした。
その中に、あるユーザーはraid-5のストレージ陣列によって、ディスクがかなりひどく壊された。バックアップがあるがあるが、テストにパースできなかった。Oracleデータベースをリカバリする途中に、大量なundo損害トラブルが起こっている。しかも、システムテーブルのシステムロールバックセグメントで起こった。残っているのは十ヶ月前のバックアップしかない。
もうひとりのエンジニアと協力し、壊されたストレージシステムから、二つのOracleデータベースをリカバリしてみた。そのなかの一つのデータベースに対して、PRM-DULはそのシステムテーブルスペースのデータディクショナリーを読み取れる。損害がかなり深刻であったが、データディクショナリー自身には何のトラブルもない。もう一つのデータベースのシステムスペースには損害があったが、PRM-DULのディクショナリーモードでリカバリしてみたが、非ディクショナリーモードに転じた。
十ヶ月前に、一部のrmanバックアップによって、十ヶ月前のシステムデータファイルでデータディクショナリーを再構造できる。けど、十ヶ月前のデータがちょっとした問題点があるので、最後に非ディクショナリーモードを採用せざるを得なかった。これで、テーブルの名前、列のセグメントの名前、及び列のセグメントのタイプなどを当てる必要がある。もし、ユーザー側が業務に詳しい業務員の協力を得られなければ、Oracle技術者だけでは、かなり工夫をかけるので、人工費が高くなる。
最後にほぼ100%にデータをリカバリできた。データディクショナリーがある場合に対して、TAB$のNUM_ROWSを参考し、各テーブルの行数を確認すれば、どれほどのデータがなくしたことが明白になる。
PRM-DULなら、論理的にすべてのデータをリカバリできるが、このケースには一部のデータファイルのブロックが物理的に壊滅されたため、100%にリカバリできなかった。ここでは、あえてもう一度言う、本当に大切なデータであれば、きちんとバックアップしてください。
Leave a Reply