Oracle Database Cloud Service runs Enterprise and Standard Edition databases on Virtual Machine (VM) DB Systems and enables you to easily build, scale, and secure Oracle databases cost-effectively in the cloud. You create databases on virtual machines with block volumes and have a choice of compute shapes and storage capacity. The service provides built-in automation for common database lifecycle management tasks such as patching, backup/recovery, and enabling Oracle Data Guard, all of which can be performed using the Oracle Cloud Infrastructure console or REST APIs. It also supports a 'cloud-first' Oracle RAC implementation on virtual machines at the virtual cloud network layer.
Once you've created an Oracle Cloud Infrastructure account, you must first create a virtual cloud network (VCN) prior to creating your first database. A VCN is a virtual, private network that you set up in Oracle data centers. It closely resembles a traditional network, with firewall rules and specific types of communication gateways that you can choose to use. From there, you can create an Oracle database in a DB System using the console, REST APIs, CLI and SDKs.
The service supports Oracle's Universal Credit Model (UCM) with 'license included' and 'bring your own license' (BYOL) pricing. Pricing is flexible, with pay-as-you-go (PAYG) and Oracle Annual Universal Credit options available. Pricing depends on the selected database edition, database shape, number of OCPUs, and storage capacity you choose. Refer to pricing for virtual machines section for more details. Existing metered/non-metered tenancies will be billed under their existing plan until converted to a Universal Credit Model tenancy.
Refer to the Oracle Universal Credit pricing FAQ for more information.
Currently, Oracle database versions 184.108.40.206, 220.127.116.11, 19c, and 21c are supported.
The following Oracle Database license-included software editions are supported and optimized for the cloud.
You can also bring your own license (BYOL).
All editions include Oracle Database Transparent Data Encryption, Machine Learning, and Spatial and Graph.
A DB System is a virtual machine that has Oracle Database software deployed and configured with a user-specified number of cores, software edition, and database version.
The technical documentation for DB Systems is part of OCI documentation.
DB Systems are available in various shapes and options. Refer to the DB Systems section of the documentation for the latest details on shapes.
Performance, storage capacity, cost, among other criteria, will drive your shape selection.
The Oracle Cloud Infrastructure (OCI) console, REST APIs, SDK, or CLI can be used to perform common database lifecycle management tasks such as patching, Oracle Data Guard, and backup/recovery.
Oracle provides customers a choice of cloud and on-premises manageability and monitoring options. These include Enterprise Manager, Management Cloud Service, and External Database Service.
Yes. 2-node Oracle RAC on virtual machines within a virtual cloud network is available. Oracle RAC on virtual machines is configurable by setting the "Total Number of Nodes" as 2 when selecting the options for provisioning a DB System.
No. Oracle RAC databases are supported with Enterprise Edition Extreme Performance on Virtual Machine DB Systems, but are limited to a 2-node RAC configuration.
No. The virtual machines for 2-node RAC are deployed on separate servers and racks within the same Availability Domain. Storage is shared across both database instances. This setup protects against server failures and rack power failures. For higher availability, it is recommended that you enable Oracle Data Guard with a standby 2-node RAC Virtual Machine DB System in a separate Availability Domain.
Virtual Machine DB Systems only contain one container database (CDB). However, the container database can have multiple pluggable databases (PDBs). A single CDB with a single PDB is created by default when the Virtual Machine DB System is created. The service offers integrated PDB lifecycle management.
Yes, you can scale the number of OCPUs up and down as required. However, scaling the OCPUs will require changing the Virtual Machine shape and will result in a database outage. For 2-node RAC Virtual Machine DB systems, the shape is changed one Virtual Machine at a time in a rolling manner.
Yes. A Virtual Machine DB System uses block storage volumes, so you can configure available storage anywhere from 256 GB to 40 TB. You can scale up the storage capacity without downtime. Scaling the storage down requires migrating to a new Virtual Machine DB System.
Yes, you can clone a Virtual Machine DB System that uses either Logical Volume Manager (LVM) or Grid Infrastructure/ASM for storage management software. Cloning a Virtual Machine DB System creates a copy of the source database at the time of the cloning operation, including software and database volumes.
Oracle offers a wide range of Oracle Database Cloud Migration solutions.
Oracle’s Universal Credit purchase model offers simple and flexible pricing models. Pay-as-you-go (PAYG) pricing lets customers quickly provision services with no upfront commitment, no minimum service period, and pay only for what they use, which will be billed monthly in arrears. Annual Universal Credits enable customers to use any eligible Oracle Cloud Infrastructure and platform services at any time, in any region. Annual Universal Credits are billed in advance and offer significant savings across cloud services, combining cost reduction and a predictable monthly spend with a ramp-up period as you onboard your workloads.
Refer to the Oracle Universal Credit pricing FAQ for more information.
For Virtual Machine DB Systems, there are 3 metering components: OCPU usage and Block storage usage are required. Object storage usage is optional.
Both license included and bring your own license (BYOL) licensing models are charged based on OCPU usage. OCPU usage per hour is billed based on Virtual Machine DB System shape. Each partial OCPU hour consumed is billed as partial hour with a one-minute minimum.
Virtual Machine DB Systems use remote block volumes. You can attach storage anywhere from 256 GB to 40 TB and pay for the total storage. Only Oracle Cloud Infrastructure Block Volume Service with balanced performance is supported. OCI block storage volumes with balanced performance is defined as 1 unit of block volume storage with 10 units of block volume performance per gigabyte per month.
You can use the backup/restore feature or use RMAN to configure backups for your databases in Oracle Cloud Infrastructure Object Storage. The billing for the backups is based on the total amount of object storage in use.
Refer to Cloud Price List for more details.
Yes, you change the licensing model from license included to BYOL and vice versa.
Yes. Stop billing is supported on Virtual Machine DB Systems. To take advantage of this capability, go to the Virtual Machine DB System and select the desired node to stop. The database remains intact while the node is stopped. You are not billed for hours the node is not running.
A VCN is a customizable private network in Oracle Cloud Infrastructure. Just like a traditional data center network, a VCN provides you with complete control over your network environment. This includes assigning your own private IP address space, creating subnets, creating routing tables and configuring stateful firewalls. A single tenant can have multiple VCNs, thereby providing grouping and isolation of related resources.
By deploying into a VCN by default, you get the security and flexibility of:
We highly recommend that you create separate subnets in each Availability Domain and place your DB Systems in those subnets. This allows you to precisely define inbound/outbound security lists for the subnet and control network access.
DB Systems are configured with TDE by default during provisioning. You have the flexibility to log in and control other security policies on the DB System. You can follow the standard database security best practices (PDF).
With Oracle Cloud Infrastructure Identity and Access Management (IAM), you can configure your cloud environment to support your security and compliance requirements. From a database perspective, you configure IAM policies that allow you to restrict access to DB Systems only to a select set of users (DBAs) from a management perspective. Please refer to the documentation on how to use Oracle IAM.
Yes. With full root access to the DB System you can configure auditing for all operations on the DB System. The service provides robust audit support in all editions of the database. Audit records include information about the operation that was audited, the user performing the operation, and the date and time of the operation. Audit records can be stored in the database audit trail or in files on the operating system. Standard auditing includes operations on privileges, schemas, objects, and statements. In addition, you can use Oracle Cloud Infrastructure Audit to audit all the API management calls that were made on your tenancy.
Yes. All Oracle Database security options are supported.
Oracle Data Safe is a cloud native service that provides security features such as assessments, auditing, and data masking, and is free to use with DB Systems.
The patching feature simplifies the steps required to patch your DB Systems and databases. You can use the Oracle Cloud Infrastructure console and APIs to view applicable patches for your DB System or database and submit a patching request. The service will then run the end-to-end patching steps while displaying the status. You can view all patches that have been applied, and if required, rollback a patch, or reapply a patch. In addition, you can use Oracle Identity and Access Management (IAM) controls to manage access to patching features.
Your DB System’s cloud network (VCN) must be able to access patches stored in Oracle Cloud Infrastructure Object Storage. You can do this by configuring a service gateway, which enables cloud resources without public IP addresses to privately access Oracle services such as Oracle Object Storage.
Service specific patches for DB Systems and databases can be applied. Only the latest patch is available for DB Systems while both the latest and older database patches are available. You can find the list of currently available DB System and database patches in the Patching a DB System documentation.
Use custom database software images to apply interim patches or one-offs. We recommend that you do not apply on-premises quarterly bundle patches using the OPatch utility. These patches may not work without applying additional cloud specific patches. Instead, you should apply cloud-customized quarterly patches that are available through the Oracle Cloud Infrastructure console and REST APIs.
Yes. Custom database software images can be used.
Yes. There will be downtime for 1-node Virtual Machine DB Systems. 2-node RAC Virtual Machine DB System patching is rolling, 1-node at a time. You can also configure Oracle Data Guard to minimize downtime. Follow the Maximum Availability Architecture (MAA) best practices.
Your DB System or database home will be in the ”Available” state if the patch fails. The patch history can indicate the reason the operation failed. To debug the root cause of failure, you can access detailed patching-related logs by accessing your host. If the log information is not helpful in debugging the issue, you can file a request with Oracle Support to help determine the root cause.
You can view the patch history for your DB System and database that were applied using Console and REST APIs.
Yes, your DB System should be on the same or higher version than your database. To avoid version conflicts, you should apply DB System patches first, followed by database patches. If you do not follow this order, you will get an error message while applying the patch.
Yes. Oracle database bundle patches and DB System database patches are different. DB System database patches are a superset containing Oracle Database bundle patches, Oracle Cloud Infrastructure patches along with other patches.
Yes. DB System patches include Grid Infrastructure patches and are available for DB Systems using Grid Infrastructure/ASM storage management. DB System patches don’t include OS updates.
No. OS patching is currently not supported. You must access the host directly to manually patch the OS through the command line. Refer to Bare Metal and Virtual Machine DB System OS Updates.
Yes. Database patches are cumulative. New patches contain patches from previous DB System or database patches of the same version.
The database backup and restore feature enables you to use the Console and REST APIs to create and manage backups of your databases. You can also restore your existing database from a backup or create a new database from a backup.
The backup and restore feature enables the Console and Rest APIs to create and manage backups. When you use the Console, you can create full backups or set up automatic incremental backups with a few clicks. Similarly, you can view your backups and restore your database using the last known good state, a point in time, or SCN (System Change Number). You can also create a new database from your backup in a new DB System.
The retention period for automatic incremental backups is 7, 15, 30, 45, or 60 days. You select your desired retention period when the automatic backups are enabled. You cannot set your own retention period or frequency of automatic incremental backups.
When you enable automatic backups for a database, a first level 0 backup will be created. After the first backup, level 1 backups will run every day until the next weekend. Every weekend, a new level 0 backup will be created. Automatic backups enabled for the first time after November 20, 2018 on any database will run between 00:00 AM and 06:00 AM in the time zone of the DB System's region. If you have enabled automatic backups on a database before this date, the backup window for the database will continue to be between 00:00 AM and 06:00 AM UTC.
Yes. All your backups are encrypted with the same master key used for TDE encryption.
Your backups are stored in Oracle Cloud Infrastructure Object Storage. Object Storage was designed from the ground up to be highly durable. Data is stored redundantly across multiple storage servers and across multiple Availability Domains. Data integrity is actively monitored using checksums, and corrupt data is detected and auto-repaired. Any loss in data redundancy is automatically detected and self-healed, without any customer impact.
If you are using the backup and restore feature, your backup operations can fail if the database or DB System is not in an ”Available” state. Actions like patching, SSH key addition, and Data Guard operations can change the DB System or database state. To avoid backup failure, ensure that these actions are not performed during the backup window. If an automatic incremental backup fails, the service retries the backup operation during the next day’s backup window. For a failed on-demand backup, you must manually retry the operation when both DB System and database is available.
No. Automatic incremental backups are not enabled by default. You can enable the option during database creation or at any time after the database is provisioned.
Automatic backups are deleted when a DB System is terminated. On-demand full backups remain in Oracle Object Storage as standalone backups when a DB System is terminated. You can later restore standalone backups to a new database on a DB System.
2-node RAC Virtual Machine DB Systems protect against downtime due to server or database instance failure. You can also launch DB Systems in different Availability Domains or Regions and configure Oracle Data Guard between them.
Review Data Guard for High Availability and Maximum Availability Architecture (MAA) best practices for more information about setting up a highly available configuration for Oracle databases.
All Enterprise database editions support Data Guard. Enterprise Extreme Performance edition supports Active Data Guard.
Enabling Oracle Data Guard is available through the Oracle Cloud Infrastructure console and REST APIs. In a few clicks, you can enable Data Guard and perform switchover, failover, and reinstate actions. You can also set up granular access control for the feature using Oracle Identity and Access Management Service.
Maximum Performance protection mode with ASYNC transport type and Maximum Availability with SYNC transport type are supported.
To remove the Data Guard association using the Data Guard feature, you must first delete the standby database. Once you delete the standby database, the Data Guard association will be removed automatically.
The standby database is created with the same database version as that of the primary.
Yes, you can configure Data Guard between an on-premises database and a database running on a DB System in Oracle Cloud Infrastructure. You can manually set up Data Guard between your on-premises database and a service database using DGMGRL. Learn more about DGMGRL.
You can patch databases in primary and standby Data Guard setup. You should patch the standby first, switch over to your standby, and then patch your primary.
You can use the Oracle Cloud Infrastructure Database backup and restore feature to back up and restore your primary databases. If you want to enable backup for a standby, you can do so by accessing your standby database host and using RMAN (Recovery Manager).
Yes. With Active Data Guard set up, you can use the standby databases for read only operations. Write operations are not enabled on a standby.
No, you cannot setup FSFO with the Data Guard feature. However, it can be configured manually. You should deploy it in a virtual machine in a separate Availability Domain if possible.