Preguntas más frecuentes para administradores de replicación

No. La actividad puede continuar en la base de datos mientras se crea una publicación. Tenga en cuenta que producir una instantánea puede consumir muchos recursos, por lo que es mejor generar instantáneas durante los períodos de menor actividad de la base de datos (de manera predeterminada, se genera una instantánea cuando se completa el Asistente para nueva publicación).

La duración de los bloqueos depende del tipo de replicación utilizada.

• Para las publicaciones de mezcla, el Agente de instantáneas no adopta ningún bloqueo.

• Para las publicaciones transaccionales, el Agente de instantáneas adopta de manera predeterminada bloqueos únicamente durante la fase inicial de la generación de instantáneas.

• Para las publicaciones de instantáneas, el Agente de instantáneas adopta bloqueos durante todo el proceso de generación de instantáneas.

Como los bloqueos impiden al resto de los usuarios actualizar las tablas, el Agente de instantáneas debe programarse para que se ejecute durante los períodos de baja actividad de la base de datos, especialmente para las publicaciones de instantáneas.

Una suscripción está disponible después de haber aplicado la instantánea a la base de datos de suscripciones. Aunque se puede obtener acceso a la base de datos de suscripciones con anterioridad, la base de datos no se debe utilizar hasta que se haya aplicado la instantánea. Utilice el Monitor de replicación para comprobar el estado de la aplicación y generación de instantáneas:

• El Agente de instantáneas genera la instantánea. Vea el estado de la generación de instantáneas en la ficha Agentes de una publicación en el Monitor de replicación. Para obtener más información, vea Cómo ver información y realizar tareas para los agentes asociados con una publicación (Monitor de replicación).

• La instantánea la aplica el Agente de distribución o el Agente de mezcla. Vea el estado de la aplicación de instantáneas en la página Agente de distribución o Agente de mezcla del Monitor de replicación. Para obtener más información, vea Cómo ver información y realizar tareas para los agentes asociados a una suscripción (Monitor de replicación).

Esto no causa ningún error si el Agente de distribución o el Agente de mezcla se ejecutan al mismo tiempo que el Agente de instantáneas. No obstante, debe tener en cuenta lo siguiente:

• Si el Agente de distribución o el Agente de mezcla están configurados para ejecutarse de forma continua, el agente aplica la instantánea automáticamente una vez que el Agente de instantáneas finaliza.

• Si el Agente de distribución o el Agente de mezcla están configurados para ejecutarse según una programación o a petición, y no hay ninguna instantánea disponible cuando el agente se ejecuta, el agente se cerrará con un mensaje en el que se indica que la instantánea no está disponible todavía. Es preciso volver a ejecutar el agente para aplicar la instantánea una vez que el Agente de instantáneas ha finalizado. Para obtener más información acerca de cómo ejecutar los agentes, vea Cómo sincronizar una suscripción de inserción (SQL Server Management Studio), Cómo sincronizar una suscripción de extracción (SQL Server Management Studio) y Conceptos de los ejecutables del Agente de replicación.

Sí. Generar un script para la configuración de replicación es una parte fundamental de cualquier plan de recuperación de desastres en una topología de replicación. Para obtener más información sobre la generación de scripts, vea Crear secuencias de script.

Funciones de replicación que utilicen correctamente uno de los modelos de recuperación: simple, completa o por medio de registros de operaciones masivas. La replicación de mezcla hace un seguimiento de los cambios almacenando información en tablas de metadatos. La replicación transaccional realiza un seguimiento de los cambios marcando el registro de transacciones, pero el modelo de recuperación no afecta a este proceso de marcado.

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 realizar esta acción:

• 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 utiliza dicha columna). Si la tabla se quita de la publicación, la columna rowguid se elimina; si se ha utilizado una columna existente para realizar el seguimiento, la columna no se quita.

• Si una publicación transaccional admite suscripciones de actualización en cola, la replicación agrega la columna msrepl_tran_version a todas las tablas. Si la tabla se quita de la publicación, la columna msrepl_tran_version no se elimina.

Existen varios aspectos que deben tenerse en cuenta en relación con las restricciones en las tablas publicadas:

• La replicación transaccional requiere una restricción de clave principal en cada tabla publicada. La replicación de mezcla no requiere clave principal, pero si existe alguna, debe replicarse. La replicación de instantáneas no requiere clave principal.

• De manera predeterminada, las restricciones de clave principal, los índices y las restricciones CHECK se replican en los suscriptores.

• La opción NOT FOR REPLICATION se especifica de manera predeterminada para las restricciones de clave externa y las restricciones CHECK; las restricciones se exigen para las operaciones de usuario, pero no para las operaciones de agente. Para obtener más información, vea Controlar restricciones, identidades y desencadenadores con NOT FOR REPLICATION.

Para obtener información acerca de la configuración de las opciones de esquema que controlan si las restricciones se replican o no, vea Cómo especificar opciones de esquema (SQL Server Management Studio) y Cómo especificar opciones de esquema (programación de la replicación con Transact-SQL).

La replicación proporciona administración automática de intervalos de identidad para las topologías de replicación que incluyen actualizaciones en el suscriptor. Para obtener más información, vea Replicar columnas de identidad.

Sí, pero con algunas limitaciones. Para obtener más información, vea la sección sobre cómo publicar tablas en varias publicaciones en el tema Publicar datos y objetos de base de datos.

Sí. No existen limitaciones al número de tipos de publicaciones que pueden utilizar la misma base de datos de distribución. Todas las publicaciones de un publicador determinado deben utilizar el mismo distribuidor y base de datos de distribución.

Si dispone de varias publicaciones, puede configurar varias bases de datos de distribución en el distribuidor para asegurarse de que los datos que pasan a través de cada una de ellas proceden de una sola publicación. Utilice el cuadro de diálogo Propiedades del distribuidor o sp_adddistributiondb (Transact-SQL) para agregar una base de datos de distribución. Para obtener más información acerca de cómo obtener acceso a este cuadro de diálogo, vea Cómo ver y modificar las propiedades del distribuidor (SQL Server Management Studio).

Esta información está disponible a través de SQL Server Management Studio y de una serie de procedimientos almacenados de replicación. Para obtener información, vea Propiedades de la replicación y Script de información del distribuidor y del publicador.

No. La replicación no cifra los datos almacenados en la base de datos o transferidos a través de la red. Para obtener más información, vea la sección sobre cifrado en el tema Información general sobre seguridad (replicación).

Los datos se replican a través de Internet mediante:

• Una red privada virtual (VPN). Para obtener más información, vea Publicar datos por Internet mediante VPN.

• La opción de sincronización Web para replicación de mezcla. Para obtener más información, vea Sincronización Web para la replicación de mezcla.

Todos los tipos de replicación de Microsoft SQL Server pueden replicar datos a través de VPN, pero tenga en cuenta la sincronización Web si está utilizando replicación de mezcla.

Sí. El procesamiento de replicación se reanuda en el punto en el que se dejó cuando se quitó la conexión. Si está utilizando la replicación de mezcla a través de una red que no es confiable, considere la posibilidad de utilizar registros lógicos, con lo que se asegurará de que los cambios se procesen como una unidad. Para obtener más información, vea Agrupar cambios en filas relacionadas con registros lógicos.

Sí, la replicación funciona a través de conexiones de poco ancho de banda. En las conexiones sobre TCP/IP, utiliza la compresión proporcionada por el protocolo, pero no aporta compresión adicional. En las conexiones de sincronización Web sobre HTTPS, utiliza la compresión proporcionada por el protocolo y también compresión adicional de los archivos XML utilizados para replicar cambios. Para obtener más información acerca de la replicación en conexiones de poco ancho de banda, vea Problemas provocados por una red lenta.

No. Puede crear un paquete DTS para transferir inicios de sesión y contraseñas de un publicador a uno o varios suscriptores. Para obtener más información, vea Diseñar e implementar paquetes (Integration Services).

A partir de Microsoft SQL Server 2005, esquema tiene dos significados:

• La definición de un objeto, como una instrucción CREATE TABLE. De manera predeterminada, la replicación copia las definiciones de todos los objetos replicados en el suscriptor.

• El espacio de nombres dentro del cual se crea un objeto: <base de datos>.<esquema>.<objeto>. Los esquemas se definen mediante la instrucción CREATE SCHEMA. Para obtener más información acerca de los esquemas, vea Esquemas (motor de base de datos).

• La replicación muestra el siguiente comportamiento predeterminado en el Asistente para nueva publicación con respecto a los objetos y la propiedad de los objetos:

• Para artículos de publicaciones de mezcla con un nivel de compatibilidad de 90 o superior, publicaciones de instantáneas y publicaciones transaccionales: de manera predeterminada, el propietario del objeto en el suscriptor es el mismo que el propietario del objeto correspondiente en el publicador. Si en el suscriptor no existen esquemas que posean objetos, se crean de forma automática.

• Para artículos en publicaciones de mezcla con un nivel de compatibilidad menor de 90: de manera predeterminada, el propietario se deja en blanco y se especifica como dbo durante la creación del objeto en el suscriptor.

• Para artículos de publicaciones de Oracle: de forma predeterminada, el propietario se especifica como dbo.

• Para artículos de publicaciones que utilizan instantáneas en modo de carácter (que se utilizan para los que no son suscriptores de SQL Server y para los suscriptores de SQL Server Compact 3.5 SP1): de manera predeterminada, el propietario se deja en blanco. El propietario que se toma de manera predeterminada es el propietario asociado a la cuenta utilizada por el Agente de distribución o el Agente de mezcla para conectarse al suscriptor.

El propietario del objeto se puede cambiar mediante el cuadro de diálogo Propiedades del artículo: <Artículo> y mediante los siguientes procedimientos almacenados: sp_addarticle, sp_addmergearticle, sp_changearticle y sp_changemergearticle. Para obtener más información, vea Cómo ver y modificar propiedades de publicaciones y artículos (SQL Server Management Studio), Cómo definir un artículo (programación de la replicación con Transact-SQL) y Cómo ver y modificar propiedades de artículo (programación de la replicación con Transact-SQL).

De manera predeterminada, la replicación no ejecuta instrucciones GRANT en la base de datos de suscripciones. Si desea que los permisos de la base de datos de suscripciones coincidan con los de la base de datos de publicaciones, utilice uno de los siguientes métodos:

• Ejecute instrucciones GRANT directamente en la base de datos de suscripciones.

• Utilice un script posterior a una instantánea para ejecutar las instrucciones. Para obtener más información, vea Ejecutar scripts antes y después de aplicar la instantánea.

• Utilice el procedimiento almacenado sp_addscriptexec para ejecutar las instrucciones.

De manera predeterminada, los objetos del suscriptor se quitan y se vuelven a crear al reinicializar una suscripción, lo que provoca que todos los permisos concedidos para dichos objetos se quiten. Hay dos formas de controlar esto:

• Volver a aplicar las concesiones después de la reinicialización utilizando las técnicas descritas en la sección anterior.

• Especificar que los objetos no se quiten al reinicializar la suscripción. Antes de la reinicialización, elija entre:

  • Ejecute sp_changearticle o sp_changemergearticle. Especifique un valor de 'pre_creation_cmd' (sp_changearticle) o 'pre_creation_command' (sp_changemergearticle) para el parámetro @property y un valor de 'none', 'delete' o 'truncate' para el parámetro @value.

  • En el cuadro de diálogo Propiedades del artículo: <Artículo> de la sección Objeto de destino, seleccione un valor de Mantener el objeto existente sin cambios, Eliminar datos. Si el artículo tiene un filtro de fila, eliminar sólo los datos que coincidan con el filtro. o Truncar todos los datos del objeto existente en la opción Acción si el nombre está en uso. Para obtener más información acerca de cómo obtener acceso a este cuadro de diálogo, vea Cómo ver y modificar propiedades de publicaciones y artículos (SQL Server Management Studio).

TRUNCATE TABLE es una operación no registrada que no activa desencadenadores. No está permitida porque la replicación no puede realizar el seguimiento de los cambios causados por la operación: la replicación transaccional realiza un seguimiento de los cambios a través del registro de transacciones; la replicación de mezcla realiza el seguimiento de los cambios mediante los desencadenadores de las tablas publicadas.

Para la replicación transaccional se realiza el seguimiento de las inserciones masivas y se replican de la misma manera que otras inserciones. Para la replicación de mezcla, debe asegurarse de que los metadatos de seguimiento de cambios se actualizan adecuadamente. Para obtener más información, vea la sección sobre la inserción masiva de datos en tablas publicadas en el tema Consideraciones acerca de la replicación de mezcla.

Sí. Hay una serie de consideraciones especiales para las bases de datos que participan en la replicación. Para obtener más información, vea Realizar copias de seguridad de bases de datos de replicación y restaurarlas.

La replicación de mezcla y la replicación de instantáneas no afectan al tamaño del registro de transacciones, pero la replicación transaccional sí que puede afectar a dicho tamaño. Si una base de datos incluye una o varias publicaciones transaccionales, el registro no se trunca hasta que todas las transacciones relevantes para las publicaciones se hayan entregado en la base de datos de distribución. Si el registro de transacciones está aumentando demasiado y el Agente de registro del LOG se está ejecutando de forma programada, considere la posibilidad de acortar el intervalo entre ejecuciones. O establézcalo para que se ejecute en modalidad continua. Si está establecido para que se ejecute en modalidad continua (opción predeterminada), asegúrese de que se está ejecutando. Para obtener más información acerca de cómo comprobar el estado del Agente de registro del LOG, vea Cómo ver información y realizar tareas para los agentes asociados con una publicación (Monitor de replicación).

Además, si ha definido la opción 'sync with backup' en la base de datos de publicaciones o en la base de datos de distribución, el registro de transacciones no se trunca hasta que se ha realizado una copia de seguridad de todas las transacciones. Si el registro de transacciones está aumentando demasiado y ha definido esta opción, considere la posibilidad de acortar el intervalo entre las copias de seguridad de los registros de transacciones. Para obtener más información sobre cómo realizar copias de seguridad y restauraciones de las bases de datos implicadas en la replicación transaccional, vea Estrategias para hacer copias de seguridad y restaurar la replicación de instantáneas o transaccional.

Existen varios mecanismos para volver a generar índices. Todos ellos se pueden utilizar sin necesidad de tener en cuenta consideraciones especiales para replicación, con la siguiente excepción: las claves principales son necesarias en las tablas de las publicaciones transaccionales, por lo que no se pueden quitar y volver a crear claves principales en dichas tablas.

Se pueden agregar índices en el publicador o los suscriptores sin consideraciones especiales en cuanto a replicación (tenga en cuenta que los índices pueden afectar al rendimiento). CREATE INDEX y ALTER INDEX no se replican, por lo que si agrega o cambia un índice, por ejemplo en el publicador, deberá realizar la misma adición o cambio en el suscriptor si desea que quede reflejado ahí.

En versiones de SQL Server anteriores a SQL Server 2005, mover o cambiar de nombre los archivos de base de datos exigía separar y volver a adjuntar la base de datos. Puesto que una base de datos replicada no se puede separar, la replicación tenía que quitarse de estas bases de datos primero. A partir de SQL Server 2005, se pueden mover o cambiar de nombre los archivos sin separar y volver a adjuntar la base de datos, sin efecto alguno en la replicación. Para obtener más información acerca de cómo mover y volver a nombrar los archivos, vea ALTER DATABASE (Transact-SQL).

Primero, quite el artículo de la publicación utilizando sp_droparticle, sp_dropmergearticle , o el cuadro de diálogo Propiedades de la publicación: <publicación> y, a continuación, quítelo de la base de datos mediante DROP <Object>. No se pueden quitar artículos de publicaciones transaccionales o de instantáneas una vez que se han agregado suscripciones; es preciso quitar primero las suscripciones. Para obtener más información, vea Agregar y quitar artículos de publicaciones existentes.

SQL Server permite una amplia variedad de cambios de esquema en objetos publicados, lo que incluye agregar y quitar columnas. Por ejemplo, ejecute ALTER TABLE … DROP COLUMN en el publicador y la instrucción se replica en los suscriptores y, a continuación, se ejecuta para quitar la columna. Los suscriptores que ejecutan versiones de SQL Server anteriores a SQL Server 2005 admiten agregar y quitar columnas a través de los procedimientos almacenados sp_repladdcolumn y sp_repldropcolumn. Para obtener más información, vea Realizar cambios de esquema en las bases de datos de publicación.

Utilice la validación. La validación informa de si un suscriptor determinado está sincronizado con el publicador. Para obtener más información, vea Validar los datos replicados. La validación no proporciona información acerca de qué filas no están sincronizadas correctamente, pero la utilidad tablediff sí.

Para agregar una tabla (u otro objeto), no es necesario detener la actividad en las bases de datos de publicaciones o suscripciones. Agregue una tabla a una publicación a través del cuadro de diálogo Propiedades de la publicación: <publicación> o los procedimientos almacenados sp_addarticle y sp_addmergearticle. Para obtener más información, vea Agregar y quitar artículos de publicaciones existentes.

Quite una tabla de la publicación mediante sp_droparticle, sp_dropmergearticle, o el cuadro de diálogo Propiedades de la publicación: <publicación>. No se pueden quitar artículos de publicaciones transaccionales o de instantáneas después de que se hayan agregado suscripciones; es preciso quitar primero las suscripciones. Para obtener más información, vea Agregar y quitar artículos de publicaciones existentes.

Existen una serie de cambios de publicaciones y artículos que requieren que las suscripciones se reinicialicen. Para obtener más información, vea Cambiar las propiedades de la publicación y de los artículos.

Existen una serie de cambios de publicaciones y artículos que invalidan las instantáneas y exigen que se generen otras nuevas. Para obtener más información, vea Cambiar las propiedades de la publicación y de los artículos.

Las acciones necesarias para quitar la replicación de una base de datos dependen de si la base de datos tenía la función de base de datos de publicaciones, base de datos de suscripciones o ambas. Para obtener más información, vea Quitar la replicación.

Para la replicación transaccional, utilice procedimientos almacenados o la ficha Comandos sin distribuir del Monitor de replicación. Para obtener más información, vea Cómo ver comandos replicados y otra información en la base de datos de distribución (programación de la replicación con Transact-SQL) y Cómo ver información y realizar tareas para los agentes asociados a una suscripción (Monitor de replicación).

Para la replicación de mezcla, utilice el procedimiento almacenado sp_showpendingchanges. Para obtener más información, vea sp_showpendingchanges (Transact-SQL).

Utilice el procedimiento almacenado sp_replmonitorsubscriptionpendingcmds o la ficha Comandos sin distribuir del Monitor de replicación. El procedimiento almacenado y la ficha muestran lo siguiente:

• El número de comandos de la base de datos de distribución que no se han entregado al suscriptor seleccionado. Un comando se compone de una instrucción de lenguaje de manipulación de datos (DML) de Transact-SQL o una instrucción de lenguaje de definición de datos (DDL).

• La cantidad estimada de tiempo para entregar comandos al suscriptor. Si este valor es superior al tiempo necesario para generar y aplicar una instantánea en el suscriptor, considere la posibilidad de volver a reinicializar el suscriptor. Para obtener más información, vea Reinicializar una suscripción.

Para obtener más información, vea sp_replmonitorsubscriptionpendingcmds (Transact-SQL) y Cómo ver información y realizar tareas para los agentes asociados a una suscripción (Monitor de replicación).

Sí. Para obtener más información, vea Replicación y trasvase de registros y Replicación y creación de reflejo de la base de datos.

Sí. No tienen que tenerse en cuenta consideraciones especiales porque todos los datos se almacenan en un conjunto de discos en el clúster.