Oracle Cloud Infrastructure Documentation

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.

  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.

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.

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.

Step-by-Step Guides

To learn how to clone an Autonomous Database from different clone sources using the OCI console, see:

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.