Oracle Database Cloud Service lets you easily build, scale, and secure Oracle databases in the cloud. You create databases on DB systems, which are either bare metal servers (with local NVMe flash or SSD storage) or virtual machines with block volumes, both of which provide high performance and cost-efficient pricing. The service also enables support for 'cloud-first' Oracle RAC implementation on virtual machine servers at the virtual cloud network layer.

You can manage your databases using simplified tools like patching, Data Guard or backup/recovery, all of which can be accessed using the Oracle Cloud Infrastructure REST APIs or console. Alternatively, you can access your database host and use your existing tools to manage your databases in the cloud, the same way you manage them on-premises.

Oracle Database Cloud Service provisions a DB system with the requested number of cores on a high performance bare metal server or virtual machine, deploys Oracle Database software with the edition of your choice, and creates the DB system in a virtual cloud network (VCN). The VCN is a private network with user-configured security lists which protects the DB system from unauthorized access.

Oracle Database Cloud Service also provides manageability features like database service patching, configuring high availability using Oracle Data Guard and backup/restore which simplifies day-to-day tasks required to run your Oracle databases.

Once you've created an Oracle Cloud Infrastructure account, you can create an Oracle database on Database Cloud Service by using the console, REST APIs, CLI and SDKs.

Both bare metal servers and virtual machines support Oracle's Universal Credit Model with both 'license included' and 'bring your own license' pricing. Pricing is flexible with both pay as you go option as well as discounted commit prices through Oracle Sales. Pricing depends on the selected database edition, database shape and number of cores you choose.

You can consume Oracle Database Cloud Service database instances by creating an account at shop.oracle.com. Alternatively, existing customers can contact their sales representative to create and account and enable an existing pool of credits, or purchase a new pool, to consume Oracle Cloud Infrastructure resources. Refer to database pricing section for more details.

Existing Metered/Non-Metered tenancies will be billed under their existing plan until converted to a Universal Credit Model tenancy.

Currently, Oracle Database Cloud Service supports Oracle Database versions 11.2.0.4, 12.1.0.2, 12.2.0.1, and 18.1.0.0.

The following Oracle Database software editions are supported and optimized for the cloud.

• Standard Edition
• Enterprise Edition
• Enterprise Edition High Performance
• Enterprise Edition Extreme Performance

The following list describes the database options available with each edition. Note that all packages include Oracle Database Transparent Data Encryption (TDE).

Bare Metal shapes
To meet the extreme performance demands of critical enterprise applications, Oracle Database Cloud Service supports three bare metal shapes that can achieve greater than 200,000 TPS or IOPS for a single database. Bare Metal DB systems use locally attached NVMe or SSD storage to ensure maximum performance. The amount of storage is determined by the shape specified when the DB system is launched.

Note that when using Standard Edition with High IO & Dense IO shapes, the maximum allowed OCPUs is 8 OCPUs per instance.

*BM.HighIO1.36 and BM.RACLocalStorage1.72* shapes are no longer available, but continue to be supported for existing customers.

Virtual Machine shapes
Oracle Database Cloud supports a variety of virtual machines based on Standard VM compute shapes. The choice of VM shapes provides cost efficiency and flexibility to select one to 24 cores and 256-GB to 40-TB of scalable and durable remote storage.

Note: For any shape greater than 2 cores, you can specify Total Number of nodes=2 to get RAC configuration. When using Standard Edition, the maximum allowed shape is VM.Standard1.8.

The following Oracle Database Cloud Service bare metal "X5" based Dense IO and Bring Your Own License options are no longer available, but continue to be supported for existing customers:

A DB system is a bare metal server or a virtual machine that has the Oracle Database software deployed and configured with a user-specified number of cores, software edition, and database version.

Yes. A bare metal DB system can have multiple DB Homes, which can have multiple databases within them. All the databases within a DB Home will have the same version, but each DB Home can have a different version. For example, an Enterprise Edition DB system might contain DB_Home11, which contains only Enterprise Edition 11.2.0.4 databases, and DB_Home12, which contains only Enterprise Edition 12.1.0.2 databases. Note, however, that Virtual Machine DB systems are single Database instances.

No, the edition can't be changed. However, you can easily terminate the DB system and launch another with the preferred edition.

When you launch a DB system, the initial database created on the system uses the default character sets AL32UTF8 and AL16UTF16. However, you can easily pick a character set of your choice during launch in the Database advanced options.

Yes, you can bring your own license. Oracle Database Cloud service supports both license included and BYOL pricing models.

Oracle highly recommends that you use Enterprise Manager for your database monitoring needs. Oracle plans to add support for returning metrics directly from the Database service soon.

Refer to the Service Limits documentation for the default limits for each instance type and instructions on how to request a service limit increase. We are happy to increase the limits for your account as needed.

Yes. Oracle Database Cloud Service supports a 'cloud-first' Oracle RAC on virtual machines within a virtual cloud network.

Oracle RAC on virtual machines is configurable by setting the "Total Number of Nodes" as 2 during the DB system launch.

Database Service on VMs is a database service offering that enables customers to build, scale, and manage full featured Oracle databases on virtual machines. The key benefits of running databases on VMs are cost effectiveness, ease of getting started, durable and scalable storage, and the ability to run Real Application Clusters (RAC) to improve availability.

RAC databases will run in a single Availability Domain (AD), while ensuring each node is on a separate physical rack ensuring high availability. Database Cloud Service on VMs is built on the same high performance, highly available cloud infrastructure used by all Oracle Cloud Infrastructure services.

Database service on VMs provides several benefits ranging from low cost to flexible storage. Specifically,

• Cost Effective & Flexible - Customers can start as low as single OCPU VM up to 24 OCPUs. Customers pay only for OCPUs and Storage used.
• Ease Of Getting Started - Customers can easily create Oracle Certified, full featured, fully supported 11g, 12c (both 12.1 & 12.2) databases with choice of any database edition.
• Built-in High Availability Constructs - Customers can easily deploy 2-node RAC configurations with all the VM shapes. For example: Easily deploy a 2-node RAC configuration with 2 core Virtual Machines and shared block storage of up to 40 TB.
• Durable & Scalable Storage - Customers can use remote storage starting 256GB up to 40 TB. Storage can be scale up with no downtime.
• Secure - Customers still get all the advantages of our Oracle IAM for management control and VCN Security lists for securing their database environments.

Yes, RAC (Real Application Cluster) databases are supported on Database Cloud Service on VMs as a 2-node RAC configuration. 2-node RAC is enabled by selecting node=2 when setting up your VM database. Note, only Enterprise Edition Extreme Performance supports RAC database and the minimum number of cores per VM is two.

No. Currently, you cannot change the number of cores used by the DB system after it is created.

No, you cannot create multiple DB Homes in a VM database. Each VM database instance can only launch one database per instance.

You can easily scale up storage for a DB system by using the console, REST APIs, CLI and SDKs. Database Cloud Service on VM uses remote block storage, so you can configure available storage anywhere from 256GB to 40TB. Scale up of storage happens without any downtime. Note: The total storage attached to an instance will be a sum of available storage, reco storage, and software size. Available storage is selected by the customer, reco storage is automatically calculated based on available storage, and software size is a fixed size Oracle database cost.

Oracle Cloud Infrastructure supports Oracle's Universal Credit Model with both license included and bring your own license pricing. Pricing is flexible with both pay as you go, as well as discounted commit prices through Oracle Sales. Oracle Database is charged on the following usage elements:

• Hosted Environment per hour - Hosted Environment is defined as the base DB system instance which has a base CPU capacity, local storage (for bare metal only), and enabled OCPUs for the edition of your choice. Each partial Hosted Environment Hour consumed is billed as a full hour.
• OCPU per hour - You can enable additional OCPUs per Hosted Environment or DB system. Each partial OCPU Hour consumed is billed as a full hour.
• Block volumes - Database service on VM uses remote block volumes. You can attach storage anywhere from 256GB to 40TB and pay for the total storage, which is the sum of available storage, reco storage, and software size. Available storage is selected by you, while Reco storage is automatically calculated based on available storage, and software size is a fixed size Oracle database cost. Please refer to Storage pricing for more details.
• Object storage - Your automatic incremental backups, on-demand full backups and on-premises to cloud backups are stored in Oracle Cloud Infrastructure Object Storage and you will be charged standard object storage cost. Please refer to Storage pricing for more details.

Refer to database pricing section from more details.

Oracle Database Cloud Service is on-demand and elastic, which means you are charged only for what you use. Your charges are rounded up to the hour. For example: if an instance runs for 45 minutes before being terminated, you are charged for an hour.

You can use the backup/restore feature or use RMAN to configure backups for our databases to Oracle Cloud Infrastructure Object Storage. The costs for the backups is the total amount of object storage in use and will adhere to the object storage pricing.

Setting up Data Guard across two DB systems deployed in separate Availability Domains configures high availability for your databases. The pricing for each DB system follows the standard pricing models described in database pricing.

Yes, Oracle Database Cloud Service supports stop billing for virtual machine databases. 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. For partial hours, you are billed for the maximum number of OCPUs used by the database system during that hour.

Stop billing is not applicable to Bare Metal Dense I/O or Exadata DB systems, and billing continues after stopping a node, since you continue hold on to the entire hosted environment. To reduce costs for Bare Metal Dense I/O or Exdata shapes you can make use of the online CPU scaling capability of the database shape and reduce the OCPUs to 2 for DenseIO and 0 for Exadata in unused and minor used environments. Setting the OCPU count to 0 in an Exadata Cloud Service will shut down the VMs as well as any databases 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 route 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:

• Deploying your databases into a private network, protected from the internet.
• Configuring security lists (inbound/outbound) to protect malicious users from accessing the DB system.

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.

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 bare metal and virtual machine DB systems only to a select set of users (DBAs) from a management perspective. Please refer to our technical documentation on how to use Oracle IAM with Oracle Database Cloud Service.

Yes, with full root access to the DB system you can configure auditing for all operations on the DB system. Oracle Database Cloud 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.

For the shapes offered today on Oracle Cloud Infrastructure, costs, available storage, performance or the need for Oracle RAC databases will drive your selection within the Database service. Keep your database size growth plan in mind as you select the shape.

Yes, for bare metal systems you can change the number of cores used by the DB system from the console directly or through our APIs without any downtime. Core scaling is currently not supported for virtual machines.

No, the instance is not restarted when scaled up or down. This capability allows you to save costs by reducing the number of cores used when not needed in Development and Test scenarios.

No, you cannot attach block storage volumes to a bare metal server DB system. However, the Database Cloud Service on virtual machines services uses remote block volumes for databases that are completely managed by the platform.

You are provided with full root access to your bare metal and virtual machine system. You can SSH into the DB system by using the SSH key information.

Oracle Database Cloud Service offers full root SSH access to the database instance and the capability to define the schemas and any performance tuning on the database instances. You can parse the Oracle trace file to understand the reason behind the slow queries. We also recommend using Enterprise Manager to monitor the performance metrics (CPU utilization, Network Throughput, etc.) of the DB system to understand if there are system level metrics that deviate from normal behavior.

You can get support for debugging and troubleshooting by submitting a service request via My Oracle Support. In addition, you can sign up for Oracle Premium Support, which provides options for 24x7 support. Contact your sales representative for more information.

The Database Cloud Service 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 home and submit a patching request. The Database Cloud Service will then run the end-to-end patching steps for you while displaying the status.

You can view all patches that have been applied, and if required, re-apply a patch. In addition, you can use Oracle Identity and Access Management (IAM) controls to manage access to patching features.

You can use the Oracle Cloud Infrastructure console and Rest APIs to access the feature.

Your DB system's cloud network (VCN) must be configured with an Internet Gateway. The network traffic between the DB system and Oracle Object Storage will be on Oracle Database Cloud Service internal servicing backbone

You can use the feature to patch all 1-node and 2-node bare metal DB systems across all shapes and editions. 2-node RAC, VMs, and Exadata Systems are currently not supported. However, you can patch these system by logging on to your host and using the OPatch utility.

Database Cloud Service specific patches for DB systems and database homes can be applied. Only the latest patch is available for DB systems while database homes supports both latest and older patches. You can find the list of currently available DB system and database home patches in the Oracle Cloud Infrastructure technical documentation.

Yes, if one or more patches are available for those versions. Patches are currently available for 11.2.0.4, 12.1.0.2 and 12.2.0.1 database versions.

You can log on to your host and apply interim patches using the OPatch utility. 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 Database Cloud Service console and REST APIs.

You can patch these systems by accessing your host and using the OPatch utility. Learn more about the OPatch utility.

Yes, there will be downtime for 1-node DB systems if you have not configured Oracle Data Guard. You should follow the Maximum Availability Architecture (MAA) best practices to avoid any downtime.

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 query the patch history for your DB system and database home to view the patches that were applied using Console, REST APIs, and SDKs.

Yes, your DB system should be on the same or higher version than your database home. To avoid version conflicts, you should apply DB system patches first, followed by database home patches. If you do not follow this order, you will get an error message while applying the patch.

Yes, you can pre-check a patch before applying. However, to rollback a patch, you need to login to your database host and use OPatch utility.

Yes, you can use Oracle Identity and Access Management (IAM) service to restrict access at a user and group level.

Yes, Oracle database bundle patches and Oracle Cloud Infrastructure database patches are different. Oracle Cloud Infrastructure database patches are a superset containing Oracle database bundle patches, Oracle Cloud Infrastructure-specific MLRs (Merge Label Requests), and other patches.

No, OS patching is currently not supported. You access the host directly to manually patch the OS. Refer to Bare Metal and Virtual Machine DB system OS Updatesand Exadata DB system OS Updates documentation for more details.

Yes, database patches are cumulative. New Oracle Cloud Infrastructure database patches contain patches from previous DB system or DB Home patches of the same version.

Oracle Cloud Infrastructure will send email notification informing you about a critical security patch. Depending on the criticality of the patch, we will set a time window for you to apply the security patch.

This depends on the type of patch. A DB system or database home state will change to ”Available” once a patch has been applied.

Backing up your database is a key aspect of any Oracle database environment. There are multiple options available for storing and recovering your backups. You can use the backup and restore feature either within the Oracle Cloud Infrastructure Console, CLI or REST APIs, or manually set up and manage backups using dbcli or RMAN. You can read about all the options in the technical documentation here.

The database backup and restore feature enables you to use the Oracle Cloud Infrastructure Console, CLI 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 provides Console, CLI 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 an existing or a new DB system.

Your backups are stored in Oracle Cloud Infrastructure Object Storage and the service fees apply for storing your backups. Learn more about Object Storage pricing. There are no additional charges for using the feature.

The backup and restore feature supports all bare metal and virtual machines shapes, editions, and database versions. Exadata is currently not supported. However, for Exadata, you can manually set up RMAN (Recovery Manager) for backup and recovery.

On-demand full backups and automatic incremental backups are currently supported.

The retention period for automatic incremental backups is 30 days.

No, you cannot control these settings using the backup and restore feature. However, you can use the manual RMAN option to set up custom retention period and frequency.

When you enable automatic backups for a database, Oracle Cloud Infrastructure Database Cloud Service will create the first level 0 backup. 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. Oracle 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 (00:00 - 06:00 UTC). If an automatic incremental backup fails, the Database Cloud 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.

If you are using the backup and restore feature, you can restore your database to the latest state, a point-in-time state, or to a committed state of database defined by System Change Number (SCN). However, you can use dbcli or RMAN option for more restore options.

You can find the SCN number either by accessing your database or accessing any online or archived logs.

Yes, you can create a new database from a backup in an existing or new DB system. However, the database from which the backup was generated should be deleted before using the backup for this purpose. For a backup from a virtual machine DB system, you should terminate the database instance from which backup was taken before using that backup in a new or an existing DB system.

Yes, you can choose any existing DB system, or create a new DB system in any compartment. However, the new or the existing DB system should be in the same Availability Domain where your backup is hosted. If you create a new DB system, the Oracle Database software edition you specify must be an equal or greater edition than that of the backed up database. Also, the shape you specify must be the same type as the database from which the backup was taken. For example, if you are using a backup of a 1-node database, then the DB system you select as your target must also be a 1-node DB system.

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.

Oracle highly recommends that you terminate all databases in a DB system before you terminate the DB system. When you terminate a database, you can select to create a final backup which will remain in Object Storage as a standalone backup. You can later restore this standalone backup as a new database.

You can manually set up RMAN to move your database backup to Oracle Cloud Infrastructure Object Storage, and use that backup to create a database in a new or existing DB system.

You can launch DB systems in different Availability Domains and configure Data Guard for setting up highly available Oracle databases. Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases.

You can review Data Guard for High Availability and Maximum Availability Architecture (MAA) best practices for information about setting up a zero data loss, highly available configuration of Oracle databases.

An Availability Domain (AD) is the subcomponent of a region designed to be independent and highly reliable. Each AD is built with fully independent infrastructure such as building(s), power generators, cooling equipment, and network connectivity. In the event of extremely uncommon disasters such as fires or flooding, only one AD is affected. In addition, the ADs within the same region are connected with high speed, low latency network, allowing customers to build and run highly reliable applications and workloads with minimum impact to the application latency and performance.

These fault-independent ADs enable customers to build highly available applications in the cloud without sacrificing performance. We highly recommend you place the primary and standby databases in different ADs to ensure they are protected from the common failures illustrated above.

All Enterprise database editions support Data Guard. Enterprise Extreme Performance edition supports Active Data Guard.

Database Cloud Service provides Data Guard configuration using 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. There is no cost associated with using this feature

All virtual machine and bare metal 1-node and 2-node shapes are supported by the Data Guard feature. Exadata is currently not supported. However, you can set up Data Guard manually for Exadata by logging on to you host and accessing Data Guard command-line interface (DGMGRL). Learn more about DGMGRL.

Switchover, Failover, and Reinstate features are currently supported. However, you can manually set up Data Guard by logging on to you host and accessing Data Guard command-line interface (DGMGRL). Learn more about DGMGRL.

Maximum Performance protection mode and Async transport type are currently supported. However, you can configure additional protection modes and transport types by logging on to the DB system and accessing Data Guard command-line interface( DGMGRL). Learn more about DGMGRL.

To set up Data Guard, both primary and secondary DB systems should be in the same VCN, and port 1521 should be open on both DB systems. DB systems can be in different subnets.

Yes, you can set up Data Guard in the same or different Availability Domains in a region. However, Oracle recommends that you set up your Data Guard configuration across Availability Domains.

Yes, you can set up Data Guard across regions, but the Database Cloud Service Data Guard feature currently does not support it. You can manually set up Data Guard across regions by logging on to your host and using DGMGRL. You must enable an internet gateway on the primary and standby DB system VCN for Data Guard to transport logs across regions. Learn more about DGMGRL.

No, cross-compartment Data Guard set up is currently not supported.

Yes, to enable a Data Guard association using the Data Guard feature, the standby’s DB system shape and edition should be the same as the primary’s DB system.

The standby database is created with the same database version as that of the primary.

No, currently the Managed Broker feature is not supported by the Data Guard feature. However, you can manually set up Managed Broker configurations by logging on to your database host and accessing Data Guard command-line interface (DGMGRL). Learn more about DGMGRL.

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.

Using the Data Guard feature, you will need to first delete your standby database before you can delete your primary database. Alternatively, you can initiate a switchover operation so the primary is now a standby, and then you can terminate the standby.

No, you can only create a single physical standby database using the Data Guard feature. However, you can manually create multiple standby databases by logging on to your DB system and accessing DGMGRL. Learn more about DGMGRL.

Yes, you can configure Data Guard between an on-premises database and an Oracle Cloud Infrastructure database. You can manually set up Data Guard between your on-premises database and an Oracle Cloud Infrastructure database using DGMGRL. Learn more about DGMGRL.

Yes, you can control access to Data Guard features using Oracle Identity and Access Management. Learn more about Oracle Identity and Access Management.

You can patch database in primary and standby Data Guard set up. You need to manually patch your standby first, and then switch over your primary to patch it.

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).

Using the Data Guard feature, once you fail over your primary database, it assumes a “Disabled Standby” state. After you fix the issue with this disabled standby, you can reinstate it to a functioning Standby role. Then, you can switch over this standby database back to the primary role.

Yes, with Active Data Guard set up, you can use the standby instances for read only operations. Write operations are not enabled on a standby.

Our recommendation is to use Enterprise Manager for monitoring your DB systems managed by Oracle Cloud Infrastructure. If you enable audit log operations on the instance, you can also view the logs to understand when the primary failed over.

For 2-node RAC configurations, the failover should be in tens of seconds. However, if the failover is between two instances that are in different ADs with Data Guard, the failover should be less than two minutes.

No, the 2-node RAC shape is a set on two servers within the same AD but different racks. Storage is shared across both instances. This set up protects against hardware failures on the instance. For higher availability, we recommend that your set up another 2-node RAC shape in a separate AD.

Yes, with root access to the DB system, you can review and audit all the operations for the databases on the DB system.