Artículo
01/24/2011

Últimos cambios en la replicación de SQL Server

En este tema se describen cambios recientes en la replicación de SQL Server. Estos cambios podrían afectar a las aplicaciones, scripts o funcionalidades que se basan en las versiones anteriores de SQL Server. Podría encontrar estos problemas al actualizar. Para obtener más información, vea Usar el Asesor de actualizaciones para preparar las actualizaciones.

Últimos cambios realizados en SQL Server 2005 y SQL Server 2008

En esta sección se describen los últimos cambios en las características de replicación realizados en SQL Server 2005 o SQL Server 2008.

Últimos cambios que afectan a todos los tipos de replicación

Los siguientes cambios se aplican a todos los tipos de replicación.

Característica	Descripción
Cambios necesarios para scripts de replicación	El modelo de seguridad del agente de replicación de SQL Server 2000 se ha cambiado. Para obtener más información sobre el modelo de seguridad, vea Modelo de seguridad del Agente de replicación. Si es miembro de la función fija de servidor sysadmin en SQL Server 2005 y ejecuta scripts de replicación creados en SQL Server 2000 o SQL Server 7.0, éstos se ejecutarán correctamente. Si es miembro de la función fija de base de datos dbo o de otra función, los scripts serán incorrectos y deberán actualizarse. Para obtener información sobre la actualización de scripts, vea Cómo actualizar scripts de replicación (programación de la replicación con Transact-SQL). Aunque no es necesario actualizar los scripts ejecutados por miembros de la función sysadmin, se recomienda hacerlo para sacar provecho de las mejoras de seguridad.
Conexiones locales para agentes de replicación	Al actualizar a SQL Server 2005, las conexiones locales que utilizan la autenticación de SQL Server se modifican para utilizar la autenticación de Windows. Las conexiones locales son aquellas realizadas por un agente en una instancia de SQL Server que se ejecuta en el mismo equipo que el agente. Por ejemplo, el Agente de mezcla de una suscripción de extracción se ejecuta en el suscriptor, por lo tanto las conexiones que realice en el suscriptor serán conexiones locales. En versiones anteriores de SQL Server, los agentes se ejecutaban, de manera predeterminada, en el contexto de la cuenta de servicio del Agente SQL Server. Después de la actualización, las conexiones locales se realizan en el contexto de esta cuenta. SQL Server 2005 permite el control exhaustivo de cada cuenta en la que los agentes de replicación se ejecuten y realicen conexiones integradas de Windows en bases de datos y demás recursos; se puede especificar una cuenta diferente para cada agente. Después de la actualización, se recomienda especificar distintas cuentas para cada agente. Para obtener más información, vea Consideraciones para actualizar las bases de datos replicadas y Modelo de seguridad del Agente de replicación.
Controles ActiveX	Todos los controles ActiveX están marcados como no seguros para scripts e inicialización. El control ActiveX del Agente de instantáneas no está disponible en SQL Server 2005. Utilice en su lugar el nuevo Agente de instantáneas administrado. Para obtener más información, vea SnapshotGenerationAgent y Cómo crear la instantánea inicial (programación con RMO).
Contraseña para la cuenta distributor_admin	Ya no se admiten conexiones de confianza entre un publicador y un distribuidor remoto porque no necesitaban contraseña (las conexiones de confianza se utilizaban de manera predeterminada en versiones anteriores a SQL Server 2000 Service Pack 3). Si utiliza un distribuidor remoto, antes de actualizar a SQL Server 2005, convierta las conexiones de confianza en conexiones no de confianza (este problema no afecta a los publicadores que utilizan un distribuidor local). Para obtener más información sobre la cuenta distributor_admin, vea Proteger el distribuidor. Para determinar el tipo de conexión utilizada Ejecute sp_helpdistpublisher en el distribuidor. Si el valor de la columna de confianza es 1, deberá cambiar a una conexión de no confianza. Para cambiar a una conexión de no confianza Ejecute sp_changedistpublisher en el distribuidor y especifique un valor 'trusted' para el parámetro @property y un valor 'False' para el parámetro @value. Nota En algunas versiones de los Libros en pantalla de SQL Server 2000, no aparece 'trusted' como valor válido para @property. Es válido para todas las versiones de SQL Server 2000. Ejecute sp_changedistributor_password tanto en el publicador como en el distribuidor, especificando una contraseña segura para el parámetro @password.
SQL Server Express no incluye el Agente SQL Server	Si va a actualizarse a SQL Server Express, deberá reconfigurar la sincronización de replicación porque SQL Server Express no incluye el Agente SQL Server. Si desea utilizar suscripciones de extracción, deberá sincronizarlas mediante Objetos de administración de replicación (RMO), el Administrador de sincronización de Windows o ejecutando el Agente de replicación en la línea de comandos. Para obtener más información, vea Replicar datos en SQL Server Express. Si desea continuar utilizando el Agente SQL Server para ejecutar trabajos de agente de replicación, deberá utilizar suscripciones de inserción o actualizar a una versión diferente de SQL Server (todas las versiones, salvo SQL Server Express y SQL Server Compact 3.5 SP1, incluyen el Agente SQL Server). Con las suscripciones de inserción, el Agente de distribución o el Agente de mezcla se ejecuta en el distribuidor y, por lo tanto, el Agente SQL Server está disponible (SQL Server Express no puede ser un distribuidor).
Suscriptores de Microsoft Access (Jet 4.0)	Jet es la base de datos subyacente utilizada por Access, y la replicación admitía suscripciones con las bases de datos de Jet en SQL Server 2000. Ya no se admiten estas suscripciones. Se recomienda utilizar SQL Server Express en su lugar. Access puede utilizar una base de datos de SQL Server como servidor, y las bases de datos de SQL Server no se verán afectadas por este problema. Para obtener más información, vea Replicar datos en SQL Server Express.

Últimos cambios en la replicación transaccional

Las siguientes cambios se aplican a la replicación transaccional.

Característica	Descripción
Inicialización de una suscripción transaccional a partir de una copia de seguridad1	Para inicializar una suscripción transaccional a partir de una copia de seguridad en SQL Server 2008, un usuario debe ser miembro de la función de servidor dbcreator. En SQL Server 2005, la pertenencia a la función de la base de datos db_owner era suficiente. Para obtener más información acerca de cómo inicializar una suscripción a partir de una base de datos, vea Inicializar una suscripción transaccional sin una instantánea.
Opción Message Queue Server para suscripción de actualización en cola	Con las suscripciones de actualización en cola, los cambios de los suscriptores se escriben en una cola; los cambios se leen posteriormente en la cola y se entregan al publicador mediante el Agente de lectura de cola. En SQL Server 2000, las suscripciones podían usar una cola de SQL Server o Message Queue Server para poner en cola los cambios. El tipo de cola se especificaba con el parámetro @queue_type de sp_addpublication, lo que permitía los valores de sql y msmq (Message Queue Server). En SQL Server 2005, sólo se permite un valor de sql. Las publicaciones existentes que utilizan Message Queue Server se modifican durante la actualización para que utilicen una cola de SQL Server. Si tiene aplicaciones que dependen de las actualizaciones en cola realizadas mediante Message Queue Server, deberá reescribir dichas aplicaciones para adaptarlas a las colas de SQL Server. Para obtener más información sobre suscripciones de actualización en cola, vea Suscripciones actualizables para replicación transaccional. La actualización eliminará las colas de suscripción de Message Queue Server existentes si el servicio Message Queue Server se ejecuta mientras SQL Server se actualiza. Importante En Windows 2000 y Windows XP, también debe ejecutarse el servicio MSDTC (Coordinador de transacciones distribuidas de Microsoft), porque Message Queue Server requiere MSDTC en estas plataformas. Si el servicio Message Queue Server no está en ejecución, elimine manualmente las colas una vez finalizada la actualización. Para obtener más información sobre cómo quitar colas, consulte la documentación de Windows.
Cambiar al formato de llamada para las suscripciones de actualización	De forma predeterminada, en la replicación transaccional se usa un conjunto de procedimientos almacenados para aplicar los cambios a los suscriptores. Cada procedimiento tiene un formato de llamada. Este formato determina cómo se pasan los parámetros al procedimiento y la cantidad de datos que se envían al suscriptor. En SQL Server 2000, el formato predeterminado es CALL. En SQL Server 2005 y SQL Server 2008, el formato predeterminado es VCALL. Este cambio únicamente afecta a las topologías en las que se han personalizado los procedimientos almacenados. Después de la actualización, debe cambiar la firma del procedimiento personalizado para que incluya los parámetros adicionales. De lo contrario, se producirá un error en el Agente de distribución.

Inicialización de una suscripción transaccional a partir de una copia de seguridad1

Para inicializar una suscripción transaccional a partir de una copia de seguridad en SQL Server 2008, un usuario debe ser miembro de la función de servidor dbcreator. En SQL Server 2005, la pertenencia a la función de la base de datos db_owner era suficiente.

Para obtener más información acerca de cómo inicializar una suscripción a partir de una base de datos, vea Inicializar una suscripción transaccional sin una instantánea.

Opción Message Queue Server para suscripción de actualización en cola

Con las suscripciones de actualización en cola, los cambios de los suscriptores se escriben en una cola; los cambios se leen posteriormente en la cola y se entregan al publicador mediante el Agente de lectura de cola. En SQL Server 2000, las suscripciones podían usar una cola de SQL Server o Message Queue Server para poner en cola los cambios. El tipo de cola se especificaba con el parámetro @queue_type de sp_addpublication, lo que permitía los valores de sql y msmq (Message Queue Server). En SQL Server 2005, sólo se permite un valor de sql. Las publicaciones existentes que utilizan Message Queue Server se modifican durante la actualización para que utilicen una cola de SQL Server. Si tiene aplicaciones que dependen de las actualizaciones en cola realizadas mediante Message Queue Server, deberá reescribir dichas aplicaciones para adaptarlas a las colas de SQL Server. Para obtener más información sobre suscripciones de actualización en cola, vea Suscripciones actualizables para replicación transaccional.

La actualización eliminará las colas de suscripción de Message Queue Server existentes si el servicio Message Queue Server se ejecuta mientras SQL Server se actualiza.

Importante

En Windows 2000 y Windows XP, también debe ejecutarse el servicio MSDTC (Coordinador de transacciones distribuidas de Microsoft), porque Message Queue Server requiere MSDTC en estas plataformas.

Si el servicio Message Queue Server no está en ejecución, elimine manualmente las colas una vez finalizada la actualización. Para obtener más información sobre cómo quitar colas, consulte la documentación de Windows.

Cambiar al formato de llamada para las suscripciones de actualización

De forma predeterminada, en la replicación transaccional se usa un conjunto de procedimientos almacenados para aplicar los cambios a los suscriptores. Cada procedimiento tiene un formato de llamada. Este formato determina cómo se pasan los parámetros al procedimiento y la cantidad de datos que se envían al suscriptor. En SQL Server 2000, el formato predeterminado es CALL. En SQL Server 2005 y SQL Server 2008, el formato predeterminado es VCALL.

Este cambio únicamente afecta a las topologías en las que se han personalizado los procedimientos almacenados. Después de la actualización, debe cambiar la firma del procedimiento personalizado para que incluya los parámetros adicionales. De lo contrario, se producirá un error en el Agente de distribución.

1 Este problema solamente afecta a SQL Server 2008 y a las versiones posteriores.

Últimos cambios en la replicación de mezcla

Las siguientes cambios se aplican a la replicación de mezcla.

Característica	Descripción
Publicación desde SQL Server Express	SQL Server MSDE podía servir como publicador para publicaciones de combinación. SQL Server Express, el sustituto de MSDE, no se puede utilizar como publicador. Puede suscribirse a publicaciones de mezcla, transaccionales y de instantáneas. La replicación de mezcla y la replicación transaccional con actualización de suscripciones permiten ambas que los cambios se propaguen de nuevo de los suscriptores al publicador. Para obtener más información acerca de cómo realizar replicaciones en SQL Server Express, vea Replicar datos en SQL Server Express.
Procesamiento de cambios por lotes	En versiones anteriores de SQL Server, los cambios realizados por el Agente de mezcla se hacían fila por fila. En SQL Server 2005, los cambios se ejecutan en lotes para mejorar el rendimiento; por lo tanto, se puede insertar, actualizar o eliminar más de una fila en una sola instrucción. Si las tablas publicadas en las bases de datos de publicaciones o suscripciones tienen desencadenadores, asegúrese de que los desencadenadores pueden controlar inserciones, actualizaciones y eliminaciones en varias filas. Para obtener más información, vea Consideraciones acerca de operaciones con varias filas para desencadenadores DML.
Nueva creación de tablas de conflictos	Al actualizar a SQL Server 2005, las tablas de conflictos se vuelven a crear con DBO como con su propietario. Si alguna tabla pertenecía a otros usuarios de SQL Server 2000, puede que su aplicación deba modificarse. La replicación de mezcla crea una tabla de conflictos para cada artículo de una publicación, con un nombre del tipo conflict_nombreDePublicación_nombreDeArtículo. Todas las tablas de metadatos se vuelven a crear durante la actualización y todas las tablas de conflictos se crean en el esquema de DBO.
Nuevos intervalos de identidad asignados	En tablas que utilicen la administración automática de intervalos de identidad, la replicación puede asignar nuevos intervalos de identidad durante la actualización. Si alguna tabla tiene un intervalo de identidad asignado al suscriptor más grande que el del publicador, la replicación asignará un intervalo al publicador igual al del suscriptor. Para determinar los intervalos que se usan para cada artículo, ejecute sp_helpmergearticle en la base de datos de publicación y compruebe las columnas pub_identity_range e identity_range.

Vea también

Conceptos

Compatibilidad con versiones anteriores de replicación

Share via