Full Stack DR Billing Details

Learn how Full Stack DR service calculates billing for each member type added to a DR protection group including a few sample calculations.

How Billing is Calculated for a DR Configuration (for a pair of associated DR protection groups)

  1. Full Stack DR only uses allocated CPU (OCPU or ECPU) as the basis for calculating charges. Storage, networking and other resource usages are not billed by Full Stack DR.
  2. The total amount billed is the sum of the CPU-based billing cost for all the individual members added to both the DR protection groups in an associated pair.
  3. The CPU usage for relevant members of a DR protection group is calculated using the methods described in the table below.
  4. After going through the details below and the given sample calculation, refer to this website to load the cost estimation calculator. Use that to estimate the charges for your DR configuration.

Member resources that incur charges

Full Stack DR only uses allocated CPU (OCPU or ECPU) as the basis for calculating charges. Charges for Full Stack DR incur for any compute or database members of a DR Protection Group whether the resource is running or stopped. For example, a non-moving compute instance that exists in the standby region however is always in a stopped state until a DR operation will still accumulate hourly charges for Full Stack DR even though it is not running.

OCI resources that incur charges

Full Stack DR charges are incurred for the following OCI IaaS and PaaS resource types:
  • Autonomous Database
    • Oracle Autonomous Database Serverless (Data Warehousing)
    • Oracle Autonomous Database Serverless (Transaction Processing)
  • Autonomous Container Database
    • Autonomous Database on Dedicated Exadata Infrastructure
  • Database
    • Base Database
    • Exadata Database on Dedicated Infrastructure
    • Exadata Database on Cloud@Customer
    • Exadata Database on Exascale Infrastructure
  • Compute Instance (moving)
  • Compute Instance (non-moving)
  • Oracle Kubernetes Engine (OKE)
No Full Stack DR charges are incurred for the following OCI IaaS and PaaS resource types:
  • Block storage (including boot volumes)
  • File storage
  • Object storage
  • Load balancers
  • Network load balancers
No Full Stack DR charges are incurred for the following:
  • Oracle applications
  • Non-Oracle applications

Determining processor consumption

The following table shows how OCPU and ECPU consumption is determined for various OCI member resource types which incur as hourly charges for Full Stack DR. Determining processor consumption for most OCI resource types is straight forward and based on what is seen in the details page in the OCI console for each individual resource. However, some resources like Oracle Exadata do not show processor consumption for individual databases are derived from the aggregate total of CPU consumed by VM cluster.

Table A-9 Determining processor consumption

Member type CPU type Basis for calculation
Compute Instance (Moving) OCPU The OCPU Count allocated to the compute instance. See the Shape Configuration section on the OCI Documentation page for the compute instance.
Compute Instance (Non-moving) OCPU The OCPU Count allocated to the compute instance. See the Shape Configurationsection on the OCI Documentation page for the compute instance.
Database: Oracle Base Database OCPU The CPU Core Count allocated to the Database System (DB System) associated with the Base Database. See the General Information section on the OCI Documentation page for the Base Database.
Database:
  • Oracle Exadata Database on Dedicated Infrastructure
  • Oracle Exadata Database on Cloud@Customer
  • Oracle Exadata Database on Exascale Infrastructure
ECPU or OCPU (Legacy)

The total ECPU or OCPU count for the VM cluster (tc) which hosts this database, divided by the total number of databases provisioned on that VM cluster (ti) equals CPU per database instance (to). This derived average CPU count is an approximation.

Formula: (tc/ti) =to

Example:
  • tc = Total ECPU or OCPU assigned to Exadata VM cluster: 64
  • ti = Total number of database instances in the cluster: 4
  • to = ECPU or OCPU per database instance: 16
Autonomous Database:
  • Serverless Data Warehouse
  • Serverless Transaction Processing
ECPU or OCPU (Legacy) The total number of ECPU/OCPU allocated to an instance is shown as ECPU/OCPU Count in the Resource Allocation section on the resource details page for each Autonomous Serverless Database instance in the OCI console.
Autonomous Container Database:
  • Autonomous Database on Dedicated Exadata Infrastructure
  • Autonomous Database on Exadata Cloud@Customer
ECPU or OCPU (Legacy)

The total number of ECPU/OCPU allocated to an instance is shown as ECPU/OCPU Count in the Resource Allocation section on the resource details page for each Autonomous Container Database instance in the OCI console.

Oracle Kubernetes Cluster (OKE) OCPU

The calculation is dependent on node pool size and quantity of OCPU assigned to each node pool for the OKE cluster in both regions. An OKE cluster can have multiple Node Pools. Therefore the total OCPU for each region is a sum of the results from all Node Pools in that region.

Node Pool size on primary OKE cluster (nps) is multiplied by the number of OCPU assigned to that Node Pool (npo). Perform this calculation for each node pool (pnsn+*pnon+) in the primary region and sum the results from each to reach a total OCPU count for the primary region (poc).

Node Pool size on standby OKE cluster (sns) is multiplied by the number of OCPU assigned to that Node Pool (sno). Perform this calculation for each node pool (snsn+*snon+) in the primary region and sum the results from each.

Add the total OCPU count from primary region (poc) and the total OCPU count from standby region (soc) to arrive at a total OCPU count for OKE (to)

Formula: (pnsn+*pnon+) + (snsn+*snon+) = to

Example:

  1. Calculate total OCPU in primary region
    • nps1 = Node Pool 1 size is: 10
    • npo1 = Node Pool 1 OCPU count per node is: 2
    • nps2 = Node Pool 2 size is: 5
    • npo2 = Node Pool 2 OCPU count per node is: 2
    • poc = Total OCPU count for primary region is: 30
  2. Calculate total OCPU in standby region
    • nps1 = Node Pool 1 size is: 10
    • npo1 = Node Pool 1 OCPU count per node is: 2
    • nps2 = Node Pool 2 size is: 5
    • npo2 = Node Pool 2 OCPU count per node is: 2
    • soc = Total OCPU count for standby region is: 30
  3. Calculate total OCPU count in both regions
    • poc = 30
    • soc = 30
    • to = Total OCPU count for OKE is: 60

Cost estimator

Oracle provides an easy to use cost estimation tool on the Full Stack DR product page.

Full Stack Disaster recovery does not install, configure, or deploy OCI resources such as compute, storage, network, databases or applications. You are responsible for designing the disaster recovery strategy that you want Full Stack Disaster Recovery to orchestrate and you are also responsible for creating, configuring, and deploying all the OCI IaaS and PaaS resources outside of the workflow for Full Stack Disaster Recovery. Therefore, you should already have some idea of the resources that will be deployed in both the regions before you begin working with Full Stack Disaster Recovery. This means that the cost estimator can be used before you have actually deployed any OCI resources in either of the OCI regions.

Considerations:

  • There is no need to calculate where resources will exist after a DR operation. Just consider the resources where they exist in the current, normal state of operations.
  • For primary region, add the totals of OCPU and ECPU consumed by resources that are members, or will be members of the primary DR protection group.
  • For standby region, add the totals of OCPU and ECPU consumed by resources that are members, or will be members of the standby DR protection group. You may or may not have any chargeable resources as members of the standby protection group. For example, it is entirely possible that you will have no member resources consuming CPU in the standby protection group if you are only orchestrating recovery for moving compute.
Example 1: Application stack with only moving compute

The example below shows a fictional business system deployed across two OCI regions. Every customer will have something different depending on the IaaS and PaaS services that are part of the application stack. This example shows how to estimate the cost for moving compute only and no databases.

The cost estimator includes six fields to plug in total OCPU & ECPU counts for IaaS and PaaS resources in each region.

The following table represents the six fields that you would fill out in the cost estimator. The values in the fields are based on the details shown in the following table representing a fictional application stack deployed for disaster recovery across two OCI regions.

Table A-10 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
12 0 0

Table A-11 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
0 0 0

Table A-12 Metric Totals

OCI Full stack DR (OCPU) OCI Full stack DR (ECPU)
12 0

CPU in Primary DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the primary region (region 1).

The following table shows an example of the IaaS and PaaS resources that exist or will exist in the primary region. The CPU totals in the last row of the table below are the figures shown in the example cost estimator above.

CPU in Primary DR Protection Group

Table A-13 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server01 4    
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server02 8    
Primary Load balancer
  • Backend set 1 active
  • Backend set 2 active
MyLoadBalancerRegion1 No charge No charge No charge
Primary Block volume group
  • Active
  • Replicated to region 2
  • Contains boot volume for MyApp01Server01
  • Contains boot volume for MyApp01Server02
MyVG00 No charge No charge No charge
Primary File system
  • Active
  • Replicated to region 2
  • Contains file system for /myscripts mounted on MyApp01Server01 & MyApp01Server02
myscripts No charge No charge No charge
Primary Total of all OCPU and ECPU of member resources in primary region   12 0 0

CPU in Standby DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the standby region (region 2).

This example only includes moving compute which only exists in a single region at any given time. Therefore, there are no chargeable member resources in the standby protection group which means no charges are incurred for Full Stack Disaster Recovery in the standby region.

CPU in Standby DR Protection Group

Table A-14 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Standby Load balancer
  • Backend set 1 not active, not populated
  • Backend set 2not active, not populated
MyLoadBalancerRegion2 No charge No charge No charge
Standby Total of all OCPU and ECPU of member resources in standby region   0 0 0

Example 2: Application stack with moving compute and databases

The example below shows a fictional business system deployed across two OCI regions. Every customer will have something different depending on the IaaS and PaaS services that are part of the application stack. This example shows how to estimate the cost for moving compute and two Oracle Databases.

The cost estimator includes six fields to plug in total OCPU & ECPU counts for IaaS and PaaS resources in each region. The following table represents the six fields that you would fill out in the cost estimator. The values in the fields are based on the details shown in the following table representing a fictional application stack deployed for disaster recovery across two OCI regions.

Primary OCI Region/Protection Group

Table A-15 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
12 16 16
Standby OCI Region/Protection Group

Table A-16 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
0 16 16
Metric Totals

Table A-17 Metric Totals

OCI Full stack DR (OCPU) OCI Full stack DR (ECPU)
44 32

CPU in Primary DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the primary region (region 1).

The following table shows an example of the IaaS and PaaS resources that exist or will exist in the primary region. The CPU totals in the last row of the table below are the figures shown in the example cost estimator above.

CPU in Primary DR Protection Group

Table A-18 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server01 4    
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server02 8    
Primary Oracle Database
  • Exadata VM Cluster
  • Data Guard in primary role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Primary Autonomous Database
  • Dedicated Infrastructure
  • Autonomous Data Guard in primary role
MyADB01     16
Primary Load balancer
  • Backend set 1 active
  • Backend set 2 active
MyLoadBalancerRegion1 No charge No charge No charge
Primary Block volume group
  • Active
  • Replicated to region 2
  • Contains boot volume for MyApp01Server01
  • Contains boot volume for MyApp01Server02
MyVG00 No charge No charge No charge
Primary File system
  • Active
  • Replicated to region 2
  • Contains file system for /myscripts mounted on MyApp01Server01 & MyApp01Server02
myscripts No charge No charge No charge
Primary Total of all OCPU and ECPU of member resources in primary region   12 16 16

CPU in Standby DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the standby region (region 2).

This example only includes moving compute which only exists in a single region at any given time. Therefore, there are no chargeable member resources in the standby protection group which means no charges are incurred for Full Stack Disaster Recovery in the standby region.

CPU in Standby DR Protection Group

Table A-19 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Standby Oracle Database
  • Exadata VM Cluster with 64 OCPU total
  • Data Guard in primary role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Standby Autonomous Database
  • Dedicated Infrastructure
  • Data Guard in standby role
MyADB01     16
Standby Load balancer
  • Backend set 1 not active, not populated
  • Backend set 2 not active, not populated
MyLoadBalancerRegion2 No charge No charge No charge
Standby Total of all OCPU and ECPU of member resources in standby region   0 16 16

Example 3: Application stack with moving and non-moving compute

The example below shows a fictional business system deployed across two OCI regions. Every customer will have something different depending on the IaaS and PaaS services that are part of the application stack.

This example illustrates how to price Full Stack DR when both moving and non-moving compute are members of DR protection groups in both regions. This also illustrates a use case where someone has chosen to manually install an Oracle Database and Data Guard on a compute instance instead of using the Oracle Database service in the OCI console. This is a simple example of why and how you might use non-moving compute, however it is not taking advantage of the built-in support for Oracle databases within Full Stack Disaster Recovery.

For illustration purposes, this example uses a total of four compute instances:

  • Two standard compute instances will act as "moving" servers for an application that tolerates being moved between regions.
    • Examples of applications that might be installed on these servers are any that do not maintain stateful, region specific, hardcoded values in binaries or configuration files and can easily tolerate being started in another region with a different IP address and minor, or no changes to configuration files at startup.
    • These compute instances will be members of the primary DR Protection Group only.
  • One standard compute instance will act as a "non-moving", active application server.
    • This compute instance only exists in region 1 and will never exist in region 2.
    • The application is installed and running in region 1.
    • This compute instance will be a member of the primary DR Protection Group only.
  • One standard compute instance will act as a "non-moving", non-active application server.
    • This compute instance only exists in region 2 and will never exist in region 1.
    • The application is installed, however not running in region 2.
    • This compute instance will be a member of the standby DR Protection Group only.

The cost estimator includes six fields to plug in total OCPU & ECPU counts for IaaS and PaaS resources in each region. The following table represents the six fields that you would fill out in the cost estimator. The values in the fields are based on the details shown in the following table representing a fictional application stack deployed for disaster recovery across two OCI regions. Notice there are no costs associated with user installed and managed databases - the cost is instead accounted for by the OPCU being consumed by the virtual machines hosting the database and Data Guard.

Primary OCI Region/Protection Group

Table A-20 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
14 16 0
Standby OCI Region/Protection Group

Table A-21 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
2 16 0
Metric Totals

Table A-22 Metric Totals

OCI Full stack DR (OCPU) OCI Full stack DR (ECPU)
48 0

CPU in Primary DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the primary region (region 1).

The following table shows an example of the IaaS and PaaS resources that exist or will exist in the primary region. The CPU totals in the last row of the table below are the figures shown in the example cost estimator above.

CPU in Primary DR Protection Group

Table A-23 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server01 4    
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server02 8    
Primary Compute Instance (Non-moving)
  • Customer installed and managed Oracle application such as Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, and so on.
  • Application actively running
MyApp02Server01 2    
Primary Oracle Database
  • Primary database for Oracle application running on MyApp02Server01
  • Exadata VM Cluster
  • Data Guard in primary role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Primary Load balancer
  • Backend set 1 active
  • Backend set 2 active
MyLoadBalancerRegion1 No charge No charge No charge
Primary Block volume group
  • Active
  • Replicated to region 2
  • Contains boot volume for MyApp01Server01
  • Contains boot volume for MyApp01Server02
MyVG00 No charge No charge No charge
Primary File system
  • Active
  • Replicated to region 2
  • Contains file system for /myscripts mounted on MyApp01Server01 & MyApp01Server02
myscripts No charge No charge No charge
Primary Total of all OCPU and ECPU of member resources in primary region   14 16 0
CPU in Standby DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the standby region (region 2).

This example only includes moving compute which only exists in a single region at any given time. Therefore, there are no chargeable member resources in the standby protection group which means no charges are incurred for Full Stack Disaster Recovery in the standby region.

CPU in Standby DR Protection Group

Table A-24 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count
Standby Compute Instance (Non-moving).
  • Customer installed and managed Oracle application such as Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, and so on.
  • Application installed, however not running
MyApp02Server02 2 0 0
Standby Oracle Database
  • Standby database for Oracle application running on MyApp02Server02
  • Exadata VM Cluster
  • Data Guard in standby role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Standby Load balancer
  • Backend set 1 not active, not populated
  • Backend set 2not active, not populated
MyLoadBalancerRegion2 No charge No charge No charge
Standby Total of all OCPU and ECPU of member resources in standby region   2 16 0

Example 4: Application stack with OKE, database, moving compute and non-moving compute

The example below shows a fictional business system deployed across two OCI regions. Every customer will have something different depending on the IaaS and PaaS services that are part of the application stack.

This example illustrates how to price Full Stack DR for a business system that includes worker nodes hosted on an Oracle Kubernetes Engine cluster (OKE), and also moving and non-moving compute as members of DR protection groups in both regions. This is a small scale example of a more typical deployment architecture for a business system that might host an application stack for any non-Oracle or Oracle application for resource planning, finance, warehouse management, supply chain management, customer relationship management, sales portal, and so on. The moving compute might be used to host Oracle or non-Oracle applications that can function with minimal modifications when brought up in a different region. The non-moving compute is normally used to host Oracle or non-Oracle applications that cannot function, or be easily modified to function at all when brought up in a different region. Examples of applications that might be installed on non-moving compute are Oracle applications such as PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server, and so on. These applications require being installed and actively running on virtual machines in the primary region, and installed, however not active on virtual machines running in the standby region.

For illustration purposes, this example uses a total of four standard compute instances, four OKE worker nodes, plus several different Oracle databases including Autonomous Database, Base Database & Exadata that are all recovered in a single DR Plan execution:

  • Two standard compute instances will act as "moving" servers for an application that tolerates being moved between regions.
    • Examples of applications that might be installed on these servers are any that do not maintain stateful, region specific, hardcoded values in binaries or configuration files and can easily tolerate being started in another region with a different IP address and minor, or no changes to configuration files at startup.
    • These compute instances will be members of the primary DR Protection Group only.
  • One standard compute instance will act as a "non-moving", active application server.
    • This compute instance only exists in region 1 and will never exist in region 2.
    • The application is installed and running in region 1.
    • This compute instance will be a member of the primary DR Protection Group only.
  • One standard compute instance will act as a "non-moving", non-active application server.
    • This compute instance only exists in region 2 and will never exist in region 1.
    • The application is installed, however not running in region 2.
    • This compute instance will be a member of the standby DR Protection Group only.
  • Four worker nodes in the OKE cluster that host application workloads that need to be recovered.
    • Four worker nodes in the primary region OKE cluster which always remains a member of the primary DR Protection Group only.
    • Four worker nodes in the standby region OKE cluster which always remains a member of the standby DR Protection Group only.
  • Four OCI Oracle databases with Data Guard already enabled using the OCI console that support the various applications.
    • The four primary databases will be members of the primary DR Protection Group only.
    • The four standby databases will be members of the standby DR Protection Group only.

The cost estimator includes six fields to plug in total OCPU & ECPU counts for IaaS and PaaS resources in each region. The following table represents the six fields that you would fill out in the cost estimator. The values in the fields are based on the details shown in the following table representing a fictional application stack deployed for disaster recovery across two OCI regions.

Primary OCI Region/Protection Group

Table A-25 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
22 24 20
Standby OCI Region/Protection Group

Table A-26 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs
10 24 20

Metric Totals

Table A-27 Metric Totals

OCI Full stack DR (OCPU) Total Database Member OCPUs
80 40

CPU in Primary DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the primary region (region 1).

The following table shows an example of the IaaS and PaaS resources that exist or will exist in the primary region. The CPU totals in the last row of the table below are the figures shown in the example cost estimator above.

Table A-28 CPU in Primary DR Protection Group

DR Protection group Member resource Description Compute OCPU Count Database OCPU count Database ECPU count
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server01 4    
Primary Compute Instance (Moving)
  • Customer installed and managed non-Oracle application
  • Apache web server for customer portal
  • Application actively running
MyApp01Server02 8    
Primary Compute Instance (Non-moving)
  • Customer installed and managed Oracle application such as Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, and so on.
  • Application actively running
MyApp02Server01 2    
Primary OKE cluster: 4 worker nodes with 2 OCPU each MyOKECluster01 8    
Primary Oracle Database:
  • Base database
  • Data Guard in primary role
MyEEDatabase01   8  
Primary Oracle Database:
  • Primary database for Oracle application running on MyApp02Server01
  • Exadata VM Cluster
  • Data Guard in primary role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Primary Autonomous Database
  • Dedicated Infrastructure
  • Autonomous Data Guard in primary role
MyADB01     16
Primary Autonomous Database
  • Serverless Infrastructure
  • Autonomous Data Guard in primary role
MyADW01     4
Primary Load balancer
  • Backend set 1 active
  • Backend set 2 active
MyLoadBalancerRegion1 No charge No charge No charge
Primary Block volume group
  • Active
  • Replicated to region 2
  • Contains boot volume for MyApp01Server01
  • Contains boot volume for MyApp01Server02
MyVG00 No charge No charge No charge
Primary Block volume group:
  • Active
  • Replicated to region 2
  • Contains block volume for /u02 onMyApp02Server01
  • Gets remounted to /u02 on MyApp02Server02 in region2 during recovery
MyVG01 No charge No charge No charge
Primary File system:
  • Active
  • Replicated to region 2
  • Contains file system for /myscripts mounted on MyApp01Server01 & MyApp01Server02
myscripts No charge No charge No charge
Primary Total of all OCPU and ECPU of member resources in primary region   22 24 20

CPU in Standby DR Protection Group

Total up all the CPU that is consumed by compute instances or databases that are members of the DR protection group in the standby region (region 2).

Only include member resources that currently exist in the standby region. You do not need to calculate where the resources will exist after a DR operation, just add the resources where they exist in the current, normal state of operations. The moving compute in the primary region is not included as members of the standby DR protection group, therefore there are no OCPU charges for moving compute in the standby region.

Table A-29 CPU in Standby DR Protection Group

DR Protection group Member resource Description Compute OCPU Count Database OCPU count Database ECPU count
Standby Compute Instance (Non-moving)
  • Customer installed and managed Oracle application such as Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, and so on.
  • Application installed, however not running
MyApp02Server02 2    
Standby OKE cluster: 4 worker nodes with 2 OCPU each MyOKECluster01 8    
Standby Oracle Database:
  • Base database
  • Data Guard in standby role
,
MyEEDatabase01   8  
Standby Oracle Database:
  • Standby database for Oracle application running on MyApp02Server02
  • Exadata VM Cluster
  • Data Guard in standby role
  • 64 total OCPUs allocated to the VM Cluster
  • 4 databases provisioned in the VM Cluster
  • 16 OCPU per database: (64/4 = 16 OCPU each database)
MyExaDatabase03   16  
Standby Autonomous Database:
  • Dedicated Infrastructure
  • Data Guard in standby role
MyADB01     16
Standby Autonomous Database:
  • Serverless Infrastructure
  • Data Guard in standby role
MyADW01     4
Standby Load balancer:
  • Backend set 1 not active, not populated
  • Backend set 2not active, not populated
MyLoadBalancerRegion2 No charge   No charge
Standby Total of all OCPU and ECPU of member resources in standby region   10 24 20