About Cloning Autonomous AI Database

Cloning is the process of creating a point-in-time copy of your Autonomous AI Database or its backup set. You can use the cloning feature to quickly set up an Autonomous AI 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 AI Database on Dedicated Exadata Infrastructure) after the clone operation completes.

Clone Types

Autonomous AI 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:

A running database instance: You can create a new database instance by cloning an Autonomous AI 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.
A backup of a database instance: You can create a new database instance by cloning an automatic backup of the Autonomous AI 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 in Oracle Database 19c SQL Tuning Guide or Oracle Database 26ai SQL Tuning Guide.
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 AI Database instance or its backup set successfully, the following requirements have to be met:

To clone an Autonomous AI 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.
To support cloning on Exadata Cloud@Customer deployments, you must open Port 1522 as part of your network setup. See Create Autonomous Exadata VM Cluster for details.
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 AI 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 AI 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 AI 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 AI 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 AI Databases in the source tenancy.
  This policy discussed in the above example allows DestinationGroup to create Autonomous AI Databases and Autonomous AI Database clones in the source tenancy. You can limit cloning permissions so that the group can only clone Autonomous AI Databases but cannot create Autonomous AI 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 AI Database for more information and examples.

Clone Limitations

There are a few limitations with cloning Autonomous AI 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 AI Database with 23ai version into an Autonomous AI 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 AI 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 AI 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 AI 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 AI 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 AI Database for more information on customer managed keys.

Step-by-Step Guides

To learn how to clone an Autonomous AI 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.