Oracle Cloud Infrastructure Documentation

Exadata DB Systems

Exadata DB systems allow you to leverage the power of Exadata within the Oracle Cloud Infrastructure. An Exadata DB system consists of a base system, quarter rack, half rack, or full rack of compute nodes and storage servers, tied together by a high-speed, low-latency InfiniBand network and intelligent Exadata software. You can configure automatic backups, optimize for different workloads, and scale up the system to meet increased demands.

Note

Exadata DB systems launched on or after March 14, 2019 run Oracle Linux 7 (OL7). Previously launched systems are running Oracle Linux 6 (OL6). See OS Updates for important information about updating existing Exadata DB system operating systems.

Supported Database Edition and Versions

Exadata DB systems 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 DB systems 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)

Note

If you plan to run Oracle Database 19c on your Exadata DB system, you must specify version 19c when you create the DB system. Earlier database versions are supported on a 19c Exadata DB system and can be created at anytime. Exadata DB systems created with earlier Oracle Database versions will not automatically support Oracle Database 19c. The DB system must be upgraded manually.

Subscription Types

The only subscription type available for Exadata DB systems is the Monthly Flex purchase model under Universal Credit Pricing. See https://www.oracle.com/cloud/bring-your-own-license/faq/universal-credit-pricing.html for more information.

Metering Frequency

For each Exadata DB system you provision, you are billed for the infrastructure for the first month, and then by the hour after that. Each OCPU you add to the system is billed by the hour from the time you add it.

Scaling an Exadata DB System

Two kinds of scaling operations are supported for an Exadata DB system:

  • Scaling within an Exadata DB system lets you modify compute node processing power within the system.
  • Scaling across Exadata DB system configurations lets you move to a different configuration, for example, from a quarter rack to a half rack.

Scaling Within an Exadata System

If an Exadata DB system requires more compute node processing power, you can scale up the number of enabled CPU cores symmetrically across all the nodes in the system. For a base system or a quarter rack, you can scale in multiples of 2 across the 2 database compute nodes. For a half rack, you can scale in multiples of 4 across the 4 database compute nodes. For a full rack, you can scale in multiples of 8 across the 8 database compute nodes.

For a non-metered Exadata DB system, you can temporarily modify the compute node processing power (bursting) or add compute node processing power on a more permanent basis. For a metered Exadata DB system, you can simply modify the number of enabled CPU cores.

You can provision an X7 Exadata DB system or a base system with zero CPU cores, or scale the DB system 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 https://www.oracle.com/database/exadata-cloud-service-pricing.html.

For information on CPU cores per configuration, see System Configuration. To learn how to scale a system, see To scale an Exadata DB system.

Scaling Across Exadata DB System Configurations

Scaling across Exadata DB system configurations enables you to move to a different system configuration. 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.

Scaling from a base system or a quarter rack to a half rack, or from a half rack to a full rack, requires that the data associated with your database deployment is backed up and restored on a different Exadata DB system, which requires planning and coordination between you and Oracle. To start the process, submit a service request to Oracle.

System Configuration

Exadata DB systems are offered in base system, quarter rack, half rack or full rack configurations, and each configuration 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.

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.

The subsections that follow provide the details for each shape's configuration.

Exadata X7 Shapes

Property Quarter Rack Half Rack Full Rack
Shape Name Exadata.Quarter2.92 Exadata.Half2.184 Exadata.Full2.368
Number of Compute Nodes 2 4 8
Total Minimum Number of Enabled CPU Cores 0 0 0
Total Maximum Number of Enabled CPU Cores 92 184 368
Total RAM Capacity 1440 GB 2880 GB 5760 GB
Number of Exadata Storage Servers 3 6 12
Total Raw Flash Storage Capacity 76.8 TB 153.6 TB 307.2 TB
Total Usable Storage Capacity 106 TB 212 TB 424 TB

Exadata X7 shapes provide 1 TB of user disk space for database homes.

Exadata X6 Shapes

Property Quarter Rack Half Rack Full Rack
Shape Name Exadata.Quarter1.84 Exadata.Half1.168 Exadata.Full1.336
Number of Compute Nodes 2 4 8
Total Minimum (Default) Number of Enabled CPU Cores 22 44 88
Total Maximum Number of Enabled CPU Cores 84 168 336
Total RAM Capacity 1440 GB 2880 GB 5760 GB
Number of Exadata Storage Servers 3 6 12
Total Raw Flash Storage Capacity 38.4 TB 76.8 TB 153.6 TB
Total Usable Storage Capacity 84 TB 168 TB 336 TB

Exadata X6 shapes provide 200 GB of user disk space for database homes.

Exadata Base System

The system configuration of an Exadata base system is similar to a quarter rack with some differences in capacity.

Property Value
Shape Name Exadata.Base.48
Number of Compute Nodes 2
Total Minimum Number of Enabled CPU Cores 0
Total Maximum Number of Enabled CPU Cores 48
Total RAM Capacity 720 GB
Number of Exadata Storage Servers 3
Total Raw Flash Storage Capacity 38.4 TB
Total Usable Storage Capacity 74.8 TB

Storage Configuration

When you launch an Exadata DB system, 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.
  • The DBFS and ACFS disk groups are system disk groups that support various operational purposes. The DBFS disk group is primarily used to store the shared clusterware files (Oracle Cluster Registry and voting disks), while the ACFS disk groups are primarily used to store Oracle Database binaries. Compared to the DATA and RECO disk groups, the system disk groups are so small that they are typically ignored when discussing the overall storage capacity. You should not store Oracle Database data files or backups inside the system disk groups.

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 %