Integrar datos de varios sitios (cliente)

Muchas empresas tienen varias oficinas o entidades que recopilan y procesan datos que se deben enviar a una ubicación central. Por ejemplo:

• Los datos de inventario se pueden consolidar desde una serie de servidores situados en almacenes locales en un servidor de las oficinas centrales de la empresa.
• La información de divisiones empresariales autónomas de una empresa se puede enviar a un servidor central.
• Se puede consolidar la información de procesamiento de pedidos procedentes de ubicaciones dispersas.

En algunos casos, los datos también se envían desde el sitio central a sitios remotos. Normalmente, la intención es 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 un sitio central.

E el siguiente diagrama se ilustra un caso típico con datos que fluyen en dos direcciones entre un sitio central y ubicaciones remotas:

En este diagrama, los datos fluyen primero a un concentrador antes de pasar a las oficinas a las que dicho concentrador da servicio. También es posible que los datos fluyan directamente entre el sitio central y las oficinas si la organización no tiene un nivel intermedio.

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 un gran número de oficinas de venta en todo el mundo. Cada una de las oficinas de venta recopila datos de los equipos de venta regionales. Estos datos se transmiten a concentradores regionales y después al sitio central al término de cada día laborable. Los datos se transmiten también desde el sitio central a través de los concentradores a cada una de las oficinas de venta, de manera que la oficina de ventas disponga de la información más reciente sobre precios y promociones.

Requisitos comunes para este escenario

Las aplicaciones de las oficinas regionales normalmente tienen los siguientes requisitos, que una solución de réplica adecuada debe satisfacer:

• Los datos se escriben y actualizan en un sitio central y en los sitios remotos.
• Los usuarios remotos deben poder realizar actualizaciones de forma independiente, sin que sea necesaria una conexión con el sitio central.
• Puesto que varios usuarios pueden actualizar los mismos datos de forma independiente, pueden producirse conflictos de datos que deben solucionarse.
• Algunos datos sólo se deben actualizar en el sitio central, por ejemplo los datos de las tablas de precios de productos.
• Los usuarios deben poder sincronizar datos a petición o en momentos programados.
• La aplicación debe controlar cuánto tiempo puede permanecer un sitio remoto sin sincronizar.
• Algunas tablas requieren filtrado para que cada usuario reciba datos diferentes de una o varias tablas. Por ejemplo, una oficina regional recibe información de contacto sólo para los clientes de la región en la que se encuentra.
• Algunos datos deben ser tratados como una unidad cuando se transfieren entre los sitios. Por ejemplo, si un usuario remoto envía un pedido al sitio central, el encabezado del pedido debe confirmarse antes que los detalles del pedido.
• La aplicación puede requerir que se ejecute lógica de negocios personalizada cuando se sincronicen los datos.
• La aplicación puede requerir que los datos se sincronicen a través de Internet en lugar de a través de una conexión dedicada.
• La empresa puede estar organizada de manera que los datos fluyan a través de una o varias capas intermedias entre el sitio central y los remotos (como en el diagrama que se muestra anteriormente en este tema).

En el siguiente diagrama se ilustran los filtros asociados con este escenario:

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 central es el publicador. Los datos del sitio central son la publicación, donde cada tabla de datos es un artículo (los artículos también pueden ser otros objetos de la base de datos, como procedimientos almacenados). Cada concentrador es un suscriptor de la publicación, y recibe el esquema y los datos como suscripción. Después, los concentradores vuelven a publicar los datos y las oficinas regionales se suscriben a dichos datos. Para obtener más información acerca de 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 de mezcla, que se adapta perfectamente para controlar los requisitos descritos en la sección anterior. Para obtener más información acerca de la réplica de mezcla, vea Información general sobre la réplica de mezcla y Cómo funciona la réplica de mezcla.

Importante:

Es posible implementar este escenario de dos maneras: la oficina central es un publicador y las oficinas remotas son suscriptores, o bien la oficina central es un suscriptor y las remotas son publicadores. La réplica de mezcla no admiten topologías de suscriptor central. Incluso si todos los cambios se producen en sitios remotos, la oficina central debería configurarse como publicador, con los sitios remotos como suscriptores. Se puede implementar un escenario similar con la réplica transaccional utilizando una topología de suscriptor central. Si la aplicación no requiere resolución de conflictos o filtros que proporcionen a cada sitio remoto un conjunto único de datos, considere la posibilidad de utilizar la réplica transaccional. Para obtener más información, vea Integrar datos de varios sitios (Server).

Opciones de la réplica de mezcla relacionadas con este escenario

La réplica de mezcla ofrece varias opciones para cubrir los requisitos descritos anteriormente en este tema. En la siguiente lista se presenta cada requisito y las opciones de la réplica de mezcla que lo cubren.

• Los datos se escriben y actualizan en un sitio central y en los sitios remotos.
  La réplica de mezcla proporciona esta capacidad sin especificar ninguna otra opción.
• Los usuarios remotos deben poder realizar actualizaciones de forma independiente, sin que sea necesaria una conexión con el sitio central.
  La réplica de mezcla proporciona esta capacidad sin especificar ninguna otra opción.
• Puesto que varios usuarios pueden actualizar los mismos datos de forma independiente, pueden producirse conflictos de datos que deben solucionarse.
  La réplica de mezcla proporciona detección y resolución de conflictos para los casos en que se espera que surjan conflictos de datos. Es mejor diseñar las aplicaciones para evitar los conflictos, pero cuando ello no es posible, puede seleccionar el mecanismo de resolución de conflictos predeterminado (el primero en entrar, gana) o utilizar una resolución de conflictos personalizada. Para obtener más información, vea Detectar y resolver conflictos de réplica de mezcla.
• Algunos datos sólo se deben actualizar en el sitio central, por ejemplo los datos de las tablas de precios de productos.
  La réplica de mezcla proporciona artículos de sólo descarga para aquellas tablas que solamente deben actualizarse en el publicador. Para obtener más información, vea Optimizar el rendimiento de la réplica de mezcla con artículos de sólo descarga.
• Los usuarios deben poder sincronizar datos a petición y en momentos programados.
  La réplica ofrece dos tipos de suscripciones: suscripciones de inserción y suscripciones de extracción. Las suscripciones de extracción son más adecuadas para la sincronización a petición. Para obtener más información acerca de los tipos de suscripciones y la sincronización programada, vea Suscribirse a publicaciones y Sincronizar datos.
• La aplicación debe controlar cuánto tiempo puede permanecer un sitio remoto sin sincronizar.
  La réplica de mezcla permite definir un período de caducidad de suscripciones para garantizar que todos los suscriptores se han sincronizado en un período de tiempo determinado. Para obtener más información, vea Desactivación y caducidad de las suscripciones.
• Algunas tablas requieren filtrado para que cada usuario reciba datos diferentes de una o varias tablas. Por ejemplo, cada empleado de ventas puede recibir información de contacto únicamente para sus clientes.
  La réplica de mezcla permite filtrar columnas y filas. Los filtros de fila pueden ser estáticos o con parámetros. Un filtro estático se aplica únicamente al crear una publicación y da lugar a un conjunto de datos. Un filtro con parámetros se aplica cada vez que un suscriptor se sincroniza y da lugar a un conjunto de datos diferente para cada suscriptor. Las aplicaciones de las oficinas regionales a menudo utilizan filtros con parámetros, pero también podrían utilizar filtros estáticos. Para obtener más información, vea Filtrar datos publicados para la réplica de mezcla.
• Algunos datos deben ser tratados como una unidad cuando se transfieren entre los sitios. Por ejemplo, si un usuario remoto envía un pedido al sitio central, el encabezado del pedido debe confirmarse antes que los detalles del pedido.
  La réplica de mezcla permite especificar que un conjunto de tablas relacionadas se procesen como una unidad. Esta unidad se denomina registro lógico. Para obtener más información, vea Agrupar cambios en filas relacionadas con registros lógicos.
• La aplicación puede necesitar que se ejecute lógica de negocios personalizada al sincronizar los datos.
  La réplica de mezcla permite especificar código para que se ejecute durante la sincronización. Este código puede responder a una amplia variedad de eventos y tiene acceso a los datos que se están sincronizando. Para obtener más información, vea Ejecutar la lógica de negocios durante la sincronización de mezcla.
• La aplicación puede requerir que los datos se sincronicen a través de Internet en lugar de a través de una conexión dedicada.
  Si se utiliza SQL Server Compact Edition (SQL Server 2005 Compact Edition), los datos se sincronizan a través de una conexión HTTP o HTTPS. Para otras ediciones de SQL Server, puede utilizar la sincronización Web, que requiere HTTPS. Para obtener más información, vea Sincronización Web para la réplica de mezcla.
• La empresa puede estar organizada de manera que los datos fluyan a través de una o varias capas intermedias entre el sitio central y los sitios remotos.
  La réplica de mezcla puede acomodar este requisito a través de la republicación, un método en el que un publicador central publica datos en uno o varios suscriptores que, a su vez, publican los datos en otros suscriptores. Para obtener más información, vea Volver a publicar datos.

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 vínculos siguientes para obtener más información acerca de cada paso:

• Configurar la distribución
• Publicar datos y objetos de base de datos
• Suscribirse a publicaciones
• Inicializar una suscripción

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:

• Supervisar la réplica
• Estrategias para hacer copias de seguridad y restaurar la réplica de mezcla
• Solucionar problemas de réplica
• Quitar la réplica

Vea también

Conceptos

Replicar datos entre un servidor y los clientes

Ayuda e información

Obtener ayuda sobre SQL Server 2005