La replicación es el proceso de compartir objetos y datos de bases de datos en múltiples bases de datos. Los datos y los objetos de la base de datos se mantienen sincronizados en todas las bases de datos en el entorno de replicación. En un entorno de replicación de Streams, la base de datos donde se origina un cambio se denomina base de datos fuente, y una base de datos donde se comparte un cambio se denomina base de datos de destino.
Podemos replicar DDL y/o DML, para esto necesitamos hacer los siguientes pasos:
1.Capturar un cambio o un conjunto de cambios (logical change records o LCRs) y encolarlo en la cola dentro de la cola de cambios. Un LCR es mensaje con un formato determinado que especifica un cambio. EL LCR encapsula los cambios a realizar.
2.Propagar el LRC a otras colas, es decir a otras base de datos.
3.Aplicar el LRC a la base destino, esto se puede hacer desde la cola o de forma directa tambien.
Por lo tanto los pasos 1 y 3 son obligatorios y el 2 es opcional dado que se puede aplicar el LRC de forma directa.
A la vez tenemos reglas de replicación, una regla indica una acción cuando ocurre un evento y si se cumple una condición. Las reglas son evaluadas por el motor de reglas de oracle. Cada uno de los siguientes pasos son ejecutados por un motor de reglas:
- Captura de proceso
- Propagación
- Aplicar proceso
Se puede tener control del comportamiento de los clientes Streams usando reglas. Un conjunto o set de reglas es una colección de reglas. En un entorno de replicación, un clinte hace una acción si el LCR sateface el conjunto de reglas.
En general, un cambio satisface los conjuntos de reglas para un cliente de Streams si ninguna regla en el conjunto de reglas negativas se evalúa como TRUE para el LCR, y al menos una regla en el conjunto de reglas positivas se evalúa como TRUE para el LCR. Si un cliente de Streams está asociado con un conjunto de reglas positivas y negativas, entonces el conjunto de reglas negativas siempre se ejecutara antes.
Específicamente, podemos controlar el flujo de información en un entorno de replicación de Streams de las siguientes maneras:
- Especifique los cambios que se deben capturar desde el area de redolog. Si hay un cambio en el area de redolog que aplica el conjunto de reglas este sera capturado.
- Especifique los LCR una propagación debe propagar.
- Especifique las LCR se deben aplicar o descarta en una cola destino.
Debemos utilizar el paquete de pl/sql DBMS_STREAMS_ADM para crear reglas de replicación. Podemos crear reglas en los siguientes niveles:
- Tabla: Contiene reglas para el cambio de una tabla en particular
- Esquema: Contiene reglas para el cambio de un esquema en particular
- Global: Se aplica a toda la base de datos.
A la vez, podemos discriminar las reglas en las que aplican DML o DDL pero no las 2 al mismo tiempo.
Streams replication soporta que se repliquen objetos que no tengan la misma estructura. Es decir en la base destino puede cambiar su estructura. Para esto es necesario utilizar una lregla de transformación, la cual lleve al cambio al formato destino.
Hay 2 tipos de reglas de transformación: declarativas o personalizadas. Las reglas declarativas de transformación o Declarative rule-based transformations (en ingles) permiten cambios en un conjunto de tablas o esquemas. Podemos cambiar el esquema o nombre de tabla o agregar una columna o eliminarla, etc.
En cambio las reglas personalizadas o custom, llaman a una función pl/sql que hace la transformación.
Streams también admite subconjuntos de datos de tablas mediante el uso de reglas de subconjuntos. Si una tabla compartida en una base de datos en un entorno de replicación de Streams contiene solo un subconjunto de datos, entonces puede configurar Flujos para administrar los cambios en una tabla, de modo que solo el subconjunto de datos apropiado se comparta con la tabla de subconjuntos. Por ejemplo, una base de datos particular puede mantener datos para los empleados en un departamento particular solamente. En este caso, puede usar reglas de subconjunto para compartir cambios en los datos para los empleados en ese departamento con la tabla de subconjuntos, pero no para los empleados de otros departamentos.
La subconjunto puede realizarse en cualquier punto del flujo de información de flujos. Es decir, un proceso de captura puede usar una regla de subconjunto para capturar un subconjunto de cambios en una tabla particular, una propagación puede usar una regla de subconjunto para propagar un subconjunto de cambios a una tabla particular y un proceso de aplicación puede usar una regla de subconjunto para aplicar solo un subconjunto de cambios a una tabla en particular.
Por ahora esta la idea general, en proximos post seguiremos en más detalle.
Dejo link: https://docs.oracle.com/cd/B19306_01/server.102/b14228/gen_rep.htm
