A propos du clonage d'Autonomous Database on Dedicated Exadata Infrastructure

Le clonage est le processus de création d'une copie à un point dans le temps de votre base de données autonome ou de son ensemble de sauvegarde. Vous pouvez utiliser la fonctionnalité de clonage pour configurer rapidement une base de données autonome avec des données historiques à des fins de test, de développement ou d'analyse.

Conseil :

La vitesse de l'opération de clonage dépend du nombre d'UC indiquées pour le clone en cours de création. Par conséquent, vous pouvez améliorer la vitesse de l'opération de clonage en indiquant davantage d'UC pour le clone, puis en la réduisant au nombre souhaité d'UC (comme décrit dans Suppression de ressources d'UC ou de stockage d'Autonomous Database on Dedicated Exadata Infrastructure) une fois l'opération de clonage terminée.

Types de clone

Autonomous Database prend en charge les types de clone suivants :

Clone complet : un clone complet crée une base de données qui inclut les métadonnées et les données de la base de données source.
Clone de métadonnées : ce type de clonage crée une base de données qui inclut toutes les métadonnées de schéma de base de données source, mais pas celles-ci.

Sources du clonage

Vous pouvez créer un clone de base de données à partir de l'une des sources suivantes :

Instance de base de données en cours d'exécution : pour créer une instance de base de données, vous pouvez cloner une instance Autonomous Database.
Lors du clonage d'une instance de base de données, vous pouvez :
- Choisissez une autre infrastructure Exadata, un autre cluster de machines virtuelles Exadata ou une autre base de données Conteneur Autonomous pour la base de données clone.
- Créez la base de données clone dans la même région ou dans une région différente de la source du clone.
- Créez la base de données clone dans la même location ou dans une location différente de la source du clone. Un clone inter-locations peut se trouver dans la même région ou dans une région différente de la source du clone. Le clonage inter-locations est pris en charge sur les déploiements Oracle Public Cloud uniquement.
Sauvegarde d'une instance de base de données : pour créer une instance de base de données, vous pouvez cloner une sauvegarde automatique de l'instance Autonomous Database, à la demande ou à long terme.

Dans une configuration Autonomous Data Guard, vous pouvez effectuer un clonage à partir d'une sauvegarde à l'emplacement principal ou de secours.
Lors de la création d'une instance de base de données à partir d'une sauvegarde, vous pouvez :
- Sélectionnez une sauvegarde dans une liste de sauvegardes comprise dans une plage de dates ou créez un clone à un point dans le temps. Les clones à un point dans le temps contiennent toutes les données jusqu'à l'horodatage spécifié. L'horodatage indiqué doit être compris dans la période de conservation définie au niveau de la base de données Conteneur Autonomous.
  
  Remarques :
  Vous ne pouvez pas cloner une sauvegarde à long terme à l'aide de l'option de clonage à un point dans le temps. Les sauvegardes à long terme sont des sauvegardes manuelles qui peuvent être conservées pendant au moins 90 jours et au maximum 10 ans. Pour plus d'informations, reportez-vous à A propos de la sauvegarde et de la récupération.
- Choisissez une autre infrastructure Exadata, un autre cluster de machines virtuelles Exadata ou une autre base de données Conteneur Autonomous pour la base de données clone.
- Créez la base de données clone dans la même région ou dans une région différente de la source du clone.
- Créez la base de données clone dans la même location ou dans une location différente de la source du clone. Un clone inter-locations peut se trouver dans la même région ou dans une région différente de la source du clone. Le clonage inter-locations est pris en charge sur les déploiements Oracle Public Cloud uniquement.

Une fois la demande de clonage soumise, la base de données clone indique PROVISIONING jusqu'à ce que la nouvelle base de données dédiée soit disponible. Vous ne pouvez pas lancer une nouvelle opération de clonage sur une base de données dédiée déjà en cours de clonage tant que l'opération en cours n'est pas terminée.

Tenez également compte des informations suivantes concernant la base de données nouvellement clonée :

Les statistiques d'optimiseur sont copiées de la base de données source vers la base de données clonée. Les effets sont les suivants :
- Pour les clones complets, les chargements dans les tables se comportent de la même manière que le chargement dans une table avec des statistiques déjà en place.
- Pour les clones de métadonnées, le premier chargement dans une table efface les statistiques de cette table et les met à jour avec le nouveau chargement.
Pour plus d'informations sur les statistiques de l'optimiseur, reportez-vous à Concepts relatifs aux statistiques de l'optimiseur dans le guide de réglage SQL d'Oracle Database 19c ou le guide de réglage SQL d'Oracle Database 23ai.
Les règles de gestion des ressources modifiées par l'utilisateur dans la base de données source sont transférées vers la base de données clonée.
Les données de performances pour la période précédant l'opération de clonage ne sont pas disponibles dans la base de données clonée.

Exigences relatives au clonage

Pour que vous puissiez cloner une instance Autonomous Database ou l'ensemble de sauvegarde correspondant, les exigences suivantes doivent être satisfaites :

Pour cloner une instance Autonomous Database, vous avez besoin de l'accès requis à l'aide des instructions de stratégie suivantes écrites par un administrateur, que vous utilisiez la console ou l'API REST avec un kit SDK, une interface de ligne de commande ou un autre outil :
```
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>
```
Conseil :
Si vous essayez d'effectuer une action et qu'un message indique que vous n'y êtes pas autorisé, vérifiez auprès de l'administrateur le type d'accès qui vous a été accordé et le compartiment dans lequel vous devez travailler.
La base de données Conteneur Autonomous cible doit être de même version que la source, ou de version supérieure.
Pour prendre en charge le clonage sur les déploiements Exadata Cloud@Customer, vous devez ouvrir le port 1522 dans le cadre de la configuration réseau. Pour plus d'informations, reportez-vous à Création d'un cluster de machines virtuelles Exadata Autonomous.
Lors d'un clonage à partir d'une instance de base de données :
- Les clés de cryptage source et cible doivent présenter le même type de fichier de clés.
- Le mot de passe ADMIN que vous indiquez pour la base de données clone doit être différent de celui de l'utilisateur de base de données ADMIN dans la base de données source. Sinon, l'opération de clonage échoue.
- Pour un clone complet, le stockage minimal que vous pouvez spécifier pour la base de données clone est l'espace utilisé réel de la base de données source arrondi au Go suivant.
Lors d'un clonage à partir d'une sauvegarde :
- Vous avez besoin d'un minimum de 4 ECPU ou 1 OCPU dans le cluster de machines virtuelles Exadata Autonomous cible. Vous pouvez visualiser le nombre d'UC disponibles à partir de la liste des clusters de machines virtuelles Exadata Autonomous sur la console Oracle Cloud Infrastructure. Pour plus d'informations, reportez-vous à Affichage de la liste des clusters de machines virtuelles Exadata Autonomous.
- La source et la cible peuvent présenter des types de fichier de clés différents pour la clé de cryptage. Toutefois, les conditions suivantes doivent être remplies :
  - Si la source et la cible utilisent toutes deux des clés gérées par le client à l'aide d'Oracle Key Vault (OKV), elles doivent utiliser la même destination OKV. Le cluster de machines virtuelles Exadata Autonomous cible et la base de données Conteneur Autonomous doivent avoir accès à l'instance Oracle Key Vault (OKV) source des clés.
  - Sur Oracle Cloud, si la source utilise des clés gérées par le client via KMS, vous devez vous assurer que le cluster de machines virtuelles Exadata Autonomous cible a accès au coffre KMS source pendant l'opération de restauration.

Exigences relatives aux clones de location croisée

S'APPLIQUE À : Oracle Public Cloud uniquement

Pour créer un clone inter-location à partir d'une instance Autonomous Database ou de son ensemble de sauvegarde, vous devez vous assurer de répondre aux exigences suivantes :

Remarques :

Les exigences relatives aux clones inter-locations décrites ci-dessous sont nécessaires en plus des exigences générales relatives aux clones décrites dans la section Clone Requirements.

Exécutez les commandes d'interface de ligne de commande ou d'API pour créer le clone inter-location à partir de la location de destination.
Définissez des groupes et des stratégies OCI Identity and Access Management sur les locations source et de destination afin de pouvoir exécuter des commandes permettant de créer un clone sur la location de destination et d'autoriser la location de destination à contacter la location source dans laquelle réside la source clone. Lorsque ces stratégies sont révoquées, le clonage inter-location n'est pas autorisé.
- Sur la location de destination, créez un groupe (par exemple : DestinationGroup) et ajoutez les utilisateurs qui seront autorisés à créer le clone inter-location à ce groupe. Pour obtenir des instructions, reportez-vous à Utilisation de la console pour créer un groupe.
- Sur la location source, créez des stratégies IAM pour autoriser le groupe créé dans la location de destination (DestinationGroup) à créer un clone à l'aide d'une source clone à partir de la location source. Pour plus d'informations, reportez-vous à Utilisation de la console pour créer une stratégie.
  Par exemple, vous pouvez définir une stratégie pour autoriser un utilisateur dans le fichier DestinationGroup de l'instance DestinationTenancy à lire à partir d'une instance Autonomous Database spécifique dans le compartiment indiqué sur la location source, comme indiqué ci-dessous :
```
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'
```
  Remarques :
  La stratégie doit uniquement autoriser l'accès en lecture sur l'instance Autonomous Database source pour créer un clone inter-location.
  La stratégie ci-dessus spécifie les éléments suivants :
  - Ligne 1 : OCID de la location de destination dans laquelle vous allez créer le clone.
  - Ligne 2 : OCID du groupe de destination auquel appartient l'utilisateur qui créera le clone.
  - Ligne 3 : OCID du compartiment dans lequel réside la source du clone et OCID de la source du clone (instance Autonomous Database ou sauvegarde).
    
    Remarques :
    La clause WHERE de l'exemple ci-dessus est facultative. Elle fournit un moyen plus détaillé d'accorder l'accès à une source clone spécifique.
- Sur la location de destination, créez des stratégies IAM pour approuver un groupe afin de gérer la source clone sur la location source. Pour plus d'informations, reportez-vous à Utilisation de la console pour créer une stratégie.
  Exemple :
```
Define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
Endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
```
  La stratégie ci-dessus spécifie les éléments suivants :
  - Ligne 1 : OCID de la location source dans laquelle réside la source clonée.
  - Ligne 2 : indique le groupe de destination qui peut être autorisé à gérer les instances Autonomous Database dans la location source.
  Cette stratégie décrite dans l'exemple ci-dessus permet à DestinationGroup de créer des clones Autonomous Database et Autonomous Database dans la location source. Vous pouvez limiter les droits d'accès de clonage afin que le groupe puisse uniquement cloner des instances Autonomous Database, mais pas créer des instances Autonomous Database, ni limiter davantage les droits d'accès permettant de créer uniquement un type particulier de clone : clone complet ou clone de métadonnées. Pour plus d'informations et d'exemples, reportez-vous à Droits d'accès IAM et opérations d'API pour Autonomous Database.

Limites relatives au clonage

Le clonage d'Autonomous Database est soumis à quelques limitations répertoriées ci-dessous :

Vous pouvez cloner une base de données OCPU dans une base de données OCPU ou ECPU. Cependant, vous ne pouvez pas cloner une base de données ECPU dans une base de données OCPU.
Vous ne pouvez pas cloner une instance Autonomous Database avec une version 23ai vers une instance Autonomous Database avec la version 19c, et inversement.
Lors d'un clonage à partir d'une instance de base de données :
- Pour les bases de données utilisant Autonomous Data Guard, vous pouvez uniquement cloner une base de données principale. Toutefois, vous pouvez cloner la base de données principale ou de secours lors du clonage à partir d'une sauvegarde.
- Vous pouvez cloner une base de données standard dans une instance Autonomous Database for Developers, et inversement. Toutefois, pour cloner une base de données standard dans une base de données de développeur, l'espace utilisé réel de la base de données source, arrondi au Go suivant, doit être de 32 Go ou moins.
Lors d'un clonage à partir d'une sauvegarde :
- Le clone de métadonnées n'est pas pris en charge. Vous pouvez uniquement utiliser l'option Clone complet pour créer un clone de base de données.
- Vous ne pouvez exécuter qu'une seule opération de restauration à la fois dans le cluster de machines virtuelles Exadata Autonomous cible. En d'autres termes, vous ne pouvez pas créer plusieurs clones de sauvegarde simultanément sur un même cluster de machines virtuelles Exadata Autonomous.
- Vous pouvez cloner une sauvegarde vers une instance Autonomous Database pour les développeurs uniquement si l'espace alloué de la base de données source est de 32 Go ou moins.
- Vous ne pouvez pas cloner une sauvegarde à long terme à l'aide de l'option de clonage à un point dans le temps.
- Vous pouvez redimensionner la CPU à une valeur fractionnaire uniquement après le clonage, si nécessaire. Pour plus d'informations sur l'utilisation des valeurs de CPU fractionnées, reportez-vous à Surprovisionnement de l'UC.
- Sur Exadata Cloud@Customer :
  - Vous ne pouvez pas utiliser de sauvegardes sur disque locales pour le clonage.
  - Le temps nécessaire pour cloner une instance Autonomous Database dépend du nombre d'UC et de la bande passante réseau entre la destination de sauvegarde et la base de données Conteneur Autonomous cible.
Clones entre locations :
- Ne peut être créé qu'à l'aide de l'interface de ligne de commande ou des API REST Autonomous Database. Cette option n'est pas disponible à l'aide de la console Oracle Cloud Infrastructure.
- Sont uniquement pris en charge sur les déploiements Oracle Public Cloud.
- Ne sont pas pris en charge avec les clés gérées par le client sur la source. Pour plus d'informations sur les clés gérées par le client, reportez-vous à Clés de cryptage maître dans Autonomous Database.

Guides étape par étape

Pour savoir comment cloner une instance Autonomous Database à partir de différentes sources de clonage à l'aide de la console OCI, reportez-vous aux sections suivantes :

Vous pouvez également utiliser l'API CreateAutonomousDatabase pour cloner une base de données. Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Informations relatives au titre et au copyright

Oracle et/ou ses affiliés.