増分バックアップを使用してフィジカル・スタンバイ・データベースをリカバリーします
スタンバイデータベースは、基本的に本番データベースの一貫したコピーであり、本番災害、データ損失、または破損に役立ちます。
次の理由により、プライマリサイトとスタンバイサイトの間の遅延が発生する可能性があります。
- プライマリデータベースとスタンバイデータベース間のネットワーク帯域幅の問題。
- スタンバイデータベースが利用できない。
- プライマリデータベースのアーカイブREDOデータが誤って削除された。
プライマリサイトからアーカイブログをコピーして適用することで、プライマリ環境とスタンバイ環境を同期できますが、このプロセスには非常に時間がかかります。
もう1つのオプションは、プライマリサイトの増分RMANバックアップを使用してスタンバイサイトをリカバリすることです。システムがスタンバイデータベースに適用したことのないプライマリのアーカイブログが欠落している場合にも、この方法を使用できます。
このシナリオを設定するために、プライマリサイトからアーカイブログの一部を手動で削除して、破損したログや欠落しているログをシミュレートしました。
ステップ1：プライマリサイトとスタンバイサイトの同期ステータスを確認します
プライマリ（本番）とスタンバイ（スタンバイ）の間の同期ステータスを簡単に確認する必要があります。
プライマリサイト：
スタンバイサイト：
ステップ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：スタンバイ制御ファイルを復元する
スタンバイサイトで制御ファイルを復元します：
注 ：上記のコマンドを実行する前に、古い制御ファイルを手動で削除して、制御ファイルを使用していることを確認してください。
グリッドユーザーとしてログオンし、古い制御ファイルを削除します：
ステップ7：バックアップピースをカタログ化します
次に、バックアッププロセスをカタログ化します。
ステップ8：既存のデータファイルをカタログ化する
また、既存のデータファイルをカタログ化します：
ステップ9：既存のデータファイルを切り替えます
既存のすべてのデータファイルをイメージコピーに切り替えます：
ステップ10：データベースを回復する
次に、データベースを回復します：
この手順でスタンバイリフレッシュが終了します。あと数ステップ！
ステップ11：同期ステータスを確認する
両方のサイトのシーケンスをざっと見てください。スタンバイがプライマリに追いついたことに注意してください：
プライマリサイト：
スタンバイサイト：
ステップ-12：メディアリカバリを開始する
スタンバイサイトでメディアリカバリを開始します：
上記の手順を使用して、スタンバイサイトを回復できます。本番環境の増分バックアップを使用すると、かなりの時間を節約できます。
データベースサービスの詳細をご覧ください。
コメントや質問をするには、[フィードバック]タブを使用します。私たちと会話を始めることもできます。
-
OracleSEv2.0ディザスタリカバリのDbvisitスタンバイ
Dbvisitスタンバイは、Oracle®Standard Edition（SE）およびStandard Edition 2（SE2）データベース用のレプリケーションツールです。 はじめに Oracleデータベースのディザスタリカバリ（DR）ソリューションを設定する場合、コストは常に要因になります。 Oracleには標準データベースを備えたDRソリューションは含まれていませんが、Dbvisitがソリューションを提供しています。 Dbvisitは、Oracleの実証済みのアーカイブおよびやり直しメカニズムを使用し、データベースDR用のツールを提供します。 Dbvisitスタンバイには次の機能
-
Verticaデータベースのバックアップと復元
データの破損や偶発的な削除が発生した場合にデータを確実に回復できるようにするには、データベースのバックアップを定期的なメンテナンス作業にします。この投稿では、Vertica®データベースのバックアップと復元について説明します。 はじめに 分析データベース管理システムであるVerticaは、大量のデータを処理するように設計された列型ストレージプラットフォームであり、従来のリソースを大量に消費するシナリオで高速なクエリパフォーマンスを実現します。 Verticaには次の利点があります。 従来のデータベースリレーショナルデータベース管理システムよりもクエリパフォーマンスが向上します。 高可用性