プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：service@parnassusdata.com

  Oracleデータベースが起動できないときに、大体は以下の状況に分けられる：
  • バラメタ設定が間違えた
  • コントロールファイルが壊れた
  • ログファイルがこわれた
  • データファイルヘッダがこわれた
  • データディクショナリーがこわれた
  • UNDO損害
  • SMONがトランザクションをロールバックするときにトラブルが起きた
  異なるエラORA-00600/ORA-07445などに対して、異なった対応法も挙げられる： ORACLEで現れたデータブロック損害/診断corruptionはいろいろあるが、症状に分けると、以下の通りになる：  ORA-01578エラ  ORA-600[61xx]エラ  ORA-600[3339]あるいはORA-600[3398]  ORA-600[2130],ORA-600[2845],ORA-600[4147]エラなど  SELECT が探し出したエラデータ このようなORACLEデータブロックがこわれたトラブルに対して、以下のような使いやすいステップがある： 1、データベースがオープンした状態ではブロックが位置しているデータファイル番号、ブロック番号を判断する必要がある（テーブルあるいはインディクス）。ORA-1578エラあるいはORA-600が報告した変数情報に対して、以下のSQLで位置を確かめる SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = &fileid and &blockid between block_id AND block_id + blocks - 1; 2、前のステップに獲得したSEGMENT_TYPEによって、以下のSEGMENT_TYPEの場合は再構造できる：  index  データはテーブルを再び獲得できるあるいはテーブルを再構造できる  SYSTEMというロールバックセグメントを除いて、セグメントをロールバック。t  一時的なテーブル 3、ステップ２インポートに属していなければ、以下の情報を確認してください：  データベースはアーカイブモードか  export /sqlldrを含んで、テーブルのバックアップデータがあるか。  そのテーブルに NOT NULLセグメントに基づくインディクスがあるか？  このようなインディクスがあれば、UNIUQEに属しているか？ 4、前にこのレポジトリにブロックが壊れたことがあるかを確かめてください。経験豊かなDBAはalert.logで大体の状況を把握できるが、前にこのようなトラブルが現れたことがあれば、次のアドバイスに参考してください： 5、ユーザーがアーカイブモードを使っているなら、今後の診断のために、アーカイブredoとオンラインログを格納してください。アーカイブモードでなければすべてのオンラインログをバックアップしてください。 6、場合によると10210,10211と10212 eventでエラの原因も見つけ出せる。Oracle自身でトラブルを引き起こしたわけではない場合に、トラブルがあるデータブロックをダンプして、OS、ストレージと巻コントローラーのログで分析してください。メモリー損害の場合に、_db_block_cache_protectを使ってください。けど、すべてのプラットフォームも_db_block_cache_protectを支持しているわけではない。 7、ある場合に、ユーザーがアーカイブモードでトラブルが再び現れたときにリカバリできないことを避けられる。 必要な証拠 1、 ORACLE TRACEとALERTファイルを含んで、このようなトラブルの源を診断して、報告に別のデータブロックがこわれたかを確認する。 2、OSでこわれたデータブロックをダンプする Unix: dd if=badfile.dbf count=5 bs=2048 skip=75 アドバイス 1、traceあるいはredoログダンプするときに、ユーザーの予想を調整してください：  リカバリする方法を考えるではなく、原因を探し出してください  証拠があるが、決定的な結論を下せる訳ではない。 2、時にデータブロックがメモリーでこわれた。例えばORA-600[3398]、これを検証するには：  analyze table X validate structure cascade;  alter system flush buffer_cache;  OSでそのデータブロックをダンプして分析する 後処置 1、本質を探す、例えば：  すべての損害はある設備、コントローラーで起こる。  四つブロックごとに一つのブロックが壊れる。  データブロック自身に何の問題もないが、現れる位置を間違えた。  データブロックは健全だが、別のところにトラブルが起こった。 2、損害/こわれたブロックがあるデータブロックを避けて、テーブルを再構造する： 10231 level 10トランザクションで全テーブルスキャンのCTASを実行する ROWIDを構造してこわれたブロックにアクセスすることを避ける 【データリカバリ】ROWIDを構造することで、バックアップなしにORA-1578、ORA-8103、ORA-1410などトラブルを避ける。 3、 10210、10211及び10212でデータブロックをアップグレードして、こわれたブロックの詳しい内容を確かめる。10231 eventを使ってください。 ほかのツール ほかのツールはdul、oranum、orapatch、bbedなどORACLE内部的なツールを含んでいる。