Dernières modifications dans la réplication SQL Server 2005
Mis à jour : 14 avril 2006
Cette rubrique décrit les modifications des fonctionnalités de réplication qui peuvent imposer des modifications dans les applications.
.gif "ms143470.note(fr-fr,SQL.90).gif") Remarque : |
|---|
| Cette rubrique est disponible dans la documentation d'aide du programme d'installation et dans la documentation en ligne de SQL Server 2005. Les liens vers des rubriques qui s'affichent en gras dans la documentation d'aide du programme d'installation font référence à des rubriques qui sont exclusivement disponibles dans la documentation en ligne. |
Dernières modifications qui affectent tous les types de réplication
Les dernières modifications décrites ci-dessous s'appliquent à tous les types de réplication dans Microsoft SQL Server 2005.
| 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 Microsoft 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 How to: Upgrade Replication Scripts (Replication Transact-SQL Programming). 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 Mise à niveau des 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 How to: Create the Initial Snapshot (RMO Programming). |
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
Pour passer à une connexion non approuvée
|
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 puisque 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 souhaitez continuer à utiliser l'Agent SQL Server pour exécuter les travaux des agents de réplication, vous devez utiliser des abonnements par envoi de données ou effectuer une mise à niveau vers une autre version de SQL Server (toutes les versions, à l'exception de SQL Server Express et Microsoft SQL Server 2005 Compact Edition, incluent l'Agent SQL Server). Avec les abonnements par envoi de données, l'Agent de distribution ou l'Agent de fusion s'exécute sur le serveur de distribution ; l'Agent SQL Server est donc 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 Microsoft SQL Server 2005 Express Edition. 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 dernières modifications décrites ci-dessous s'appliquent à la réplication transactionnelle dans SQL Server 2005.
Fonctionnalité
Description
Option MSMQ (Message Queuing) pour les abonnements 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é par le paramètre @queue_type de sp_addpublication (Transact-SQL), qui autorisait les valeurs de sql et de msmq. Dans SQL Server 2005, seule une valeur de 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 MSMQ, 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 supprimera les files d'attente d'abonnement MSMQ existantes si le service MSMQ est en cours d'exécution et SQL Server est en cours de mise à niveau.
Important :
Sous Windows 2000 et Windows XP, le service MSDTC (Microsoft Distributed Transaction Coordinator) doit également être en cours d'exécution puisque MSMQ nécessite ce service sur ces systèmes d'exploitation.
Si le service MSMQ 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 manière de supprimer des files d'attente, consultez votre documentation Windows.
Dernières modifications pour la réplication de fusion
Les dernières modifications décrites ci-dessous s'appliquent à la réplication de fusion dans SQL Server 2005.
| 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. |
Regroupement 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 (Transact-SQL) dans la base de données et analysez les colonnes pub_identity_range et identity_range. |
Voir aussi
Concepts
Compatibilité descendante de la réplication
Autres ressources
Amélioration de la réplication