Lugares de trabajo de conversión

Los lugares de trabajo de conversión te ayudan a convertir el esquema y los objetos de tu base de datos de origen en la sintaxis de SQL que es compatible con tu base de datos de destino. En esta página, se proporciona una descripción general de los espacios de trabajo de conversión de Database Migration Service:

Las descripciones generales de la conversión proporcionan una sección transversal del progreso de la conversión del esquema.
Objetos compatibles con la conversión determinística de código y esquema enumera los objetos de Oracle compatibles con la conversión determinística de esquemas.
Editor de SQL interactivo describe qué objetos puedes modificar directamente en el editor del espacio de trabajo de conversión.
Funciones de conversión potenciadas por Gemini analiza cómo puedes integrar la compatibilidad con la IA generativa para acelerar el proceso de conversión de esquemas.
La sección Archivos de asignación de conversiones proporciona una descripción general de las directivas de personalización que puedes usar para anular las reglas de la conversión de esquemas determinísticos.
En espacios de trabajo de conversión heredados, se describen los espacios de trabajo heredados que no brindan compatibilidad con el editor de SQL interactivo.

Hay ciertos tipos de datos que no se admiten para las migraciones de Oracle. Para obtener más información, consulta Limitaciones conocidas de los tipos de datos.

Resúmenes del progreso de las conversiones

Información general sólida de los espacios de trabajo de conversión, en la que puedes obtener estadísticas sobre la cantidad total de problemas de conversión pendientes o resueltos, las mejoras asistidas por Gemini y el estado general de tu proceso de conversión

Pantalla del espacio de trabajo de conversión con la pestaña Resumen de la conversión, en la que puedes ver la cantidad de objetos convertidos, los problemas de conversión y las mejoras de la conversión asistida por Gemini. — **Figura 1.** Pantalla de descripción general del espacio de trabajo de conversión, en la que puedes supervisar el progreso de tu conversión, ver problemas y analizar el código de PostgreSQL resultante. (haz clic para agrandar)

Puedes usar esta vista para filtrar objetos en tu esquema por tipo, gravedad del problema, acciones necesarias o estado de conversión.

Pantalla del espacio de trabajo de conversión que muestra cómo puedes filtrar objetos convertidos por tipo o estado. — **Figura 2.** Filtrado de objetos convertidos por estado y tipo de objeto. (haz clic para agrandar)

Para obtener más información sobre cómo usar los resúmenes de conversiones para inspeccionar los resultados de las conversiones, consulta Trabaja con lugares de trabajo de conversiones.

Conversión determinística de código y esquemas

Cuando crea un espacio de trabajo de conversión, Database Migration Service realiza de inmediato la conversión inicial del esquema con un conjunto de reglas de conversión determinísticas en las que los tipos de datos y los objetos específicos de Oracle se asignan a tipos de datos y objetos específicos de PostgreSQL. Este proceso admite un subconjunto muy específico de objetos de base de datos de Oracle disponibles.

La conversión de código determinístico proporciona compatibilidad con los siguientes objetos de la base de datos de Oracle:

Elementos de esquema de Oracle admitidos

Limitaciones
Índices (solo los índices que se crean en el mismo esquema que su tabla)
Vistas materializadas
Tipos de objetos (compatibilidad parcial)
Secuencias
Sinónimos
Tablas
Vistas

Elementos de código de Oracle compatibles

Activadores (solo a nivel de la tabla)
Paquetes
Funciones
Procedimientos almacenados

Editor de SQL interactivo

El editor de SQL interactivo te permite modificar la sintaxis de PostgreSQL convertida directamente en Database Migration Service. Puedes usarlo para corregir problemas relacionados con las conversiones o ajustar el esquema para que se adapte mejor a tus necesidades. Algunos objetos no se pueden modificar en el editor integrado.

Objetos de Oracle editables

Después de convertir el código y el esquema de la base de datos de origen, puedes usar el editor interactivo para modificar el código SQL generado para ciertos tipos de objetos. El editor admite los siguientes objetos de Oracle:

Activadores de tablas (requiere permiso)
Vistas materializadas
Paquetes
Funciones y procedimientos almacenados
Sinónimos
Vistas
Limitaciones
Índices
Secuencias

Además, algunos objetos se convierten, pero no están disponibles para su edición directa en Database Migration Service. Para modificar esos objetos, debes realizar las actualizaciones directamente en la base de datos de destino después de aplicar el esquema y el código convertidos.

Objetos que no se admiten para la edición:

Tipos de objetos definidos por el usuario
Tablas
Esquemas

Acelera la conversión de código y esquemas con Gemini

Database Migration Service integra Gemini para Google Cloud en los espacios de trabajo de conversión para ayudarte a acelerar y mejorar el proceso de conversión en las siguientes áreas:

Mejora los resultados de la conversión determinística con la conversión automática potenciada por Gemini para aprovechar el poder de la IA y reducir significativamente la cantidad de ajustes manuales necesarios en tu código de PostgreSQL.

Proporciona funciones de explicabilidad del código con el asistente de conversión: un conjunto de instrucciones dedicadas que pueden ayudarte a comprender mejor la lógica de conversión, proponer correcciones para los problemas de conversión o bien optimizar el código convertido.
Acelera la aplicación de correcciones para los problemas de conversión con las sugerencias de conversión de código de Gemini: un mecanismo en el que el modelo de Gemini puede aprender a medida que corriges los problemas de conversión y sugerir cambios en otros objetos defectuosos del espacio de trabajo.

Para obtener más información sobre la conversión potenciada por Gemini, consulta las siguientes páginas:

Convierte código y esquemas de Oracle con la asistencia de Gemini

Ejemplo de flujo de trabajo para corregir objetos de código con problemas de conversión

Archivos de asignación de conversiones

Puedes personalizar la lógica de conversión con un archivo de asignación de conversiones. El archivo de asignación de conversión es un archivo de texto que contiene instrucciones precisas (denominadas directivas de conversión) sobre cómo se deben convertir tus objetos de Oracle en objetos de PostgreSQL.

Directivas de conversión admitidas

Database Migration Service admite las siguientes directivas de conversión para los archivos de asignación de conversión:

`EXPORT_SCHEMA`

EXPORT_SCHEMA es una directiva obligatoria para todos los archivos de asignación de conversiones. Database Migration Service requiere esta instrucción para garantizar que tus esquemas de origen se conviertan en los esquemas de destino correctos. Asegúrate de que tus archivos de asignación de conversiones incluyan esta línea:

EXPORT_SCHEMA 1

`SCHEMA`

Database Migration Service debe poder determinar qué esquema contiene los objetos que se deben modificar con tus directivas de conversión. La directiva SCHEMA hace que todas las demás directivas de personalización proporcionadas en tu archivo se apliquen a los objetos de este esquema en particular.

Cuando usas esta directiva, también se convierten otros esquemas contenidos en tu base de datos, pero sus objetos no están sujetos a ninguna modificación.
Si incluyes esta directiva en el archivo de asignación de conversiones, todas las personalizaciones se aplicarán solo a los objetos contenidos en este esquema específico.
Si omites esta directiva, debes proporcionar nombres de objetos completamente calificados que incluyan el nombre del esquema para los objetos modificados por otras directivas de conversión. Por ejemplo, en lugar de usar SOURCE_TABLE_NAME para la directiva REPLACE_TABLES, deberías usar "SCHEMA_NAME.SOURCE_TABLE_NAME".
Para personalizar objetos en diferentes esquemas, prueba lo siguiente:
- Crea archivos de asignación de conversiones separados para otros esquemas y súbelos al lugar de trabajo de conversión.
- Usa nombres de objetos completamente calificados que incluyan el nombre del esquema para los objetos que residen en esquemas diferentes del que proporcionas a la directiva SCHEMA.

Usa el siguiente formato:

SCHEMA SCHEMA_NAME

Aquí, SCHEMA_NAME es el nombre de tu esquema en la base de datos de origen.

`CASE_HANDLING`

De forma predeterminada, Database Migration Service convierte todos los nombres de objetos a minúsculas. Puedes usar la directiva CASE_HANDLING para modificar este comportamiento.

Esta directiva no se ve afectada por la directiva SCHEMA. Funciona a nivel global y afecta a todos los objetos del espacio de trabajo de conversión.
Las directivas RENAME_*, MOVE_* y REPLACE_* tienen prioridad sobre la directiva CASE_HANDLING y cambian el nombre de tus objetos exactamente, independientemente de la propiedad CASE_HANDLING.
Si esta directiva existe en varios archivos de configuración con valores en conflicto, Database Migration Service genera un error durante la importación del esquema.

Usa el siguiente formato:

CASE_HANDLING OPTION

En el ejemplo anterior, OPTION puede ser una de las siguientes opciones:

UPPERCASE: Convierte todos los nombres de objetos a mayúsculas.
LOWERCASE: Convierte todos los nombres de objetos a minúsculas (comportamiento predeterminado).
PRESERVE_ORIGINAL: Conserva el uso de mayúsculas y minúsculas original del esquema de origen. Esto es útil si tus aplicaciones usan identificadores que distinguen mayúsculas de minúsculas.

Ejemplo:

CASE_HANDLING PRESERVE_ORIGINAL

`GENERATE_MISSING_PK`

Las tablas sin claves primarias no garantizan una replicación coherente. Database Migration Service solo migra las tablas que tienen claves primarias. De forma predeterminada, los espacios de trabajo de conversión de Database Migration Service crean automáticamente las claves primarias faltantes en las tablas de destino cuando conviertes tu código fuente y esquema.

Puedes controlar la generación automática de clave primaria con la directiva GENERATE_MISSING_PK. Para inhabilitar la generación automática de claves, establece esta directiva en 0.

Ejemplo:

GENERATE_MISSING_PK 0

Esta directiva afecta a todos los objetos de un lugar de trabajo de conversión específico. No es posible inhabilitar la generación automática de clave primaria solo para una tabla específica.

Database Migration Service solo puede migrar tablas que tengan restricciones de clave primaria en sus versiones convertidas de PostgreSQL. Si inhabilitas la generación automática de clave primaria, deberás crear manualmente claves primarias o restricciones únicas en las tablas convertidas de la base de datos de destino después de aplicar el esquema convertido. Expande las siguientes secciones para ver ejemplos de comandos SQL.

Cómo crear claves primarias con columnas existentes

Es posible que tu tabla ya tenga una clave primaria lógica basada en una columna o una combinación de columnas. Por ejemplo, podría haber columnas con una restricción única o un índice configurado. Usa estas columnas para generar una nueva clave primaria para las tablas de tu base de datos de origen. Por ejemplo:

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

Crea una clave primaria con todas las columnas

Si no tienes una restricción preexistente que pueda servir como clave primaria, crea claves primarias con todas las columnas de la tabla. Asegúrate de no superar la longitud máxima de la clave primaria que permite tu clúster de PostgreSQL. Por ejemplo:

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);

Cuando creas una clave primaria compuesta como esta, debes enumerar explícitamente todos los nombres de columna que deseas usar. No es posible usar una instrucción para recuperar todos los nombres de las columnas con este fin.

Crea una restricción única con la seudocolumna `ROWID`

Las bases de datos de Oracle utilizan la pseudocolumna ROWID para almacenar la ubicación de cada fila en una tabla. Para migrar tablas de Oracle que no tienen claves primarias, puedes agregar una columna ROWID en la base de datos PostgreSQL de destino. Database Migration Service completa la columna con los valores numéricos correspondientes de la seudocolumna ROWID de Oracle de origen.

Para agregar la columna y establecerla como clave primaria, ejecuta el siguiente comando:

ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;
CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;
ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('TABLE_NAME_rowid_seq');
ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);

Cómo cambiar el nombre de los objetos (`RENAME_*`)

Puedes cambiar el nombre de diferentes objetos de la base de datos durante la conversión. Database Migration Service actualiza automáticamente todas las referencias de código (en vistas, procedimientos almacenados, funciones, etc.) para usar los nombres nuevos.

Sintaxis general

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

Consideraciones importantes

Las directivas RENAME_* distinguen mayúsculas de minúsculas para el nombre del objeto de destino y tienen prioridad sobre la directiva CASE_HANDLING. Por ejemplo, si usas ambas directivas:

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

Para SOURCE_NAME, siempre haz referencia al nombre del objeto original, incluso si usas otras directivas, como MOVE_*. Por ejemplo, si deseas cambiar el nombre de uno de tus objetos de vista y moverlo a un esquema nuevo, consulta el nombre de la vista original para ambas directivas:
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
La directiva RENAME_TABLES anula la directiva REPLACE_TABLES en un solo archivo. Si quieres cambiar el nombre y mover una tabla, te recomendamos que uses la directiva MOVE_*.
El formato completo de la variable SOURCE_NAME depende de si también usas la directiva SCHEMA:
- Con la directiva SCHEMA: Usa nombres no calificados, como MyTable.
- Sin la directiva SCHEMA: Usa nombres completamente calificados, por ejemplo, MySchema.MyTable.

Directivas RENAME_* admitidas

RENAME_SCHEMA: Cambia el nombre de un esquema.
Un solo archivo de configuración solo puede contener una directiva RENAME_SCHEMA. Si se proporciona la directiva SCHEMA, RENAME_SCHEMA solo puede cambiar el nombre de ese esquema en particular.
RENAME_TABLES: Cambia el nombre de las tablas. Anula el REPLACE_TABLES en el mismo archivo.
RENAME_COLUMNS: Cambia el nombre de las columnas dentro de las tablas. Anula la directiva REPLACE_COLS en el mismo archivo. Usa el siguiente formato:
```
RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL
```
Si usas la directiva SCHEMA, usa nombres de tablas no calificados. Si no usas la directiva SCHEMA, incluye los nombres de tabla completamente calificados, como SCHEMA.TABLE1.
RENAME_VIEWS
RENAME_MATERIALIZED_VIEWS
RENAME_SEQUENCES
RENAME_FUNCTIONS
RENAME_STORED_PROCEDURES
RENAME_TRIGGERS
RENAME_PACKAGES: Database Migration Service convierte paquetes de Oracle en esquemas de PostgreSQL. Si tu esquema contiene paquetes que comparten nombres, es posible que el código de PostgreSQL encuentre conflictos de nombres cuando intente crear dos esquemas con el mismo nombre. Puedes usar esta directiva para evitar esos conflictos.

Por ejemplo, si tienes paquetes como SALES.REPORTING_PKG y HR.REPORTING_PKG, puedes cambiarles el nombre para que sean distintos:
```
RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS
```
RENAME_USER_DEFINED_TYPES

Alias disponible: RENAME_UDTS.

Objetos en movimiento (`MOVE_*`)

Puedes mover objetos a diferentes esquemas en la base de datos de destino. Esto es útil para reorganizar la estructura de la base de datos durante la migración. Database Migration Service actualiza automáticamente todas las referencias de código en vistas, procedimientos almacenados, funciones, etcétera.

Sintaxis general

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

Consideraciones importantes

Para SOURCE_NAME, siempre haz referencia al nombre del objeto original, incluso si usas otras directivas, como RENAME_*. Por ejemplo, si deseas cambiar el nombre de uno de tus objetos de vista y moverlo a un esquema nuevo, consulta el nombre de la vista original para ambas directivas:
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
La directiva solo espera el nombre de DESTINATION_SCHEMA, no el nombre completo del objeto.
El formato completo de la variable SOURCE_NAME depende de si también usas la directiva SCHEMA:
- Con la directiva SCHEMA: Usa nombres no calificados, como MyTable.
- Sin la directiva SCHEMA: Usa nombres completamente calificados, por ejemplo, MySchema.MyTable.

Directivas MOVE_* admitidas

MOVE_TABLES: Mueve tablas a un esquema diferente. Tiene prioridad sobre REPLACE_TABLES para los cambios de esquema en un solo archivo de configuración.
MOVE_VIEWS
MOVE_MATERIALIZED_VIEWS
MOVE_SEQUENCES
MOVE_FUNCTIONS
MOVE_STORED_PROCEDURES
MOVE_USER_DEFINED_TYPES

Alias disponible: MOVE_UDTS.

Ejemplo: Reorganización de esquemas

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`

Puedes usar esta directiva para asignar de forma explícita cualquier tipo de datos compatible entre la sintaxis de Oracle y PostgreSQL. Esta directiva espera una lista de asignaciones separadas por comas. La definición completa debe proporcionarse en una sola línea, pero puedes incluir varias directivas DATA_TYPE en tu archivo de configuración. Usa el siguiente formato:

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

Aquí, ORACLE_DATA_TYPE y PGSQL_DATA_TYPE son tipos de datos admitidos por las versiones respectivas de Oracle y PostgreSQL que usas en tu migración. Para obtener información sobre las versiones compatibles, consulta Descripción general del escenario.

Ejemplo:

DATA_TYPE REAL:double precision,SMALLINT:integer

Para obtener más información sobre los tipos de datos de Oracle y PostgreSQL, consulta los siguientes vínculos:

Tipos de datos de Oracle en la documentación de Oracle
Tipos de datos de PostgreSQL en la documentación de PostgreSQL

`MODIFY_TYPE`

La directiva MODIFY_TYPE te permite controlar a qué tipo de datos convierte Database Migration Service una columna específica de tu tabla de origen. Esta directiva espera una lista de asignaciones separadas por comas. La definición completa debe proporcionarse en una sola línea, pero puedes incluir varias directivas MODIFY_TYPE en tu archivo de configuración. Usa el siguiente formato:

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

Aquí:

SOURCE_TABLE_NAME es el nombre de la tabla que contiene la columna en la que deseas cambiar el tipo de datos.
Importante: Si no usas la directiva SCHEMA, asegúrate de usar el nombre de tabla completo: SCHEMA_NAME.SOURCE_TABLE_NAME
COLUMN_NAME es el nombre de la columna para la que deseas personalizar la asignación de conversiones.
EXPECTED_END_RESULT_DATA_TYPE es el tipo de datos de PostgreSQL que deseas que use la columna convertida.

Ejemplo:

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

`PG_INTEGER_TYPE`

De forma predeterminada,Database Migration Service convierte los tipos NUMBER(p,s) en el tipo DECIMAL(p,s) de PostgreSQL.

Puedes modificar este comportamiento con la directiva PG_INTEGER_TYPE. Establece su valor en 1 y fuerza la conversión de todos tus tipos NUMBER con precisión y escala (NUMBER(p,s)) en tipos smallint, integer o bigint de PostgreSQL según la cantidad de dígitos de precisión.

Nota: También puedes usar esta directiva para tipos NUMBER simples si la combinas con la directiva DEFAULT_NUMERIC.

Incluye el siguiente parámetro de configuración en tu archivo de asignación de conversiones:

PG_INTEGER_TYPE 1

`PG_NUMERIC_TYPE`

Establece esta directiva en 1 si deseas convertir todos tus tipos NUMBER con precisión y escala (NUMBER(p,s)) en tipos real o float de PostgreSQL (según su cantidad de dígitos de precisión).

Si configuras esta directiva en 0, los valores de NUMBER(p,s) conservarán su valor original exacto y usarán el tipo de datos interno de PostgreSQL.

Incluye el siguiente parámetro de configuración en tu archivo de asignación de conversiones:

PG_NUMERIC_TYPE 1

`DEFAULT_NUMERIC`

La conversión predeterminada para los NUMBERs sin precisión cambia según si también usas la directiva PG_INTEGER_TYPE:

Si usas la directiva PG_INTEGER, los NUMBERs sin precisión se convierten en valores DECIMAL.
Si no usas la directiva PG_INTEGER, los NUMBERs sin precisión se convierten en valores BIGINT.

Puedes modificar este comportamiento y usar la directiva DEFAULT_NUMERIC para especificar qué tipo de datos se debe usar para los tipos NUMBER sin puntos de precisión especificados. Usa el siguiente formato:

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

Donde POSTGRESQL_NUMERIC_DATA_TYPE es uno de los siguientes: integer, smallint, bigint.

Ejemplo:

DEFAULT_NUMERIC integer

`REPLACE_COLS`

Puedes usar la directiva REPLACE_COLS para cambiar el nombre de las columnas en tu esquema convertido. Esta directiva espera una lista de asignaciones separadas por comas.

Usa el siguiente formato:

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)...

Aquí:

SOURCE_TABLE_NAME es el nombre de la tabla que contiene la columna cuyo nombre deseas cambiar. Si no usas la directiva SCHEMA, asegúrate de usar el nombre de tabla completamente calificado: SCHEMA_NAME.SOURCE_TABLE_NAME
SOURCE_COLUMN_NAME es el nombre de la columna de tu fuente cuyo nombre deseas cambiar.
DESTINATION_COLUMN_NAME es el nuevo nombre de la columna que deseas usar en el esquema convertido.

Ejemplo:

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

`REPLACE_TABLES`

Puedes usar la directiva REPLACE_TABLES para cambiar el nombre de las tablas o moverlas a un esquema nuevo. Esta directiva espera una lista de asignaciones separadas por espacios. Si deseas obtener más información sobre la sintaxis de cada caso de uso, expande las siguientes secciones.

Si no usas la directiva SCHEMA, asegúrate de usar los nombres de tabla completamente calificados entre comillas para las variables de origen y destino:

"SCHEMA_NAME.SOURCE_TABLE_NAME"
"SCHEMA_NAME.DESTINATION_TABLE_NAME"

Cambia el nombre de las tablas

Para cambiar el nombre de las tablas en tu esquema convertido, usa el siguiente formato:

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

Aquí:

SOURCE_TABLE_NAME es el nombre de la tabla de origen a la que deseas cambiarle el nombre en el esquema convertido.
DESTINATION_TABLE_NAME es el nuevo nombre de la tabla que deseas usar en el esquema convertido.

Ejemplo:

REPLACE_TABLES "events:login_events" "users:platform_users"

Cómo mover tablas entre esquemas

Puedes usar esta directiva para mover tablas entre esquemas agregando el prefijo del esquema al nombre de la tabla nueva. Este mecanismo se puede usar independientemente de cómo uses la directiva SCHEMA para todo el archivo de conversiones. Por ejemplo:

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

Alias para personalizar tipos de datos

Cuando usas directivas de conversión para modificar la forma en que Database Migration Service convierte diferentes tipos de datos (por ejemplo, con las directivas DATA_TYPE, MODIFY_TYPE o PG_NUMERIC_TYPE), puedes usar alias en lugar de los tipos de datos SQL de origen.

Expande la siguiente sección para ver la lista de alias de tipos de datos admitidos por Database Migration Service.

Alias de tipos de datos

Alias	Se convirtió al tipo de PostgreSQL
`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` y `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`

Archivo de asignación de conversiones de muestra

Consulta el siguiente archivo de asignación de conversiones de ejemplo que usa algunas de las directivas de conversión de esquema admitidas:

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

Los resultados de usar este archivo son los siguientes:

EXPORT_SCHEMA 1 es una directiva obligatoria.
SCHEMA root hace que las otras directivas se apliquen a los objetos dentro del esquema root, a menos que se usen nombres completamente calificados.
CASE_HANDLING PRESERVE_ORIGINAL garantiza que todos los nombres de objetos del esquema root de origen conserven su capitalización original en el destino (a menos que se anule con una directiva RENAME_*).
PG_INTEGER_TYPE 1 hace que Database Migration Service convierta todos los tipos de datos numéricos de Oracle que se encuentran en las tablas del esquema root en tipos específicos de PostgreSQL en lugar de tipos numéricos portátiles de ANSI.
DEFAULT_NUMERIC integer hace que Database Migration Service convierta los valores de NUMBER que no tienen un punto de precisión especificado en el tipo INTEGER de PostgreSQL.
DATA_TYPE NUMBER(4\,0):integer hace que Database Migration Service convierta valores NUMBER(4,0) específicos en INTEGER de PostgreSQL.
La directiva MODIFY_TYPE events:dates_and_times:TIMESTAMP hace que Database Migration Service convierta los datos de la columna dates_and_times en la tabla de origen events específicamente al tipo TIMESTAMP de PostgreSQL.
RENAME_TABLES events:LoginEvents users:PlatformUsers cambia el nombre de las tablas y conserva el caso especificado:
- Se cambió el nombre de la tabla events a LoginEvents.
- Se cambió el nombre de la tabla users a PlatformUsers.
RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname cambia el nombre de las columnas y conserva el caso especificado en el destino:
- En la tabla LoginEvents (nombre original events), se cambió el nombre de la columna dates_and_times a EventDates.
- En la columna PlatformUsers (nombre original users), se cambió el nombre de la columna pseudonym a Nickname.
RENAME_VIEWS InternalReport:FinInternalReport cambia el nombre de la vista InternalReport a FinInternalReport.
MOVE_TABLES audit_log:archive mueve la tabla audit_log del esquema root al esquema archive.
MOVE_VIEWS InternalReport:reporting mueve la vista InternalReport al esquema reporting. Esta vista también se renombra como FinInternalReport debido a la directiva RENAME_VIEWS. Database Migration Service controla la dependencia: primero se cambia el nombre del objeto y, luego, se mueve.

Espacios de trabajo de conversión heredados

Los espacios de trabajo de conversión heredados son un tipo de espacios de trabajo de conversión más antiguo y limitado. Los espacios de trabajo de conversión heredados no admiten las funciones de conversión mejoradas por Gemini ni el editor de SQL interactivo. Solo puedes usarlos para convertir tu esquema de origen con la herramienta de migración Ora2Pg.

No recomendamos usar el tipo heredado de espacios de trabajo de conversiones para tus migraciones. Si tu situación requiere el uso de espacios de trabajo de conversión heredados, consulta Cómo trabajar con espacios de trabajo de conversión heredados.

¿Qué sigue?

Para obtener información sobre cómo usar los espacios de trabajo de conversión, consulta los siguientes recursos:

Lugares de trabajo de conversión Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Resúmenes del progreso de las conversiones

Conversión determinística de código y esquemas

Elementos de esquema de Oracle admitidos

Elementos de código de Oracle compatibles

Editor de SQL interactivo

Objetos de Oracle editables

Acelera la conversión de código y esquemas con Gemini

Archivos de asignación de conversiones

Directivas de conversión admitidas

EXPORT_SCHEMA

SCHEMA

CASE_HANDLING

GENERATE_MISSING_PK

Cómo crear claves primarias con columnas existentes

Crea una clave primaria con todas las columnas

Crea una restricción única con la seudocolumna ROWID

Cómo cambiar el nombre de los objetos (RENAME_*)

Objetos en movimiento (MOVE_*)

DATA_TYPE

MODIFY_TYPE

PG_INTEGER_TYPE

PG_NUMERIC_TYPE

DEFAULT_NUMERIC

REPLACE_COLS

REPLACE_TABLES

Cambia el nombre de las tablas

Cómo mover tablas entre esquemas

Alias para personalizar tipos de datos

Alias de tipos de datos

Archivo de asignación de conversiones de muestra

Espacios de trabajo de conversión heredados

¿Qué sigue?

Lugares de trabajo de conversión

`EXPORT_SCHEMA`

`SCHEMA`

`CASE_HANDLING`

`GENERATE_MISSING_PK`

Crea una restricción única con la seudocolumna `ROWID`

Cómo cambiar el nombre de los objetos (`RENAME_*`)

Objetos en movimiento (`MOVE_*`)

`DATA_TYPE`

`MODIFY_TYPE`

`PG_INTEGER_TYPE`

`PG_NUMERIC_TYPE`

`DEFAULT_NUMERIC`

`REPLACE_COLS`

`REPLACE_TABLES`