Diseño y rendimiento de las migraciones de Oracle

Este artículo es la primera parte de una serie de siete partes, que proporciona instrucciones sobre cómo migrar de Oracle a Azure Synapse Analytics. Este artículo se centra en los procedimientos recomendados para el diseño y el rendimiento.

Información general

Debido al costo y la complejidad de mantener y actualizar entornos de Oracle locales heredados, muchos usuarios existentes de Oracle desean aprovechar las innovaciones proporcionadas por los entornos de nube modernos. Los entornos en la nube de infraestructura como servicio (IaaS) y plataforma como servicio (PaaS) permiten delegar tareas como el mantenimiento de la infraestructura y el desarrollo de plataformas en el proveedor de nube.

Aunque Oracle y Azure Synapse Analytics son bases de datos SQL que usan técnicas de procesamiento paralelo masivo (MPP) con el fin de lograr un alto rendimiento de las consultas en volúmenes de datos excepcionalmente grandes, hay algunas diferencias básicas en cuanto al enfoque que utilizan:

• Los sistemas heredados de Oracle suelen estar instalados en el entorno local y usan hardware relativamente caro, mientras que Azure Synapse se basa en la nube y usa recursos de proceso y almacenamiento de Azure.

• La actualización de una configuración de Oracle es una tarea importante que supone hardware físico adicional y una reconfiguración o volcado y recarga de las bases de datos potencialmente grandes. Dado que los recursos de almacenamiento y de proceso son independientes en el entorno de Azure y tienen funcionalidad de escalado elástico, se pueden escalar o reducir verticalmente de manera independiente.

• Puede pausar o cambiar el tamaño de Azure Synapse según sea necesario para reducir el costo y el uso de recursos.

Microsoft Azure es un entorno en la nube escalable, muy seguro, está disponible en todo el mundo e incluye Azure Synapse y un ecosistema de herramientas y funcionalidades complementarias. En el siguiente diagrama, se resume el ecosistema de Azure Synapse.

Azure Synapse proporciona el mejor rendimiento de las bases de datos relacionales gracias al uso de técnicas como MPP y el almacenamiento en caché automático en memoria. Puede ver los resultados de estas técnicas en puntos de referencia independientes, como el ejecutado recientemente por GigaOm, que compara Azure Synapse con otras ofertas conocidas de almacenamiento de datos en la nube. Los clientes que migran al entorno de Azure Synapse se benefician de muchas ventajas, entre las que se incluyen:

• Rendimiento y relación precio/rendimiento mejorados.

• Mayor agilidad y tiempo de rentabilidad menor.

• Implementación de servidores y desarrollo de aplicaciones más rápidos.

• Escalabilidad elástica: solo se paga por el uso real.

• Mayor seguridad y cumplimiento.

• Costos reducidos de almacenamiento y recuperación ante desastres.

• Menor TCO global, mejor control de costos y gastos de funcionamiento (OPEX) optimizados.

Para maximizar estas ventajas, migre los datos y aplicaciones existentes o nuevos a la plataforma Azure Synapse. En muchas organizaciones, este enfoque incluye la migración de un almacenamiento de datos existente desde una plataforma local heredada, como Oracle, a Azure Synapse. A grandes rasgos, el proceso de migración incluye los siguientes pasos:

En este artículo, se proporciona información general y directrices para la optimización del rendimiento al migrar un almacenamiento de datos desde un entorno de Oracle existente a Azure Synapse. El objetivo de la optimización del rendimiento es lograr el mismo o mejor rendimiento del almacenamiento de datos en Azure Synapse después de la migración.

Consideraciones de diseño

Ámbito de la migración

Cuando esté preparando la migración desde un entorno de Oracle, tenga en cuenta las siguientes opciones de migración.

Elección de la carga de trabajo para la migración inicial

Normalmente, los entornos heredados de Oracle han evolucionado con el tiempo para abarcar varias áreas temáticas y cargas de trabajo mixtas. Al decidir por dónde empezar en un proyecto de migración inicial, elija un área en la que pueda hacer lo siguiente:

• Demostrar la viabilidad de la migración a Azure Synapse con la obtención de beneficios rápidos del nuevo entorno.

• Permitir que el personal técnico interno obtenga experiencia pertinente con los procesos y herramientas que usarán al migrar otras áreas.

• Crear una plantilla para migraciones adicionales que sea específica del entorno de origen de Oracle y de las herramientas y los procesos actuales que ya están en funcionamiento.

Un buen candidato para una migración inicial desde un entorno de Oracle admite los elementos anteriores y además:

• Implementa una carga de trabajo de BI y análisis en lugar de una carga de trabajo de procesamiento de transacciones en línea (OLTP).

• Tiene un modelo de datos, como un esquema de estrella o copo de nieve, que se puede migrar con una modificación mínima.

El volumen de datos migrados en una migración inicial debe ser lo suficientemente grande como para demostrar las funcionalidades y ventajas del entorno de Azure Synapse, pero no demasiado grande para demostrar rápidamente el valor. Un tamaño en el intervalo de 1 a 10 terabytes es lo habitual.

Un enfoque inicial de un proyecto de migración es minimizar el riesgo, el esfuerzo y el tiempo necesarios para que vea rápidamente las ventajas del entorno en la nube de Azure. Los siguientes enfoques limitan el ámbito de la migración inicial a solo los data marts y no abordan aspectos de migración más amplios, como la migración de ETL y la migración de datos históricos. Sin embargo, puede abordar esos aspectos en fases posteriores del proyecto una vez que la capa de data mart migrada se rellene con los datos y los procesos de compilación necesarios.

Migración mediante lift-and-shift frente al enfoque por fases

En general, hay dos tipos de migración independientemente del propósito y el ámbito de la migración planeada: lift-and-shift tal cual y un enfoque por fases que incorpora cambios.

migración mediante lift-and-shift

En una migración mediante lift-and-shift, un modelo de datos existente, como un esquema de estrella, se migra sin cambios a la nueva plataforma de Azure Synapse. Este enfoque minimiza el riesgo y el tiempo necesario para la migración reduciendo el trabajo necesario para lograr las ventajas de migrar al entorno en la nube de Azure. La migración mediante lift-and-shift es una buena opción para estos escenarios:

• Tiene un entorno de Oracle existente con un único data mart para migrar, o bien
• Tiene un entorno de Oracle existente con datos que ya están en un esquema de estrella o copo de nieve bien diseñado, o bien
• Está afectado por limitaciones de tiempo y dinero para pasar a un entorno en la nube moderno.

Estrategia por fases que incorpora cambios

Si un almacén heredado ha evolucionado con el tiempo, es posible que tenga que volver a diseñarlo para mantener el rendimiento necesario. También es posible que tenga que volver a diseñar para admitir nuevos datos, como los flujos de Internet de las cosas (IoT). Migre a Azure Synapse para obtener las ventajas de un entorno en la nube escalable como parte del proceso de reingeniería. La migración puede incluir un cambio en el modelo de datos subyacente; por ejemplo, pasar de un modelo Inmon a un almacén de datos.

Microsoft recomienda trasladar el modelo de datos actual tal y como está a Azure y usar el rendimiento y la flexibilidad del entorno de Azure para aplicar los cambios del nuevo diseño. De este modo, puede usar las funcionalidades de Azure para realizar los cambios sin afectar al sistema de origen existente.

Uso de las utilidades de Microsoft para implementar una migración controlada por metadatos

Puede automatizar y orquestar el proceso de migración mediante las funcionalidades del entorno de Azure. Este enfoque minimiza el impacto en el rendimiento en el entorno de Oracle existente, que es posible que ya funcione casi a plena capacidad.

SQL Server Migration Assistant (SSMA) para Oracle puede automatizar muchas partes del proceso de migración, incluidas, en algunos casos, el código de las funciones y los procedimientos. SSMA admite Azure Synapse como entorno de destino.

SQL Server Migration Assistant le puede ayudar a migrar un almacenamiento de datos o un data mart de Oracle en Azure Synapse. SQL Server Migration Assistant está diseñado para automatizar el proceso de migración de tablas, vistas y datos desde un entorno de Oracle existente.

Azure Data Factory es un servicio de integración de datos basado en la nube que permite crear flujos de trabajo basados en datos en la nube a fin de orquestar y automatizar el movimiento y la transformación de los datos. Con Azure Data Factory puede crear y programar flujos de trabajo basados en datos (llamados canalizaciones) que ingieren datos de distintos almacenes de datos. Data Factory puede procesar y transformar datos mediante servicios de proceso, como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics y Azure Machine Learning.

Se puede usar Data Factory para migrar datos en el origen al destino de Azure SQL. Este movimiento de datos sin conexión ayuda a reducir significativamente el tiempo de inactividad de la migración.

Azure Database Migration Service puede ayudar a planear y realizar una migración desde entornos como Oracle.

Cuando planee usar las utilidades de Azure para administrar el proceso de migración, cree metadatos que enumeren todas las tablas de datos que se van a migrar y su ubicación.

Diferencias de diseño entre Oracle y Azure Synapse

Como se mencionó anteriormente, hay algunas diferencias básicas en el enfoque entre las bases de datos de Oracle y Azure Synapse Analytics. SSMA para Oracle no solo ayuda a salvar estas brechas, sino que también automatiza la migración. Aunque SQL Server Migration Assistant no será la estrategia más eficaz para grandes volúmenes de datos, resulta útil en el caso de tablas más pequeñas.

Varias bases de datos frente a esquemas y bases de datos únicas

El entorno de Oracle suele contener varias bases de datos independientes. Por ejemplo, podría haber bases de datos independientes para: tablas de ingesta y almacenamiento provisional de datos, tablas de almacenamiento principal y data marts (a veces llamada capa semántica). Los procesos de canalización de ETL o ELT pueden implementar combinaciones entre bases de datos y mover datos entre las bases de datos independientes.

Por otro lado, el entorno de Azure Synapse tiene una sola base de datos y se usan esquemas para separar las tablas en grupos lógicamente distintos. Se recomienda usar una serie de esquemas en la base de datos de Azure Synapse de destino para imitar las bases de datos independientes migradas desde el entorno de Oracle. Si ya se usan esquemas en el entorno de Oracle, es posible que sea necesario utilizar una nueva convención de nomenclatura para trasladar las tablas y vistas de Oracle existentes al nuevo entorno. Por ejemplo, podría concatenar los nombres de tabla y esquema de Oracle existentes en el nuevo nombre de tabla de Azure Synapse y, luego, usar nombres de esquema del nuevo entorno para mantener los nombres originales de las bases de datos independientes. Puede usar vistas SQL en las tablas subyacentes para mantener las estructuras lógicas, pero este enfoque presenta algunas posibles desventajas:

• Las vistas de Azure Synapse son de solo lectura, por lo que toda actualización de los datos debe realizarse en las tablas base subyacentes.

• Puede que ya existan una o varias capas de vistas, y agregar una adicional podría afectar al rendimiento.

Consideraciones sobre las tablas

Al migrar tablas entre distintos entornos, normalmente solo los datos sin procesar y los metadatos que lo describen migran físicamente. Otros elementos de base de datos del sistema de origen, como los índices, normalmente no se migran porque podrían ser innecesarios o implementados de forma diferente en el nuevo entorno.

Las optimizaciones de rendimiento en el entorno de origen, como los índices, indican dónde puede agregar la optimización del rendimiento en el nuevo entorno. Por ejemplo, si las consultas del entorno de Oracle de origen usan con frecuencia índices de mapa de bits, puede indicar que se debe crear un índice no agrupado en Azure Synapse. Otras técnicas de optimización del rendimiento nativas, como la replicación de tablas, pueden ser más adecuadas que la creación directa de un índice equivalente. SSMA para Oracle se puede usar para proporcionar recomendaciones de migración para la distribución y la indexación de tablas.

Tipos de objetos de base de datos de Oracle no admitidos

A menudo, las características específicas de Oracle se pueden reemplazar por características de Azure Synapse. Sin embargo, algunos objetos de base de datos de Oracle no se admiten directamente en Azure Synapse. En la siguiente lista de objetos de base de datos de Oracle no admitidos, se describe cómo se puede lograr una funcionalidad equivalente en Azure Synapse.

• Varias opciones de indexación: en Oracle, varias opciones de indexación, como los índices de mapa de bits, los índices basados en funciones y los índices de dominio, no tienen ningún equivalente directo en Azure Synapse.

  Para averiguar qué columnas están indexadas y el tipo de índice, haga lo siguiente:

  • Consultar las vistas y tablas del catálogo del sistema, como ALL_INDEXES, DBA_INDEXES, USER_INDEXES y DBA_IND_COL. Puede usar las consultas integradas en Oracle SQL Developer, como se muestra en la captura de pantalla siguiente.

    

    O bien, ejecute la siguiente consulta para buscar todos los índices de un tipo determinado:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Consultar las vistas dba_index_usage o v$object_usage cuando la supervisión está habilitada. Puede consultar esas vistas en Oracle SQL Developer, como se muestra en la captura de pantalla siguiente.

    

  Los índices basados en funciones, en los que el índice contiene el resultado de una función en las columnas de datos subyacentes, no tienen ningún equivalente directo en Azure Synapse. Se recomienda migrar primero los datos y, a continuación, ejecutar en Azure Synapse las consultas de Oracle que usan índices basados en funciones para medir el rendimiento. Si el rendimiento de esas consultas en Azure Synapse no es aceptable, considere la posibilidad de crear una columna que contenga el valor calculado previamente y, a continuación, indexar esa columna.

  Al configurar el entorno de Azure Synapse, tiene sentido implementar solo los índices en uso. Actualmente, Azure Synapse admite los tipos de índice que se muestran aquí:

  

  Con las características de Azure Synapse, como el procesamiento paralelo de consultas y el almacenamiento en caché en memoria de los datos y los resultados, es probable que se necesiten menos índices para que las aplicaciones de almacenamiento de datos logren los objetivos de rendimiento. Se recomienda usar los siguientes tipos de índice en Azure Synapse:

  • Índices de almacén de columnas agrupados: cuando no se especifican opciones de índice para una tabla, Azure Synapse crea de manera predeterminada un índice de almacén de columnas agrupado. Las tablas de almacén de columnas agrupadas ofrecen el mayor nivel de compresión de datos, el mejor rendimiento general de las consultas y, por lo general, superan el rendimiento de los índices agrupados o las tablas de montón. Un índice de almacén de columnas agrupado suele ser la mejor opción para tablas grandes. Al crear una tabla, elija la opción de almacén de columnas agrupado si no está seguro de cómo indexar la tabla. Sin embargo, hay algunos escenarios en los que los índices de almacén de columnas agrupados no son la mejor opción:

    • Las tablas con datos de ordenación previa en una clave de ordenación podrían beneficiarse de la eliminación del segmento habilitada por los índices de almacén de columnas agrupados ordenados.
    • Las tablas con tipos de datos varchar(max), nvarchar(max) o varbinary(max), porque un índice de almacén de columnas agrupado no admite esos tipos de datos. En su lugar, considere la posibilidad de usar un índice de montón o un índice agrupado.
    • Las tablas con datos transitorios, ya que las tablas de almacén de columnas pueden ser menos eficaces que las tablas de montón o temporales.
    • Tablas pequeñas con menos de 100 millones de filas. En su lugar, considere la posibilidad de usar tablas de montón.

  • Índices de almacén de columnas agrupados ordenados: al habilitar la eliminación eficaz de segmentos, los índices de almacén de columnas agrupados ordenados en grupos de SQL dedicados de Azure Synapse proporcionan un rendimiento mucho más rápido omitiendo grandes cantidades de datos ordenados que no coinciden con el predicado de consulta. La carga de datos en una tabla de CCI ordenado puede tardar más que en una tabla de CCI no ordenado debido a la operación de ordenación de datos; sin embargo, posteriormente las consultas podrán ejecutarse más rápidamente con el CCI ordenado. Para más información sobre los índices de almacén de columnas agrupados ordenados, consulte Optimización del rendimiento con el índice de almacén de columnas agrupado ordenado.

  • Índices agrupados y no agrupados: los índices agrupados pueden superar el rendimiento de los índices de almacén de columnas agrupados cuando es necesario recuperar rápidamente una sola fila. En el caso de las consultas en las que hay una búsqueda de una sola fila, o solo algunas búsquedas de filas, que deben realizarse a una velocidad extrema, considere la posibilidad de usar un índice agrupado o un índice secundario no agrupado. La desventaja de utilizar un índice agrupado es que solo se beneficiarán las consultas que utilicen un filtro muy selectivo en la columna del índice agrupado. Para mejorar el filtrado por otras columnas, puede agregar un índice no agrupado a las otras columnas. Sin embargo, cada índice que agregue a una tabla usa más espacio y aumenta el tiempo de procesamiento para la carga.

  • Tablas de montón: al aterrizar temporalmente datos en Azure Synapse, es posible que el uso de una tabla de montón haga que el proceso general sea más rápido. Esto se debe a que cargar datos en tablas de montón es más rápido que cargar datos en tablas de índice y, en algunos casos, las lecturas posteriores se pueden realizar desde la memoria caché. Si solo va a cargar datos para almacenarlos temporalmente, es mucho más rápido cargarlos en una tabla de montón que en una tabla de almacén de columnas agrupada. Además, la carga de datos en una tabla temporal es una operación mucho más rápida que la carga de una tabla en un almacenamiento permanente. En el caso de tablas de búsqueda pequeñas con menos de 100 millones de filas, las tablas de montón suelen ser la opción adecuada. Las tablas de almacén de columnas agrupadas empiezan a lograr una compresión óptima cuando hay más de 100 millones de filas.

• Tablas agrupadas: las tablas de Oracle se pueden organizar para que las filas de la tabla a las que se accede con frecuencia (en función de un valor común) se almacenen físicamente juntas para reducir la E/S de disco cuando se recuperan los datos. Oracle también proporciona una opción de agrupación con hash para tablas individuales, que aplica un valor hash a la clave del clúster y almacena físicamente juntas las filas con el mismo valor hash. Para enumerar los clústeres de una base de datos de Oracle, use la consulta SELECT * FROM DBA_CLUSTERS;. Para determinar si una tabla está dentro de un clúster, use la consulta SELECT * FROM TAB;, que muestra el nombre de la tabla y el identificador de clúster de cada tabla.

  En Azure Synapse, puede lograr resultados similares mediante tablas materializadas o replicadas, ya que esos tipos de tabla minimizan la E/S necesaria en tiempo de ejecución de la consulta.

• Vistas materializadas: Oracle admite vistas materializadas y recomienda usar una o varias de estas vistas en tablas grandes que tengan muchas columnas si solo algunas columnas se usan con frecuencia en las consultas. El sistema actualiza las vistas materializadas automáticamente cuando se actualizan los datos de la tabla base.

  En 2019, Microsoft anunció que Azure Synapse admitirá vistas materializadas con la misma funcionalidad que Oracle. Las vistas materializadas ahora son una característica en versión preliminar en Azure Synapse.

• Desencadenadores en la base de datos: en Oracle, se puede configurar un desencadenador para que se ejecute automáticamente cuando se produce un evento desencadenador. Los eventos desencadenadores pueden ser:

  • Se ejecuta en una tabla una instrucción del lenguaje de manipulación de datos (DML), como INSERT, UPDATEo DELETE. Si ha definido un desencadenador que se activa antes de una instrucción INSERT en una tabla de cliente, el desencadenador se activará una vez antes de insertar una nueva fila en la tabla del cliente.

  • Se ejecuta una instrucción DDL, como CREATE o ALTER. Este desencadenador se suele usar con fines de auditoría para registrar los cambios de esquema.

  • Un evento del sistema, como el inicio o apagado de la base de datos de Oracle.

  • Un evento de usuario, como el inicio de sesión o el cierre de sesión.

  Puede obtener una lista de los desencadenadores definidos en una base de datos de Oracle consultando las vistas ALL_TRIGGERS, DBA_TRIGGERS o USER_TRIGGERS. En la captura de pantalla siguiente, se muestra una consulta de DBA_TRIGGERS en Oracle SQL Developer.

  

  Azure Synapse no admite desencadenadores de base de datos de Oracle. Sin embargo, puede agregar una funcionalidad equivalente mediante Data Factory, aunque si lo hace, tendrá que refactorizar los procesos que usan desencadenadores.

• Sinónimos: Oracle admite la definición de sinónimos como nombres alternativos para varios tipos de objetos de base de datos. Estos tipos de objeto incluyen: tablas, vistas, secuencias, procedimientos, funciones almacenadas, paquetes, vistas materializadas, objetos de esquema de clase de Java, objetos definidos por el usuario u otro sinónimo.

  Azure Synapse no admite actualmente la definición de sinónimos, aunque si un sinónimo de Oracle hace referencia a una tabla o vista, puede definir una vista en Azure Synapse para que coincida con el nombre alternativo. Si un sinónimo de Oracle hace referencia a una función o procedimiento almacenado, en Azure Synapse puede crear otra función o procedimiento almacenado con un nombre que coincida con el sinónimo que llame al destino.

• Tipos definidos por el usuario: Oracle admite objetos definidos por el usuario que pueden contener una serie de campos individuales, cada uno con su propia definición y valores predeterminados. A continuación, se puede hacer referencia a esos objetos en una definición de tabla de la misma manera que los tipos de datos integrados, como NUMBER o VARCHAR. Puede obtener una lista de los tipos definidos por el usuario en una base de datos de Oracle consultando las vistas ALL_TYPES, DBA_TYPES o USER_TYPES.

  Azure Synapse no admite actualmente tipos definidos por el usuario. Si los datos que tiene que migrar incluyen tipos de datos definidos por el usuario, puede "aplanarlos" en una definición de tabla convencional o, si son matrices de datos, normalizarlos en una tabla independiente.

Asignación de tipos de datos para Oracle

La mayoría de los tipos de datos de Oracle tienen un equivalente directo en Azure Synapse. En la tabla siguiente, se muestra el enfoque recomendado para asignar los tipos de datos de Oracle a Azure Synapse.

Oracle también admite objetos definidos por el usuario que pueden contener una serie de campos individuales, cada uno con su propia definición y valores predeterminados. A continuación, se puede hacer referencia a esos objetos dentro de una definición de tabla de la misma manera que los tipos de datos integrados, como NUMBER o VARCHAR. Azure Synapse no admite actualmente tipos definidos por el usuario. Si los datos que tiene que migrar incluyen tipos de datos definidos por el usuario, puede "aplanarlos" en una definición de tabla convencional o, si son matrices de datos, normalizarlos en una tabla independiente.

Hay proveedores de terceros que ofrecen herramientas y servicios para automatizar la migración, incluida la asignación de tipos de datos. Si ya se utiliza una herramienta de ETL de terceros en el entorno de Oracle, utilice dicha herramienta para implementar cualquier transformación de datos necesaria.

Diferencias de sintaxis de DML de SQL

Existen diferencias de sintaxis de DML de SQL entre Oracle SQL y Azure Synapse T-SQL. Estas diferencias se describen detalladamente en Minimización de los problemas de SQL para migraciones de Oracle. En algunos casos, puede automatizar la migración de DML mediante herramientas de Microsoft como SSMA para Oracle y Azure Database Migration Service, o productos y servicios de migración de terceros.

Funciones, procedimientos almacenados y secuencias

Al migrar un almacenamiento de datos de un entorno consolidado como Oracle, probablemente tenga que migrar elementos que no sean tablas y vistas simples. Compruebe si las herramientas del entorno de Azure pueden reemplazar la funcionalidad de funciones, procedimientos almacenados y secuencias, ya que normalmente es más eficaz usar herramientas integradas de Azure que volver a codificarlos para Azure Synapse.

Como parte de la fase de preparación, cree un inventario de objetos que se deban migrar, defina un método para controlarlos y asigne los recursos adecuados en el plan de migración.

Las herramientas de Microsoft, como SSMA para Oracle y Azure Database Migration Service, o los servicios y productos de migración de terceros, pueden automatizar la migración de funciones, procedimientos almacenados y secuencias.

En las secciones siguientes, se describe aún más la migración de funciones, procedimientos almacenados y secuencias.

Functions

Al igual que en la mayoría de los productos de base de datos, Oracle admite funciones del sistema y funciones definidas por el usuario en una implementación de SQL. Al migrar una plataforma de base de datos heredada a Azure Synapse, las funciones comunes del sistema normalmente se pueden migrar sin cambios. Algunas funciones del sistema pueden tener una sintaxis ligeramente diferente, pero se pueden automatizar los cambios necesarios. Puede obtener una lista de funciones de una base de datos de Oracle consultando la vista ALL_OBJECTS con la cláusula WHERE adecuada. Puede usar Oracle SQL Developer para obtener una lista de funciones, como se muestra en la captura de pantalla siguiente.

En el caso de las funciones del sistema de Oracle o funciones arbitrarias definidas por el usuario que no tienen ningún equivalente en Azure Synapse, vuelva a codificar esas funciones mediante un lenguaje del entorno de destino. El código de las funciones definidas por el usuario de Oracle se crea en PL/SQL, Java o C. Azure Synapse usa el lenguaje Transact-SQL para implementar las funciones definidas por el usuario.

Procedimientos almacenados

La mayoría de los productos de base de datos modernos permite almacenar los procedimientos en la base de datos. Oracle proporciona el lenguaje PL/SQL para este fin. Normalmente, un procedimiento almacenado contiene instrucciones SQL y lógica de procedimiento, y puede devolver datos o un estado. Puede obtener una lista de procedimientos almacenados de una base de datos de Oracle consultando la vista ALL_OBJECTS con la cláusula WHERE adecuada. Puede usar Oracle SQL Developer para obtener una lista de procedimientos almacenados, como se muestra en la siguiente captura de pantalla.

Azure Synapse admite procedimientos almacenados mediante T-SQL, por lo que debe volver a codificar los procedimientos almacenados migrados en ese lenguaje.

Secuencias

En Oracle, una secuencia es un objeto de base de datos con nombre creado con CREATE SEQUENCE. Una secuencia proporciona valores numéricos únicos mediante los métodos CURRVAL y NEXTVAL. Puede usar los números únicos generados como valores de clave suplente para las claves principales.

Azure Synapse no implementa CREATE SEQUENCE, pero puede implementar secuencias mediante columnas IDENTITY o código SQL que genera el siguiente número de secuencia de una serie.

Extracción de metadatos y datos de un entorno de Oracle

Generación del lenguaje de definición de datos

El estándar ANSI SQL define la sintaxis básica para los comandos DDL (Lenguaje de definición de datos). Algunos comandos DDL, como CREATE TABLE y CREATE VIEW, son comunes tanto a Oracle como a Azure Synapse, pero también proporcionan características específicas de la implementación, como la indexación, la distribución de tablas y las opciones de creación de particiones.

Puede editar los scripts con CREATE TABLE y CREATE VIEW de Oracle existentes para lograr definiciones equivalentes en Azure Synapse. Para ello, es posible que tenga que usar tipos de datos modificados y quitar o modificar cláusulas específicas de Oracle, como TABLESPACE.

En el entorno de Oracle, las tablas del catálogo del sistema especifican la definición de vista y tabla actual. A diferencia de la documentación mantenida por el usuario, la información del catálogo del sistema siempre está completa y sincronizada con las definiciones de tabla actuales. Puede acceder a la información del catálogo del sistema mediante utilidades como Oracle SQL Developer. Oracle SQL Developer puede generar instrucciones DDL CREATE TABLE que puede editar para crear tablas equivalentes en Azure Synapse.

O bien, puede usar SSMA para Oracle para migrar tablas de un entorno de Oracle existente a Azure Synapse. SSMA para Oracle aplicará las asignaciones de tipos de datos adecuadas y los tipos de tabla y distribución recomendados, como se muestra en la captura de pantalla siguiente.

También puede usar herramientas de ETL y migración de terceros que procesan la información del catálogo del sistema para lograr resultados similares.

Extracción de datos de Oracle

Puede extraer datos de tabla sin procesar de las tablas de Oracle a archivos delimitados planos, como archivos CSV, mediante utilidades estándar de Oracle como Oracle SQL Developer, SQL*Plus y SCLcl. Después, puede comprimir los archivos delimitados planos mediante gzip y cargar los archivos comprimidos en Azure Blob Storage mediante AzCopy o herramientas de transporte de datos de Azure, como Azure Data Box.

Extraiga los datos de la tabla de la forma más eficaz posible, especialmente al migrar tablas de hechos grandes. Para las tablas de Oracle, use el paralelismo para maximizar el rendimiento de extracción. Puede lograr el paralelismo mediante la ejecución de varios procesos que extraen individualmente segmentos discretos de datos o mediante herramientas capaces de automatizar la extracción en paralelo mediante la creación de particiones.

Si hay suficiente ancho de banda de red disponible, puede extraer los datos de un sistema de Oracle local directamente en tablas de Azure Synapse o Azure Blob Data Storage. Para ello, use procesos de Data Factory, Azure Database Migration Service o productos de migración de datos o de ETL de terceros.

Los archivos de datos extraídos deben contener texto delimitado en formato CSV, Optimized Row Columnar (ORC) o Parquet.

Para obtener más información sobre la migración de datos y ETL desde un entorno de Oracle, consulte Migración de datos, ETL y carga para migraciones de Oracle.

Recomendaciones de rendimiento para migraciones de Oracle

El objetivo de la optimización del rendimiento es obtener el mismo o mejor rendimiento del almacenamiento de datos después de la migración a Azure Synapse.

Similitudes en los conceptos del enfoque de optimización del rendimiento:

Muchos conceptos de optimización del rendimiento para las bases de datos de Oracle son válidos para las bases de datos de Azure Synapse. Por ejemplo:

• Utilice la distribución de datos para colocar conjuntamente los datos que se van a combinar en el mismo nodo de procesamiento.

• Utilice el tipo de datos más pequeño para una columna determinada para ahorrar espacio de almacenamiento y acelerar el procesamiento de las consultas.

• Asegúrese de que las columnas que se van a combinar tengan el mismo tipo de datos para optimizar el procesamiento de las combinaciones y reducir la necesidad de transformaciones de datos.

• Para ayudar al optimizador a generar el mejor plan de ejecución, asegúrese de que las estadísticas estén actualizadas.

• Supervise el rendimiento mediante las funcionalidades de base de datos integradas para asegurarse de que los recursos se usen de forma eficaz.

Diferencias en el enfoque de optimización del rendimiento

En esta sección, se tratan las diferencias de implementación de nivel inferior entre Oracle y Azure Synapse para el ajuste del rendimiento.

Opciones de distribución de datos

Para el rendimiento, Azure Synapse se diseñó con arquitectura de varios nodos y usa el procesamiento en paralelo. Para optimizar el rendimiento de las tablas en Azure Synapse, puede definir una opción de distribución de datos en las instrucciones CREATE TABLE mediante la instrucción DISTRIBUTION. Por ejemplo, puede especificar una tabla distribuida por hash, que distribuye las filas de la tabla entre nodos de proceso mediante una función hash determinista. Muchas implementaciones de Oracle, especialmente los sistemas locales más antiguos, no admiten esta característica.

A diferencia de Oracle, Azure Synapse admite combinaciones locales entre una tabla pequeña y una tabla grande mediante la replicación de la tabla pequeña. Por ejemplo, considere una tabla de dimensiones pequeña y una tabla de hechos grande en un modelo de esquema en estrella. Azure Synapse puede replicar la tabla de dimensiones más pequeña en todos los nodos para asegurarse de que el valor de cualquier clave de combinación para la tabla grande tenga una fila de dimensión disponible localmente coincidente. La sobrecarga de replicación de tablas de dimensiones es relativamente baja para una tabla de dimensiones pequeña. En el caso de las tablas de dimensiones grandes, un enfoque de distribución hash es más adecuado. Para obtener más información sobre las opciones de distribución de datos, consulte Instrucciones de diseño para el uso de tablas replicadas en un grupo de Synapse SQL y Guía de diseño de tablas distribuidas mediante un grupo de SQL dedicado en Azure Synapse Analytics.

La distribución hash se puede aplicar en varias columnas para una distribución más uniforme de la tabla base. La distribución de varias columnas le permitirá elegir hasta ocho columnas para la distribución. Esto no solo reduce la asimetría de datos a lo largo del tiempo, sino que también mejora el rendimiento de las consultas.

Asesor de distribución

En Azure Synapse SQL, se puede personalizar la forma en que se distribuye cada tabla. La estrategia de distribución de tablas afecta considerablemente al rendimiento de las consultas.

El asesor de distribución es una nueva característica de Synapse SQL que analiza las consultas y recomienda las mejores estrategias de distribución para las tablas con el fin de mejorar el rendimiento de las consultas. Puede proporcionar las consultas que el asesor debe tener en cuenta o extraerlas de las consultas históricas disponibles en la DMV.

Para más información y ejemplos sobre cómo usar el asesor de distribución, consulte Asesor de distribución de Azure Synapse SQL.

Indexación de datos

Azure Synapse admite varias opciones de indexación definibles por el usuario que tienen una operación y un uso diferentes en comparación con los mapas de zona administrados por el sistema de Oracle. Para obtener más información sobre las distintas opciones de indexación en Azure Synapse, consulte Indexaciones de tablas en un grupo de SQL dedicado en Azure Synapse Analytics.

Las definiciones de índices de un entorno de Oracle de origen proporcionan indicaciones útiles del uso de los datos y las columnas candidatas para la indexación en el entorno de Azure Synapse. Normalmente, no es necesario migrar todos los índices de un entorno heredado de Oracle porque Azure Synapse no depende en exceso de los índices e implementa las siguientes características para lograr un rendimiento excepcional:

• Procesamiento en paralelo de consultas.

• Almacenamiento en caché en memoria de los datos y el conjunto de resultados.

• Distribución de datos, como la replicación de tablas de dimensiones pequeñas, para reducir la E/S.

Creación de particiones de datos

En un almacenamiento de datos empresarial, las tablas de hechos pueden contener miles de millones de filas. La creación de particiones optimiza el mantenimiento y las consultas de estas tablas al dividirlas en partes independientes para reducir la cantidad de datos que se procesan. En Azure Synapse, la especificación de creación de particiones de una tabla se define en la instrucción CREATE TABLE.

En la creación de particiones, solo se puede usar un campo por tabla. Suele ser un campo de fecha, porque muchas consultas se filtran por fecha o por intervalo de fechas. Puede cambiar la creación de particiones de una tabla después de la carga inicial; para ello, vuelva a crear la tabla con la nueva distribución mediante la instrucción CREATE TABLE AS (CTAS). Para obtener una explicación detallada de la creación de particiones en Azure Synapse, consulte Creación de particiones de tablas en el grupo de SQL dedicado.

PolyBase o COPY INTO para la carga de datos

PolyBase admite la carga eficaz de grandes cantidades de datos en un almacenamiento de datos mediante flujos de carga paralelos. Para más información, consulte Estrategia de carga de datos de PolyBase.

COPY INTO también admite la ingesta de datos de alto rendimiento y:

• Recuperación de datos de todos los archivos dentro de una carpeta y subcarpetas.
• Recuperación de datos desde varias ubicaciones en la misma cuenta de almacenamiento. Puede especificar varias ubicaciones mediante rutas de acceso separadas por comas.
• Azure Data Lake Storage (ADLS) y Azure Blob Storage.
• Formatos de archivo CSV, PARQUET y ORC.

Administración de cargas de trabajo

La ejecución de cargas de trabajo mixtas puede suponer desafíos de recursos en sistemas ocupados. Un esquema de administración de cargas de trabajo correcto administra los recursos de manera eficaz, garantiza un uso de recursos muy eficaz y maximiza la rentabilidad de la inversión (ROI). Los valores de clasificación de la carga de trabajo, importancia de la carga de trabajo y aislamiento de la carga de trabajo proporcionan más control sobre cómo la carga de trabajo utiliza los recursos del sistema.

La guía de administración de cargas de trabajo describe las técnicas para analizar la carga de trabajo y administrar y supervisar la importancia de la carga de trabajo, junto con los pasos necesarios para convertir una clase de recurso en un grupo de cargas de trabajo. Use Azure Portal y las consultas de T-SQL en DMV para supervisar la carga de trabajo para asegurarse de que los recursos aplicables se usan de forma eficaz.

Pasos siguientes

Para obtener más información sobre ETL y carga para la migración de Oracle, consulte el siguiente artículo de esta serie: Migración de datos, ETL y carga para migraciones de Oracle.