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

ハイブリッドOracle Data Guard構成は、プライマリ・データベースと、一部はオンプレミスにあり一部はOracle OCIクラウドまたはOracleマルチクラウド(Oracle@Azure、Oracle@Google、Oracle@AWSなど)にある1つ以上のスタンバイ・データベースで構成されます。

Oracleクラウドという用語は今後、Oracle OCIとOracleマルチクラウドの両方を指すことに注意してください。

このトピックで説明するプロセスでは、Oracle Database as a Service (DBaaS)ツールを使用して、既存のオンプレミス・プライマリ・データベースからクラウド・スタンバイ・データベースを作成します。Oracle DBaaSツールは、MAAのベスト・プラクティスを組み込んで、Oracle Cloudにスタンバイ・データベースを作成するプロセスを合理化および簡素化します。

ここで説明するようにクラウド・スタンバイ・データベースを設定した後、プライマリ・データベースがオンプレミスではなくクラウドで稼働し、dbaascliコマンドを使用してOracle Data Guardのライフサイクル操作(スイッチオーバー、フェイルオーバーおよび回復)を使用できるように、ロール・トランジションを実行できます。

ノート:

オンプレミスにスタンバイ・データベースが存在する場合は、構成中に追加の手動ステップが必要になることがあります。

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

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

  • Oracle Cloud Infrastructureデータ・センターを使用して、障害時リカバリやその他の目的でオンプレミスのデータ・センターのフットプリントを補完する柔軟性を備えています

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

  • スケジュールされたメンテナンスまたは計画外の停止中に、本番をクラウド内のスタンバイ・データベースにスイッチオーバー(計画イベント)またはフェイルオーバー(計画外イベント)できます。

    障害が発生したオンプレミス・データベースが修復されると、クラウドの現在の本番データベースと同期できます。その後、必要に応じて、本番環境をオンプレミス・データベースに再度切り替えることができます。

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

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

障害時リカバリに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動作に関する追加の詳細が記載されています。

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

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

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

TDEを使用したデータの保護は、システムのセキュリティの向上に不可欠です。TDEを評価する際に考慮する必要がある次の変数に注意してください。

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

  • より低いデータ圧縮 - 暗号化されたデータは非暗号化データより効率的に圧縮されないため、TDEで暗号化されたデータに適用された圧縮は圧縮率が低くなります。TDE暗号化を使用する場合、REDO内のデータはすでに暗号化されているため、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のバージョン*

Extreme performance / BYOL*

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

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へのデータ転送では、パブリック・ネットワーク、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クラウド・ホスト間の接続の検証

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

  1. オンプレミス環境のすべてのノードで、oracle OSユーザーとしてcurlを使用して、すべてのオンプレミス・ノードとすべてのクラウド・ノード間の接続をテストします。 

    [oracle@on-prem1]$ curl -v telnet://<FQDN-CLOUD-HOST1>:22 (or other available port)
* Rebuilt URL to: telnet://<FQDN-CLOUD-HOST1>:22/
*   Trying <CLOUD-HOST1-IP>...
* TCP_NODELAY set
* Connected to <FQDN-CLOUD-HOST1> (<CLOUD-HOST1-IP>) port 22 (#0)
SSH-2.0-OpenSSH_8.0
^C
[oracle@on-prem1]$

  2. クラウド環境のすべてのノードで、oracle OSユーザーとしてcurlを使用して、すべてのクラウド・ノードとすべてのオンプレミス・ノード間の接続をテストします。 

    [oracle@cloud-exadata1]$ curl -v telnet://<FQDN-ON-PREM-HOST1>:22 (or other available port)
* Rebuilt URL to: telnet://<FQDN-CLOUD-HOST1>:22/
*   Trying <ON-PREM-HOST1-IP>...
* TCP_NODELAY set
* Connected to <FQDN-ON-PREM-HOST1> (<ON-PREM-HOST1-IP>) port 22 (#0)
SSH-2.0-OpenSSH_8.0
^C
[oracle@cloud-exadata1]$

curl接続が成功した場合は、次のステップに進みます。

ノート:

接続に成功すると「Connected to <FQDN-HOST1> (<HOST-IP>) port 22」というメッセージが表示される一方、接続に失敗すると「Failed to connect to <FQDN-HOST1> port 22: Connection refused」というメッセージが表示されます。

プライマリ・データベース環境の準備

ハイブリッドData Guard構成プロセスでは、Oracle Cloud DBaaSツールと自動化を使用して、スタンバイ・データベースの作成に使用されるプロセスが、Oracle Cloudで使用されるプロセスと同じであることを保証します。

これにより、クラウド・データベースがクラウド・ユーザー・インタフェースに表示されるようになります。

オンプレミス・データベースはクラウドで作成されたデータベースではないため、正常に完了するにはいくつかのステップが必要です。

ACFSマウント・ポイントの作成

ハイブリッドData Guard構成では、インスタンス間でファイルを共有するためのACFSマウント・ポイント(tnsnames.oraやTDEウォレットなど)が必要です。

このマウント・ポイントは、/var/opt/oracle/dbaas_acfsのクラウド・プラットフォームに存在します。プライマリ・クラスタに既存のACFSマウント・ポイントがない場合は、「Oracle ACFSファイル・システムの作成」のステップを使用して作成します。(既存のACFSマウント・ポイントを使用できます)

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

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

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

Oracle Data Guardを使用するすべてのTDE構成では、暗号化ウォレットをプライマリ・データベースに作成し、プライマリ・データベースを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 ウォレットの場所を定義します 推奨 非推奨 非推奨
WALLET_ROOTおよびTDE_CONFIGURATION

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

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

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)以降のリリースがあるクラウドのプライマリ・データベースでは表領域の暗号化が強制されるため、適用されません。
推奨 推奨

非推奨

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は、オンプレミス・データベースでのみ有効です。

N/A N/A 推奨

TDEウォレットを使用して透過的データ暗号化を構成するには、ウォレットベースの透過的データ暗号化の設定ガイドの手順に従います。

インスタンス化前の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ログのサイズを設定します。
REDOログのサイズ設定

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

ピーク生成率を確認するには、ピーク時のワークロードを含む期間に次の問合せを実行します。

最大速度は、月末、四半期末または年次で確認できます。前述のガイダンスを使用して、REDO適用をこれらのワークロード中に一貫して実行するために、最大速度+10%を処理するように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 500 MB
<= 5 MB/s 1 GB
<= 25 MB/s 8 GB
<= 50 MB/s 16 GB
> 50 MB/s 32 GB
フラッシュバック・データベースの有効化

フラッシュバック・データベースでは、フェイルオーバー後に古いプライマリ・データベースをスタンバイ・データベースとして復元できます。

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

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

オンプレミス環境の最初のノードでoracle OSユーザーとして、次のコマンドを実行してプライマリでフラッシュバック・データベースがまだ有効になっていない場合は有効にします。 

[oracle@on-prem1]$ echo "alter database flashback on;" | sqlplus -SILENT "/ as sysdba"

Database altered.
ログ内のエラーの調査(TFA)

オンプレミス環境の最初のノードでroot OSユーザーとして、Oracle Trace File Analyzerを使用してクラスタ全体のすべてのログを分析し、直近のデータベース・エラーを特定します。

イベント・サマリーでは、データベース・ステータスがリアルタイムでレポートされます。

[root@on-prem1]# tfactl events -component RDBMS -database [DBname] -last 7d


Output from host : on-prem1
------------------------------

Event Summary:
INFO    :0
ERROR   :0
WARNING :0

Event Timeline:
No Events Found


Output from host : on-prem2
------------------------------

Event Summary:
INFO    :0
ERROR   :0
WARNING :0

Event Timeline:
No Events Found

ノート:

結果を確認し、障害があれば調査してから先に進みます。詳細は、Oracle Database診断データの収集および分析を参照してください。

Oracle DBaaSツールを使用したスタンバイのインスタンス化

DBaaSツールのprepareForStandbyおよびconfigureStandbyワークフローを使用し、オンプレミス環境を準備してスタンバイ・データベースをインスタンス化します。

タスク1: オンプレミス環境でのDBaaSCAのインストール

  1. oracle OSユーザーとして、/var/opt/oracle/dbaastools/dbaasca.zipアーティファクトをクラウド環境からオンプレミス環境の最初のノードにコピーします。

    ノート:

    このプロセスが実行されるたびに、新しいバージョンのdbaascaをダウンロードする必要があります。 

    [oracle@on-prem1]$ scp 
<cloud-exadata1>@/var/opt/oracle/dbaastools/dbaasca.zip /tmp

  2. オンプレミス環境の最初のノードでroot OSユーザーとして、dbaascaディレクトリを作成します。 

    [root@on-prem1]# mkdir -p /var/opt/oracle/dbaastools/dbaasca

[root@on-prem1]# chown -R oracle:oinstall /var/opt/oracle

  3. オンプレミス環境の最初のノードでoracle OSユーザーとして、dbaasca.zipファイルを/var/opt/oracle/dbaastools/dbaascaに解凍します。 

    [oracle@on-prem1]$ unzip -q
 /tmp/dbaasca.zip -d /var/opt/oracle/dbaastools/dbaasca

タスク2: スタンバイ・データベースのインスタンス化のためのクラウド環境の準備

スタンバイ・データベースのターゲットORACLE_HOMEは、スタンバイ・システムにすでに存在している必要があります。まだ存在していない場合は、次のステップを使用してホームを作成します。

スタンバイ・データベースのホームは、同じバージョン、RUにして、個別パッチを含めることをお薦めします。同じRUを入手できない場合は、同じメジャー・バージョンのより新しいRUを使用できます。

スタンバイ・データベース用のOracleホームをインストールするには:

  1. オンプレミス環境の最初のノードでoracle OSユーザーとして、opatchを使用してデータベース・リリースをリストします。 

    [oracle@on-prem1]$ $ORACLE_HOME/OPatch/opatch lspatches | grep 'Database Release Update'

36912597;Database Release Update : 19.25.0.0.241015 (36912597)

  2. クラウド環境の最初のノードでroot OSユーザーとして、dbaascliを使用してオンプレミスのリリースと一致する使用可能なイメージをリストします。 

    [root@cloud-exadata1 ~]# dbaascli cswLib showImages | grep -A 1 '19.25'

2.IMAGE_TAG=19.25.0.0.0
  VERSION=19.25.0.0.0
  DESCRIPTION=19c OCT 2024 DB Image

  3. クラウド環境の最初のノードでroot OSユーザーとして、dbaascliを使用してオンプレミスのリリースと一致する使用可能なイメージをダウンロードします。 

    [root@cloud-exadata1 ~]# dbaascli cswlib download --version 19.25.0.0.0
...
dbaascli execution completed

  4. クラウド環境の最初のノードでroot OSユーザーとして、dbaascliを使用してオンプレミスのリリースと一致するターゲットORACLE_HOMEを作成します。 

    [root@cloud-exadata ~]# dbaascli dbHome create --version 19.25.0.0.0

-----------------
Running Plugin_initialization job
...
---------- START OF PLUGIN RESULT ----------
{"ORACLE_HOME_NAME":"OraHome4","ORACLE_HOME":"/u02/app/oracle/product/19.0.0.0/dbhome_3"}
---------- END OF PLUGIN RESULT ----------

dbaascli execution completed

ノート:

ORACLE_HOME_NAMEを書き留めておきます。移行に必要になります。

クラウド・システム上のOracleホームは、OCIユーザー・インタフェースを使用して作成することもできます。

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

準備が完了したら、Oracle DBaaSツールのprepareForStandbyおよびconfigureStandbyワークフローを実行して、クラウド・スタンバイ・データベースをインスタンス化できます。

実際には、Oracle DBaaSツールを使用して2つのジョブを実行します:

  • オンプレミス環境でdbaasca操作prepareForStandbyを実行します。
  • クラウド環境でdbaascli操作configureStandbyを実行します。
ACFSの構成

オンプレミス環境の最初のノードでroot OSユーザーとして、prepareForStandbyの実行に必要なACFSマウント・ポイントを作成します。

[root@on-prem1]# $(grep ^crs_home /etc/oracle/olr.loc |
 cut -d= -f2)/bin/crsctl stat res -w "TYPE == ora.acfs.type" |grep NAME
NAME=ora.datac1.acfsvol01.acfs

[root@on-prem1]# $(grep ^crs_home /etc/oracle/olr.loc |
 cut -d= -f2)/bin/crsctl stat res ora.datac1.acfsvol01.acfs -f |grep ^MOUNTPOINT_PATH
MOUNTPOINT_PATH=/acfs01

Create a directory for the dbname (oradb1 for this example):

[root@on-prem1]# mkdir /acfs01/oradb1
[root@on-prem1]# chown oracle:oinstall /acfs01/oradb1
オンプレミス環境でのdbaasca操作prepareForStandbyの実行

これで、プロセスを開始する準備が整いました。まず、プライマリ・データベースをData Guard構成の一部になるように準備します。ワークフローに渡される次の情報を収集します。

  1. クラウド環境の最初のノードでroot OSユーザーとして、dbaascaの実行に必要なstandbyScanNameおよびstandbyScanPortを収集します。 

    [root@cloud-exadata1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d=
 -f2)/bin/srvctl config scan |grep 'SCAN name:' | awk '{print $3}'
cloud-exadata-scan.clientnet.default.oraclevcn.com,

[root@cloud-exadata1 ~]# dbaascli grid getDetails | grep scanListenerTCPPorts |
 cut -d "[" -f2 | cut -d "]" -f1
 1521 

    ワークフローに渡されるこれらの情報を書き留めておきます。

  2. オンプレミス環境の最初のノードでoracle OSユーザーとして、dbaascaの実行に必要なプライマリ・データベースの一意の名前を収集します。 

    [oracle@on-prem1]$ echo "select DB_UNIQUE_NAME from v\$database;" |
 sqlplus -SILENT "/ as sysdba"

DB_UNIQUE_NAME
------------------------------
oradb1_onprem

  3. オンプレミス環境の最初のノードでoracle OSユーザーとして、オンプレミス・データベースのOracleホームを指す環境変数ORACLE_HOMEを設定します。 

    [oracle@on-prem1]$ srvctl config database -home
oradb1     /u01/app/oracle/product/19.0.0.0/dbhome_1       19.0.0.0.0

[oracle@on-prem1]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1

  4. 収集した情報を使用して、適切に置き換えてprepareForStandbyワークフローを実行します。

    オンプレミス環境の最初のノードでoracle OSユーザーとして、対応する引数を指定してdbaasca操作prepareForStandbyを実行します。 

    [oracle@on-prem1]$ 

/var/opt/oracle/dbaastools/dbaasca/bin/dbca \
-silent \
-oui_internal \
-configureDatabase \
-prepareForStandby \
-dgTNSNamesoraFilePath /acfs01/oradb1 \
-sourceDB oradb1_onprem \
-standbyDBUniqueName oradb1_cloud \
-standbyScanName cloud-exadata-scan.clientnet.default.oraclevcn.com \
-standbyScanPort 1521 \
-standbyDBDomain clientnet.default.oraclevcn.com \
-blobFileLocation /tmp 

SYS_PASSWORD_PROMPT
<ENTER_SYS_PASSWORD>

Session ID of the current execution is: 53
-----------------
Running Create_dg_services job
Completed Create_dg_services job
25% complete
-----------------
Running Update_tnsnames_ora_file job
Completed Update_tnsnames_ora_file job
50% complete
-----------------
Running Update_ifile_entry job
Completed Update_ifile_entry job
75% complete
-----------------
Running Prepare_blob_file job
Completed Prepare_blob_file job
100% complete
---------- PLUGIN NOTES ----------
Successfully created blob file: /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar
---------- END OF PLUGIN NOTES ----------
Look at the log file
 "/u01/app/oracle/cfgtoollogs/dbca/oradb1_onprem/oradb1_onprem.log"
 for further details.

    ワークフローにより、スタンバイ・データベースのインスタンス化に必要なファイルを含むzipファイルが作成されます。たとえば、tnsnames.ora、TDEウォレットなどです。このtarファイルは、コマンドの出力にリストされ、スタンバイ・システムの場所にコピーする必要があります。

  5. オンプレミス環境の最初のノードでoracle OSユーザーとして、生成されたBLOBファイルをクラウド環境の最初のノードにコピーします。 

    [oracle@on-prem1]$ scp
 /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar opc@cloud-exadata1:/tmp
クラウド環境でのdbaascli操作configureStandbyの実行

  1. まず、configureStandbyワークフローに渡す必要がある情報を収集します。

    オンプレミス環境の最初のノードでoracle OSユーザーとして、dbaascliの実行に必要なprimaryScanIPAddresses、primaryScanPortおよびprimaryServiceNameを収集します。
    [oracle@on-prem1]$ $(grep ^crs_home /etc/oracle/olr.loc |
 cut -d= -f2)/bin/srvctl config scan |grep 'SCAN name:' | awk '{print $3}'
maafra2vm01-oe6ab-scan.clientnet.maafradefault.oraclevcn.com

[oracle@on-prem1]$ srvctl config scan_listener -scannumber 1 |grep Endpoints
Endpoints: TCP:1521/TCPS:2484

[oracle@on-prem1]$ lsnrctl status | grep oradb1_onprem | cut -d'"' -f 2
oradb1_onprem.clientnet.maafradefault.oraclevcn.com

  2. クラウド環境の最初のノードでroot OSユーザーとして、対応する引数を指定してdbaascli操作configureStandbyを実行します。 

    [root@cloud-exadata1]# 

dbaascli dataguard configureStandby \
--dbname oradb1 \
--oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_3 \
--standbyDBUniqueName oradb1_cloud \
--primaryScanIPAddresses companyxyz.region.com \
--primaryScanPort 1521 \
--primaryServiceName oradb1_onprem.companyxyz.region.com \
--protectionMode MAX_PERFORMANCE \
--transportType ASYNC \
--activeDG true \
--standbyScanIPAddresses cloud-exadata-scan.clientnet.default.oraclevcn.com \
--standbyScanPort 1521 \
--standbyBlobFromPrimary /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar


Enter PRIMARY_DB_SYS_PASSWORD:
<ENTER_PRIMARY_DB_SYS_PASSWORD>
Enter PRIMARY_DB_TDE_PASSWORD:
<ENTER_PRIMARY_DB_SYS_PASSWORD>
Enter AWR_ADMIN_PASSWORD:
<ENTER_AWR_ADMIN_PASSWORD>
Enter AWR_ADMIN_PASSWORD (reconfirmation):
<ENTER_AWR_ADMIN_PASSWORD>

Loading PILOT...
Session ID of the current execution is: 10015
Log file location:
 /var/opt/oracle/log/oradb1/dataguard/configureStandby/pilot_2024-11-21_11-28-21-AM_270773
-----------------
Running Plugin_initialization job
Enter PRIMARY_DB_SYS_PASSWORD
*******************
Enter PRIMARY_DB_TDE_PASSWORD
******************
Enter AWR_ADMIN_PASSWORD
********************
Completed Plugin_initialization job
-----------------
Running Validate_plugin_inputs job
Completed Validate_plugin_inputs job
-----------------
Running Default_database_values_initialization job
Completed Default_database_values_initialization job
-----------------
...
-----------------
Running Generate_dgconfig_details job
Acquiring native write lock: global_dgsystem_details_generation
Releasing native lock: global_dgsystem_details_generation
Completed Generate_dgconfig_details job
Releasing lock: oradb1
Releasing lock: _u02_app_oracle_product_19.0.0.0_dbhome_3
-----------------
Running Cleanup job
Completed Cleanup job

dbaascli execution completed

    ノート:

    Oracle MAAベスト・プラクティスは、自動ブロック・メディア・リカバリを有効にするためにスタンバイを読取り専用でオープンすることです。フラグ--activeDG trueを使用します

  3. クラウド環境の最初のノードでroot OSユーザーとして、次のコマンドを実行してdbaascli操作configureStandbyの進捗状況をモニタリングします。 

    [root@cloud-exadata1]# export dbName=oradb1
[root@cloud-exadata1]# export dbUniqueName=oradb1_cloud

[root@cloud-exadata1]# tail -20f `ls -t
 /var/opt/oracle/log/$dbName/dataguard/configureStandby/pilot_* | head -1`

FINE: [2024-11-21 11:43:38.908 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 -----------------
FINE: [2024-11-21 11:43:38.910 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 Running Open_pdbs job
FINE: [2024-11-21 11:43:42.661 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 Completed Open_pdbs job
FINE: [2024-11-21 11:43:42.668 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 90% complete
FINE: [2024-11-21 11:43:42.692 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 -----------------
FINE: [2024-11-21 11:43:42.697 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
 Running Create_services job

[root@cloud-exadata1]# tail -20f `ls -t
 /var/opt/oracle/log/$dbName/dataguard/configureStandby/$dbUniqueName/trace* | head -1`

[pool-3-thread-4] [ 2024-11-21 12:03:55.015 UTC ] [CRSCache.getAttributesFromCRS:155]
  CRS: name: ora.oradb1_cloud.oradb1_oradb1p3.paas.oracle.com.svc, type 1, node: null
[pool-3-thread-4] [ 2024-11-21 12:03:55.015 UTC ] [CRSCache.getAttributesFromCRS:156]
  attrs: [GLOBAL]
[pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSCache.getAttributesFromCRS:163]
  CRS: [<GLOBAL:false>]
[pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:668]
  [MAJOR EVENT] About to start resource:
 Name: ora.oradb1_cloud.oradb1_oradb1p3.paas.oracle.com.svc, force:false node: null,
 options: 0, filter null
[pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:678]
  filter = null
[pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:679]
  node name = null

[root@cloud-exadata1]# tail -20f /u01/app/grid/diag/crs/`hostname`/crs/trace/alert.log 

2024-11-21 12:13:59.362 [CRSD(398369)]
 CRS-2772: Server 'maafra3vm02-qbi0z1' has been assigned to pool
 'ora.oradb1_oradb1_oradb1p3_ro.paas.oracle.com'.
2024-11-21 12:13:59.363 [CRSD(398369)]
 CRS-2772: Server 'maafra3vm02-qbi0z2' has been assigned to pool
 'ora.oradb1_oradb1_oradb1p3_ro.paas.oracle.com'.
2024-11-21 12:14:00.420 [CRSD(398369)]
 CRS-2772: Server 'maafra3vm02-qbi0z1' has been assigned to pool
 'ora.oradb1_oradb1_oradb1p4.paas.oracle.com'.
2024-11-21 12:14:00.421 [CRSD(398369)]
 CRS-2772: Server 'maafra3vm02-qbi0z2' has been assigned to pool
 'ora.oradb1_oradb1_oradb1p4.paas.oracle.com'.

ノート:

このプロセスが完了したら、dbaascaおよびzipファイルをオンプレミス・システムから削除します。

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

  1. クラウド環境の最初のノードでroot OSユーザーとして、Oracleデータベース構成を確認します。 

    [root@cloud-exadata1]# dbaascli database getDetails --dbname oradb1 |
 egrep 'dbName|dbRole|dbType|patchVersion'
  "dbName" : "oradb1",
  "dbRole" : "PHYSICAL_STANDBY",
  "dbType" : "RAC",
  "patchVersion" : "19.25.0.0.0",
      "pdbName" : "ORADB1P1",
      "pdbName" : "ORADB1P2",
      "pdbName" : "ORADB1P3",
      "pdbName" : "ORADB1P4",
      "pdbName" : "ORADB1P5",

  2. クラウド環境の最初のノードでroot OSユーザーとして、Oracle Data Guard Broker構成を確認します。 

    [root@cloud-exadata1]# dbaascli dataguard getDetails --dbName oradb1 |
 egrep 'protectionMode|"status"|dbUniqueName|dgRole|standbyType|transportType|"switchoverReadiness"|"failoverReadiness"|redoTransportState|databaseStatus'

  "protectionMode" : "MAX_PERFORMANCE",
  "status" : "SUCCESS",
      "dbUniqueName" : "oradb1_onprem",
      "dgRole" : "PRIMARY",
      "standbyType" : null,
      "transportType" : "ASYNC",
      "switchoverReadiness" : "HEALTHY",
      "failoverReadiness" : "HEALTHY",
      "redoTransportState" : "ON",
      "databaseStatus" : "SUCCESS",
      "dbUniqueName" : "oradb1_cloud",
      "dgRole" : "STANDBY",
      "standbyType" : "PHYSICAL_STANDBY",
      "transportType" : "ASYNC",
      "switchoverReadiness" : "HEALTHY",
      "failoverReadiness" : "HEALTHY",
      "redoTransportState" : null,
      "databaseStatus" : "SUCCESS",

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

  3. クラウド環境の最初のノードでoracle OSユーザーとして、スタンバイ・データベースを検証します。 

    [oracle@cloud-exadata1]$ dgmgrl / 'validate database oradb1_cloud'

DGMGRL for Linux: Release 19.0.0.0.0 - Production on Thu Nov 21 15:26:55 2024
Version 19.25.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "oradb1_cloud"
Connected as SYSDG.

  Database Role:     Physical standby database
  Primary Database:  oradb1_onprem

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

  Managed by Clusterware:
    oradb1_onprem  :  YES            
    oradb1_cloud:  YES      

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

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

推奨されるベスト・プラクティスの多くはワークフローの一部として実装されますが、パフォーマンスに影響を及ぼす可能性があるため、追加の推奨事項の一部は実装されません。

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

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

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を設定しながら、プライマリではNONEに設定し、両方のデータベースに対して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ファイルに次のエントリを配置します。

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

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

バックアップの構成

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

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

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

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

Data Guardのライフ・サイクル操作

構成が完了すると、dbaascliコマンドでData Guardのライフサイクル操作、フェイルオーバー、スイッチオーバーおよび回復を実行できます。詳細は、OCIドキュメントを参照してください。

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

スタンバイ・データベースをインスタンス化した後、ヘルス・チェックを実行して、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構成の監視」を参照してください。