Référence des problèmes et des schémas de conversion

Les espaces de travail de conversion regroupent tous les problèmes de conversion en groupes et catégories pour vous aider à planifier la correction des erreurs et des avertissements de conversion. Chaque catégorie représente le type de travail que vous devrez peut-être effectuer pour résoudre les problèmes (examiner, refactoriser, ajuster les types de données). Les groupes fournissent une agrégation supplémentaire, car ils différencient des cas spécifiques à un niveau inférieur :

Écran de présentation de l'espace de travail de conversion, qui affiche les groupes et les catégories de problèmes de conversion.
Figure 1. Écran de présentation de l'espace de travail de conversion avec les groupes et les catégories de problèmes de conversion.
Écran de présentation de l'espace de travail de conversion, qui affiche les groupes et les catégories de problèmes de conversion.

Le tableau suivant recense tous les groupes de problèmes de conversion que vous pouvez rencontrer lors de la conversion de schéma :

ID de groupe de problèmes Description

Code source non valide

Cause possible

Les erreurs de ce groupe se produisent souvent lorsque Database Migration Service rencontre une syntaxe inconnue ou lorsque le code source Oracle n'est pas valide (par exemple, une procédure stockée ne contient pas le mot clé END;).

Atténuation possible

Corrigez les objets non valides dans la base de données Oracle source. Ensuite, actualisez l'instantané du schéma source dans Database Migration Service et réessayez le processus de conversion de schéma. Vous pouvez également exclure l'objet de la migration.

Objets référencés manquants

Cause possible

Database Migration Service utilise les métadonnées des objets de l'arborescence source pour améliorer la qualité de la conversion du code des objets dépendants. Si votre code fait référence à des objets qui ne sont pas inclus dans le schéma source, vous pouvez rencontrer des problèmes de conversion, car Database Migration Service ne peut pas déterminer la structure ni les types de données des colonnes, attributs ou objets référencés manquants.

Les erreurs possibles dans ce groupe incluent des types de données incorrects pour les types définis par l'utilisateur (UDT) ou les types de données VARCHAR par défaut pour les colonnes, les paramètres ou les variables.

Atténuation possible

Assurez-vous que tous les objets référencés sont ajoutés à l'arborescence source de Database Migration Service, ou ajustez manuellement le code PostgreSQL en fonction de votre connaissance du modèle de données source pour les dépendances manquantes.

Tables sans clé primaire

Cause possible

Database Migration Service requiert que toutes les tables possèdent une clé primaire. Pour les tables sans clé primaire, Database Migration Service ajoute une colonne NUMERIC nommée rowid à la table PostgreSQL cible. Cette colonne est renseignée avec les valeurs numériques correspondantes de la pseudo-colonne Oracle ROWID source. Pour s'assurer que les instructions INSERT n'échouent pas après la migration, Database Migration Service crée une séquence et l'utilise pour incrémenter automatiquement la colonne rowid.

Atténuation possible

Vous pouvez conserver ou supprimer la colonne rowid après la migration.

Fonctionnalité intégrée Oracle non compatible

Cause possible

Il est possible que vous utilisiez une fonctionnalité Oracle intégrée qui n'est pas compatible.

Atténuation possible

Recherchez une fonctionnalité similaire dans PostgreSQL et modifiez le code converti en conséquence. Dans certains cas, la fonctionnalité manquante peut être fournie par l' extension Orafce, disponible pour les migrations Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL.

SQLCODE non compatible

Cause possible

La fonction Oracle SQLCODE n'est pas compatible avec la conversion. SQLCODE renvoie un INTEGER, tandis que l'équivalent le plus proche dans PostgreSQL est la fonction SQLSTATE qui renvoie des valeurs TEXT.

Atténuation possible

Si votre code source ne repose pas sur le renvoi d'un entier par SQLCODE (par exemple, SQLCODE n'est jamais consigné que dans une colonne VARCHAR2 ou avec un message DBMS_OUTPUT), vous pouvez utiliser SQLSTATE en toute sécurité dans le code PostgreSQL.

Si votre code source repose sur SQLCODE renvoyant un entier (par exemple, si vous l'utilisez avec des variables NUMBER ou INTEGER, ou si vous enregistrez les valeurs de retour SQLCODE en tant que paramètres ou colonnes), vous devez refactoriser le code converti.

Fonction Oracle SQL non compatible

Cause possible

Certaines fonctions intégrées d'Oracle ne sont pas compatibles avec Database Migration Service pour la conversion.

Certaines fonctions peuvent avoir leurs équivalents dans PostgreSQL (par exemple, ASCII), d'autres peuvent partager le même nom, mais avoir des spécifications différentes (par exemple, les fonctions REGEXP%). Certaines fonctions peuvent ne pas exister du tout.

Atténuation possible

Identifiez la fonction Oracle qui a généré l'erreur.

  • Si la fonction existe avec le même comportement dans PostgreSQL, vous pouvez ignorer le message d'erreur, car le code converti devrait fonctionner de la même manière après la migration.

  • Si une fonction porte le même nom, mais fonctionne différemment ou n'existe pas dans PostgreSQL, vous pouvez essayer de corriger le code converti :

    • Créez une fonction définie par UDF;utilisateur portant le même nom dans la base de données de destination.
    • Remplacez l'appel de fonction dans la source par une expression équivalente.

    • Utilisez l'assistance à la conversion optimisée par Gemini. Pour en savoir plus, consultez Convertir le code et les schémas SQL Server avec l'aide de Gemini.

    • Certaines fonctions ou fonctionnalités de base de données Oracle peuvent être répliquées avec des extensions, telles que Orafce. Pour en savoir plus sur les extensions compatibles avec votre base de données de destination, consultez Extensions de base de données compatibles.

Packages intégrés Oracle non entièrement compatibles

Cause possible

Database Migration Service accepte certains packages intégrés Oracle, mais beaucoup ne sont pas entièrement compatibles avec la conversion, par exemple DBMS_STATS, DBMS_UTILITY ou DBMS_SQL.

Atténuation possible

Si vous utilisez des packages non compatibles, vous devrez peut-être :

  • Modifiez votre code. Par exemple, au lieu d'utiliser DBMS_STATS.GATHER_TABLE_STATS, vous pouvez utiliser une commande plus simple telle que ANALYZE.

    Les packages tels que UTL_FILE et DBMS_AQ peuvent nécessiter une refactorisation, car ils ne peuvent pas être facilement répliqués dans PostgreSQL.

  • Certaines fonctions ou fonctionnalités de base de données Oracle peuvent être répliquées avec des extensions, telles que Orafce. Pour en savoir plus sur les extensions compatibles avec votre base de données de destination, consultez Extensions de base de données compatibles.

Type de données Oracle non compatible avec la conversion

Cause possible

Certains types de données Oracle ne sont actuellement pas compatibles avec la conversion ou le déplacement de données.

Atténuation possible

Dans la plupart des cas, PostgreSQL dispose d'un type de données équivalent. Vous pouvez utiliser des fichiers de mappage de conversion pour personnaliser la logique de conversion et transformer le type de données Oracle non compatible en type de données PostgreSQL requis.

Pour en savoir plus sur la compatibilité des types de données, consultez Espaces de travail de conversion : présentation et objets compatibles.

Conflit d'attribution de noms

Cause possible

Ce groupe capture les problèmes où plusieurs objets de base de données (tels que des tables ou des vues matérialisées) sont convertis pour utiliser le même nom dans la base de données de destination. Par exemple, ce problème peut se produire lorsque vous avez des objets sources dont les noms ne diffèrent que par la casse. Les noms d'objets Oracle ne sont pas sensibles à la casse, mais PostgreSQL l'est. Les noms d'objets sont donc convertis pour utiliser la même chaîne.

Atténuation possible

Renommez les objets en conflit directement dans la base de données source ou dans le schéma converti dans l'éditeur de l'espace de travail de conversion. Vous pouvez également utiliser un fichier de mappage de conversion avec la directive RENAME_*.

Fonctionnalité source non compatible
Cause possible

Ce groupe capture tous les problèmes génériques liés aux fonctionnalités Oracle qui ne sont pas compatibles avec la conversion. Les problèmes de ce groupe ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible

Type d'objet de schéma non compatible

Cause possible

Database Migration Service n'est pas compatible avec certains types d'objets de schéma Oracle pour la conversion de code, car PostgreSQL ne dispose pas d'équivalents appropriés. Il peut s'agir, par exemple, de tables organisées par index (IOT), d'index de recherche de texte ou de corps pour les types définis par l'utilisateur (UDT).

Atténuation possible

Database Migration Service convertit les objets non compatibles en l'équivalent PostgreSQL le plus proche. Par exemple, les tables organisées en index deviennent des tables standards avec une contrainte de clé primaire, et les index de recherche de texte sont convertis en index B-tree. N'oubliez pas que ces conversions peuvent entraîner une perte de fonctionnalités spécifiques au type d'objet d'origine.

Fonctionnalité PL/SQL non compatible
Cause possible

Ce groupe capture tous les problèmes génériques liés aux fonctionnalités PL/SQL qui ne sont pas compatibles avec la conversion. Les problèmes de ce groupe ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible

Liaison groupée non compatible

Cause possible

La conversion de code de Database Migration Service n'est actuellement pas compatible avec les fonctionnalités de liaison groupée Oracle telles que BULK COLLECT, FORALL ou SAVE EXCEPTIONS.

Atténuation possible

Pour résoudre le problème, vous devez modifier le code qui utilise les fonctionnalités de liaison groupée. Vous pouvez envisager les différences entre l'architecture PostgreSQL et l'architecture Oracle, et déterminer si le traitement des tableaux est nécessaire dans PostgreSQL pour votre cas d'utilisation.

Il existe plusieurs stratégies pour aborder les opérations de liaison groupée Oracle dans PostgreSQL. Leur utilisation dépend de votre scénario spécifique. Nous vous recommandons donc d'utiliser l' assistance à la conversion optimisée par Gemini pour répondre à vos besoins spécifiques. Voici d'autres exemples de recommandations pour vous aider à vous lancer :

  • Pour un BULK COLLECT complet (sans LIMIT), vous pouvez essayer d'utiliser la fonction ARRAY_AGG.
  • Pour BULK COLLECT avec LIMIT, vous pouvez essayer d'utiliser un CURSOR FOR LOOP pour charger et traiter des lots de lignes dans des tableaux. Toutefois, si votre cas permet des modifications fonctionnelles, une alternative potentiellement plus simple consisterait à utiliser CURSOR FOR LOOP pour traiter une ligne à la fois (plutôt que de les charger dans des tableaux).
  • Pour les opérations FORALL, vous pouvez essayer le LMD basé sur un ensemble avec UNNEST si vous choisissez d'utiliser le traitement des tableaux.
  • Pour SAVE EXCEPTIONS, vous devrez peut-être écrire un gestionnaire d'exceptions dans un CURSOR FOR LOOP basé sur des lignes, car il n'existe pas de clause équivalente dans PostgreSQL.

Collections non compatibles

Cause possible

La conversion de code de Database Migration Service est partiellement compatible avec les collections Oracle.

Atténuation possible

Vous devez modifier le code PostgreSQL converti en conséquence. Lorsque vous résolvez des problèmes liés aux collections, n'oubliez pas que les tableaux PostgreSQL ne sont jamais creux. Si vous attribuez des éléments de manière éparse, les tableaux PostgreSQL peuvent renvoyer des résultats et des nombres de cardinalité différents de ceux des tableaux Oracle.

Étant donné que PostgreSQL n'est pas compatible avec les tableaux indexés par chaîne, selon la nature des données, vous pouvez utiliser JSON/JSONB ou les extensions hstore.

Fonctions de pipeline non compatibles

Cause possible

Les fonctions de pipeline ne sont pas compatibles avec Database Migration Service.

Atténuation possible

Vous pouvez remplacer les fonctions pipelined Oracle par des fonctions PostgreSQL renvoyant des ensembles. Nous vous recommandons d'ajuster le code en fonction de votre cas d'utilisation. Voici quelques exemples pour vous aider à vous lancer :

  1. Référencez le type PostgreSQL (UDT) converti à partir du type d'objet ou d'enregistrement Oracle source qui définit le type de ligne de la fonction pipelined. Ensuite, modifiez la clause de retour de la fonction PostgreSQL pour qu'elle soit RETURNS SETOF <type name> ou RETURNS TABLE, selon votre cas spécifique.

  2. Remplacez la valeur renvoyée dans le code PIPE ROW converti par RETURN NEXT <row or record variable>.

Le type de collection de la fonction pipelined source, utilisé dans la clause RETURN de la fonction Oracle, n'est pas nécessaire dans PostgreSQL.

SQL dynamique non compatible

Cause possible

Database Migration Service est partiellement compatible avec la conversion de SQL dynamique. Les mots clés Oracle EXECUTE IMMEDIATE, OPEN FOR et USING/INTO sont correctement convertis en leurs équivalents PostgreSQL, mais les chaînes SQL, LMD ou LDD dynamiques réelles ne sont pas converties.

Atténuation possible

Vous devez modifier le code converti pour l'adapter à vos besoins. Nous vous recommandons vivement d'utiliser l' assistance à la conversion optimisée par Gemini pour gérer le SQL dynamique.

Option CONNECT BY non compatible

Cause possible

La plupart des opérateurs, fonctions et pseudocolonnes CONNECT BY sont compatibles avec Database Migration Service et convertis en expressions de table communes (CTE) récursives PostgreSQL. Toutefois, certaines exceptions peuvent nécessiter votre attention. Par exemple, la clause ORDER SIBLINGS BY n'est acceptée que pour l'ordre croissant.

Atténuation possible

Il n'est pas possible de répliquer la clause ORDER SIBLINGS BY pour l'ordre décroissant de manière simple. Vous devrez donc peut-être restructurer votre code pour qu'il fonctionne avec l'ordre croissant.

Examinez les problèmes signalés avec les opérateurs CONNECT BY et ajustez le code si nécessaire. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

JSON non compatible

Cause possible

La compatibilité de Database Migration Service avec JSON pour le déplacement des données et la conversion du code est soumise à certaines limites :

  • JSONB n'est pas compatible avec le déplacement de données.
  • La conversion de code n'est pas compatible avec les fonctions ou opérateurs de requête JSON dans Oracle (tels que JSON_TABLE, JSON_QUERY, JSON_OBJECT[AGG], JSON_ARRAYAGG, JSON_PATCH).
  • Dans les versions d'Oracle antérieures à 21c, vous pouvez stocker des données JSON dans des colonnes VARCHAR2, CLOB ou BLOB, et les vérifier avec la condition IS JSON. Database Migration Service ne permet pas de convertir cette condition.
Atténuation possible

  • Pour déplacer des données JSON stockées dans des colonnes VARCHAR2, CLOB ou BLOB vers PostgreSQL, vous devrez peut-être écrire un fichier de mappage de conversion avec la directive MODIFY_TYPE.

    Exemple :

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_JSON_DATA:JSON

    Pour en savoir plus sur les fichiers de mappage de conversion, consultez Fichiers de mappage de conversion.

  • Pour convertir les fonctions et opérateurs Oracle JSON en PostgreSQL, vous pouvez utiliser des fonctions PostgreSQL telles que JSONB_ARRAY_ELEMENTS, JSON_AGG. Pour en savoir plus, consultez la section Fonctions et opérateurs JSON dans la documentation PostgreSQL.

Problèmes de verrouillage et de transactions

Cause possible

La conversion de code de Database Migration Service n'est pas compatible avec les instructions LOCK ou SAVEPOINT. PostgreSQL n'est pas compatible avec SAVEPOINT.

Atténuation possible
  • Divisez les blocs SAVEPOINT dans Oracle pour séparer les blocs de transaction dans PostgreSQL qui utilisent l'instruction ROLLBACK.
  • Pour implémenter DBMS_LOCK, utilisez l'extension PostgreSQL pg_dbms_lock. Cette extension simplifie la migration des verrous définis par l'utilisateur Oracle vers PostgreSQL en émulant la fonctionnalité du package Oracle DBMS_LOCK.

XML non compatible

Cause possible

Database Migration Service n'est pas compatible avec Oracle XMLTYPE ni avec les fonctions et opérateurs XML associés.

Atténuation possible

Bien que Database Migration Service n'accepte pas directement XMLTYPE, vous pouvez personnaliser les colonnes BLOB, CLOB, NVARCHAR2 ou VARCHAR2 au format XML pour le déplacement des données. PostgreSQL est compatible avec la fonctionnalité XML.

Pour migrer vos données XML, procédez comme suit :

  1. Créez un fichier de mappage de conversion avec la directive MODIFY_TYPE pour les données XML. Exemple : 

    MODIFY_TYPE SOURCE_TABLE_NAME:BLOB_COLUMN_NAME_WITH_XML_DATA:XML

    Pour en savoir plus sur les fichiers de mappage de conversion, consultez Fichiers de mappage de conversion.

  2. Démarrez le job de migration. Ce processus migre toutes les données d'Oracle vers PostgreSQL, à l'exception des données des colonnes de type XMLTYPE. Ces colonnes sont remplies avec des valeurs NULL dans PostgreSQL.
  3. Créez une table externe dans PostgreSQL en sélectionnant uniquement la colonne XMLTYPE d'Oracle. Incluez la colonne de clé primaire de la table source.
  4. Fusionnez les données XML de la table externe dans la table PostgreSQL d'origine.

Pour en savoir plus sur le fonctionnement de PostgreSQL avec XMLTYPE, consultez la section Fonctions XML dans la documentation PostgreSQL.

PIVOT non compatible

Cause possible

Database Migration Service n'est pas compatible avec les opérateurs de transposition PIVOT et UNPIVOT pour la conversion de code.
Atténuation possible

Vous pouvez effectuer une transposition PIVOT dans PostgreSQL à l'aide de l'extension tablefunc ou en réécrivant l'expression PIVOT source en agrégations conditionnelles. Exemple :

  • SUM(CASE WHEN <condition> THEN <value> ELSE 0 END)
  • COUNT(CASE WHEN <condition> THEN 1 END)

Vous pouvez créer des transpositions UNPIVOT, qui créent des paires clé-valeur à partir d'un ensemble de colonnes, dans PostgreSQL de différentes manières :

  • Combinaison d'une jointure LATERAL avec un ensemble de VALUES. Par exemple, SELECT ... FROM <table> CROSS JOIN LATERAL (VALUES ('<column1-name>', <column1>), ('<column2-name>', <column2>) AS u(column_name, column_value)).
  • Utiliser UNNEST avec des ARRAY. Par exemple, SELECT ..., UNNEST(ARRAY['<column1-name>', '<column2-name>']) AS column_name, UNNEST(ARRAY[column1, column2]) AS column_value FROM <table>.

Option d'instruction ALTER non compatible

Cause possible

Database Migration Service ne ALTER pas les instructions (qui sont souvent exécutées en SQL dynamique) pour la conversion.

Atténuation possible

Remplacez les instructions Oracle ALTER par la commande SET dans PostgreSQL. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Fonctionnalité SQL non compatible
Cause possible

Ce groupe capture tous les problèmes génériques liés aux fonctionnalités SQL qui ne sont pas compatibles avec la conversion. Les problèmes de ce groupe ne relèvent d'aucun autre groupe de problèmes plus spécifique. Par exemple, les déclencheurs d'événements de base de données, les instructions GRANT, les opérations INSERT multitables, le LMD sur les vues intégrées (INSERT INTO (SELECT ... FROM ...)) et les vues latérales.

Atténuation possible

Syntaxe pas compatible
Cause possible

Ce groupe capture tous les problèmes génériques liés à une syntaxe Oracle SQL ou PL/SQL non compatible. Les problèmes de ce groupe ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible

Modifiez votre code pour utiliser la syntaxe PostgreSQL équivalente sur le plan fonctionnel. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour ajuster le code. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Syntaxe SQL pas compatible

Cause possible

Votre code source utilise une syntaxe ou des éléments SQL qui ne sont pas compatibles avec Database Migration Service. Par exemple, le paramètre NLS_LANG de la fonction Oracle TO_DATE n'est pas accepté.

Atténuation possible
Syntaxe PL/SQL non compatible

Cause possible

Votre code source utilise une syntaxe ou des éléments PL/SQL qui ne sont pas compatibles avec Database Migration Service. Par exemple, les instructions INSERT basées sur des enregistrements (telles que INSERT INTO table VALUES r_variable) et PRAGMA RESTRICT_REFERENCES ne sont pas acceptées.

Atténuation possible

Modifiez votre code pour utiliser la syntaxe PostgreSQL équivalente sur le plan fonctionnel. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour ajuster le code. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Syntaxe de date et code temporel pas compatible

Cause possible

Database Migration Service peut générer des erreurs ou des avertissements pour une syntaxe, des opérations ou des expressions de date ou de code temporel non compatibles. Il peut s'agir, par exemple, de comparaisons entre des types de données incompatibles ou de l'utilisation du modèle de format TZH:TZM dans les codes temporels. Pour en savoir plus sur les objets et les types de données compatibles, consultez À propos des espaces de travail de conversion.

Atténuation possible

Vous pouvez recréer la plupart des expressions de date et de code temporel à l'aide d'équivalents PostgreSQL. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Éléments non compatibles de la syntaxe de gestion des exceptions d'Oracle

Cause possible

La conversion de code de Database Migration Service n'est pas compatible avec les éléments de syntaxe d'exception Oracle PL/SQL suivants :

  • L'utilisation de RAISE_APPLICATION_ERROR avec des codes d'erreur variables au lieu de codes -20nnn littéraux.
  • L'utilisation de SQLERRM avec un argument de code d'erreur, car cette syntaxe n'est pas compatible avec PostgreSQL.
Atténuation possible

Vous devez résoudre manuellement ces problèmes dans le code converti. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Problèmes liés aux types de données et aux conversions

Cause possible

Database Migration Service peut regrouper les problèmes de conversion en fonction du contexte (par exemple, les problèmes de conversion qui se produisent dans les expressions de comparaison de types). Le groupe CW_OP0500 capture tous les problèmes de conversion de types de données génériques qui ne relèvent pas d'autres groupes de problèmes.

Atténuation possible

Dans la plupart des cas, Database Migration Service émet un message ERROR_UNIMPLEMENTED ou ERROR_TYPE dans le code PostgreSQL converti. Résolvez cette erreur en fonction de vos connaissances sur les types de données concernés.

Problèmes de modèle de format de date

Cause possible

Vous pouvez rencontrer des avertissements ou des problèmes lors de la conversion d'expressions de date ou de code temporel vers ou depuis des chaînes basées sur un modèle de format. Database Migration Service utilise un modèle par défaut (actuellement DD-MON-RR) lorsque les casts du code source Oracle excluent un modèle de format de date ou d'horodatage explicite.

Cela peut parfois entraîner des problèmes dans le code converti si le modèle de format émis pour le cast implicite entre en conflit avec un modèle de format explicite dans la même expression. Vous pouvez également rencontrer ce problème si vos données sont susceptibles d'être affectées par les différences entre le format Oracle RR et le format PostgreSQL YY.

Atténuation possible

Examinez et validez les expressions PostgreSQL converties dans l'espace de travail de conversion.

Problèmes de modèle de format numérique

Cause possible

Database Migration Service n'est pas compatible avec tous les modèles de format Oracle. Par exemple, 'L' ou 'X' ne sont pas acceptés. Vous pouvez rencontrer des problèmes ou des avertissements avec le code qui convertit des chaînes en nombres en fonction des modèles de format Oracle.

Atténuation possible

Pour les modèles de format Oracle qui n'ont pas d'équivalent dans PostgreSQL, vous devrez peut-être refactoriser vos expressions ou vos modèles de format. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Problèmes de conversion de types de données

Cause possible

Vous pouvez rencontrer des erreurs en raison d'un transtypage de données non compatible ou inexact. Database Migration Service émet généralement ERROR_UNIMPLEMENTED. Cela est généralement dû à des métadonnées manquantes ou incomplètes. Database Migration Service ne dispose peut-être pas de suffisamment d'informations pour caster un type, par exemple dans les arguments de fonction ou les paramètres de procédure.

Atténuation possible

Ajustez le code PostgreSQL pour garantir des conversions de types de données correctes. Pour effectuer ces corrections, vous devez connaître vos attributs, variables et colonnes référencés.

Problèmes de comparaison

Cause possible

Database Migration Service ne dispose peut-être pas de suffisamment de métadonnées ou d'informations sur les types de données lors de la conversion des expressions de comparaison de données. Par exemple, cela peut se produire lorsqu'un type défini par l'utilisateur (UDT) est comparé à NULL.

Atténuation possible

Examinez les expressions PostgreSQL converties et résolvez les problèmes. Nous vous recommandons d'explorer les fonctionnalités de conversion automatique optimisées par Gemini pour accélérer ces corrections. Pour en savoir plus, consultez Convertir le code et les schémas Oracle avec l'aide de Gemini.

Les problèmes de cette catégorie représentent les cas où le code source Oracle est correctement converti en l'équivalent PostgreSQL le plus proche, mais le code obtenu peut présenter des différences sémantiques ou fonctionnelles mineures qui nécessitent votre examen. Cela est dû aux différences de gestion des types de données, des formats ou des objets entre Oracle et PostgreSQL.

À première vue, cette catégorie peut sembler se chevaucher avec les problèmes de la catégorie Types de données et conversion (CW_05), mais notez qu'ils représentent des problèmes différents. CW_05 contient des problèmes connus pour lesquels Database Migration Service ne peut pas convertir le code Oracle en son équivalent PostgreSQL.

Examiner le modèle de format de date

Cause possible

La plupart des modèles de format de date et d'horodatage Oracle ont des équivalents appropriés dans PostgreSQL. Le code converti ne présente donc aucune différence sémantique ou fonctionnelle. Certains modèles n'ont pas de correspondance exacte, et leur comportement varie. Par exemple, le format Oracle RR est converti au format PostgreSQL YY.

Atténuation possible

Examinez et validez les expressions avec des conversions de modèle de format pour vous assurer que le code converti se comporte comme prévu.

Examiner le modèle de format numérique

Cause possible

La plupart des modèles de format numérique source ont un équivalent dans PostgreSQL. Par conséquent, le code converti ne présente aucune différence sémantique ou fonctionnelle. Toutefois, il est possible que certains modèles de format n'aient pas de correspondance exacte ou se comportent légèrement différemment.

Atténuation possible

Examinez et validez les expressions avec des conversions de modèle de format pour vous assurer que le code converti fonctionne comme prévu.

Examiner le code d'exception

Cause possible

Lorsque vous utilisez RAISE_APPLICATION_ERROR avec un code d'erreur compris entre -20000 et -20999, Database Migration Service le convertit en RAISE EXCEPTION PostgreSQL avec un SQLSTATE compris entre CW0000 et CW999. La conversion conserve les trois derniers chiffres du code d'erreur source et les préfixe par CW.

Atténuation possible

Examinez ce comportement pour déterminer s'il répond à vos besoins. Cet examen n'est nécessaire que si les codes d'erreur sources sont pertinents pour votre application, vos équipes d'assistance ou votre documentation. Si la valeur du code d'erreur n'est pas significative, vous pouvez ignorer cet avertissement.

Examinez le message d'exception

Cause possible

La fonction SQLERRM existe à la fois dans Oracle PL/SQL et dans PostgreSQL, mais elle peut renvoyer un texte d'erreur différent dans chaque moteur. Par exemple, la division par zéro dans Oracle renvoie le texte d'erreur ORA-01476: divisor is equal to zero, mais ERROR: division by zero dans PostgreSQL.

Atténuation possible

Si votre application, votre infrastructure d'assistance ou votre documentation dépendent du texte d'erreur, examinez la conversion. Sinon, vous pouvez ignorer cette différence.

Examiner l'émulation de la fonction intégrée Oracle

Cause possible

La conversion de code et de schéma de Database Migration Service vise à fournir un comportement de fonction Oracle avec des équivalents PostgreSQL, mais les résultats peuvent ne pas toujours être satisfaisants pour votre scénario. Par conséquent, les espaces de travail de conversion fournissent toujours un avertissement avec les conversions de fonctions qui peuvent nécessiter votre examen.

Atténuation possible

Nous vous recommandons d'examiner les objets pour lesquels les espaces de travail de conversion émettent des avertissements dans le groupe de problèmes CW_OP0605.

Examiner le type de données de la colonne de clé étrangère

Cause possible

Database Migration Service a identifié des spécifications de types de données incompatibles entre les objets parents et enfants (par exemple, lorsqu'une colonne parente est de type NUMBER(4) et que la colonne enfant est de type NUMBER(10)).

Atténuation possible

La plupart du temps, de légères incohérences de types de données ne causent pas de problèmes dans les fonctionnalités de la base de données. Toutefois, nous vous recommandons d'examiner le modèle de données converti pour détecter d'éventuelles incohérences.

Examen fonctionnel recommandé
Cause possible

Ce groupe capture tous les problèmes génériques liés aux différences fonctionnelles potentielles dans le code Oracle et PostgreSQL. Les problèmes de ce groupe ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible

Examiner l'émulation de la fonction intégrée Oracle

Cause possible

De nombreuses fonctions intégrées d'Oracle n'ont pas d'équivalent direct dans PostgreSQL. Pour atténuer ce problème lors des migrations, Database Migration Service convertit votre code en utilisant différentes expressions SQL afin de produire un comportement fonctionnel équivalent dans PostgreSQL.

Dans certains cas, les expressions converties peuvent être complexes. Database Migration Service émet des avertissements dans le groupe CW_OP0702 pour mettre en évidence les problèmes potentiels et indiquer qu'une fonction a été émulée avec une expression.

Atténuation possible

Examinez le code converti pour vous assurer que les fonctions converties se comportent comme prévu dans votre environnement PostgreSQL.

Refactorisation des transactions autonomes requise

Cause possible

PostgreSQL n'est pas compatible avec les transactions autonomes.

Atténuation possible

Vous pouvez réaliser des transactions autonomes dans PostgreSQL à l'aide de l'extension dblink, pg_background ou PL/Proxy. Les appels de base de données effectués avec l'une de ces extensions s'exécutent dans une session différente et génèrent donc une transaction autonome.

Refactorisation des liens de base de données requise

Cause possible

Database Migration Service n'est pas compatible avec les liens de base de données Oracle. Les objets qui utilisent des liens doivent être refactorisés.

Atténuation possible

Selon la cible de votre lien de base de données, vous pouvez implémenter une fonctionnalité équivalente dans PostgreSQL avec des extensions de base de données, telles que dblink, postgres_fdw, oracle_fdw ou PL/Proxy.

Refactorisation avancée de la mise en file d'attente requise

Cause possible

Les packages Oracle Advanced Queuing (DBMS_AQ, DBMS_AQADM) n'ont pas d'équivalents PostgreSQL et nécessitent un refactoring.

Atténuation possible

Vous avez le choix entre les options suivantes :

  • Refactorisez la fonctionnalité de mise en file d'attente en la déplaçant de la base de données vers le niveau de l'application.
  • Utilisez des tables, des alertes et des déclencheurs PostgreSQL pour implémenter un comportement équivalent.
  • Contactez votre représentant de l'équipe Technical Solutions pour obtenir de l'aide.

Refactorisation de l'adresse e-mail de la base de données requise

Cause possible

AlloyDB pour PostgreSQL ne permet pas d'envoyer des e-mails directement depuis la base de données. Les extensions qui activent cette fonctionnalité ne sont pas non plus compatibles. Par conséquent, Database Migration Service ne convertit pas les utilisations du package UTL_SMTP.

Atténuation possible

Refactorisez le code de messagerie de votre base de données et transférez la responsabilité de l'envoi d'e-mails au niveau de l'application. Vous pouvez toujours utiliser la base de données pour capturer les conditions dans lesquelles l'envoi d'un e-mail est requis.

Par exemple, vous pouvez écrire les détails de l'e-mail dans une table dédiée. Cette table peut également servir de file d'attente d'e-mails que vous interrogez avec une fonction Cloud Run Functions et qui gère le traitement SMTP réel.

Refactorisation des jobs et de la planification requise

Cause possible

Les packages Oracle DBMS_JOB et DBMS_SCHEDULER ne sont pas convertis par Database Migration Service. Vous devez refactoriser le code qui fait référence à ces packages.

Atténuation possible

Pour les jobs simples sans dépendances, vous pouvez créer manuellement des jobs planifiés dans la base de données PostgreSQL cible à l'aide de l' extension pg_cron.

Pour les planifications plus complexes que pg_cron ne prend pas en charge, vous devrez peut-être utiliser un planificateur au niveau de l'application ou un planificateur tiers.

Refactorisation des E/S de fichiers requise

Cause possible

Database Migration Service n'est pas compatible avec le package Oracle UTL_FILE. Vous devez refactoriser le code qui fait référence à ces packages.

L'extension Orafce inclut l'émulation UTL_FILE, mais peut ne pas fonctionner dans un environnement PostgreSQL géré par Google en raison de capacités d'E/S de fichiers limitées.

Atténuation possible
  • Refactorisez votre code pour supprimer les dépendances à UTL_FILE.

  • AlloyDB pour PostgreSQL présente certaines restrictions concernant les fonctionnalités d'E/S de fichiers. Il n'est donc pas possible d'implémenter ce comportement directement dans la base de données de destination.

    Une autre solution possible consiste à installer PostgreSQL avec l' extension orafce sur une VM Compute Engine de votre VPC. Vous pouvez ensuite utiliser l' extension PL/Proxy dans votre base de données de destination pour appeler la version UTL_FILE compatible avec PostgreSQL qui s'exécute dans la base de données sur la VM Compute Engine.

Synonymes

Cause possible

PostgreSQL n'est pas compatible avec les synonymes. Pour les objets de code, Database Migration Service remplace automatiquement les références de synonymes par leur schéma source et leur nom d'objet. Si vous utilisez des synonymes en dehors des objets de code, par exemple dans des schémas en lecture seule pour les utilisateurs d'applications de base de données, vous devez les convertir manuellement.

Atténuation possible

Pour utiliser des synonymes en dehors des objets de code, vous pouvez utiliser le paramètre SEARCH_PATH de PostgreSQL ou refactoriser votre code pour utiliser des vues pour les objets de requête.

Refactorisation des tables temporaires globales requise

Cause possible

Ce groupe de problèmes est un avertissement indiquant que Database Migration Service a détecté une table temporaire globale dans votre code source Oracle. Pour migrer des tables temporaires globales, vous devez installer et créer l'extension PostgreSQL pgtt sur la base de données de destination.

Atténuation possible

Nous vous recommandons de vérifier que l'extension PostgreSQL pgtt est installée et créée sur la base de données de destination.

Examiner les suggestions de Gemini
Cause possible :

Ce groupe de problèmes capture toutes les erreurs et tous les avertissements génériques liés à la conversion de code optimisée par Gemini.

Correction possible : Les problèmes détectés ici n'indiquent pas toujours de vrais problèmes, mais nous vous recommandons vivement d'examiner toutes les conversions améliorées par Gemini pour vous assurer qu'elles correspondent à vos attentes.

Examiner le code augmenté par l'IA
Cause principale potentielle : Ce code LDD a été converti avec des fonctionnalités optimisées par Gemini et peut nécessiter votre examen pour en vérifier l'exactitude.

Atténuation possible : Nous vous recommandons d'examiner attentivement le code converti avec les augmentations par l'IA pour vous assurer que le résultat final correspond aux fonctionnalités de votre schéma source.

Citations
Cause potentielle : les suggestions améliorées par Gemini peuvent inclure du contenu cité provenant de plusieurs sources. Certaines citations peuvent être soumises à des restrictions de licence. Nous vous recommandons d'examiner le code converti pour vérifier les citations.

Problèmes de conversion des métadonnées
Cause possible :

Ce groupe capture tous les problèmes de conversion qui ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible

Nous vous recommandons d'examiner le code converti en fonction de votre connaissance du modèle de données source et de l'ajuster si nécessaire.

Problèmes de conversion des métadonnées
Cause possible :

Ce groupe capture tous les problèmes de suivi des métadonnées qui ne relèvent d'aucun autre groupe de problèmes plus spécifique.

Atténuation possible :

Les exemples de problèmes de ce groupe sont généralement liés à des erreurs de compilation ou à des avertissements pouvant entraîner des problèmes de types de données dans le code PostgreSQL converti. Nous vous recommandons d'examiner le code converti en fonction de votre connaissance du modèle de données source et d'ajuster les références défectueuses.

Contactez votre équipe d'assistance

Cause possible

Dans certains cas particuliers, vous pouvez rencontrer une erreur interne avec un objet source Oracle valide. Si c'est le cas, contactez votre équipe d'assistance pour obtenir de l'aide.

Problèmes de conversion génériques
Cause possible

Ce groupe contient tous les problèmes qui ne relèvent d'aucune autre catégorie ou groupe de problèmes plus spécifiques.

Atténuation possible

Nous vous recommandons d'examiner le code converti en fonction de votre connaissance du modèle de données et du code sources, et de l'ajuster si nécessaire.