ARQUITECTURA CLIENTE SERVIDOR

Dirección: Loja y Olmedo Teléfono: 2962347 LENIN ROJAS BONILLA
Instituto Tecnológico Superior Particular
“SAN GABRIEL”
REGISTRO INSTITUCIONAL No. 224 CONESUP
Dirección: Loja y Olmedo
Teléfono: 2962-347
CLIENTE SERVIDOR
TEMA
MODELOS DE ADMINISTACION
DE SQL SERVER
POR:
LENIN O. ROJAS B.
DOCENTE:
Ing. WILLIAN ADRIANO.
MODALIDAD:
PRESENCIAL
RIOBAMBA ECUADOR
2016

“SAN GABRIEL”
Teléfono: 2962-347
SQL SERVER
MODELO DE REPLICACION
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: publicador,
distribuidor, suscriptor, publicación, artículo y suscripción; y varios agentes
responsabilizados de copiar los datos entre el publicador y el suscriptor. A los tipos
básicos de replicación (de instantáneas, transaccional y de mezcla), se le incorporan
opciones para ajustarse aún más a los requerimientos del usuario.
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. [Elm00]
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 [Mic01].
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: publicador,
distribuidor, suscriptores, publicaciones, artículos y suscripciones [Mic01].

“SAN GABRIEL”
Teléfono: 2962-347
COMPONENTES DEL MODELO DE REPLICACIÓN
Para representar los componentes y procesos de una topología de replicación se
utilizan metáforas de la industria de la publicación. El modelo se compone de los
siguientes objetos: el publicador, el distribuidor, el suscriptor, la publicación, el
artículo y la suscripción; 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 instantáneas, agente de distribución, agente del lector
del registro, agente del lector de cola y agente de mezcla [Mic01].
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: publicador, distribuidor o
suscriptor.
El publicador es un servidor que pone los datos a disposición de otros servidores
para poder replicarlos. El distribuidor es un servidor que aloja la base de datos de
distribución y almacena los datos históricos, transacciones y metadatos. Los
suscriptores reciben los datos replicados.
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 indizada o
una función definida por el usuario.
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.
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.
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.

“SAN GABRIEL”
Teléfono: 2962-347
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 [Mic01].
ESCENARIOS TÍPICOS DE LA REPLICACIÓN
En una solución de replicación pudiera ser necesario utilizar varias publicaciones en
una combinación de metodologías y opciones. En la replicación los datos o
transacciones fluyen del publicador al suscriptor pasando por el distribuidor.
Por lo tanto en su configuración mínima una topología de replicación se compone de
al menos dos o tres servidores SQL Server que desempeñan los tres roles
mencionados.
Variando la ubicación del servidor distribuidor podríamos contar con las siguientes
variantes:
El rol de distribuidor desempeñado por el publicador
El rol de distribuidor desempeñado por el suscriptor
Un servidor de distribución, independiente del publicador y del suscriptor
Fig.1 Publicador-Distribuidor Fig.2 Distribuidor-Suscriptor Fig. 3 Distribuidor independiente
En la mayoría de las configuraciones, el peso fundamental de la replicación recae,
sobre el servidor de distribución. Por tanto éste puede ser un criterio para determinar
su ubicación, teniendo en cuenta las configuraciones (posibilidades físicas) de los
servidores, así como otras responsabilidades que pueden estar desempeñando
(servidor de dominio, servidor de páginas web entre otras) [Mic01].
Existe la posibilidad de contar con un servidor que se suscriba a una publicación y a
la vez la publique para el resto de los suscriptores, esto puede ser muy útil cuando se
cuente con una conexión 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 actúa como servidor de publicación para los servidores de Varadero, Cayo
Coco, Cayo Largo y demás. Evidentemente en una configuración tal pueden
nuevamente combinarse la ubicación de los dos distribuidores y aumentar el número

“SAN GABRIEL”
Teléfono: 2962-347
de variantes que pueden presentarse pero las consideraciones para determinar la
ubicación del servidor que fungirá como distribuidor son las ya mencionadas.
TIPOS DE REPLICACIÓN
Los tipos básicos de replicación son:
 replicación de instantáneas
 replicación transaccional
 replicación de mezcla
Para ajustarse aún más a los requerimientos de los usuarios se incorporan opciones
como son la actualización inmediata en el suscriptor, la actualización en cola y la
transformación de datos replicados [Mic01].
REPLICACIÓN DE INSTANTÁNEAS
En la replicación de instantáneas 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 instantáneas se suelen
replicar con menos frecuencia que otros tipos de publicaciones. Puede llevar
más tiempo propagar las modificaciones de datos a los suscriptores. Se recomienda
utilizar: cuando la mayoría de los datos no cambian con frecuencia; se replican
pequeñas cantidades de datos; los sitios con frecuencia están desconectados y es
aceptable un periodo de latencia largo (la cantidad de tiempo que transcurre entre la
actualización de los datos en un sitio y en otro). En ocasiones se hace necesario
utilizarla cuando están 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 metodología de replicación transaccional.
Los servidores OLAP son candidatos a la replicación de instantáneas. Las consultas
ad-hoc que aplican los administradores de sistemas de información son
generalmente de solo lectura y los datos con antigüedad de horas o días no afectan
sus consultas.
Por ejemplo un departamento desea hacer una investigación sobre demografía de los
artículos vendidos hace dos meses. La información de la semana pasada no afectará
sus consultas; además el departamento no está planeando hacer cambio en los datos,
solo necesita el almacén de datos. Hay que destacar además que cuando están
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 replicación de instantáneas, al menos como una solución parcial.
Con la opción de actualización 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

“SAN GABRIEL”
Teléfono: 2962-347
realizar cambios en el suscriptor. Esta opción es útil en escenarios en los que tienen
lugar unas cuantas modificaciones ocasionales en los servidores suscriptor.
REPLICACIÓN TRANSACCIONAL
En este caso se propaga una instantánea inicial de datos a los suscriptores, y
después, cuando se efectúan 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
propagación de los cambios, todos los suscriptores tendrán los mismos valoresque el
publicador. Suele utilizarse cuando: se desea que las modificaciones de datos se
propaguen a los suscriptores, normalmente pocos segundos después de producirse;
se necesita que las transacciones sean atómicas, que se apliquen todas o ninguna al
suscriptor; los suscriptores se conectan en su mayoría al publicador; su aplicación
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
sólo lectura, pere necesitan cambios a los datos con una cantidad mínima de
latencia. Ejemplo: un sistema para el procesamiento y distribución de pedidos. En
este tipo de escenario, podría tener varios publicadores recibiendo pedidos de
mercancías. Estos pedidos se replican entonces a un almacén central donde se
despachan los pedidos. El almacén puede tratar los datos como de sólo lectura y
requiere nueva información en forma periódica.
Con el uso de la opción de atualización inmediata en el suscriptor se pierde aún más
la autonomía 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) también en la base de datos publicador en una
confirmación de dos fases (2PC) por lo que si su modificación se confirma indica
que es válida y luego en cuestión de minutos, o según laplanificación hecha, estos
cambios son duplicados a las demás bases de datos suscriptoras.
REPLICACIÓN DE MEZCLA
Permite que varios sitios funcionen en línea o desconectados de manera autónoma, y
mezclar más adelante las modificaciones de datos realizadas en un resultado único y
uniforme. La instantánea inicial se aplica a los suscriptores; a continuación 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 petición. Las actualizaciones se realizan de manera
independiente, sin protocolo de confirmación, en más de un servidor, así el
publicador o más 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 resolución para
determinar qué datos se aceptarán y se propagarán a otros sitios. Es útil cuando:

“SAN GABRIEL”
Teléfono: 2962-347
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 conexión y sincronizar más adelante los cambios con el
publicador y otros suscriptores; el requisito de periodo de latencia de la aplicación
es largo o corto; la autonomía 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 información de los otros sitios. Por ejemplo podría
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 MÉTODO DE REPLICACIÓN A UTILIZAR
En la elección de un método adecuado para la distribución de los datos en una
organización influyen varios factores. Los cuales podemos agruparlos en
dos grupos: factores relacionados con los requerimientos de la aplicación y factores
relacionados con el entorno de red.
Dentro de los factores relacionados con los requerimientos de la aplicación, los
fundamentales son [Gar99]:
 Autonomía
 Consistencia transaccional
 Latencia
La autonomía 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 sincronía? O si es admisible
determinada latencia ¿de qué tamaño es aceptable el rezago? [Gar99].
Entre los factores relacionados con el entorno de red están la velocidad de
transmisión de datos de la red, deben considerarse preguntas como ¿Cómo luce la
red? ¿Es rápida? Debe analizarse además la confiabilidad de la red y responder
preguntas como ¿Cuán confiable es la red? Por otra parte en el caso que los
servidores SQL no permanezcan todo el día encendidos, como pudiera suceder en
algunas organizaciones, deben considerarse los horarios de disponibilidad de cada
servidor.
La consideración de estos factores sirven de guía en la configuración
del ambiente de replicación. Además debe considerar las siguientes preguntas: ¿Qué
datos se van a publicar? ¿Reciben todos los suscriptores todos los datos o sólo
subconjuntos de ellos? ¿Se deben particionar los datos por sitio? ¿Se debe permitir
que los suscriptores envíen actualizaciones de los datos? Y en caso de permitirlas

“SAN GABRIEL”
Teléfono: 2962-347
¿Cómo deben implementarse? ¿Quiénes pueden tener acceso a los datos? ¿Se
encuentran estos usuarios en línea? ¿Se encuentran conectados mediante enlaces
caros?
FASES GENERALES PARA IMPLEMENTAR Y SUPERVISAR LA
REPLICACIÓN
A pesar de que existen varias formas de implementar y supervisar la replicación, y
el proceso de replicación es diferente según el tipo y las opciones elegidas, en
general, la replicación se compone de las siguientes fases:
 configuración de la replicación
 generación y aplicación de la instantánea inicial
 modificación de los datos replicados
 sincronización y propagación de los datos.
Información general del modelo de publicación de replicación
La replicación utiliza una metáfora del sector editorial para representar los
componentes de una topología de replicación, que incluyen el publicador, el
distribuidor, los suscriptores, las publicaciones, los artículos y las suscripciones.
Resulta útil pensar en la replicación de Microsoft SQL Server como si fuera una
revista:
 El publicador (editor) de una revista produce una o más publicaciones.
 Una publicación contiene artículos.
 El publicador distribuye la revista directamente o a través de un
distribuidor.
 Los suscriptores reciben las publicaciones a las que se han suscrito.
Aunque la metáfora de la revista es útil para comprender la replicación, es
importante señalar que la replicación de SQL Server incluye funciones que no están
representadas en esta metáfora, en particular, la posibilidad de que un suscriptor
realice actualizaciones y de que un publicador envíe cambios incrementales a los
artículos de una publicación.
Una topología de replicación define la relación entre los servidores y las copias de
los datos, y aclara la lógica que determina cómo fluyen los datos entre los
servidores. Hay varios procesos de replicación (denominados agentes) que son
responsables de copiar y mover los datos entre el publicador y los suscriptores. En la
siguiente ilustración se muestra información general acerca de los componentes y
procesos que participan en la replicación.

“SAN GABRIEL”
Teléfono: 2962-347
Publicador
El publicador es una instancia de base de datos que permite que los datos estén
disponibles para otras ubicaciones a través de la replicación. El publicador puede
tener una o más publicaciones, cada una de las cuales representa un conjunto de
objetos y datos relacionados lógicamente para replicar.
Distribuidor
El distribuidor es una instancia de base de datos que funciona como almacén para
datos específicos de replicación asociados con uno o más publicadores. Cada
publicador está asociado con una sola base de datos (conocida como la base de datos
de distribución) en el distribuidor. La base de datos de distribución almacena los
datos de estado de la replicación, metadatos acerca de la publicación y, en algunos
casos, funciona como cola para los datos que se transfieren del publicador a los
suscriptores. En muchos casos, una sola instancia de servidor de bases de datos
funciona como publicador y como distribuidor Esto se conoce como un distribuidor
local. Cuando el publicador y el distribuidor se configuran en instancias distintas del
servidor de bases de datos, el distribuidor se denomina un distribuidor remoto.
Suscriptores
Un suscriptor es una instancia de base de datos que recibe datos replicados. Un
suscriptor puede recibir datos de varios publicadores y publicaciones. En función
del tipo de replicación elegida, el suscriptor también puede devolver los datos
modificados al publicador o volver a publicar los datos en otros suscriptores.
Artículo
Un artículo identifica un objeto de base de datos incluido en una publicación. Una
publicación puede contener diferentes tipos de artículos, como tablas, vistas,
procedimientos almacenados y otros objetos. Cuando las tablas se publican como

“SAN GABRIEL”
Teléfono: 2962-347
artículos, se pueden usar filtros para restringir las columnas y filas de datos que se
envían a los suscriptores.
Publicación
Una publicación es un conjunto de uno o más artículos de una base de datos. La
agrupación de varios artículos en una publicación permite especificar más
fácilmente un conjunto de objetos y datos de bases de datos relacionados
lógicamente, que se replican como una unidad.
Suscripción
Una suscripción es una solicitud de una copia de una publicación que se entrega a
un suscriptor. La suscripción define qué publicación se recibirá, dónde y cuándo.
Hay dos tipos de suscripciones: de inserción y de extracción. Para obtener más
información acerca de las suscripciones de inserción y de extracción,
vea Suscribirse a publicaciones.
EXTRACCIÓN DE DATOS DEL SERVIDOR PARA EL CLIENTE
El acceso a datos remotos se inicia a menudo extrayendo datos de un servidor de
Microsoft SQL Server e insertándolos en una base de datos cliente de SQL Server
Compact 3.5. Cuando se extraen los datos de un servidor y se insertan en un cliente,
SQL Server Compact 3.5 inicia la extracción. SQL Server Compact 3.5 extrae datos
de una base de datos de SQL Server y los almacena en una tabla de una base de
datos de SQL Server Compact 3.5.
Para extraer datos del servidor, puede configurar RDA mediante programación en la
aplicación. Cuando configure e inicie una operación de extracción con cualquiera de
estas técnicas, tendrá que especificar lo siguiente:

“SAN GABRIEL”
Teléfono: 2962-347
 La base de datos de la que desea extraer los datos.
 La autenticación del servidor web necesario para conectarse a un
servidor web.
 La autenticación de SQL Server utilizada.
 Las tablas que se copiarán y propagarán al cliente.
 Las opciones de extracción, incluidos el seguimiento y una tabla de
errores.
Seguimiento
Una aplicación puede realizar un seguimiento de los cambios efectuados en una
tabla de SQL Server Compact 3.5 estableciendo las opciones de seguimiento
correspondientes. SQL Server Compact 3.5 realiza un seguimiento de todas las
inserciones, actualizaciones y eliminaciones.
A continuación, las aplicaciones pueden llamar al método Push para propagar los
cambios de vuelta en la tabla original de SQL Server.
Las operaciones de extracción e inserción cuyo seguimiento se ha realizado
mediante el acceso a datos remoto (RDA) utilizan el control de simultaneidad
optimista. SQL Server no mantiene bloqueados los registros extraídos. Cuando la
aplicación llama a Push, los cambios realizados en la base de datos local de SQL
Server Compact 3.5 se aplican sin condiciones a la base de datos de SQL Server.
Esto puede ocasionar la pérdida de los cambios realizados por otros usuarios en la
base de datos de SQL Server.
Debe usar los métodos Pull y Push con seguimiento cuando los registros que esté
actualizando tengan particiones lógicas y no es probable que haya conflictos. Por
ejemplo, puede utilizar los métodos Pull y Push con seguimiento en una aplicación
de asistencia directa que realice un seguimiento de cada técnico con una lista única
de llamadas de asistencia.
RDA_TRACKOPTION especifica si SQL Server Compact 3.5 debe realizar un
seguimiento de los cambios realizados en la tabla extraída.
Especifique TRACKINGON o TRACKINGON_INDEXES si desea actualizar la
tabla extraída en el dispositivo basado en Windows Mobile y, a continuación,
insertar los registros modificados en la tabla original de SQL Server. Cuando se
especifica TRACKINGON, las restricciones PRIMARY KEY se crean en la tabla
extraída. Cuando se especifica TRACKINGON_INDEXES, las restricciones
PRIMARY KEY y los índices adicionales que existen en la tabla de servidores se
crean en la tabla extraída. En ambos casos, SQL Server Compact 3.5 realizará un
seguimiento de cada registro que se inserte, actualice o elimine en la tabla local.

“SAN GABRIEL”
Teléfono: 2962-347
Nota:
Los índices solo se crean si se extraen las columnas que los componen. En la tabla
extraída no se crea ninguna restricción de integridad referencial, ya que las tablas
relacionadas pueden existir o no en la base de datos de SQL Server Compact 3.5.
Éstas deben agregarse de nuevo mediante código dentro de la aplicación.
Cuando la aplicación llama al método Push, SQL Server Compact 3.5 usa la
información de seguimiento de los cambios para localizar los registros insertados,
actualizados y eliminados en la tabla local de SQL Server Compact 3.5 y
propagarlos de vuelta a la tabla de SQL Server.
Cuando RDA_TRACKOPTION se establece
en TRACKINGON o TRACKINGON_INDEXES, se aplican las siguientes
restricciones:
Si la instrucción SELECT devuelve un conjunto de registros no actualizable, se
produce un error.
Debe definirse una clave principal en el conjunto de registros actualizable devuelto
por la instrucción SELECT. La instrucción SELECT puede hacer referencia a una
vista o a un procedimiento almacenado, pero esta vista o este procedimiento
almacenado debe hacer referencia solo a una tabla y debe ser actualizable.
Cuando se especifica TRACKINGON_INDEXES, los índices que existen en la
tabla de SQL Server y que son relevantes para las columnas especificadas
en SQLSelectString se crean en la tabla local de SQL Server Compact 3.5
especificada en LocalTableName.
Inserción de datos eficiente en MySQL

“SAN GABRIEL”
Teléfono: 2962-347
De vez en cuando hacemos inserciones que implican cientos (e incluso miles) de
filas en un corto espacio de tiempo, por ejemplo al importar datos de una fuente
externa. Cuando esto ocurre el rendimiento puede verse muy mermado, y para
evitarlo enumero a continuación algunas posibles optimizaciones a tener en cuenta.
Si insertamos los datos de una sola vez:
1. Si es posible, usar LOAD DATA INFILE. Esto proporciona beneficios en
cuanto al rendimiento reduciendo la cantidad de trabajo a realizar por cliente
y servidor al preparar los datos para su inserción en la tabla.
2. Desactivar temporalmente la creación de índices al insertar grandes
cantidades de datos. Esto permite la creación de los índices de la tabla de
forma más eficiente después de que la información esté ya en la tabla. Para
ello utilizaremos la sentencia ALTER TABLE:
3. [sql]
ALTER TABLE tabla DISABLE KEYS;
# Sentencias de insercion
ALTER TABLE tabla ENABLE KEYS;
[/sql]
4. Para las tablas MyISAM, bloquear la tabla mientras se insertan los datos
para prevenir lecturas que puedan enlentecer las escrituras. Tal y como vemos
a continuación:
5. [sql]
LOCK TABLES tabla WRITE;
# Sentencias de inserción
UNLOCK TABLES;
[/sql]
6. En el caso de InnoDB, realizaremos las inserciones dentro de
una transacción:
7. [sql]
BEGIN;
# Sentencias de inserción
COMMIT;
[/sql]
8. Usar INSERTs multifila. Este tipo de sentencias reducen la cantidad de
trabajo que tanto cliente como servidor deben hacer para procesar una
consulta antes de que los datos sean escritos en la tabla. Así:
9. [sql]
INSERT INTO tabla (a,b,c) VALUES (1,2,3), (4,5,6), (7,8,9);
[/sql]

“SAN GABRIEL”
Teléfono: 2962-347
10.Si la tabla en la que insertamos no está vacía, podemos modificar la variable
de sistemabulk_insert_buffer_size.
En el caso de que entre las inserciones se produzcan lecturas, podemos llevar a
cabo las siguientes optimizaciones:
1. En MyISAM, activar la opción DELAY_KEY_WRITE. Esto reduce las
escrituras a disco que MySQL hace cuando crea nuevas entradas en el índice
de la tabla. Se realiza con una sentencia ALTER TABLE:
[sql]
ALTER TABLE tabla DELAY_KEY_WRITE = 1;
[/sql]
Ojo: si el servidor cae, las tablas que tengan la opción
DELAY_KEY_WRITE activada pueden tener índices incompletos. Para
asegurarnos de que los índices estén completos, cuando volvamos a lanzar el
servidor lo haremos con la coletilla --myisam-recover=BACKUP,FORCE.
2. Usar InnoDB. Este tipo de tablas manejan mucho mejor que MyISAM las
lecturas y escrituras concurrentes.
3. No escribir desde la tabla de la que se está leyendo. Es mejor crear una
tabla adicional para manejar las escrituras y después fusionar las filas desde la
tabla de escrituras en la tabla de lectura a intervalos regulares.
INFORMACIÓN GENERAL SOBRE LOS AGENTES DE REPLICACIÓN
La replicación utiliza varios programas independientes, llamados agentes, para
realizar las tareas asociadas con el seguimiento de los cambios y la distribución de
los datos. De forma predeterminada, los agentes de replicación se ejecutan como
trabajos programados en el Agente SQL Server y es necesario que se esté
ejecutando el Agente SQL Server para que puedan ejecutarse los trabajos. Los
agentes de replicación también se pueden ejecutar desde la línea de comandos y en
aplicaciones que utilizan Replication Management Objects (RMO). Los agentes de
replicación se pueden administrar desde el Monitor de replicación de SQL Server y
SQL Server Management Studio.
Agente SQL Server
El Agente SQL Server hospeda y programa los agentes utilizados en la replicación,
y proporciona una manera sencilla de ejecutar los agentes de replicación. El Agente
SQL Server también controla y supervisa las operaciones fuera de la replicación.
Para obtener más información, vea Configurar el Agente SQL Server.

“SAN GABRIEL”
Teléfono: 2962-347
Importante
De manera predeterminada, el servicio del Agente SQL Server está deshabilitado
cuando se instala SQL Server, a menos que se elija explícitamente iniciar el servicio
automáticamente durante la instalación. Para obtener más información sobre cómo
iniciar el servicio del Agente SQL Server, veaIniciar, detener o pausar el servicio
del Agente SQL Server.
Agente de instantáneas
Por lo general, el Agente de instantáneas se utiliza con todos los tipos de
replicación. Prepara esquemas y archivos de datos iniciales de tablas publicadas y
otros objetos, almacena los archivos de instantáneas y registra la información acerca
del estado de sincronización en la base de datos de distribución. El Agente de
instantáneas se ejecuta en el distribuidor. Para obtener más información, vea Agente
de instantáneas de replicación.
Agente de registro del LOG
El Agente de registro del LOG se utiliza en la replicación transaccional. Mueve las
transacciones marcadas para replicación desde el registro de transacciones del
publicador a la base de datos de distribución. Cada base de datos publicada con la
replicación transaccional tiene su propio Agente de registro del LOG, que se ejecuta
en el distribuidor y se conecta al publicador (el distribuidor puede estar en el mismo
equipo que el publicador). Para obtener más información, vea Agente de registro del
LOG de replicación.
Agente de distribución
El Agente de distribución se utiliza en la replicación de instantáneas y transaccional.
Aplica la instantánea inicial al suscriptor y mueve las transacciones contenidas en la
base de datos de distribución a los suscriptores. El Agente de distribución se ejecuta
en el distribuidor, para las suscripciones de inserción, o en el suscriptor, para las
suscripciones de extracción. Para obtener más información, vea Agente de
distribución de replicación.
Agente de mezcla
El Agente de mezcla se utiliza con la replicación de mezcla. Aplica la instantánea
inicial al suscriptor, y transfiere y reconcilia los cambios incrementales de datos que
se producen. Cada suscripción de mezcla tiene su propio Agente de mezcla, que se
conecta con el publicador y con el suscriptor, y los actualiza. El Agente de mezcla
se ejecuta en el distribuidor, para las suscripciones de inserción, o en el suscriptor,
para las suscripciones de extracción. De forma predeterminada, el Agente de mezcla

“SAN GABRIEL”
Teléfono: 2962-347
carga los cambios del suscriptor al publicador y, a continuación, descarga los
cambios del publicador al suscriptor. Para obtener más información, vea Agente de
mezcla de replicación.
Agente de lectura de cola
El Agente de lectura de cola se utiliza con la replicación transaccional y la opción de
actualización en cola. El agente se ejecuta en el distribuidor y transfiere los cambios
realizados en el suscriptor de vuelta al publicador. A diferencia del Agente de
distribución y del Agente de mezcla, solo existe una instancia del Agente de lectura
de cola para todos los publicadores y las publicaciones de una determinada base de
datos. Para obtener más información acerca del Agente de lectura de cola,
vea Agente de lectura de cola de replicación. Para obtener más información acerca
de las suscripciones actualizables, vea Suscripciones actualizables para replicación
transaccional.
Trabajos de mantenimiento de la replicación
La replicación incluye varios trabajos de mantenimiento que realizan operaciones de
mantenimiento programadas y a petición. Para obtener más información,
vea Administración del Agente de replicación.
Tipos de replicación
Microsoft SQL Server proporciona los siguientes tipos de replicación para usarlos
en las aplicaciones distribuidas:
 Replicación transaccional.
 Replicación de mezcla.
 Replicación de instantáneas. Para obtener más información, vea Replicación
de instantáneas.
El tipo de replicación que se elige para una aplicación depende de muchos factores,
como el entorno físico de la replicación, el tipo y la cantidad de datos que se desean
replicar y si los datos se actualizan en el suscriptor. El entorno físico incluye el
número y la ubicación de los equipos que participan en la replicación, y si estos
equipos son clientes (estaciones de trabajo, equipos portátiles o dispositivos de
mano) o servidores.
Por lo general, cada tipo de replicación comienza con una sincronización inicial de
los objetos publicados entre el publicador y los suscriptores. Esta sincronización
inicial puede llevarse a cabo mediante la replicación con una instantánea, que es
una copia de todos los objetos y datos especificados por una publicación. Una vez
creada la instantánea, se envía a los suscriptores. Para algunas aplicaciones, la
replicación de instantáneas es lo único que se necesita. Para otros tipos de
aplicaciones, es importante que los cambios de datos posteriores fluyan al suscriptor
de forma incremental a lo largo del tiempo. Algunas aplicaciones también requieren

“SAN GABRIEL”
Teléfono: 2962-347
que los cambios vuelvan del suscriptor al publicador. La replicación transaccional y
la replicación de mezcla proporcionan opciones para estos tipos de aplicaciones.
En la replicación de instantáneas, no se realiza un seguimiento de los cambios de
datos; cada vez que se aplica una instantánea, ésta sobrescribe completamente los
datos existentes. La replicación transaccional realiza un seguimiento de los cambios
a través del registro de transacciones de SQL Server y la replicación de mezcla
realiza un seguimiento de los cambios a través de desencadenadores y tablas de
metadatos.
Replicación transaccional
Normalmente, la replicación transaccional se inicia con una instantánea de los datos
y los objetos de la base de datos de publicaciones. En cuanto se obtiene la
instantánea inicial, los posteriores cambios de datos y modificaciones del esquema
realizados en el publicador habitualmente se entregan en el suscriptor cuando se
producen (casi en tiempo real). Los cambios de datos se aplican al suscriptor en el
mismo orden y dentro de los mismos límites de la transacción que cuando se
produjeron en el publicador. Por tanto, en una publicación, se garantiza la
coherencia transaccional.
La replicación transaccional se utiliza normalmente en entornos entre servidores y
es la adecuada en los siguientes casos:
 Se desea que se propaguen cambios incrementales a los suscriptores en el
momento en que ocurren.
 La aplicación requiere una latencia baja entre el momento en que se realizan
los cambios en el publicador y el momento en que llegan los cambios al
suscriptor.
 La aplicación necesita acceso a los estados intermedios de los datos. Por
ejemplo, si una fila cambia cinco veces, la replicación transaccional permite
que una aplicación responda a cada cambio (por ejemplo, la activación de un
desencadenador) y no solo al cambio de datos neto en la fila.
 El publicador tiene un volumen elevado de actividad de inserción,
actualización y eliminación.
 El publicador o el suscriptor es una base de datos que no es de SQL Server,
como Oracle.
De forma predeterminada, los suscriptores de publicaciones transaccionales deben
tratarse como de solo lectura, porque los cambios no se propagan de vuelta al
publicador. Sin embargo, la replicación transaccional ofrece opciones que permiten
realizar actualizaciones en el suscriptor
Cómo funciona la replicación transaccional
La replicación transaccional se implementa con el Agente de instantáneas, el Agente
de registro del LOG y el Agente de distribución de SQL Server. El Agente de

“SAN GABRIEL”
Teléfono: 2962-347
instantáneas prepara archivos de instantáneas que contienen esquemas y datos de las
tablas y objetos de base de datos publicados, almacena los archivos en la carpeta de
instantáneas y registra los trabajos de sincronización en la base de datos de
distribución del distribuidor.
El Agente de registro del LOG supervisa el registro de transacciones de cada base
de datos configurada para la replicación transaccional y copia las transacciones
marcadas para ser replicadas desde el registro de transacciones a la base de datos de
distribución, que actúa como una cola de almacenamiento y reenvío confiable. El
Agente de distribución copia los archivos de instantáneas iniciales de la carpeta de
instantáneas y las transacciones almacenadas en las tablas de la base de datos de
distribución a los suscriptores.
Los cambios incrementales realizados en el publicador se transfieren a los
suscriptores de acuerdo con la programación del Agente de distribución, que se
puede ejecutar continuamente para que la latencia sea mínima o a intervalos
programados. Puesto que los datos deben cambiarse en el publicador (cuando se
utiliza la replicación transaccional sin las opciones de actualización inmediata ni de
actualización en cola), se evita que se produzcan conflictos de actualización. Al
final, todos los suscriptores disponen de los mismos valores que el publicador. Si se
utilizan las opciones de actualización inmediata o de actualización en cola con la
replicación transaccional, las actualizaciones pueden realizarse en el suscriptor y,
con la actualización en cola, pueden producirse conflictos.
En la siguiente ilustración se muestran los principales componentes de la replicación
transaccional.

“SAN GABRIEL”
Teléfono: 2962-347
Conjunto de datos inicial
Antes de que un suscriptor de replicación transaccional pueda recibir los cambios
incrementales desde un publicador, debe contener tablas con el mismo esquema y
los mismos datos que las tablas del publicador. El conjunto de datos inicial es
normalmente una instantánea que se crea con el Agente de instantáneas y se
distribuye y aplica a través del Agente de distribución. También se puede
suministrar el conjunto de datos inicial mediante una copia de seguridad u otro
medio, como SQL Server Integration Services.
Cuando se distribuyen y se aplican instantáneas a los suscriptores, solo se ven
afectados los suscriptores que estén esperando instantáneas iniciales. Otros
suscriptores de esa publicación (aquellos que ya se han inicializado) no se ven
afectados.
Procesamiento simultáneo de instantáneas
La replicación de instantáneas coloca bloqueos compartidos en todas las tablas
publicadas como parte de la replicación mientras dure la generación de instantáneas.
Así se puede evitar que se realicen actualizaciones en las tablas de publicación. El
procesamiento simultáneo de instantáneas, que es el valor predeterminado con la

“SAN GABRIEL”
Teléfono: 2962-347
replicación transaccional, no mantiene los bloqueos compartidos durante la
generación completa de la instantánea, lo que permite a los usuarios continuar el
trabajo sin interrupción mientras la replicación crea los archivos de instantáneas
iniciales.
Los procedimientos por los que el Agente de instantáneas implementa la instantánea
inicial en la replicación transaccional son los mismos que se utilizan en la
replicación de instantáneas (excepto en lo indicado anteriormente acerca del
procesamiento simultáneo de instantáneas).
Después de generarse los archivos de instantáneas, podrá verlos en la carpeta de
instantáneas mediante el Explorador de Microsoft Windows.
Modificar datos y el Agente de registro del LOG
El Agente de registro del LOG se ejecuta en el distribuidor. Normalmente se ejecuta
de forma continua, pero también puede hacerlo siguiendo una programación
establecida. Al ejecutarse, el Agente de registro del LOG lee primero el registro de
transacciones de la publicación (el mismo registro de la base de datos que se utiliza
para el seguimiento de las transacciones y la recuperación durante las operaciones
normales del motor de base de datos de SQL Server) e identifica las instrucciones
INSERT, UPDATE y DELETE, u otras modificaciones efectuadas en los datos de
las transacciones que se hayan marcado para ser replicadas. A continuación, el
agente copia por lotes dichas transacciones a la base de datos de distribución del
distribuidor. El Agente de registro del LOG utiliza el procedimiento almacenado
interno sp_replcmds para obtener el siguiente conjunto de comandos marcados para
replicación desde el registro. La base de datos de distribución se convierte así en una
cola de almacenamiento y reenvío desde la que se envían los cambios a los
suscriptores. A la base de datos de distribución solo se envían las transacciones
confirmadas.
El lote completo de transacciones se confirma después de que se ha escrito
correctamente en la base de datos de distribución. A continuación de la
confirmación de cada lote de comandos en el distribuidor, el Agente de registro del
LOG llama a sp_repldone para marcar hasta dónde se ha llegado en la replicación.
Por último, el agente marca las filas del registro de transacciones que están listas
para ser purgadas. Las filas que están en espera de ser replicadas no se purgan.
Los comandos de transacción se almacenan en la base de datos de distribución hasta
que se propagan a todos los suscriptores o hasta que se ha alcanzado el período
máximo de retención de distribución. Los suscriptores recibirán las transacciones en
el mismo orden en que fueron aplicadas en el publicador.
Agente de distribución
El Agente de distribución se ejecuta en el distribuidor para las suscripciones de
inserción y en el suscriptor para las suscripciones de extracción. El Agente mueve
las transacciones desde la base de datos de distribución al suscriptor. Si se ha

“SAN GABRIEL”
Teléfono: 2962-347
marcado una suscripción para validarla, el Agente de distribución comprueba
también si los datos en el publicador y en el suscriptor coinciden.
Replicación de mezcla
La replicación de mezcla, como la replicación transaccional, normalmente se inicia
con una instantánea de los objetos y datos de una base de datos de publicaciones.
Los cambios de datos y las modificaciones de esquema posteriores que se lleven a
cabo en el publicador y en los suscriptores se controlan mediante desencadenadores.
El suscriptor se sincroniza con el publicador cuando están conectados a la red e
intercambian todas las filas que han cambiado entre el publicador y el suscriptor
desde la última vez que se produjo la sincronización.
La replicación de mezcla se suele utilizar en entornos de servidor a cliente. La
replicación de mezcla es adecuada en las siguientes situaciones:
 Varios suscriptores actualizan los mismos datos en diferentes ocasiones y
propagan los cambios al publicador y a otros suscriptores.
 Los suscriptores necesitan recibir datos, realizar cambios sin conexión y
sincronizar más adelante los cambios con el publicador y otros suscriptores.
 Cada suscriptor requiere una partición de datos diferente.
 Se pueden producir conflictos y, cuando ocurren, debe poder detectarlos y
resolverlos.
 La aplicación requiere el cambio de datos neto en lugar de acceso a los
estados intermedios de los datos. Por ejemplo, si una fila cambia cinco veces
en el suscriptor antes de que éste se sincronice con el publicador, la fila
cambiará solo una vez en el publicador para reflejar el cambio de datos neto
(es decir, el quinto valor).
La replicación de mezcla permite que diferentes sitios funcionen de forma autónoma
y, después, mezclen las actualizaciones en un solo resultado uniforme. Puesto que
las actualizaciones tienen lugar en más de un nodo, los mismos datos pueden haber
sido actualizados por el publicador y por más de un suscriptor. Por lo tanto, se
pueden producir conflictos al mezclar las actualizaciones y la replicación de mezcla
proporciona varias maneras de controlar los conflictos.
El Agente de instantáneas y el Agente de mezcla de SQL Server implementan la
replicación de mezcla. Si la publicación no se filtra o utiliza filtros estáticos, el
Agente de instantáneas crea una sola instantánea. Si la publicación utiliza filtros con
parámetros, el Agente de instantáneas crea una instantánea para cada partición de
datos. El Agente de mezcla aplica las instantáneas iniciales a los suscriptores.
También combina los cambios incrementales de los datos que tienen lugar en el
publicador o en los suscriptores después de la creación de la instantánea inicial y
detecta y resuelve los conflictos según las reglas que configure.

“SAN GABRIEL”
Teléfono: 2962-347
Para realizar un seguimiento de los cambios, la replicación de mezcla (y la
replicación transaccional con suscripciones de actualización en cola) deben poder
identificar de forma única cada fila de todas las tablas publicadas. Para conseguirlo,
l.La replicación de mezcla agrega la columna rowguid a todas las tablas, a menos
que la tabla ya tenga una columna del tipo de datos uniqueidentifier con la
propiedad ROWGUIDCOL definida (en cuyo caso se usa dicha columna). Si la
tabla se quita de la publicación, la columna rowguid se quita; si se ha usado una
columna existente para realizar el seguimiento, la columna no se quita. Un filtro no
debe incluir la columna rowguidcol que usa la replicación para identificar filas. La
función newid() se proporciona como valor predeterminado para la columna
de rowguid; no obstante, los clientes pueden proporcionar un GUID para cada fila
si es necesario. Sin embargo, no proporcione el valor 00000000-0000-0000-0000-
000000000000.
En el siguiente diagrama se muestran los componentes que se utilizan en la
replicación de mezcla.

“SAN GABRIEL”
Teléfono: 2962-347
Replicación de instantáneas
La replicación de instantáneas distribuye los datos exactamente como aparecen en
un momento específico en el tiempo y no supervisa las actualizaciones de los datos.
Cuando se produce la sincronización, se genera la instantánea completa y se envía a
los suscriptores.
Nota
La replicación de instantáneas se puede utilizar por sí sola, pero el proceso de
instantáneas (que crea una copia de todos los objetos y datos especificados por una
publicación) se utiliza habitualmente para proporcionar el conjunto inicial de datos y
objetos de base de datos para las publicaciones transaccionales y de combinación.
El uso independiente de la replicación de instantáneas es más apropiado cuando se
cumple una o más de las siguientes condiciones:
 Los datos no cambian con frecuencia.
 Es aceptable disponer de copias de datos desfasados respecto al publicador
durante un período de tiempo.
 se duplican pequeñas cantidades de datos.
 Hay un gran volumen de cambios en un corto período de tiempo.
La replicación de instantáneas es más apropiada cuando los cambios de datos son
importantes, pero poco frecuentes. Por ejemplo, si una organización de ventas
mantiene una lista de precios de productos y todos los precios se actualizan al
mismo tiempo una o dos veces al año, es recomendable replicar la instantánea
completa de los datos una vez que han cambiado. Para determinados tipos de datos
pueden ser adecuadas también instantáneas más frecuentes. Por ejemplo, si una tabla
relativamente pequeña se actualiza en el publicador durante el día pero es aceptable
cierta latencia, los cambios se pueden entregar por la noche como una instantánea.
La replicación de instantáneas tiene una carga continua más reducida en el
publicador que la replicación transaccional, ya que no se realiza ningún seguimiento
de los cambios incrementales. No obstante, si el conjunto de datos que se está
replicando es muy grande, será necesaria una cantidad importante de recursos para
generar y aplicar la instantánea. Tenga en cuenta el tamaño del conjunto de datos
entero y la frecuencia de los cambios en los datos al evaluar si utiliza o no la
replicación de instantáneas.
Cómo funciona la replicación de instantáneas
De forma predeterminada, los tres tipos de replicación utilizan una instantánea para
inicializar suscriptores. El Agente de instantáneas de SQL Server siempre genera los
archivos de instantáneas, pero el agente que entrega los archivos varía según el tipo

“SAN GABRIEL”
Teléfono: 2962-347
de replicación que se utilice. La replicación de instantáneas y la replicación
transaccional utilizan el Agente de distribución para entregar los archivos, mientras
que la replicación de mezcla utiliza el Agente de mezcla de SQL Server. El Agente
de instantáneas se ejecuta en el distribuidor. El Agente de distribución y el Agente
de mezcla se ejecutan en el distribuidor para las suscripciones de inserción o en los
suscriptores para las suscripciones de extracción.
Las instantáneas se pueden generar y aplicar inmediatamente tras la creación de la
suscripción o de acuerdo con una programación establecida en el momento de crear
la publicación. El Agente de instantáneas prepara archivos de instantáneas que
contienen el esquema y los datos de las tablas y objetos de base de datos publicados,
almacena los archivos en la carpeta de instantáneas del publicador y registra la
información de seguimiento en la base de datos de distribución del distribuidor. Al
configurar un distribuidor se especifica la carpeta de instantáneas predeterminada,
pero puede especificar una ubicación alternativa para una publicación en lugar de, o
además de, la predeterminada.
Además del proceso de instantáneas estándar descrito en este tema, se utiliza un
proceso de dos partes para las publicaciones de combinación con filtros con
parámetros.
En la ilustración siguiente se muestran los componentes principales de la replicación
de instantáneas.

“SAN GABRIEL”
Teléfono: 2962-347
Para la replicación de mezcla se genera una instantánea cada vez que se ejecuta el
Agente de instantáneas. Para la replicación transaccional, la generación de
instantáneas depende de la configuración de la propiedad de
publicación immediate_sync. Si la propiedad se define como TRUE (la opción
predeterminada cuando se utiliza el Asistente para nueva publicación), se genera
una instantánea cada vez que se ejecuta el Agente de instantáneas, y puede aplicarse
a un suscriptor en cualquier momento. Si la propiedad se define como FALSE (la
opción predeterminada cuando se utiliza sp_addpublication), la instantánea se
genera solo si se ha agregado una nueva suscripción desde la última ejecución del
Agente de instantáneas; los suscriptores deberán esperar a que el Agente de
instantáneas finalice para poder sincronizarse.
El Agente de instantáneas ejecuta los pasos siguientes:
1. Establece una conexión del distribuidor al publicador y, a continuación, si
fuera necesario, adopta bloqueos en las tablas publicadas:
 Para las publicaciones de combinación, el Agente de instantáneas no adopta
ningún bloqueo.

“SAN GABRIEL”
Teléfono: 2962-347
 Para las publicaciones transaccionales, el Agente de instantáneas adopta
bloqueos de manera predeterminada únicamente durante la fase inicial de la
generación de instantáneas.
 Para las publicaciones de instantáneas, adopta bloqueos durante todo el
proceso de generación de instantáneas.
2. Escribe una copia del esquema de la tabla para cada artículo en un archivo
.sch. Si se publican otros objetos de base de datos, como índices,
restricciones, procedimientos almacenados, vistas, funciones definidas por el
usuario, etc., se generan archivos de script adicionales.
3. Copia los datos de la tabla publicada en el publicador y escribe los datos en la
carpeta de instantáneas. La instantánea se genera como un conjunto de
archivos de programa de copia masiva (BCP).
4. En las publicaciones de instantáneas y transaccionales, el Agente de
instantáneas anexa filas a las
tablas MSrepl_commands yMSrepl_transactions de la base de datos de
distribución. Las entradas de la tabla MSrepl_commands son comandos que
indican la ubicación de los archivos .sch y .bcp, de cualquier otro archivo de
instantáneas y de las referencias a cualquier script anterior o posterior a la
instantánea. Las entradas de la tabla MSrepl_transactions son comandos
importantes para sincronizar el suscriptor.
5. En las publicaciones de combinación, el Agente de instantáneas realiza pasos
adicionales.
6. Libera los bloqueos de las tablas publicadas.
Durante la generación de instantáneas, no es posible realizar cambios en el esquema
de las tablas publicadas. Después de generar los archivos de instantáneas, podrá
verlos en la carpeta de instantáneas mediante el Explorador de Windows.
Agente de distribución y Agente de mezcla
En las publicaciones de instantáneas, cada vez que el Agente de distribución se
ejecuta para la publicación, mueve una nueva instantánea a cada suscriptor que aún
no se ha sincronizado, se ha marcado para volver a inicializarse o incluye nuevos
artículos.
En la replicación de instantáneas y transaccional, el Agente de distribución realiza
los siguientes pasos:
1. Establece una conexión con el distribuidor.
2. Examina las tablas MSrepl_commands y MSrepl_transactions de la base
de datos de distribución del distribuidor. El agente lee la ubicación de los
archivos de instantáneas de la primera tabla y los comandos de sincronización
del suscriptor de ambas tablas.

“SAN GABRIEL”
Teléfono: 2962-347
3. Aplica el esquema y los comandos a la base de datos de suscripciones.
En una publicación de replicación de mezcla sin filtrar, el Agente de mezcla realiza
los siguientes pasos:
1. Establece una conexión con el publicador.
2. Examina la tabla sysmergeschemachange del publicador y determina si
existe una nueva instantánea que deba aplicarse a éste.
3. Si hay una nueva instantánea disponible, el Agente de mezcla aplica los
archivos de instantáneas de la ubicación especificada
ensysmergeschemachange a la base de datos de suscripciones.

ARQUITECTURA CLIENTE SERVIDOR

Más contenido relacionado

La actualidad más candente

Similar a ARQUITECTURA CLIENTE SERVIDOR

Último

ARQUITECTURA CLIENTE SERVIDOR