増分バックアップを使用してフィジカル・スタンバイ・データベースをリカバリーする方法
スタンバイ・データベースとは、本番データベースの一貫性のあるコピーのことです。本番環境で災害やデータ損失、データ破損が発生した際の保護手段として重要な役割を果たします。
はじめに
プライマリ・サイトとスタンバイ・サイトの間にラグ(遅延)が発生する主な理由としては、以下が挙げられます。
- プライマリ・データベースとスタンバイ・データベース間のネットワーク帯域幅の問題
- スタンバイ・データベースが利用できない状態
- プライマリ・データベース上のアーカイブREDOデータの誤削除
プライマリ・サイトからアーカイブログをコピーして適用することで両環境を同期させることも可能ですが、この方法は非常に時間がかかります。
そこで有効なのが、プライマリ・サイトのRMAN増分バックアップを使用してスタンバイ・サイトをリカバリーする方法です。この手法は、プライマリ側でアーカイブログが欠落してしまい、スタンバイ・データベースに適用できなくなった場合にも活用できます。
RMAN増分バックアップによるフィジカル・スタンバイ・データベースのリカバリー手順
このシナリオを再現するため、プライマリ・サイトから一部のアーカイブログを手動で削除し、ログの破損や欠落を意図的に発生させています。
ステップ1:プライマリ・サイトとスタンバイ・サイトの同期状態を確認する
まず、プライマリ(prod)とスタンバイ(stby)の同期状態を簡単に確認します。
プライマリ・サイト:
スタンバイ・サイト:
ステップ2:プライマリとスタンバイ間のギャップをシミュレートする
プライマリ・データベースにログオンし、LOG_ARCHIVE_DEST_STATE_2 を DEFER に変更します。その後、手動でログスイッチを数回実行してアーカイブログを生成し、プライマリとスタンバイの間にギャップを作成します。
この状態でプライマリとスタンバイの CURRENT_SCN を比較すると、同期を手動で無効化しているため、スタンバイが追いついていないことが確認できます。
プライマリ・サイト:
スタンバイ・サイト:
ここで LOG_ARCHIVE_DEST_STATE_2 を再度有効化すれば、スタンバイは自動的に追いつきます。しかし、ギャップをシミュレートするためには、その前にプライマリ・サイトからアーカイブログを手動で削除しておく必要があります。
両サイトとも、スレッド1およびスレッド2のアーカイブログがそれぞれ232番と218番より先のものになっていないことを確認してください。
続いて、LOG_ARCHIVE_DEST_STATE_2 を再び ENABLE に設定します。
予想どおり、プライマリ・サイトから一部のログが欠落しているため、スタンバイはログの適用を継続できません。
最後に、リカバリーをキャンセルし、スタンバイ・インスタンスをシャットダウンします。
ステップ3:増分バックアップの取得
プライマリにログオンし、スタンバイで最後に適用されたSCN以降の増分バックアップを取得します。
ステップ4:スタンバイ制御ファイルのバックアップ
次に、スタンバイ・サイトで制御ファイルをバックアップします。
ステップ5:バックアップをスタンバイ・サイトへ転送する
取得した増分バックアップをスタンバイ・サイトに転送します。
ステップ6:スタンバイ制御ファイルのリストア
スタンバイ・サイトで制御ファイルをリストアします。
注意: 上記のコマンドを実行する前に、必ず古い制御ファイルを手動で削除してください。これにより、新しい制御ファイルが確実に使用されます。
gridユーザーとしてログオンし、古い制御ファイルを削除します。
ステップ7:バックアップ・ピースのカタログ登録
続いて、バックアップ・ピースをカタログに登録します。
ステップ8:既存データファイルのカタログ登録
あわせて、既存のデータファイルもカタログに登録します。
ステップ9:既存データファイルの切り替え(SWITCH)
既存のすべてのデータファイルを、そのイメージコピーに切り替えます。
ステップ10:データベースのリカバリー
ここでデータベースをリカバリーします。
これでスタンバイのリフレッシュは完了です。あと数ステップで終了です!
ステップ11:同期状態の確認
両サイトのシーケンス番号を確認してみましょう。スタンバイがプライマリに追いついたことがわかります。
プライマリ・サイト:
スタンバイ・サイト:
ステップ12:メディア・リカバリーの開始
最後に、スタンバイ・サイトでメディア・リカバリーを開始します。
まとめ
以上の手順を実行することで、スタンバイ・サイトをリカバリーできます。本番環境の増分バックアップを活用することで、従来のアーカイブログ転送方式と比べて大幅な時間短縮が可能です。アーカイブログの欠落や同期遅延といったトラブルが発生した際の復旧手段として、ぜひ覚えておきましょう。
データベースサービスの詳細については、関連ページをご覧ください。
ご意見やご質問がある場合は、フィードバックタブをご利用ください。また、私たちとの対話も歓迎します。
-
Oracle SE/SE2向けディザスタリカバリを実現するDbvisit Standby徹底解説
Dbvisit Standbyは、Oracle® Standard Edition(SE)およびStandard Edition 2(SE2)データベース向けに設計されたレプリケーションツールです。 はじめに Oracleデータベースのディザスタリカバリ(DR)環境を構築する際、コストは常に大きな検討要素となります。Oracle Standard Editionには標準でDRソリューションが含まれていませんが、Dbvisitはこの課題に対する有効なソリューションを提供しています。Dbvisitは、長年の実績で信頼性が証明されているOracleのアーカイブログおよびREDOログの仕組みを活用し、
-
Verticaデータベースのバックアップと復元方法を徹底解説
データ破損や誤操作による削除が発生した場合に備え、確実にデータを復旧できるようにするには、データベースのバックアップを日常的なメンテナンス作業として組み込むことが重要です。本記事では、Vertica®データベースのバックアップとリストア(復元)について詳しく解説します。 はじめに Verticaは、大量のデータを扱うために設計されたカラム型ストレージプラットフォームを採用する分析データベース管理システムです。従来はリソースを大量に消費していたシナリオにおいても、高速なクエリパフォーマンスを実現します。 Verticaには、次のようなメリットがあります。 従来のリレーショナルデータベース管理シ