About Billing Autonomous AI Database Elastic Pools with Autonomous Data Guard

An Autonomous Data Guard primary database can use a local or a cross region standby that is part of an elastic pool, either as a leader or a member.

Note: Dedicated elastic pools with Autonomous Data Guard are billed hourly for both allocated storage and compute (ECPUs). While compute usage (ECPUs) is billed exactly as described on this page, its storage consumption is subject to different billing guidelines. See About Billing Autonomous AI Database Dedicated Elastic Pools with Autonomous Data Guard for details and examples.

About Elastic Pool Billing with Autonomous Data Guard Enabled with a Local Standby

When an elastic pool leader or an elastic pool member enables a local Autonomous Data Guard standby, the standby database is part of the elastic pool and you are billed accordingly.

When you add a local standby, a total of two times (2 x) the primary’s ECPU allocation is counted towards the pool capacity (1 x for the primary and 1 x for the standby).

For example, if you create an elastic pool with a pool size of 128 ECPUs, with a pool capacity of 512 ECPUs, adding the following Autonomous AI Database instance uses the elastic pool capacity:

• 1 instance with 256 ECPUs with local Autonomous Data Guard enabled, for a total of 512 ECPUs allocation from the pool.

  When using this instance, if the peak ECPU utilization is 256 ECPUs for a given billing hour, the overall peak ECPU utilization will be reported as 256 ECPUs for the primary databases and 256 ECPUs for the standby databases. The billing for that hour will be 512 ECPUs (4x pool size).

Similarly, if you create an elastic pool with a pool size of 128 ECPUs, with a pool capacity of 512 ECPUs, adding the following Autonomous AI Database instances uses the elastic pool capacity as follows:

• 128 instances with 2 ECPUs each, with local Autonomous Data Guard enabled, for a total of 512 ECPUs allocation from the pool.

  When using all of these instances, if the peak ECPU utilization is 256 ECPUs, 128 *2 ECPUs per instance, for a given billing hour, the overall peak ECPU utilization will be reported as 256 ECPUs for the primary databases and 256 ECPUs for the standby databases. The billing for that hour will be 512 ECPUs (4x pool size).

In some cases, the aggregated peak of the local ADG standby databases in your elastic pool causes the hourly peak of the elastic pool to fall within the next billing tier. When this occurs, the aggregated peak of pool members and the aggregated peak for local ADG standbys are calculated separately to provide you a cost advantage.

For example, you create an elastic pool with a pool size of 128 ECPUs, with a pool capacity of 512 ECPUs. The pool has 3 members (including the leader). DB1 is allocated 20 ECPUs and has local ADG standby, DB2 is allocated 25 ECPUs and has local ADG standby, and DB3 is allocated 30 ECPUs and has local ADG standby. If the peak ECPU utilization of these databases is 18 ECPUs, 22 ECPUs, and 30 ECPUs respectively for a given billing hour, the aggregated hourly peak ECPU utilization would be 70 ECPUs x 2 (since each one has a local ADG standby). In this case, instead of billing the elastic pool for 256 ECPUs (since the peak jumps to 140 ECPUs due to having local ADG standbys and 140 > 128), the hourly pool charge is calculated by just looking at the primary instances’ hourly ECPU peaks to determine the pool billing tier and adding the aggregated peaks resulting from configured local ADG standbys to the pool charge. In other words, the pool charge for the mentioned billing hour in this example will be 198 ECPUs (128 ECPUs + 70 ECPUs) instead of 256 ECPUs.

In this example you save 58 ECPUs worth of billing cost when the aggregated peak of pool members and the aggregated peak for local ADG standbys are determined separately.

See Enable Autonomous Data Guard for more information.

About Elastic Pool Billing with a Cross Region Standby

Describes billing and elastic pool capacity details for a cross region Autonomous Data Guard standby when the cross region standby is added to an elastic pool.

The databases in an elastic pool must be located in the same region. If you have a cross region Autonomous Data Guard standby, you can place it in an elastic pool in the standby’s region.

• If you increase the primary database's compute resources, the remote elastic pool where the cross region standby runs must have enough available capacity to accommodate the increase.

  See About Elastic Pools for more information on elastic pool capacity.

• It is not possible to terminate a primary database when its cross region Autonomous Data Guard standby is a pool leader. In this case you must terminate the elastic pool before you terminate the primary database.”

  See Terminate an Elastic Pool for more information.

• A cross region Autonomous Data Guard standby that is in an elastic pool is billed based on the peak usage of the primary. This applies independent of whether the primary is in an elastic pool.

  For example, in a given billing hour from 1pm to 2pm where the primary's peak usage is 30 ECPUs, the cross region Autonomous Data Guard standby also shows its peak ECPU usage as 30 ECPUs and this usage is reported to the remote region elastic pool leader.

• A cross region Autonomous Data Guard standby that is not in an elastic pool, neither as a pool leader nor as a pool member, is billed just like a regular cross region standby.

  See Oracle Autonomous AI Database Serverless Features Billing for more information.