About DB Systems
Oracle Cloud Infrastructure (OCI) offers DB systems on virtual machines.
There are two types of database systems (DB systems) on virtual machines:
- Single-node DB system: A 1-node DB system consists of one virtual machine.
- Multi-node RAC DB system: A 2-node DB system consists of two virtual machines.
If you must provision a DB system for development or testing purposes, a special fast-provisioning single-node DB system is available.
When you create a DB system, you select the Oracle AI Database edition and version that applies to the database on that DB system. You cannot change the selected edition. Depending on your selected Oracle AI Database edition and version, your DB system can support multiple pluggable databases (PDB). See the following Oracle AI Database licensing topic for information about the maximum number of pluggable and container databases (CDB) available for your selected Oracle AI Database version.
- Oracle Database 19c: Permitted Features, Options, and Management Packs by Oracle AI Database Offering
A DB system can have only a single Database Home, which in turn can have only a single database. A DB system database uses OCI block storage instead of local storage. You specify a storage size when you create the DB system, and you can scale up the storage as required at any time. To change the number of CPU cores on an existing DB system, you must change the shape of that DB system. For more information, see Change the Shape of a DB System.
Note: The shape change operation takes place in a rolling fashion for multi-node RAC DB systems, enabling you to change the shape with no database downtime.
Available Shapes and How It Determines the Resources Allocated
When you create a DB system, you select a shape, which determines the resources allocated to the DB system. After you create the DB system, you can change its shape to adapt to new processing capacity requirements. The following shapes are available:
Note:
Oracle Base Database Service has announced the retirement of VM.Standard.x86 shape, the Enterprise Edition - Extreme Performance (EE-EP) software edition, and OCPU-metered service SKUs, effective July 31, 2026. Existing deployments will continue to run, but new provisioning and contract renewals will be affected.
Plan migration to VM.BaseDB.x86 using the ECPU metric or to Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) for EE-EP workloads, as applicable. For information about affected SKUs, customer impact, and migration guidance, see My Oracle Support Article KB921246.
Flexible Shapes
Flexible shapes let you customize the compute resources - ECPUs or OCPUs allocated to an instance. When you create an instance using a flexible shape, you select the compute resource that you require for the workloads that run on the instance. This flexibility lets you build instances that match your workload, enabling you to optimize performance and minimize cost. The amount of memory allowed is based on the number of ECPUs or OCPUs selected, and the ratio of memory to ECPUs or OCPUs depends on the shape.
Flexible shapes are available with Ampere, AMD, and Intel processors. The following table shows the available shapes.
| Shape | Compute | Memory |
|---|---|---|
| VM.BaseDB.x86 | Minimum is 4 ECPUs and maximum is 256 ECPUs. Should be in increments of 4. |
8 GB for every 4 ECPUs. Minimum is 8 GB and maximum is 512 GB total memory. |
| VM.Standard.x86 | Minimum is 4 ECPUs and maximum is 252 ECPUs. Should be in increments of 4. |
8 GB for every 4 ECPUs. Minimum is 8 GB and maximum is 504 GB total memory. |
| Ampere VM.Standard.A1.Flex | Minimum is 1 OCPU and maximum is 57 OCPUs. | 8 GB per OCPU. Minimum is 8 GB and maximum is 456 GB total memory. |
| AMD VM.Standard.E5.Flex | Minimum is 1 OCPU and maximum is 64 OCPUs. | 16 GB per OCPU. Minimum is 16 GB and maximum is 1024 GB total memory. |
| AMD VM.Standard.E4.Flex | Minimum is 1 OCPU and maximum is 64 OCPUs. | 16 GB per OCPU. Minimum is 16 GB and maximum is 1024 GB total memory. |
| Intel X9 VM.Standard3.Flex | Minimum is 1 OCPU and maximum is 32 OCPUs. | 16 GB per OCPU. Minimum is 16 GB and maximum is 512 GB total memory. |
Note:
- Arm-based Ampere A1 shape is available for Oracle AI Database versions 26ai and 19c starting with the 23.7.0.0, 19.19.0.0, and later release updates (RU) only.
- AMD E5 shape is available for Oracle AI Database versions 26ai and 19c starting with the 23.4.0.24.05, 19.21.0.0, and later release updates (RU) only.
- AMD E4 shape is available for Oracle AI Database versions 26ai, 21c, and 19c with the 23.4.0.24.05, 21.6.0.0, 19.15.0.0, and later release updates (RU) only.
- Intel X9 shape is available for Oracle AI Database versions 26ai, 21c, and 19c with the 23.4.0.24.05, 21.8.0.0, 19.17.0.0, and later release updates (RU) only.
- Multi-node RAC DB systems require a minimum of two OCPUs per node.
Generation-Agnostic X86 Shape
The VM.BaseDB.x86 shape and VM.Standard.x86 shape are generation-agnostic, flexible x86 shapes that let you customize the number of ECPUs allocated to a DB system. These shapes provide a consistent experience across supported x86 infrastructure generations while allowing you to scale compute resources based on workload requirements.
The x86 shapes have the following characteristics:
- Use ECPU-based billing, enabling more granular, usage-based pricing.
- VM.BaseDB.x86 supports Oracle AI Database 26ai and Oracle Database 19c.
- VM.Standard.x86 supports Oracle AI Database 26ai only.
-
Support the following Oracle AI Database software editions:
- Standard Edition
- Enterprise Edition
- Enterprise Edition - High Performance
- Support Logical Volume Manager for storage management.
- Support single-node DB systems only.
Note: The x86 shapes do not support fault domain.
Arm-based Ampere A1 Shape
Arm-based Ampere A1 shapes are flexible and enable you to customize the number of OCPUs allocated to an instance. The following are some additional details about Ampere A1 shapes:
- Ampere A1 shape is only supported on Logical Volume Manager.
- Ampere A1 shape is only supported on single-node DB systems.
- Oracle AI Database Standard Edition is not supported on Ampere A1 shape-based DB systems.
- A database software image cannot be used for creating a database on Ampere A1 shape-based DB systems.
- Ampere A1 shape-based DB system provisioning and restoration are not supported if the backup destination for the database is the Autonomous Recovery Service.
- Ampere A1 shape is not supported for databases that use OCI vault encryption.
- The shape of Ampere A1 shape-based DB systems cannot be changed to Intel or AMD shape-based DB systems, and vice versa.
- A backup of an Ampere A1 shape-based database cannot be restored on Intel or AMD shape-based DB systems, and vice versa.
- Ampere A1 shape-based DB systems do not support Data Guard associations with Intel or AMD shape-based DB systems.
Standard Shapes
Standard shapes are available with Intel processors.
The following table shows the available shapes in the X7 series.
| Shape | CPU Cores | Memory |
|---|---|---|
| VM.Standard2.1 | 1 | 15 GB |
| VM.Standard2.2 | 2 | 30 GB |
| VM.Standard2.4 | 4 | 60 GB |
| VM.Standard2.8 | 8 | 120 GB |
| VM.Standard2.16 | 16 | 240 GB |
| VM.Standard2.24 | 24 | 320 GB |
Note:
- Intel X7 shapes are available for Oracle AI Database versions 26ai, 21c, and 19c only.
- VM.Standard2.1 shape cannot be used for multi-node RAC DB system.
Available Database Versions
OCI supports the creation of DB systems using older database versions, subject to the following shape requirements.
The latest approved Release Update is available by default. You can also select one of the two preceding Release Updates (N-1 or N-2) after acknowledging the message displayed. To use a Release Update older than N-2, you must submit a Service Request.
- Arm-based Ampere A1 shape is available for Oracle AI Database versions 26ai and 19c starting with the 23.7.0.0, 19.19.0.0, and later release updates (RU) only.
- AMD E5 shape is available for Oracle AI Database versions 26ai and 19c starting with the 23.4.0.24.05, 19.21.0.0, and later release updates (RU) only.
- AMD E4 shape is available for Oracle AI Database versions 26ai, 21c, and 19c with the 23.4.0.24.05, 21.6.0.0, 19.15.0.0, and later release updates (RU) only.
- Intel X9 shape is available for Oracle AI Database versions 26ai, 21c, and 19c with the 23.4.0.24.05, 21.8.0.0, 19.17.0.0, and later release updates (RU) only.
- Intel X7 shapes are available for Oracle AI Database versions 26ai, 21c, and 19c only.
- Migration from Intel X9 shape to AMD E4 and E5 shapes is not supported.
- Migration to AMD E4 shape is supported for instances using the base image with 21.6.0.0, 19.15.0.0, and later release updates only. For instances created before those release updates, updating and migrating them is not possible as the base image itself does not support migration.
- Migration to Intel X9 shape is supported for instances using the base image with 21.8.0.0, 19.17.0.0, and later release updates only. For instances created before those release updates, updating and migrating them is not possible as the base image itself does not support migration.
If you must create a DB system with an older database version, see Critical Patch Updates for information about known security issues with your chosen database version. You must also analyze and patch known security issues for the operating system included with the older database version. For information about security best practices for databases in OCI, see Securing Databases.
How various configurations affect the usable storage
The DB systems use OCI block storage. The following table shows details of the available storage options. Total storage includes available storage plus recovery logs.
General Information
- You can scale your data storage and recovery storage separately. Oracle recommends keeping recovery storage at 20% of total storage or higher.
- For multi-node RAC DB systems, storage capacity is shared between the nodes.
- The recovery area storage is determined based on the storage selected. However, you can change the recovery area storage independently after provisioning.
- The total storage is the sum of available data storage, recovery area storage, and 200 GB reserved for the DB system software.
Available data storage for flexible shapes
| Available data storage (GB) | Recovery area storage (GB) | Total storage (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 512 | 1736 |
| 2048 | 512 | 2760 |
| 4096 | 1024 | 5320 |
| 8192 | 2048 | 10440 |
| 12288 | 4096 | 16584 |
| 16384 | 4096 | 20680 |
| 24576 | 8192 | 32968 |
| 32768 | 8192 | 41160 |
| 40960 | 10240 | 51400 |
| 49152 | 12288 | 61640 |
| 57344 | 14336 | 71880 |
| 65536 | 16384 | 82120 |
| 73728 | 18432 | 92360 |
| 81920 | 20480 | 102600 |
Available data storage for standard shapes
| Available data storage (GB) | Recovery area storage (GB) | Total storage (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 256 | 1480 |
| 2048 | 408 | 2656 |
| 4096 | 820 | 5116 |
| 6144 | 1228 | 7572 |
| 8192 | 1640 | 10032 |
| 10240 | 2048 | 12488 |
| 12288 | 2456 | 14944 |
| 14336 | 2868 | 17404 |
| 16384 | 3276 | 19860 |
| 18432 | 3688 | 22320 |
| 20480 | 4096 | 24776 |
| 22528 | 4504 | 27232 |
| 24576 | 4916 | 29692 |
| 26624 | 5324 | 32148 |
| 28672 | 5736 | 34608 |
| 30720 | 6144 | 37064 |
| 32768 | 6552 | 39520 |
| 34816 | 6964 | 41980 |
| 36864 | 7372 | 44436 |
| 38912 | 7784 | 46896 |
| 40960 | 8192 | 49352 |
Service Limits
The following limits apply to the Base Database resources.
| Resources | Oracle Universal Credits | Pay As You Go or Trial |
|---|---|---|
| Total VM DB Block Storage | 150TB | 2TB |
| VM.Standard1 -Total OCPUs | 300 cores | 2 cores |
| VM.Standard2 -Total OCPUs | 300 cores for US West (Phoenix), 300 cores for US East (Ashburn), 50 cores for Germany Central (Frankfurt), 50 cores for UK South (London) |
2 cores |
Note: Total VM DB Block Storage includes block storage for all VM.Standard1 and VM.Standard2 virtual machine databases.
Fast Provisioning Option
For single-node DB systems, OCI provides a “fast provisioning” option that enables you to create a DB system using Logical Volume Manager (LVM) as your storage management software. The standard way (“standard provisioning”) is to provision with Automatic Storage Management (ASM).
The following details apply to the fast provisioning option:
- When using the fast provisioning option, the number and size of the block volumes specified during provisioning determines the maximum total storage available through scaling.
- Multi-node RAC DB systems require ASM and cannot be created using the fast provisioning option.
- You can clone DB systems that have been created using the fast provisioning option.
- You cannot use a custom database software image when provisioning a DB system with LVM.
For more information, see:
Storage Scaling Considerations While Using Fast Provisioning
Note: This topic applies only to single-node DB systems.
When you provision a DB system using the fast provisioning option, the Available storage (GB) value you specify during provisioning determines the maximum total storage available through scaling. The following table details the maximum storage value available through scaling for each setting offered in the provisioning workflow:
| Initial storage specified during provisioning (GB) | Maximum storage available through scaling (GB) |
|---|---|
| 256 | 2560 |
| 512 | 2560 |
| 1024 | 5120 |
| 2048 | 10240 |
| 4096 | 20480 |
| 8192 | 40960 |
Fault Domain Considerations for Multi-Node RAC DB Systems
When you provision a multi-node RAC DB systems, the system assigns each node to a different fault domain by default. Using the Advanced options link in the provisioning dialog, you can select the fault domain(s) to be used for your multi-node RAC DB systems and the system will assign the nodes to your selected fault domains. Oracle recommends that you place each node of a multi-node RAC DB system in a different fault domain.
For more information on fault domains, see Regions and Availability Domains.
Reboot a DB System Node for Planned Maintenance
The DB system nodes use underlying physical hosts that periodically must undergo maintenance. When such maintenance is required, OCI schedules a reboot of your DB system node and notifies you of the upcoming reboot. The reboot enables your DB system node to be migrated to a new physical host that is not in need of maintenance. (Stopping and starting the node will also result in the migration to a new physical host.) The only effect to your DB system node is the reboot itself. The planned maintenance of the original physical hardware takes place after your node has been migrated to its new host and has no effect on your DB system.
If your DB system node is scheduled for a maintenance reboot, you can proactively reboot your node (by stopping and starting it) using the Console or the API. This lets you control how and when your node experiences downtime. If you choose not to reboot before the scheduled time, then OCI will reboot and migrate your node at the scheduled time.
To identify the DB system nodes that you can proactively reboot, navigate to your system’s DB System Details page in the Console and check the Node maintenance reboot field. If the instance has a maintenance reboot scheduled and can be proactively rebooted, this field displays the date and start time for the reboot. When the Maintenance reboot field does not display a date, your DB system has no scheduled node maintenance events.
To check for scheduled maintenance events using the API, use the GetDbNode operation to check the timeMaintenanceWindowEnd field of the DbNode resource. This field specifies when the system will begin the next scheduled node reboot.
To locate nodes that have scheduled maintenance reboots, you can use the Search Service with a predefined query to find all DB systems that have a scheduled maintenance reboot.
For instructions about using the Console to reboot a node, see Reboot a DB System.
Security Hardening Tool for DB systems
The DB systems provisioned using Oracle Linux 7 include a Python script, referred to as the Security Technical Implementation Guide (STIG) tool, that you can use to perform security hardening for your DB system.
For more information, see:
- Security Technical Implementation Guide (STIG) Tool for the DB System.
- Enable FIPS, SE Linux, and STIG on the DB System Components.
Boot Volume Backups
Oracle maintains a weekly boot volume backup of your DB system so that the system can be easily restored in the event of a serious error or system failure. Boot volume backups are currently not accessible to users (there is no Console, API, or CLI access to a DB system boot volume backup), and Oracle bears the cost of keeping and maintaining the backup. In the event of a system failure, contact My Oracle Support to request that Oracle perform a restore of your DB system from the boot volume backup.