REPLICACIN SQL SERVER

CALLETANA LPEZ BALETA

INSTRUCTOR
JONATHAN QUICENO VARGAS
INGENIERO DE SISTEMAS Y COMPUTACIN

SERVICIO NACIONAL DE APRENDIZAJE

PROGRAMA
ESPECIALIZACIN TECNOLGICA EN GESTIN Y SEGURIDAD DE BASE
DE DATOS
MODALIDAD VIRTUAL
2017
 REPLICACIN CON SQL SERVER

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.

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.

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.
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.
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.

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 simultneamente 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) solicitan 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, pueden devolver datos modificados al publicador.
Adems puede tener sus propias publicaciones.

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.

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 imagen)
cuyas modificaciones no se registran en el registro de transacciones y por tanto no
se pueden replicar utilizando la metodologa de replicacin transaccional.

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.

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, pero 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 actualizacin 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.

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 en ambientes en los que cada sitio hace 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.

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:

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?

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 todos los das encendidos, como pudiera suceder
en algunas organizaciones, deben considerarse los horarios de disponibilidad de
cada servidor.

La consideracin de estos factores sirve de gua 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?

Configuracin de red.

En primer lugar debemos conocer la configuracin de red que afecta a nuestro

equipo SERVIDOR (el que tiene SQL Server). Si nuestro servidor sale a Internet por
medio de un Router, deberemos hacer NAT para redireccionar las conexiones
entrantes por el puerto 1433 (puerto por defecto de SQL Server) a nuestro equipo
SERVIDOR.

Tambin hay que asegurarse que cualquier firewall habilitado permite las
conexiones contra SQL Server. No hace falta decir que deberemos conocer la IP
Pblica por la que sale el Router, para luego conectarnos a ella.

Configuracin en SQL Server

Antes de intentar conectarnos debemos comprobar los siguientes aspectos de

configuracin:

1. Tener arrancado el servicio de SQL Server (mediante el administrador de

servicios de SQL Server).

2. Conocer la IP contra la que nos conectamos: Para conectarnos contra una

instancia predeterminada de SQL Server bastara con poner la IP publica de la
mquina donde se ejecuta, pero si se trata de instancias con nombre es necesario
especificar IP\NombreInstancia. En este caso no nos vale con poner
NombreMaquina\Instancia dado que no se va a conseguir resolver el nombre de la
maquina por Internet.

3. Protocolos habilitados en el Servidor: Comprobar con la herramienta de red del

servidor que se encuentran habilitados los protocolos TCP/IP.

Si no hemos tenido en cuenta alguno de los puntos anteriores, podramos obtener

el siguiente mensaje de Error:

"No existe el Servidor SQL Server o se ha denegado el acceso al mismo"

Pero como siempre, existen situaciones especiales que pueden hacer que nos
surjan errores pese a tener bien configurado lo anterior.
Lo primero que hay que tener en cuenta es que si en una misma mquina existen
varias instancias de SQL Server, solo la predeterminada corre por el puerto 1433, y
todas las dems escuchan en un puerto que les asigna el Servicio de Resolucin
de SQL, por lo que sera necesario reconfigurar el NAT de nuestro Router para
permitir las conexiones a SQL Server por el puerto correspondiente. Pero adems
habr que tener en cuenta algo MUY IMPORTANTE, y es que el Servicio de
Resolucin de SQL corre en el Puerto UDP 1434, por lo que tambin deberemos
hacer NAT a este puerto en concreto. Sino NO conseguiremos conectarnos.

La asignacin de este puerto (la de la instancia) se puede configurar para que se

haga de forma esttica o de forma dinmica. Como ya hemos dicho, la instancia
predeterminada de SQL Server escucha solicitudes de clientes de SQL Server en
el puerto 1433 (esttico). Sin embargo, si una instancia de SQL Server se configura
para escuchar en un puerto esttico y si ya utiliza el puerto esttico especificado
otro programa que se ejecuta en el equipo cuando se inicia SQL Server, SQL Server
no escuchar en el puerto esttico especificado. Si utilizamos conexiones a nivel de
red local, en principio toda esta asignacin de puertos nos dara igual, salvo por
algn firewall que nos este capando la conectividad, pero es cuando utilizamos
conexin va Internet, cuando debemos controlar estos aspectos si queremos
mantener un cierto grado de seguridad en nuestro Servidor. Para "solucionar" esto,
podramos hacer que una instancia determinada escuche en varios puertos
estticos.

Pero antes de ver como configurar una instancia de SQL Server para que escuche
por varios puertos estticos, es ms que conveniente saber cmo podemos conocer
en qu puerto corre una instancia determinada.

Conocer en qu puerto corre una instancia determinada

Tenemos varias opciones, y todas ellas son interesantes porque puede darse el
caso de que en alguna ocasin no dispongamos de determinadas herramientas y
necesitemos conocer estos datos de algn otro modo.
1. Desde la Herramienta de red del servidor de SQL Server.

Iniciamos la Herramienta de red del servidor desde Inicio, Programas, Microsoft SQL
Server, Herramienta de red del servidor o tambin desde Inicio, Ejecutar y en el
cuadro Abrir escribimos svrnetcn.exe y hacemos clic en Aceptar.

Hacemos clic en la ficha General, seleccionamos de la lista nuestra instancia de

SQL Server.
En el cuadro de lista Protocolos habilitados, hacemos clic en TCP/IP y a
continuacin clic en Propiedades.

3. Mediante una instruccin de red en Windows XP.

Si abrimos ms-dos y ejecutamos la instruccin netstat -abn en el servidor, tambin

podremos comprobar en qu puerto est corriendo una instancia determinada de
SQL Server.
La opcin -b que es la que muestra el ejecutable y el puerto de escucha, solo est
disponible en Windows XP.
Adicionalmente si no nos encontramos en el servidor, podemos lanzar contra l
desde nuestra maquina, la instruccin osql -S nombre_instancia -U sa. Esta
instruccin nos abre una conexin contra la instancia indicada a modo de analizador
de consultas. No es necesario que efectuemos ninguna consulta, porque lo nico
que nos interesa es que hemos abierto una conexin desde nuestra maquina hacia
el Servidor, por lo que si ahora hacemos un netstat -abn en nuestra maquina, y
consultamos el resultado del comando, buscando la entrada que hace referencia al
ejecutable [osql.exe] podremos ver las Ip de origen y destino as como los puertos
por los que se establece la conexin.
Configurar el puerto de escucha de una instancia de SQL Server

Ahora s, para configurar el puerto de forma esttica, accedemos mediante la

Herramienta de red del servidor a las propiedades de TCP/IP de nuestra instancia
y pulsamos propiedades, el puerto que aparece como predeterminado es el puerto
esttico que se est utilizando, si queremos asignar varios, solo debemos ir
aadindolos uno detrs de otro, seguidos por comas, por ejemplo: 1433,5000

Nota 1: Si el protocolo TCP/IP est deshabilitado, lo habilitamos ahora. Para ello,

clic en TCP/IP en el cuadro de lista Protocolos deshabilitados y a continuacin, clic
en Habilitar.
Nota 2: El puerto esttico que especifiquemos no debe ser igual que el puerto
dinmico en el que actualmente este escuchando otra instancia de SQL Server. Por
ejemplo, si una instancia de SQL Server escucha en el puerto TCP/IP dinmico
1400, escribiremos por ejemplo 1500 para el nuevo puerto esttico.

Si lo que queremos es que la asignacin de puerto se haga de forma dinmica,

deberemos poner el cero como puerto predeterminado.
Siempre que modifiquemos alguno de estos puertos, a continuacin deberemos
reiniciar la instancia de SQL Server.

CONFIGURACIONES NECESARIAS PARA REALIZAR LA REPLICA

CREANDO PUBLICACIN EN EL SERVIDOR

Como primer paso se ingresar a SQL Managment Studio desde el Servidor.
Se debe loguear con el usuario y contrasea establecidos durante la instalacin.

Si no hay dificultades con la cuenta, se establece la conexin al Servidor.

Creando la Base de Datos:
Para el ejemplo actual, se utiliza la Base de Datos: proyecto

Con la base de datos creada correctamente se procede a crear una tabla sencilla.

Se selecciona la opcin Crear una instantnea Inmediatamente.

En las configuraciones de seguridad, se debe introducir el usuario y contrasea de
SQL.

CREAR UNA BASE DE DATOS EN LA MAQUINA REPLICA

Se crea una base de datos en la mquina que se utilizara como Rplica, la cual debe dejarse sin ninguna
tabla, es decir, totalmente vaca, ya que es, en esta Base de Datos en donde se replicaran todas las tablas de
la Base de Datos del Servidor.
SUSCRIPCION AL SERVIDOR
Teniendo la publicacin creada, se debe dar paso a crear la suscripcin local. Clic derecho sobre
Suscripciones Locales, y elegir la opcin Nuevas suscripciones.

Datos reflejados en el Servidor:

Datos reflejados en la rplica:

Como se puede observar en el formulario, ya se cuenta con 5 registros en la tabla.

COMPROBAR CONEXIONES SERVIDOR-REPLICA-CLIENTE

Para poder constatar que la rplica de mezcla efectivamente puede suplir al servidor, se procede a
desconectar al servidor, y dejar nicamente el cliente conectado a la rplica.
Desconectando el servidor
Como se puede observar la aplicacin muestra un mensaje de error en la conexin al servidor, y
automticamente conecta a la rplica.
En la realidad cotidiana, este proceso es totalmente transparente al cliente, pero por razones de estudio se
han dejado estos mensajes de error, para poder monitorear cada paso de la conexin.
Conectado a la replica

Ahora se procede a desconectar tanto al servidor como a la replica

Se puede observar, que como falta el servidor, la aplicacin nuevamente intenta conectarse a la rplica.
Y debido a que tambin se desconecto la rplica, nuevamente muestra un error fatal en la conexin.

Y debido a que la aplicacin cliente no tiene conexin a la base de datos, muestra nicamente el formulario
vaco.

Para demostrar que la rplica de mezcla, efectivamente suple al servidor cuando ste falta, se procede a que
la aplicacin cliente, agregue datos a la rplica (Se obviaran los pasos en los que el cliente no se conecta al
servidor, pues estn detallados en capturas anteriores).

Agregando datos a la Rplica.

Se puede observar que ya se cuenta con un nuevo registro en la base de datos:
Y en efecto, los datos se ven reflejados en la rplica.

Ahora se procede a reconectar el servidor a la red, y la rplica debe ser capaz de enviarle automticamente
despus de 60 segundos, los datos agregados por el cliente.

RESUMEN

Con todo este proyecto queda demostrado el uso de las rplicas en los servidores,
para el caso particular la Rplica de Mezcla.
La Rplica de Mezcla, adems de hacer el back-up de la Base de Datos del Servidor
(comnmente por razones de seguridad), es capaz de brindar el mismo servicio que
ofrece el Servidor a los clientes, cuando ste por cualquier motivo se encuentre de
baja en las conexiones.
La rplica adems de suplirlo en la conexin de una forma completamente invisible
para el Cliente, es a la vez, totalmente capaz de enviarle todas las modificaciones
que la base de datos haya sufrido en su ausencia, cuando ste entra de nuevo a su
papel de servidor central