Cloning an Autonomous Database on Shared Exadata Infrastructure

This topic describes how to create a non-refreshable clone of an existing Autonomous Database on shared Exadata infrastructure using the Oracle Cloud Infrastructure Console or the API. For information on creating clones using dedicated Exadata infrastructure, see Clone a Dedicated Autonomous Database

You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option. For information on creating refreshable clones, see Using Refreshable Clones with Autonomous Database.


  • You can clone any existing Autonomous Database (including those provisioned with preview version software) using a preview version of Autonomous Database. However, preview-version databases cannot be cloned using the regular (general-availability) Autonomous Database software.
  • You cannot clone an Autonomous Database from one Autonomous Container Database to another Autonomous Container Database if one of the Autonomous Container Databases has different encryption management configured. Encryption management must be the same for both Autonomous Container Databases, either Oracle-managed or customer-managed.

Clone Types

The clone feature offers the following types of Autonomous Database clones:

  • Full clone: This option creates a database that includes the metadata and data from the source database.
  • Metadata clone: This option creates a database that includes only the metadata from the source database.
  • Refreshable clone: This option creates a clone that can be easily updated with changes from the source database. For information about creating and using refreshable clones, see Using Refreshable Clones with Autonomous Database.

Clone Sources

You can use a running database to create a clone. For databases running on shared Exadata infrastructure, you can also use a backup as the source of your clone. When using a backup, you can select a listed backup to clone from, or create a point-in-time clone. Point-in-time clones contain all data up to a specified timestamp. The specified timestamp must be in the past.


To clone an Autonomous Database, you must have the required type of access in a policy  written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which compartment  you should work in. See Authentication and Authorization for more information on user authorizations for the Oracle Cloud Infrastructure Database service.


You can't clone a database in a security zone to create a database that isn't in the same security zone. This is true whether the source is a running database or a database backup. See Security Zone Policies for a full list of policies that affect Database service resources.

Using the Oracle Cloud Infrastructure Console


See Create a Refreshable Clone for an Autonomous Database Instance for instructions for creating a refreshable clone.
To clone an Autonomous Database to shared Exadata infrastructure
  1. Open the navigation menu. Click Oracle Database. Under Autonomous Database, click Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  2. If you are not already in the correct compartment, then choose one from the Compartment drop-down in the List Scope section that contains the database you want to clone.
  3. In the list of Autonomous Databases, click the display name of the database you want to clone.
  4. Go to More Actions, and then click Create Clone. The Create Autonomous Database Clone dialog opens, and you can configure the fields details in the steps below.
  5. Clone Type: Select the type of clone you want to create. Choose either Full Clone or Metadata Clone to create a standalone clone that cannot be refreshed with data from the source database. For information on creating and using refreshable clones, see Using Refreshable Clones with Autonomous Database.
  6. Clone Source: The clone source selection allows you to specify whether the clone is created from a running database or from a database backup. Select one of the following options:

    • Clone from running database: Creates a clone of a running database as it exists at the current moment.
    • Clone from a backup: Creates a clone from a database backup. If you choose this option, select one of the following options:

      • Specify a timestamp: Creates a point-in-time clone.
      • Select from a list of backups: Creates a clone using all data from the specified backup. To limit your list of backups to a specific date range, enter the starting date in the From field and the ending date in the To field.

  7. Database Information:

    • Compartment:Your current compartment is the default selection.
    • Display name: A user-friendly description or other information that helps you easily identify the resource. The display name does not have to be unique, and you can change it whenever you like. Avoid entering confidential information.
    • Database name: Specify the database name; it must consist of letters and numbers only. The maximum length is 30 characters. The same database name cannot be used for multiple Autonomous Databases in the same tenancy in the same region.
    • Choose database version: Select a database version from the available versions.
    • OCPU count: You can enable up to 128 cores for your Autonomous Database. The actual number of available cores is subject to your tenancy's service limits.

      Auto scaling: allows Autonomous Database to automatically increase the number of CPU cores by up to three times the assigned CPU core count value, depending on demand for processing. The auto scaling feature reduces the number of CPU cores when additional cores are not needed. For databases with up to 42 assigned cores, you can increase the maximum number of cores available through auto scaling by increasing the CPU core count value. See CPU Scaling for more information.


      The maximum number of cores that are available to any Autonomous Database database not using dedicated Exadata infrastructure is 128, regardless of whether auto scaling is enabled or not. This means that database with a CPU core count of 64 could auto scale up to two times the assigned number of cores (2 x 64 = 128). A database with 42 cores (or fewer) could auto scale up to three times the assigned number (3 x 42 = 126). For billing purposes, the database service determines the average number of CPUs used per hour.
    • Storage: Specify the storage you wish to make available to your Autonomous Database database, in terabytes. You can make up to 128 TB available. For full clones, the size of the source database determines the minimum amount of storage you can make available.
    • Patch level: By default the patch level is Regular. Select Early to configure the instance with the early patch level. When cloning a source database with Early patch level, you can only choose the Early patch level for your clone. Note: You cannot change the patching cycle after you provision an instance. See Setting the Patch Level for more information.
    • Enable Preview Version: (This option only displays during periods when a preview version of Autonomous Database is available) Select this option to provision the database with an Autonomous Database preview version. Preview versions of Autonomous Database are made available for limited periods for testing purposes. Do not select this option if you are provisioning a database for production purposes or if you will need the database to persist beyond the limited availability period of the preview version.
  8. Administrator Credentials: Set the password for the Autonomous Database Admin user by entering a password that meets the following criteria. You use this password when accessing the Autonomous Database service console and when using an SQL client tool.

    • Password cannot be one of the three most recently used passwords of the source database
    • Contains from 12 to 30 characters
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing
  9. Choose the type of network access.

    Require mutual TLS (mTLS) authentication Optionally, when you select either Secure access from allowed IPs and VCNs only or Virtual cloud network, you can choose to allow only mutual TLS (mTLS) authentication, or to allow both mTLS and TLS authentication. By default, the option is set to allow mTLS authentication only. For more information on mTLS and TLS authentication, see Secure Connections to Autonomous Database.

  10. License Type: The type of license you want to use for the Autonomous Transaction Processing database. Your choice affects metering for billing. You have the following options:

    • My Organization Already Owns Oracle Database Software Licenses: This choice is used for the Bring Your Own License (BYOL) license type. If you choose this option, make sure you have proper entitlements to use for new service instances that you create.
    • Subscribe to New Database Software Licenses and the Database Cloud Service: This is used for the License Included license type. With this choice, the cost of the cloud service includes a license for the Database service.
  11. Click Create Autonomous Database Clone.

The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:

  • The new clone displays the Provisioning lifecycle state until the provisioning process completes.
  • The source database remains in the Available lifecycle state.
  • Backups associated with the source database are not cloned for either the full clone or the metadata clone option.
  • Oracle recommends that you evaluate the security requirements for the new database and implement them, as applicable. See Security Considerations for details.