Exadata Cloud Service
Exadata Cloud Service allows you to leverage the power of Exadata in the cloud. You can provision flexible X8M systems that allow you to add database compute servers and storage servers to your system as your needs grow. X8M systems offer RDMA over Converged Ethernet (RoCE) networking for high bandwidth and low latency, persistent memory (PMEM) modules, and intelligent Exadata software. X8M systems can be provisioned using an shape equivalent to a quarter rack X8 system, and then database and storage servers can be added at any time after provisioning. For more information on X8M systems, see Overview of X8M Scalable Exadata Infrastructure.
X8 and X7 systems are also available in fixed-shapes (quarter, half, and full rack systems). These systems use InfiniBand networking, and do not have the ability to scale database and storage servers. You can also provision an Exadata base system, which has a smaller capacity than a quarter rack system.
For all Exadata Cloud Service instances, you can configure automatic backups, optimize for different workloads, and scale the OCPU and storage allocations as needed.
Exadata Cloud Service instances launched on or after March 14, 2019 run Oracle Linux 7. Previously launched systems are running Oracle Linux 6. See OS Updates for important information about updating existing Exadata DB system operating systems.
Supported Database Edition and Versions
Exadata Cloud Service instances require Enterprise Edition - Extreme Performance. This edition provides all the features of Oracle Database Enterprise Edition, plus all the database enterprise management packs and all the Enterprise Edition options, such as Oracle Database In-Memory and Oracle Real Application Clusters (RAC).
Exadata Cloud Service instances support the following software releases:
- Oracle Database 19c (19.0)
- Oracle Database 18c (18.0)
- Oracle Database 12c Release 2 (12.2)
- Oracle Database 12c Release 1 (12.1)
- Oracle Database 11g Release 2 (11.2)
- If you plan to run Oracle Database 19c on a cloud VM cluster or DB system in the Exadata Cloud Service, you must specify version 19c when you create the resource. Earlier database versions are supported on a 19c cloud VM cluster or DB system, and can be created at anytime. Cloud VM clusters and DB systems created with earlier Oracle Database versions will not automatically support Oracle Database 19c.
- For information on upgrading an existing 18c or earlier database to Oracle Database 19c, see Upgrading Exadata Databases.
The only subscription type available for Exadata Cloud Service instances is the Monthly Flex purchase model under Universal Credit Pricing. See the Universal Credit Pricing FAQ for more information.
Metering Frequency and Per-Second Billing
For each Exadata Cloud Service instance you provision, you are billed for the infrastructure for a minimum of 48 hours, and then by the second after that. Each OCPU you add to the system is billed by the second, with a minimum usage period of 1 minute. For X8M systems, if you terminate the cloud VM cluster and do not terminate the cloud Exadata infrastructure resource, billing will continue for the infrastructure resource.
Three kinds of scaling operations are supported for an Exadata Cloud Service:
- For all Exadata Cloud Service instances, you can scale the compute node processing power within the provisioned system, adding or subtracting CPU cores as needed.
- For X8M systems, the flexible shape allows you to add additional database and storage servers to the cloud Exadata infrastructure resource as you need them.
- For X6, X7 and X8 Exadata DB systems, you can scale by moving the system to a different shape configuration, for example, from a quarter rack to a half rack.
For more information on each type of scaling, see Scaling an Exadata Cloud Service Instance.
Scaling CPU Cores Within an Exadata Cloud Service Instance
If an Exadata Cloud Service instance requires more compute node processing power, you can scale up the number of enabled CPU cores symmetrically across all the nodes in the system as follows:
X8M flexible infrastructure systems: You can scale CPU cores in multiples of the number of database servers currently provisioned for the cloud VM cluster. For example, if you have 6 database servers provisioned, you can add CPU cores in multiples of 6. At the time of provisioning, X8M systems have 2 database servers. For more information on adding compute and storage resources to an X8M system, see Scaling Exadata X8M Compute and Storage.
Non-X8M fixed-shape systems: For a base system or an X7 or X8 quarter rack, you can scale in multiples of 2 across the 2 database compute nodes. For an X7 or X8 half rack, you can scale in multiples of 4 across the 4 database compute nodes. For an X7 or X8 full rack, you can scale in multiples of 8 across the 8 database compute nodes.
For a non-metered service instances, you can temporarily modify the compute node processing power (bursting) or add compute node processing power on a more permanent basis. For a metered service instance, you can simply modify the number of enabled CPU cores.
You can provision an Exadata Cloud Service instance with zero CPU cores, or scale the service instance down to zero cores after you provision it. With zero cores, you are billed only for the infrastructure until you scale up the system. For detailed information about pricing, see Exadata Cloud Service Pricing.
OCPU scaling activities are done online with no downtime.
For information on CPU cores per configuration, see Exadata Shape Configurations. To learn how to scale a system, see To scale CPU cores in an Exadata Cloud Service cloud VM cluster or DB system.
Scaling X6, X7 and X8 Exadata DB System Configurations
Scaling an Exadata X6, X7, or X8 Exadata Cloud Service instance by moving to a shape with more capacity enables you meet the needs of your growing workload. This is useful when a database deployment requires:
- Processing power that is beyond the capacity of the current system configuration.
- Storage capacity that is beyond the capacity of the current system configuration.
- A performance boost that can be delivered by increasing the number of available compute nodes.
- A performance boost that can be delivered by increasing the number of available Exadata Storage Servers.
You can move you workloads to a larger fixed shape (X7 and X8 hardware shapes), or move to the flexible X8M shape that allows for easy expansion of compute and storage resources as your workloads grow.
To assist with moving your database deployments between Exadata Cloud Service instances, you can restore a backup to a different service instance that has more capacity, or create a Data Guard association for your database in a service instance with more capacity, and then perform a switchover so that your new standby database assumes the primary role. To start the process, contact Oracle and request a service limit increase so that you can provision the larger service instance needed by your database.
Exadata Shape Configurations
Each Exadata Cloud Service instance consists of compute nodes and storage servers. The compute nodes are each configured with a Virtual Machine (VM). You have root privilege for the compute node VMs, so you can load and run additional software on them. However, you do not have administrative access to the Exadata infrastructure components, including the physical compute node hardware, network switches, power distribution units (PDUs), integrated lights-out management (ILOM) interfaces, or the Exadata Storage Servers, which are all administered by Oracle.
For X8M systems, the Exadata hardware is administered through two resource types, the cloud Exadata infrastructure resource and the cloud VM cluster. See The New Exadata Cloud Service Resource Model for more details.
For X6, X7, and X8 systems, the Exadata hardware is administered through the DB system resource.
For all hardware models, you have full administrative privileges for your databases, and you can connect to your databases by using Oracle Net Services from outside the Oracle Cloud Infrastructure. You are responsible for database administration tasks such as creating tablespaces and managing database users. You can also customize the default automated maintenance set up, and you control the recovery process in the event of a database failure.
For full details on the available shape configurations, see Exadata Fixed Hardware Shapes: X6, X7, X8 and Exadata Base
Customer-Managed Keys in Exadata Cloud Service
Customer-managed keys for Exadata Cloud Service is a feature of Oracle Cloud Infrastructure Vault service that enables you to encrypt your data using encryption keys that you control. The Vault service provides you with centralized key management capabilities that are highly available and durable. This key-management solution also offers secure key storage using isolated partitions (and a lower-cost shared partition option) in FIPS 140-2 Level 3-certified hardware security modules, and integration with select Oracle Cloud Infrastructure services. Use customer-managed keys when you need security governance, regulatory compliance, and homogenous encryption of data, while centrally managing, storing, and monitoring the life cycle of the keys you use to protect your data.
- Enable customer-managed keys when you create databases in Exadata Cloud Service
- Switch from Oracle-managed keys to customer-managed keys on databases that are not enabled with Oracle Data Guard
- Rotate your keys to maintain security compliance
Databases that are enabled with Oracle Data Guard must use Oracle-managed keys.
When you launch an Exadata Cloud Service instance, the storage space inside the Exadata storage servers is configured for use by Oracle Automatic Storage Management (ASM). By default, the following ASM disk groups are created:
- The DATA disk group is intended for the storage of Oracle Database data files.
- The RECO disk group is primarily used for storing the Fast Recovery Area (FRA), which is an area of storage where Oracle Database can create and manage various files related to backup and recovery, such as RMAN backups and archived redo log files.
/acfsfile systems contain system files that support various operations. You should not store custom files, Oracle Database data files, or backups inside the ACFS disk groups. Custom ACFS mounts can be created using the DATA ASM disk group for files that are not service-related.
The disk group names contain a short identifier string that is associated with your Exadata Database machine environment. For example, the identifier could be C2, in which case the DATA disk group would be named DATAC2, the RECO disk group would be named RECOC2, and so on.
In addition, you can create a SPARSE disk group. A SPARSE disk group is required to support Exadata snapshots. Exadata snapshots enable space-efficient clones of Oracle databases that can be created and destroyed very quickly and easily. Snapshot clones are often used for development, testing, or other purposes that require a transient database.
Note that you cannot change the disk group layout after service creation.
Impact of Configuration Settings on Storage
If you choose to perform database backups to the Exadata storage, or to create a sparse disk group, or to do both, your choices profoundly affect how storage space in the Exadata storage servers is allocated to the ASM and sparse disk groups.
The table that follows shows the approximate percentages of storage allocated for DATA, RECO, and SPARSE disk groups for each possible configuration.
|Configuration Settings||DATA Disk Group||RECO Disk Group||SPARSE Disk Group|
Database backups on Exadata storage: No
Sparse disk group: No
|80 %||20 %||0 %|
Database backups on Exadata storage: Yes
Sparse disk group: No
|40 %||60 %||0 %|
Database backups on Exadata storage: No
Sparse disk group: Yes
|60 %||20 %||20 %|
Database backups on Exadata storage: Yes
Sparse disk group: Yes
|35 %||50 %||15 %|
Moving Databases to Oracle Cloud Exadata Systems Using Zero Downtime Migration
Oracle now offers the Zero Downtime Migration service, a quick and easy way to move on-premises Oracle Databases and Oracle Cloud Infrastructure Classic databases to Oracle Cloud Infrastructure. You can migrate databases to the following types of Oracle Cloud Infrastructure systems: Exadata, Exadata Cloud@Customer, bare metal, and virtual machine.
Zero Downtime Migration leverages Oracle Active Data Guard to create a standby instance of your database in an Oracle Cloud Infrastructure system. You switch over only when you are ready, and your source database remains available as a standby. Use the Zero Downtime Migration service to migrate databases individually or at the fleet level. See Move to Oracle Cloud Using Zero Downtime Migration for more information.