My Oracle Support Banner

10g以降のリリースのRMANによるRESETLOGSをまたがるリカバリ (Doc ID 2689420.1)

Last updated on SEPTEMBER 28, 2020

適用範囲:

Oracle Database - Enterprise Edition - バージョン 10.1.0.2 以降
この文書の内容はすべてのプラットフォームに適用されます。

目的

不完全リカバリ(Point-in-Timeリカバリ)の実行後は、データベースをRESETLOGSでオープンする必要があります:

SQL> alter database open resetlogs;


RESETLOGSでのオープンは、データベースの新しいインカネーションを生成し、ログ順序番号をリセットします。10gより前のリリースでは、RESETLOGSでのオープン前に取得したバックアップから、オープン後に生成されたREDOを使用してリカバリを行うことはできなかったので、RESETLOGSでのオープンを行ったら、速やかにバックアップを取得することが重要でした。また、RMANのリカバリ・カタログを使用している場合は、次のようにデータベースの新しいインカネーションをカタログに認識させる必要もありました :

RMAN> reset database;


10g以降のリリースでは、不完全リカバリとRESETLOGSでのオープン実行後に、バックアップを取得し直す必要がありません。

この機能は、バックアップ制御ファイルを使用したリカバリを行って、RESETLOGSでオープンした場合にも使用可能です。

RESETLOGSをまたがるリカバリの機能には次のような利点があります:

* 不完全リカバリの実行後に全体バックアップを取得する必要がありません。
* フェイルオーバー実行後に新しいスタンバイ・データベースを作成する必要がありません。
* 以前からのリカバリ・コマンドでこの機能を利用することができるので、バックアップ・スクリプトを修正する必要がありません。
* RMANを使用すれば、前のインカネーションで取得した全体バックアップをベースにした増分バックアップが取得できます。
* ブロック・メディア・リカバリでも、前のインカネーションのバックアップからリストアしたブロックをRESETLOGSをまたいでリカバリできます。


古いインカネーションのデータベースに、新しいインカネーションで生成されたREDOログを適用できます。そのため、10g以降のリリースでは、アーカイブ・ログのファイル名のフォーマットが変更され、RESETLOGSでのオープンによってログ順序番号がリセットされても、以前のインカネーションの同じログ順序番号のアーカイブ・ログを上書きすることがないようになっています。

解決策

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


本書の内容
目的
解決策
参照情報

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.