日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ディザスタリカバリワークフロー

09/23/2024 共同作成者

企業はパブリッククラウドを、ディザスタリカバリの実現可能なリソースとして活用してきました。SnapCenter は、このプロセスを可能な限りシームレスに実行します。このディザスタリカバリワークフローはクローニングワークフローと非常によく似ていますが、データベースリカバリは、クラウドにレプリケートされた最後の使用可能なログまで実行され、可能なすべてのビジネストランザクションをリカバリします。ただし、ディザスタリカバリに固有の、設定前の手順と設定後の手順がほかにもあります。

オンプレミスの Oracle 本番 DB を、 DR 用にクラウドへクローニング

クローンリカバリが最後に使用可能なログで実行されるかどうかを検証するために、小さなテストテーブルを作成して行を挿入しました。テストデータは、使用可能な最後のログへの完全リカバリ後にリカバリされます。
Oracle のデータベース管理ユーザ ID として SnapCenter にログインします。リソースタブに移動します。このタブには、 SnapCenter で保護されている Oracle データベースが表示されます。

Oracle ログリソースグループを選択し、 Backup Now （今すぐバックアップ）をクリックして Oracle ログバックアップを手動で実行し、最新のトランザクションをクラウド内のデスティネーションにフラッシュします。実際の DR シナリオでは、最後にリカバリ可能なトランザクションはデータベースログボリュームからクラウドへのレプリケーション頻度によって異なり、クラウドへのレプリケーションは企業の RTO ポリシーまたは RPO ポリシーによって異なります。

入力/出力ダイアログを示す図、または書き込まれた内容を表す図

非同期 SnapMirror では、ディザスタリカバリシナリオでクラウドデスティネーションにしていないデータは失われます。これは、データベースログのバックアップ間隔で行われます。データ損失を最小限に抑えるため、ログバックアップの頻度を増やすようにスケジュールを設定できます。ただし、技術的には、ログのバックアップ頻度に制限があります。

セカンダリ・ミラー・バックアップで最後のログ・バックアップを選択し、ログ・バックアップをマウントします。
最後のフルデータベースバックアップを選択し、 Clone をクリックしてクローンワークフローを開始します。
ホスト上で一意のクローン DB ID を選択します。
ログボリュームをプロビジョニングし、 Oracle フラッシュリカバリ領域とオンラインログのターゲット DR サーバにマウントします。

Oracle クローン手順はログボリュームを作成しないため、クローニングを実行する前に DR サーバでプロビジョニングする必要があります。
ターゲットのクローンホストと、データファイル、制御ファイル、および REDO ログを配置する場所を選択します。
クローンのクレデンシャルを選択します。ターゲット・サーバの Oracle ホーム構成の詳細を入力します
クローニングの前に実行するスクリプトを指定します。データベースパラメータは必要に応じて調整できます。
リカバリオプションとして Until Cancel を選択して、使用可能なすべてのアーカイブログをリカバリで実行し、セカンダリクラウドの場所に最後にレプリケートされたトランザクションをリカバリします。
必要に応じて、 SMTP サーバで E メール通知を設定します。
DR クローンの概要：
クローニングされた DB は、クローンの完了直後に SnapCenter に登録され、バックアップ保護に使用できます。

Oracle の DR クローンの検証と設定後の POST コマンドです

クラウドの DR サイトでフラッシュ、レプリケート、リカバリされた最後のテストトランザクションを検証します。
フラッシュリカバリ領域を設定します。
ユーザアクセス用に Oracle リスナーを設定します。
レプリケートされたソースボリュームからクローンボリュームをスプリットします。
クラウドからオンプレミスへの逆レプリケーションを行い、障害が発生したオンプレミスデータベースサーバを再構築します。

クローンスプリットでは、一時的にストレージスペースが利用され、通常の処理よりもはるかに高くなる場合があります。ただし、オンプレミスの DB サーバを再構築すると、追加スペースを解放できるようになります。

オンプレミスの SQL 本番 DB を DR 用のクラウドにクローニング

同様に、 SQL クローンリカバリが前回使用可能なログを通過したかどうかを検証するために、小さなテストテーブルを作成して行を挿入しました。テストデータは、使用可能な最後のログへのフルリカバリ後にリカバリされます。
SQL Server 用のデータベース管理ユーザ ID で SnapCenter にログインします。[ リソース ] タブに移動します。このタブには、 SQL Server 保護リソースグループが表示されます。
パブリッククラウドのセカンダリストレージにレプリケートする最後のトランザクションをフラッシュするには、ログバックアップを手動で実行します。
クローンに対して最後に実行した SQL Server のフルバックアップを選択します。
クローンサーバ、クローンインスタンス、クローン名、マウントオプションなどのクローン設定を行います。クローニングが実行されるセカンダリストレージの場所が自動的に入力されます。
適用するすべてのログバックアップを選択します。
クローニングの前後に実行するオプションのスクリプトを指定します。
E メール通知が必要な場合は、 SMTP サーバを指定します。
DR クローンの概要：クローニングされたデータベースはただちに SnapCenter に登録され、バックアップ保護に使用できます。