iデータベースが起動できなくなったとお客様からの知らせがあった。この話を続く前に、言っておきたいことがある。このデータベースは我々が担当していない。私たちはこの知らせを受けた前に、このデータベース自身が存在していることですら知らなかった。一部のユーザーがすべてを私たちに担当させたが、一部のユーザーが五分五分であった。私たちに対して、お客様がどのやり方を取っても構わない。これはユーザーそれぞれ異なった選択である。いや、ちょっと話がわき道にそれた。原因を探して見れば、このデータベースはNOARCHIVELOGモードであったうえに、コールドバックアップもない。一回だけのデータベースをエクスポートしたこともない。こんなことはいつも金曜日に起こる!まずは、壊れたオンラインredoログで最初シャットダウンをリカバリしたが、失敗した。お客様が人工的にリカバリしてみたが、状況があまり変わっていない。その上に、シャットダウンした直後、すぐにコールドバックアップを作成していないから。これらの試しがよりひどい損害をもたらしたか私たちも見当がつかない。SCNをゆっくり増やしてリカバリしてみた。異なったredoログメンバーも試した。[3020]が現れた。ログファイルを成功にリセットしたが、データベースがまだ起動できず、「一部のオブジェクトが見つけ出せない」とエラ情報を返した。一言で言えば、システムテーブルスペースが足りないから、データベースを起動出来ない。PRM-DULを使うことが最適だった。ExtractionでDatabaseをUnloadingすることと意味している。その機能は起動できなくなったデータベースからデータを抽出する。これはデータベース損害次第である。詳しい情報は「PRM-DULガイドブック」に参考してください。そこで、PRM-DUL体験版をもらえる。私たちにデータ抽出サビースの申請を出してください。私はもう既にPRM-DULについて詳しいから、一つ目の方法を選んだ。それを使ったら、数時間だけでデータを収集できた。胡さんより、実演バーションをもらった。実演バーションで、すべてのテーブルに前の10行のデータを抽出できた。すべても成功に実行できたと確認できたら、お客様が七日のライセンスをもらった。私は数分だけで抽出コマンドを再び実行したが、なんと、PRM-DULが奇跡的にすべてのテーブルのダンプファイルもリカバリできた。SQLオブジェクトも作成した。いくつのSYSオブジェクトをダンプするだけで、インディクスと制約が抽出できるが、ユーザーが同じデータモデルを持っているから、そこから定義を抽出する方が簡単になる。お客様はこんな短い時間にこれほど致命的な損害をリカバリできたことに高く評価した。これはすべてもPRM-DULとその開發者、胡さんのおかげだ。胡さん、金曜日に仕事を早めに完成できて、ありがとうございました。31010802001379。