Oracle Base Database Service (formerly known as Oracle Database Cloud Service) consists of Enterprise Database Service and Standard Database Service running on virtual machine (VM) database systems. It enables you to easily and cost effectively build, scale, and secure Oracle Enterprise Edition and Standard Edition databases in Oracle Cloud Infrastructure (OCI). You create databases on virtual machines with a choice of compute shapes and block volume storage capacity. The service provides built-in automation for common database lifecycle management tasks, such as updating, backup/recovery, and enabling Oracle Data Guard—all of which can be performed using the OCI console or REST APIs.
Once you've created an OCI 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 database 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 19c, 21c, and 23c 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 database 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 database systems is part of the OCI documentation.
Database systems are available with AMD Standard E4 Flex, Intel X9 Standard 3 Flex, or Ampere Standard A1 Flex shapes. For the latest details on available shapes, refer to About virtual machine database systems in the documentation.
VM database systems are available with either higher performance or balanced performance block volume storage.
Performance, storage capacity, cost, among other criteria, will drive your shape selection.
Yes. Events impacting database systems are available through the events service. Refer to the documentation for a list of event types for database systems.
Yes. Two-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 database system.
No. Oracle RAC databases are supported with Enterprise Edition Extreme Performance on virtual machine database systems, but are limited to a two-node Oracle RAC configuration.
No. The virtual machines for two-node Oracle 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 two-node Oracle RAC virtual machine database system in a separate availability domain.
Virtual machine database 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 database 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 database systems, the shape is changed one virtual machine at a time in a rolling manner.
Yes. A virtual machine database system uses block volume storage, so you can configure available storage anywhere from 256 GB to 80 TB. You can scale up the storage capacity without downtime. Scaling the storage down requires migrating to a new virtual machine database system.
Yes, you can clone a virtual machine database system that uses either Logical Volume Manager (LVM) or Grid Infrastructure/ASM for storage management software. Cloning a virtual machine database 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 you quickly provision services with no upfront commitment, no minimum service period, and pay only for what you use, which will be billed monthly in arrears. Annual Universal Credits enable you to use any eligible OCI 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 database systems, there are three metering components: OCPU usage and Block Volume storage usage are required. Oracle Database Autonomous Recovery Service and Oracle Cloud Infrastructure (OCI) Object Storage are 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 database system shape. Each partial OCPU hour consumed is billed as partial hour with a one-minute minimum.
Virtual machine database systems use remote block volume storage. You can attach up to 100 TB total storage which consists of up to 80 TB for data storage and up to 20 TB for recovery storage. You pay for the total storage. You can choose block storage volumes with either higher performance or balanced performance. Block storage volumes with higher performance is defined as 1 unit of block volume storage with 20 units of block volume performance per gigabyte per month. 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 to configure backups for your databases to Database Autonomous Recovery Service or OCI Object Storage. The billing for the backups is based on the total amount of storage in use.
Refer to the 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 database systems. To take advantage of this capability, go to the virtual machine database 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 OCI. 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, which will provide grouping and isolation of related resources.
Deploying into a VCN by default also provides security and flexibility by:
We highly recommend that you create separate subnets in each availability domain and place your database systems in those subnets. This allows you to precisely define inbound/outbound security lists for the subnet and control network access.
Database systems are configured with TDE by default during provisioning. Refer to the TDE FAQ for more details regarding TDE. You also have the flexibility to log in and control other security policies on the database system.
You can use OCI Vault service with customer-managed encryption keys. Oracle-managed encryption keys are also available. Refer to the documentation for Database Encryption Keys.
With Oracle 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 database systems only to a select set of users (DBAs). Refer to the documentation on how to use Oracle IAM.
Yes. With full root access to the database system you can configure auditing for all operations on the database 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 OCI 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 database systems.
The updating feature simplifies the steps required to update your database systems and databases. You can use the OCI console and APIs to view applicable updates for your database system or database and submit an updating request. The service will then run the end-to-end updating steps while displaying the status. You can view all updates that have been applied, and if required, rollback or reapply an update. In addition, you can use Oracle Identity and Access Management (IAM) controls to manage access to updating features.
Your database system’s cloud network (VCN) must be able to access updates stored in OCI 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 updates for database systems and databases can be applied. Database systems have only the latest update available. Databases have both the latest update as well as older database updates available. You can find the list of currently available database system and database updates in Update a database system.
Use custom database software images to apply interim updates or one-offs. We recommend that you do not apply on-premises quarterly bundle updates using the OPatch utility. These updates may not work without applying additional cloud specific updates. Instead, you should apply cloud-customized quarterly updates 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 database systems. 2-node RAC virtual machine database system updating 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 database system or database home will be in the ”Available” state if the update fails. The update history can indicate the reason the operation failed. To debug the root cause of failure, you can access detailed updating-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 update history for your database system and database that were applied using OCI console and REST APIs.
Yes, your database system should be on the same or higher version than your database. To avoid version conflicts, you should apply database system updates first, followed by database updates. If you do not follow this order, you will get an error message while applying the update.
Yes. Oracle Database bundle updates and database system database updates are different. Database system database updates are a superset containing Oracle Database bundle updates and OCI updates, along with other updates.
Yes, database system updates include Grid Infrastructure updates and are available for database systems using Grid Infrastructure/ASM storage management. Database system updates don’t include OS updates.
OS updates are currently not supported through the OCI console or APIs using the patching feature. You must access the host directly to manually update the OS through the command line. Refer to the documentation for virtual machine database system OS updates.
Yes. Database updates are cumulative. New updates contain updates from previous database system or database updates of the same version.
Oracle Database Autonomous Recovery Service and Oracle Cloud Infrastructure (OCI) Object Storage can be used as backup destinations. Refer to Recovery Service Concepts and OCI Object Storage Overview for more details.
Autonomous Recovery Service is a fully managed, standalone, and centralized cloud backup solution for OCI databases. Recovery Service is designed to leverage the combined capabilities of Zero Data Loss Recovery Appliance and Oracle Recovery Manager (Oracle RMAN). When using Autonomous Recovery Service for automatic backups, there’s no need to perform weekly full backups. Autonomous Recovery Service uses virtual full backups to perform database recovery, which allows for faster recovery because there are no daily incremental backups. When the real-time data protection feature is enabled, Autonomous Recovery Service provides a better recovery point objective (RPO) than backups to Object Storage as the redo log changes are continuously transferred from the protected database.
Autonomous Recovery Service provides an optimized policy-driven automatic backup and recovery solution. Zero Data Loss Autonomous Recovery Service is an optional feature for Autonomous Recovery Service that offers real-time data protection to protect databases with zero data loss recovery in the event of a database failure. Real-time Data Protection is the continuous transfer of redo changes from a protected database to Autonomous Recovery Service. This feature reduces data loss and provides an RPO near 0. Since the real-time data protection feature is an extra-cost option, you can choose to enable or disable it when you are configuring automatic database backups.
Yes. Your backups are encrypted with the same master key used for encrypting your database.
The Oracle-managed automatic backups feature is the preferred method for backing up the database. You can use the OCI console or 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. Refer to Managed Backup Features and Backup Automation and Storage in Oracle Cloud for more details.
Automated backups are more reliable, consistent, and less error-prone than manual backups. You can use either the OCI console or Rest APIs to easily create and manage backups. When you use the console, you can create on-demand 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 database system. Refer to Recover a Database Using the Console and Ways to Manage the Recovery Service Resources for more details.
If an automatic backup operation fails, the database service retries the operation during the next day's backup window. If an on-demand full backup fails, you can try the operation again when the database system and database availability are restored. Failed backups are reported on the OCI console. For database systems using the Zero Data Loss Autonomous Recovery Service real-time data protection feature, the skipped backup does not cause data loss as database recoverability continues to be available by using the shipped redo logs.
No. Automatic backups are not enabled by default. You can enable the option during database creation or at any time after the database is provisioned. For more information, refer to Backing Up Oracle Cloud Databases to Recovery Service.
The available retention period for automatic backups is based on the backup destination type that is chosen.
When you choose the Autonomous Recovery Service for the backup destination:
When you choose OCI Object Storage for the backup destination:
You cannot set your own retention period or frequency of automatic incremental backups.
Daily Level 1 backups are incremental backups that are created each day for the six days following the Level 0 backup day. Archive redo log backups are conducted with a minimum frequency of every 60 minutes.
When you enable automatic backups for a database, an initial Level 0 backup will be created. For automatic backups to OCI Object Storage, full backups are done once a week with daily incremental backups in between. For automatic backups to the Autonomous Recovery Service, only daily incremental backups are done after the initial full backup.
You can schedule the day of the week for the automatic full backup to occur along with a 2-hour window for when the full backup should start. You can also schedule a 2-hour window for when the daily incremental backups should start.
For OCI Object Storage automatic backup destinations:
For Autonomous Recovery Service automatic backup destinations, you can choose how backups are managed after a database is terminated:
For OCI Object Storage backup destinations, your backups are stored in OCI Object Storage. OCI 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 automatically repaired. Any loss in data redundancy is automatically detected and self-healed, without any customer impact. Refer to Object Storage Characteristics for more details.
For Recovery Service backup destinations, Recovery Service offers many layers of protection. Backups are routinely validated and stored on highly redundant storage and distributed across different availability domains. Data integrity is actively monitored using checksums, and corrupt data is detected and automatically repaired. Any loss in data redundancy is automatically detected and self-healed, without any customer impact. Refer to Recovery Service Concepts for more details.
2-node RAC virtual machine database systems protect against downtime due to server or database instance failure. You can also launch database 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 OCI 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.
By default, the standby database is created with the same database version as that of the primary. However, you can choose the same or higher version by using a custom database software image for your standby database.
Yes, you can configure Data Guard between an on-premises database and a database running on a database system in OCI. You can manually set up Data Guard between your on-premises database and a service database using DGMGRL. Learn more about DGMGRL.
You can update databases in primary and standby Data Guard setup. You should update the standby first, switch over to your standby, and then update your primary.
You can use the OCI 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).
With Active Data Guard, you can use the standby database for read only operations.
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.