Saltar al contenido
Excepciones en una replicación lógica

Excepciones en una replicación lógica

Cuando pensamos en replicación de datos en entornos críticos es necesario considerar las excepciones implícitas de las herramientas de replicación. Este artículo se enfoca en las consideraciones funcionales para una replicación lógica entre bases de datos Oracle, con independencia de sus versiones y ediciones; es decir, en un producto de tipo CDC (Change Data Capture), internamente basada en REDO LOGS. El software referido es SharePlex de Quest.

 

Es común que las herramientas de replicación utilicen sistemas de mensajerías que usan grafos FIFO (First In First Out), estructura de datos que permite mantener un orden cronológico, consistente y robusto de cambios como lo requieren las propiedades ACID (Atomicity, Consistency, Isolation, and Durability). Además, se lo suele complementar con marcas timestamp o SCN (System Change Number) del origen, así existe una trazabilidad que permite un análisis forense, de requerirse.

Resuelto lo anterior, el producto se debe enfocar en la captura de mensajes —en el origen— y la aplicación de estos —en el destino—.

Para la captura de mensajes se requiere que las operaciones sean visibles y, por tanto, detectables, lo que implica que la base de datos deba generar y forzar la generación de REDO a pesar de que existan atributos contrarios a ello (nologging).

Las operaciones deben ser visibles para ser detectadas

El motor de base de datos debe generar trazabilidad y persistencia de todos los cambios que ocurren. No obstante, existe un grupo de instrucciones o procesos que no generan REDO, sea por definición o por configuración:

  • Carga de datos con SQL*Loader: acceso directo sin pasar por el SGA.
  • Operaciones configuradas como NOLOGGING por el usuario.
  • Operaciones que cambien el entorno de la base de datos, tales como: modificación de parámetros de instancia, creación de datafiles, diskgroups, particiones, etcétera.

Las operaciones no deben utilizar un API para aplicarse

Este caso es bastante particular y tiene que ver con las operaciones en el motor relacional que invocan rutinas PL/SQL para administrarse. Las herramientas de replicación no realizarán su invocación en el destino porque Oracle —en el origen— no genera REDO relacionado a la invocación, sino a las modificaciones a los datos producto de la ejecución del API (Aplication Program Interface). Ejemplos:

  • Jobs y Schedules: Para los cuales se requiere el paquete DBMS_SCHEDULER.
  • Message Queuing o AQ Tables: Paquete DBMS_AQADM. Resulta ser más complejo aún porque las AQ Tables son tablas persistentes de la base de datos que se pueden replicar, pero su contenido no será reconocido por los procesos locales, ya que por su definición son mensajes en tránsito.

Las operaciones no pueden ser dinámicas

La mayoría de las herramientas de replicación se basan en definiciones estáticas de estructuras que se consultan en el diccionario; esto es, al detectar una operación se consulta el catálogo (diccionario) para extraer la definición y así replicarla; sin embargo, existen tipos de datos UDT (User-Defined Types) polimórficos que el usuario puede crear: un tipo de dato padre que hereda a sus hijas su contenido, características y métodos (orientación a objetos), de esta manera cada tipo de dato hijo puede agregar nuevas columnas particulares.

  • Definición de tipos de datos con polimorfismo: Al intentar replicar tablas con definición de tipos de datos padre, el proceso de captura consultará la definición de dicho tipo de dato y solo identificará los datos definidos en él, e ignorará los demás datos agregados por sus hijos que podrían viajar de manera dinámica.

Las operaciones que hacen referencia a objetos externos a la base de datos

Entre ellos:

  • Referencia a archivos externos: Se replica la referencia, pero no el archivo.
  • Interpretación de archivos planos como tablas: Muchas bases de datos permiten esta opción, pero al no replicar los archivos externos, se genera error al intentar acceder a dichas tablas en el destino.
  • En esta categoría también se podría incluir las operaciones que requieren configuración adicional en tnsnames; por ejemplo, database links.

Las operaciones no deben ser de índole administrativo

Las herramientas de replicación lógica operan como un cliente en los destinos, por ende, se requiere un usuario de base de datos para aplicar todas las operaciones que capturan en el origen. Si hablamos de operaciones de altos privilegios, el usuario en el destino deberá tener los mismos privilegios para ejecutarlas; sin embargo, no es buena práctica el utilizar usuarios con altos privilegios. Además, existen operaciones que ni siquiera un usuario con altos privilegios podría realizar.

Modificación de esquemas propietarios: Los cambios en los esquemas pueden darse por utilidades del motor de base de datos, upgrades, cambios de versiones.

  • Modificación de esquemas propietarios: Los cambios en los esquemas pueden darse por utilidades del motor de base de datos, upgrades, cambios de versiones.

Optimización del proceso de replicación

En su mayor parte, la replicación lógica utiliza un sistema de mensajes y colas que puede ser bastante transitado según la actividad de la base de datos, para optimizar el paso de mensajes, algunas herramientas de replicación no suelen replicar:

  • Tablas definidas en espacios temporales para la base de datos (temporary tablespaces)
  • Tablas con datos que se puedan identificar como una copia de otras tablas incluidas en la replicación.
  • Por configuración se pueden excluir acciones masivas como borrados de registros en cascada.

Lógica de las herramientas de replicación

Depende de la herramienta de replicación seleccionada; por ejemplo, en el caso de SharePlex, donde casi todo lo maneja como XML, no admitirá XML almacenado como OBJECT RELATIONAL, tendrá que ser almacenado como CLOB o BINARY.

Tipos de datos especiales

Esta clasificación es la más amplia porque depende de cada tipo de ambiente:

  • Tipos de datos genéricos ANYDATA: Solo se permite replicar aquellos tipos de datos simples (CHAR, DATE, NUMBER, RAW, VARCHAR, VARCHAR2, TIMESTAMP) o ANYDATA no polimórfico.
  • Tablas con tipos de datos complejos:
    • En el caso de LOB, BLOB, CLOB, se requiere una clave primaria. Si no se cuenta con una las herramientas de replicación intentarán crear una a partir de los tipos de datos simples. Lo recomendado es que cada tabla contenga, al menos, un tipo de dato simple para poder ser replicada.
    • No permite replicar tablas anidadas (nested tables) ni tampoco tablas tipo cluster (clustered tables).
  • Tipos de datos con compresión que requieren funcionalidades adicionales en su motor.
  • SharePlex admite LOB de SecureFiles de la siguiente manera:
    • El Logging debe estar habilitado.
    • Se admite SecureFiles LOBS sin comprimir y SecureFiles LOBS con compresión alta o media.
    • SecureFiles LOBS no se admite cuando la especificación de almacenamiento incluye cifrado y/o deduplicación.
  • Los tipos de datos mencionados corresponden a los que más frecuentemente generan tratamientos especiales. La lista no es completa porque las bases de datos continuamente incluyen nuevos tipos y funcionalidades.

En resumen, la replicación lógica Oracle-Oracle, con SharePlex de Quest, presenta diferentes tipos de desafíos que pueden ser muy específicos según la estrategia utilizada en la replicación, las características del ambiente, la versión del motor y el nivel de actividad de la base de datos, estos requieren una comprensión detallada/minuciosa/específica del funcionamiento de todos los componentes de Oracle para realizar una configuración óptima teniendo en cuenta sus limitaciones, las cuales no son tan frecuentes como parecen, es decir, son pocas las organizaciones que tienen este tipo de operaciones en sus bases de datos. Puntualmente SharePlex, es muy flexible en cuanto a configuración, es bastante optimizado en su funcionamiento, y permite detectar comportamientos muy específicos, por ejemplo, cuellos de botella en el destino, que al solucionarse pueden optimizar los ambientes productivos. Ello permite abordar los proyectos de replicación y migración con confianza. En TS4B, sabemos que cada desafío es una puerta abierta a nuevas posibilidades.

Si estás listo para dejar atrás las complicaciones y preparar tu negocio para el futuro: ¡Hablemos! Estamos aquí para ayudarte a crecer.

Autor

Carlos Andrés Ardila

Carlos Andrés Ardila

Co-fundador de TS4B, MBA, Project Management Spec, y con experiencia en todos los aspectos de la gestión de la seguridad de aplicaciones y proyectos. Actualmente se desempeña como Lider Servicios, entrega e implementación para TS4B. Trabajó durante los últimos 12 años en diferentes proyectos de consultoría, para una variedad de clientes en México, Panamá, Guatemala, República Dominicana, Colombia, Brasil, Chile y España, en proyectos de seguridad, tales como seguridad de aplicaciones, gestión de identidad, control de acceso, auditoría, alta disponibilidad, migración y administración.

Editor

Fernando Parra

Fernando Parra

Co-fundador de TS4B. Soporte técnico desde México hasta Chile en Oracle & SharPlex. Ex instructor de Oracle University (10 años). Ex docente de postgrado en UDLA (Universidad de las Américas, Quito-Ecuador). Ex colaborador de PNUD (Programa de las Naciones Unidas). Ex implementador y desarrollador de software bancario en Fisa Group (7 años).

Especialista certificado en base de datos Oracle (+30 años) con enfoque en:  Alta Disponibilidad, seguridad, contingencia, optimización, Audit Vault, Database Vault,  respaldo, recuperación, entre otros.

Ver más

 

Asesoría personalizada

Habla con un experto

¡Mantén tus sistemas y datos seguros con nuestras soluciones de seguridad de TI!

O también puedes escribirnos por WhatsApp

Noticias y artículos recomendados

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

×

Hola!

Habla con uno de nuestros representantes por WhatsApp o envíanos un correo a luisa.posada@ts4b.co

× ¿Cómo puedo ayudarte?