私たちのDRサイトで最近停電が発生した後、そこでのスタンバイがログの適用を停止していることを発見しました。明らかに、アーカイブREDOログには、データファイルを増大させるトランザクションがありましたが、スタンバイサイトのディスクには、そのトランザクションを完了するのに十分なディスク容量がありませんでした。そのため、スタンバイは必要に応じてマネージドリカバリを終了しました。
通常、アーカイブされたREDOログは7日間保持されます。残念ながら、この状況を発見するまでに15日が経過し、アーカイブされたREDOログが「欠落」していました。適用するアーカイブREDOログがないため、唯一の解決策はデータベースを最初から再構築することでした。このデータベースのサイズは約7TBであるため、最初から再構築するのは簡単なことではありません。
プライマリは、Linuxで実行されている3ノードのRAC11.2.0.2データベースです。スタンバイは2ノードのRACデータベースであり、明らかに同じOracleバージョンとOSバージョンです。
スタンバイの再構築をどのように達成したかを次に示します。
- プライマリをホットバックアップモードにし、データベースのディスクベースのスナップショットを作成しました。
- スナップショットが外部メディアにコピーされました。注：WANを介した配送には時間がかかりすぎました。
- 外部メディアはDRサイトに手で運ばれました。
- スタンバイのLOG_ARCHIVE_DEST_STATE_nがDEFERに設定されました。
- スタンバイデータベースがDGBroker構成から削除されました：データベーススタンバイの保存先を削除します;
- スタンバイデータベースのマウントポイントが消去されました。結局のところ、データベースはこの時点では本質的に役に立たなかったのです。
- 新しいマウントポイントが作成され、スナップショットがDRサイトのディスクに書き込まれました。
- ファイル転送が完了した後（約5日）、DRサイトのスナップショットを最新のスナップショットで更新するようにストレージに指示しました。これは、データベースよりもはるかに小さい変更のみが送信されたため、WANを介して実行されました。
- スタンバイ制御ファイルが作成されました：ALTER DATABASE CREATE STANDBY CONTROLFILE AS‘/ dir / path’;
- 簡単にするために、起動して実行するまでシングルインスタンススタンバイを使用したかったのです。そこで、スタンバイのRAC SPFILEからPFILEを作成し、テキストエディタを使用してパラメータファイルを変更し、RAC対応のパラメータを削除しました。 CLUSTER_DATABASEを削除し、すべてのインスタンス「*。」に使用されるインスタンス固有のUNDO_TABLESPACEパラメーターを設定し、THREADパラメーターなどを削除しました。通常のスタンバイデータベースには、STANDBY1とSTANDBY2の2つのインスタンスがあります。ノード1では、pfileをinitstandby1.oraではなく$ ORACLE_HOME / dbs / initstandby.oraに配置して、単一インスタンスデータベースがそのパラメータファイルを見つけられるようにします。パスワードファイルについても同様のことを行いました。
- ステップ9のスタンバイ制御ファイルをデータベーススナップショットの制御ファイルにコピーしました。
- シングルインスタンスデータベース用にpfileとpswdファイルを配置して、STARTUPMOUNTを実行しました。
- 必要なスタンバイREDOログを作成しました。この場合、プライマリにはスイッチオーバー操作を容易にするためのスタンバイREDOログもあり、プライマリからのスタンバイREDOログはスナップショットの一部ではありませんでした。そのため、旅行に参加しなかったSRLを削除する必要がありました。
- プライマリで、LOG_ARCHIVE_DEST_STATE_nをENABLEに設定します。
- プライマリインスタンスで、ALTER SYSTEMSWITCHLOGFILEを実行しました;
- プライマリとスタンバイの両方のアラートログで、スタンバイがログを受信していることを確認しました。つまり、ログ転送が機能していることを確認しました。
- マネージドスタンバイをオンにしました：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
- スタンバイのアラートログで、ログが適用されていることを確認しました。つまり、確認済みの適用が機能していることを確認しました。
この時点で、スタンバイデータベースがバックアップされて実行されていました。プライマリに単純なテーブルを作成し、その中に1行のデータを挿入し、ログの切り替えを再度実行してから、スタンバイをREAD ONLYモードで開いて、トランザクションがスタンバイで正常に再生されたことを確認しました。スタンバイデータベースが機能していることを確認したら、それをRACデータベースにする必要があります。かつてはRACデータベースであったため、これがRACデータベースになるためのすべてがすでに整っています。ジョブを完了するには、SQL * Plusでシングルインスタンススタンバイデータベース（SHUTDOWN ABORT）をシャットダウンし、srvctlを使用してスタンバイをRACデータベースとして起動します。
srvctl start database -dstandby -o mount
この時点で残っていたのは、スタンバイをDG Broker構成（DGMGRL内）に戻すことだけでした。データベーススタンバイを追加
これが最初に起こったとき、私はそれがこんなに大きなデータベースになるのか不安でした。上記の操作はいずれも、メディアとの間でファイルをコピーする以外はサイズに依存しません。しかし、すべてうまくいきました。
将来この状況に遭遇しないようにするために、Oracle Enterprise ManagerGridControlにアラートを追加しました。ログ配布またはログ適用が12時間遅れると警告アラートが表示され、24時間遅れるとクリティカルアラートが表示されます。これにより、アーカイブREDOログが7日後に自動的に削除される前に問題を修正するための十分な時間が与えられるはずです。または、少なくとも、状況を修正するまで、より多くの日数に相当するアーカイブREDOログを保持するようにプロセスを変更してください。