Espaces de travail de conversion

Les espaces de travail de conversion vous aident à convertir le schéma et les objets de votre base de données source dans la syntaxe SQL compatible avec votre base de données de destination. Cette page présente les espaces de travail de conversion Database Migration Service :

Certains types de données ne sont pas compatibles avec les migrations Oracle. Pour en savoir plus, consultez Limites connues pour les types de données.

Présentation de la progression des conversions

Des informations générales détaillées sur les espaces de travail de conversion, qui vous permettent d'obtenir des insights sur le nombre total de problèmes de conversion en suspens ou résolus, les augmentations assistées par Gemini et l'état général de votre processus de conversion.

Écran de l'espace de travail de conversion avec l'onglet "Vue d'ensemble de la conversion" où vous pouvez voir le nombre d'objets convertis, les problèmes de conversion et les améliorations de la conversion assistée par Gemini.
Figure 1. Écran de présentation de l'espace de travail de conversion, où vous pouvez suivre la progression de votre conversion, afficher les problèmes et inspecter le code PostgreSQL obtenu. (cliquez pour agrandir)
Écran de l'espace de travail de conversion avec l'onglet "Vue d'ensemble de la conversion" où vous pouvez voir le nombre d'objets convertis, les problèmes de conversion et les améliorations de la conversion assistée par Gemini.

Vous pouvez utiliser cette vue pour filtrer les objets de votre schéma par type, niveau de gravité du problème, actions requises ou état de la conversion.

Écran de l'espace de travail de conversion montrant comment filtrer les objets convertis par type ou état.
Figure 2. Filtrage des objets convertis par état et type d'objet. (cliquez pour agrandir)
Écran de l'espace de travail de conversion montrant comment filtrer les objets convertis par type ou état.

Pour en savoir plus sur l'utilisation des aperçus des conversions pour examiner les résultats des conversions, consultez Utiliser les espaces de travail de conversion.

Conversion de code et de schéma déterministes

Lorsque vous créez un espace de travail de conversion, Database Migration Service effectue immédiatement la conversion initiale du schéma à l'aide d'un ensemble de règles de conversion déterministes, où des types de données et des objets Oracle spécifiques sont mappés à des types de données et des objets PostgreSQL spécifiques. Ce processus est compatible avec un sous-ensemble très spécifique des objets de base de données Oracle disponibles.

La conversion déterministe du code est compatible avec les objets de base de données Oracle suivants :

Éléments de schéma Oracle acceptés

  • Contraintes
  • Index (uniquement les index créés dans le même schéma que leur table)
  • Vues matérialisées
  • Types d'objets (prise en charge partielle)
  • Séquences
  • Synonymes
  • Tables
  • Vues

Éléments de code Oracle compatibles

  • Déclencheurs (au niveau de la table uniquement)
  • Packages
  • Fonctions
  • Procédures stockées

Éditeur SQL interactif

L'éditeur SQL interactif vous permet de modifier la syntaxe PostgreSQL convertie directement dans Database Migration Service. Vous pouvez l'utiliser pour résoudre les problèmes de conversion ou ajuster le schéma afin de mieux répondre à vos besoins. Certains objets ne peuvent pas être modifiés dans l'éditeur intégré.

Objets Oracle modifiables

Une fois que vous avez converti le code et le schéma de la base de données source, vous pouvez utiliser l'éditeur interactif pour modifier le code SQL généré pour certains types d'objets. L'éditeur est compatible avec les objets Oracle suivants :

  • Déclencheurs de table (autorisation requise)
  • Vues matérialisées
  • Packages
  • Fonctions, procédures stockées
  • Synonymes
  • Vues
  • Contraintes
  • Index
  • Séquences

De plus, certains objets sont convertis, mais ne peuvent pas être modifiés directement dans Database Migration Service. Pour modifier ces objets, vous devez effectuer les mises à jour directement dans la base de données de destination après avoir appliqué le schéma et le code convertis.

Objets qui ne peuvent pas être modifiés :

  • Types d'objets définis par l'utilisateur
  • Tables
  • Schémas

Accélérer la conversion de code et de schémas avec Gemini

Database Migration Service intègre Gemini pour Google Cloud dans les espaces de travail de conversion afin de vous aider à accélérer et à améliorer le processus de conversion dans les domaines suivants :

  • Améliorez les résultats de la conversion déterministe grâce à la conversion automatique optimisée par Gemini. Utilisez la puissance de l'IA pour réduire considérablement le nombre d'ajustements manuels nécessaires dans votre code PostgreSQL.

  • Fournissez des fonctionnalités d'explication du code avec l'assistant de conversion : un ensemble de requêtes dédiées qui peuvent vous aider à mieux comprendre la logique de conversion, à proposer des corrections pour les problèmes de conversion ou à optimiser le code converti.

  • Accélérez l'application de correctifs pour les problèmes de conversion grâce aux suggestions de conversion de code de Gemini : un mécanisme permettant au modèle Gemini d'apprendre à mesure que vous corrigez les problèmes de conversion et de suggérer des modifications pour d'autres objets défectueux dans l'espace de travail.

Pour en savoir plus sur la conversion optimisée par Gemini, consultez les pages suivantes :

Fichiers de mise en correspondance des conversions

Vous pouvez personnaliser la logique de conversion à l'aide d'un fichier de mappage des conversions. Le fichier de mappage de conversion est un fichier texte contenant des instructions précises (appelées directives de conversion) sur la façon dont vos objets Oracle doivent être convertis en objets PostgreSQL.

Directives de conversion acceptées

Database Migration Service est compatible avec les directives de conversion suivantes pour les fichiers de mappage de conversion :

EXPORT_SCHEMA

EXPORT_SCHEMA est une directive obligatoire pour tous les fichiers de mise en correspondance des conversions. Database Migration Service a besoin de cette instruction pour s'assurer que vos schémas sources sont convertis en schémas de destination appropriés. Assurez-vous que vos fichiers de mappage des conversions incluent la ligne suivante : 

EXPORT_SCHEMA 1

SCHEMA

Database Migration Service doit pouvoir déterminer le schéma contenant les objets à modifier avec vos directives de conversion. La directive SCHEMA permet d'appliquer toutes les autres directives de personnalisation fournies dans votre fichier aux objets de ce schéma spécifique.

  • Lorsque vous utilisez cette directive, les autres schémas contenus dans votre base de données sont également convertis, mais leurs objets ne sont soumis à aucune modification.
  • Si vous incluez cette directive dans le fichier de mappage des conversions, toutes les personnalisations ne s'appliquent qu'aux objets contenus dans ce schéma spécifique.
  • Si vous ignorez cette directive, vous devez fournir des noms d'objets complets incluant le nom du schéma pour les objets modifiés par d'autres directives de conversion. Par exemple, au lieu d'utiliser SOURCE_TABLE_NAME pour la directive REPLACE_TABLES, vous devez utiliser "SCHEMA_NAME.SOURCE_TABLE_NAME".
  • Pour personnaliser des objets dans différents schémas, procédez comme suit :
    • Créez des fichiers de mappage de conversion distincts pour les autres schémas, puis importez-les dans l'espace de travail de conversion.
    • Utilisez des noms d'objet complets incluant le nom du schéma pour les objets qui résident dans des schémas différents de celui que vous fournissez à la directive SCHEMA.

Utilisez le format suivant :

SCHEMA SCHEMA_NAME

Où SCHEMA_NAME correspond au nom de votre schéma dans la base de données source.

CASE_HANDLING

Par défaut, Database Migration Service convertit tous les noms d'objets en minuscules. Vous pouvez utiliser la directive CASE_HANDLING pour modifier ce comportement.

  • Cette instruction n'est pas affectée par l'instruction SCHEMA. Il fonctionne dans le monde entier et affecte tous les objets de l'espace de travail de conversion.
  • Les directives RENAME_*, MOVE_* et REPLACE_* prévalent sur la directive CASE_HANDLING et renomment vos objets exactement, quelle que soit la propriété CASE_HANDLING.
  • Si cette directive existe dans plusieurs fichiers de configuration avec des valeurs conflictuelles, Database Migration Service génère une erreur lors de l'importation du schéma.

Utilisez le format suivant :

CASE_HANDLING OPTION

où OPTION peut avoir l'une des valeurs suivantes :

  • UPPERCASE : convertit tous les noms d'objets en majuscules.
  • LOWERCASE : convertit tous les noms d'objets en minuscules (comportement par défaut).
  • PRESERVE_ORIGINAL : conserve la casse d'origine du schéma source. Cela peut être utile si vos applications utilisent des identifiants sensibles à la casse.

Exemple :

CASE_HANDLING PRESERVE_ORIGINAL

Renommer des objets (RENAME_*)

Vous pouvez renommer différents objets de base de données lors de la conversion. Database Migration Service met automatiquement à jour toutes les références de code (dans les vues, les procédures stockées, les fonctions, etc.) pour utiliser les nouveaux noms.

Syntaxe générale

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

Remarques importantes

  • Les directives RENAME_* sont sensibles à la casse pour le nom de l'objet de destination et prévalent sur la directive CASE_HANDLING. Par exemple, si vous utilisez les deux directives : 

    SCHEMA MySchema
CASE_HANDLING PRESERVE_ORIGINAL
# Destination objects are renamed exactly
# to 'SoMe_tAbLe' and 'RenamedView', respecting the case
# despite the CASE_HANDLING directive
RENAME_TABLES some_table:SoMe_tAbLe
RENAME_VIEWS MyView:RenamedView

  • Pour SOURCE_NAME, reportez-vous toujours au nom d'objet d'origine, même si vous utilisez d'autres directives telles que MOVE_*. Par exemple, si vous souhaitez renommer l'un de vos objets de vue et le déplacer vers un nouveau schéma, reportez-vous au nom de vue d'origine pour les deux directives : 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • L'instruction RENAME_TABLES remplace l'instruction REPLACE_TABLES dans un seul fichier. Si vous souhaitez à la fois renommer et déplacer une table, nous vous recommandons d'utiliser plutôt la directive MOVE_*.

  • Le format complet de la variable SOURCE_NAME dépend de l'utilisation ou non de la directive SCHEMA :

    • Avec la directive SCHEMA : utilisez des noms non qualifiés, par exemple MyTable.
    • Sans directive SCHEMA : utilisez des noms complets, par exemple MySchema.MyTable.

Directives RENAME_* acceptées

  • RENAME_SCHEMA : renomme un schéma.
    Un fichier de configuration ne peut contenir qu'une seule directive RENAME_SCHEMA. Si l'instruction SCHEMA est fournie, RENAME_SCHEMA ne peut renommer que ce schéma spécifique.
  • RENAME_TABLES : renomme les tables. Remplace le REPLACE_TABLES dans le même fichier.
  • RENAME_COLUMNS : renomme les colonnes des tables. Remplace l'instruction REPLACE_COLS dans le même fichier. Utilisez le format suivant : 
    RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL

    Si vous utilisez la directive SCHEMA, utilisez des noms de table non qualifiés. Si vous n'utilisez pas la directive SCHEMA, incluez les noms de tables complets, tels que SCHEMA.TABLE1.

  • RENAME_VIEWS
  • RENAME_MATERIALIZED_VIEWS
  • RENAME_SEQUENCES
  • RENAME_FUNCTIONS
  • RENAME_STORED_PROCEDURES
  • RENAME_TRIGGERS

  • RENAME_PACKAGES : Database Migration Service convertit les packages Oracle en schémas PostgreSQL. Si votre schéma contient des packages qui partagent des noms, le code PostgreSQL peut rencontrer des conflits de noms lorsqu'il tente de créer deux schémas portant le même nom. Vous pouvez utiliser cette directive pour éviter de tels conflits.

    Par exemple, si vous avez des packages tels que SALES.REPORTING_PKG et HR.REPORTING_PKG, vous pouvez les renommer avec des noms distincts : 

    RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS

  • RENAME_USER_DEFINED_TYPES

    Alias disponible : RENAME_UDTS.

Déplacer des objets (MOVE_*)

Vous pouvez déplacer des objets vers différents schémas dans la base de données de destination. Cela est utile pour réorganiser la structure de votre base de données lors de la migration. Database Migration Service met automatiquement à jour toutes les références de code dans les vues, les procédures stockées, les fonctions, etc.

Syntaxe générale

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

Remarques importantes

  • Pour SOURCE_NAME, reportez-vous toujours au nom d'objet d'origine, même si vous utilisez d'autres directives telles que RENAME_*. Par exemple, si vous souhaitez renommer l'un de vos objets de vue et le déplacer vers un nouveau schéma, reportez-vous au nom de vue d'origine pour les deux directives : 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • La directive n'attend que le nom DESTINATION_SCHEMA, et non le nom complet de l'objet.

  • Le format complet de la variable SOURCE_NAME dépend de l'utilisation ou non de la directive SCHEMA :

    • Avec la directive SCHEMA : utilisez des noms non qualifiés, par exemple MyTable.
    • Sans directive SCHEMA : utilisez des noms complets, par exemple MySchema.MyTable.

Directives MOVE_* acceptées

  • MOVE_TABLES : déplace les tables vers un autre schéma. A la priorité sur REPLACE_TABLES pour les modifications de schéma dans un seul fichier de configuration.
  • MOVE_VIEWS
  • MOVE_MATERIALIZED_VIEWS
  • MOVE_SEQUENCES
  • MOVE_FUNCTIONS
  • MOVE_STORED_PROCEDURES

  • MOVE_USER_DEFINED_TYPES

    Alias disponible : MOVE_UDTS.

Exemple : Réorganiser les schémas

SCHEMA LegacyApp

# Moves the 'LegacyApp.Users' and 'LegacyApp.Orders' tables
# to the 'data' schema.
MOVE_TABLES Users:data Orders:data

# Moves the 'LegacyApp.CreateUser' and 'LegacyApp.ProcessOrder'
# stored procedures to the 'api' schema
MOVE_STORED_PROCEDURES CreateUser:api ProcessOrder:api

# Moves the 'LegacyApp.SalesSummary' views to the 'reporting' schema
MOVE_VIEWS SalesSummary:reporting

DATA_TYPE

Vous pouvez utiliser cette directive pour mapper explicitement n'importe quel type de données compatible entre la syntaxe Oracle et PostgreSQL. Cette directive attend une liste de mappages séparés par des virgules. La définition complète doit être fournie sur une seule ligne, mais vous pouvez inclure plusieurs directives DATA_TYPE dans votre fichier de configuration. Utilisez le format suivant : 

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

Où ORACLE_DATA_TYPE et PGSQL_DATA_TYPE sont des types de données compatibles avec les versions Oracle et PostgreSQL respectives que vous utilisez dans votre migration. Pour en savoir plus sur les versions compatibles, consultez Présentation du scénario.

Exemple :

DATA_TYPE REAL:double precision,SMALLINT:integer

Pour en savoir plus sur les types de données Oracle et PostgreSQL, consultez les ressources suivantes :

MODIFY_TYPE

La directive MODIFY_TYPE vous permet de contrôler le type de données dans lequel Database Migration Service convertit une colonne spécifique de votre table source. Cette directive attend une liste de mappages séparés par des virgules. La définition complète doit être fournie sur une seule ligne, mais vous pouvez inclure plusieurs directives MODIFY_TYPE dans votre fichier de configuration. Utilisez le format suivant : 

MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE
MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...

Où :

  • SOURCE_TABLE_NAME est le nom de la table contenant la colonne dont vous souhaitez modifier le type de données.
  • COLUMN_NAME correspond au nom de la colonne pour laquelle vous souhaitez personnaliser le mappage des conversions.
  • EXPECTED_END_RESULT_DATA_TYPE correspond au type de données PostgreSQL que vous souhaitez utiliser pour la colonne convertie.

Exemple :

MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT

PG_INTEGER_TYPE

Par défaut,Database Migration Service convertit les types NUMBER(p,s) en type DECIMAL(p,s) PostgreSQL.

Vous pouvez modifier ce comportement avec la directive PG_INTEGER_TYPE. Définissez sa valeur sur 1 et forcez la conversion de tous vos types NUMBER avec précision et échelle (NUMBER(p,s)) en types PostgreSQL smallint, integer ou bigint en fonction du nombre de chiffres de précision.

Incluez le paramètre suivant dans votre fichier de mappage des conversions : 

PG_INTEGER_TYPE 1

PG_NUMERIC_TYPE

Définissez cette directive sur 1 si vous souhaitez convertir tous vos types NUMBER avec précision et échelle (NUMBER(p,s)) en types PostgreSQL real ou float (en fonction de leur nombre de chiffres de précision).

Si vous définissez cette directive sur 0, vos valeurs NUMBER(p,s) conservent leur valeur d'origine exacte et utilisent le type de données PostgreSQL interne.

Incluez le paramètre suivant dans votre fichier de mappage des conversions : 

PG_NUMERIC_TYPE 1

DEFAULT_NUMERIC

La conversion par défaut pour les NUMBER sans précision change selon que vous utilisez également la directive PG_INTEGER_TYPE :

  • Si vous utilisez la directive PG_INTEGER, les NUMBERs sans précision sont convertis en valeurs DECIMAL.
  • Si vous n'utilisez pas la directive PG_INTEGER, les NUMBER sans précision sont convertis en valeurs BIGINT.

Vous pouvez modifier ce comportement et utiliser la directive DEFAULT_NUMERIC pour spécifier le type de données à utiliser pour les types NUMBER sans points de précision spécifiés. Utilisez le format suivant : 

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

Où POSTGRESQL_NUMERIC_DATA_TYPE est l'une des valeurs suivantes : integer, smallint ou bigint.

Exemple :

DEFAULT_NUMERIC integer

REPLACE_COLS

Vous pouvez utiliser la directive REPLACE_COLS pour renommer les colonnes de votre schéma converti. Cette directive attend une liste de mappages séparés par des virgules.

Utilisez le format suivant : 

REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...

Où :

  • SOURCE_TABLE_NAME correspond au nom de la table contenant la colonne dont vous souhaitez modifier le nom. Si vous n'utilisez pas la directive SCHEMA, assurez-vous d'utiliser le nom de table complet : SCHEMA_NAME.SOURCE_TABLE_NAME.
  • SOURCE_COLUMN_NAME correspond au nom de la colonne de votre source que vous souhaitez modifier.
  • DESTINATION_COLUMN_NAME est le nouveau nom que vous souhaitez attribuer à la colonne à utiliser dans le schéma converti.

Exemple :

REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)

REPLACE_TABLES

Vous pouvez utiliser la directive REPLACE_TABLES pour renommer des tables ou les déplacer vers un nouveau schéma. Cette directive attend une liste de mappages séparés par des espaces. Pour en savoir plus sur la syntaxe de chaque cas d'utilisation, développez les sections suivantes.

Si vous n'utilisez pas la directive SCHEMA, assurez-vous d'utiliser les noms de tables complets entre guillemets pour les variables source et de destination :

  • "SCHEMA_NAME.SOURCE_TABLE_NAME"
  • "SCHEMA_NAME.DESTINATION_TABLE_NAME"

Renommer des tables

Pour renommer les tables dans votre schéma converti, utilisez le format suivant :

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

Où :

  • SOURCE_TABLE_NAME correspond au nom de la table source que vous souhaitez renommer dans le schéma converti.
  • DESTINATION_TABLE_NAME est le nouveau nom de la table que vous souhaitez utiliser dans le schéma converti.

Exemple :

REPLACE_TABLES "events:login_events" "users:platform_users"

Déplacer des tables entre des schémas

Vous pouvez utiliser cette directive pour déplacer des tables entre des schémas en ajoutant le préfixe du schéma au nouveau nom de table. Ce mécanisme peut être utilisé quelle que soit la façon dont vous utilisez la directive SCHEMA pour l'ensemble du fichier de conversion. Exemple : 

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

Alias pour personnaliser les types de données

Lorsque vous utilisez des directives de conversion pour modifier la façon dont Database Migration Service convertit différents types de données (par exemple, avec les directives DATA_TYPE, MODIFY_TYPE ou PG_NUMERIC_TYPE), vous pouvez utiliser des alias au lieu de vos types de données SQL sources.

Développez la section suivante pour afficher la liste des alias de types de données compatibles avec Database Migration Service.

Alias de type de données

Alias Type PostgreSQL converti
bigint, int8 BIGINT
bool, boolean BOOLEAN
bytea BYTEA
char, character CHAR
character varying, varchar VARCHAR
date DATE
decimal, numeric DECIMAL
double precision, float8 DOUBLE PRECISION
real float4 REAL
int, integer, int4 INTEGER
int2 SMALLINT
interval INTERVAL
json JSON
smallint SMALLINT
text TEXT
time TIME
timestamp TIMESTAMP
timestamptz TIMESTAMPTZ
timetz TIMETZ
uuid UUID
XML XML

Exemple de fichier de mappage des conversions

Consultez l'exemple de fichier de mappage de conversion suivant qui utilise certaines des directives de conversion de schéma acceptées :

EXPORT_SCHEMA 1
SCHEMA root

# Preserve original casing for all objects
CASE_HANDLING PRESERVE_ORIGINAL

# Data type conversions
PG_NUMERIC_TYPE 0
PG_INTEGER_TYPE 1
DEFAULT_NUMERIC integer
DATA_TYPE NUMBER(4\,0):integer
MODIFY_TYPE events:dates_and_times:TIMESTAMP

# Renaming objects using the RENAME_* directives
# These allow case-sensitive destination names
RENAME_TABLES events:LoginEvents users:PlatformUsers
RENAME_COLUMNS events.dates_and_times:EventDates users.pseudonym:Nickname
RENAME_VIEWS InternalReport:FinInternalReport

# Moving objects to new schemas using the MOVE_* directives
MOVE_TABLES audit_log:archive
MOVE_VIEWS InternalReport:reporting

Voici les résultats de l'utilisation de ce fichier :

  • EXPORT_SCHEMA 1 est une directive obligatoire.
  • SCHEMA root entraîne l'application des autres directives aux objets du schéma root, sauf si des noms complets sont utilisés.
  • CASE_HANDLING PRESERVE_ORIGINAL garantit que tous les noms d'objets du schéma root source conservent leur casse d'origine dans la destination (sauf s'ils sont remplacés par une directive RENAME_*).
  • PG_INTEGER_TYPE 1 permet à Database Migration Service de convertir tous les types de données numériques Oracle trouvés dans les tables du schéma root en types spécifiques à PostgreSQL au lieu de types numériques portables ANSI.
  • DEFAULT_NUMERIC integer permet à Database Migration Service de convertir les valeurs NUMBER qui n'ont pas de point de précision spécifié en type INTEGER PostgreSQL.
  • DATA_TYPE NUMBER(4\,0):integer entraîne la conversion par Database Migration Service de valeurs NUMBER(4,0) spécifiques en INTEGER PostgreSQL.
  • La directive MODIFY_TYPE events:dates_and_times:TIMESTAMP permet à Database Migration Service de convertir les données de la colonne dates_and_times de la table source events spécifiquement au type PostgreSQL TIMESTAMP.
  • RENAME_TABLES events:LoginEvents users:PlatformUsers renomme les tables en conservant la casse spécifiée :
    • La table events est renommée LoginEvents.
    • La table users est renommée PlatformUsers.
  • RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname renomme les colonnes en conservant la casse spécifiée dans la destination :
    • Dans la table LoginEvents (nom d'origine events), la colonne dates_and_times est renommée EventDates.
    • Dans la colonne PlatformUsers (nom d'origine users), la colonne pseudonym est renommée Nickname.
  • RENAME_VIEWS InternalReport:FinInternalReport renomme la vue InternalReport en FinInternalReport.
  • MOVE_TABLES audit_log:archive déplace la table audit_log du schéma root vers le schéma archive.
  • MOVE_VIEWS InternalReport:reporting déplace la vue InternalReport vers le schéma reporting. Cette vue est également renommée FinInternalReport en raison de l'instruction RENAME_VIEWS. Database Migration Service gère la dépendance : l'objet est d'abord renommé, puis déplacé.

Anciens espaces de travail de conversion

Les anciens espaces de travail de conversion sont un type d'espaces de travail de conversion plus ancien et plus limité. Les anciens espaces de travail de conversion ne sont pas compatibles avec les fonctionnalités de conversion optimisées par Gemini ni avec l'éditeur SQL interactif. Vous ne pouvez les utiliser que pour convertir votre schéma source avec l'outil de migration Ora2Pg.

Nous vous déconseillons d'utiliser l'ancien type d'espaces de travail de conversion pour vos migrations. Si votre scénario nécessite l'utilisation d'anciens espaces de travail de conversion, consultez Utiliser les anciens espaces de travail de conversion.

Étapes suivantes

Pour savoir comment utiliser les espaces de travail de conversion, consultez les articles suivants :