Replicacin de Datos en SQL Server

1.
2.
3.
4.
5.
6.
7.
8.
9.

Resumen
Introduccin
Componentes del modelo de replicacin
Escenarios tpicos de la replicacin
Tipos de replicacin
Factores para elegir el mtodo de replicacin a utilizar
Fases generales para implementar y supervisar la replicacin
Consideraciones finales
Referencias Bibliogrficas

Resumen
La replicacin de datos consiste en el transporte de datos entre dos o ms servidores,
permitiendo que ciertos datos de la base de datos estn almacenados en ms de un sitio, y as
aumentar la disponibilidad de los datos y mejorar el rendimiento de las consultas globales. El
modelo de replicacin est formado por: publicador, distribuidor, suscriptor, publicacin, artculo
y suscripcin; y varios agentes responsabilizados de copiar los datos entre el publicador y el
suscriptor. A los tipos bsicos de replicacin (de instantneas, transaccional y de mezcla), se le
incorporan opciones para ajustarse an ms a los requerimientos del usuario.
1. Introduccin
La replicacin de datos permite que ciertos datos de la base de datos sean almacenados en
ms 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. [Elm00]
La replicacin en SQL Server consiste, en el transporte de datos entre dos o ms instancias de
servidores. Para ello SQL Server brinda un conjunto de soluciones que permite copiar, distribuir
y posiblemente modificar datos de toda la organizacin. Se incluyen, adems, varios mtodos y
opciones para el diseo, implementacin, supervisin y administracin de la replicacin, que le
ofrecen la funcionalidad y flexibilidad necesarias para distribuir datos y mantener su coherencia
[Mic01].
En la replicacin se utiliza una metfora de la industria de la publicacin para representar los
componentes y procesos de una topologa de replicacin. De esta forma el modelo se
compone, bsicamente, de los siguientes elementos: publicador, distribuidor, suscriptores,
publicaciones, artculos y suscripciones [Mic01].
2. Componentes del modelo de replicacin
Para representar los componentes y procesos de una topologa de replicacin se utilizan
metforas de la industria de la publicacin. El modelo se compone de los siguientes objetos: el
publicador, el distribuidor, el suscriptor, la publicacin, el artculo y la suscripcin; as como de
varios agentes, que son los procesos responsabilizados de copiar los datos entre el publicador
y el suscriptor. Estos agentes son: agente de instantneas, agente de distribucin, agente del
lector del registro, agente del lector de cola y agente de mezcla [Mic01].
La replicacin de datos es un asunto exclusivamente entre servidores de datos, en nuestro
caso hablamos de servidores SQL Server. Los servidores SQL Server pueden desempear uno
o varios de los siguientes roles: publicador, distribuidor o suscriptor.
El publicador es un servidor que pone los datos a disposicin de otros servidores para poder
replicarlos. El distribuidor es un servidor que aloja la base de datos de distribucin y almacena
los datos histricos, transacciones y metadatos. Los suscriptores reciben los datos replicados.

Una publicacin es un conjunto de artculos (este concepto: "artculo de una publicacin", es

diferente del concepto "artculo o registro de una base de datos", como explicaremos ms
adelante) de una base de datos. Esta agrupacin de varios artculos facilita especificar un
conjunto de datos relacionados lgicamente y los objetos de bases de datos que desea replicar
conjuntamente. Un artculo de una publicacin 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 definicin de vista, la
ejecucin de un procedimiento almacenado, una vista, una vista indizada o una funcin definida
por el usuario.
Una suscripcin es una peticin de copia de datos o de objetos de base de datos para
replicar. Una suscripcin define qu publicacin se recibir, dnde y cundo. Las suscripciones
pueden ser de insercin o de extraccin; y una publicacin puede admitir una combinacin de
suscripciones de insercin y extraccin. El publicador (en las suscripciones de insercin) o el
suscriptor (en las suscripciones de extraccin) solicita la sincronizacin o distribucin de datos
de una suscripcin.
El publicador puede disponer de una o ms publicaciones, de las cuales los suscriptores se
suscriben a las publicaciones que necesitan, nunca a artculos individuales de una publicacin.
El publicador, adems, detecta qu datos han cambiado durante la replicacin transaccional y
mantiene informacin acerca de todas las publicaciones del sitio.
La funcin del distribuidor vara segn la metodologa de replicacin 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 algn caso con
un suscriptor.
Los suscriptores adems de obtener sus suscripciones, en dependencia del tipo y opciones de
replicacin elegidas, puede devolver datos modificados al publicador. Adems puede tener sus
propias publicaciones [Mic01].
3. Escenarios tpicos de la replicacin
En una solucin de replicacin pudiera ser necesario utilizar varias publicaciones en una
combinacin de metodologas y opciones. En la replicacin los datos o transacciones fluyen del
publicador al suscriptor pasando por el distribuidor.
Por lo tanto en su configuracin mnima una topologa de replicacin se compone de al menos
dos o tres servidores SQL Server que desempean los tres roles mencionados.
Variando la ubicacin del servidor distribuidor podramos contar con las siguientes variantes:
1. El rol de distribuidor desempeado por el publicador (Fig. 1.1).
2. El rol de distribuidor desempeado por el suscriptor (Fig. 1.2)
3. Un servidor de distribucin, independiente del publicador y del suscriptor (Fig. 1.3)

Fig.1 Publicador-Distribuidor Fig.2 Distribuidor-Suscriptor Fig. 3 Distribuidor independiente

En la mayora de las configuraciones, el peso fundamental de la replicacin recae, sobre el
servidor de distribucin. Por tanto ste puede ser un criterio para determinar su ubicacin,
teniendo en cuenta las configuraciones (posibilidades fsicas) de los servidores, as como otras
responsabilidades que pueden estar desempeando (servidor de dominio, servidor de pginas
web entre otras) [Mic01].
Existe la posibilidad de contar con un servidor que se suscriba a una publicacin y a la vez la
publique para el resto de los suscriptores, esto puede ser muy til cuando se cuente con una
conexin muy costosa con el publicador principal. Por ejemplo el publicador principal en Madrid
y los suscriptores en Ciudad Habana, Varadero, Cayo Coco, Cayo Largo, etc. En casos como
este, se puede elegir un suscriptor, digamos el servidor de Ciudad Habana el cual se suscribe
al publicador en Madrid y a la vez acta como servidor de publicacin para los servidores de
Varadero, Cayo Coco, Cayo Largo y dems. Evidentemente en una configuracin tal pueden
nuevamente combinarse la ubicacin de los dos distribuidores y aumentar el nmero de
variantes que pueden presentarse pero las consideraciones para determinar la ubicacin del
servidor que fungir como distribuidor son las ya mencionadas.
3. Tipos de replicacin
Los tipos bsicos de replicacin son:

replicacin de instantneas
replicacin transaccional
replicacin de mezcla
Para ajustarse an ms a los requerimientos de los usuarios se incorporan opciones como son
la actualizacin inmediata en el suscriptor, la actualizacin en cola y la transformacin de datos
replicados [Mic01].
3.1 Replicacin de instantneas
En la replicacin de instantneas los datos se copian tal y como aparecen exactamente en un
momento determinado. Por consiguiente, no requiere un control continuo de los cambios. Las
publicaciones de instantneas se suelen replicar con menos frecuencia que otros tipos de
publicaciones. Puede llevar ms tiempo propagar las modificaciones de datos a los
suscriptores. Se recomienda utilizar: cuando la mayora de los datos no cambian con
frecuencia; se replican pequeas cantidades de datos; los sitios con frecuencia estn
desconectados y es aceptable un periodo de latencia largo (la cantidad de tiempo que
transcurre entre la actualizacin de los datos en un sitio y en otro). En ocasiones se hace
necesario utilizarla cuando estn involucrados algunos tipos de datos (text, ntext, e image)
cuyas modificaciones no se registran en el registro de transacciones y por tanto no se pueden
replicar utilizando la metodologa de replicacin transaccional.
Los servidores OLAP son candidatos a la replicacin de instantneas. Las consultas ad-hoc
que aplican los administradores de sistemas de informacin son generalmente de solo lectura y
los datos con antigedad de horas o das no afectan sus consultas. Por ejemplo un
departamento desea hacer una investigacin sobre demografa de los artculos vendidos hace
dos meses. La informacin de la semana pasada no afectar sus consultas; adems el
departamento no est planeando hacer cambio en los datos, solo necesita el almacn de datos.
Hay que destacar adems que cuando estn involucrados algunos tipos de datos (text, ntext, e
image) cuyas modificaciones no se registran en el registro de transacciones [Mic01] y por lo
tanto es necesario transportar estos datos del publicador al suscriptor para lo cual es necesario
utilizar la replicacin de instantneas, al menos como una solucin parcial.
Con la opcin de actualizacin inmediata en el suscriptor se permite a los suscriptores
actualizar datos solamente si el publicador los va a aceptar inmediatamente. Si el publicador los

acepta, se propagan a otros suscriptores. El suscriptor debe estar conectado de forma estable
y continua al publicador para poder realizar cambios en el suscriptor. Esta opcin es til en
escenarios en los que tienen lugar unas cuantas modificaciones ocasionales en los servidores
suscriptor.
3.2 Replicacin transaccional
En este caso se propaga una instantnea inicial de datos a los suscriptores, y despus, cuando
se efectan las modificaciones en el publicador, las transacciones individuales se propagan a
los suscriptores. SQL Server 2000 almacena las transacciones que afectan a los objetos
replicados y propaga esos cambios a los suscriptores de forma continua o a intervalos
programados. Al finalizar la propagacin de los cambios, todos los suscriptores tendrn los
mismos valores que el publicador. Suele utilizarse cuando: se desea que las modificaciones de
datos se propaguen a los suscriptores, normalmente pocos segundos despus de producirse;
se necesita que las transacciones sean atmicas, que se apliquen todas o ninguna al
suscriptor; los suscriptores se conectan en su mayora al publicador; su aplicacin no puede
permitir un periodo de latencia largo para los suscriptores que reciban cambios.
Es til en escenarios en los que los suscriptores pueden tratar a sus datos como de slo
lectura, pere necesitan cambios a los datos con una cantidad mnima de latencia. Ejemplo: un
sistema para el procesamiento y distribucin de pedidos. En este tipo de escenario, podra
tener varios publicadores recibiendo pedidos de mercancas. Estos pedidos se replican
entonces a un almacn central donde se despachan los pedidos. El almacn puede tratar los
datos como de slo lectura y requiere nueva informacin en forma peridica.
Con el uso de la opcin de atualizacin inmediata en el suscriptor se pierde an ms la
autonoma de sitio, pero se reduce el tiempo en el cual los sitios actualizan sus copias de los
datos. Para hacer modificaciones en la base de datos del suscriptor stas se realizan (o
intentan) tambin en la base de datos publicador en una confirmacin de dos fases (2PC) por lo
que si su modificacin se confirma indica que es vlida y luego en cuestin de minutos, o segn
la planificacin hecha, estos cambios son duplicados a las dems bases de datos suscriptoras.
3.3 Replicacin de mezcla
Permite que varios sitios funcionen en lnea o desconectados de manera autnoma, y mezclar
ms adelante las modificaciones de datos realizadas en un resultado nico y uniforme. La
instantnea inicial se aplica a los suscriptores; a continuacin SQL Server 2000 hace un
seguimiento de los cambios realizados en los datos publicados en el publicador y en los
suscriptores. Los datos se sincronizan entre los servidores a una hora programada o a peticin.
Las actualizaciones se realizan de manera independiente, sin protocolo de confirmacin, en
ms de un servidor, as el publicador o ms de un suscriptor pueden haber actualizado los
mismos datos. Por lo tanto, pueden producirse conflictos al mezclar las modificaciones de
datos. Cuando se produce un conflicto, el Agente de mezcla invoca una resolucin para
determinar qu datos se aceptarn y se propagarn a otros sitios. Es til cuando: varios
suscriptores necesitan actualizar datos en diferentes ocasiones y propagar los cambios al
publicador y a otros suscriptores; los suscriptores necesitan recibir datos, realizar cambios sin
conexin y sincronizar ms adelante los cambios con el publicador y otros suscriptores; el
requisito de periodo de latencia de la aplicacin es largo o corto; la autonoma del sitio es un
factor crucial.
Es til en ambientes en los que cada sitio hacen cambios solamente en sus datos pero que
necesitan tener la informacin de los otros sitios. Por ejemplo podra crearse una base de datos
que registre la historia delictiva de individuos. En cada municipio de Villa Clara, se puede tener
una copia de la base de datos de toda la provincia y no se requiere estar conectado
permanentemente a la base de datos de la instancia provincial.
4. Factores para elegir el mtodo de replicacin a utilizar

En la eleccin de un mtodo adecuado para la distribucin de los datos en una organizacin

influyen varios factores. Los cuales podemos agruparlos en dos grupos: factores relacionados
con los requerimientos de la aplicacin y factores relacionados con el entorno de red.
Dentro de los factores relacionados con los requerimientos de la aplicacin, los fundamentales
son [Gar99]:

Autonoma
Consistencia transaccional
Latencia
La autonoma de un sitio da la medida de cuanto puede operar el sitio desconectado de la base
de datos publicadora. La consistencia transaccional de un sitio viene dado por la necesidad de
ejecutar o no inmediatamente todas las transacciones que se han ejecutado en el servidor, o si
es suficiente con respetar el orden de las mismas. La latencia de un sitio se refiere al momento
en que se deben de sincronizar las copias de los datos. Necesitan los datos estar el 100% en
sincrona? O si es admisible determinada latencia de qu tamao es aceptable el rezago?
[Gar99].
Entre los factores relacionados con el entorno de red estn la velocidad de transmisin de
datos de la red, deben considerarse preguntas como Cmo luce la red? Es rpida? Debe
analizarse adems la confiabilidad de la red y responder preguntas como Cun confiable es la
red? Por otra parte en el caso que los servidores SQL no permanezcan todo el da encendidos,
como pudiera suceder en algunas organizaciones, deben considerarse los horarios de
disponibilidad de cada servidor.
La consideracin de estos factores sirven de guia en la configuracin del ambiente de
replicacin. Adems debe considerar las siguientes preguntas: Qu datos se van a publicar?
Reciben todos los suscriptores todos los datos o slo subconjuntos de ellos? Se deben
particionar los datos por sitio? Se debe permitir que los suscriptores enven actualizaciones de
los datos? Y en caso de permitirlas Cmo deben implementarse? Quines pueden tener
acceso a los datos? Se encuentran estos usuarios en lnea? Se encuentran conectados
mediante enlaces caros?
5. Fases generales para implementar y supervisar la replicacin
A pesar de que existen varias formas de implementar y supervisar la replicacin, y el proceso
de replicacin es diferente segn el tipo y las opciones elegidas, en general, la replicacin se
compone de las siguientes fases:

configuracin de la replicacin
generacin y aplicacin de la instantnea inicial
modificacin de los datos replicados
sincronizacin y propagacin de los datos.
6. Consideraciones finales
La replicacin es muy til para mejorar la disponibilidad de datos, lo cual pudiera llevarse al
caso extremo, conocido como bases de datos distribuidas replicadas totalmente, en el cual
consiste en la replicacin de la base de datos completa en cada sitio en el sistema distribuido y
garantiza notablemente la disponibilidad de datos, pues el sistema puede continuar operando
cuando exista en servicio al menos uno de los servidores SQL Server. La desventaja es un alto
costo para mantener la consistencia de las copias en cada sitio [Elm00].
Referencias Bibliogrficas

[Elm00] Elmasri, R y Navathe, S. B. Fundamentals of database systems. AddisonWesley, Third Edition, 2000.
[Gar99] Garca, C. Escenario de red para la supervisin de fallas en centrales
telefnicas. Informe Final de Tesis de Maestra en Computacin Aplicada, Universidad
Central de "Marta Abreu" de Las Villa, Santa Clara, 1999.
[Mic01] Microsoft Corporation, Libros en pantalla de SQL Server, 2001.