Migra del sistema de OLTP de Oracle® a Spanner

En este artículo, se explica cómo migrar tu base de datos de los sistemas de procesamiento de transacciones en línea (OLTP) de Oracle® a Spanner.

Spanner usa algunos conceptos de manera diferente a otras herramientas de administración de bases de datos empresariales, por lo que es posible que debas configurar tu aplicación para aprovechar al máximo sus capacidades. Es posible que también debas complementar Spanner con otros servicios de Google Cloud para satisfacer tus necesidades.

Restricciones de migración

Cuando migres la aplicación a Spanner, deberás tener en cuenta todas las funciones disponibles. Es probable que necesites rediseñar la arquitectura de la aplicación a fin de ajustarla al conjunto de atributos de Spanner, así como para integrarla a los servicios adicionales de Google Cloud.

Procedimientos y activadores almacenados

Spanner no admite la ejecución de código de usuario a nivel de base de datos. Por lo tanto, como parte de la migración, deberás trasladar la lógica empresarial que implementaron los activadores y los procedimientos almacenados a nivel de base de datos a la aplicación.

Secuencias

Recomendamos usar la versión 4 de UUID como el método predeterminado para generar valores de clave primaria. La función GENERATE_UUID() (GoogleSQL, PostgreSQL) muestra los valores de la versión 4 de UUID como un tipo STRING.

Si necesitas generar valores de números enteros de 64 bits, Spanner admite secuencias positivas invertidas de bits (GoogleSQL, PostgreSQL), que producen valores que se distribuyen de manera uniforme en el espacio positivo del número de 64 bits. Puedes usar estos números para evitar problemas de generación de hotspots.

Para obtener más información, consulta las estrategias de valor predeterminado de la clave primaria.

Controles de acceso

Spanner solo admite controles de acceso a nivel de la base de datos mediante las funciones y los permisos de acceso de Cloud IAM. Las funciones predefinidas pueden dar acceso de lectura y escritura o acceso de solo lectura a la base de datos.

Si necesitas permisos más detallados, debes implementarlos en la capa de la aplicación. En una situación normal, solo la aplicación tiene permiso para leer y escribir en la base de datos.

Si necesitas exponer tu base de datos a los usuarios para generar informes y deseas utilizar permisos de seguridad específicos (como permisos a nivel de la tabla y la vista), debes exportar tu base de datos a BigQuery.

Restricciones de validación de datos

Spanner puede admitir un conjunto limitado de restricciones de validación de datos en la capa de la base de datos.

Si necesitas restricciones de datos más complejas, impleméntalas en la capa de la aplicación.

En la siguiente tabla, se analizan los tipos de restricciones que suelen encontrarse en las bases de datos de Oracle® y cómo implementarlas con Spanner.

Restricción Implementación con Spanner
No nula Restricción de columna NOT NULL
Único Índice secundario con restricción UNIQUE
Clave externa (para tablas normales) Consulta Crea y administra relaciones de claves externas
Acciones ON DELETE/ON UPDATE de clave externa Solo es posible para tablas intercaladas; si quieres usarlas en otro contexto, tendrás que implementarlas en la capa de la aplicación
Verificaciones de valor y validación mediante restricciones o activadores CHECK Se implementa en la capa de la aplicación

Tipos de datos admitidos

Las bases de datos Oracle® y Spanner admiten conjuntos diferentes de tipos de datos. En la siguiente tabla, se enumeran los tipos de datos de Oracle y sus equivalentes en Spanner. Para obtener definiciones detalladas de cada tipo de datos de Spanner, consulta Tipos de datos.

Es posible que también tengas que realizar transformaciones adicionales en los datos, como se describe en la columna de notas, para que los datos de Oracle se ajusten a tu base de datos de Spanner.

Por ejemplo, puedes almacenar un BLOB grande como objeto en un depósito de Cloud Storage en lugar de la base de datos y, luego, almacenar la referencia de URI al objeto de Cloud Storage en la base de datos como una STRING.

Tipo de datos de Oracle Equivalente en Spanner Notas
Tipos de caracteres (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Nota: Spanner usa strings Unicode en todo momento.
Oracle admite una longitud máxima de 32,000 bytes o caracteres (según el tipo), mientras que Spanner admite hasta 2,621,440 caracteres.
BLOB, LONG RAW, BFILE BYTES o STRING que contienen el URI del objeto. Los objetos pequeños (menos de 10 MiB) se pueden almacenar como BYTES.
Para almacenar objetos más grandes, considera usar otras ofertas de Google Cloud, como Cloud Storage.
CLOB, NCLOB, LONG STRING (que puede contener datos o el URI de un objeto externo) Los objetos pequeños (menos de 2,621,440 caracteres) se pueden almacenar como STRING. Para almacenar objetos más grandes, considera usar otras ofertas de Google Cloud, como Cloud Storage.
NUMBER, NUMERIC, DECIMAL STRING, FLOAT64, INT64 El tipo de datos NUMBER de Oracle admite hasta 38 dígitos de precisión, mientras que el tipo de datos FLOAT64 de Spanner admite hasta 16 dígitos. Consulta Almacena datos numéricos de precisión arbitrarios para ver mecanismos alternativos.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La representación predeterminada STRING del tipo DATE de Spanner es yyyy-mm-dd, lo cual difiere de la que se usa en Oracle. Por eso, debes tener cuidado si conviertes las representaciones de fechas en STRING de un sistema al otro de forma automática. Se proporcionan funciones de SQL para convertir las fechas en una string con formato.
DATETIME TIMESTAMP Spanner almacena el tiempo de forma independiente de la zona horaria. Si necesitas almacenar una zona horaria, debes usar una columna de STRING separada. Se proporcionan funciones de SQL para convertir las marcas de tiempo en una string con formato mediante zonas horarias.
XML STRING (que puede contener datos o el URI de un objeto externo) Los objetos XML pequeños (menos de 2,621,440 caracteres) se pueden almacenar como STRING. Para almacenar objetos más grandes, considera usar otras ofertas de Google Cloud, como Cloud Storage.
URI, DBURI, XDBURI, HTTPURI STRING
ROWID PRIMARY KEY Spanner usa la clave primaria de la tabla para ordenar las filas y hacer referencia a ellas de forma interna. Por lo tanto, en Spanner, es equivalente al tipo de datos ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Spanner no admite tipos de datos geoespaciales. Tienes que almacenarlos como tipos de datos estándares y, además, implementar en la capa de la aplicación la lógica de búsqueda y filtrado que quieras usar.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo y ORDImageSignature Spanner no admite tipos de datos de medios. Si necesitas almacenar datos de este tipo, considera usar Cloud Storage.

Proceso de migración

Un cronograma general del proceso de migración incluiría los pasos que se indican a continuación:

  1. Convertir tu esquema y modelo de datos
  2. Traducir las consultas de SQL que uses
  3. Migrar tu aplicación para usar Spanner, además de Oracle
  4. Hacer una exportación masiva de tus datos de Oracle y, luego, importarlos en Spanner mediante Dataflow
  5. Mantener la coherencia entre ambas bases de datos durante la migración
  6. Migrar tu aplicación para sacarla de Oracle

Paso 1: Convierte la base de datos y el esquema

Debes convertir el esquema existente en un esquema de Spanner para almacenar los datos. Dentro de lo posible, esto debe coincidir con el esquema de Oracle existente para simplificar las modificaciones de la aplicación. Sin embargo, debido a las diferencias en las funciones, se necesitarán algunos cambios.

El uso de las prácticas recomendadas en el diseño de esquemas puede ayudarte a aumentar la capacidad de procesamiento y a reducir los puntos problemáticos en la base de datos de Spanner.

Claves primarias

En Spanner, cada tabla que debe almacenar más de una fila debe tener una clave primaria compuesta por una o más columnas. La clave primaria de la tabla identifica de manera única cada fila de una tabla, y las filas de la tabla se ordenan según la clave primaria. Debido a que Spanner está altamente distribuido, es importante que elijas una técnica de generación de clave primaria que se ajuste bien al crecimiento de tus datos. Para obtener más información, consulta las estrategias recomendadas de migración de claves primarias.

Ten en cuenta que después de designar tu clave primaria, no puedes agregar ni quitar una columna de clave primaria, ni cambiar un valor de clave primaria sin borrar y volver a crear la tabla. Si deseas obtener más información para designar tu clave primaria, consulta Esquema y modelo de datos: Claves primarias.

Intercala tus tablas

Spanner tiene una función que te permite definir una relación de superior y secundaria de tipo uno a varios entre dos tablas. Esto intercala las filas de datos secundarias con las filas superiores en el almacenamiento, que permite una unión previa de la tabla y mejora la eficiencia de la recuperación de datos cuando se consultan datos del nivel superior y del secundario a la vez.

La clave primaria de la tabla secundaria debe comenzar con las columnas de la clave primaria de la tabla superior. Desde la perspectiva de la fila secundaria, la clave primaria de la fila superior se denomina clave externa. Puedes definir hasta 6 niveles de relaciones entre tablas superiores y secundarias.

Puedes definir acciones de eliminación para las tablas secundarias en las que indicas qué sucede cuando se borra la fila superior: se borran todas las filas secundarias o se impide la eliminación de la fila superior mientras existen filas secundarias.

A continuación, te mostramos un ejemplo de cómo crear una tabla de Álbumes intercalada en la tabla superior de Cantantes definida anteriormente:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Crea índices secundarios

También puedes crear índices secundarios para indexar datos dentro de la tabla aparte de la clave primaria.

Spanner implementa los índices secundarios de la misma manera que las tablas, por lo que los valores de la columna que se usarán como claves de índice tienen las mismas restricciones que las claves primarias de las tablas. Esto también significa que los índices tienen las mismas garantías de coherencia que las tablas de Spanner.

Las búsquedas de valores con índices secundarios son, en la práctica, lo mismo que una consulta con una unión de tablas. Para mejorar el rendimiento de las consultas con índices, puedes almacenar copias de los valores de las columnas de la tabla original en el índice secundario mediante la cláusula STORING, lo que la convierte en un índice de cobertura.

El optimizador de consultas de Spanner solo usará los índices secundarios de forma automática cuando el índice almacene todas las columnas que se consultan (una consulta cubierta). Para facilitar el uso de un índice cuando se consultan las columnas de la tabla original, deberás usar una directiva FORCE INDEX en la instrucción de SQL, por ejemplo:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

Se pueden usar los índices a fin de aplicar valores únicos dentro de una columna de la tabla; para ello, se define un índice UNIQUE en esa columna. Este índice impedirá que se agreguen valores duplicados.

A continuación, se incluye una instrucción de DDL de ejemplo en la que se crea un índice secundario para la tabla de Álbumes:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Ten en cuenta que si creas índices adicionales después de cargar tus datos, la propagación de datos al índice puede tardar un poco. Debes limitar la velocidad a la que los agrega a un promedio de tres por día. Para obtener más indicaciones sobre cómo crear índices secundarios, consulta Índices secundarios. Para obtener más información sobre las limitaciones en la creación de índices, consulta Actualizaciones del esquema.

Paso 2: Traduce cualquier consulta en SQL

Spanner usa el dialecto ANSI 2011 de SQL con extensiones y tiene muchas funciones y operadores para ayudarte a traducir y a agregar los datos. Deberás convertir cualquier consulta de SQL que use sintaxis, funciones y tipos específicos de Oracle para que sea compatible con Spanner.

Si bien Spanner no admite datos estructurados como definiciones de columnas, esos datos se pueden usar en consultas de SQL que usan los tipos ARRAY y STRUCT.

Por ejemplo, se podría escribir una consulta que muestre todos los álbumes de un artista mediante un ARRAY de STRUCTs en una sola consulta (esto permite aprovechar los datos unidos con anterioridad). Para obtener más información, consulta la sección Notas sobre las subconsultas de la documentación.

Las consultas de SQL se pueden perfilar mediante la página de Spanner Studio en la Google Cloud Console para ejecutar la consulta. En general, las consultas que realizan análisis de tablas completos en tablas grandes son muy costosas y deben usarse con moderación.

Consulta la documentación Prácticas recomendadas de SQL para obtener más información sobre cómo optimizar las consultas de SQL.

Paso 3: Migra tu aplicación para usar Spanner

Spanner proporciona un conjunto de bibliotecas cliente para varios idiomas y la capacidad de leer y escribir datos mediante llamadas a la API específicas de Spanner, así como mediante el uso de consultas de SQL y de instrucciones de lenguaje de modificación de datos (DML). El uso de llamadas a la API puede ser más rápido para algunas consultas, como la lectura directa de filas por clave, ya que no hace falta traducir la instrucción de SQL.

También puedes usar el controlador de la conectividad a bases de datos de Java (JDBC) para conectarte a Spanner, lo que te permite aprovechar las herramientas existentes y la infraestructura sin integración nativa.

Como parte del proceso de migración, las funciones que no están disponibles en Spanner deben implementarse en la aplicación. Por ejemplo, si usas un activador para verificar los valores de datos y actualizar una tabla relacionada, tendrás que implementarlo en la aplicación mediante una transacción de lectura y escritura a fin de leer la fila existente, verificar las restricciones y escribir las filas actualizadas en ambas tablas.

Spanner ofrece transacciones de solo lectura y de lectura y escritura, que garantizan la coherencia externa de los datos. Además, se pueden aplicar límites de marca de tiempo a las transacciones de lectura, en cuyo caso se lee una versión coherente de los datos especificados de las siguientes maneras:

  • En un momento exacto del pasado (hasta hace 1 hora)
  • En el futuro (en cuyo caso la lectura se bloquea hasta que llegue ese momento)
  • Con una cantidad aceptable de obsolescencia limitada, en cuyo caso se muestra una vista coherente hasta algún tiempo en el pasado sin necesidad de verificar que los datos posteriores estén disponibles en otra réplica. Esto puede ser beneficioso en términos de rendimiento, pero tiene la desventaja de que los datos podrían estar obsoletos.

Paso 4: Transfiere tus datos de Oracle a Spanner

Para transferir tus datos de Oracle a Spanner, deberás exportar la base de datos de Oracle a un formato de archivo portátil (por ejemplo, CSV) y, luego, importar esos datos a Spanner mediante Dataflow.

El proceso de extracción, transformación y carga en Dataflow

Exportación masiva desde Oracle

Oracle no proporciona ninguna utilidad integrada para exportar o descargar tu base de datos completa en un formato de archivo portátil.

En las Preguntas frecuentes de Oracle se enumeran algunas opciones para realizar una exportación.

Estas incluyen lo siguiente:

  • Utilizar SQL*plus o SQLcl para enviar una consulta a un archivo de texto mediante una operación de tipo Spool.
  • Escribir una función PL/SQL mediante UTL_FILE para descargar una tabla en paralelo a archivos de texto.
  • Usar funciones de Oracle APEX o de Oracle SQL Developer para descargar una tabla en un archivo CSV o XML.

Cada una de estas opciones tiene como desventaja que solo se puede exportar una tabla a la vez, por lo que debes pausar tu aplicación o desactivar tu base de datos para que permanezca en un estado coherente durante la exportación.

Otras opciones incluyen las herramientas de terceros descritas en la página Preguntas frecuentes de Oracle, algunas de las cuales pueden descargar una vista coherente de la base de datos completa.

Una vez descargados los archivos de datos, debes subirlos a un bucket de Cloud Storage a fin de que pueda accederse a ellos para la importación.

Realiza una importación masiva a Spanner

Debido a que puede haber diferencias entre los esquemas de base de datos de Oracle y Spanner, es posible que debas realizar algunas conversiones de datos como parte del proceso de importación.

El uso de Dataflow es la forma más sencilla de realizar estas conversiones y, luego, importar los datos a Spanner.

Dataflow es el servicio de extracción, transformación y carga (ETL) de Google Cloud. Proporciona una plataforma para ejecutar canalizaciones de datos escritas con el SDK de Apache Beam a fin de leer y procesar grandes cantidades de datos en paralelo en varias máquinas.

El SDK de Apache Beam requiere que escribas un programa de Java sencillo para configurar la lectura, la transformación y la escritura de los datos. Existen conectores de Beam para Cloud Storage y Spanner, por lo que el único código que debe escribirse es la transformación de datos.

Para ver un ejemplo de canalización simple que lee desde archivos CSV y escribe en Spanner, consulta el repositorio del código de muestra que acompaña este artículo.

Si se usan tablas superiores y secundarias intercaladas en el esquema de Spanner, se debe tener cuidado en el proceso de importación para que la fila superior se cree antes que la secundaria. El código de canalización de importación de Spanner se encarga de esto. Para ello, primero importa todos los datos de las tablas de nivel raíz; luego, todas las tablas secundarias de nivel 1; y, por último, todas las tablas secundarias de nivel 2, y así sucesivamente.

Se puede usar directamente la canalización de importación de Spanner para hacer una importación masiva de tus datos, pero esto requiere que los datos existan en archivos Avro que usen el esquema correcto.

Paso 5: Mantén la coherencia entre ambas bases de datos

Muchas aplicaciones tienen requisitos de disponibilidad que hacen imposible mantener la aplicación sin conexión durante el tiempo necesario para exportar y, además, importar los datos. Mientras transfieres los datos a Spanner, tu aplicación continúa con la modificación de la base de datos existente. Deberás duplicar las actualizaciones de la base de datos de Spanner mientras la aplicación esté en ejecución.

Existen varios métodos para mantener las dos bases de datos sincronizadas, incluida la captura de datos modificados y la implementación de actualizaciones simultáneas en la aplicación.

Captura los datos modificados

Oracle GoldenGate puede proporcionar una transmisión de captura de datos modificados (CDC) para tu base de datos de Oracle. Oracle LogMiner y Oracle XStream Out son interfaces alternativas para que la base de datos de Oracle obtenga una transmisión de CDC que no involucre a Oracle GoldenGate.

Puedes escribir una aplicación que se suscriba a una de estas transmisiones y aplique las mismas modificaciones (después de convertir los datos) a tu base de datos de Spanner. Esta aplicación de procesamiento de transmisión debe implementar varias funciones:

  • Establecer una conexión con la base de datos de Oracle (base de datos de origen)
  • Conectarse a Spanner (base de datos de destino)
  • Realizar, de manera reiterada, lo siguiente:
    • Recibir los datos generados mediante una de las transmisiones de CDC de la base de datos de Oracle
    • Interpretar los datos generados mediante la transmisión de CDC
    • Convertir los datos en instrucciones INSERT de Spanner
    • Ejecutar las instrucciones INSERT de Spanner

La tecnología de migración de bases de datos, que es de tipo middleware, implementó las funciones necesarias como parte de su funcionalidad. La plataforma de migración de bases de datos se instala como un componente independiente en la ubicación de origen o de destino, de acuerdo con los requisitos del cliente. La plataforma de migración de bases de datos solo requiere la configuración de conectividad de las bases de datos involucradas para especificar y comenzar la transferencia de datos continua desde la base de datos de origen hasta la de destino.

Striim es una plataforma de tecnología de migración de bases de datos que está disponible en Google Cloud. Proporciona conectividad a las transmisiones de CDC de Oracle GoldenGate, así como de Oracle LogMiner y Oracle XStream Out. Striim ofrece una herramienta gráfica que te permite configurar la conectividad de la base de datos y las reglas de transformación necesarias para transferir datos de Oracle a Spanner.

Puedes instalar Striim desde Google Cloud Marketplace, conectarte a las bases de datos de origen y destino, implementar reglas de transformación y comenzar a transferir datos sin tener que compilar una aplicación de procesamiento de transmisión.

Realiza actualizaciones de forma simultánea en ambas bases de datos desde la aplicación

Un método alternativo es modificar tu aplicación para realizar escrituras en ambas bases de datos. Una base de datos (en principio, Oracle) se consideraría la fuente de información y, después de cada escritura de la base de datos, toda la fila se lee, se convierte y se escribe en la base de datos de Spanner.

De esta manera, la aplicación reemplaza de forma constante las filas de Spanner por los datos más recientes.

Una vez que estés seguro de que todos tus datos se transfirieron de manera correcta, podrás cambiar la fuente de información a la base de datos de Spanner.

Este mecanismo proporciona una ruta de reversión si se detectan problemas cuando se realiza el cambio a Spanner.

Verifica la coherencia de los datos

A medida que los datos se transmiten a tu base de datos de Spanner, podrás ejecutar una comparación de forma periódica entre los datos de Spanner y los de Oracle para asegurarte de que sean coherentes.

Para validar la coherencia, puedes consultar ambas fuentes de datos y comparar los resultados.

Puedes usar Dataflow para realizar una comparación detallada en conjuntos de datos grandes mediante la transformación de unión. Esta transformación toma 2 conjuntos de datos con clave y hace coincidir los valores por clave. Luego, los valores pueden compararse para determinar si son iguales.

Puedes ejecutar esta verificación con regularidad hasta que el nivel de coherencia coincida con tus requisitos empresariales.

Paso 6: Cambia a Spanner como la fuente de información de la aplicación

Cuando estés seguro acerca de la migración de datos, puedes cambiar tu aplicación a Spanner como la fuente de información. Continúa reescribiendo los cambios en la base de datos de Oracle para mantenerla actualizada, lo que te brindará una ruta de reversión en caso de que se detecten problemas.

Por último, puedes inhabilitar y quitar el código de actualización de la base de datos de Oracle y cerrarla.

Importa y exporta bases de datos de Spanner

De manera opcional, puedes exportar tus tablas de Spanner a un bucket de Cloud Storage mediante una plantilla de Dataflow para realizar la exportación. La carpeta resultante contiene un conjunto de archivos Avro y archivos de manifiesto JSON que contienen las tablas exportadas. Estos archivos pueden servir para distintos propósitos, incluidos los que se indican a continuación:

  • Crear copias de seguridad de tu base de datos para usarlas en la recuperación ante desastres o cumplir con una política de retención de datos
  • Importar el archivo Avro a otras ofertas de Google Cloud, como BigQuery

Para obtener más información sobre el proceso de exportación y de importación, consulta Exporta bases de datos y, también, Importa bases de datos.

¿Qué sigue?