難しいデータベースリカバリプロセス　Oracle 11.2はかなり強大

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

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

これは単なる自己満足で、何の実な意味もない。ついでに、テストに見つけ出したことも後で述べる（未だにデータベースを起動できていないが、試し続けたいと思う。O(∩_∩)O ~。。。）;
まずは言うべきなのは11.2の強さである。昔に大部分の場合のエラもリカバリできる。データベースを起動出来たら、損害に関係ないチェックを試す。
1， 11.2から、コントロールファイル自動バックアップが完成した情報はm000によって完成する。それに、ほかの仕事も完成できる。もちろん、別のプロセスが使われる時しか利用できない。
2，DBA_TABLESPACEとV$TABLESPACEの源が違っている。一つ目はコントロールファイルから、もう一つはベーステーブルts$から
3，ts$とfile$が番号をスキップできない。
4，DBMS_HMが強い（Health Manager）。定期的にデータベースにあるものをいちいちチェックして、m000プロセスでtraceを書く。
。。。

主なテストステップはあまり覚えていないが、主なシミュレーションステップは以下の通り：
私の環境： db 11.2.0.3 OEL 5.8
1，二つのテーブルスペースを作成し（一つもいい、数なんかどうでもいい、よりはっきり見えるためだけ）、ログを切り替えて、OSでUNDOTBSを含むデータファイル（普通なデータファイルとundoデータファイルでいい）
2，データベースを起動するときに、ファイルがなくしたあるいは壊された。このとき、エラになったファイルをoffline dropして、データベースが起動できるはず。バックグラウンドにm000によって作成されたtraceがあって、HealthManagerは持続的にm000を引き起こし、ほかの悪い情報をtraceに書き込む。
3，undo$のトラブルロールバックセグメントをクリンアップする
4，新たな普通データのテーブルスペースを作成して、例えば“UNDTBS333”、， UNDO_TABLESPACE=この普通のテーブルスペース（scope=spfile）を設定して、データベースを起動する————–これは当時初めての誤操作だった。
5，データベースがエラになった。具体的な内容も解決策も忘れていた。薄々覚えているのは、undoの隠しバラメタとか、正確なundoテーブルスペース（create undo tablespace …）を作成するだけ。
6，解決したあと、データベースが起動できた。delete from fs$ where name=前に誤操作したあの普通なデータテーブルスペースUNDTBS333’。こうするのはそのとき、リスクを考えず人工的にクリンアップした。
全部で人工的にやってもいいんだが、当時に考えすぎちゃったから、誤操作した。
7，実はこのようなデータベースがまだ起動できるが、DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)でテストして、データベースにundo$とts$ がfile$と一致していないが、ほかのデータオブジェクトに影響を与えていない。
けど、頭が熱くなって、二つ目の過ちを犯した：コントロールファイルを再構造する
v$tablespaceの内容が誤ったと映されているが、dba_tablespacesが正確だと映している。その定義を検索することで、v$tablespaceのデータはx$kcctsというベーステーブルから獲得できた。つまりコントロールファイルの情報から。それにdba_tablespacesはts$を元にしているから、コントロールファイルを再構造するという愚かな発想が生み出した。
8，コントロールファイルのプロセス自体が誤った、.。わかるよね。。。もちろん、後でこのトラブルを避けた。具体的なステップを忘れたが、いいんだ。別に難しくないから。
9，再びデータベースを救出できなかった
。。。。。

このプロセスは以下の文にエラがあった。Oracle2進数ファイルをテストすることで、みつかりやすい。これはデータベースを起動するときに、file$に対してインサートするから、つまり、bootstrap$によって、file$のブロックを見つけ出す。そのすべての内容をこのテーブルにインサートする：
select blocks,NVL(ts#,-1),status$,NVL(relfile#,0),maxextend,inc, crscnwrp,crscnbas,NVL(spare1,0) from file$ where file#=:1

それでbbedでfile$を修正するという手を考え出した。delete from fs$のテーブルスペースのデータファイルを削除状態に変更する。テストによると、ts$もfile$も番号をスキップできない。例えば、このfile#は３で、その状態を削除したと設定すれば、コントロールファイルを再構造するときに、file#>3が一致性テストの場合に削除する。

そして、仕方なくfile＄をリカバリした。fs$でdeleteの記録をリカバリすることを考えたが、いい方法が見つからない。
もう一つの方法は10046によってトレースして、エラ文を探し出して、上のようなトラブルは忽ち解決できる：
select name,online$,contents$,undofile#,undoblock#,blocksize,dflmaxext,dflinit,dflincr,dflextpct,dflminext, dflminlen, owner#,scnwrp,scnbas, NVL(pitrscnwrp, 0), NVL(pitrscnbas, 0), dflogging, bitmapped, inc#, flags, plugged, NVL(spare1,0), NVL(spare2,0), affstrength from ts$ where ts#=:1
ここでは避けていない。Oracle2進数ファイルを修正することもいい策だと思うが、うまく使いこなさなかった。これは最後の手を使う例だが、なんかそこまでしたくない。

ではディクショナリーテストをgdbでスキップしてください：

(gdb) commands 
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>set *0x60023388=0x0 
>cont 
>end 
(gdb) cont 
Continuing.
 
Breakpoint 1, 0x00000000022370e0 in kcfckdb ()
 
Program received signal SIGSEGV, Segmentation fault.
0x0000000002cbe19f in slaac_int ()
(gdb) 

そして、再びresetlogデータベースを起動するときに：

Sat Nov 30 12:03:37 2013
ARC3 started with pid=21, OS id=29788 
Undo initialization finished serial:0 start:127664534 end:127664564 diff:30 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Errors in file /u01/app/oracle/diag/rdbms/bb/bb/trace/bb_ora_28960.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/stage/system01.dbf'
Errors in file /u01/app/oracle/diag/rdbms/bb/bb/trace/bb_ora_28960.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/stage/system01.dbf'
Error 604 happened during db open, shutting down database
USER (ospid: 28960): terminating the instance due to error 604
Sat Nov 30 12:08:38 2013
USER (ospid: 29792): terminating the instance due to error 604
Termination issued to instance processes. Waiting for the processes to exit
Sat Nov 30 12:08:48 2013
Instance termination failed to kill one or more processes

それで、一つの断絶点を知る必要がある。どうやってその断絶点を設定するか。データベースを “Verifying file header compatibility for 11g tablespace encryption”しないようにしてください。