web-dev-qa-db-ja.com

RMAN-06054:不明なアーカイブログを要求するメディアリカバリ、SCNはどこに保持されますか?

次のような状況です。

  1. DB1(--srv1サーバーにあります)データベースのバックアップは、毎日午前1時に作成されます。

  2. 2011/10/24のバックアップファイル(datafile、archivelog、controlfile、spfile)を取得し、サーバーに復元しましたsrv2

  3. Oracleの必要なログファイルのリカバリ中:

    RMAN-06054:シーケンス228で開始SCNが26651733のスレッド1の不明なアーカイブログを要求するメディアリカバリ

  4. サーバーでログファイルを検索srv1し、サーバーにコピーしましたsrv2。それをデータベースに登録し、recover databaseコマンドを再実行してください。それでも同じエラーですが、他のシーケンス番号とSCNがあります。

    RMAN-06054:シーケンス229で開始SCN26654944を使用して、スレッド1の不明なアーカイブログを要求するメディアリカバリ

これらのアーカイブログは、2011年10月24日以降に生成されるため、この日付のバックアップでは、新しいアーカイブログについては認識されません。そのシーケンスまでリカバリを設定できますが、SCNがどこに保存されているのか知りたいのですが? Oracleに新しいアーカイブログが必要なのはなぜですか?

サーバーsrv1srv2は互いに通信していません。

本当にありがとうございました。

6
kupa

各REDOログ・ファイル(およびアーカイブREDOログ・ファイル)には、開始SCNと終了SCNが含まれています。最後のREDOの場合、終了SCNは0xffffffffffffです。

nap01:~/oradata/jt10g$ strings redo01.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000004, SCN 0x0000000b05b5-0x0000000bd34f

nap01:~/oradata/jt10g$ strings redo02.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000005, SCN 0x0000000bd34f-0x0000000bf612

nap01:~/oradata/jt10g$ strings redo03.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000006, SCN 0x0000000bf612-0xffffffffffff

データベースが0xffffffffffffを見つけるまで、データベースはさらにログを要求し続けます。しかし、それは問題ではありません。リカバリにUNTIL SCNまたはUNTIL CANCELを指定できます(つまり、completeリカバリは必要ありません。つまり、最近のデータをいくつか失います)。

6
kubanczyk

@kubanczykからの回答を完了するだけで、とても良いです。

recover databaseコマンドを発行すると、RDBMSはcomplete recoveryを試行します。これは、SCN(スレッドとシーケンス)から始まるアーカイブログをバックアップを復元し、元のデータベースの「アクティブな」REDOログに達するまで、各アーカイブログを適用します。そのため、そのエラーが発生します。

したがって、@ kubanczykが投稿した最善の策は、キャンセルまでデータベースを回復を使用することです。これは、最新の(連続した)アーカイブログが見つかるまで不完全な回復です。

これでうまくいくはずです。

これにより、復元/回復プロセスが少し明確になることを願っています。

質問の他の部分については

SCNはどこに保存されますか?

SCN(システム変更番号)は、制御ファイルと各データファイルのヘッダーに保持されます。uitを使用すると、データベースは同期しているデータファイルと、データベースライターDBWRがデータベースバッファーキャッシュから次の書き込みを実行する場所を知ることができます。

また、各バックアップにはSCN(およびスレッドシーケンス)が「タグ付け」されており、RMANプロセスは、それらが取得された正確な「時間」を認識できます。

お役に立てれば。

2
Silvarion