Oracle がallow_resetlogs_corrutionで自動undo管理のもとにデータベースを強制的に起動する

ORACLEデータベース によくあるエラ の解決策

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

データベースを強制的に起動するステップ：

1）データベースを閉じるときにデータベースをバックアップする

後のオペレーションを実行する前に、バックアップがなければ、データベースをなくすｒかもしれない。

2）データファイルの時点が異なった場合に、もっとも古いデータファイルに近いシステムテーブルスペースデータファイルを使ったほうがいい。これでデータベースを起動するノートがエラになる可能性を減らせる。

3）*init<sid>.oraファイルを編集して、undo_managementを変更し、二つのバラメタを追加する：

•undo_management=autoをundo_management=manualに変更する

• undo_tablespace とundo_retentionを削除/移動する

•_allow_resetlogs_corruption=true,_corrupted_rollback_segments=を増やす

例えば：

_corrupted_rollback_segments=(SYSSMU1$,SYSMU2$, SYSMU3$, SYSMU4$, SYSMU5$, SYSMU6$, SYSMU7$ SYSMU8$, SYSMU9$, SYSMU10$)

注意：alert.logでどこの自動undoセグメントが使われたかすぐ分かる。SYSSで検索する。alter.logに探し出せなかった。フォーマットは_SYSMU_$，例えば：

_SYSSMU1_3423929671$

_SYSSMU2_3471197032$

_SYSSMU3_1940572779$

_SYSSMU4_703930491$

_SYSSMU5_2293911943$

_SYSSMU6_2782670761$

_SYSSMU7_3176421677$

_SYSSMU8_1585569843$

_SYSSMU9_1242704454$

_SYSSMU10_777531512$

UNIXで、以下のようなコマンドで、undoセグメントの名を獲得できる：

strings SYSTEM01.DBF|grep _SYSSMU | awk -F “$” ‘{print $1″$”}’ | sort -u

•使えるバラメタファイルがあれば、pfileを作成できる：

create pfile from spfile;

spfileを変更しないでください

4）SQL*PLUS中で、startup mount、ふさわしいバラメタファイルを使ったかをテストしてください。すべてのデータファイルもonlineあるいはsystem状態だった

show parameter corrupt

show parameter undo

select name,file#,status from v$datafile where status not in(‘ONLINE’,’SYSTEM’);

どんなラインが返されても、次のファイルでオンラインさせる：

alter database datafile file# online;

オンラインしたい場合に、その状態をreoverに変更し、ステップ5を続く。

5）

仮に不完全リカバリを実行して、resetlogsでデータベースを起動する。

recover database until cancel;

あるいは

recover database using backup controlfile until cancel;

アーカイブタイプを実行することが現れて、enterキーを押す

alter database open resetlogs;

6)データベースを起動した場合に、テーブルを検索してみる。例えば：

select sysdata from dual;

ラインが返されたら、ほかのテーブルを検索して、エクスポートを実行するために、データベースが足りるかを確認する。

データベースが起動してから、データベースをエクスポートする。エクスポート出来たら、生き残ったところからデータベースを再構造できる。つまり、すべてのデータファイルを削除して、新たなデータベースを作成する。

この方法で起動した場合に、再構造しない限り、Oracleに支持されない。どんな遅れたエクスポートファイルも取り返さない災厄をもたらす。

注意：init.oraで削除したステップ３に増やしたバラメタに注目してください。さもなければ、このinit.oraで新たなデータベースを作成するときに予想外の損害が起こる。

7）もしステップ5で、起動するときに、インスタンスがシャットダウンしたら、トレースファイルをチェックしてください。トレースファイルがあれば、そこにはORA-00600[2662]あるいはORA-00600[4000]を含んでいるかチェックしてください。これらのエラもalert.logに現れるかもしれない。