1. 高可用性概要およびベスト・プラクティス
  2. Oracle Database Cloudのベスト・プラクティス
  3. Oracle Data Guardハイブリッド・クラウド構成

32 Oracle Data Guardハイブリッド・クラウド構成

ハイブリッドOracle Data Guard構成は、プライマリ・データベースと、一部はオンプレミスにあり一部はクラウドにある1つ以上のスタンバイ・データベースで構成されます。ここで説明するプロセスでは、Oracleゼロ・ダウンタイム移行ツールを使用して、既存のオンプレミス・プライマリ・データベースからクラウド・スタンバイ・データベースを作成します。

ゼロ・ダウンタイム移行は、MAAのベスト・プラクティスを組み込んで、クラウドにスタンバイ・データベースを作成するプロセスを合理化および簡素化します

ここで説明するようにクラウド・スタンバイ・データベースを設定した後、プライマリ・データベースがオンプレミスではなくクラウドで動作するようにロール・トランジションを実行できます。

Oracle CloudでのハイブリッドData Guardの利点

Oracle CloudでハイブリッドData Guard構成を使用する主なメリットは次のとおりです。

  • クラウド・データ・センターとインフラストラクチャはOracleが管理します。

  • スケジュールされたメンテナンスまたは計画外の停止中に、本番をクラウド内のスタンバイ・データベースにスイッチオーバー(計画イベント)またはフェイルオーバー(計画外イベント)できます。障害が発生したオンプレミス・データベースが修復されると、クラウドの現在の本番データベースと同期できます。その後、本番環境をオンプレミス・データベースに切り替えることができます。

  • オンプレミス・デプロイメントと同じOracle MAAベスト・プラクティスを使用します。ハイブリッドData Guardデプロイメントに固有のその他のOracle MAAベスト・プラクティスは、次のトピックで説明しています。MAAプラクティスで構成すると、ハイブリッドData Guard構成によって次のものが提供されます。

    • Data Guardファスト・スタート・フェイルオーバーで構成されている場合の自動フェイルオーバーを使用したリカバリ時間目標(RTO)の秒数
    • ASYNCト転送を使用するData Guardの1秒未満のリカバリ・ポイント目標(RPO)
    • SYNCまたはFAR SYNC構成でのData GuardのゼロのRPO

ノート:

スイッチオーバー、フェイルオーバー、復元などのData Guardライフ・サイクル管理操作は、ハイブリッドData Guard構成の手動プロセスです。

障害時リカバリにExadata Cloudを使用するためのMAAの推奨事項

障害時リカバリのためにExadata Cloudをデプロイする場合、Oracle MAAでは次のことをお薦めします。

  • オンプレミスのプライマリ・データベースと対称または類似のクラウド・データベース・システム・ターゲットを作成して、ロール・トランジション後にパフォーマンスSLAを満たすことができるようにします。たとえば、Oracle RACソースにはOracle RACターゲット、ExadataにはExadataなどを作成します。

  • 既存のネットワーク・トラフィックに加えて、ネットワーク帯域幅でピークREDO率を処理できることを確認します。

    My Oracle SupportドキュメントData GuardおよびRMANのネットワーク・パフォーマンスの評価およびチューニング(ドキュメントID 2064368.1)では、Data GuardおよびRMANのネットワーク・パフォーマンスを評価およびチューニングするための追加のネットワーク帯域幅トラブルシューティング・ガイダンスが提供されます。

  • オンプレミス環境とクラウド環境間のネットワークの信頼性とセキュリティを確保します。

  • 追加の自動ブロック修復、データ保護およびオフロードのために、Oracle Active Data Guardを使用します。

  • プライマリ・データベースとスタンバイ・データベースの両方にOracle Transparent Data Encryption (TDE)を使用します。

    My Oracle SupportドキュメントのOracle CloudでのOracle Database表領域の暗号化動作(ドキュメントID 2359020.1)に、クラウド構成のTDE動作に関する追加の詳細が記載されています。

  • プライマリまたはスタンバイ・ロールで、OCIまたはAzure内のデータベースについてオブジェクト・ストレージまたはAutonomous Recovery Serviceへのバックアップを構成します。Oracle Exadata Database Service on Dedicated Infrastructureでのデータベースのバックアップおよびリカバリの管理およびDatabase Autonomous Recovery Serviceを参照してください。

サービス・レベルの要件

Oracle Data Guardハイブリッド・デプロイメントは、ユーザー管理環境です。特定の構成およびアプリケーションで実用的な可用性、データ保護およびパフォーマンスに対するサービス・レベルの期待値は、ユーザーの要件によって決定する必要があります。

Data Guard構成に適用可能な障害時リカバリに関連する次の各ディメンションについて、サービス・レベルを設定する必要があります。

  • リカバリ時間目標(RTO)は、停止が発生した場合の最大許容停止時間を示します。これには、サービスを再開するために、停止を検出し、データベースおよびアプリケーションの接続をフェイルオーバーするために必要な時間が含まれています。

  • リカバリ・ポイント目標(RPO)は、許容可能なデータ損失の最大量を示します。目的のRPOの達成は、次によって異なります。

    • ネットワーク・ボリュームに関連する使用可能な帯域幅

    • 信頼性が高く、中断のない転送を実現するネットワークの機能

    • 使用されるData Guard転送方法: ほぼゼロのデータ損失保護の場合は非同期、データ損失防止の場合は同期

  • データ保護 - Oracle Active Data GuardおよびMAAを使用して、最も包括的なブロック破損検出、防止および自動修復を構成できます。

  • パフォーマンス - コンピュート、メモリー、I/Oなどの容量がスタンバイ・システムにプロビジョニングされていない場合、データベースのレスポンス時間はフェイルオーバー後に、オンプレミスの本番システムと異なる場合があります。

    これは、管理者が意図的にスタンバイ・リソースを低く構成してコストを削減し、DRモードでサービス・レベルが低下した場合に発生します。MAAのベスト・プラクティスでは、フェイルオーバー後のレスポンス時間に変更がないように、プライマリ・データベース・ホストとスタンバイ・データベース・ホストの両方で対称的に容量を構成することをお薦めしています。

    クラウドで迅速にプロビジョニングできるため、安定した状態でデプロイされる容量が少なくなるという妥協点を容易に実現できますが、フェイルオーバーが必要な場合は、新しいプライマリ・データベース・システムを迅速にスケールアップできます。

ノート:

高速プロビジョニング・アプローチでの安定した状態のリソースの削減により、スタンバイ・データベースをプライマリ・データベースに遅れていないようにするためのリカバリ機能が影響を受け、適用ラグおよび影響のあるRTOが作成される可能性があります。このアプローチは、徹底的なテスト後にのみ考慮する必要があります。

RTOおよびRPOの要件およびその他の考慮事項の決定の詳細は、「高可用性およびデータ保護 - 要件からのアーキテクチャの取得」を参照してください。

「データ破損の検出および監視」を参照してください。

セキュリティ要件および考慮事項

Oracle MAAのベスト・プラクティスでは、Oracle Transparent Data Encryption (TDE)を使用してプライマリ・データベースとスタンバイ・データベースを暗号化し、保存データを暗号化することをお薦めします。

TDEを使用したデータの保護は、システムのセキュリティの向上に不可欠な部分ですが、次のような暗号化ソリューションを使用する場合は、特定の考慮事項に注意する必要があります。

  • 追加のCPUオーバーヘッド - 暗号化では、暗号化および復号化された値を計算するために追加のCPUサイクルが必要です。ただし、TDEは、データベース・キャッシング機能を利用し、Exadata内のハードウェア・アクセラレーションを活用して、オーバーヘッドを最小化するように最適化されています。ほとんどのTDEユーザーは、TDEを有効にした後、本番システムでのパフォーマンスへの影響がほとんどありません。

  • より低いデータ圧縮 - 暗号化されたデータは元のプレーン・テキスト・データに関する情報を表示する必要がないため、圧縮率は低くなります。そのため、TDEで暗号化されたデータに適用される圧縮は圧縮率が低くなります。

    TDE暗号化を使用する場合、REDO転送の圧縮はお薦めしません。ただし、TDEをAdvanced CompressionやHybrid Columnar圧縮などのOracle Database圧縮テクノロジとともに使用する場合は、暗号化が実行される前に圧縮が実行され、圧縮と暗号化の利点の両方が得られます。

  • キー管理 - 暗号化は使用される暗号化キーと同じくらい強力で、暗号化キーが失われると、そのキーで保護されているすべてのデータが失われます。

    いくつかのデータベースで暗号化が有効になっている場合、キーとそのライフ・サイクルを追跡することは比較的簡単です。暗号化されたデータベースの数が増えるにつれて、キーの管理はますます難しくなります。多数の暗号化データベースを管理している場合は、Oracle Key Vaultをオンプレミスで使用してTDEマスター・キーを格納および管理することをお薦めします。

データは移行プロセス中に変換できますが、最も安全なOracle Data Guard環境を提供するために、移行を開始する前にTDEを有効にすることをお薦めします。データ・ファイルやREDOヘッダーなど、TDEで暗号化されていない他のデータベース・ペイロードの処理中の暗号化には、VPN接続またはOracle Net暗号化も必要です。詳細は、My Oracle SupportドキュメントOracle CloudでのOracle Database表領域の暗号化動作(ドキュメントID 2359020.1)を参照してください。

オンプレミス・データベースがTDEでまだ有効になっていない場合は、My Oracle Supportドキュメントの透過的データ暗号化(TDE)のプライマリ・ノート(ドキュメントID 1228046.1)の手順に従い、TDEを有効にしてウォレット・ファイルを作成します。

TDEをオンプレミス・データベースで有効にできない場合は、クラウド・データベースがTDEで暗号化されていてオンプレミス・データベースが暗号化されていないハイブリッド・クラウド・ディザスタ・リカバリ構成でのREDO操作の復号化の詳細について、Oracle Database Advanced SecurityガイドのOracle Data Guard環境での表領域の暗号化を参照してください。

プラットフォーム、データベースおよびネットワークの前提条件

クラウド・スタンバイ・データベースへの移行を確実に成功させるためには、次の要件を満たす必要があります。

要件タイプ オンプレミス要件 Oracle Cloud要件

オペレーティング・システム

Linux、WindowsまたはSolaris X86 (Data Guardクロス・プラットフォーム互換性のためのMy Oracle Supportノート413484.1)

Oracle Enterprise Linux (64ビット)

Oracle Databaseのバージョン*

ゼロ・ダウンタイム移行でサポートされるすべてのOracleリリース*

オンプレミス・ソース・データベースのOracleリリースおよびエディションのサポートの詳細は、移行でサポートされているデータベース・バージョンを参照してください。

Extreme performance / BYOL*

Oracle Cloudのデータベース・サービス・オプションの詳細は、サポートされているデータベース・エディションおよびバージョンを参照してください。

Oracle Databaseアーキテクチャ

Oracle RACまたは単一インスタンス

Oracle RACまたは単一インスタンス

Oracle Multitenant

Oracle 12.1以降では、プライマリ・データベースはマルチテナント・コンテナ・データベース(CDB)である必要があります

マルチテナント・コンテナ・データベース(CDB)または非CDB

物理ホストまたは仮想ホスト

物理または仮想

Exadata仮想

データベース・サイズ

任意のサイズ

任意のサイズ。

形状の制限については、Exadata Cloudのドキュメントを参照してください

TDE暗号化

推奨

クラウド・データベースに必須

*プライマリ・データベースとスタンバイ・データベースでのOracle Databaseリリースは、スタンバイの初期インスタンス化中に同じデータベース・メジャー・リリースおよびデータベース・リリース更新(RU)である必要があります。スタンバイファーストで互換性があるデータベース・ソフトウェア更新の場合、プライマリ・データベースとスタンバイ・データベースのOracleホーム・ソフトウェアは異なっていてもかまいません(たとえば、19RUと19 RU+1)。Oracleクラウドでのスタンバイ・インスタンス化の場合、スタンバイ・データベースのOracle HomeソフトウェアのRUが同じかそれ以降である必要があります。Oracle Patchの保証 - Data Guard Standby-First Patch適用(ドキュメントID 1265700.1)を参照してください。

クラウド・ネットワークの前提条件

オンプレミスからOracle Cloud Infrastructure (OCI)へのデータ転送では、パブリック・ネットワーク、VPNまたはOracle FastConnectが提供する高帯域幅オプション(あるいはそのすべて)が使用されます。

Oracle Data Guard構成では、プライマリ・データベースとスタンバイ・データベースが双方向で通信できる必要があります。これには、システム間のポートへのアクセスを許可するための追加のネットワーク構成が必要です。

ノート:

Oracle Exadata Database Service on Cloud@Customerはオンプレミス・ネットワークにデプロイされているため、ネットワーク接続構成は必要ありません。ExaDB-C@Cを使用する場合は、「オンプレミスの前提条件」にスキップします。

安全な接続

Oracle Exadata Database Service (ExaDB-C@Cには不要)には、仮想クラウド・ネットワークをオンプレミス・ネットワークにプライベート接続するための2つのオプション(FastConnectとIPSec VPN)があります。どちらの方法でも、プライベート仮想クラウド・ネットワーク(VCN)に接続するには、動的ルーティング・ゲートウェイ(DRG)が必要です。

DRGの作成の詳細は、オンプレミス・ネットワークへのアクセスを参照してください。

  • OCI FastConnect - データ・センターとOCI間に専用のプライベート接続を簡単に作成できます。FastConnectは、インターネットベースの接続と比較して、より高い帯域幅オプションおよびより信頼性の高い一貫性のあるネットワーキング・エクスペリエンスを提供します。詳細は、FastConnectの概要を参照してください(リンクhttps://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectoverview.htm)。

  • IPSec VPN - Internet Protocol SecurityまたはIP Security (IPSec)は、パケットがソースから宛先に転送される前にIPトラフィック全体を暗号化するプロトコル・スイートです。OCIのIPSecの概要は、サイト間VPNの概要を参照してください。

パブリック・インターネット接続

OCIとオンプレミス間の接続も、パブリック・インターネットを使用して実現できます。

この方法はデフォルトでは安全ではありません。転送を保護するには、追加の手順を実行する必要があります。ハイブリッドData Guard構成のステップでは、パブリック・インターネット接続を想定しています。

デフォルトでは、ポート1521のクラウド・セキュリティは無効になっています。また、仮想マシン(VM)またはベア・メタル(BM)用のクラウド内のこのデフォルトの事前構成済ポートは、パブリック・インターネットからオープン・アクセスが可能です。

  1. スタンバイ・データベースの仮想クラウド・ネットワーク(VCN)にインターネット・ゲートウェイがない場合は、追加する必要があります。

    インターネット・ゲートウェイを作成するには、インターネット・ゲートウェイを参照してください。

  2. オンプレミス・データベースとの間で接続するには、受信および送信ルールをVCNセキュリティ・リストで構成する必要があります。

    追加情報は、セキュリティ・リストを参照してください。

オンプレミスの前提条件

スタンバイ・データベースをインスタンス化する前に、次の前提条件を満たす必要があります。

oratcptestを使用したネットワークの評価

Oracle Data Guard構成では、プライマリ・データベースとスタンバイ・データベースが両方向で情報を送信します。これには、プライマリ・データベースとスタンバイ・データベースの両方で、基本的な構成、ネットワーク・チューニングおよびポートのオープンが必要です。

プライマリ・データベースのREDO生成率をサポートするために、帯域幅が存在することが重要です。

Data GuardおよびRMANのネットワーク・パフォーマンスの評価およびチューニング(ドキュメントID 2064368.1)の手順に従って、オンプレミス環境とクラウド環境の間のネットワーク・リンクを評価およびチューニングします。

構成

  • 名前解決

    • ExaDB-C@Cの場合、クラスタがオンプレミス・ネットワークに存在するため、オンプレミスDNSは各クラスタを解決する必要があり、それ以上の構成は必要ありません。

    • Oracle Exadata Database Serviceの場合、クラスタ間の名前解決を構成する必要があります。

      これを実行するには、/etc/hostsなどの静的ファイルを使用するか、OCIインスタンスのパブリックIPアドレスを適切に解決するようにオンプレミスDNSを構成します。また、オンプレミス・ファイアウォールでアクセス制御リストを構成して、SSHおよびOracle Netでオンプレミス・システムからOCIへのアクセスを許可する必要があります。

  • DR構成のOracle Data Guardでは、クラウド・インスタンスからオンプレミス・データベースへのアクセスが必要です。プライマリ・データベース・リスナー・ポートは、iptablesなどの機能を使用してクラウドIPアドレスからのアクセスが制限されている状態でオープンする必要があります。

    各企業には異なるネットワーク・セキュリティ・ポリシーがあるため、ネットワーク管理者は、「クラウド・ネットワークの前提条件」に示すクラウド側のネットワーク構成などの操作を実行する必要があります。

  • Oracle Cloudからオンプレミス・マシンへのプロンプトレスSSH。これは、プロビジョニング・プロセス中にオンプレミスからクラウドに対して、およびクラウドからオンプレミスに対して構成されます。

  • クラウドからオンプレミス・マシンへのインバウンドSSH接続を許可するオンプレミス・ファイアウォールの構成。

  • 「oratcptestを使用したネットワークの評価」で前述したネットワーク評価を完了することをお薦めします。適切なTCPソケット・バッファ・サイズの設定は、ASYNC REDO転送に特に重要です。

  • RDBMSソフトウェアは、インスタンス化のために、プライマリ・データベースとスタンバイ・データベースとで同じにすることをお薦めします。現在のオンプレミスのOracle DatabaseリリースをOracle Exadata Database Serviceで使用できない場合、プライマリ・データベースは、メジャー・データベース・リリースが同じであり、リリース更新(RU)が同じかそれ以下である必要があります。

プライマリ・データベースでのMAAベスト・プラクティスのパラメータ設定の実装

Data GuardのほとんどのMAAベスト・プラクティスはここで説明するプロセスの一部です。ただし、このプロセスを開始する前に、プライマリ・データベースでスタンバイREDOログを作成する必要があります。

詳細は、「Oracle Data Guardの構成ベスト・プラクティス」を参照してください。

オンプレミス・ホストとExadataクラウド・ホスト間の接続の検証

ネットワーク・ステップが正常に実装されたら、次のコマンドを実行して、すべてのソースとすべてのターゲット間の接続が両方向で成功したことを確認します。

オンプレミス・ホストで次を実行します。

[root@onpremise1 ~]# telnet TARGET-HOST-IP-ADDRESS PORT
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
^C^]q
telnet> q
Connection closed.

クラウド・ホストで次を実行します。

[root@oci2 ~]# telnet TARGET-HOST-IP-ADDRESS PORT
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
^]q
telnet> q
Connection closed.

telnetが成功した場合は、次の手順に進みます。

ノート:

telnetのかわりにnetcat (nc -zv)を使用できます。

ゼロ・ダウンタイム移行を使用したスタンバイのインスタンス化

ゼロ・ダウンタイム移行環境を準備し、物理移行方法を使用してスタンバイ・データベースをインスタンス化します。

各タスクは、『Zero Downtime Migrationを使用したOracle Cloudへの移行』の最新のゼロ・ダウンタイム移行ドキュメントの手順を参照し、これにはハイブリッドData Guard構成に関する追加情報が含まれています。

Oracle Data Guardハイブリッド・ユースケースでは、ゼロ・ダウンタイム移行をスタンバイ・データベースのインスタンス化と呼ぶこともできます。

スタンバイ・データベースがインスタンス化された後、完全移行ワークフローを完了する前に、移行ジョブが停止し、スタンバイがクラウドに配置されたままになります。ハイブリッドData Guard構成を完了するには、追加の修正が必要です。

タスク1: ゼロ・ダウンタイム移行のインストールおよび構成

ゼロ・ダウンタイム移行アーキテクチャには、プライマリ・データベース・ホストとスタンバイ・データベース・ホストとは別のゼロ・ダウンタイム移行サービス・ホストが含まれています。ゼロ・ダウンタイム移行ソフトウェアは、ゼロ・ダウンタイム移行サービス・ホストにインストールおよび構成されます。

DBCSコンピュート・リソースなどの任意のLinuxサーバーは、要件を満たし、ターゲットおよびソース・データベース・システムによって双方向にアクセス可能な場合に、サービス・ホストとして使用できます。

ホストの構成およびインストール手順については、ゼロ・ダウンタイム移行ソフトウェアの設定を参照してください。

タスク2: 物理データベースのインスタンス化の準備

ハイブリッドData Guard構成プロセスでは、ターゲット・データベースのインスタンス化後に移行ジョブを一時停止するオプションとともに、ゼロ・ダウンタイム移行物理データベースのオンライン移行ワークフローが使用されます。

スタンバイ・データベースがインスタンス化および検証されると、スタンバイ・データベースをそのままにして、移行ジョブを停止できます。

物理的な移行を準備するには、『Zero Downtime Migrationを使用したOracle Cloudへの移行』の物理データベース移行の準備の手順に従います。

次に、ハイブリッドData Guard構成に固有の追加情報を示します。

ソース・データベースでの透過的データ暗号化の構成

ハイブリッドData Guard構成の一部であるスタンバイ・データベースを含め、Oracle Cloudデータベースでは透過的データ暗号化(TDE)が必要です。

オンプレミス・データベースも暗号化することをお薦めしますが、ハイブリッドData Guard構成の一部としてプライマリ・データベースを暗号化しないまま構成することも可能で、Oracle Database 19c (19.16)以降のリリースでは新しいパラメータによってより適切にサポートされます。

Oracle Data Guardを使用するすべてのTDE構成では、暗号化ウォレットをプライマリ・データベースに作成し、マスター・キーを設定する必要があります。

TDE構成に必要なパラメータは、Oracle Databaseリリースによって異なります。値は、Data Guard構成のデータベースごとに異なる場合があります。

  • Oracle Databaseリリース19c (19.16)以降では、TDEを正しく構成するために、パラメータTABLESPACE_ENCRYPTION、WALLET_ROOTおよびTDE_CONFIGURATIONが必要です。
  • 19.16より前のOracle Database 19cリリースでは、パラメータWALLET_ROOT、TDE_CONFIGURATIONおよびENCRYPT_NEW_TABLESPACESを設定します。
  • Oracle Database19cより前のリリースでは、パラメータENCRYPTION_WALLET_LOCATIONおよびENCRYPT_NEW_TABLESPACESを設定します。

ノート:

TABLESPACE_ENCRYPTION=DECRYPT_ONLYパラメータで特に指定されていないかぎり、スタンバイ・データベースでの新しい表領域の暗号化はプライマリのものと同じになります。

次の表では、リンクを使用して、プライマリおよびスタンバイ・データベース・パラメータを設定するためのリファレンスを検索します。

パラメータ 定義 19cより前のすべてのOracle Databaseリリース Oracle Databaseリリース19.15以前 Oracle Databaseリリース19.16以降

ENCRYPTION_WALLET_LOCATION

ウォレットの場所を定義します

sqlnet.oraファイル内のキーストアの場所についてを参照

推奨

非推奨

非推奨

WALLET_ROOTおよびTDE_CONFIGURATION

WALLET_ROOTは、CDB内の各PDBのウォレット・ストレージのディレクトリのルートの場所を設定します。WALLET_ROOTを参照

TDE_CONFIGURATIONは、キーストアのタイプを定義します。たとえば、ウォレット・キーストアの場合はFILEです。キーストア・タイプは、プライマリ・データベースとスタンバイ・データベースで同じ値に設定する必要があります。TDE_CONFIGURATIONを参照

N/A

推奨

推奨

ENCRYPT_NEW_TABLESPACES

プライマリ・データベースの新規表領域を暗号化するかどうかを示します

ENCRYPT_NEW_TABLESPACESパラメータは、次のように設定できます。

  • CLOUD_ONLY - デフォルト設定。作成された新しい表領域は、CREATE TABLESPACE文のENCRYPTION句に別のアルゴリズムが指定されていないかぎり、AES128アルゴリズムで透過的に暗号化されます。オンプレミス・データベースの場合、表領域はCREATE TABLESPACE...ENCRYPTION句が指定されている場合にのみ暗号化されます。
  • ALWAYS - プライマリ・データベース(オンプレミスまたはクラウド)で作成された新しい表領域は、CREATE TABLESPACE ENCRYPTION句で別の暗号化アルゴリズムが指定されていないかぎり、AES128アルゴリズムで透過的に暗号化されます。
  • DDL - CREATE TABLESPACE文に続く暗号化の有無に関係なく表領域を作成でき、暗号化アルゴリズムを変更することもできます。ノート: この値は、Oracle Database 19c (19.16)以降のリリースがあるクラウドのプライマリ・データベースでは表領域の暗号化が強制されるため、適用されません。

ENCRYPT_NEW_TABLESPACESを参照

推奨

推奨

非推奨

TABLESPACE_ENCRYPTIONの推奨設定でオーバーライドします

TABLESPACE_ENCRYPTION (前述のノートを参照)

Oracle Database 19c (19.16)以降のリリース - 新しい表領域を暗号化する必要があるかどうかを示します。使用可能なオプションは、AUTO_ENABLE、MANUAL_ENABLEおよびDECRYPT_ONLYです。

Oracle Database 19c (19.16)以降、Oracle Cloudはクラウド・データベース内のすべての表領域に対して暗号化を強制します。これはオーバーライドできません。

オンプレミス・データベース(プライマリまたはスタンバイ)で暗号化表領域を防止するには、TABLESPACE_ENCRYPTIONパラメータをDECRYPT_ONLYに設定します。

DECRYPT_ONLYは、オンプレミス・データベースでのみ有効です。

TABLESPACE_ENCRYPTIONを参照

N/A

N/A

推奨

TDEを構成するには、Zero Downtime Migrationを使用したOracle Cloudへの移行の透過的データ暗号化ウォレットの設定のステップに従います。

インスタンス化前のTDEマスター・キーの確認

プライマリ・データベースが暗号化されないままの場合でも、TDEをプライマリ・データベースで構成する必要があります。この構成には、暗号化ウォレットの作成およびマスター・キーの設定が含まれています。

プロセス中に、ウォレットがスタンバイ・データベースにコピーされます。ウォレットに格納されたマスター・キーは、スタンバイ・データベースによって暗号化に使用されます。

クラウド・スタンバイ・データベースがプライマリ・データベースになるスイッチオーバーの場合、暗号化されたREDOをクラウド・データベースから復号化するために、暗号化されていないオンプレミス・データベースによってキーが使用されます。

マスター・キーの設定に失敗すると、Data Guard管理のリカバリが失敗します。

マスター・キーが正しく設定されていることを確認するには:

  • V$DATABASE_KEY_INFOのMASTERKEYID列が、ソース・データベースのV$ENCRYPTION_KEYSに存在するキーと一致することを確認します。

    マルチテナント・コンテナ・データベース(CDB)環境で、CDB$ROOT、およびPDB$SEEDを除くすべてのPDBを確認します。

オンラインREDOログの構成

REDOログ・スイッチは、REDO転送および適用のパフォーマンスに大きな影響を与える可能性があります。インスタンス化の前に、プライマリ・データベースのオンラインREDOログのサイズ設定に関する次のベスト・プラクティスに従います。

  • すべてのオンラインREDOログ・グループは、同じサイズのログ(バイト)を持つ必要があります。
  • オンラインREDOログは、高パフォーマンスのディスク(DATAディスク・グループ)に存在する必要があります。
  • Oracle RACインスタンスでREDOのスレッドごとに3つ以上のオンラインREDOログ・グループを作成します。
  • Oracle RAC環境の共有ディスクにオンラインREDOログ・グループを作成します。
  • 高冗長性ディスク・グループに配置されていないかぎり、オンラインREDOログを多重化します(ログ・グループごとに複数のメンバー)。
  • ログ・スイッチが1時間に12回(5分ごと)以下になるようにオンラインREDOログのサイズを設定します。ほとんどの場合、ピーク時のワークロードであっても、15分から20分ごとのログ・スイッチが最適です。
REDOログ・サイズの設定

プライマリ・データベースのピークREDO生成率に基づいてREDOログ・サイズを設定します。

ピーク生成率を確認するには、ピーク時のワークロードを含む期間に次の問合せを実行します。最大速度は、月末、四半期末または年次で確認できます。REDO適用をこれらのワークロード中に一貫して実行するためには、最大速度を処理するようにREDOログ・サイズを設定します。

SQL> SELECT thread#,sequence#,blocks*block_size/1024/1024 MB,
(next_time-first_time)*86400 sec,
 blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s"
 FROM v$archived_log
 WHERE ((next_time-first_time)*86400<>0)
 and first_time between to_date('2015/01/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
 and to_date('2015/01/15 11:00:00','YYYY/MM/DD HH24:MI:SS')
 and dest_id=1 order by first_time;

   THREAD#  SEQUENCE#         MB        SEC       MB/s 
---------- ---------- ---------- ---------- ---------- 
         2       2291 29366.1963        831  35.338383 
         1       2565 29365.6553        781 37.6000708 
         2       2292 29359.3403        537  54.672887 
         1       2566 29407.8296        813 36.1719921 
         2       2293 29389.7012        678 43.3476418 
         2       2294 29325.2217       1236 23.7259075 
         1       2567 11407.3379       2658 4.29169973 
         2       2295 29452.4648        477 61.7452093 
         2       2296 29359.4458        954 30.7751004 
         2       2297 29311.3638        586 50.0193921 
         1       2568 3867.44092       5510 .701894903

次のチャートを使用して、ピーク生成率に基づいてREDOログ・サイズを選択します。

ピークREDO率 推奨REDOログ・サイズ
<= 1 MB/s 1 GB
<= 5 MB/s 4 GB
<= 25 MB/s 16 GB
<= 50 MB/s 32 GB
> 50 MB/s 64 GB

ターゲット・データベースの作成

スタンバイ・データベースになるターゲット・データベースは、最初にOracle Cloudの自動化によって作成されます。このアプローチにより、Oracle Cloudユーザー・インタフェースでデータベースが表示され、パッチ適用などのクラウド自動化のサブセットで使用できるようになります。

ノート:

スイッチオーバー、フェイルオーバー、復元などのOracle Data Guard操作は、Data Guard Brokerで実行される手動操作です。Data Guardライフ・サイクル管理は、ハイブリッドData Guard構成のユーザー・インタフェースではサポートされていません。

データベースが作成されると、ゼロ・ダウンタイム移行ワークフローによって既存のファイルが削除され、スタンバイ・データベースがかわりにインスタンス化されます。

ターゲット・データベースのハイブリッドData Guard構成(ゼロ・ダウンタイム移行と比較)の例外を次に示します。

  • ターゲット・データベースでは、ソース・データベースと同じdb_nameを使用する必要があります。
  • ターゲット・データベースでは、異なるdb_unique_nameを使用する必要があります。

インスタンス化方法の選択

ゼロ・ダウンタイム移行を使用するハイブリッドData Guardスタンバイ・インスタンス化に推奨される2つのオプションは、直接データ転送とオブジェクト・ストレージ・サービスです。

  • 直接データ転送 - DATA_TRANSFER_MEDIUM=DIRECT - RMANを使用して、データ・ファイルをプライマリ・データベースから直接コピーします。
  • オブジェクト・ストレージ・サービス - DATA_TRANSFER_MEDIUM=OSS - OSSバケットへのプライマリ・データベースのバックアップを実行し、バックアップからスタンバイ・データベースをインスタンス化します。

既存のバックアップまたは既存のスタンバイからインスタンス化するための追加オプションがありますが、この手順では対応していません。詳細は、『Zero Downtime Migrationを使用したOracle Cloudへの移行』のデータ・ソースとしての既存のRMANバックアップの使用および既存のスタンバイを使用したターゲット・データベースのインスタンス化を参照してください。

ゼロ・ダウンタイム移行パラメータの設定

次に示すゼロ・ダウンタイム移行の物理移行レスポンス・ファイル・パラメータは、ほとんどの場合に設定される主なパラメータです。

  • TGT_DB_UNIQUE_NAME - クラスタウェアに登録されているターゲット・クラウド・データベースのdb_unique_name (srvctl)

  • MIGRATION_METHOD=ONLINE_PHYSICAL - ハイブリッドData Guardの設定はすべてONLINE_PHYSICALメソッドを使用します

  • DATA_TRANSFER_MEDIUM=DIRECT | OSS - DIRECTは、Oracle 12.1より前のバージョンのソース・データベースではサポートされていません

  • PLATFORM_TYPE=EXACS | EXACC | VMDB - 適切な構成を確保するために、適切なターゲットのOracle Cloudプラットフォームを選択します

  • HOST=cloud-storage-REST-endpoint-URL - OSSデータ転送メディアを使用する場合は必須です

  • OPC_CONTAINER=object-storage-bucket - OSSデータ転送メディアを使用する場合は必須です

  • ZDM_RMAN_COMPRESSION_ALGORITHM=BASIC

  • ZDM_USE_DG_BROKER=TRUE - Data Guard BrokerはMAA構成のベスト・プラクティスです

要塞ホストまたはその他の複雑さが関係する場合は、『Zero Downtime Migrationを使用したOracle Cloudへの移行』の物理移行パラメータの設定を参照してください。

タスク3: スタンバイ・データベースのインスタンス化

準備が完了したら、ゼロ・ダウンタイム移行オンライン物理移行ジョブを実行して、クラウド・スタンバイ・データベースをインスタンス化できます。

実際には、ZDMCLIのゼロ・ダウンタイム移行コマンドを使用して、評価ジョブと実際の移行ジョブの2つのジョブを実行します。

  1. 評価ジョブを実行します。

    評価ジョブでは、トポロジ構成および移行ジョブ設定が分析され、本番データベースに対して実行したときにプロセスが成功することを確認します。

    次に示すように、ZDMCLI migrate databaseコマンドの-evalオプションを使用して、評価ジョブを実行します。 

    zdmuser> $ZDM_HOME/bin/zdmcli migrate database
 -sourcedb source_db_unique_name_value
 -sourcenode source_database_server_name
 -srcauth zdmauth
 -srcarg1 user:source_database_server_login_user_name
 -srcarg2 identity_file:ZDM_installed_user_private_key_file_location
 -srcarg3 sudo_location:/usr/bin/sudo
 -targetnode target_database_server_name
 -backupuser Object_store_login_user_name
 -rsp response_file_location
 -tgtauth zdmauth
 -tgtarg1 user:target_database_server_login_user_name
 -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
 -tgtarg3 sudo_location:/usr/bin/sudo
 -eval

    『Zero Downtime Migrationを使用したOracle Cloudへの移行』の移行ジョブの評価には、評価ジョブ・オプションの例が他にもあります。

    ノート:

    ハイブリッドData Guardクラウド・スタンバイ・インスタンス化プロセスは物理的な移行であるため、クラウド移行前アドバイザ・ツール(CPAT)はサポートされていません。

  2. 移行ジョブを実行します。

    デフォルトでは、ゼロ・ダウンタイム移行で、ターゲット・データベースのインスタンス化直後にスイッチオーバー操作が実行されるため、ZDMCLI migrate databaseコマンドで-stopafterオプションを使用して、スタンバイ・データベースの作成後に移行ジョブを停止します。

    -stopafterオプションを使用して、次に示すようにZDM_CONFIGURE_DG_SRCに設定します。 

    zdmuser> $ZDM_HOME/bin/zdmcli migrate database
 -sourcedb source_db_unique_name_value
 -sourcenode source_database_server_name
 -srcauth zdmauth
 -srcarg1 user:source_database_server_login_user_name
 -srcarg2 identity_file:ZDM_installed_user_private_key_file_location
 -srcarg3 sudo_location:/usr/bin/sudo
 -targetnode target_database_server_name
 -backupuser Object_store_login_user_name
 -rsp response_file_location
 -tgtauth zdmauth
 -tgtarg1 user:target_database_server_login_user_name
 -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
 -tgtarg3 sudo_location:/usr/bin/sudo
 -stopafter ZDM_CONFIGURE_DG_SRC

    データベース移行ジョブが発行されると、コマンド出力にジョブIDが表示されます。後で診断が必要な場合は、この情報を保存します。

    『Zero Downtime Migrationを使用したOracle Cloudへの移行』のデータベースの移行には、ZDMCLI migrate databaseコマンドの使用例が他にもあります。

タスク4: スタンバイ・データベースの検証

スタンバイ・データベースのインスタンス化後にゼロ・ダウンタイム移行ジョブが停止した場合、スタンバイ・データベースを検証します。

Oracle Data Guard Broker構成の確認

ゼロ・ダウンタイム移行レスポンス・ファイルでパラメータZDM_USE_DG_BROKER=TRUEを使用すると、Data Guard Broker構成が作成されます。Oracle Cloudユーザー・インタフェースではオンプレミス・データベースが認識されないため、Data Guard Brokerが、ハイブリッドData Guard構成のライフ・サイクル操作を管理する主要なユーティリティになります。

DGMGRLを使用して、Data Guard Broker構成を検証します。リストされているData Guard Brokerコマンドは、プライマリ・データベースまたはスタンバイ・データベースから実行できます。

DGMGRL> show configuration

Configuration - ZDM_primary db_unique_name

  Protection Mode: MaxPerformance
  Members:
  primary db_unique_name - Primary database
    standby db_unique_name - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 58 seconds ago)

構成ステータスはSUCCESSである必要があります。その他のステータスが表示された場合は、2分間待った後でコマンドを再実行して、ブローカが更新する時間を指定します。問題が解決しない場合は、Oracle Data Guard Brokerのドキュメントを参照して、問題を診断および修正してください。

スタンバイ・データベースの検証

DGMGRLを使用して、スタンバイ・データベースを検証します。

DGMGRL> validate database standby db_unique_name

  Database Role:     Physical standby database
  Primary Database:  primary db_unique_name

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    primary db_unique_name:  On
    standby db_unique_name:  Off  <- see note below

  Managed by Clusterware:
    primary db_unique_name:  YES           
    standby db_unique_name:  YES

ノート:

スタンバイでフラッシュバック・データベースを有効にするステップは、次のステップで対処します。

タスク5: お薦めするMAAのベスト・プラクティスの実装

スタンバイ・インスタンス化の後、より優れたデータ保護と可用性を実現するために、次のOracle MAAのベスト・プラクティスの実装を評価します。

主なベスト・プラクティスを次に示します。Oracle Data GuardのOracle MAAでお薦めするベスト・プラクティスの詳細は、Oracle Data Guard構成のベスト・プラクティスも参照してください。

フラッシュバック・データベースの有効化

フラッシュバック・データベースでは、フェイルオーバー後に古いプライマリ・データベースをスタンバイ・データベースとして復元できます。フラッシュバック・データベースを有効にしない場合、フェイルオーバー後に古いプライマリ・データベースをスタンバイとして再作成する必要があります。フラッシュバック・データベースがまだ有効になっていない場合は、ここで有効にします。

フラッシュバック・データベースを有効にするには、高速リカバリ領域またはRECOディスク・グループに十分な領域およびI/Oスループットがあることを確認し、パフォーマンスへの影響を評価します。

  1. プライマリ・データベースで、次のコマンドを実行して、フラッシュバック・データベースがまだ有効になっていない場合はプライマリでこれを有効にします。

    SQL> alter database flashback on;
Database altered.

  2. スタンバイ・データベースで、フラッシュバック・データベースを有効にするには、まずREDO適用を無効にし、フラッシュバック・データベースを有効にしてから、REDO適用を再度有効にします。

    DGMGRL> edit database standby-database set state=apply-off;
Succeeded.

SQL> alter database flashback on;
Database altered.

DGMGRL> edit database standby-database set state=apply-on;
Succeeded.

CONTROL_FILESパラメータの設定およびスタンバイのデフォルト・オープン・モードの変更

Oracle MAAベスト・プラクティスでは、高い冗長性のディスク・グループに配置されるときに制御ファイルを1つのみ持つことをお薦めします。すべてのOracle Cloud製品で高い冗長性が使用されるため、必要な制御ファイルは1つのみです。

  1. スタンバイ・データベースで、CONTROL_FILESパラメータを編集します。 

    SQL> show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      controlfile-1
                                                 , controlfile-2

SQL> ALTER SYSTEM SET control_files='controlfile-1' scope=spfile sid='*';
System altered.

  2. oracleユーザーとしてデータベースを停止し、gridユーザーとして余分な制御ファイルを削除します(opcユーザーからgridユーザーへのsu)。 

    $ srvctl stop database -db standby-unique-name
[grid@standby-host1 ~]$ asmcmd rm controlfile-2

  3. データベースが停止している間に、スタンバイ・データベースのデフォルトが読取り専用でオープンされるように起動オプションを変更し、データベースを起動します。

    $ srvctl modify database -db standby-unique-name -startoption 'read only'
$ srvctl start database -db standby-unique-name

ノート:

Oracle MAAベスト・プラクティスは、自動ブロック・メディア・リカバリを有効化するためにスタンバイを読取り専用でオープンすることですが、Oracle Cloudはマウントされたスタンバイをサポートします。マウントされたスタンバイがユーザーの優先構成の場合は、構成できます。

代替ローカル・アーカイブ・ログの場所の設定

リカバリ領域で領域が消費されると、プライマリ・データベースはアーカイブを停止し、オンラインREDOログをアーカイブするための領域が使用可能になるまですべての操作が停止します。

このシナリオを回避するには、DATAディスク・グループに代替のローカル・アーカイブの場所を作成します。

  1. LOG_ARCHIVE_DEST_10を設定してDATAディスク・グループを使用し、状態をALTERNATEに設定します。 

    SQL> ALTER SYSTEM SET log_archive_dest_10='LOCATION=+DATAC1
 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1
 REOPEN=5 DB_UNIQUE_NAME=standby-unique-name
 ALTERNATE=LOG_ARCHIVE_DEST_1' scope=both sid=’*’;

SQL> ALTER SYSTEM SET log_archive_dest_state_10=ALTERNATE scope=both sid=’*’;

  2. LOG_ARCHIVE_DEST_10を代替として使用するようにLOG_ARCHIVE_DEST_1を設定します。 

    SQL> ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1
 REOPEN=5 DB_UNIQUE_NAME=standby-unique-name
 ALTERNATE=LOG_ARCHIVE_DEST_10' scope=both sid=’*’;

ノート:

バックアップが構成されていない場合、デフォルトでは24時間より古いアーカイブ・ログは30分ごとにスイープされます。

データ保護パラメータの設定

MAAのベスト・プラクティスの推奨事項には、プライマリ・データベースとスタンバイ・データベースに関する次の設定が含まれています。

db_block_checksum=TYPICAL

db_lost_write_protect=TYPICAL

db_block_checking=MEDIUM

SQL> show parameter db_block_checksum

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_checksum                    string      TYPICAL

SQL> alter system set db_block_checksum=TYPICAL scope=both sid='*';

SQL> show parameter db_lost_write_protect

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_lost_write_protect                string      typical

SQL> alter system set db_lost_write_protect=TYPICAL scope=both sid='*';

SQL> show parameter db_block_checking

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_checking                    string      OFF

SQL> alter system set db_block_checking=MEDIUM scope=both sid='*';

db_block_checking設定は、プライマリ・データベースのパフォーマンスに影響するため、本番と同様のより低い環境で本番ワークロードを使用して十分にテストする必要があります。

パフォーマンスへの影響がプライマリ・データベースで許容できないと判断された場合、両方のデータベースに対してスタンバイ・データベースではdb_block_checking=MEDIUMを設定し、cloudautomation Data Guard Brokerプロパティを'1'に設定して、ロール・トランジション後に値が適切に変更されるようにする必要があります。 

DGMGRL> edit database primary-unique-name set property cloudautomation=1;
Property "cloudautomation" updated

DGMGRL> edit database standby-unique-name set property cloudautomation=1;
Property "cloudautomation" updated

両方のデータベースでcloudautomationプロパティが正しく動作するように設定する必要があることに注意してください。

REDO転送の構成 - Oracle Net暗号化

プレーン・テキストまたは暗号化されていない表領域のREDOがWANに表示されないようにするには、すべてのオンプレミス・データベースおよびクラウド・データベースのsqlnet.oraファイルに次のエントリを配置します。

クラウド・デプロイメントでは、TNS_ADMIN変数を使用して、共有データベース・ホームでtnsnames.oraとsqlnet.oraを分けます。したがって、特定のデータベースのクラウドsqlnet.oraおよび拡張tnsnames.oraは、$ORACLE_HOME/network/admin/db_nameにあります。

これらの値は、クラウド構成のデプロイメント・ツールによってすでに設定されている必要があります。

SQLNET.ORA ON ON-PREMISES HOST(S)
SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA1)
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)

ノート:

すべての表領域およびデータ・ファイルがTDEで暗号化されている場合、Oracle Net暗号化は冗長であり、省略できます。

REDO転送の構成 - 完全接続記述子を使用したREDO転送の再構成

わかりやすくするために、ゼロ・ダウンタイム移行ではEZconnect識別子を使用してOracle Data Guard REDO転送を設定します。

完全なゼロ・ダウンタイム移行ワークフローを使用する構成など、短期間の構成の場合、このソリューションは許容可能です。ただし、ハイブリッドData Guard構成の場合、MAAのベスト・プラクティスの推奨事項は、tnsnames.oraで構成された完全接続記述子を使用することです。

次の例を使用して、属性値を構成に関連する値に置き換えます。

データベースのTNS記述子は、SCANリスナーが他のシステムから解決可能かどうかによって異なります。

次の説明は、SCAN名が解決可能であり、TNS記述子で使用できることを前提としています。SCAN名を解決できない場合は、ADDRESS_LISTを使用できます。詳細は、tnsnames.oraの複数のアドレス・リストを参照してください。

適切な置換を行った後に、プライマリおよびスタンバイ・データベース・システムの共有tnsnames.oraファイルに次の記述子を追加します。

standby-db_unique_name =
    (DESCRIPTION=
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= standby-cluster-scan-name )
        (PORT=standby-database-listener-port))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= standby-database-service-name)))
primary-db_unique_name=
    (DESCRIPTION=
      (ADDRESS=
        (PROTOCOL=TCP)
        (HOST=primary-cluster-scan-name)
        (PORT=primary-database-listener-port))
      (CONNECT_DATA=
        (SERVER=DEDICATED)
        (SERVICE_NAME=primary-database-service-name)
    ))

ノート:

プライマリdb_unique_nameの名前を持つ記述子は、クラウド自動化またはゼロ・ダウンタイム移行によって作成されている可能性があります。このエントリは間違ったデータベースを指しているため、置き換えます。

REDO転送の構成 - REDO転送のData Guard Broker設定の変更

ゼロ・ダウンタイム移行ワークフロー中に設定されたEZconnect識別子を変更して、各データベースのtnsnames.oraファイルに追加された接続記述子を使用します。

DGMGRL> show database primary-db_unique_name DGConnectIdentifier
DGConnectIdentifier = 'ZDM-created-EZconnect-string>'
DGMGRL> edit database primary-db_unique_name
         set property DGConnectIdentifier=’primary-db_unique_name’;
DGMGRL> show database standby-db_unique_name DGConnectIdentifier
DGConnectIdentifier = 'ZDM-created-EZconnect-string'
DGMGRL> edit database standby-db_unique_name
         set property DGConnectIdentifier=’standby-db_unique_name’;

スタンバイ自動ワークロード・リポジトリの構成

スタンバイ自動ワークロード・リポジトリ(AWR)を使用すると、スタンバイに対してAWRレポートを生成できます。これらのレポートは、スタンバイ・データベースでのREDO適用およびその他のパフォーマンスの問題を診断する際に非常に重要です。

すべてのOracle Data Guard構成に対してスタンバイAWRを構成することをお薦めします。

詳細は、My Oracle SupportノートActive Data Guardスタンバイ・データベースでAWRを生成する方法(ドキュメントID 2409808.1)を参照してください。

バックアップの構成

オプションで、Autonomous Recovery Serviceまたはオブジェクト・ストレージを使用してプライマリまたはスタンバイ・ロール用のOracleクラウド・データベースの自動バックアップを構成します。

Autonomous Recovery Serviceを使用すると、次のメリットがある他、バックアップ処理およびストレージをオフロードできます:

  • バックアップ・インフラストラクチャへの依存を大幅に削減
  • サポートされているすべてのOCIデータベース・サービスについての一元化されたバックアップ管理戦略の開発
  • リカバリ・サービスによるバックアップを最長で95日間保持
  • リアルタイム・データ保護機能を活用してデータ損失を排除
  • 本番データベースのバックアップ処理のオーバーヘッドを大幅に削減
  • 各仮想クラウド・ネットワーク(VCN)でのリカバリ・サービス操作のための専用ネットワークの実装
  • バックアップ検証を自動化してリカバリ可能性を確保
  • ポリシー主導のバックアップ・ライフサイクル管理の実装

詳細は、Oracle Exadata Database Service on Dedicated Infrastructureでのデータベースのバックアップおよびリカバリの管理およびDatabase Autonomous Recovery Serviceを参照してください。

ヘルス・チェックおよび監視

スタンバイ・データベースをインスタンス化した後、ヘルス・チェックを実行して、Oracle Data Guardデータベース(プライマリおよびスタンバイ)がOracle MAAのベスト・プラクティスに準拠していることを確認する必要があります。

また、ヘルス・チェックは毎月、データベース・メンテナンスの前後に実行することをお薦めします。Data Guard構成のヘルスをチェックするには、Oracle Autonomous Health FrameworkおよびOraChkまたはExaChkを使用したOracle MAAスコアカードを含む自動ツールをお薦めします。Oracle Autonomous Health Frameworkユーザーズ・ガイドおよびOracle ORAchkおよびOracle EXAchkのドキュメントを参照してください。

Oracle Data Guard構成の定期的な監視は、ハイブリッドData Guard構成では提供されないため、手動で実行する必要があります。詳細は、「Oracle Data Guard構成の監視」を参照してください。