Utilisation d'une base de données Oracle comme source pour AWS DMS - AWS Service de Migration de Base de Données
Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDCFlux de travail pour configurer une base de données source Oracle AWS autogérée ou gérée pour AWS DMSConfiguration d’une base de données source OracleUtilisation d’une base de données source Oracle autogéréeUtilisation d'une AWS source Oracle géréeLimitations sur Oracle comme sourcePrise en charge de SSL pour un point de terminaison OracleMéthodes de chiffrement sur Oracle en tant que sourceMéthodes de compression sur Oracle en tant que sourceRéplication de tables imbriquées à l'aide d'Oracle en tant que sourceStockage de REDO sur Oracle ASMParamètres de point de terminaisonTypes de données sources pour Oracle

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation d'une base de données Oracle comme source pour AWS DMS

Vous pouvez migrer les données d'une ou de plusieurs bases de données Oracle à l'aide de AWS DMS. Avec une base de données Oracle en tant que source, vous pouvez migrer des données vers l’une des cibles prises en charge par AWS DMS.

AWS DMS prend en charge les éditions de base de données Oracle suivantes :

  • Oracle Enterprise Edition

  • Oracle Standard Edition

  • Édition Oracle Express

  • Édition Oracle Personal

Pour plus d'informations sur les versions des bases de données Oracle AWS DMS prises en charge en tant que source, consultezSources pour AWS DMS.

Vous pouvez utiliser SSL (Secure Sockets Layer) pour chiffrer les connexions entre votre point de terminaison Oracle et votre instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison Oracle, consultez Prise en charge de SSL pour un point de terminaison Oracle.

AWS DMS prend en charge l'utilisation du chiffrement transparent des données (TDE) Oracle pour chiffrer les données au repos dans la base de données source. Pour plus d'informations sur l'utilisation de TDE Oracle avec un point de terminaison source Oracle, consultez Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.

AWS prend en charge l'utilisation de TLS version 1.2 et ultérieure avec les points de terminaison Oracle (et tous les autres types de points de terminaison) et recommande d'utiliser TLS version 1.3 ou ultérieure.

Procédez comme suit pour configurer une base de données Oracle en tant que point de terminaison AWS DMS source :

  1. Créez un utilisateur Oracle doté des autorisations appropriées pour accéder AWS DMS à votre base de données source Oracle.

  2. Créez un point de terminaison source Oracle conforme à la configuration de base de données Oracle que vous avez choisie. Pour créer une full-load-only tâche, aucune autre configuration n'est nécessaire.

  3. Pour créer une tâche qui gère la capture des données de modification (une tâche uniquement CDC ou une tâche à chargement complet et une tâche CDC), choisissez Oracle LogMiner ou AWS DMS Binary Reader pour capturer les modifications de données. Le choix LogMiner de Binary Reader détermine certaines des autorisations et options de configuration ultérieures. Pour une comparaison entre Binary Reader LogMiner et Binary Reader, consultez la section suivante.

Note

Pour plus d’informations sur les tâches de chargement complet, les tâches de CDC uniquement et les tâches de chargement complet et de CDC, consultez Création d’une tâche

Pour plus de détails sur l'utilisation des bases de données source Oracle AWS DMS, consultez les sections suivantes.

Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC

Dans AWS DMS, il existe deux méthodes pour lire les journaux de restauration lors de la capture des données de modification (CDC) pour Oracle en tant que source : Oracle LogMiner et AWS DMS Binary Reader. LogMiner est une API Oracle permettant de lire les journaux de journalisation en ligne et les fichiers de journalisation archivés. Le lecteur binaire est une AWS DMS méthode qui lit et analyse directement les fichiers de journalisation bruts. Ces méthodes présentent les fonctionnalités suivantes.

Fonctionnalité LogMiner Binary Reader
Facile à configurer Oui Non
Réduction de l’impact sur les E/S et le CPU du système source Non Oui
Meilleures performances de CDC Non Oui
Prend en charge les clusters de tables Oracle Oui Non
Prend en charge tous les types de compressions HCC Oracle Oui

Partiellement

Binary Reader ne prend pas en charge QUERY LOW pour les tâches avec CDC. Tous les autres types de HCC sont entièrement pris en charge.
Prise en charge des colonnes LOB dans Oracle 12c uniquement Non (le support LOB n'est pas disponible LogMiner dans Oracle 12c.) Oui
Prend en charge les instructions UPDATE qui n’affectent que les colonnes LOB Non Oui
Prend en charge le chiffrement transparent des données (TDE) Oracle

Partiellement

Lorsque vous utilisez Oracle LogMiner, le chiffrement TDE au niveau des colonnes AWS DMS n'est pas pris en charge pour Amazon RDS for Oracle.

Partiellement

Binary Reader prend en charge le chiffrement TDE uniquement pour les bases de données Oracle autogérées.
Prend en charge toutes les méthodes de compression Oracle Oui Non
Prend en charge les transactions XA Non Oui
RAC

Oui

Non recommandé

Oui

Fortement recommandé
Note

Par défaut, AWS DMS utilise Oracle LogMiner pour (CDC).

AWS DMS prend en charge les méthodes de chiffrement transparent des données (TDE) lorsque vous travaillez avec une base de données source Oracle. Si les informations d'identification TDE que vous spécifiez sont incorrectes, la tâche de AWS DMS migration n'échoue pas, ce qui peut avoir un impact sur la réplication continue des tables chiffrées. Pour plus d’informations sur la spécification des informations d’identification TDE, consultez Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.

Les principaux avantages de l'utilisation de LogMiner with AWS DMS sont les suivants :

  • LogMiner prend en charge la plupart des options Oracle, telles que les options de chiffrement et de compression. Binary Reader ne prend pas en charge toutes les options Oracle, en particulier celles liées au chiffrement et à la compression.

  • LogMiner offre une configuration plus simple, en particulier par rapport à la configuration à accès direct à Binary Reader ou lorsque les journaux de rétablissement sont gérés à l'aide d'Oracle Automatic Storage Management (ASM).

  • LogMiner prend en charge les clusters de tables destinés à être utilisés par AWS DMS. Ce n'est pas le cas de Binary Reader.

Les principaux avantages de l'utilisation de Binary Reader AWS DMS sont les suivants :

  • Pour les migrations impliquant un volume élevé de modifications, LogMiner cela peut avoir un impact sur les E/S ou le processeur de l'ordinateur hébergeant la base de données source Oracle. Binary Reader a moins de chances d’impacter les E/S ou le CPU, car les journaux sont extraits directement au lieu d’effectuer plusieurs requêtes sur la base de données.

  • Pour les migrations impliquant un volume élevé de modifications, les performances du CDC sont généralement bien meilleures avec Binary Reader qu'avec Oracle LogMiner.

  • Binary Reader prend en charge le CDC pour les LOB dans la version 12c d'Oracle. LogMinerne le fait pas.

En général, utilisez Oracle LogMiner pour migrer votre base de données Oracle, sauf si vous vous trouvez dans l'une des situations suivantes :

  • Vous avez besoin d'exécuter plusieurs tâches de migration sur la base de données source Oracle.

  • Le volume de modifications ou le volume de journaux redo sur la base de données Oracle source est élevé, ou vous avez des modifications et vous utilisez également Oracle ASM.

Note

Si vous passez d'Oracle LogMiner à AWS DMS Binary Reader, assurez-vous de redémarrer la tâche CDC.

Configuration de CDC sur une base de données source Oracle

Pour qu’un point de terminaison source Oracle puisse se connecter à la base de données pour une tâche de capture des données de modification (CDC), vous devrez peut-être spécifier des attributs de connexion supplémentaires. Vous devrez peut-être le faire pour une tâche de chargement complet et de CDC ou pour une tâche de CDC uniquement. Les attributs de connexion supplémentaires que vous spécifiez dépendent de la méthode que vous utilisez pour accéder aux journaux de journalisation : Oracle LogMiner ou AWS DMS Binary Reader.

Vous spécifiez des attributs de connexion supplémentaires lorsque vous créez un point de terminaison source. Si vous avez plusieurs paramètres d'attribut de connexion, séparez-les les uns des autres par des points-virgules, sans espace supplémentaire (par exemple, oneSetting;thenAnother).

AWS DMS utilise LogMiner par défaut. Vous n’avez pas à spécifier d’attributs de connexion supplémentaires pour l’utiliser.

Pour utiliser Binary Reader afin d’accéder aux journaux redo, ajoutez les attributs de connexion supplémentaires suivants.

useLogMinerReader=N;useBfile=Y;

Utilisez le format suivant pour les attributs de connexion supplémentaires afin d'accéder à un serveur qui utilise ASM avec Binary Reader.

useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;

Définissez le paramètre de demande Password du point de terminaison source sur le mot de passe d'utilisateur Oracle et le mot de passe ASM, séparés par une virgule comme suit.

oracle_user_password,asm_user_password

Dans les versions où la source Oracle utilise ASM, vous pouvez utiliser des options hautes performances dans Binary Reader pour le traitement des transactions à grande échelle. Ces options incluent des attributs de connexion supplémentaires pour spécifier le nombre de threads parallèles (parallelASMReadThreads) et le nombre de tampons de lecture anticipée (readAheadBlocks). La définition conjointe de ces attributs peut améliorer considérablement les performances de la tâche de CDC. Les paramètres suivants fournissent de bons résultats pour la plupart des configurations ASM.

useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
    parallelASMReadThreads=6;readAheadBlocks=150000;

Pour de plus amples informations sur les valeurs prises en charge par les attributs de connexion supplémentaires, veuillez consulter Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

En outre, les performances d’une tâche de CDC avec une source Oracle qui utilise ASM dépendent d’autres paramètres que vous choisissez. Ces paramètres incluent vos attributs de connexion supplémentaires AWS DMS et les paramètres SQL pour configurer la source Oracle. Pour plus d’informations sur les attributs de connexion supplémentaires pour une source Oracle qui utilise ASM, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

Vous devez également choisir un point de départ de CDC approprié. Généralement, lorsque vous effectuez cette opération, vous souhaitez identifier le point de traitement des transactions qui capture la première transaction ouverte à partir de laquelle commencer la CDC. Dans le cas contraire, la tâche de CDC peut manquer les premières transactions ouvertes. Pour une base de données source Oracle, vous pouvez choisir un point de départ natif de CDC en fonction du numéro SCN Oracle afin d’identifier cette première transaction ouverte. Pour plus d’informations, consultez Exécution de la réplication à partir d'un point de départ CDC.

Pour plus d’informations sur la configuration de la CDC pour une base de données Oracle autogérée en tant que source, consultez Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation, Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration et Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM.

Pour plus d'informations sur la configuration du CDC pour une base de données Oracle AWS gérée en tant que source, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS etUtilisation d’Amazon RDS Oracle Standby (réplica de lecture) en tant que source avec Binary Reader pour la CDC dans AWS DMS.

Flux de travail pour configurer une base de données source Oracle AWS autogérée ou gérée pour AWS DMS

Configuration d’une base de données source Oracle

Pour configurer une instance de base de données source autogérée, suivez les étapes du flux de travail suivantes, en fonction de la manière dont vous effectuez la CDC.

Pour cette étape du flux de travail Si vous utilisez le CDC LogMiner, procédez comme suit Si vous effectuez la CDC à l’aide de Binary Reader, procédez comme suit
Accordez des privilèges de compte Oracle. veuillez consulter Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS. veuillez consulter Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS.
Préparez la base de données source pour la réplication à l’aide de la CDC. veuillez consulter Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS. veuillez consulter Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS.
Accordez les privilèges d’utilisateur Oracle supplémentaires requis pour la CDC. veuillez consulter Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation. veuillez consulter Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration.
Pour une instance Oracle avec ASM, accordez les privilèges de compte d’utilisateur supplémentaires requis pour accéder à ASM pour la CDC. Aucune action supplémentaire. AWS DMS prend en charge Oracle ASM sans privilèges de compte supplémentaires. veuillez consulter Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM.
Si ce n'est pas déjà fait, configurez la tâche à utiliser LogMiner ou Binary Reader for CDC. veuillez consulter Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC. veuillez consulter Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC.
Configurez Oracle Standby en tant que source pour la CDC. AWS DMS ne prend pas en charge Oracle Standby en tant que source. veuillez consulter Utilisation d’une instance autogérée d’Oracle Standby en tant que source avec Binary Reader pour la CDC dans AWS DMS.

Utilisez les étapes de flux de travail suivantes pour configurer une instance de base de données source Oracle AWS gérée.

Pour cette étape du flux de travail Si vous utilisez le CDC LogMiner, procédez comme suit Si vous effectuez la CDC à l’aide de Binary Reader, procédez comme suit
Accordez des privilèges de compte Oracle. Pour plus d’informations, consultez Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS. Pour plus d’informations, consultez Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS.
Préparez la base de données source pour la réplication à l’aide de la CDC. Pour plus d’informations, consultez Configuration d'une source Oracle AWS gérée pour AWS DMS. Pour plus d’informations, consultez Configuration d'une source Oracle AWS gérée pour AWS DMS.
Accordez les privilèges d’utilisateur Oracle supplémentaires requis pour la CDC. Aucun privilège de compte supplémentaire n’est requis. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.
Si ce n'est pas déjà fait, configurez la tâche à utiliser LogMiner ou Binary Reader for CDC. Pour plus d’informations, consultez Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC. Pour plus d’informations, consultez Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC.
Configurez Oracle Standby en tant que source pour la CDC. AWS DMS ne prend pas en charge Oracle Standby en tant que source. Pour plus d’informations, consultez Utilisation d’Amazon RDS Oracle Standby (réplica de lecture) en tant que source avec Binary Reader pour la CDC dans AWS DMS.

Utilisation d'une base de données Oracle autogérée comme source pour AWS DMS

Une base de données autogérée est une base de données que vous configurez et contrôlez. Il peut s’agir d’une instance de base de données locale sur site ou d’une base de données sur Amazon EC2. Vous trouverez ci-dessous des informations sur les privilèges et les configurations dont vous avez besoin pour utiliser une base de données Oracle autogérée avec AWS DMS.

Privilèges de compte utilisateur requis sur une source Oracle autogérée pour AWS DMS

Pour utiliser une base de données Oracle comme source dans AWS DMS, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

Note

Lorsque vous accordez des privilèges, utilisez le nom réel des objets, et non leur synonyme. Par exemple, utilisez V_$OBJECT en intégrant le trait de soulignement, et non V$OBJECT sans le trait de soulignement.

GRANT CREATE SESSION TO db_user;
GRANT SELECT ANY TRANSACTION TO db_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO db_user;
GRANT SELECT ON V_$LOG TO db_user;
GRANT SELECT ON V_$LOGFILE TO db_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO db_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO db_user;
GRANT SELECT ON V_$DATABASE TO db_user;
GRANT SELECT ON V_$THREAD TO db_user;
GRANT SELECT ON V_$PARAMETER TO db_user;
GRANT SELECT ON V_$NLS_PARAMETERS TO db_user;
GRANT SELECT ON V_$TIMEZONE_NAMES TO db_user;
GRANT SELECT ON V_$TRANSACTION TO db_user;
GRANT SELECT ON V_$CONTAINERS TO db_user;                   
GRANT SELECT ON ALL_INDEXES TO db_user;
GRANT SELECT ON ALL_OBJECTS TO db_user;
GRANT SELECT ON ALL_TABLES TO db_user;
GRANT SELECT ON ALL_USERS TO db_user;
GRANT SELECT ON ALL_CATALOG TO db_user;
GRANT SELECT ON ALL_CONSTRAINTS TO db_user;
GRANT SELECT ON ALL_CONS_COLUMNS TO db_user;
GRANT SELECT ON ALL_TAB_COLS TO db_user;
GRANT SELECT ON ALL_IND_COLUMNS TO db_user;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO db_user;
GRANT SELECT ON ALL_LOG_GROUPS TO db_user;
GRANT SELECT ON ALL_TAB_PARTITIONS TO db_user;
GRANT SELECT ON SYS.DBA_REGISTRY TO db_user;
GRANT SELECT ON SYS.OBJ$ TO db_user;
GRANT SELECT ON DBA_TABLESPACES TO db_user;
GRANT SELECT ON DBA_OBJECTS TO db_user; -– Required if the Oracle version is earlier than 11.2.0.3.
GRANT SELECT ON SYS.ENC$ TO db_user; -– Required if transparent data encryption (TDE) is enabled. For more information on using Oracle TDE with AWS DMS, see Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.
GRANT SELECT ON GV_$TRANSACTION TO db_user; -– Required if the source database is Oracle RAC in AWS DMS versions 3.4.6 and higher.
GRANT SELECT ON V_$DATAGUARD_STATS TO db_user; -- Required if the source database is Oracle Data Guard and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.

Accordez le privilège supplémentaire suivant pour chaque table répliquée lorsque vous utilisez une liste de tables spécifique.

GRANT SELECT on any-replicated-table to db_user;

Accordez le privilège supplémentaire suivant pour valider les colonnes LOB avec la fonctionnalité de validation.

GRANT EXECUTE ON SYS.DBMS_CRYPTO TO db_user;

Accordez le privilège supplémentaire suivant si vous utilisez un lecteur binaire au lieu de LogMiner.

GRANT SELECT ON SYS.DBA_DIRECTORIES TO db_user;

Accordez le privilège supplémentaire suivant pour exposer les vues.

GRANT SELECT on ALL_VIEWS to dms_user;

Pour exposer les vues, vous devez également ajouter l’attribut de connexion supplémentaire exposeViews=true au point de terminaison source.

Accordez le privilège supplémentaire suivant lorsque vous utilisez des réplications sans serveur.

GRANT SELECT on dba_segments to db_user;

Pour en savoir plus sur les réplications sans serveur, consultez Travailler avec AWS DMS Serverless.

Accordez les privilèges supplémentaires suivants lorsque vous utilisez des évaluations de prémigration spécifiques à Oracle.

GRANT SELECT on gv_$parameter  to dms_user;
GRANT SELECT on v_$instance to dms_user;
GRANT SELECT on v_$version to dms_user;
GRANT SELECT on gv_$ASM_DISKGROUP to dms_user;
GRANT SELECT on gv_$database to dms_user;
GRANT SELECT on dba_db_links to dms_user;
GRANT SELECT on gv_$log_History to dms_user;
GRANT SELECT on gv_$log to dms_user;
GRANT SELECT ON DBA_TYPES TO db_user;

Pour en savoir plus sur les évaluations de prémigration spécifiques à Oracle, consultez Évaluations Oracle.

Conditions préalables à la gestion des transactions ouvertes pour Oracle Standby

Lorsque vous utilisez AWS DMS les versions 3.4.6 ou supérieures, effectuez les étapes suivantes pour gérer les transactions ouvertes pour Oracle Standby.

  1. Créez un lien de base de données nommé AWSDMS_DBLINK sur la base de données principale. DMS_USER utilisera ce lien pour se connecter à la base de données principale. Notez que le lien de base de données est exécuté à partir de l’instance de secours pour interroger les transactions ouvertes exécutées sur la base de données principale. Consultez l'exemple suivant. 

    CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
   CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
   USING '(DESCRIPTION=
            (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
            (CONNECT_DATA=(SERVICE_NAME=SID))
          )';

  2. Vérifiez que la connexion au lien de base de données avec DMS_USER est établie, comme indiqué dans l’exemple suivant.

    select 1 from dual@AWSDMS_DBLINK

Préparation d'une base de données source autogérée Oracle pour le CDC à l'aide de AWS DMS

Préparez la base de données Oracle autogérée en tant que source pour exécuter une tâche de CDC en procédant comme suit :

Vérifier que la version de la base de données source est prise en AWS DMS charge

Exécutez une requête similaire à ce qui suit pour vérifier que la version actuelle de la base de données source Oracle est prise en charge par AWS DMS.

SELECT name, value, description FROM v$parameter WHERE name = 'compatible';

Ici, name, value et description sont des colonnes quelque part dans la base de données qui sont interrogées en fonction de la valeur de name. Si cette requête s'exécute sans erreur, elle AWS DMS prend en charge la version actuelle de la base de données et vous pouvez poursuivre la migration. Si la requête génère une erreur, AWS DMS cela signifie que la version actuelle de la base de données n'est pas prise en charge. Pour procéder à la migration, convertissez d'abord la base de données Oracle vers une version prise en charge par AWS DMS.

Vérifiez que le mode ARCHIVELOG est activé

Vous pouvez exécuter Oracle en deux modes différents : le mode ARCHIVELOG et le mode NOARCHIVELOG. Pour exécuter une tâche de CDC, exécutez la base de données en mode ARCHIVELOG. Pour savoir si la base de données est en mode ARCHIVELOG, exécutez la requête suivante.

SQL> SELECT log_mode FROM v$database;

Si le mode NOARCHIVELOG est renvoyé, définissez la base de données sur ARCHIVELOG conformément aux instructions d’Oracle.

Configurez une journalisation supplémentaire

Pour enregistrer les modifications en cours, AWS DMS vous devez activer une journalisation supplémentaire minimale sur votre base de données source Oracle. En outre, vous devez activer la journalisation supplémentaire sur chaque table répliquée de la base de données.

Par défaut, AWS DMS ajoute une journalisation PRIMARY KEY supplémentaire sur toutes les tables répliquées. AWS DMS Pour autoriser l'ajout d'une journalisation PRIMARY KEY supplémentaire, accordez le privilège suivant pour chaque table répliquée.

ALTER on any-replicated-table;

Vous pouvez désactiver la journalisation PRIMARY KEY supplémentaire par défaut ajoutée en AWS DMS utilisant l'attribut addSupplementalLogging de connexion supplémentaire. Pour plus d’informations, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

Assurez-vous d’activer la journalisation supplémentaire si votre tâche de réplication met à jour une table en utilisant une clause WHERE qui ne fait pas référence à une colonne de clé primaire.

Pour configurer manuellement la journalisation supplémentaire

  1. Exécutez la requête suivante pour vérifier si la journalisation supplémentaire est déjà activée pour la base de données.

    SELECT supplemental_log_data_min FROM v$database;

    Si le résultat renvoyé est YES ou IMPLICIT, la journalisation supplémentaire est activée pour la base de données.

    Sinon, activez la journalisation supplémentaire pour la base de données en exécutant la commande suivante.

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

  2. Assurez-vous que la journalisation supplémentaire requise est ajoutée pour chaque table répliquée.

    Éléments à prendre en compte :

    • Si la journalisation supplémentaire ALL COLUMNS est ajoutée à la table, il n’est pas nécessaire d’en ajouter une autre.

    • Si une clé primaire existe, ajoutez une journalisation supplémentaire pour la clé primaire. Vous pouvez le faire en utilisant le format pour ajouter une journalisation supplémentaire sur la clé primaire en elle-même, ou en ajoutant une journalisation supplémentaire sur les colonnes de clé primaire dans la base de données.

      ALTER TABLE Tablename ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

    • Si aucune clé primaire n'existe et que la table possède un seul index unique, toutes les colonnes de l'index unique doivent être ajoutées au journal supplémentaire.

      ALTER TABLE TableName ADD SUPPLEMENTAL LOG GROUP LogGroupName (UniqueIndexColumn1[, UniqueIndexColumn2] ...) ALWAYS;

      L'utilisation de la commande SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS n'ajoute pas les colonnes d'index uniques dans le journal.

    • S'il n'existe aucune clé primaire et que la table comporte plusieurs index uniques, AWS DMS sélectionne le premier index unique dans une liste alphabétique croissante. Vous devez ajouter une journalisation supplémentaire sur les colonnes de l’index sélectionné, comme au point précédent.

      L'utilisation de la commande SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS n'ajoute pas les colonnes d'index uniques dans le journal.

    • Si aucune clé primaire n'existe et qu'il n'y a pas d'index unique, ajoutez une journalisation supplémentaire sur toutes les colonnes.

      ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

      Dans certains cas, l'index unique et la clé primaire de la table cible sont différents de ceux de la table source. Dans ce cas, ajoutez manuellement une journalisation supplémentaire sur les colonnes de la table source qui constituent l’index unique ou la clé primaire de la table cible.

      De plus, si vous modifiez la clé primaire de la table cible, vous devez ajouter la journalisation supplémentaire dans les colonnes de l'index cible, au lieu des colonnes de la clé primaire ou de l'index unique source.

Si un filtre ou une transformation est défini pour une table, vous devrez peut-être activer la journalisation supplémentaire.

Éléments à prendre en compte :

  • Si la journalisation supplémentaire ALL COLUMNS est ajoutée à la table, il n’est pas nécessaire d’en ajouter une autre.

  • Si la table a un index unique ou une clé primaire, ajoutez une journalisation supplémentaire sur chaque colonne impliquée dans un filtre ou une transformation. Toutefois, ne le faites que si ces colonnes sont différentes des colonnes de la clé primaire ou de l’index unique.

  • Si une transformation inclut une seule colonne, n’ajoutez pas cette colonne à un groupe de journalisations supplémentaires. Par exemple, pour une transformation A+B, ajoutez une journalisation supplémentaire sur les deux colonnes A et B. Cependant, pour une transformation substring(A,10), n'ajoutez pas de journalisation supplémentaire sur la colonne A.

  • Pour configurer une journalisation supplémentaire sur les colonnes de clé primaire ou d’index unique et sur d’autres colonnes filtrées ou transformées, vous pouvez configurer la journalisation supplémentaire USER_LOG_GROUP. Ajoutez cette journalisation à la fois sur les colonnes de clé primaire ou d’index unique et sur toute autre colonne spécifique filtrée ou transformée.

    Par exemple, pour répliquer une table nommée TEST.LOGGING avec une clé primaire ID et un filtre sur la colonne NAME, vous pouvez exécuter une commande similaire à celle qui suit pour créer la journalisation supplémentaire du groupe de journaux.

    ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;

Privilèges de compte requis lors de l'utilisation LogMiner d'Oracle pour accéder aux journaux de journalisation

Pour accéder aux journaux de journalisation à l'aide d'Oracle LogMiner, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

GRANT EXECUTE on DBMS_LOGMNR to db_user;
GRANT SELECT on V_$LOGMNR_LOGS to db_user;
GRANT SELECT on V_$LOGMNR_CONTENTS to db_user;
GRANT LOGMINING to db_user; -– Required only if the Oracle version is 12c or higher.

Privilèges de compte requis lors de l'utilisation de AWS DMS Binary Reader pour accéder aux journaux de restauration

Pour accéder aux journaux de journalisation à l'aide du lecteur AWS DMS binaire, accordez les privilèges suivants à l'utilisateur Oracle spécifié dans les paramètres de connexion du point de terminaison Oracle.

GRANT SELECT on v_$transportable_platform to db_user;   -– Grant this privilege if the redo logs are stored in Oracle Automatic Storage Management (ASM) and AWS DMS accesses them from ASM.
GRANT CREATE ANY DIRECTORY to db_user;                  -– Grant this privilege to allow AWS DMS to use Oracle BFILE read file access in certain cases. This access is required when the replication instance doesn't have file-level access to the redo logs and the redo logs are on non-ASM storage.
GRANT EXECUTE on DBMS_FILE_TRANSFER to db_user;         -– Grant this privilege to copy the redo log files to a temporary folder using the CopyToTempFolder method.
GRANT EXECUTE on DBMS_FILE_GROUP to db_user;

Binary Reader fonctionne avec les fonctions de fichier Oracle qui incluent des répertoires Oracle. Chaque objet répertoire Oracle inclut le nom du dossier contenant les journaux redo à traiter. Ces répertoires Oracle ne sont pas représentés au niveau du système de fichiers. Il s'agit plutôt de répertoires logiques créés au niveau de la base de données Oracle. Vous pouvez les afficher dans la vue Oracle ALL_DIRECTORIES.

Si vous souhaitez AWS DMS créer ces annuaires Oracle, accordez le CREATE ANY DIRECTORY privilège spécifié ci-dessus. AWS DMS crée les noms de répertoires avec le DMS_ préfixe. Si vous n'accordez pas le privilège CREATE ANY DIRECTORY, créez manuellement les répertoires correspondants. Dans certains cas, lorsque vous créez manuellement les répertoires Oracle, l'utilisateur Oracle spécifié dans le point de terminaison source Oracle n'est pas l'utilisateur qui a créé ces répertoires. Dans ces cas, accordez également le privilège READ on DIRECTORY.

Si le point de terminaison source Oracle est en mode Active Dataguard Standby (ADG), consultez le billet Comment utiliser le lecteur binaire avec ADG sur le blog de base de données. AWS

Note

AWS DMS Le CDC ne prend pas en charge Active Dataguard Standby qui n'est pas configuré pour utiliser le service de rétablissement automatique du transport.

Dans certains cas, vous pouvez utiliser Oracle Managed Files (OMF) pour stocker les journaux. Ou le point de terminaison source se trouve dans ADG et vous ne pouvez donc pas accorder le privilège CREATE ANY DIRECTORY. Dans ces cas, créez manuellement les répertoires avec tous les emplacements de journal possibles avant de démarrer la tâche de AWS DMS réplication. Si AWS DMS ne trouve pas le répertoire précréé qu'il attend, la tâche s'arrête. En outre, AWS DMS ne supprime pas les entrées qu'il a créées dans la vue ALL_DIRECTORIES, donc supprimez-les manuellement.

Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM

Pour accéder aux journaux redo dans Automatic Storage Management (ASM) à l’aide de Binary Reader, accordez les privilèges suivants à l’utilisateur Oracle spécifié dans les paramètres de connexion au point de terminaison Oracle.

SELECT ON v_$transportable_platform
SYSASM -– To access the ASM account with Oracle 11g Release 2 (version 11.2.0.2) and higher, grant the Oracle endpoint user the SYSASM privilege. For older supported Oracle versions, it's typically sufficient to grant the Oracle endpoint user the SYSDBA privilege.

Vous pouvez valider l’accès au compte ASM en ouvrant une invite de commandes et en invoquant l’une des instructions suivantes, en fonction de votre version d’Oracle spécifiée précédemment.

Si vous avez besoin du privilège SYSDBA, utilisez ce qui suit.

sqlplus asmuser/asmpassword@+asmserver as sysdba

Si vous avez besoin du privilège SYSASM, utilisez ce qui suit. 

sqlplus asmuser/asmpassword@+asmserver as sysasm

Utilisation d’une instance autogérée d’Oracle Standby en tant que source avec Binary Reader pour la CDC dans AWS DMS

Pour configurer une instance d’Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC, commencez par prendre connaissance des prérequis suivants :

  • AWS DMS prend actuellement en charge uniquement Oracle Active Data Guard Standby.

  • Assurez-vous que la configuration d’Oracle Data Guard utilise :

    • Services de transport redo pour les transferts automatisés de données redo.

    • Services d’application pour appliquer automatiquement redo à la base de données de secours.

Pour confirmer que ces exigences sont satisfaites, exécutez la requête suivante.

SQL> select open_mode, database_role from v$database;

À partir du résultat de cette requête, vérifiez que la base de données de secours est ouverte en mode READ ONLY et que redo est appliqué automatiquement. Par exemple :

OPEN_MODE             DATABASE_ROLE
--------------------  ----------------
READ ONLY WITH APPLY  PHYSICAL STANDBY
Pour configurer une instance d’Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC

  1. Accordez les privilèges supplémentaires requis pour accéder aux fichiers journaux de secours.

    GRANT SELECT ON v_$standby_log TO db_user;

  2. Créez un point de terminaison source pour Oracle Standby à l’aide d’ AWS Management Console ou d’ AWS CLI. Lors de la création du point de terminaison, spécifiez les attributs de connexion supplémentaires suivants.

    useLogminerReader=N;useBfile=Y;
    Note

    Dans AWS DMS, vous pouvez utiliser des attributs de connexion supplémentaires pour spécifier si vous souhaitez migrer à partir des journaux d'archives plutôt que des journaux de rétablissement. Pour plus d’informations, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

  3. Configurez la destination du journal archivé.

    DMS Binary Reader pour la source Oracle sans ASM utilise les répertoires Oracle pour accéder aux journaux redo archivés. Si la base de données est configurée de sorte à utiliser la zone de récupération rapide (FRA) comme destination du journal d’archivage, l’emplacement des fichiers redo d’archivage n’est pas constant. Chaque jour de génération de journaux redo archivés entraîne la création d’un nouveau répertoire dans la FRA en utilisant le format de nom de répertoire AAAA_MM_JJ. Par exemple : 

    DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD

    Lorsque DMS a besoin d’accéder à des fichiers redo archivés dans le répertoire FRA récemment créé et que la base de données principale en lecture-écriture est utilisée en tant que source, DMS crée un nouveau répertoire Oracle ou remplace un répertoire Oracle existant, comme suit. 

    CREATE OR REPLACE DIRECTORY dmsrep_taskid AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD’;

    Lorsque la base de données de secours est utilisée en tant que source, DMS ne parvient pas à créer ou à remplacer le répertoire Oracle, car la base de données est en mode lecture seule. Toutefois, vous pouvez choisir d’effectuer l’une des étapes supplémentaires suivantes :

    1. Modifiez log_archive_dest_id_1 de sorte à utiliser un chemin réel plutôt que la FRA dans une configuration de ce type où Oracle ne créera pas de sous-répertoires quotidiens :

      ALTER SYSTEM SET log_archive_dest_1=’LOCATION=full directory path’

      Créez ensuite un objet de répertoire Oracle à utiliser par DMS :

      CREATE OR REPLACE DIRECTORY dms_archived_logs AS ‘full directory path’;

    2. Créez une destination de journal d’archivage supplémentaire et un objet de répertoire Oracle pointant vers cette destination. Par exemple :

      ALTER SYSTEM SET log_archive_dest_3=’LOCATION=full directory path’; 
CREATE DIRECTORY dms_archived_log AS ‘full directory path’;

      Ajoutez ensuite un attribut de connexion supplémentaire au point de terminaison source de la tâche :

      archivedLogDestId=3

    3. Précréez manuellement des objets de répertoire Oracle à utiliser par DMS.

      CREATE DIRECTORY dms_archived_log_20210301 AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/2021_03_01’;
CREATE DIRECTORY dms_archived_log_20210302 AS ‘DB_RECOVERY_FILE_DEST>/SID>/archivelog/2021_03_02’; 
...

    4. Créez une tâche de planificateur Oracle qui s’exécute quotidiennement et crée le répertoire requis.

Utilisation d’une base de données gérée par l’utilisateur sur Oracle Cloud Infrastructure (OCI) en tant que source pour la CDC dans AWS DMS

Une base de données gérée par l’utilisateur est une base de données que vous configurez et contrôlez, comme une base de données Oracle créée sur une machine virtuelle (VM), un matériel nu ou un serveur Exadata. Il peut également s’agir de bases de données que vous configurez et contrôlez et qui s’exécutent sur une infrastructure dédiée, comme Oracle Cloud Infrastructure (OCI). Les informations suivantes décrivent les privilèges et les configurations dont vous avez besoin lorsque vous utilisez une base de données Oracle gérée par l’utilisateur sur OCI en tant que source pour la capture des données de modification (CDC) dans AWS DMS.

Pour configurer une base de données Oracle gérée par l’utilisateur et hébergée par OCI en tant que source pour la capture des données de modification

  1. Accordez les privilèges de compte d’utilisateur requis pour une base de données source Oracle gérée par l’utilisateur sur OCI. Pour plus d’informations, consultez Privilèges de compte pour un point de terminaison source Oracle autogéré.

  2. Accordez les privilèges de compte requis lors de l’utilisation de Binary Reader pour accéder aux journaux redo. Pour plus d’informations, consultez Privilèges de compte requis lors de l’utilisation de Binary Reader.

  3. Ajoutez les privilèges de compte requis lors de l’utilisation de Binary Reader avec Oracle Automatic Storage Management (ASM). Pour plus d’informations, consultez Privilèges de compte supplémentaires requis lors de l’utilisation de Binary Reader avec Oracle ASM.

  4. Configurez une journalisation supplémentaire. Pour plus d’informations, consultez Configuration d’une journalisation supplémentaire.

  5. Configurez le chiffrement TDE. Pour plus d’informations, consultez Méthodes de chiffrement lors de l’utilisation d’une base de données Oracle comme point de terminaison source.

Les limitations suivantes s’appliquent lors de la réplication de données à partir d’une base de données source Oracle sur Oracle Cloud Infrastructure (OCI).

Limites

  • DMS ne prend pas en charge l'utilisation d'Oracle LogMiner pour accéder aux journaux de journalisation.

  • DMS ne prend pas en charge Autonomous DB.

Utilisation d'une base de données Oracle AWS gérée comme source pour AWS DMS

Une base de données AWS gérée est une base de données qui se trouve sur un service Amazon tel qu'Amazon RDS, Amazon Aurora ou Amazon S3. Vous trouverez ci-dessous les privilèges et les configurations que vous devez configurer lorsque vous utilisez une base de données Oracle AWS gérée avec AWS DMS.

Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS

Accordez les privilèges suivants au compte d’utilisateur Oracle spécifié dans la définition du point de terminaison source Oracle.

Important

Pour toutes les valeurs de paramètre telles que db_user et any-replicated-table, Oracle suppose que la valeur est entièrement en majuscules, sauf si vous spécifiez la valeur avec un identifiant sensible à la casse. Supposons, par exemple, que vous créez une valeur db_user sans utiliser de guillemets, comme dans CREATE USER myuser ou CREATE USER MYUSER. Dans ce cas, Oracle identifie et stocke la valeur entièrement en majuscules (MYUSER). Si vous utilisez des guillemets, comme dans CREATE USER "MyUser" ou CREATE USER 'MyUser', Oracle identifie et stocke la valeur sensible à la casse que vous spécifiez (MyUser).

GRANT CREATE SESSION to db_user;
GRANT SELECT ANY TRANSACTION to db_user;
GRANT SELECT on DBA_TABLESPACES to db_user;
GRANT SELECT ON any-replicated-table to db_user;
GRANT EXECUTE on rdsadmin.rdsadmin_util to db_user;
 -- For Oracle 12c or higher:
GRANT LOGMINING to db_user; – Required only if the Oracle version is 12c or higher.

De plus, accordez les autorisations SELECT et EXECUTE sur les objets SYS à l’aide de la procédure Amazon RDS rdsadmin.rdsadmin_util.grant_sys_object, comme indiqué. Pour plus d'informations, consultez la page Attribution des privilèges SELECT ou EXECUTE aux objets SYS.

exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','db_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'db_user', 'EXECUTE');

-- (as of Oracle versions 12.1 and higher)
exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'db_user', 'SELECT');

-- (for Amazon RDS Active Dataguard Standby (ADG))
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'db_user', 'SELECT'); 

-- (for transparent data encryption (TDE))

exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'db_user', 'SELECT'); 
               
-- (for validation with LOB columns)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'db_user', 'EXECUTE');
                    
-- (for binary reader)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','db_user','SELECT'); 
                    
-- Required when the source database is Oracle Data guard, and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATAGUARD_STATS', 'db_user', 'SELECT');

Pour plus d’informations sur l’utilisation d’Amazon RDS Active Dataguard Standby (ADG) avec AWS DMS , consultez Utilisation d’Amazon RDS Oracle Standby (réplica de lecture) en tant que source avec Binary Reader pour la CDC dans AWS DMS.

Pour plus d'informations sur l'utilisation d'Oracle TDE avec AWS DMS, consultezMéthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.

Conditions préalables à la gestion des transactions ouvertes pour Oracle Standby

Lorsque vous utilisez AWS DMS les versions 3.4.6 ou supérieures, effectuez les étapes suivantes pour gérer les transactions ouvertes pour Oracle Standby.

  1. Créez un lien de base de données nommé AWSDMS_DBLINK sur la base de données principale. DMS_USER utilisera ce lien pour se connecter à la base de données principale. Notez que le lien de base de données est exécuté à partir de l’instance de secours pour interroger les transactions ouvertes exécutées sur la base de données principale. Consultez l'exemple suivant. 

    CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
   CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
   USING '(DESCRIPTION=
            (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
            (CONNECT_DATA=(SERVICE_NAME=SID))
          )';

  2. Vérifiez que la connexion au lien de base de données avec DMS_USER est établie, comme indiqué dans l’exemple suivant.

    select 1 from dual@AWSDMS_DBLINK

Configuration d'une source Oracle AWS gérée pour AWS DMS

Avant d'utiliser une base de données Oracle AWS gérée comme source pour AWS DMS, effectuez les tâches suivantes pour la base de données Oracle :

  • Activez les sauvegardes automatiques. Pour plus d’informations sur l’activation des sauvegardes automatiques, consultez Activation des sauvegardes automatiques dans le Guide de l’utilisateur Amazon RDS.

  • Configurez la journalisation supplémentaire.

  • Configurez l'archivage. L'archivage des journaux redo de votre instance de base de données Amazon RDS for Oracle permet de récupérer les informations du journal AWS DMS à l'aide d'Oracle LogMiner ou de Binary Reader.

Pour configurer l'archivage

  1. Exécutez la commande rdsadmin.rdsadmin_util.set_configuration pour configurer l'archivage.

    Par exemple, pour conserver les journaux redo archivés pendant 24 heures, exécutez la commande suivante.

    exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
commit;
    Note

    La validation est obligatoire pour qu’une modification prenne effet.

  2. Vérifiez que votre espace de stockage est suffisant pour les journaux redo archivés pendant la période spécifiée. Par exemple, si votre période de conservation est de 24 heures, calculez la taille totale de vos journaux redo archivés accumulés sur une heure type de traitement des transactions et multipliez ce total par 24. Comparez ce total calculé sur 24 heures avec votre espace de stockage disponible et déterminez si vous disposez de suffisamment d’espace de stockage pour traiter les transactions 24 h/24.

Pour configurer la journalisation supplémentaire

  1. Exécutez la commande suivante pour activer la journalisation supplémentaire au niveau de la base de données.

    exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

  2. Exécutez la commande suivante pour activer la journalisation supplémentaire des clés primaires.

    exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

  3. (Facultatif) Activez la journalisation supplémentaire au niveau des clés, au niveau de la table.

    Votre base de données source exige un peu plus de temps système lorsqu’une journalisation supplémentaire au niveau des clés est activée. Par conséquent, si vous ne migrez qu’un sous-ensemble de vos tables, vous souhaiterez peut-être activer la journalisation supplémentaire au niveau des clés, au niveau de la table. Pour activer la journalisation supplémentaire au niveau des clés, au niveau de la table, exécutez la commande suivante.

    alter table table_name add supplemental log data (PRIMARY KEY) columns;

Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS

Vous pouvez configurer l'accès AWS DMS à la source des journaux redo de l'instance Amazon RDS pour Oracle à l'aide de Binary Reader for CDC.

Note

Pour utiliser Oracle LogMiner, les privilèges de compte utilisateur minimaux requis sont suffisants. Pour plus d’informations, consultez Privilèges de compte utilisateur requis sur une source Oracle AWS gérée pour AWS DMS.

Pour utiliser AWS DMS Binary Reader, spécifiez des paramètres supplémentaires et des attributs de connexion supplémentaires pour le point de terminaison source Oracle, en fonction de votre AWS DMS version.

La prise en charge de Binary Reader est disponible dans les versions suivantes d’Amazon RDS for Oracle :

  • Oracle 11.2 : versions 11.2.0.4V11 et ultérieures

  • Oracle 12.1 : versions 12.1.0.2.V7 et ultérieures

  • Oracle 12.2 : toutes les versions

  • Oracle 18.0 : toutes les versions

  • Oracle 19.0 : toutes les versions

Pour configurer CDC à l'aide d' Binary Reader

  1. Connectez-vous à la base de données source Amazon RDS for Oracle en tant qu’utilisateur principal et exécutez les procédures stockées suivantes pour créer les répertoires au niveau du serveur.

    exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;

  2. Accordez les privilèges suivants au compte d’utilisateur Oracle utilisé pour accéder au point de terminaison source Oracle.

    GRANT READ ON DIRECTORY ONLINELOG_DIR TO db_user;
GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO db_user;

  3. Définissez les attributs de connexion supplémentaires suivants sur le point de terminaison source Amazon RDS Oracle :

    • Pour RDS Oracle versions 11.2 et 12.1, définissez les attributs suivants.

      useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;useAlternateFolderForOnline=true;
oraclePathPrefix=/rdsdbdata/db/{$DATABASE_NAME}_A/;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;

    • Pour RDS Oracle versions 12.2, 18.0 et 19.0, définissez les attributs suivants.

      useLogminerReader=N;useBfile=Y;
Note

Assurez-vous qu’il n’y ait pas d’espace après le point-virgule (;) si vous avez plusieurs paramètres d’attribut ; par exemple, oneSetting;thenAnother.

Pour plus d’informations sur la configuration d’une tâche de CDC, consultez Configuration de CDC sur une base de données source Oracle.

Utilisation d’Amazon RDS Oracle Standby (réplica de lecture) en tant que source avec Binary Reader pour la CDC dans AWS DMS

Vérifiez les conditions préalables suivantes pour utiliser Amazon RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC dans AWS DMS :

  • Utilisez l’utilisateur principal Oracle pour configurer Binary Reader.

  • Assurez-vous qu'il ne prend AWS DMS actuellement en charge que l'utilisation d'Oracle Active Data Guard Standby.

Ensuite, procédez comme suit pour utiliser RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC.

Pour configurer RDS for Oracle Standby en tant que source lors de l’utilisation de Binary Reader pour la CDC

  1. Connectez-vous à l’instance principale de RDS for Oracle en tant qu’utilisateur principal.

  2. Exécutez les procédures stockées suivantes, comme indiqué dans le Guide de l’utilisateur Amazon RDS, pour créer les répertoires au niveau du serveur.

    exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;

  3. Identifiez les répertoires créés à l’étape 2.

    SELECT directory_name, directory_path FROM all_directories
WHERE directory_name LIKE ( 'ARCHIVELOG_DIR_%' )
        OR directory_name LIKE ( 'ONLINELOG_DIR_%' )

    Par exemple, le code précédent affiche une liste de répertoires comme ce qui suit.

  4. Accordez le privilège Read sur les répertoires précédents au compte d’utilisateur Oracle utilisé pour accéder à Oracle Standby.

    GRANT READ ON DIRECTORY ARCHIVELOG_DIR_A TO db_user;
GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TO db_user;
GRANT READ ON DIRECTORY ONLINELOG_DIR_A TO db_user;
GRANT READ ON DIRECTORY ONLINELOG_DIR_B TO db_user;

  5. Changez de journal d’archivage sur l’instance principale. Cela garantit que les modifications apportées à ALL_DIRECTORIES sont également transmises à Oracle Standby.

  6. Exécutez une requête ALL_DIRECTORIES sur Oracle Standby pour confirmer que les modifications ont été appliquées.

  7. Créez un point de terminaison source pour Oracle Standby à l'aide de la console AWS DMS de gestion ou AWS Command Line Interface (AWS CLI). Lors de la création du point de terminaison, spécifiez les attributs de connexion supplémentaires suivants.

    useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2

  8. Après avoir créé le point de terminaison, utilisez Tester la connexion du point de terminaison sur la page Créer un point de terminaison de la console ou utilisez la AWS CLI test-connection commande pour vérifier que la connectivité est établie.

Restrictions relatives à l'utilisation d'Oracle comme source pour AWS DMS

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données Oracle comme source pour AWS DMS:

  • AWS DMS prend en charge les types de données Oracle Extended dans les AWS DMS versions 3.5.0 et supérieures.

  • AWS DMS ne prend pas en charge les noms d'objets longs (plus de 30 octets).

  • AWS DMS ne prend pas en charge les index basés sur les fonctions.

  • Si vous gérez la journalisation supplémentaire et que vous effectuez des transformations sur l’une des colonnes, assurez-vous que la journalisation supplémentaire est activée pour tous les champs et colonnes. Pour plus d’informations sur la configuration d’une journalisation supplémentaire, consultez les rubriques suivantes :

  • AWS DMS ne prend pas en charge la base de données racine de conteneurs à locataires multiples (CDB$ROOT). Il prend en charge une PDB qui utilise Binary Reader.

  • AWS DMS ne prend pas en charge les contraintes différées.

  • Les LOB sécurisés sont pris en charge en mode LOB complet uniquement en effectuant une recherche d’objets LOB.

  • AWS DMS prend en charge la rename table table-name to new-table-name syntaxe de toutes les versions Oracle 11 et supérieures prises en charge. Cette syntaxe n’est pas prise en charge pour les bases de données sources Oracle version 10.

  • AWS DMS ne reproduit pas les résultats de l'instruction DDL. ALTER TABLE ADD column data_type DEFAULT default_value Au lieu de répliquer default_value vers la cible, il définit la nouvelle colonne sur NULL.

  • Lorsque vous utilisez AWS DMS la version 3.4.7 ou supérieure, pour répliquer les modifications résultant d'opérations de partition ou de sous-partition, procédez comme suit avant de démarrer une tâche DMS.

    • Créez manuellement la structure de table partitionnée (DDL) ;

    • Assurez-vous que la DDL est la même sur la source Oracle et la cible Oracle ;

    • Définissez l’attribut de connexion supplémentaire enableHomogenousPartitionOps=true.

    Pour plus d’informations sur enableHomogenousPartitionOps, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS. Notez également que sur les tâches FULL+CDC, DMS ne réplique pas les modifications de données capturées dans le cadre des modifications mises en cache. Dans ce cas d’utilisation, recréez la structure de table sur la cible Oracle et rechargez les tables en question.

    Avant la AWS DMS version 3.4.7 :

    DMS ne réplique pas les modifications de données résultant d’opérations de partition ou de sous-partition (ADD, DROP, EXCHANGE et TRUNCATE). Ces mises à jour peuvent provoquer les erreurs suivantes pendant la réplication :

    • Pour les opérations ADD, les mises à jour et les suppressions des données ajoutées peuvent déclencher un avertissement « 0 lignes affectées ».

    • Pour les opérations DROP et TRUNCATE, les nouvelles insertions peuvent générer des erreurs de « doublons ».

    • Les opérations EXCHANGE peuvent déclencher à la fois un avertissement « 0 lignes affectées » et des erreurs « doublons ».

    Pour répliquer les modifications résultant d'opérations de partition ou de sous-partition, rechargez les tables en question. Après l’ajout d’une nouvelle partition vide, les opérations sur la partition récemment ajoutée sont répliquées vers la cible comme d’habitude.

  • AWS DMS les versions antérieures à 3.4 ne prennent pas en charge les modifications de données sur la cible résultant de l'exécution de l'CREATE TABLE ASinstruction sur la source. Toutefois, la nouvelle table est créée sur la cible.

  • AWS DMS ne capture pas les modifications apportées par le DBMS_REDEFINITION package Oracle, par exemple les métadonnées de la table et le OBJECT_ID champ.

  • AWS DMS mappe les colonnes BLOB et CLOB vides NULL sur la cible.

  • Lors de la capture de modifications avec Oracle 11 LogMiner, une mise à jour sur une colonne CLOB dont la longueur de chaîne est supérieure à 1982 est perdue et la cible n'est pas mise à jour.

  • Lors de la capture des données de modification (CDC), les mises à jour par lots des colonnes numériques définies comme clé primaire AWS DMS ne sont pas prises en charge.

  • AWS DMS ne prend pas en charge certaines UPDATE commandes. L’exemple suivant est une commande UPDATE non prise en charge.

    UPDATE TEST_TABLE SET KEY=KEY+1;

    Ici, TEST_TABLE est le nom de la table et KEY est une colonne numérique définie comme une clé primaire.

  • AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONG et LONG RAW. Vous pouvez plutôt utiliser le mode LOB limité pour migrer ces types de données vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONG ou LONG RAW de plus de 64 Ko.

  • AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes XMLTYPE. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes XMLTYPE vers une cible Oracle. En mode LOB limité, DMS tronque toutes les données dont la taille est supérieure à la variable « Taille de LOB maximale » définie par l’utilisateur. La valeur maximale recommandée pour « Taille de LOB maximale » est de 100 Mo.

  • AWS DMS ne reproduit pas les tables dont les noms contiennent des apostrophes.

  • AWS DMS soutient le CDC à partir de vues matérialisées. Mais DMS ne prend pas en charge la CDC à partir d’une autre vue.

  • AWS DMS ne prend pas en charge le CDC pour les tables organisées par index avec un segment de débordement.

  • AWS DMS ne prend pas en charge l'Drop Partitionopération pour les tables partitionnées par référence avec la valeur enableHomogenousPartitionOps définie sur. true

  • Lorsque vous utilisez Oracle LogMiner pour accéder aux journaux de journalisation, les limites suivantes AWS DMS s'appliquent :

    • Pour Oracle 12 uniquement, AWS DMS ne reproduit aucune modification apportée aux colonnes LOB.

    • Pour toutes les versions d'Oracle, AWS DMS ne reproduit pas le résultat des UPDATE opérations sur les colonnes LOB XMLTYPE et sur les colonnes.

    • AWS DMS ne prend pas en charge les transactions XA lors de la réplication lors de l'utilisation d'Oracle LogMiner.

    • Oracle LogMiner ne prend pas en charge les connexions à une base de données enfichable (PDB). Pour vous connecter à un PDB, accédez aux fichiers de journalisation à l'aide de Binary Reader.

    • Les opérations SHRINK SPACE ne sont pas prises en charge.

  • Lorsque vous utilisez Binary Reader, il AWS DMS présente les limites suivantes :

    • Il ne prend pas en charge les clusters de tables.

    • Il ne prend en charge que les opérations SHRINK SPACE au niveau de la table. Ce niveau inclut la table complète, les partitions et les sous-partitions.

    • Il ne prend pas en charge les modifications apportées aux tables organisées par index avec compression de clé.

    • Il ne prend pas en charge l’implémentation de journaux redo en ligne sur les appareils bruts.

    • Binary Reader prend en charge le TDE uniquement pour les bases de données Oracle autogérées, car RDS for Oracle ne prend pas en charge la récupération des mots de passe de portefeuille pour les clés de chiffrement TDE.

  • AWS DMS ne prend pas en charge les connexions à une source Oracle Amazon RDS à l'aide d'un proxy Oracle Automatic Storage Management (ASM).

  • AWS DMS ne prend pas en charge les colonnes virtuelles.

  • AWS DMS ne prend pas en charge le type de ROWID données ou les vues matérialisées basées sur une colonne ROWID.

    AWS DMS prend partiellement en charge Oracle Materialized Views. Pour les chargements complets, DMS peut effectuer une copie de chargement complet d’une vue matérialisée Oracle. DMS copie la vue matérialisée en tant que table de base sur le système cible et ignore les colonnes ROWID dans la vue matérialisée. Pour la réplication continue (CDC), DMS essaie de répliquer les modifications apportées aux données de la vue matérialisée, mais il est possible que les résultats ne soient pas idéaux. Plus précisément, si la vue matérialisée est complètement actualisée, DMS réplique les suppressions individuelles pour toutes les lignes, puis les insertions individuelles pour toutes les lignes. Cet exercice nécessite beaucoup de ressources et risque d’être peu performant pour les vues matérialisées comportant un grand nombre de lignes. Pour une réplication continue où les vues matérialisées sont actualisées rapidement, DMS essaie de traiter et de répliquer les modifications des données d’actualisation rapide. Dans les deux cas, DMS ignore toutes les colonnes ROWID dans la vue matérialisée.

  • AWS DMS ne charge ni ne capture de tables temporaires globales.

  • Pour les cibles S3 utilisant la réplication, activez la journalisation supplémentaire sur chaque colonne afin que les mises à jour des lignes source puissent capturer chaque valeur de colonne. Voici un exemple : alter table yourtablename add supplemental log data (all) columns;.

  • La mise à jour d’une ligne comportant une clé unique composite contenant null ne peut pas être répliquée sur la cible.

  • AWS DMS ne prend pas en charge l'utilisation de plusieurs clés de chiffrement Oracle TDE sur le même point de terminaison source. Chaque point de terminaison ne peut avoir qu’un seul attribut pour le nom de clé de chiffrement TDE « securityDbEncryptionName » et un seul mot de passe TDE pour cette clé.

  • Lors de la réplication depuis Amazon RDS for Oracle, le TDE n'est pris en charge qu'avec un tablespace chiffré et avec Oracle. LogMiner

  • AWS DMS ne prend pas en charge plusieurs opérations de renommage de table en succession rapide.

  • Lorsque vous utilisez Oracle 19.0 comme source, les fonctionnalités suivantes AWS DMS ne sont pas prises en charge :

    • Redirection DML dans Data Guard

    • Tables hybrides partitionnées

    • Comptes Oracle de schéma uniquement

  • AWS DMS ne prend pas en charge la migration de tables ou de vues de type BIN$ ouDR$.

  • À partir d'Oracle 18.x, la capture des données de modification (CDC) AWS DMS n'est pas prise en charge à partir d'Oracle Express Edition (Oracle Database XE).

  • Lors de la migration de données à partir d’une colonne CHAR, DMS tronque les espaces de fin.

  • AWS DMS ne prend pas en charge la réplication à partir de conteneurs d'applications.

  • AWS DMS ne prend pas en charge l'exécution de la base de données Oracle Flashback et des points de restauration, car ces opérations affectent la cohérence des fichiers Oracle Redo Log.

  • La procédure INSERT de chargement direct avec l’option d’exécution parallèle n’est pas prise en charge dans les cas suivants :

    • Tables non compressées de plus de 255 colonnes

    • Taille de ligne supérieure à 8 Ko

    • Tables HCC Exadata

    • Base de données exécutée sur la plateforme Big Endian

  • Une table source n’ayant ni clé primaire ni clé unique nécessite l’activation de la journalisation supplémentaire ALL COLUMN. Des activités de journal redo supplémentaires seront créées et la latence de la CDC DMS peut augmenter.

  • AWS DMS ne migre pas les données des colonnes invisibles de votre base de données source. Pour inclure ces colonnes dans la portée de migration, utilisez l’instruction ALTER TABLE pour les rendre visibles.

Prise en charge de SSL pour un point de terminaison Oracle

AWS DMS Les points de terminaison Oracle prennent en charge le protocole SSL V3 pour les modes none et verify-ca SSL. Pour utiliser SSL avec un point de terminaison Oracle, vous devez charger le portefeuille Oracle pour le point de terminaison au lieu des fichiers de certificat .pem.

Utilisation d'un certificat existant pour Oracle SSL

Pour utiliser une installation de client Oracle existante afin de créer le fichier de portefeuille Oracle à partir du fichier de certificat CA, procédez comme suit.

Pour utiliser une installation de client Oracle existante pour Oracle SSL avec AWS DMS

  1. Définissez la variable système ORACLE_HOME sur l'emplacement de votre répertoire dbhome_1 en exécutant la commande suivante.

    
prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1

  2. Ajouter $ORACLE_HOME/lib à la variable système LD_LIBRARY_PATH.

    
prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

  3. Créez un répertoire pour le portefeuille Oracle dans $ORACLE_HOME/ssl_wallet.

    
prompt>mkdir $ORACLE_HOME/ssl_wallet

  4. Placez le fichier .pem du certificat de l'autorité de certification dans le répertoire ssl_wallet. Si vous utilisez Amazon RDS, vous pouvez télécharger le fichier de certificat d’autorité de certification racine rds-ca-2015-root.pem hébergé par Amazon RDS. Pour plus d’informations sur le téléchargement de ce fichier, consultez Utilisation de SSL/TLS pour chiffrer une connexion à une instance de base de données dans le Guide de l’utilisateur Amazon RDS.

  5. Exécutez les commandes suivantes pour créer le portefeuille Oracle.

    
prompt>orapki wallet create -wallet $ORACLE_HOME/ssl_wallet -auto_login_only
prompt>orapki wallet add -wallet $ORACLE_HOME/ssl_wallet -trusted_cert -cert 
   $ORACLE_HOME/ssl_wallet/ca-cert.pem -auto_login_only

Une fois que vous avez terminé les étapes précédentes, vous pouvez importer le fichier de portefeuille avec l'appel d'API ImportCertificate en spécifiant le paramètre de portefeuille de certificat. Vous pouvez ensuite utiliser le certificat de portefeuille importé lorsque vous sélectionnez verify-ca comme mode SSL lors de la création ou de la modification de votre point de terminaison Oracle.

Note

Les portefeuilles Oracle sont des fichiers binaires. AWS DMS accepte ces fichiers tels quels.

Utilisation d'un certificat auto-signé pour Oracle SSL

Pour utiliser un certificat auto-signé pour Oracle SSL, procédez comme suit en supposant que le mot de passe du portefeuille Oracle est oracle123.

Pour utiliser un certificat auto-signé pour Oracle SSL avec AWS DMS

  1. Créez un répertoire que vous utiliserez pour travailler avec le certificat auto-signé.

    mkdir -p /u01/app/oracle/self_signed_cert

  2. Accédez au répertoire que vous avez créé à l'étape précédente.

    cd /u01/app/oracle/self_signed_cert

  3. Créez une clé racine.

    openssl genrsa -out self-rootCA.key 2048

  4. Auto-signez un certificat racine à l'aide de la clé racine que vous avez créée à l'étape précédente.

    openssl req -x509 -new -nodes -key self-rootCA.key 
        -sha256 -days 3650 -out self-rootCA.pem

    Utilisez les paramètres d’entrée suivants.

    • Country Name (2 letter code) [XX], par exemple : AU

    • State or Province Name (full name) [], par exemple : NSW

    • Locality Name (e.g., city) [Default City], par exemple : Sydney

    • Organization Name (e.g., company) [Default Company Ltd], par exemple : AmazonWebService

    • Organizational Unit Name (e.g., section) [], par exemple : DBeng

    • Common Name (e.g., your name or your server's hostname) [], par exemple : aws

    • Email Address [], par exemple : abcd.efgh@amazonwebservice.com

  5. Créez un répertoire de portefeuille Oracle pour la base de données Oracle.

    mkdir -p /u01/app/oracle/wallet

  6. Créez un nouveau portefeuille Oracle.

    orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local

  7. Ajoutez le certificat racine au portefeuille Oracle.

    orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -trusted_cert 
-cert /u01/app/oracle/self_signed_cert/self-rootCA.pem

  8. Affichez le contenu du portefeuille Oracle. La liste doit inclure le certificat racine. 

    orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123

    Par exemple, ce paramètre peut s’afficher comme suit.

    Requested Certificates:
User Certificates:
Trusted Certificates:
Subject:        CN=aws,OU=DBeng,O= AmazonWebService,L=Sydney,ST=NSW,C=AU

  9. Générez la demande de signature de certificat (CSR) à l'aide de l'utilitaire ORAPKI.

    orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 
-dn "CN=aws" -keysize 2048 -sign_alg sha256

  10. Exécutez la commande suivante.

    openssl pkcs12 -in /u01/app/oracle/wallet/ewallet.p12 -nodes -out /u01/app/oracle/wallet/nonoracle_wallet.pem

    Ce paramètre a un résultat similaire à ce qui suit.

    Enter Import Password:
MAC verified OK
Warning unsupported bag type: secretBag

  11. Mettez « dms » comme nom commun.

    openssl req -new -key /u01/app/oracle/wallet/nonoracle_wallet.pem -out certdms.csr

    Utilisez les paramètres d’entrée suivants.

    • Country Name (2 letter code) [XX], par exemple : AU

    • State or Province Name (full name) [], par exemple : NSW

    • Locality Name (e.g., city) [Default City], par exemple : Sydney

    • Organization Name (e.g., company) [Default Company Ltd], par exemple : AmazonWebService

    • Organizational Unit Name (e.g., section) [], par exemple : aws

    • Common Name (e.g., your name or your server's hostname) [], par exemple : aws

    • Email Address [], par exemple : abcd.efgh@amazonwebservice.com

    Assurez-vous qu’il est différent de l’étape 4. Pour ce faire, remplacez par exemple le nom de l’unité organisationnelle par un autre nom, comme indiqué.

    Entrez les attributs supplémentaires suivants à envoyer avec votre demande de certificat.

    • A challenge password [], par exemple : oracle123

    • An optional company name [], par exemple : aws

  12. Obtenez la signature de certificat.

    openssl req -noout -text -in certdms.csr | grep -i signature

    La clé de signature de ce message est sha256WithRSAEncryption.

  13. Exécutez la commande suivante pour générer le fichier de certificat (.crt).

    openssl x509 -req -in certdms.csr -CA self-rootCA.pem -CAkey self-rootCA.key 
-CAcreateserial -out certdms.crt -days 365 -sha256

    Ce paramètre a un résultat similaire à ce qui suit.

    Signature ok
subject=/C=AU/ST=NSW/L=Sydney/O=awsweb/OU=DBeng/CN=aws
Getting CA Private Key

  14. Ajoutez le certificat au portefeuille.

    orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt

  15. Consultez le portefeuille. Il doit comporter deux entrées. Consultez le code suivant.

    orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123

  16. Configurez le fichier sqlnet.ora ($ORACLE_HOME/network/admin/sqlnet.ora).

    WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/wallet/)
     )
   ) 

SQLNET.AUTHENTICATION_SERVICES = (NONE)
SSL_VERSION = 1.0
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)

  17. Arrêtez l'écouteur Oracle.

    lsnrctl stop

  18. Ajoutez des entrées pour SSL dans le fichier listener.ora ($ORACLE_HOME/network/admin/listener.ora).

    SSL_CLIENT_AUTHENTICATION = FALSE
WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/wallet/)
    )
  )

SID_LIST_LISTENER =
 (SID_LIST =
  (SID_DESC =
   (GLOBAL_DBNAME = SID)
   (ORACLE_HOME = ORACLE_HOME)
   (SID_NAME = SID)
  )
 )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

  19. Configurez le fichier tnsnames.ora ($ORACLE_HOME/network/admin/tnsnames.ora).

    <SID>=
(DESCRIPTION=
        (ADDRESS_LIST = 
                (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
        )
        (CONNECT_DATA =
                (SERVER = DEDICATED)
                (SERVICE_NAME = <SID>)
        )
)

<SID>_ssl=
(DESCRIPTION=
        (ADDRESS_LIST = 
                (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
        )
        (CONNECT_DATA =
                (SERVER = DEDICATED)
                (SERVICE_NAME = <SID>)
        )
)

  20. Redémarrez l'écouteur Oracle.

    lsnrctl start

  21. Affichez le statut de l'écouteur Oracle.

    lsnrctl status

  22. Testez la connexion SSL à la base de données à partir de localhost à l'aide de sqlplus et de l'entrée SSL tnsnames.

    sqlplus -L ORACLE_USER@SID_ssl

  23. Vérifiez que la connexion a été établie à l'aide de SSL.

    SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL;

SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
--------------------------------------------------------------------------------
tcps

  24. Accédez au répertoire contenant le certificat auto-signé.

    cd /u01/app/oracle/self_signed_cert

  25. Créez un nouveau portefeuille client Oracle AWS DMS à utiliser.

    orapki wallet create -wallet ./ -auto_login_only

  26. Ajoutez le certificat racine auto-signé au portefeuille Oracle.

    orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only

  27. Répertoriez le contenu du portefeuille Oracle AWS DMS à utiliser. La liste doit inclure le certificat racine auto-signé.

    orapki wallet display -wallet ./

    Ce paramètre a un résultat similaire à ce qui suit.

    Trusted Certificates:
Subject:        CN=aws,OU=DBeng,O=AmazonWebService,L=Sydney,ST=NSW,C=AU

  28. Téléchargez le portefeuille Oracle que vous venez de créer sur AWS DMS.

Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS

Dans le tableau suivant, vous trouverez les méthodes de chiffrement transparent des données (TDE) prises AWS DMS en charge lors de l'utilisation d'une base de données source Oracle.

Méthode d'accès aux journaux de journalisation Espace disque logique TDE Colonne TDE
Oracle LogMiner Oui Oui
Binary Reader Oui Oui

AWS DMS prend en charge Oracle TDE lorsque vous utilisez Binary Reader, à la fois au niveau des colonnes et au niveau de l'espace disque logique. Pour utiliser le chiffrement TDE avec AWS DMS, identifiez d'abord l'emplacement du portefeuille Oracle où sont stockés la clé de chiffrement TDE et le mot de passe TDE. Identifiez ensuite la clé de chiffrement TDE et le mot de passe appropriés pour le point de terminaison source Oracle.

Pour identifier et spécifier la clé de chiffrement et le mot de passe pour le chiffrement TDE

  1. Exécutez la requête suivante pour trouver le portefeuille de chiffrement Oracle sur l’hôte de base de données Oracle.

    SQL> SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET;

WRL_PARAMETER
--------------------------------------------------------------------------------
/u01/oracle/product/12.2.0/dbhome_1/data/wallet/

    Dans cet exemple, l’emplacement du portefeuille est /u01/oracle/product/12.2.0/dbhome_1/data/wallet/.

  2. Obtenez l’ID de la clé principale à l’aide de l’une des options de chiffrement suivantes, selon celle qui renvoie cette valeur.

    1. Pour le chiffrement au niveau de la table ou de la colonne, exécutez les requêtes suivantes.

      SQL> SELECT OBJECT_ID FROM ALL_OBJECTS 
WHERE OWNER='DMS_USER' AND OBJECT_NAME='TEST_TDE_COLUMN' AND OBJECT_TYPE='TABLE';

OBJECT_ID
---------------
81046
SQL> SELECT MKEYID FROM SYS.ENC$ WHERE OBJ#=81046;

MKEYID
------------
AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

      Dans cet exemple, l’ID de clé principale est AWGDC9glSk8Xv+3bVveiVSg (MKEYID). Si vous obtenez une valeur pour MKEYID, vous pouvez passer à l’étape 3. Sinon, poursuivez avec l’étape 2.2.

      Note

      Les caractères 'A' de la chaîne de fin (AAA...) ne font pas partie de la valeur.

    2. Pour le chiffrement au niveau de l’espace de table, exécutez les requêtes suivantes.

      SQL> SELECT TABLESPACE_NAME, ENCRYPTED FROM dba_tablespaces;
TABLESPACE_NAME                ENC
------------------------------ ---
SYSTEM                         NO
SYSAUX                         NO
UNDOTBS1                       NO
TEMP                           NO
USERS                          NO
TEST_ENCRYT                    YES
SQL> SELECT name,utl_raw.cast_to_varchar2( utl_encode.base64_encode('01'||substr(mkeyid,1,4))) || utl_raw.cast_to_varchar2( utl_encode.base64_encode(substr(mkeyid,5,length(mkeyid)))) masterkeyid_base64
FROM (SELECT t.name, RAWTOHEX(x.mkid) mkeyid FROM v$tablespace t, x$kcbtek x WHERE t.ts#=x.ts#)
WHERE name = 'TEST_ENCRYT';

NAME                           MASTERKEYID_BASE64
------------------------------ ----------------------------------
TEST_ENCRYT                    AWGDC9glSk8Xv+3bVveiVSg=

      Dans cet exemple, l’ID de clé principale est AWGDC9glSk8Xv+3bVveiVSg (TEST_ENCRYT). Si les étapes 2.1 et 2.2 renvoient une valeur, elles sont toujours identiques.

      Le caractère '=' de fin ne fait pas partie de la valeur.

  3. À partir de la ligne de commande, répertoriez les entrées du portefeuille de chiffrement sur l’hôte de base de données Oracle source.

    $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -list
Oracle Secret Store entries:
ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ORACLE.SECURITY.DB.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY
ORACLE.SECURITY.ID.ENCRYPTION.
ORACLE.SECURITY.KB.ENCRYPTION.
ORACLE.SECURITY.KM.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA

    Recherchez l’entrée contenant l’ID de clé principale que vous avez trouvé à l’étape 2 (AWGDC9glSk8Xv+3bVveiVSg). Cette entrée est le nom de la clé de chiffrement TDE.

  4. Consultez les détails de l’entrée que vous avez trouvés à l’étape précédente.

    $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Oracle Secret Store Tool : Version 12.2.0.1.0
Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.
Enter wallet password:
ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA = AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

    Entrez le mot de passe du portefeuille pour voir le résultat.

    Ici, la valeur à droite de '=' est le mot de passe TDE.

  5. Spécifiez le nom de la clé de chiffrement TDE pour le point de terminaison source Oracle en définissant l’attribut de connexion supplémentaire securityDbEncryptionName.

    securityDbEncryptionName=ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

  6. Indiquez le mot de passe TDE associé à cette clé sur la console dans le champ Mot de passe de la source Oracle. Utilisez l’ordre suivant pour mettre en forme les valeurs de mot de passe séparées par des virgules, qui se terminent par la valeur du mot de passe TDE.

    Oracle_db_password,ASM_Password,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

    Spécifiez les valeurs de mot de passe dans cet ordre quelle que soit la configuration de votre base de données Oracle. Par exemple, si vous utilisez TDE, mais que la base de données Oracle n’utilise pas ASM, spécifiez les valeurs de mot de passe dans l’ordre suivant séparé par des virgules.

    Oracle_db_password,,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

Si les informations d'identification TDE que vous spécifiez sont incorrectes, la tâche de AWS DMS migration n'échoue pas. Toutefois, la tâche ne lit pas et n’applique pas non plus les modifications de réplication continue à la base de données cible. Après avoir démarré la tâche, surveillez les Statistiques de table sur la page de la tâche de migration de la console pour vous assurer que les modifications sont répliquées.

Si un administrateur de base de données modifie les valeurs d’informations d’identification TDE pour la base de données Oracle pendant l’exécution de la tâche, celle-ci échoue. Le message d’erreur contient le nouveau nom de clé de chiffrement TDE. Pour spécifier de nouvelles valeurs et redémarrer la tâche, procédez comme suit.

Important

Vous ne pouvez pas manipuler un portefeuille TDE créé dans un emplacement Oracle Automatic Storage Management (ASM), car les commandes au niveau du système d’exploitation telles que cp, mv, orapki et mkstore corrompent les fichiers du portefeuille stockés dans un emplacement ASM. Cette restriction est spécifique aux fichiers de portefeuille TDE stockés dans un emplacement ASM uniquement, mais pas aux fichiers de portefeuille TDE stockés dans un répertoire local du système d’exploitation.

Pour manipuler un portefeuille TDE stocké dans ASM à l’aide de commandes au niveau du système d’exploitation, créez un magasin de clés local et fusionnez-le avec le magasin de clés ASM, comme suit :

  1. Créez un magasin de clés local.

    ADMINISTER KEY MANAGEMENT create keystore file system wallet location identified by wallet password;

  2. Fusionnez le magasin de clés ASM avec le magasin de clés local.

    ADMINISTER KEY MANAGEMENT merge keystore ASM wallet location identified by wallet password into existing keystore file system wallet location identified by wallet password with backup;

Ensuite, pour répertorier les entrées du portefeuille de chiffrement et le mot de passe TDE, exécutez les étapes 3 et 4 sur le magasin de clés local.

Méthodes de compression prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS

Dans le tableau suivant, vous trouverez les méthodes de compression prises AWS DMS en charge lors de l'utilisation d'une base de données source Oracle. Comme le montre le tableau, la prise en charge de la compression dépend à la fois de la version de votre base de données Oracle et de la configuration de DMS pour utiliser Oracle LogMiner pour accéder aux journaux de journalisation.

Version Base OLTP

HCC (à partir d’Oracle 11g R2 ou ultérieur)

 Autres
Oracle 10 Non N/A N/A Non
Oracle 11 ou version ultérieure — Oracle LogMiner Oui Oui Oui Oui — Toutes les méthodes de compression prises en charge par Oracle LogMiner.
Oracle 11 ou version ultérieure : Binary Reader Oui Oui Oui : pour plus d’informations, consultez la remarque suivante. Oui
Note

Lorsque le point de terminaison source Oracle est configuré pour utiliser Binary Reader, le niveau Query Low de la méthode de compression HCC est pris en charge uniquement pour les tâches à pleine charge.

Réplication de tables imbriquées en utilisant Oracle comme source pour AWS DMS

AWS DMS prend en charge la réplication des tables Oracle contenant des colonnes qui sont des tables imbriquées ou des types définis. Pour activer cette fonctionnalité, ajoutez le paramètre d’attribut de connexion supplémentaire suivant au point de terminaison source Oracle.

allowSelectNestedTables=true;

AWS DMS crée les tables cibles à partir des tables imbriquées Oracle en tant que tables parent et enfant normales sur la cible sans contrainte unique. Pour accéder aux données correctes sur la cible, joignez les tables parent et enfant. Pour ce faire, créez d'abord manuellement un index non unique sur la colonne NESTED_TABLE_ID de la table enfant cible. Vous pouvez ensuite utiliser la colonne NESTED_TABLE_ID dans la clause de jointure ON avec la colonne parent qui correspond au nom de la table enfant. En outre, la création d'un tel index améliore les performances lorsque les données de la table enfant cible sont mises à jour ou supprimées par AWS DMS. Pour obtenir un exemple, consultez Exemple de jointure pour les tables parent et enfant sur la cible.

Nous vous recommandons de configurer la tâche pour qu'elle s'arrête une fois la charge complète terminée. Ensuite, créez ces index non uniques pour toutes les tables enfants répliquées sur la cible et reprenez la tâche.

Si une table imbriquée capturée est ajoutée à une table parent existante (capturée ou non capturée), elle AWS DMS est gérée correctement. Toutefois, l'index non unique de la table cible correspondante n'est pas créé. Dans ce cas, si la table enfant cible devient extrêmement volumineuse, les performances peuvent être affectées. Dans ce cas, nous vous recommandons d'arrêter la tâche, de créer l'index, puis de reprendre la tâche.

Une fois les tables imbriquées répliquées vers la cible, faites en sorte que l'administrateur de base de données exécute une jointure sur les tables parent et enfant correspondantes pour aplatir les données.

Conditions préalables à la réplication des tables imbriquées Oracle en tant que source

Assurez-vous de répliquer les tables parentes pour toutes les tables imbriquées répliquées. Incluez à la fois les tables parents (les tables contenant la colonne de table imbriquée) et les tables enfants (c'est-à-dire imbriquées) dans les AWS DMS mappages de tables.

Types de tables imbriquées Oracle pris en charge en tant que source

AWS DMS prend en charge les types de tables imbriquées Oracle suivants en tant que source :

  • Type de données

  • Objet défini par l'utilisateur

Limitations de la prise en charge par AWS DMS des tables imbriquées Oracle en tant que source

AWS DMS présente les limites suivantes en ce qui concerne sa prise en charge des tables imbriquées Oracle en tant que source :

  • AWS DMS ne prend en charge qu'un seul niveau d'imbrication de tables.

  • AWS DMS le mappage des tables ne vérifie pas que la ou les tables parent et enfant sont sélectionnées pour la réplication. Autrement dit, il est possible de sélectionner une table parent sans enfant ou une table enfant sans parent.

Comment AWS DMS réplique les tables imbriquées Oracle en tant que source

AWS DMS réplique les tables parentes et imbriquées vers la cible comme suit :

  • AWS DMS crée la table parent identique à la source. Il définit ensuite la colonne imbriquée dans le parent comme RAW(16) et inclut une référence aux tables imbriquées du parent dans sa colonne NESTED_TABLE_ID.

  • AWS DMS crée la table enfant identique à la source imbriquée, mais avec une colonne supplémentaire nomméeNESTED_TABLE_ID. Cette colonne a le même type et la même valeur que la colonne imbriquée parent correspondante et a la même signification.

Exemple de jointure pour les tables parent et enfant sur la cible

Pour aplatir la table parent, exécutez une jointure entre les tables parent et enfant, comme illustré dans l'exemple suivant :

  1. Créez la table Type.

    CREATE OR REPLACE TYPE NESTED_TEST_T AS TABLE OF VARCHAR(50);

  2. Créez la table parent avec une colonne de type NESTED_TEST_T, tel que défini précédemment.

    CREATE TABLE NESTED_PARENT_TEST (ID NUMBER(10,0) PRIMARY KEY, NAME NESTED_TEST_T) NESTED TABLE NAME STORE AS NAME_KEY;

  3. Aplatissez la table NESTED_PARENT_TEST à l'aide d'une jointure avec la table NAME_KEY enfant où CHILD.NESTED_TABLE_ID correspond à PARENT.NAME.

    SELECT … FROM NESTED_PARENT_TEST PARENT, NAME_KEY CHILD WHERE CHILD.NESTED_
TABLE_ID = PARENT.NAME;

Stockage de REDO sur Oracle ASM lors de l'utilisation d'Oracle comme source pour AWS DMS

Pour les sources Oracle à forte génération de REDO, le stockage de REDO sur Oracle ASM peut améliorer les performances, en particulier dans une configuration RAC, car vous pouvez configurer DMS pour distribuer les lectures ASM REDO sur tous les nœuds ASM.

Pour utiliser cette configuration, utilisez l’attribut de connexion asmServer. Par exemple, la chaîne de connexion suivante distribue les lectures DMS REDO sur 3 nœuds ASM :

asmServer=(DESCRIPTION=(CONNECT_TIMEOUT=8)(ENABLE=BROKEN)(LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node1_ip_address)(PORT=asm_node1_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node2_ip_address)(PORT=asm_node2_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node3_ip_address)(PORT=asm_node3_port_number)))
(CONNECT_DATA=(SERVICE_NAME=+ASM)))

Lorsque vous utilisez NFS pour stocker Oracle REDO, il est important de vous assurer que les correctifs client DNFS (Direct NFS) appropriés sont appliqués, en particulier les correctifs qui corrigent le bogue Oracle 25224242. Pour plus d’informations, consultez la publication Oracle suivante concernant les correctifs liés au client Direct NFS, intitulée Recommended Patches for Direct NFS Client.

En outre, pour améliorer les performances de lecture NFS, nous vous recommandons d’augmenter la valeur de rsize et de wsize dans fstab pour le volume NFS, comme indiqué dans l’exemple suivant.

NAS_name_here:/ora_DATA1_archive /u09/oradata/DATA1 nfs rw,bg,hard,nointr,tcp,nfsvers=3,_netdev,
timeo=600,rsize=262144,wsize=262144

Ajustez également la valeur de tcp-max-xfer-size comme suit :

vserver nfs modify -vserver vserver -tcp-max-xfer-size 262144

Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source Oracle comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la create-endpoint commande dans le AWS CLI, avec la syntaxe --oracle-settings '{"EndpointSetting": "value", ...}' JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec Oracle en tant que source sont indiqués dans le tableau suivant.

Name (Nom) Description
AccessAlternateDirectly

Définissez cet attribut sur false pour utiliser Binary Reader afin de capturer les données de modification pour Amazon RDS for Oracle en tant que source. Cette opération indique à l'instance DMS qu'elle ne doit pas accéder aux journaux redo via un remplacement de préfixe de chemin spécifié en utilisant un accès direct aux fichiers. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : true

Valeurs valides : true/false

Exemple : --oracle-settings '{"AccessAlternateDirectly": false}'

AdditionalArchivedLogDestId

Définissez cet attribut avec ArchivedLogDestId dans une configuration principale/de secours. Cet attribut est utile lors d’un basculement lorsqu’une base de données Oracle Data Guard est utilisée en tant que source. Dans ce cas, vous AWS DMS devez savoir de quelle destination obtenir les journaux de restauration des archives pour lire les modifications. En effet, après le basculement, l’instance précédemment principale est désormais une instance de secours.

Bien qu'il AWS DMS supporte l'utilisation de l'RESETLOGSoption Oracle pour ouvrir la base de données, ne l'utilisez jamais RESETLOGS sauf si cela est nécessaire. Pour plus d’informations sur RESETLOGS, consultez RMAN Data Repair Concepts dans le Guide de l’utilisateur Oracle® Database Backup and Recovery.

Valeurs valides : ID de destination d’archive

Exemple : --oracle-settings '{"AdditionalArchivedLogDestId": 2}'

AddSupplementalLogging

Définissez cet attribut pour configurer la journalisation supplémentaire au niveau de la table pour la base de données Oracle. Cet attribut active l’une des options suivantes sur toutes les tables sélectionnées pour une tâche de migration, en fonction des métadonnées des tables :

  • Journalisation supplémentaire des COLONNES PRIMARY KEY

  • Journalisation supplémentaire des COLONNES UNIQUE KEY

  • Journalisation supplémentaire de TOUTES LES COLONNES

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"AddSupplementalLogging": false}'

Note

Si vous utilisez cette option, vous devez encore activer la journalisation supplémentaire au niveau de la base de données, comme indiqué précédemment.

AllowSelectNestedTables

Définissez cet attribut sur true pour activer la réplication des tables Oracle contenant des colonnes imbriquées ou des types définis. Pour plus d’informations, consultez Réplication de tables imbriquées en utilisant Oracle comme source pour AWS DMS.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"AllowSelectNestedTables": true}'

ArchivedLogDestId

Spécifie l'ID de la destination des journaux redo archivés. Cette valeur doit être identique à un des nombres de la colonne dest_id de la vue v$archived_log. Si vous travaillez avec une destination de journal redo supplémentaire, nous vous recommandons d’utiliser l’attribut AdditionalArchivedLogDestId pour spécifier l’ID de destination supplémentaire. Cela améliore les performances en garantissant l'accès aux journaux appropriés dès le départ.

Valeur par défaut : 1

Valeurs valides : nombre

Exemple : --oracle-settings '{"ArchivedLogDestId": 1}'

ArchivedLogsOnly

Lorsque ce champ est défini sur Y, il accède AWS DMS uniquement aux journaux de journalisation archivés. Si les journaux de restauration archivés sont stockés uniquement sur Oracle ASM, le compte AWS DMS utilisateur doit disposer de privilèges ASM.

Valeur par défaut : N

Valeurs valides : Y/N

Exemple : --oracle-settings '{"ArchivedLogsOnly": Y}'

asmUsePLSQLArray (ECA uniquement)

Utilisez cet attribut de connexion supplémentaire (ECA) lors de la capture des modifications de source avec BinaryReader. Ce paramètre permet à DMS de mettre en mémoire tampon 50 lectures au niveau ASM par thread de lecture unique tout en contrôlant le nombre de threads à l’aide de l’attribut parallelASMReadThread. Lorsque vous définissez cet attribut, le lecteur AWS DMS binaire utilise un bloc PL/SQL anonyme pour capturer les données de restauration et les renvoyer à l'instance de réplication sous forme de grande mémoire tampon. Cela réduit le nombre d’allers retours jusqu’à la source. Cela peut améliorer de manière significative les performances de capture de source, mais cela entraîne une consommation de mémoire PGA plus élevée sur l’instance ASM. Des problèmes de stabilité peuvent survenir si la mémoire cible n’est pas suffisante. Vous pouvez utiliser la formule suivante pour estimer l’utilisation totale de la mémoire PGA sur l’instance ASM par tâche DMS : number_of_redo_threads * parallelASMReadThreads * 7 MB

Valeur par défaut : false

Valeurs valides : true/false

Exemple d’ECA : asmUsePLSQLArray=true;

ConvertTimestampWithZoneToUTC

Définissez cet attribut sur true pour convertir la valeur d’horodatage des colonnes « TIMESTAMP WITH TIME ZONE » et « TIMESTAMP WITH LOCAL TIME ZONE » au format UTC. Par défaut, la valeur de cet attribut est « false » et les données seront répliquées en utilisant le fuseau horaire de la base de données source.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"ConvertTimestampWithZoneToUTC": true}'

EnableHomogenousPartitionOps

Définissez cet attribut sur true pour permettre la réplication des opérations DDL de partition et de sous-partition Oracle pour une migration Oracle homogène.

Notez que cette fonctionnalité et cette amélioration ont été introduites dans la AWS DMS version 3.4.7.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"EnableHomogenousPartitionOps": true}'

EnableHomogenousTablespace

Définissez cet attribut pour activer la réplication homogène d'un espace de table et créer des tables ou des index existants sous le même espace de table sur la cible.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"EnableHomogenousTablespace": true}'

EscapeCharacter

Définissez cet attribut sur un caractère d’échappement. Ce caractère d’échappement vous permet de faire en sorte qu’un caractère générique unique se comporte comme un caractère normal dans les expressions de mappage de table. Pour plus d’informations, consultez Caractères génériques dans le mappage de table.

Valeur par défaut : Null

Valeurs valides : tout caractère autre qu’un caractère générique

Exemple : --oracle-settings '{"EscapeCharacter": "#"}'

Note

Vous pouvez uniquement utiliser escapeCharacter pour les noms de table. Il n’exclut pas les caractères des noms de schéma ou de colonne.

ExposeViews

Utilisez cet attribut pour extraire les données d’une vue une fois ; vous ne pouvez pas l’utiliser pour la réplication continue. Lorsque vous extrayez les données d’une vue, la vue est représentée sous la forme d’une table sur le schéma cible.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"ExposeViews": true}'

ExtraArchivedLogDestIds

Spécifie les ID d'une ou de plusieurs destinations pour un ou plusieurs journaux redo archivés. Ces ID sont les valeurs de la colonne dest_id dans la vue v$archived_log. Utilisez ce paramètre avec l'attribut de connexion ArchivedLogDestId supplémentaire dans une primary-to-single configuration ou une primary-to-multiple-standby configuration.

Ce paramètre est utile lors d'un basculement lorsque vous utilisez une base de données Oracle Data Guard comme source. Dans ce cas, il AWS DMS a besoin d'informations sur la destination à partir de laquelle obtenir les journaux de restauration des archives pour lire les modifications. AWS DMS en a besoin car après le basculement, l'instance principale précédente est une instance de secours.

Valeurs valides : ID de destination d’archive

Exemple : --oracle-settings '{"ExtraArchivedLogDestIds": 1}'

FailTasksOnLobTruncation

Lorsque la valeur true est définie, cet attribut provoque l'échec d'une tâche si la taille réelle d'une colonne LOB est supérieure à la valeur LobMaxSize spécifiée.

Si une tâche est définie sur le mode LOB limité et que cette option a pour valeur true, la tâche échoue au lieu de tronquer les données LOB.

Valeur par défaut : false

Valeurs valides : booléen

Exemple : --oracle-settings '{"FailTasksOnLobTruncation": true}'

filterTransactionsOfUser (ECA uniquement)

Utilisez cet attribut de connexion supplémentaire (ECA) pour permettre à DMS d'ignorer les transactions d'un utilisateur spécifié lors de la réplication des données d'Oracle lors de l'utilisation. LogMiner Vous pouvez transmettre des valeurs de nom d’utilisateur séparées par des virgules, mais elles doivent être entièrement en majuscules.

Exemple d’ECA : filterTransactionsOfUser=USERNAME;

NumberDataTypeScale

Spécifie l'échelle de nombres. Vous pouvez sélectionner une échelle jusqu’à 38, -1 pour FLOAT ou -2 pour VARCHAR. Par défaut, le type de données NUMBER est converti en précision 38, échelle 10.

Valeur par défaut : 10

Valeurs valides : -2 à 38 (-2 pour VARCHAR, -1 pour FLOAT)

Exemple : --oracle-settings '{"NumberDataTypeScale": 12}'

Note

Sélectionnez une combinaison d’échelle de précision, -1 (FLOAT) ou -2 (VARCHAR). DMS prend en charge toutes les combinaisons d’échelle de précision prises en charge par Oracle. Si la précision est supérieure ou égale à 39, sélectionnez -2 (VARCHAR). Le NumberDataTypeScale paramètre de la base de données Oracle est utilisé uniquement pour le type de données NUMBER (sans précision ni définition d'échelle explicites).

OpenTransactionWindow

Fournit le délai en minutes pour vérifier l’existence de transactions ouvertes pour une tâche de CDC uniquement.

Valeur par défaut : 0

Valeurs valides : entier compris entre 0 et 240

Exemple : openTransactionWindow=15;
OraclePathPrefix Définissez cet attribut de chaîne sur la valeur requise afin d'utiliser Binary Reader pour capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette valeur spécifie la racine Oracle utilisée par défaut pour accéder aux journaux redo. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : none

Valeur valide : /rdsdbdata/db/ORCL_A/

Exemple : --oracle-settings '{"OraclePathPrefix": "/rdsdbdata/db/ORCL_A/"}'
ParallelASMReadThreads

Définissez cet attribut pour modifier le nombre de threads configurés par DMS pour effectuer une capture des données de modification (CDC) à l’aide d’Oracle Automatic Storage Management (ASM). Vous pouvez spécifier un nombre entier compris entre 2 (par défaut) et 8 (maximum). Utilisez cet attribut avec l'attribut ReadAheadBlocks. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : 2

Valeurs valides : un nombre entier compris entre 2 à 8

Exemple : --oracle-settings '{"ParallelASMReadThreads": 6;}'
ReadAheadBlocks

Définissez cet attribut pour modifier le nombre de blocs de lecture anticipée configurés par DMS pour effectuer une CDC à l’aide d’Oracle Automatic Storage Management (ASM) et d’un stockage NAS non ASM. Vous pouvez spécifier un nombre entier compris entre 1000 (valeur par défaut) et 200 000 (maximum). Utilisez cet attribut avec l'attribut ParallelASMReadThreads. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : 1000

Valeurs valides : Un nombre entier compris entre 1000 à 200 000

Exemple : --oracle-settings '{"ReadAheadBlocks": 150000}'

ReadTableSpaceName

Lorsque la valeur true est définie, cet attribut prend en charge la réplication d'espace de table.

Valeur par défaut : false

Valeurs valides : booléen

Exemple : --oracle-settings '{"ReadTableSpaceName": true}'
ReplacePathPrefix Définissez cet attribut sur true (vrai) pour utiliser Binary Reader afin de capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Ce paramètre indique à l'instance DMS qu'elle doit remplacer la racine Oracle par défaut par le paramètre UsePathPrefix pour accéder aux journaux redo. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"ReplacePathPrefix": true}'

RetryInterval

Spécifie le nombre de secondes que le système attend avant de renvoyer une requête.

Valeur par défaut : 5

Valeurs valides : nombres à partir de 1

Exemple : --oracle-settings '{"RetryInterval": 6}'

SecurityDbEncryptionName

Spécifie le nom d'une clé utilisée pour le chiffrement transparent des données (TDE) des colonnes et de l'espace disque logique dans la base de données source Oracle. Pour de plus amples informations sur la définition de cet attribut et de son mot de passe associé sur le point de terminaison source Oracle, veuillez consulter Méthodes de chiffrement prises en charge pour l'utilisation d'Oracle comme source pour AWS DMS.

Valeur par défaut : ""

Valeurs valides : string

Exemple : --oracle-settings '{"SecurityDbEncryptionName": "ORACLE.SECURITY.DB.ENCRYPTION.Adg8m2dhkU/0v/m5QUaaNJEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}'

SpatialSdo2GeoJsonFunctionName

Pour les sources Oracle version 12.1 ou antérieures migrant vers des cibles PostgreSQL, utilisez cet attribut pour convertir SDO_GEOMETRY au format GEOJSON.

Par défaut, AWS DMS appelle la fonction SDO2GEOJSON personnalisée qui doit être présente et accessible à l' AWS DMS utilisateur. Vous pouvez également créer votre propre fonction personnalisée qui imite le fonctionnement de SDOGEOJSON et définir SpatialSdo2GeoJsonFunctionName pour l'appeler à la place.

Valeur par défaut : SDO2GEOJSON

Valeurs valides : string

Exemple : --oracle-settings '{"SpatialSdo2GeoJsonFunctionName": "myCustomSDO2GEOJSONFunction"}'

StandbyDelayTime

Utilisez cet attribut pour spécifier une durée en minutes pour le retard de synchronisation de l'instance de secours. Si la source est une base de données de secours Active Data Guard, utilisez cet attribut pour spécifier le décalage entre les bases de données principale et de secours.

Dans AWS DMS, vous pouvez créer une tâche Oracle CDC qui utilise une instance de secours Active Data Guard comme source pour répliquer les modifications en cours. Cela vous permet de ne plus avoir besoin de vous connecter à une base de données active pouvant être en production.

Valeur par défaut : 0

Valeurs valides : nombre

Exemple : --oracle-settings '{"StandbyDelayTime": 1}'

Remarque : lorsque vous utilisez DMS 3.4.6, 3.4.7 ou ultérieur, l’utilisation de ce paramètre de connexion est facultative. Dans les dernières versions de DMS 3.4.6 et 3.4.7, dms_user devrait avoir l’autorisation select sur V_$DATAGUARD_STATS, ce qui permet à DMS de calculer le délai de veille.
UseAlternateFolderForOnline Définissez cet attribut sur true (vrai) pour utiliser Binary Reader afin de capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette opération indique à l'instance DMS qu'elle doit utiliser un remplacement de préfixe spécifié pour accéder à tous les journaux redo en ligne. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : false

Valeurs valides : true/false

Exemple : --oracle-settings '{"UseAlternateFolderForOnline": true}'
UseBfile

Définissez cet attribut sur Y pour capturer les données modifiées à l'aide de l'utilitaire Binary Reader. Attribuez la valeur N à UseLogminerReader pour définir cet attribut sur Y. Pour utiliser Binary Reader avec Amazon RDS for Oracle en tant que source, définissez des attributs supplémentaires. Pour plus d'informations sur ce paramètre et l'utilisation d'Oracle Automatic Storage Management (ASM), consultez Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC.

Remarque : lorsque vous définissez cette valeur en tant qu’attribut de connexion supplémentaire (ECA), les valeurs valides sont « Y » et « N ». Lorsque vous définissez cette valeur en tant que paramètre de point de terminaison, les valeurs valides sont true et false.

Valeur par défaut : N

Valeurs valides : Y/N (lorsque vous définissez cette valeur en tant qu’ECA) ; true/false (lorsque vous définissez cette valeur en tant que paramètre de point de terminaison).

Exemple : --oracle-settings '{"UseBfile": Y}'

UseLogminerReader

Définissez cet attribut sur Y pour capturer les données de modification à l'aide de l' LogMiner utilitaire (valeur par défaut). Définissez cette option sur N si vous voulez qu' AWS DMS accède aux journaux redo en tant que fichier binaire. Lorsque vous définissez cette option sur N, ajoutez également le paramètre useBfile=Y. Pour plus d’informations sur ce paramètre et sur l’utilisation d’Oracle Automatic Storage Management (ASM), consultez Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC.

Remarque : lorsque vous définissez cette valeur en tant qu’attribut de connexion supplémentaire (ECA), les valeurs valides sont « Y » et « N ». Lorsque vous définissez cette valeur en tant que paramètre de point de terminaison, les valeurs valides sont true et false.

Valeur par défaut : Y

Valeurs valides : Y/N (lorsque vous définissez cette valeur en tant qu’ECA) ; true/false (lorsque vous définissez cette valeur en tant que paramètre de point de terminaison).

Exemple : --oracle-settings '{"UseLogminerReader": Y}'
UsePathPrefix Définissez cet attribut de chaîne sur la valeur requise afin d'utiliser Binary Reader pour capturer les données modifiées pour un Amazon RDS for Oracle en tant que source. Cette valeur spécifie le préfixe de chemin utilisé pour remplacer la racine Oracle utilisée par défaut pour accéder aux journaux redo. Pour plus d’informations, consultez Configuration d'une tâche CDC pour utiliser Binary Reader avec une source RDS pour Oracle pour AWS DMS.

Valeur par défaut : none

Valeur valide : /rdsdbdata/log/

Exemple : --oracle-settings '{"UsePathPrefix": "/rdsdbdata/log/"}'

Types de données sources pour Oracle

Le point de terminaison Oracle pour AWS DMS prend en charge la plupart des types de données Oracle. Le tableau suivant indique les types de données source Oracle pris en charge lors de l'utilisation AWS DMS et le mappage par défaut aux types de AWS DMS données.

Note

À l’exception des types de données LONG et LONG RAW, lors de la réplication d’une source Oracle vers une cible Oracle (réplication homogène), tous les types de données source et cibles seront identiques. Toutefois, le type de données LONG sera mappé aux objets CLOB et le type de données LONG RAW sera mappé aux objets BLOB.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.

Type de données Oracle

AWS DMS type de données

BINARY_FLOAT

REAL4

BINARY_DOUBLE

REAL8

BINAIRE

BYTES

FLOAT (P)

Si la précision est inférieure ou égale à 24, utilisez REAL4.

Si la précision est supérieure à 24, utilisez REAL8.

NUMBER (P,S)

Lorsque l’échelle est supérieure à 0, utilisez NUMERIC.

Lorsque l'échelle est 0 :

  • Lorsque la précision est inférieure ou égale à 2, utilisez INT1.

  • Et que la précision est supérieure à 2 et inférieure ou égale à 4, utilisez INT2.

  • Et que la précision est supérieure à 4 et inférieure ou égale à 9, utilisez INT4.

  • Et que la précision est supérieure à 9, utilisez NUMERIC.

  • Et que la précision est supérieure ou égale à l'échelle, utilisez NUMERIC.

Lorsque l’échelle est inférieure à 0, utilisez REAL8.

DATE

DATETIME

INTERVAL_YEAR TO MONTH

STRING (avec indication d'intervalle year_to_month)

INTERVAL_DAY TO SECOND

STRING (avec indication d'intervalle day_to_second)

TIMESTAMP

DATETIME

TIMESTAMP WITH TIME ZONE

STRING (avec indication timestamp_with_timezone)

TIMESTAMP WITH LOCAL TIME ZONE

STRING (avec indication timestamp_with_local_timezone)

CHAR

CHAÎNE

VARCHAR2

CHAÎNE

NCHAR

WSTRING

NVARCHAR2

WSTRING

RAW

BYTES

REAL

REAL8

BLOB

BLOB

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données BLOB pour une tâche spécifique. AWS DMS prend en charge les types de données BLOB uniquement dans les tables qui incluent une clé primaire.

CLOB

CLOB

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données CLOB pour une tâche spécifique. Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.

NCLOB

NCLOB

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données NCLOB pour une tâche spécifique. Pendant le CDC, AWS DMS prend en charge les types de données NCLOB uniquement dans les tables qui incluent une clé primaire.

LONG

CLOB

Le type de données LONG n'est pas pris en charge en mode d'application optimisé par lots (mode TurboStream CDC).

Pour utiliser ce type de données avec AWS DMS, activez l'utilisation de LOB pour une tâche spécifique.

Pendant le CDC ou le chargement complet, AWS DMS prend en charge les types de données LOB uniquement dans les tables dotées d'une clé primaire.

De plus, AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONGUES. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes LONG vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONGUES de plus de 64 Ko. Pour plus d'informations sur le support LOB dans AWS DMS, voir Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS

LONG RAW

BLOB

Le type de données LONG RAW n'est pas pris en charge en mode d'application optimisé par lots (mode TurboStream CDC).

Pour utiliser ce type de données avec AWS DMS, activez l'utilisation de LOB pour une tâche spécifique.

Pendant le CDC ou le chargement complet, AWS DMS prend en charge les types de données LOB uniquement dans les tables dotées d'une clé primaire.

De plus, AWS DMS ne prend pas en charge le mode LOB complet pour le chargement de colonnes LONG RAW. Vous pouvez plutôt utiliser le mode LOB limité pour migrer les colonnes LONG RAW vers une cible Oracle. En mode LOB limité, AWS DMS tronque à 64 Ko toutes les données que vous définissez comme des colonnes LONG RAW de plus de 64 Ko. Pour plus d'informations sur le support LOB dans AWS DMS, voir Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS

XMLTYPE

CLOB

SDO_GEOMETRY

BLOB (pour une migration Oracle vers Oracle)

CLOB (pour une migration Oracle vers PostgreSQL)

Les tables Oracle utilisées comme source avec des colonnes des types de données suivants ne sont pas prises en charge et ne peuvent pas être répliquées. La réplication des colonnes avec ces types de données a pour conséquence une colonne nulle.

  • BFILE

  • ROWID

  • REF

  • UROWID

  • Types de données définis par l'utilisateur

  • ANYDATA

  • VARRAY

Note

Les colonnes virtuelles ne sont pas prises en charge.

Migration de types de données spatiales Oracle

Les données spatiales identifient les informations de géométrie d'un objet ou d'un emplacement dans l'espace. Dans une base de données Oracle, la description géométrique d'un objet spatial est stockée dans un objet de type SDO_GEOMETRY. Dans cet objet, la description géométrique est stockée dans une seule ligne dans une seule colonne d'une table définie par l'utilisateur.

AWS DMS prend en charge la migration du type Oracle SDO_GEOMETRY d'une source Oracle vers une cible Oracle ou PostgreSQL.

Lorsque vous migrez des types de données spatiales Oracle à l'aide de AWS DMS, tenez compte des points suivants :

  • Lors de la migration vers une cible Oracle, assurez-vous de transférer manuellement les entrées USER_SDO_GEOM_METADATA qui incluent des informations de type.

  • Lors de la migration d'un point de terminaison source Oracle vers un point de terminaison AWS DMS cible PostgreSQL, crée des colonnes cibles. Ces colonnes contiennent des informations sur la géométrie et le type de géographie par défaut avec une dimension 2D et un identificateur de référence spatiale (SRID) égal à zéro (0). Par exemple : GEOMETRY, 2, 0.

  • Pour les sources Oracle version 12.1 ou antérieures qui migrent vers des cibles PostgreSQL, convertissez les objets SDO_GEOMETRY au format GEOJSON à l'aide de la fonction SDO2GEOJSON ou de l'attribut de connexion spatialSdo2GeoJsonFunctionName supplémentaire. Pour plus d’informations, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

  • AWS DMS prend en charge les migrations de colonnes spatiales Oracle pour le mode LOB complet uniquement. AWS DMS ne prend pas en charge les modes LOB limité ou LOB en ligne. Pour plus d’informations sur le mode LOB, consultez Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS.

  • Comme le mode Full LOB est AWS DMS uniquement compatible avec la migration des colonnes spatiales Oracle, la table des colonnes a besoin d'une clé primaire et d'une clé unique. Si la table n’a pas de clé primaire et de clé unique, elle est ignorée de la migration.