À propos du clonage d'une base de données autonome sur une infrastructure Exadata dédiée
Le clonage est le processus de création d'une copie ponctuelle de votre base de données autonome ou de son jeu de sauvegarde. Vous pouvez utiliser la fonction 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 spécifié pour le clone que vous créez. Par conséquent, vous pouvez améliorer la vitesse de l'opération de clonage en spécifiant plus d'UC pour le clone, puis en l'ajustant au nombre d'UC souhaité (comme décrit dans Supprimer des ressources d'UC ou de stockage d'Autonomous Database sur une infrastructure Exadata dédiée) une fois l'opération de clonage terminée.Types de clone
-
Clone complet : Un clone complet crée une nouvelle base de données qui comprend les métadonnées et les données de la base source.
-
Clone des métadonnées : Ce type de clone crée une base de données qui comprend toutes les métadonnées du schéma de la base source, mais pas les données sources.
Sources de clones
-
Instance de base de données en cours d'exécution : Vous pouvez créer une nouvelle instance de base de données en clonant une instance Autonomous Database.
Lors du clonage d'une instance de base de données, vous pouvez :-
Sélectionnez une autre infrastructure Exadata, une autre grappe de machines virtuelles Exadata autonome ou une autre base de données conteneur autonome pour la base de données du clone.
-
Créez la base de données clonée 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 clonée dans la même location ou une location différente de la source du clone. Un clone interlocation peut se trouver dans la même région ou dans une région différente de la source du clone. Le clonage interlocation est pris en charge uniquement dans les déploiements Oracle Public Cloud.
-
-
Sauvegarde d'une instance de base de données : Vous pouvez créer une nouvelle instance de base de données en clonant une sauvegarde automatique d'Autonomous Database, soit une sauvegarde sur demande, soit une sauvegarde à long terme.
Dans une configuration Autonomous Data Guard, vous pouvez le cloner à partir d'une sauvegarde dans 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 dans un intervalle de dates ou créez un clone à un moment précis. Les clones ponctuels contiennent toutes les données jusqu'à un horodatage spécifié. L'horodatage spécifié doit être compris dans la période de conservation définie au niveau de la base de données conteneur autonome.
Note :
Vous ne pouvez pas cloner une sauvegarde à long terme à l'aide de l'option de clonage à un instant donné. 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 de détails, voir À propos de la sauvegarde et de la récupération. -
Sélectionnez une autre infrastructure Exadata, une autre grappe de machines virtuelles Exadata autonome ou une autre base de données conteneur autonome pour la base de données du clone.
-
Créez la base de données clonée 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 clonée dans la même location ou une location différente de la source du clone. Un clone interlocation peut se trouver dans la même région ou dans une région différente de la source du clone. Le clonage interlocation est pris en charge uniquement dans les déploiements Oracle Public Cloud.
-
Après la soumission d'une demande de clonage, la base de données clonée passe au statut 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 avant la fin de l'opération en cours.
Notez également les informations suivantes sur la nouvelle base de données clonée :
- Les statistiques de l'optimiseur sont copiées de la base source vers la base clonée. Ensuite :
- Pour les clones complets, les chargements dans les tables ont le même comportement que les chargements dans les tables 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 dernière et met à jour les statistiques avec le nouveau chargement.
Pour plus d'informations sur les statistiques de l'optimiseur, voir Concepts relatifs aux statistiques de l'optimiseur dans le guide de réglage SQL pour Oracle Database 19c ou le guide de réglage SQL pour Oracle Database 23ai.
- Les règles de gestion des ressources modifiées par l'utilisateur dans la base de données source sont répercutées sur la base clonée.
- Les données de performance pour la période qui précède l'opération de clonage ne sont pas disponibles dans la base de données clonée.
Exigences pour le clonage
-
Pour cloner une Autonomous Database, vous avez besoin de l'accès requis à l'aide des énoncés de politique suivants écrits par un administrateur, que vous utilisiez la console ou l'API REST avec une trousse 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 que vous voyez s'afficher un message indiquant que vous ne disposez pas de l'autorisation requise, vérifiez avec votre administrateur le type d'accès qui vous a été octroyé et le compartiment que vous devez utiliser. -
La base de données conteneur autonome cible doit avoir une version identique ou supérieure à celle de la base source.
-
Pour prendre en charge le clonage sur les déploiements Exadata Cloud@Customer, vous devez ouvrir le port 1522 dans le cadre de votre configuration réseau. Pour plus de détails, voir Créer une grappe de MV Exadata autonome.
-
Lors du clonage à partir d'une instance de base de données :
-
Les clés de chiffrement source et cible doivent avoir le même type de magasin de clés.
-
Le mot de passe ADMIN que vous spécifiez pour la base de données clonée doit être différent de celui de l'utilisateur de base de données ADMIN de 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 clonée est l'espace utilisé réel de la base de données source arrondi au Go suivant.
-
-
Lors du clonage à partir d'une sauvegarde :
-
Vous avez besoin d'un minimum de 4 ECPU ou 1 OCPU dans la grappe de machines virtuelles Exadata autonome cible. Vous pouvez voir le nombre d'UC disponibles dans la liste des grappes de machines virtuelles Exadata autonomes sur la console Oracle Cloud Infrastructure. Pour plus de détails, voir Voir une liste de grappes de machines virtuelles Exadata autonomes.
-
La source et la cible peuvent avoir des types de magasin de clés différents pour la clé de chiffrement. Toutefois, les exigences suivantes doivent être respectées :
-
Si la source et la cible utilisent des clés gérées par le client à l'aide d'Oracle Key Vault (OKV), elles doivent utiliser la même destination OKV. La grappe de machines virtuelles Exadata autonome cible et la base de données conteneur autonome nécessiteront l'accès à Oracle Key Vault (OKV) source pour les clés.
-
Sur Oracle Cloud, si la source utilise des clés gérées par le client au moyen d'un service de gestion des clés, vous devez vous assurer que la grappe de machines virtuelles Exadata autonome cible a accès à la chambre forte du service de gestion des clés source lors de l'opération de restauration.
-
-
Exigences de clonage interlocation
S'applique à : Oracle Public Cloud seulement
Pour créer un clone interlocation à partir d'une instance Autonomous Database ou de son jeu de sauvegarde, vous devez vous assurer de répondre aux exigences suivantes :
Note :
Les exigences de clonage interlocation décrites ci-dessous sont nécessaires en plus des exigences générales de clonage décrites dans Exigences de clonage.-
Exécutez l'interface de ligne de commande ou les commandes d'API pour créer le clone interlocation à partir de la location de destination.
-
Définissez des groupes et des politiques de gestion des identités et des accès OCI sur les locations source et de destination afin que vous puissiez exécuter des commandes pour créer un clone sur la location de destination et permettre à la location de destination de communiquer avec la location source où réside la source du clone. Lorsque ces politiques sont révoquées, le clonage interlocation n'est pas autorisé.
-
Dans la location de destination, créez un groupe (par exemple : DestinationGroup) et ajoutez les utilisateurs qui seront autorisés à créer le clone interlocation à ce groupe. Pour plus d'informations, voir Utilisation de la console pour créer un groupe.
-
Dans la location source, créez des politiques IAM pour permettre au groupe créé dans la location de destination (DestinationGroup) de créer un clone à l'aide d'une source de clonage de la location source. Pour plus d'informations, voir Utilisation de la console pour créer une politique.
Par exemple, vous pouvez définir une politique pour autoriser un utilisateur dansDestinationGroup
deDestinationTenancy
à lire à partir d'une instance Autonomous Database spécifique dans le compartiment spécifié de 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'
Note :
La politique doit uniquement autoriser l'accès en lecture sur l'instance Autonomous Database source pour créer un clone interlocation.La politique ci-dessus spécifie les éléments suivants :- Ligne 1 : OCID de la location de destination où 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 où réside la source du clone et OCID de la source du clone (instance Autonomous Database ou sauvegarde).
Note :
La clause WHERE de l'exemple ci-dessus est facultative. Il fournit un moyen plus détaillé d'accorder l'accès à une source de clone spécifique.
-
Dans la location de destination, créez des politiques IAM pour endosser un groupe afin de gérer la source du clone dans la location source. Pour plus d'informations, voir Utilisation de la console pour créer une politique.
Par exemple :Define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID Endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
La politique ci-dessus spécifie les éléments suivants :- Ligne 1 : OCID de l'OCID de la location source où réside la source du clone.
- Ligne 2 : Spécifie le groupe de destination qui peut être autorisé à gérer les base de données Autonomous Database dans la location source.
Cette politique décrite dans l'exemple ci-dessus permet à
DestinationGroup
de créer des base de données Autonomous Database et des clones Autonomous Database dans la location source. Vous pouvez limiter les autorisations de clonage afin que le groupe ne puisse cloner que des bases de données Autonomous Database, mais ne peut pas créer des bases de données Autonomous Database ou limiter davantage l'autorisation de créer uniquement un type particulier de clone : clone complet ou clone de métadonnées. Pour plus d'informations et des exemples, voir Autorisations IAM et opérations d'API pour Autonomous Database.
-
Cloner les limites
- Vous pouvez cloner une base de données OCPU dans une base de données OCPU ou ECPU. Toutefois, vous ne pouvez pas cloner une base de données ECPU dans une base de données OCPU.
- Vous ne pouvez pas cloner une base de données Autonomous Database avec une version 23ai dans une base de données Autonomous Database avec une version 19c et vice-versa.
-
Lors du 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 normale dans une instance Autonomous Database pour les développeurs et vice versa. Toutefois, pour cloner une base de données normale dans une base de données pour développeurs, l'espace utilisé réel de la base de données source, arrondi au Go suivant, doit être inférieur ou égal à 32 Go.
-
Lors du clonage à partir d'une sauvegarde :
-
Le clone des 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 dans la grappe de machines virtuelles Exadata autonome cible à un moment donné. Autrement dit, plusieurs clones de sauvegarde ne peuvent pas être créés simultanément sur une même grappe de machines virtuelles Exadata autonome.
-
Vous ne pouvez cloner une sauvegarde vers une base de données Autonomous Database pour les développeurs que si l'espace affecté à la base de données source est inférieur ou égal à 32 Go.
-
Vous ne pouvez pas cloner une sauvegarde à long terme à l'aide de l'option de clonage à un instant donné.
-
Vous ne pouvez redimensionner l'UC à une valeur fractionnaire qu'après le clonage, si nécessaire. Reportez-vous à la section Surprovisionnement d'UC pour en savoir plus sur l'utilisation de valeurs d'UC fractionnaires.
-
Sur Exadata Cloud@Customer :
- Vous ne pouvez pas utiliser des sauvegardes sur disque local pour le clonage.
- Le temps nécessaire pour cloner une base de données Autonomous Database dépend du nombre d'UC et de la bande passante de réseau entre la destination de sauvegarde et la base de données conteneur autonome cible.
-
- Clones interlocation :
-
Peut uniquement être créé à l'aide de l'interface de ligne de commande ou des API REST d'Autonomous Database. Cette option n'est pas disponible à l'aide de la console Oracle Cloud Infrastructure.
-
Ne sont pris en charge que pour les déploiements Oracle Public Cloud.
-
Les clés gérées par le client ne sont pas prises en charge dans la source. Pour plus d'informations sur les clés gérées par le client, voir Clés de chiffrement principales dans Autonomous Database.
-
Guides étape par étape
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 sur les demandes de signature, voir API REST et Données d'identification de sécurité. Pour plus d'informations sur les trousses SDK, voir Trousses SDK et interface de ligne de commande.