Oracle Cloud Infrastructure Documentation

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

  1. A DR configuration is everything needed to recover a single business system.
    • A DR configuration does not need to exist in order to estimate the monthly cost for Full Stack DR.
    • Only the OCI IaaS and PaaS resources listed below are needed to estimate the monthly cost for Full Stack DR.
  2. Charges for Full Stack DR are over and above the normal charges incurred for common OCI services such as compute, Oracle databases, MySQL databases, and DR enabled Oracle Integration instances.
    • No additional charges are incurred for storage, networking or other OCI resources supported natively with Full Stack DR.
    • See the list in Member resources that incur charges section below for more detail.
  3. Full Stack DR uses the following for calculating charges on a monthly basis:
    • Moving compute: only allocated OCPU in the primary region.
    • Non-moving compute: allocated OCPU in the primary and standby regions.
    • Oracle databases: allocated OCPU or ECPU in the primary and standby regions.
    • MySQL Heatwave databases: allocated ECPU in the primary and standby regions.
    • Oracle Integration: allocated OIC message packs in the primary and standby regions.
    • Oracle Kubernetes Engine: allocated OCPU of worker nodes in the primary and standby regions.
      • Full Stack DR supports OKE virtual and managed node pools.
      • OKE node pools support the OKE Cluster Autoscaler feature which can change the number of worker nodes on-demand in the primary or standby regions.
      • Your cost estimate needs to consider, the quantity of allocated OCPU may increase or decrease numerous times during a monthly billing cycle.
    • See the list in Member resources that incur charges section below for more detail.
  4. Estimating the total monthly cost associated with Full Stack Disaster Recovery can be calculated using a cost estimation tool:
    • The table available in the Determining resource consumption section below explains how to find and determine allocated resources for each OCI resource type that incurs charges.
    • Add the quantities for the various allocated resources to the cost estimator tool. There are two different cost estimation tools:
      • Option 1: The Full Stack DR cost estimator available on the Pricing tab of the Full Stack DR product page. This provides a quick estimate of the costs related only to Full Stack DR but does not allow you to estimate the cost of OCI resources.
      • Option 2: The Comprehensive cost estimator available on the OCI Price List page. This allows you to put together an estimate that includes costs related to Full Stack DR along with all the other OCI resources that are or will be part of the application stack you are protecting with Full Stack DR. You can save your pricing estimate by exporting the configuration to a JSON file. You can also import the JSON file at any point in the future to continue working on a bill of materials for your entire application stack.

Member resources that incur charges

Full Stack DR only uses allocated OCPU, ECPU, or OIC message packs as the basis for calculating charges. Charges for Full Stack DR accrue for any compute, database, or Oracle Integration 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 but is always in a stopped state until a DR operation is executed will still accumulate hourly charges 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
  • Oracle Database
    • Base Database
    • Exadata Database on Dedicated Infrastructure
    • Exadata Database on Cloud@Customer
    • Exadata Database on Exascale Infrastructure
  • Database
    • MySQL Heatwave
  • Compute Instance (moving)
  • Compute Instance (non-moving)
  • Developer services
    • Oracle Integration 3 (OIC)
    • 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 resource consumption

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

Table A-11 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: MySQL Heatwave DB system ECPU The ECPU Count allocated to the DB System. See the ECPU count in the Resource allocation section under the Details tab on the OCI page for DB system details.
Oracle 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.
Oracle 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 Integration 3
  • Enterprise Edition with Oracle Managed License
 Message pack

The total number of OIC message packs is shown as Message packs on the OIC instance page in the General section under the Details tab.

The number of messages allowed per message pack varies depending on your OIC configuration and usage. See the OIC documentation for additional information.
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. In this scenario the OCI resources only exist in a single region at any point in time. This is similar to the approach other cloud service providers employ for disaster recovery. This strategy relies on replicating the boot and block storage for each virtual machine to the standby region so you will only add the OCPU count for the region where the virtual machines are currently running.

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 below the table representing a fictional application stack deployed for disaster recovery across two OCI regions.

Table A-12 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
12 0 0 0

Table A-13 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
0 0 0 0

Table A-14 Metric Totals

OCI Full stack DR (OCPU) OCI Full stack DR (ECPU) Total OIC Message Packs
12 0 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-15 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack 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 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-16 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack Count
Standby Load balancer
  • Backend set 1 not active, not populated
  • Backend set 2not active, not populated
 MyLoadBalancerRegion2 No charge No charge No charge No charge
Standby Total of all OCPU and ECPU of member resources in standby region   0 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. In this scenario the compute OCI resources only exist in a single region while the databases both have Data Guard enabled which means there are OCI resources in both regions. This is similar to the pilot light approach other cloud service providers employ for disaster recovery except you can include the database as part of the same recovery without handing off tasks to different teams. This strategy relies on replicating the boot and block storage for each virtual machine to the standby region so you will only add the OCPU count for the region where the virtual machines are currently running. For the databases, you will add OCPU and ECPU counts to both regions since you have resources running in both regions.

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-17 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
12 16 16 0
Standby OCI Region/Protection Group

Table A-18 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
0 16 16 0
Metric Totals

Table A-19 Metric Totals

OCI Full stack DR (OCPU) OCI Full stack DR (ECPU) Total OIC Message Packs
44 32 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-20 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack 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 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-21 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack 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 0

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, non-moving compute, and multiple Data Guard enabled databases are members of DR protection groups in both regions. This is a simple example of why and how you might use non-moving compute for non-Oracle and Oracle applications like E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, and others that do not have their own inherent DR capabilities built into their products. These products generally require that the application be installed on virtual machines that exist and run concurrently in both regions; the application is installed in both regions, but is not running in the standby region.

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.
  • One Oracle database with Data Guard already enabled using the OCI console.
    • The primary database will be a member of the primary DR Protection Group only.
    • The standby database 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-22 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-23 Standby OCI Region/Protection Group

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

Table A-24 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-25 CPU in Primary DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack 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 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-26 CPU in Standby DR Protection Group

DR Protection Group Member Resource Description Compute OCPU Count Database OCPU Count Database ECPU Count OIC Message Pack 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 0

Example 4: Application stack with OKE, database, Oracle Integration, 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.
  • One Oracle Integration instance already created and deployed for disaster recovery using the Enable disaster recovery switch under Advanced options when creating a new Oracle Integration instance.
    • One instance with primary disaster recovery role will be a member of the primary DR Protection Group only.
    • One instance with secondary disaster recovery role 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.

Primary OCI Region/Protection Group

Table A-27 Primary OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
22 24 20 2
Standby OCI Region/Protection Group

Table A-28 Standby OCI Region/Protection Group

Total Compute Member OCPUs Total Database Member OCPUs Total Database Member ECPUs Total OIC Message Packs
10 24 20 2

Metric Totals

Table A-29 Metric Totals

OCI Full stack DR (OCPU) Total Database Member OCPUs Total OIC Message Packs
80 40 4

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-30 CPU in Primary DR Protection Group

DR Protection group Member resource Description Compute OCPU Count Database OCPU count Database ECPU count OIC Message Pack 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 OIC single click DR (Oracle Managed DR) MyOIC01       2
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 2

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-31 CPU in Standby DR Protection Group

DR Protection group Member resource Description Compute OCPU Count Database OCPU count Database ECPU count OIC Message Pack 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 OIC single click DR (Oracle Managed DR) MyOIC01_Recovery       2
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 2

Parent topic: Reference