Volver a publicar datos

Actualizado: 12 de diciembre de 2006

En un modelo de republicación, el publicador envía datos a un suscriptor y éste, a su vez, vuelve a publicar los datos en cualquier número de suscriptores. Esto es útil cuando un publicador tiene que enviar datos a suscriptores a través de un vínculo de comunicaciones lento o costoso. Si hay varios suscriptores en el otro extremo del vínculo, el uso de un republicador desplaza la mayor parte de la carga de distribución a ese extremo del vínculo.

Para republicar datos, lleve a cabo los siguientes pasos:

1. Cree una publicación en el publicador.
2. Cree una suscripción a la publicación para el suscriptor de republicación.
3. Inicialice la suscripción. La suscripción se debe inicializar antes de crear la publicación en el suscriptor de republicación; de lo contrario, se producirá un error de réplica.
4. Cree una publicación en la base de datos de suscripciones para el suscriptor de republicación.
5. Cree suscripciones a la publicación en el suscriptor de republicación para los demás suscriptores.
6. Inicialice las suscripciones.

[!NOTA] Si utiliza la réplica de mezcla en una topología de republicación, todos los suscriptores de republicación deberán utilizar las suscripciones del servidor. Para obtener más información acerca de los tipos de suscripciones, vea Suscribirse a publicaciones.

En la siguiente ilustración, tanto el publicador como el republicador actúan como sus propios distribuidores locales. Si estuvieran configurados para utilizar un distribuidor remoto, cada distribuidor tendría que estar en el mismo lado del vínculo de comunicaciones lento o costoso que su publicador. Los publicadores tienen que estar conectados con sus distribuidores remotos mediante vínculos de comunicaciones confiables y de alta velocidad.

Cualquier servidor puede funcionar como publicador y como suscriptor. Por ejemplo, considere la ilustración siguiente: en Londres existe la publicación de una tabla que debe distribuirse a cuatro ciudades diferentes de los Estados Unidos: Chicago, Nueva York, San Diego y Seattle. Se elige el servidor de Nueva York para que se suscriba a la tabla publicada originada en Londres, porque el sitio de Nueva York cumple las siguientes condiciones:

• El enlace de red con Londres es relativamente confiable.
• Los costos de comunicación entre Londres y Nueva York son aceptables.
• Hay buenas líneas de comunicación por red desde Nueva York a todos los demás sitios suscriptores de los Estados Unidos.
  

La réplica admite los siguientes escenarios de republicación:

Publicador	Suscriptor de publicación	Suscriptor
Publicación transaccional	Suscripción transaccional/publicación transaccional	Suscripción transaccional
Publicación transaccional	Suscripción transaccional/publicación de mezcla1	Suscripción de mezcla
Publicación de mezcla	Suscripción de mezcla/publicación de mezcla	Suscripción de mezcla
Publicación de mezcla	Suscripción de mezcla/publicación transaccional	Suscripción transaccional

1Debe establecer la propiedad @published_in_tran_pub en la publicación de mezcla. De forma predeterminada, la réplica transaccional espera que las tablas del suscriptor se traten como de sólo lectura. Si la réplica de mezcla realiza cambios en los datos de una tabla de una suscripción transaccional, la convergencia de los datos puede no producirse. Para evitar este riesgo, se recomienda que cada tabla de este tipo se especifique como sólo para descarga en la publicación de mezcla. Esto evita que un suscriptor de mezcla cargue cambios de datos en la tabla. Para obtener más información, vea Optimizar el rendimiento de la réplica de mezcla con artículos de sólo descarga.

Vea también

Conceptos

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

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios

Versión	Historial
12 de diciembre de 2006	Contenido nuevo: Se agregó información para aclarar la compatibilidad con topologías de republicación mixtas.