Thursday, October 14, 2010

Oracle Streams

Éste es un artículo interesante que he traducido. Tengo pendiente revisarlo para conseguir una coherencia más o menos cuerda de los conceptos.

Un "Oracle Stream", una nueva características de Oracle 9i R2, es una tecnología para compartir información, la cual permite la propagación y gestión de datos, eventos y transacciones dentro de bases de datos ya sean oracle a oracle ó oracle a No-oracle. Los Oracle Streams son flexibles en el sentido de que permiten la intervención del usuario - los usuarios pueden especificar qué información va dentro del stream, la ruta del flujo, qué ocurre con los eventos en el stream y cómo finaliza el mismo. Se emplea para capturar eventos como un Data Manipulation Language (DML), que son los INSERT, UPDATE y DELETE, y Data Definition Language (DDL), que son los ALTER, DROP y RENAME.

No obstante, muy fundamentales para el trabajo de un Oracle Stream son tres elementos/compònenetes. A saber:

  • Captura
  • Puesta en escena
  • Aplicación

Proceso de Captura

El proceso de captura es el responsable de la identificación de los datos a capturar tales como los cambios de la base de datos (DDL y DML) y mensajes generados por la aplicación. Podemos bien tener capturas implícitas las cuales el servidor captura eventos DDL y DML en la base de datos origen mediante las reglas por defecto de Oracle o, capturas explícitas, en las cuales una configuración personalizada es usada para capturar datos usando 'procedures'.

Además, el proceso de cambio formatea los datos recuperados dentro de eventos conocidos como 'Logical Change Records' (LCR) y que se sitúan en una querya - de ahora en adelante Staging Environment. Los cambios lógicos registrados son de dos tipos: DDL LCR y row LCR. Las DDL LCR se refieren a cambios hechos en los objetos de la base de datos por comandos como ALTER, RENAME, CREATE y DROP. Por otra parte, las Row LCR se refieren a modificaciones de una fila dentro de una tabla mediante una sentencia DML. Esto implica que actualizando 10 filas usando una única sentencia DML, se obtienen 10 row LCR's.

Proceso de Puesta en Escena (Staging)

La Staging Area es una cola y actúa como un repositorio temporal para los registros de cambios lógicos (LCR) hasta que son definitivamente suscritos. El suscriptor (un usuario de la aplicación u otra Staging Area ó proceso estándar) tiene el control sobre las Staging Areas. Por lo tanto, el suscriptor puede decidir que registros son propagados o consumidos desde la cola. Para la propagación de eventos desde una cola que tendrá lugar, un usuario debe ser el propietario de la cola y de los priviliegios necesitados que sean necesarios, no solamente en la cola origen sin también en la cola destino. Además. una cola destino particular puede aceptar eventos de más de una cola de origen.

Proceso de Aplicación

El Proceso de Aplicación es responsable de la aplicación de los cambios a la base de datos destino. Esto es posible de dos formas a saber- Default Consumption (implícito) y Customizen Consumption (explícito). El consumo por defecto, el engine que se aplica es usado para aplicar cambios directamente en la base de datos. Por aventurar, si ocurre un conflicto, el engine de la aplicación lo resuelve invocando rutinas de resolución (Data Transmision).

En la Customized Consumption,los registros de cambios lógicos (LCR) son pasados como argumentos a una función definida por el usuario para su procesamiento. Si el Procedure personalizado procesa DML LCRs, DDL LCRs y mensajes encolados, se les llama DML Handlers, DDL Handlers y Messages Handlers respectivamente.

Traducido de ORACLE STREAMS and ETL.

No comments:

Post a Comment