Article
01/24/2011

Dernières modifications dans la réplication SQL Server

Cette rubrique décrit les changements importants apportés à la réplication SQL Server. Ces modifications peuvent interrompre les applications, scripts ou fonctionnalités fondés sur les versions antérieures de SQL Server. Il se peut que vous rencontriez ces problèmes lors d'une mise à niveau. Pour plus d'informations, consultez Utilisation du Conseiller de mise à niveau pour la préparation des mises à niveau.

Dernières modifications apportées dans SQL Server 2005 et SQL Server 2008

Cette section décrit les dernières modifications des fonctionnalités de réplication qui ont été apportées dans SQL Server 2005 ouSQL Server 2008.

Dernières modifications qui affectent tous les types de réplication

Les modifications décrites ci-dessous s'appliquent à tous les types de réplication.

Fonctionnalité	Description
Modifications requises pour les scripts de réplication	Le modèle de sécurité de l'agent de réplication n'est plus celui de SQL Server 2000. Pour plus d'informations sur le modèle de sécurité, consultez Modèle de sécurité de l'Agent de réplication. Si vous êtes un membre du rôle serveur fixe sysadmin dans SQL Server 2005 et que vous exécutez des scripts de réplication créés à partir de SQL Server 2000 ou SQL Server 7.0, les scripts sont correctement exécutés. Si vous êtes un membre du rôle de base de données fixe dbo ou d'un autre rôle, les scripts échouent et doivent être mis à niveau. Pour plus d'informations sur la mise à niveau des scripts, consultez Procédure : mettre à niveau les scripts de réplication (programmation Transact-SQL de la réplication). Bien qu'il ne soit pas obligatoire de mettre à niveau les scripts qui sont exécutés par des membres du rôle sysadmin, il est recommandé de le faire afin de bénéficier des améliorations en termes de sécurité.
Connexions locales pour les agents de réplication	Lors de la mise à niveau vers SQL Server 2005, toutes les connexions locales qui utilisent l'authentification SQL Server sont modifiées pour utiliser l'authentification Windows. Les connexions locales sont les connexions effectuées par un agent vers une instance SQL Server qui s'exécute sur le même ordinateur. Par exemple, l'Agent de fusion pour un abonnement par extraction de données s'exécute chez l'Abonné, si bien que les connexions qu'il établit avec l'Abonné sont des connexions locales. Dans les versions précédentes de SQL Server, les agents s'exécutaient par défaut sous le compte du service SQL Server Agent. Après la mise à niveau, les connexions locales sont établies sous ce compte. SQL Server 2005 permet de contrôler soigneusement chaque compte sous lequel les agents de réplication s'exécutent et établissent des connexions intégrées à Windows avec les bases de données et d'autres ressources ; un compte différent peut être spécifié pour chaque agent. Après la mise à niveau, il est recommandé de spécifier un compte différent par agent. Pour plus d'informations, consultez Considérations relatives à la mise à niveau de bases de données répliquées et Modèle de sécurité de l'Agent de réplication.
Contrôles ActiveX	Tous les contrôles ActiveX sont marqués comme non sûrs pour l'écriture de scripts et l'initialisation. Le contrôle ActiveX de l'Agent de capture instantanée n'est pas disponible dans SQL Server 2005. Utilisez plutôt le nouvel Agent de capture instantané managé. Pour plus d'informations, consultez SnapshotGenerationAgent et Procédure : créer la capture instantanée initiale (programmation RMO).
Mot de passe pour le compte distributor_admin	Les connexions approuvées entre un serveur de publication et un serveur de distribution distant ne sont plus prises en charge, car elles ne requéraient pas un mot de passe (les connexions approuvées étaient utilisées par défaut dans les versions précédant SQL Server 2000 Service Pack 3). Si vous utilisez un serveur de distribution distant, avant d'effectuer la mise à niveau vers SQL Server 2005, convertissez les connexions approuvées en connexions non approuvées (cette observation ne concerne pas les serveurs de publication qui utilisent un serveur de distribution local). Pour plus d'informations sur le compte distributor_admin, consultez Protection du serveur de distribution. Pour déterminer le type de connexion en cours d'utilisation Sur le serveur de distribution, exécutez sp_helpdistpublisher. Si la valeur de la colonne trusted est 1, vous devez passer à une connexion non approuvée. Pour passer à une connexion non approuvée Exécutez sp_changedistpublisher sur le serveur de distribution, en affectant la valeur 'trusted' au paramètre @property et la valeur 'False' au paramètre @value. Remarque Certaines versions de la documentation en ligne de SQL Server 2000 ne répertorient pas 'trusted' comme valeur valide pour @property. Elle est pourtant valide pour toutes les versions de SQL Server 2000. Exécutez sp_changedistributor_password sur le serveur de publication et sur le serveur de distribution, en spécifiant un mot de passe fort pour le paramètre @password.
SQL Server Express n'inclut pas l'Agent SQL Server.	Si vous effectuez une mise à niveau vers SQL Server Express, vous devez reconfigurer la synchronisation de la réplication car SQL Server Express n'inclut pas l'Agent SQL Server. Si vous souhaitez utiliser des abonnements par extraction de données, vous devez les synchroniser à l'aide des objets RMO (Replication Management Objects), du Gestionnaire de synchronisation Windows ou en exécutant l'agent de réplication à partir de la ligne de commande. Pour plus d'informations, consultez Réplication de données vers SQL Server Express. Si vous voulez continuer à utiliser l'Agent SQL Server pour exécuter des travaux de l'agent de réplication, vous devez utiliser des abonnements par émission de données ou effectuer une mise à jour vers une version différente de SQL Server (toutes les versions à l'exception de SQL Server Express et de SQL Server Compact 3.5 SP1 incluent l'Agent SQL Server). Avec les abonnements par émission de données, l'Agent de distribution ou l'Agent de fusion s'exécutent au niveau du serveur de distribution, de sorte que l'Agent SQL Server est disponible (SQL Server Express ne peut pas être un serveur de distribution).
Abonnés à Microsoft Access (Jet 4.0)	Jet est la base de données sous-jacente utilisée par Access et la réplication prenait en charge les abonnements aux bases de données Jet dans SQL Server 2000. Ces abonnements ne sont plus pris en charge. Il est recommandé d'utiliser plutôt SQL Server Express. Access peut utiliser une base de données SQL Server comme arrière-plan et les bases de données SQL Server ne sont pas concernées par ce problème. Pour plus d'informations, consultez Réplication de données vers SQL Server Express.

Dernières modifications pour la réplication transactionnelle

Les modifications avec rupture décrites ci-dessous s'appliquent à la réplication transactionnelle.

Fonctionnalité	Description
Initialisation d'un abonnement transactionnel à partir d'une sauvegarde1	Pour initialiser un abonnement transactionnel à partir d'une sauvegarde dans SQL Server 2008, l'utilisateur doit être membre du rôle de serveur dbcreator. Dans SQL Server 2005, l'appartenance au rôle de base de données db_owner était suffisante. Pour plus d'informations sur l'initialisation d'un abonnement à partir d'une sauvegarde, consultez Initialisation d'un abonnement transactionnel sans capture instantanée.
Option MSMQ (Message Queuing) pour l'abonnement de mise à jour en attente	Avec les abonnements de mise à jour en attente, les modifications des Abonnés sont écrites dans une file d'attente ; elles sont ensuite lues dans cette file d'attente et remises au serveur de publication par l'Agent de lecture de la file d'attente. Dans SQL Server 2000, les abonnements pouvaient utiliser une file d'attente SQL Server ou bien l'option Message Queuing pour mettre les modifications en file d'attente. Le type de file d'attente était spécifié avec le paramètre @queue_type de sp_addpublication, qui autorisait les valeurs sql et msmq (Message Queuing). Dans SQL Server 2005, seule la valeur sql est autorisée. Les publications existantes qui utilisent l'option Message Queuing sont modifiées lors de la mise à niveau en vue de l'utilisation d'une file d'attente SQL Server. Si certaines de vos applications dépendent de la mise à jour en attente à l'aide de Message Queuing, vous devrez les réécrire pour une file d'attente SQL Server. Pour plus d'informations sur les abonnements de mise à jour en attente, consultez Abonnements pouvant être mis à jour pour la réplication transactionnelle. La mise à niveau de SQL Server supprime les files d'attente d'abonnement Message Queuing existantes si le service Message Queuing est parallèlement en cours d'exécution. Important Dans Windows 2000 et Windows XP, le service MSDTC (Microsoft Distributed Transaction Coordinator) doit également être en cours d'exécution car Message Queuing requiert MSDTC sur ces plateformes. Si le service Message Queuing n'est pas en cours d'exécution, supprimez les files d'attente manuellement une fois la mise à niveau achevée. Pour plus d'informations sur la suppression des files d'attente, consultez la documentation de Windows.
Changer pour appeler le format pour les abonnements avec mise à jour	Par défaut, un ensemble de procédures stockées est utilisé pour propager les modifications vers les Abonnés dans la réplication transactionnelle. Chaque procédure a un format d'appel. Ce format détermine la manière dont les paramètres sont passés à la procédure et la quantité de données qui est envoyée à l'Abonné. Dans SQL Server 2000, le format par défaut est CALL. Dans SQL Server 2005 et SQL Server 2008, le format par défaut est VCALL. Cette modification affecte seulement les topologies dans lesquelles les procédures stockées ont été personnalisées. Après la mise à niveau, vous devez modifier la signature de la procédure personnalisée pour inclure des paramètres supplémentaires. Sinon, l'Agent de distribution échouera.

Initialisation d'un abonnement transactionnel à partir d'une sauvegarde1

Pour initialiser un abonnement transactionnel à partir d'une sauvegarde dans SQL Server 2008, l'utilisateur doit être membre du rôle de serveur dbcreator. Dans SQL Server 2005, l'appartenance au rôle de base de données db_owner était suffisante.

Pour plus d'informations sur l'initialisation d'un abonnement à partir d'une sauvegarde, consultez Initialisation d'un abonnement transactionnel sans capture instantanée.

Option MSMQ (Message Queuing) pour l'abonnement de mise à jour en attente

Avec les abonnements de mise à jour en attente, les modifications des Abonnés sont écrites dans une file d'attente ; elles sont ensuite lues dans cette file d'attente et remises au serveur de publication par l'Agent de lecture de la file d'attente. Dans SQL Server 2000, les abonnements pouvaient utiliser une file d'attente SQL Server ou bien l'option Message Queuing pour mettre les modifications en file d'attente. Le type de file d'attente était spécifié avec le paramètre @queue_type de sp_addpublication, qui autorisait les valeurs sql et msmq (Message Queuing). Dans SQL Server 2005, seule la valeur sql est autorisée. Les publications existantes qui utilisent l'option Message Queuing sont modifiées lors de la mise à niveau en vue de l'utilisation d'une file d'attente SQL Server. Si certaines de vos applications dépendent de la mise à jour en attente à l'aide de Message Queuing, vous devrez les réécrire pour une file d'attente SQL Server. Pour plus d'informations sur les abonnements de mise à jour en attente, consultez Abonnements pouvant être mis à jour pour la réplication transactionnelle.

La mise à niveau de SQL Server supprime les files d'attente d'abonnement Message Queuing existantes si le service Message Queuing est parallèlement en cours d'exécution.

Important

Dans Windows 2000 et Windows XP, le service MSDTC (Microsoft Distributed Transaction Coordinator) doit également être en cours d'exécution car Message Queuing requiert MSDTC sur ces plateformes.

Si le service Message Queuing n'est pas en cours d'exécution, supprimez les files d'attente manuellement une fois la mise à niveau achevée. Pour plus d'informations sur la suppression des files d'attente, consultez la documentation de Windows.

Changer pour appeler le format pour les abonnements avec mise à jour

Par défaut, un ensemble de procédures stockées est utilisé pour propager les modifications vers les Abonnés dans la réplication transactionnelle. Chaque procédure a un format d'appel. Ce format détermine la manière dont les paramètres sont passés à la procédure et la quantité de données qui est envoyée à l'Abonné. Dans SQL Server 2000, le format par défaut est CALL. Dans SQL Server 2005 et SQL Server 2008, le format par défaut est VCALL.

Cette modification affecte seulement les topologies dans lesquelles les procédures stockées ont été personnalisées. Après la mise à niveau, vous devez modifier la signature de la procédure personnalisée pour inclure des paramètres supplémentaires. Sinon, l'Agent de distribution échouera.

1 Ce problème affecte uniquement SQL Server 2008 et versions ultérieures.

Dernières modifications pour la réplication de fusion

Les dernières modifications décrites ci-dessous s'appliquent à la réplication de fusion.

Fonctionnalité	Description
Publication à partir de SQL Server Express	MSDE SQL Server peut tenir lieu de serveur de publication pour les publications de fusion. SQL Server Express, qui remplace MSDE, ne peut pas tenir lieu de serveur de publication. Il peut s'abonner aux publications de fusion, aux publications transactionnelles et aux publications de capture instantanée. La réplication de fusion et la réplication transactionnelle avec des abonnements de mise à jour autorisent toutes deux que les modifications soient retournées au serveur de publication à partir des Abonnés. Pour plus d'informations sur la réplication sur SQL Server Express, consultez Réplication de données vers SQL Server Express.
Traitement des modifications	Dans les versions antérieures de SQL Server, les modifications apportées par l'Agent de fusion étaient réalisées ligne par ligne. Dans SQL Server 2005, les modifications sont regroupées, ce qui permet d'améliorer les performances ; par conséquent, une même instruction permet d'insérer, de mettre à jour ou de supprimer plusieurs lignes. Si, dans les bases de données de publication ou d'abonnement, des tables publiées possèdent des déclencheurs, vérifiez que ceux-ci peuvent gérer les insertions, les mises à jour et les suppressions portant sur plusieurs lignes. Pour plus d'informations, consultez Observations au sujet des lignes multiples pour les déclencheurs DML.
Recréation de tables de conflits	Lors de la mise à niveau de SQL Server 2005, les tables de conflits sont recréées et le propriétaire de la base de données (DBO, Database Owner) est leur propriétaire. Si d'autres propriétaires possédaient l'une des tables dans SQL Server 2000, votre application doit peut-être être modifiée. La réplication de fusion crée une table de conflits pour chaque article associé à une publication, avec un nom qui a la forme conflict_PublicationName_ArticleName. Toutes les tables de métadonnées sont recréées lors de la mise à niveau et toutes les tables de conflits sont créées dans le schéma DBO.
Nouvelles plages d'identité attribuées	Pour les tables qui utilisent la gestion automatique des plages d'identité, la réplication peut attribuer de nouvelles plages d'identité au cours de la mise à niveau. Si certaines tables ont une plage d'identité attribuée à l'Abonné plus grande que celle du serveur de publication, la réplication attribue au serveur de publication une plage égale à celle de l'Abonné. Pour déterminer les plages en cours d'utilisation pour chaque article, exécutez sp_helpmergearticle dans la base de données de publication et consultez les colonnes pub_identity_range et identity_range.

Voir aussi

Concepts

Compatibilité descendante de la réplication

Partager via