About Cloning Autonomous Database on Dedicated Exadata Infrastructure

Cloning is the process of creating a point-in-time copy of your Autonomous Database or its backup set. You can use the cloning feature to quickly set up an Autonomous Database with historical data for purposes such as testing, development, or analytics.

Tip:

The speed of the clone operation depends on the number of CPUs you specify for the clone you are creating. Therefore, you can improve the speed of the clone operation by specifying more CPUs for the clone and then scaling it down to the desired number of CPUs (as described in Remove CPU or Storage Resources from Autonomous Database on Dedicated Exadata Infrastructure) after the clone operation completes.

Clone Types

Autonomous Database supports the following clone types:
  • Full Clone: A full clone creates a new database that includes the metadata and data from the source database.

  • Metadata Clone: This clone type creates a new database that includes all source database schema metadata, but not the source database data.

Clone Sources

You can create a database clone from any of the following sources:
  1. A running database instance: You can create a new database instance by cloning an Autonomous Database instance.

    While cloning a database instance, you may:
    • Choose a different Exadata Infrastructure, Autonomous Exadata VM Cluster, or Autonomous Container Database for the clone database.

    • Create the clone database in the same region or a region different from the clone source.

    • Create the clone database in the same tenancy or a tenancy different from the clone source. A cross-tenancy clone can be in the same region or a region different from the clone source. Cross tenancy cloning is supported on Oracle Public Cloud deployments only.

  2. A backup of a database instance: You can create a new database instance by cloning an automatic backup of the Autonomous Database, either an on-demand backup or a long-term backup.

    In an Autonomous Data Guard setup, you can clone from a backup at the primary or standby location.

    While creating a database instance from backup, you may:
    • Select a backup from a list of backups within a date range or create a point-in-time clone. Point-in-time clones contain all data up to a specified timestamp. The specified timestamp must be within the retention period defined at the Autonomous Container Database level.

      Note

      You can not clone a long-term backup using the Point-in-time clone option. Long-term backups are manual backups that can be retained for a minimum of 90 days and a maximum of 10 years. Refer to About Backup and Recovery for more details.
    • Choose a different Exadata Infrastructure, Autonomous Exadata VM Cluster, or Autonomous Container Database for the clone database.

    • Create the clone database in the same region or a region different from the clone source.

    • Create the clone database in the same tenancy or a tenancy different from the clone source. A cross-tenancy clone can be in the same region or a region different from the clone source. Cross tenancy cloning is supported on Oracle Public Cloud deployments only.

After submitting a clone request, the clone database shows up as PROVISIONING until the new dedicated database is available. You cannot initiate a new clone operation on a dedicated database that is already being cloned until the ongoing operation completes.

Also, note the following information about the newly cloned database:

  • Optimizer statistics are copied from the source database to the cloned database. Then:
    • For full clones, loads into tables behave the same as loading into a table with statistics already in place.
    • For metadata clones, the first load into a table clears the statistics for that table and updates the statistics with the new load.

    For more information on Optimizer Statistics, see Optimizer Statistics Concepts.

  • Resource management rules changed by the user in the source database are carried over to the cloned database.
  • Performance data for the time before the clone operation is not available in the cloned database.

Clone Requirements

To clone an Autonomous Database instance or its backup set successfully, the following requirements have to be met:
  • To clone an Autonomous Database, you need the required access using the following policy statements written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or another tool:
    Allow group <Group_Name>
    to manage autonomous-databases
    in compartment <Compartment_Name>
    Allow group <Group_Name>
    to read autonomous-container-databases
    in compartment <Compartment_Name>

    Tip:

    If you try to 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.
  • The target Autonomous Container Database (ACD) must be on the same or higher database version as the source.

  • When cloning from a database instance:
    • The source and target encryption key must be the same keystore type.

    • The ADMIN password you specify for the clone database must be different from that of the ADMIN database user in the source database; otherwise, the clone operation will fail.

    • For a Full Clone, the minimum storage that you can specify for the clone database is the source database's actual used space rounded up to the next GB.

  • When cloning from a backup:
    • You need a minimum of 4 ECPUs or 1 OCPU in the target Autonomous Exadata VM Cluster. You can view the number of available CPUs from the Autonomous Exadata VM Clusters listing on the Oracle Cloud Infrastructure console. See View a List of Autonomous Exadata VM Clusters for more details.

    • The source and target can be different keystore types for the encryption key. However, the following requirements must be met:

      • If both the source and target use customer managed keys using Oracle Key Vault (OKV), they must use the same OKV destination. The target Autonomous Exadata VM Cluster and Autonomous Container Database will require access to the source Oracle Key Vault (OKV) for the keys.

      • On Oracle Cloud, if the source uses customer managed keys via KMS, you must ensure that the target Autonomous Exadata VM Cluster has access to the source KMS vault during the restore operation.

Cross Tenancy Clone Requirements

APPLIES TO: Applicable Oracle Public Cloud only

To create a cross tenancy clone from an Autonomous Database instance or its backup set successfully, you must ensure to meet the following requirements:

Note

The cross-tenancy clone requirements discussed below are needed in addition to the general clone requirements discussed in Clone Requirements.
  • Run the CLI or API commands to create the cross tenancy clone from the destination tenancy.

  • Define OCI Identity and Access Management groups and policies on the source and destination tenancies so that you can run commands to create a clone on the destination tenancy and allow the destination tenancy to contact the source tenancy where the clone source resides. When these polices are revoked, cross tenancy cloning will not be allowed.
    • On the destination tenancy, create a group (for example: DestinationGroup), and add the user(s) who will be allowed to create the cross tenancy clone to this group. See Using the Console to Create a Group for guidance.

    • On the source tenancy, create IAM policies to allow the group created in the destination tenancy (DestinationGroup) to create a clone using a clone source from the source tenancy. See Using the Console to Create a Policy for guidance.

      For example, you can define a policy to allow a user in the DestinationGroup of the DestinationTenancy read from a specific Autonomous Database instance in the specified compartment on the source tenancy as shown below:
      define tenancy DestinationTenancy as ocid1.tenancy.oc1..unique_ID
      define group DestinationGroup as ocid1.group.region1..unique_ID
      admit group DestinationGroup of tenancy DestinationTenancy to read autonomous-database-family
             in compartment ocid1.compartment.region1..unique_ID 
             where target.id = 'oc1.autonomousdatabase.oc1..unique_ID'
      Note

      The policy only needs to allow read access on the source Autonomous Database instance to create a cross tenancy clone.
      The above policy specifies the following:
      • Line 1: OCID of the destination tenancy where you are going to create the clone.
      • Line 2: OCID of the destination group to which the user who will create the clone belongs.
      • Line 3: OCID of the compartment where the clone source resides and the OCID of the clone source (Autonomous Database instance or a backup).
        Note

        The where clause in the above example is optional. It provides a more fine-grained way to grant access to a specific clone source.
    • On the destination tenancy, create IAM policies to endorse a group to manage the clone source on the source tenancy. See Usiing the Console to Create a Policy for guidance.

      For example:
      Define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
      Endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
      The above policy specifies the following:
      • Line 1: OCID of the source tenancy OCID where the clone source resides.
      • Line 2: Specifies the destination group that can be allowed to manage Autonomous Databases in the source tenancy.

      This policy discussed in the above example allows DestinationGroup to create Autonomous Databases and Autonomous Database clones in the source tenancy. You can limit cloning permissions so that the group can only clone Autonomous Databases but cannot create Autonomous Databases, or further limit permission to only create a particular type of clone: Full Clone or Metadata Clone. See IAM Permissions and API Operations for Autonomous Database for more information and examples.

Clone Limitations

There are a few limitations with cloning Autonomous Database as listed below:
  • You can clone an OCPU database into either OCPU or ECPU database. However, you can not clone an ECPU database into an OCPU database.
  • You can not clone an Autonomous Database with 23ai version into an Autonomous Database with 19c version and vice-versa.
  • When cloning from a database instance:
    • For databases using Autonomous Data Guard, you can only clone a primary database. However, you can clone either the primary or standby database when cloning from a backup.
    • You can clone a regular database into an Autonomous Database for Developers instance and vice versa. However, to successfully clone a regular database into a developer database, the actual used space of the source database, rounded up to the next GB, must be 32GB or less.
  • When cloning from a backup:
    • Metadata Clone is not supported. You can only use the Full Clone option to create a database clone.

    • You can have only one restore operation running in the target Autonomous Exadata VM Cluster at a given time. In other words, you can not have multiple backup clones created on a single Autonomous Exadata VM Cluster simultaneously.

    • You can clone a backup to an Autonomous Database for Developers only if the source database's allocated space is 32GB or less.

    • You can not clone a long-term backup using the Point-in-time clone option.

    • You can resize the CPU to a fractional value only after the clone, if needed. Refer to CPU Overprovisioning to learn more about using fractional CPU values.

    • On Exadata Cloud@Customer:
      • You can not use local disk-based backups for cloning.
      • The time taken to clone an Autonomous Database depends on the CPU Count and the network bandwidth between the Backup Destination and the target Autonomous Container Database.
  • Cross tenancy clones:
    • Can only be created using the CLI or the Autonomous Database REST APIs. This option is not available using the Oracle Cloud Infrastructure Console.

    • Are only supported on Oracle Public Cloud deployments only.

    • Are not supported with customer managed keys on the source. See Master Encryption Keys in Autonomous Database for more information on customer managed keys.

Step-by-Step Guides

You can also use the CreateAutonomousDatabase API to clone a database. For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.