Integrar datos de varios sitios (Server)
Muchas compañías tienen oficinas o entidades regionales que recopilan y procesan datos que se deben enviar a una ubicación central. Por ejemplo:
Los datos de inventario se pueden acumular o consolidar en un servidor central que se encuentra en las oficinas centrales a partir de una serie de servidores que se encuentran en los almacenes locales.
La información de divisiones independientes de una misma compañía se puede enviar a un servidor central.
La información sobre el orden de procesamiento de las diversas ubicaciones se puede consolidar.
En algunos casos, los datos también se envían desde el sitio central a los sitios remotos. Normalmente, se intenta que estos datos sean de sólo lectura en el sitio remoto, por ejemplo un conjunto de tablas de inventario de productos que sólo se actualizan en el sitio central.
En el siguiente diagrama se muestra un caso típico en el que se acumulan los datos de los sitios remotos. Los datos de sólo lectura también se envían a cada sitio remoto.
.gif "Replicar datos para oficinas regionales")
Ejemplo de Adventure Works Cycles
Adventure Works Cycles es una compañía ficticia que se utiliza para mostrar situaciones y conceptos de bases de datos. Para obtener más información, vea Bases de datos de ejemplo AdventureWorks2008R2.
Adventure Works Cycles tiene varias oficinas de ventas regionales en Estados Unidos. Las oficinas utilizan la replicación de dos maneras:
Para proporcionar información sobre pedidos con fines de cumplimiento de pedidos y creación de informes. Los datos se recopilan y se procesan en cada oficina de ventas y después se replican en la oficina central.
Para proporcionar datos y capacidades de realización de pedidos al personal de ventas móvil. Este escenario se describe en el tema Intercambiar datos con usuarios móviles.
Requisitos comunes para este escenario
Las aplicaciones para oficinas regionales suelen tener los siguientes requisitos, que debe satisfacer una solución de replicación adecuada:
El sistema debe mantener la coherencia transaccional.
El sistema debe tener latencia baja: las actualizaciones en los sitios remotos deben llegar al sitio central rápidamente.
El sistema debe tener un rendimiento alto: debe controlar la replicación de un gran número de transacciones.
El proceso de replicación debe producir una sobrecarga mínima en los sitios remotos.
Los cambios de datos pueden fluir en las dos direcciones: en algunos casos, los datos de sólo lectura se envían a sitios remotos, además de que los datos se consolidan desde los sitios remotos al sitio central.
Los datos requeridos en el sitio central deben ser un subconjunto de los datos disponibles en cada sitio remoto.
Tipo de replicación que se debe utilizar en este escenario
Microsoft SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de replicación. Los componentes incluyen el publicador, los suscriptores, las publicaciones y artículos, y las suscripciones.
En el diagrama anterior, el sitio remoto es un publicador. Algunos o todos los datos del sitio remoto se incluyen en la publicación, en la que cada tabla de datos es un artículo (los artículos también pueden ser otros objetos de base de datos, por ejemplo procedimientos almacenados). El sitio central es un suscriptor de estas publicaciones y recibe el esquema y los datos como suscripciones.
El sitio central también hace las veces de publicador para los datos que se envían a los sitios remotos. Cada sitio remoto se suscribe a la publicación del sitio central.
Para obtener más información sobre los componentes del sistema, vea Información general del modelo de publicación de replicación.
SQL Server ofrece diferentes tipos de replicación para distintos requisitos de aplicación: replicación de instantáneas, replicación transaccional y replicación de mezcla. La mejor implementación para este escenario es la replicación transaccional, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la replicación transaccional, vea Información general de la replicación transaccional y Cómo funciona la replicación transaccional.
Por diseño, la replicación transaccional satisface los requisitos principales de este escenario:
Coherencia transaccional
Latencia baja
Rendimiento alto
Sobrecarga mínima
Nota
Un escenario similar se puede implementar con la replicación de mezcla. Utilice la replicación de mezcla si su aplicación requiere la resolución de conflictos o filtros que proporcionen a cada sitio remoto un conjunto de datos exclusivo. Para obtener más información, vea Integrar datos de varios sitios (cliente).
Pasos para implementar este escenario
Para implementar este escenario, primero debe crear una publicación y suscripciones y, a continuación, inicializar cada suscripción. Haga clic en los siguientes vínculos para obtener más información sobre cada paso:
Cuando la suscripción se haya inicializado y los datos fluyan entre el publicador y los suscriptores, es posible que necesite consultar los siguientes temas para obtener información sobre tareas habituales de administración y supervisión: