m.c. daniel esparza soto 1 base de datos distribuidas replicación de datos en sql server

M.C. Daniel Esparza Soto 1

Base de datos Distribuidas

Replicación de Datos en SQL Server


Introducción

La replicación de Datos consiste en el transporte de datos entre dos o más servidores, permitiendo que ciertos datos de la base de datos estén almacenados en más de un sitio, y así aumentar la disponibilidad de los datos y mejorar el rendimiento de las consultas globales.

El modelo de replicación está formado por: 1.- publicador, 2.- distribuidor, 3.- suscriptor, 4-. publicación, 5-. artículo 6-. suscripción; 7.- y varios agentes responsabilizados de copiar los datos entre el publicador y el suscriptor.


Introducción

La replicación de datos permite que ciertos datos de la base de datos sean almacenados en más de un sitio, y su principal utilidad es que permite aumentar la disponibilidad de los datos y mejora el funcionamiento de las consultas globales a la base de datos.

La replicación en SQL Server consiste, en el transporte de datos entre dos o más instancias de servidores. Para ello SQL Server brinda un conjunto de soluciones que permite copiar, distribuir y posiblemente modificar datos de toda la organización.

Se incluyen, además, varios métodos y opciones para el diseño, implementación, supervisión y administración de la replicación, que le ofrecen la funcionalidad y flexibilidad necesarias para distribuir datos y mantener su coherencia.


Beneficios

1.- Los datos están mas cerca del usuario.

2.- Elimina el impacto de ambientes OLAP (procesamientos analíticos en línea) de lecturas intensivas de los los ambientes OLTP (procesamientos de transacciones en línea) de transacciones intensivas.

3.- Reduce conflictos entre sitios múltiples que intentan trabajar con la misma información.

4.- Los sitios de base de datos pueden operar de manera autonomía con los datos duplicados. Esto significa que pueden definir sus propias reglas, procedimientos y vistas sobre copias de datos.


Factores de la distribución de datos

Hay muchos factores a considerar cuando se trata de decidir sobre un método en particular para distribuir sus datos. Estos comprenden :

1.- autonomía del sitio,

2.- la consistencia transaccional y

3.- la latencia.


Autonomía

Depende de las respuestas a las siguientes preguntas:

¿Qué tanta independencia debe tener sus sitios suscriptores de la base de datos publicada?

¿Por cuánto tiempo es buena una versión de datos en un sitio suscriptor?

¿con que frecuencia es buena una versión de datos en un sitio suscriptor?

¿con que frecuencia es necesario conectarse al sitio publicador y actualizar sus copias de datos?


Consistencia transaccional

Se refiere a las transacciones mismas:

¿Es necesario aplicar al mismo tiempo todas las transacciones almacenadas, o no es necesario en lo absoluto?

Si hay demora en las transacciones, pero éstas se procesan en orden ¿es aceptable?

¿Se están aplicando las transacciones de manera que no tengan conflictos con la consistencia de sus datos?


Latencia

Se refiere al momento en que se aplican las copias de datos.

¿Necesitan sus datos estar 100 por ciento en sincronía el 100 por ciento del tiempo, o es aceptable actualizar los datos en forma periódica?

Si puede tener cierta latencia, ¿De que tamaño es aceptable un rezago?


Consideraciones para la duplicación de datos

Se debe tener las siguientes consideraciones para poder elegir el modelo de replicación adecuado:

1.- Relacionado con los datos

2.- Relacionado con los usuarios

3.- Relacionado con el tiempo de actualización

4.- Relacionado con la red



1.- Relacionado con los datos

¿Qué voy a publicar? ¿Reciben los suscriptores todos los datos o sólo subconjuntos de datos?¿Se deben hacer particiones de mis datos por valores de región o código postal?¿Debo permitir que los suscriptores de mis datos me envíen actualizaciones?Si permito actualizaciones, ¿Cómo deben implementarse?



2.- Relacionado con los usuarios:

¿Quién puede tener acceso a mis datos?

¿Están estos usuarios en línea o fuera de línea?

¿Se encuentran distribuidos en todo el país y conectados mediante líneas telefónicas caras?

3.- Relacionados con el tiempo de actualización:

¿Con que frecuencia debo sincronizar mis datos con los suscriptores?

¿Con que frecuencia obtienen los cambios que les envío?



4.- Relacionado con la red:

¿Cómo luce la red?

¿La red es rápida?

¿Debo hacer mas particiones de datos para minimizar el tráfico ligado a la duplicación?

¿Es confiable la red?

¿Están disponibles todo el tiempo todos los nodos de la red?


Componentes del modelo de replicación

En la replicación se utiliza una metáfora de la industria de la publicación para representar los componentes y procesos de una topología de replicación. De esta forma el modelo se compone, básicamente, de los siguientes elementos: 1-. artículo 2-. publicación, 3-. suscripción; 4.- publicador, 5.- distribuidor, 6.- suscriptor,


1.- Artículos

Un articulo es una sola tabla o subconjunto de datos de una tabla. Los artículos se agrupan en publicaciones. Para publicar un subconjunto de datos en un articulo, debe usar algún tipo de filtro para hacer una partición de datos de una tabla. Puede emplear particiones verticales, horizontales o de ambas. Además de utilizar instrucciones SQL para crear los artículos, puede emplear procedimientos almacenados de sistema.


Reglas para crear artículos

1.- Las columnas identity se duplican, pero la propiedad no. Cuando ocurre una sincronización inicial, los valores de la columna identity se copian como valores enteros.2.- Los tipos de datos TimeStamp se usan para indicar la secuencia de la actividad de SQL server sobre una fila de datos. Proporcionan una historia o genealogía de los cambios realizados a esa fila. Estos valores se duplican como tipos binarios.3.- Los tipos de datos definidos por el usuario pueden ser duplicados solamente si también existen en la base de datos suscriptor.


2.- Publicaciones

Las publicaciones se conforman de uno o más artículos y son la base de una suscripción. Al realizar una suscripción se está suscribiendo a toda una publicación. Cuando está usted suscrito a una suscripción, puede leer artículos individuales. Con las publicaciones es posible mantener la integridad referencial debido a que todos los artículos de esa sola publicación se sincronizan al mismo tiempo. Puede crear tantas publicaciones por base de datos como desee.


Restricciones de publicación

Las tablas deben tener una clave principal para asegurar la integridad (la excepción es cuando usa la duplicación instantánea).

No se pueden duplicar las siguientes BD de sistema: master, model, msdb, tempdb, distribution.

Las publicaciones podrían no abarcar multiples bases de datos. Cada publicación sólo puede contener artículos de una base de datos.

Los tipos de datos IMAGE, TEXT y NTEXT tienen manejo limitado debido a que son tipos de datos que se almacenan por separado de la tablas y no se registran cuando cambian.


Servidores

La replicación de datos es un asunto exclusivamente entre servidores de datos, en nuestro caso hablamos de servidores SQL Server. Los servidores SQL Server pueden desempeñar uno o varios de los siguientes roles:

1.- El publicador es un servidor que pone los datos a disposición de otros servidores para poder replicarlos. 2.- El distribuidor es un servidor que aloja la base de datos de distribución y almacena los datos históricos, transacciones y metadatos. 3.- Los suscriptores reciben los datos replicados.


4.-Publicador

Una publicación es un conjunto de artículos (este concepto: "artículo de una publicación", es diferente del concepto "artículo o registro de una base de datos", como explicaremos más adelante) de una base de datos. Esta agrupación de varios artículos facilita especificar un conjunto de datos relacionados lógicamente y los objetos de bases de datos que desea replicar conjuntamente.

Un artículo de una publicación puede ser una tabla de datos la cual puede contar con todas las filas o algunas (filtrado horizontal) y simultaneamente contar de todas las columnas o algunas (filtrado vertical), un procedimiento almacenado, una definición de vista, la ejecución de un procedimiento almacenado, una vista, una vista indexada o una función definida por el usuario.


4.-Publicador

Una suscripción es una petición de copia de datos o de objetos de base de datos para replicar. Una suscripción define qué publicación se recibirá, dónde y cuándo.

Las suscripciones pueden ser de inserción o de extracción; y una publicación puede admitir una combinación de suscripciones de inserción y extracción.

El publicador (en las suscripciones de inserción) o el suscriptor (en las suscripciones de extracción) solicita la sincronización o distribución de datos de una suscripción.


4.-Publicador

El publicador puede disponer de una o más publicaciones, de las cuales los suscriptores se suscriben a las publicaciones que necesitan, nunca a artículos individuales de una publicación. El publicador, además, detecta qué datos han cambiado durante la replicación transaccional y mantiene información acerca de todas las publicaciones del sitio.


5.- Distribuidor

La función del distribuidor varía según la metodología de replicación implementada. En ocasiones se configura como distribuidor el mismo publicador y se le denomina distribuidor local. En el resto de los casos el distribuidor será remoto, pudiendo coincidir en algún caso con un suscriptor.


6.- Suscriptores

Los suscriptores además de obtener sus suscripciones, en dependencia del tipo y opciones de replicación elegidas, puede devolver datos modificados al publicador. Además puede tener sus propias publicaciones.


Tipos de suscripciones

Cuanto trabaja con publicaciones y suscripciones, puede configurar suscripciones como:

1.- suscripción de inserción .

2.- suscripción de extracción.

La verdadera diferencia entre estos dos métodos de transferencia de datos es donde se lleva a cabo la administración de la suscripción.


Suscripción de inserción

Cuando configura una suscripción al mismo tiempo que su publicación, en esencia está configurando para una suscripción de inserción. Esto ayuda a centralizar la administración debido a que las suscripción está definida en el publicador junto con el calendario de sincronización de suscriptores. Toda la administración de la suscripción se maneja desde el publicador. Los datos se insertan al suscriptor cuando el publicador decide enviarlos.


Suscripción de inserción

Las suscripciones de inserción son muy útiles cuando sus suscriptores requieren que se les envíe las actualizaciones tan pronto como ocurran. Las suscripciones de inserción permiten también un nivel de seguridad más alto ya que el publicador decide a quién se le permite suscribirse y cuándo. Las suscripciones de inserción tienen una sobrecarga adicional en la base de datos de distribución ya que realiza la administración de duplicaciones.


Suscripción de Extracción

Está conformada por cada suscripción individual. Los suscriptores inician la transferencia de información de manera periódica. Esto es útil para aplicaciones que permiten un nivel de seguridad más bajo. El publicador puede permitir que ciertos suscriptores extraigan información, o permitir suscripciones anónimas. Las suscripciones de extracción también son útiles en situaciones en las que podría haber un gran numero de suscriptores. Las soluciones basadas en internet son buenas candidatas para este tipo.

Solo los suscriptores de SQL server pueden extraer suscripciones. Otras base de datos como access, oracle y sybase pueden usar la duplicación de SQL server sólo en escenarios de suscripciones de inserción.


Metodología de distribución

Teniendo en mente la latencia, la consistencia transaccional y la autonomía de sitio, existen los siguientes métodos para implementar la duplicación en SQL Server:

1.- Duplicación de mezcla.

2.- Duplicación de instantánea.

3.- Duplicación transaccional.



La duplicación de mezcla tiene la mas alta autonomía de sitio. También puede permitirse la mayoría de la latencia, pero tiene consistencia transaccional mas baja.

La duplicación de mezcla permite que cada sitio haga cambios a su copia local de datos duplicados. En algún punto en el tiempo, los cambios del sitio se envían a la base de datos publicadora, donde se mezclan con los cambios de otros sitios.

Tarde o temprano, todos los sitios recibirán las actualizaciones de todos los demás sitios. Esto se conoce como convergencia de datos. Los cambios de todos los sitios convergerán, y tarde o temprano todos los sitios tendrán la misma información.



Aquí la consistencia transaccional se tira por la ventana debido a que diferentes sitios podrán estar actualizandos datos en momentos distintos. Un sitio en particular no espera a que sus actualizaciones se envíen a todos los demás sitios antes de continuar su trabajo. En otras palabras, se garantiza que todos los sitios converjan al mismo conjunto de resultados, pero no necesariamente al mismo tiempo.



¿Quienes deben usar usar la duplicación de mezcla?

Debido a los conflictos potenciales que pueden ocurrir, la duplicación se adapta mejor a ambientes en los que están minimizadas las posibilidades de estos conflictos, por ejemplo, los sitios que tienden a hacer cambios solo a sus registros, pero que necesitan la información de otras ubicaciones:-- Base de datos de comandancias policíacas.-- Sucursales de comercios.-- Instituciones educativas.


2.- Duplicación de instantánea.

En la duplicación de instantánea, una copia completa de los elementos a duplicar se copian del servidor publicador a la base de datos suscriptor. Este tipo de duplicación es el más fácil de configurar y dar mantenimiento.

Tiene un alto grado de autonomía de sitio. Además garantiza la consistencia transaccional debido a que todas las transacciones se aplican sólo en el servidor publicador. La autonomía de sitio puede ser muy útil para ubicaciones que necesitan versiones de sólo lectura de datos y no les importa una elevada cantidad de latencia.


2.- Duplicación de instantanea.

Al usar la duplicación de instantánea, la base de datos suscriptor debe considerar los datos como de sólo lectura. Esto se debe a que cualquier cambio a los datos no se enviará de vuelta al a BD publicador. Además, todos los cambios que pudieran haberse realizado a los datos se borrarán cuando descargue la siguiente instantánea.

Candidatos a la duplicación instantánea:- Los servidores OLAP.- Páginas web de consulta de información.- resultados de sorteos. - Consulta de calificaciones. - Consulta tarjetas de crédito.


2b.- Duplicación de instántanea con suscriptores de actualización inmediata.

Con esta metodología se tiene cierta autonomía a que la base de datos suscriptor no tiene que estar todo el tiempo en contacto con la base de datos publicador. El único momento en que el suscriptor está trabajando con el publicadores es cuando descarga una instantánea o cuando está utilizando 2PC (confirmación en dos fases) para actualizar una transacción tanto en la ubicación local (suscriptor) como en la BD publicador.


2b.- Duplicación de instántanea con suscriptores de actualización inmediata.

Esto mantiene un alto grado de consistencia transaccional, ya que las transacciones deben aplicarse tanto en la BD suscriptor con en la BD publicador. El hecho de que otros suscriptores pudiesen hacer cambios a la base de datos publicador desde la última descarga es irrelevante. La consistencia se mantiene por el hecho de que la transacción fracasará si los datos que se están modificando tanto en el publicacdor como en el suscriptor son diferentes.


2b.- Duplicación de instantánea con suscriptores de actualización inmediata.

El servidor suscriptor puede comenzar a trabajar de inmediato con los datos modificados ya que sabe que actualizó con éxito el servidor publicador. El servidor publicador hará converger la información, y en su momento todos los servidores involucrados en la duplicación recibirán una instantánea con los cambios.

Es útil en escenarios en los que tienen lugar unas cuantas modificaciones ocacionales en los servidores suscriptor. Entre mas tiempo tome la latencia, es mas probable que falle su confirmación en dos fases(2PC). Esto se debe a que hay una mayor probabilidad de que los datos hayan cambiado en el publicador, pero aún no se haya enviado un duplicado al suscriptor.



En esta metodología, las transacciones se envían del publicador a los suscriptores. Este tipo de duplicación es de una sola vía. La única forma de que un suscriptor pueda hacer cambios a los datos es directamente a la base de datos publicador. Entonces, el cambio se duplicará de vuelta a los suscriptores en la siguiente sincronización.Este tipo de duplicación permite una autonomía media. El suscriptor debe tratar los datos como de solo lectura. Esto es importante ya que los cambios hechos a los datos duplicados podrían no permitir que se realicen las futuras transacciones duplicadas.



En este tipo de publicación comprende una latencia media. El suscriptor no tiene que estar siempre en contacto con el publicador, aunque son útiles las sincronizaciones regulares, y la cantidad de datos que se mueven es relativamente pequeña. La duplicación de instantánea debe mover al suscriptor todos los datos publicados del publicador hayan o no hecho modificaciones. En la duplicación transaccional, solo se envían a los suscriptores las transacciones que se realizaron.

La duplicación transaccional es muy útil en escenarios en los que los suscriptores puedan tratar sus datos como de solo lectura, pero necesitan cambios a los datos con una cantidad mínima de latencia.

Un ejemplo es en un sistema de procesamientos de pedidos/distribución de pedidos.

M.C. Daniel Esparza Soto

3b.- Duplicación transaccional con suscriptores de actualización inmediata

Aquí se puede perder aún más autonomía en los sitios suscriptores, pero se minimiza la latencia. Con esta metodología, usted emplea junto con la confirmación de dos fases(2pc) la duplicación transaccional descrita en la sección anterior.

Cuando una BD suscriptor intenta hacer cambios a los datos, el cambio se escribe también en la BD publicador en una confirmación en dos fases. Esto significa que el cambio se escribe al mismo tiempo tanto en el suscriptor como en el publicador. Esto garantiza la consistencia transaccional. El cambio convergerá entonces con otros suscriptores que actualizan y se enviará de vuelta a todas las BD suscriptor.


3b.- Duplicación transaccional con suscriptores de actualización inmediata

Esto tiene menos latencia que usar una duplicación de instantaneas con suscriptores de actualización inmediata, debido a que las transacciones que se están duplicando son mucho más pequeñas (y rápidas de mover) que sincronizar una instantánea completa de sus datos.Escenarios útiles:- Sistemas de resevaciones de bajo volumen. En este tipo de sistema, un suscriptor puede reviar una agenda de disponibilidad y luego intentar hacer una reservación.


¿Cómo funciona la duplicación?

Se maneja mediante cuatro diferentes agentes, cada uno tiene una labor especializada por realizar, cuando se ponen juntos todos los agentes, se obtiene la duplicación:

1.- Agente de distribución (Distribution Agent)

2.- Agente de lector del registro ( Log reader Agent).

3.- Agente de mezcla (Merge Agent)

4.- Agente de instántanea (Snapshot Agent)



1.- Agente de distribución (Distribution Agent):Mueve la información de la BD distribución hacia los suscriptores.

2.- Agente de lector del registro ( Log reader Agent): Monitorea el registro de transacciones de todas las BD publicadas que lo utilizan para duplicación. Cuando encuentran transacciones que son parte de una duplicación, las copia a la BD de distribución en donde pueden aplicarse a los sucriptores por medio del agente de distribución.



3.- Agente de mezcla (Merge Agent). Mezcla modificaciones desde sitios múltiples.

4.- Agente de instántanea (Snapshot Agent). Mueve un instantánea de los datos antes de que pueda comenzar la duplicación. Esto es obligatorio. Si en el suscriptor no existe una instantánea de datos, no es posible aplicar transacciones al suscriptor. También se emplea para los diversos tipos de duplicación de instantánea.


Funcionamiento de la duplicación de mezcla

El gente de mezcla puede vivir en el servidor de distribución o en cada servidor suscriptor. En un escenario de inserción, el agente de mezcla vive en el servidor distribución. En los escenarios de extracción, el agente vive en cada suscriptor.

Distribución

Susc. Inserción SuscripiciónAgente de

Mezcla

Distribución

Susc. Extracción

Suscripición

Agente de Mezcla


Pasos en una duplicación de mezcla

Publicador

BD de publicación

Distribución

BD de Distribución

Agente de Instantáneas

Agente de Mezcla de Inserción

Carpeta de trabajo de

distribución

BD de Suscriptor

Agente de mezcla de extracción

Suscriptor

1

2

4

15


Pasos en una duplicación de mezcla

1.- El agente de instantanea (que vive en el servidor de distribución) toma una instantánea inicial de los datos y los mueve a los suscriptores. Recuerde que los suscriptores deben primero sincronizarse con los publicadores para que comience la duplicación (con excepción de la duplicación de instantáneas).2.- Se crea una carpeta de trabajo de distribución en le servidor de distribución para manejar las mezclas.3.- Ahora comienza la duplicación.4.- El agente de mezcla toma modificaciones de los publicadores y las aplica a los suscriptores.5.- El agente de mezcla toma modificaciones de los suscriptores y las aplica a los publicadores.6.- El agente de mezcla recibe cualquier conflicto de actualización y toma la acción adecuada.


Cambios al esquema en Duplicación de mezcla

Para que la duplicación de mezcla funcione en forma apropiada, se realizan algunos cambios al esquema de tablas así como a la base de datos de distribución(distribution).

Estos cambios se hacen para permitir que SQL Server lleve a cabo la resolución de conflictos.


Cambios al esquema en Duplicación de mezcla

Tenga en cambio los siguentes cambios al esquema:

1.- Se incorporan tablas del sistema a la carpeta de trabajo de distribución para el rastreo de cambios durante la sincronización y la resolución de conflictos.

2.- SQL Server crea trigger tanto en el servidor de publicación como en los de suscripción y se accionan cuando ocurre una modificación de datos en las tablas comprendidas en la duplicación.

3.- SQL Server server crea una nueva columna de tipo UNIQUEIDENTIFIER para cada fila en las tablas que se están duplicando y de esta manera se identifica de forma unica esa fila, de manera que cuando se actualice el registro de diferentes fuentes, puede diferenciar las distintas actualizaciones.


Duplicación de mezcla

La duplicación de mezcla se utiliza mejor cuando hay pocas probabilidades de que se realicen cambios a los mismos registros por parte de suscriptores diferentes. Las tablas segmentadas en forma horizontal son utiles y puede crear y suscribirse a publicaciones por separado con base en códigos de región o algún mecanismo de filtrar datos. No se pueden hacer particiones verticales.


Solución de conflictos de actualización

Cuando se permiten realizar actualizaciones a los mismos datos en diferentes ubicaciones SQL Server hace lo siguiente:- Se emplean las tablas del sistema que están almacenadas en la carpeta de trabajo de distribución (servidor distribución) para rastrear todos los cambios a una fila. Dichos cambios se listan y cada uno tiene un ROWGUID. A este historial de modificaciones de un registro se le denomina Linaje del registro.

- Por medio del linaje, el agente de mezcla puede evaluar tanto los valores actuales como los que llegan y resolver en forma automática conflictos con base en las prioridades que el administrador hayan asignado, las cuales se almacenan como desencadenadores.


Funcionamiento de la duplicación de instantánea

Cuando se una duplicación instantanea, copia el articulo entero o la publicación entera del publicador al suscriptor. Esto incluye a la duplicación de instantáneas con suscriptores de actualización inmediata. Las actualizaciones se hacen tanto en el suscriptor como en el publicador, pero cuando ocurre una sincronización, los datos del suscriptor se reemplazan por completo por el artículo entrante.


Funcionamiento de la duplicación de instantánea

En la duplicación de instantánea no hay agente de mezcla; sin embargo, se emplea el agente de distribución. Si está usando una suscripción de extracción, el agente de distribución se encuentra en el servidor suscriptor. Si esta usando una suscripción de inserción, el agente de distribución se encuentra en el servidor de distribución.

Distribución

Susc. Inserción SuscripiciónAgente de distribución

Distribución

Susc. Extracción

Suscripición

Agente de distribución


Pasos de la duplicación de instantánea

Publicador

BD de publicación

Distribución

BD de Distribución

Agente de Instantáneas

Agente de distribución de Inserción


distribución

BD de Suscriptor


de extracción

Sucriptor

1

23

3


Pasos de la duplicación de instantánea

1.- El agente de instantáneas lee el artículo publicado y crea el esquema de tabla y los datos en la carpeta de trabajo de distribución.

2.- El agente de distribución lee este esquema y reconstruye las tablas en el suscriptor.

3.- El agente de distribución mueve entonces los datos a las tablas recién creadas en el suscriptor.

4.- Se crean nuevos índices sobre recién sincronizadas base de datos de suscripción.


Duplicación de instantánea

La duplicación de instantánea ocurre sobre demanda, esto significa que la instantánea de los datos se almacenan en la base de datos de distribuidor, como ocurre con el algoritmo de almacenamiento y expedición que se emplean en la duplicación con base en transacciones.

En la base de datos de distribución sólo se almacena información de estado de una instantánea. El agente de instantánea hace todo el trabajo al momento en que se inicia la sincronización.


Aspectos de la duplicación transaccional

La duplicación basada en transacciones sólo copia a la base de datos de distribución las transacciones que ocurrieron en la base de datos publicadas. Las actualizaciones se aplican entonces a la base de datos de suscripción. Por lo general en el momento en que ocurren. Esto reduce la latencia. Debe pensar en la base de datos de suscripción como de sólo lectura, ya que este tipo de duplicación es de una sola vía. Los cambios a los datos sólo pueden hacerse en el publicador.


Funcionamiento de la duplicación transaccional

Aquí ya no hay agente de mezcla; sin embargo, hay un agente de lector de registro, tenga en cuenta que el agente de instantánea está aun operando. Debe tener una base para aplicar las transacciones, y el agente de instantáneas lo realizará. Aquí se usa el agente de distribución. Si está usando una suscripción de inserción, el agente de distribución se encuentra en el servidor de suscripción. Si emplea una suscripción de extracción, el agente de distribución se ubica en el servidor de distribución.


Pasos de la duplicación transaccional

Publicador

BD de publicación

Distribución

BD de Distribución

A. Lector del registro

Agente de distribución de Inserción


distribución

BD de Suscriptor


de extracción

Sucriptor



1.- El agente de instantánea lee el artículo publicado y crea el esquema de tablas y los datos en la carpeta de trabajo de distribución.

2.- El agente de distribución lee este esquema y construye las tablas en el suscriptor.

3.- El agente de distribución mueve entonces los datos a las tablas recién creadas en el suscriptor.

4.- Se crean de nuevo los indices sobre la recién sincronizada BD de suscripción.

5.- Ahora puede comenzar la duplicación transaccional normal.



6.- El agente lector del registro observa el registro de transacciones de la BD publicada. Cuando encuentra una transacción, la mueve a la BD distribución, en donde se almancenará hasta que comience el siguiente proceso de sincronización.

7.- Cuando llama el proceso de sincronización (ya sea por una inserción desde el distribuidor o una extracción desde el sucriptor), el agente de distribución lee la transacción y la aplica después a la BD de suscripción.


Escenarios de duplicación

La duplicación puede ser generada en los diferentes escenarios:

1.- Publicador central.

2.- Publicador central con un distribuidor remoto.

3.- Suscriptor publicador.

4.- Suscriptor central.

5.- Publicadores y suscriptores múltiples.



Puede reducir el impacto de los servicios OLAP del ambiente OLTP. En este escenario, el servidor publicador es también el servidor distribución. Tenga presente que entre mas suscriptores tenga, será mayor el impacto en el servidr de distribución. Este impacto puede reducirse en cierto modo mediante una suscripción de extracción, en la que el agente de distribución reside en cada suscriptor.



Servidor de publicación

Servidor de distribución

Servidor de suscripción




Puede reducir aún más el impacto de la base de datos de distribución en su ambiente OLTP de gran volumen moviéndolo a su propio servidor. Al igual que antes, un solo servidor de distribución puede manejar múltiples publicadores y suscriptores. Éste es el escenario preferido en situaciones con publicadores y suscriptores múltiples.



En un escenario de suscriptor publicador, el servidor suscriptor es también servidor publicador. Esto puede ser de gran beneficio cuando tiene un enlace lento y costoso entre el publicador principal y un grupo de suscriptores. En este escenario, el suscriptor actúa también como publicador para una serie de base de datos de suscripción. De esta manera, puede minimizar el costo de enlaces lentos mediante la actualización de un solo suscriptor y después duplicador de nuevo al resto de los servidores suscriptores la información recien sincronizada.


Nueva York

Paris

Berlin Madrid

Enlace lento











El servidor de suscripción esta ubicado de manera central y uno o más servidores publicadores le envían actualizaciones. Esto es útil para situaciones de informes concentrados o de procesamiento central.

Para diferenciar los datos de la tabla central que llegan de diferentes localidades, debe hacer algunos cambios a el esquema de datos:

1.- Agregue una columna ClaveRegión, claveSucursal, etc, osea una clave que identifique los registros de cada base de datos en la tabla central.

2.- Hacer la nueva columna como parte de la clave principal.



El escenario de suscriptor central se presta muy bien para una duplicación con base en transacciones. Cada localidad que pide un producto, hará que se duplique el pedido de producto a la ubicación central en donde se procesará y embarcará.


5.- Publicadores y suscriptores múltiples.

Son útiles para sistemas del tipo de reservaciones o cualquier otro en el que deba estar disponible, en cada región, información acerca de otras regiones. En el sistema del tipo de reservaciones, puede también implementar esta forma de duplicación. Se sugiere usar transacciones distribuidas para hacerlo de modo que todas las localidades tengan los mismo datos al mismo tiempo. También se recomienda agregar una clave de región a la tabla central y hacerla parte de la llave primaria como en el caso de servidor central. Para que esto funcione de manera adecuada, cada tienda debe actualizar sólo los datos de su propia localidad. Si va a usar un escenario del tipo suscriptor de actualización, asegurese de hacer sus actualizaciones de manera simultánea a todos los sitios para evitar conflictos.


Prácticas recomendadas

Para ayudar a asegurar el mejor desempeño, tenga presente los siguientes puntos al determinar el tipo de duplicación que va a utilizar y el escenario que desea implementar:1.- Asegure la velocidad y disponibilidad de la red2.- Los suscriptores que actualizan en forma inmediata pueden ser útiles cuando hay suficiente ancho de banda.3.- Publique datos particionados. No hay necesidad de enviar siempre toda la información. 4.- Los suscriptores de extracción pueden hacerse cargo de gran parte de la carga de trabajo del servidor de distribución. Recuerde que perderá su administración centralizada de duplicación pero ganará algo de rendimiento.


Prácticas recomendadas

5.- Use en escenarios un distribuidor remoto. Esto puede desplazar de su base de datos OLTP el grueso de la carga de trabajo que comprende la duplicación. Esto es útil también si tiene un enlace lento y costoso entre sus servidores de distribución y sus servidores de suscripción.6.- Minimice los conflictos de actualización reduciendo la posibilidad de que ocurran cuando está usando una duplicación de mezcla o actualizando suscriptores.7.- En la duplicación de mezcla o actualización de suscriptores, asegurese de incluir una clave de región como parte de la clave principal.


Publicación a base de datos diferentes a SQL Server

Se deben tener en cuenta los siguentes puntos cuando intente duplicar a suscriptores ODBC que no sean SQL Server:1.- SQL Server no maneja suscripciones de extacción. Debe usted insertar suscripciones desde un publicador de SQL Server.2.- No se manejan instrucciones por lote para los suscriptores ODBC.3.- Los tipos de datos se mapean al tipo de dato mas coincidente en la base de datos de suscripción.4.- El ODBC DNS debe apegarse al las reglas de denominación de identificadores de SQL Server.5.- Al utilizar instantáneas, los datos a transferir usarán el formato de caracteres BCP.


Base de datos que no son SQL Server y publicán para SQL Server

Es posible que otras base de datos se convierten en publicadores en el ambiente de SQL Server. Para lograr esto, debe escribir programas que aprovechen SQL-DMO(objetos de administración de base de datos SQL). Después de crear sus progamas par este propósito, podrá manejar las diferentes caracteristicas de duplicación de SQL Server.


Base de datos que no son SQL Server y publicán para SQL Server

SQL-DMO expone los siguientes objetos COM para us uso en la duplicación:1.- Objetos para la administración de duplicación.2.- Objetos para la supervisión de duplicación.3.- Objetos para aprovechar el agente de distribución para reexpedir transacciones a servidores de suscripción.4.- Objetos para trabajar con la base de datos de distribución para el almacenamiento de transacciones duplicadas.5.- Contadores de desempeño de SQL Server, varios de los cuales se agrupan en los objetos de desempeño de SQL Server y se exhiben en en monitor de rendimiento de SQL Server.6.- Objeto par exponer su publicador en el administrador corporativo para administración gráfica.

m.c. daniel esparza soto 1 base de datos distribuidas replicación de datos en sql server

Documents