エラスティック・プール・リーダーまたはエラスティック・プール・メンバーがローカルのAutonomous Data Guardスタンバイを有効にすると、スタンバイ・データベースはエラスティック・プールの一部となり、それに応じて請求されます。

ローカル・スタンバイを追加すると、プライマリのECPU割当てがプール容量(プライマリの場合は1つのx、スタンバイの場合は1つのx)に対して合計2回(2つのx)カウントされます。ローカル・スタンバイは、プライマリのピーク使用量に2を掛けます。

たとえば、プール・サイズが128 ECPUのエラスティック・プールを作成し、プール容量が512 ECPUの場合、次のAutonomous Databaseインスタンスを追加するとエラスティック・プール容量が使用されます:

• ローカルAutonomous Data Guardが有効になっている256 ECPUの1インスタンスで、プールからの合計512 ECPU割当て。

  このインスタンスを使用する場合、特定の請求時間のピークECPU使用率が256 ECPUの場合、ローカル・スタンバイ・データベースの2x乗算係数により、全体的なピークECPU使用率が512 ECPUとしてレポートされます。また、その時間の請求は512 ECPU (4xプール・サイズ)になります。

詳細は、Autonomous Data Guardの有効化を参照してください。

クロスリージョン・スタンバイがエラスティック・プールに追加されたときのリージョン間のAutonomous Data Guardスタンバイの請求およびエラスティック・プール容量の詳細について説明します。

エラスティック・プール内のデータベースは、同じリージョンに配置する必要があります。リージョン間のAutonomous Data Guardスタンバイがある場合は、スタンバイのリージョンのエラスティック・プールに配置できます。

• プライマリ・データベースのコンピュート・リソースを増やす場合、リージョン間スタンバイが実行されるリモート・エラスティック・プールには、増加に対応するために十分な空き容量が必要です。

  エラスティック・プール容量の詳細は、エラスティック・プールについてを参照してください。

• プライマリ・データベースのクロスリージョンAutonomous Data Guardスタンバイがプール・リーダーである場合、プライマリ・データベースを終了することはできません。この場合、プライマリ・データベースを終了する前に、エラスティック・プールを終了する必要があります。」

  詳細は、エラスティック・プールの終了を参照してください。

• エラスティック・プールにあるリージョン間のAutonomous Data Guardスタンバイは、プライマリのピーク使用量に基づいて請求されます。これは、プライマリがエラスティック・プール内にあるかどうかに関係なく適用されます。

  たとえば、プライマリのピーク使用量が30 ECPUである、午後1時から午後2時の特定の請求時間において、リージョン間のAutonomous Data Guardスタンバイでは、ピークECPU使用量も30 ECPUとして表示され、この使用量はリモート・リージョンのエラスティック・プール・リーダーに報告されます。

• エラスティック・プールにないクロスリージョンAutonomous Data Guardスタンバイは、プール・リーダーとしてもプール・メンバーとしても、通常のクロスリージョン・スタンバイと同様に請求されます。

  詳細は、Oracle Autonomous Database Serverless機能の請求を参照してください。