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 and Per-Second Billing

For each Exadata DB system 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.

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 X8 or X7 Exadata DB system, or an Exadata 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.

Tip

OCPU scaling activities are done online with no downtime.

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.

To assist with moving your database deployments between Exadata DB systems, you can restore a backup to a different Exadata DB system that uses a larger shape, or create a Data Guard associations for your database 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 Exadata Cloud Service instance needed by your database.

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 X8 Shapes

Property Quarter Rack Half Rack Full Rack
Shape Name Exadata.Quarter3.100 Exadata.Half3.200 Exadata.Full3.400
Number of Compute Nodes 2 4 8
Total Minimum Number of Enabled CPU Cores 0 0 0
Total Maximum Number of Enabled CPU Cores 100 200 400
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 179.2 TB 358.4 TB
Total Usable Storage Capacity 149 TB 299 TB 598 TB

Exadata X8 shapes provide 700 GB of user disk space for database homes.

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 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 /acfs file 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 %

Exadata Maximum Availability Architecture in Oracle Cloud Infrastructure

Exadata Maximum Availability Architecture in Oracle Cloud Infrastructure provides inherent high availability, data protection, and disaster recovery protection integrated with both cloud automation and lifecycle operations, enabling Oracle Cloud Infrastructure to be the best cloud solution for enterprise databases and applications.

Exadata Maximum Availability Architecture Benefits in Oracle Cloud

  • Deployment: Oracle deploys Exadata in Oracle Cloud Infrastructure using Maximum Availability Architecture best practices, including configuration best practices for storage, network, operating system, Oracle Grid Infrastructure, and Oracle Database. Exadata is optimized to run enterprise Oracle Databases with extreme scalability and availability.

  • Maximum Availability Architecture database templates: All cloud databases created with Oracle Cloud automation use Maximum Availability Architecture settings optimized for the Exadata in Oracle Cloud. Oracle does not recommend that you use custom scripts to create cloud databases.

  • Backup and restore automation: When you configure automatic backup to Oracle Cloud Infrastructure Object Storage, backup copies exist across multiple availability domains for additional protection, and RMAN validates cloud database backups for any physical corruptions. Database backups occur daily with a full backup occurring once per week and incremental backups occurring on all other days. Archive log backups occur frequently to reduce potential data loss in case of disaster.

  • Exadata inherent benefits: Exadata is the best Maximum Availability Architecture platform that Oracle offers, engineered with hardware, software, database, and availability innovations to support the most mission-critical enterprise applications. Specifically, Exadata provides unique high availability, data protection, and quality-of-service capabilities that set Oracle apart from any other platforms or cloud vendor.

    For a comprehensive list of Exadata Maximum Availability Architecture benefits, see Exadata Database Machine: Maximum Availability Architecture Best Practices and Deploying Oracle Maximum Availability Architecture with Exadata Database Machine. Examples of these benefits include:

    • High availability and low brownout: Fully-redundant, fault-tolerant hardware exists in the storage, network, and database servers. Resilient, highly-available software, such as Oracle Real Application Clusters (Oracle RAC), Oracle Clusterware, Oracle Database, Oracle Automatic Storage Management, Oracle Linux, and Oracle Exadata Storage Server enable applications to maintain application service levels through unplanned outages and planned maintenance events. For example, Exadata has instant failure detection that can detect and repair database node, storage server, and network failures in less than two seconds, and resume application and database service uptime and performance. Other platforms can experience 30 seconds, or even minutes, of blackout and extended application brownouts for the same type of failures. Only the Exadata platform offers a wide range of unplanned outage and planned maintenance tests to evaluate end-to-end application and database brownouts and blackouts.

    • Data protection: Exadata provides Oracle Database physical and logical block corruption prevention, detection, and, in some cases, automatic remediation. The Exadata Hardware Assisted Resilient Data (HARD) checks include support for server parameter files, control files, log files, Oracle data files, and Oracle Data Guard broker files when those files are stored in Exadata storage. This intelligent Exadata storage validation stops corrupted data from being written to disk when a HARD check fails, which eliminates a large class of failures that the database industry had previously been unable to prevent. Examples of the Exadata HARD checks include:

      • Redo and block checksum

      • Correct log sequence

      • Block type validation

      • Block number validation

      • Oracle data structures, such as block magic number, block size, sequence number, and block header and tail data structures

      Exadata HARD checks initiate from Exadata storage software (cell services) and work transparently after enabling a database DB_BLOCK_CHECKSUM parameter, which is enabled by default in the cloud. Exadata is the only platform that currently supports the HARD initiative. Furthermore, Oracle Exadata Storage Server provides non-intrusive, automatic hard disk scrub and repair. This feature periodically inspects and repairs hard disks during idle time. If bad sectors are detected on a hard disk, then Oracle Exadata Storage Server automatically sends a request to Oracle Automatic Storage Management to repair the bad sectors by reading the data from another mirror copy. Finally, Exadata and Oracle Automatic Storage Management can detect corruptions as data blocks are read into the buffer cache and automatically repair data corruption with a good copy of the data block on a subsequent database write. This inherent intelligent data protection makes Exadata and Exadata Cloud the best data protection storage platform for Oracle Databases. For comprehensive data protection, a Maximum Availability Architecture best practice is to use a standby database on a separate Exadata to detect, prevent, and automatically repair corruptions that cannot be addressed by Exadata, alone. The standby database also minimizes downtime and data loss for disasters that result from site, cluster, and database failures.

    • Response time quality of service: Only Exadata has end-to-end quality-of-service capabilities to ensure that response time remains low and optimum. Database server I/O capping and Exadata storage I/O latency capping ensures that read or write I/O can be redirected to partnered cells when response time exceeds a certain threshold. If storage becomes unreliable (but not failed) because of poor and unpredictable performance, then the disk or flash cache can be quarantined, offline, and later brought back online if heuristics show that I/O performance is back to acceptable levels. Resource management can help prioritize key database network or I/O functionality, so that your application and database perform at an optimized level. For example, database log writes get priority over backup requests on the Exadata network and storage. Furthermore, rapid response time is maintained during storage software updates by ensuring that partner flash cache is warmed so flash misses are minimized.

    • End-to-end testing and holistic health checks: Because Oracle owns the entire Exadata Cloud infrastructure, end-to-end testing and optimizations benefit every Exadata customer around the world, whether hosted on premise or in the cloud. Validated optimizations and fixes required to run any mission-critical system are uniformly applied after rigorous testing. Health checks are designed to evaluate the entire stack. The Exadata health check utility EXACHK is Exadata cloud-aware and highlights any configuration and software alerts that may have occurred because of customer changes. No other cloud platform currently has this kind of end-to-end health check available. For Oracle Autonomous Database, EXACHK runs automatically to evaluate Maximum Availability Architecture compliance. For non-autonomous databases, Oracle recommends running EXACHK at least once a month, and before and after any software updates, to evaluate any new best practices and alerts.

  • Cloud Maximum Availability Architecture best practices paper: Maximum Availability Architecture engineering collaborates with Oracle Cloud teams to integrate Maximum Availability Architecture practices that are optimized for Oracle Cloud Infrastructure and security. See MAA Best Practices for the Oracle Cloud for additional information about continuous availability, Oracle Data Guard, Hybrid Data Guard, Oracle GoldenGate, and other Maximum Availability Architecture-related topics.

The following table lists various software updates and the impacts associated with those updates on databases and applications.

Software Update Database Impact Application Impact Implementation
Network Zero downtime Zero to single-digit seconds Performed by Oracle Cloud
Storage cells Zero downtime Zero to single-digit seconds Performed by Oracle Cloud
Exadata Dom0 Zero downtime with Oracle RAC rolling updates Zero downtime Performed by Oracle Cloud
Exadata DomU Zero downtime with Oracle RAC rolling updates Zero downtime

Performed by Oracle Cloud for Autonomous Database

Performed by customer using cloud-assisted tools for non-Autonomous Database

Oracle Database quarterly update or patch Zero downtime with Oracle RAC rolling updates Zero downtime

Performed by Oracle Cloud for Autonomous Database

Performed by customer using cloud-assisted tools for non-Autonomous Database

Oracle Grid Infrastructure quarterly update, patch, or upgrade Zero downtime with Oracle RAC rolling updates Zero downtime

Performed by Oracle Cloud for Autonomous Database

Performed by customer using cloud-assisted tools for non-Autonomous Database

Oracle Database upgrade

Minimal downtime with DBMS_ROLLING, Oracle GoldenGate replication, or with pluggable database relocate

Minimal downtime with DBMS_ROLLING, Oracle GoldenGate replication, or with pluggable database relocate

Not applicable for Autonomous Database

Performed by customer using generic Maximum Availability Architecture best practices

Achieving Continuous Availability for your Applications

As part of Exadata Cloud, all software updates (except for non-rolling database upgrades) can be done online or with Oracle RAC rolling updates to achieve continuous database uptime. Furthermore, any local failures of the storage, Exadata network, or Exadata database server are managed, automatically, and database uptime is maintained.

To achieve continuous application uptime during Oracle RAC switchover or failover events, follow these application-configuration best practices:

  • Use non-default Oracle Clusterware-managed services to connect your application.

  • Use recommended connection string with built-in timeouts, retries, and delays, so that incoming connections do not see errors during outages.

  • Configure your connections with Fast Application Notification.

  • Drain and relocate services prior to any planned maintenance outage on Exadata that requires restarting any of the Oracle RAC instances. Software updates to Exadata Dom0 or DomU are automatic. For Oracle Database and Oracle Grid Infrastructure software updates, Exadata Cloud-assisted tools and Autonomous Database drain and relocate services automatically.

  • Leverage Application Continuity or Transparent Application Continuity to replay in-flight uncommitted transactions transparently after failures.

For more information, see Continuous Availability - Application Continuity for the Oracle Database.

Maximum Availability Architecture Reference Architectures in the Exadata Cloud

Exadata Cloud supports all four Maximum Availability Architecture reference architectures, providing support for all Oracle Databases, regardless of their specific high availability, data protection, and disaster recovery service-level agreements. See MAA Best Practices for the Oracle Cloud for more information about Maximum Availability Architecture in the Exadata Cloud.