Compartir a través de

Integrar datos de varios sitios (Server)

  • Artículo

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

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 Ejemplos y bases de datos de ejemplo.

Adventure Works Cycles tiene varias oficinas de ventas regionales en Estados Unidos. Las oficinas utilizan la réplica 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 réplica adecuada:

  • El sistema debe mantener la coherencia transaccional.
  • El sistema debe tener una latencia baja: las actualizaciones en los sitios remotos deben llegar rápidamente al sitio central.
  • El sistema debe tener un rendimiento alto: debe controlar la réplica de un gran número de transacciones.
  • El proceso de réplica debe producir una sobrecarga mínima en los sitios remotos.
  • Los cambios en los datos deben fluir en ambas direcciones: en algunos casos, los datos de sólo lectura se envían a los sitios remotos, además de los datos que se están consolidando desde los sitios remotos en el sitio central.
  • Los datos requeridos en el sitio central deben ser un subconjunto de los datos disponibles en cada sitio remoto.

Tipo de réplica que se debe utilizar en este escenario

Microsoft SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de réplica. 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 réplica.

SQL Server ofrece diferentes tipos de réplica para distintos requisitos de aplicación: réplica de instantáneas, réplica transaccional y réplica de mezcla. La mejor implementación para este escenario es la réplica transaccional, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la réplica transaccional, vea Información general de la réplica transaccional y Cómo funciona la réplica transaccional.

Por diseño, la réplica 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 réplica de mezcla. Utilice la réplica 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:

Vea también

Otros recursos

Replicar datos en un entorno de servidor a servidor

Ayuda e información

Obtener ayuda sobre SQL Server 2005