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>

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.

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.

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.