DetailPage-MSS-KB

Base de connaissances

Numéro d'article: 322910 - Dernière mise à jour: mercredi 5 novembre 2003 - Version: 3.2

 

Sommaire

Résumé

Un des défis pour la réplication de fusion et publipostage et toute autre technologie qui partage nouvellement insérées les données entre différentes bases de données, est la gestion des valeurs de colonne incrémentielle qui sont fréquemment utilisées en tant que "id" clés primaires colonnes pour une table.

Par exemple, si deux bases de données partager des données dans une table contenant une colonne ID incrémentielle et les deux tables ont des valeurs ID de 1 à 100, l'insérer dans chaque base de données suivant est 101. Lorsque les nouvelles lignes sont copiés dans l'autre base de données, il y a deux lignes avec la valeur 101. Car les colonnes de clé primaire doivent disposer d'un index unique, une violation de contrainte d'unicité se produit.

Si les problèmes liés à toutes les techniques et la réplication incrémentation sont identiques, cet article porte sur la façon dont la réplication de fusion gère la propriété IDENTITY de SQL Server 2000.

Plus d'informations

Identité des colonnes de réplication de fusion

L'objectif de réplication de valeurs d'identité est d'utiliser une technique incrémentation, afin qu'insertion effectuée sur différents serveurs n'utilisera pas les mêmes valeurs incrémentielles. Étant donné que la réplication de fusion doit gérer les serveurs qui sont déconnectés et qui ne peut pas communiquer entre eux, il ne peut pas coordonner chaque Insertion pour utiliser la valeur de code disponible suivante entre les deux copies de la table.

Utilisateurs ranged

Les utilisations de réplication de fusion et publipostage solution est « identités ranged », dans laquelle chaque article publié est affecté à une plage de valeurs de compteur. Les valeurs d'identité dans chaque table commencent à la valeur minimale de la plage et incrémenter la valeur maximale de la plage. Par exemple, les affectations de plage peuvent être définies comme lots de 100 :

                   Range      Range
Server             Minimum    Maximum
------------------ ---------- ---------- 
Publisher                 1      100
Subscriber1             101      200
Subscriber2             201      300
				

Pour implémenter ces plages, elle de départ pour la colonne identité dans chaque table est définie à la valeur minimale de la plage, qui alimente les valeurs incrémentielles commence à la fin de la plage faible. Pour contrôler la fin de la plage, une contrainte CHECK est utilisée pour empêcher les valeurs de colonne d'identité de tomber en dehors de la plage. Par exemple, un tableau Publisher peut-être être défini comme :
CREATE TABLE id_table
(
     ID int identity (1,1) not for replication primary key,
     CONSTRAINT id_range_check CHECK (ID BETWEEN 1 AND 100)
)
				
Subscriber1 le tableau serait :
CREATE TABLE id_table
(
     ID int identity (101,1) not for replication primary key,
     CONSTRAINT id_range_check CHECK (ID BETWEEN 101 AND 200)
)
				
Subscriber2 le tableau serait :
CREATE TABLE id_table
(
     ID int identity (201,1) not for replication primary key,
     CONSTRAINT id_range_check CHECK (ID BETWEEN 201 AND 300)
)
				

Affectation de plages nouveau

À l'aide les définitions de table sont antérieures dans cet article, chaque abonné pouvez correctement insérer 100 lignes et ces données nouvellement insérée peuvent puis répliquées en toute sécurité à l'autres abonné (ou Publisher) bases de données sans erreur ou sans index unique violations. Toutefois, après la ligne un centième, début insère à échouer avec messages indiquant la plage d'identité côté de l'abonné a renseigné des :
Serveur: Msg 548, Niveau 16, État 2, ligne 1

La plage d'identité gérée par réplication est plein et doit être mis à jour par un agent de réplication. Le conflit INSERT s'est produite dans base de données dbGeneralMergeSub, le tableau « t1 » colonne 'c1'. Sp_adjustpublisheridentityrange peut être appelée pour obtenir une nouvelle plage d'identité.

L'instruction a été arrêtée.
Lorsque la plage d'identité d'origine est pleine, l'agent de réplication devez créer une nouvelle plage avant d'autoriser les plus de lignes à insérer dans la table. Dans l'exemple précédente, la plage suivante disponible est 301-400, et le code Transact-SQL suivant est utilisé pour implémenter la nouvelle plage :

ALTER TABLE id_table DROP CONSTRAINT id_range_check

DBCC CHECKIDENT('id_table','reseed',301)

ALTER TABLE WITH NOCHECK id_table ADD CONSTRAINT id_range_check
CHECK (ID BETWEEN 301 and 400)
				
Après ce point, insère est autorisés dans la table et commencent à incrémenter de la nouvelle plage. Notez que ce code est pour explicative uniquement. La réplication de fusion gère ce processus pour vous, et vous ne pouvez pas utiliser cette technique si la table est publiée pour la réplication de fusion et publipostage.

Comment faire pour implémentation identités Range géré avec la réplication de fusion

Bien qu'il soit possible d'implémenter ranged identités indépendamment de la réplication de fusion, il peut être très difficile à gérer les affectations de plage et réallouer les nouvelles plages, surtout si les serveurs ne possèdent pas une liaison réseau fiables.

Colonnes d'identité et pas de réplication

Il existe un compte spécial de garder à l'esprit lors de la réplication tables avec des colonnes compteur. Par défaut, SQL Server ne sait pas la qui effectue l'insertion. Il peut être un processus utilisateur qui exécute une insertion, ou il peut être le processus de réplication de fusion et réplication de l'insertion d'utilisateur. Par défaut, dans les deux cas, SQL Server essaie à incrémenter la colonne des identités lors du chargement la ligne. Toutefois, vous souhaitez généralement SQL Server pour incrémenter la valeur uniquement lorsque l'utilisateur effectue l'insertion, mais vous ne souhaitez pas la valeur incrémentée lorsque le processus de réplication insère la nouvelle ligne dans un autre serveur dans la topologie de réplication. Lorsqu'un la ligne est insérée dans un autre serveur vous souhaitez généralement qu'il conserve la valeur de l'insertion d'origine.

Pour cette raison, si vous prévoyez de publier un tableau qui contient une colonne à l'aide de la propriété IDENTITY, vous devez utiliser la propriété ne de réplication (NFR) pour la colonne IDENTITY. Lorsque cette option est définie, SQL Server reconnaît les processus de réplication de fusion lorsque leur effectuent l'insertion et la valeur de colonne d'identité d'origine est conservée.

Si la propriété NFR n'est pas utilisée, vous pouvez recevoir plusieurs types différents d'erreurs au cours du processus de fusion et. La plage erreurs d'index unique erreurs erreurs plus subtiles telles que des violations de clé étrangères et erreurs de déclencheur.

Ajouter le non de l'option de réplication pour les tables existantes

Si vous publiez une table existante avec une colonne IDENTITY, vous devez tout d'abord ajouter la propriété non de réplication à la colonne IDENTITY. Il est relativement facile si la table est vide. Vous simplement supprimer la table et recréez avec l'option non de réplication. Toutefois, car, l'instruction Transact-SQL ALTER TABLE n'autorise pas modifier les propriétés de colonne IDENTITY, il peut devenir plus difficile si, par exemple, il est données qui doivent être conservées, ou si la colonne IDENTITY est également la clé primaire de la table et autres tables des contraintes FOREIGN KEY qui font référence à la colonne des identités clé primaire.

Voici le processus de base pour ajouter la propriété non de réplication à une table existante :
  1. Sauvegardez la base de données.
  2. Copier les données de la table dans une autre table ou dans un fichier.
  3. Enregistrez le script SQL pour les contraintes de clé étrangère faisant référence à la table d'identité, puis puis supprimer les clés étrangères. Vous devez ces scripts pour recréer les clés étrangères ultérieurement.
  4. Supprimer la table d'identité et puis le recréer avec l'option non de réplication.
  5. Définissez l'option IDENTITY_INSERT à lors de la table.
  6. Copier les données de l'autre table ou le fichier revenir à la nouvelle table.
  7. Définissez l'option IDENTITY_INSERT désactivé pour la table.
  8. Recréez les clés étrangères en utilisant le script enregistré précédemment.

Comment faire pour configurer articles de réplication de fusion et publipostage

Lorsque vous créez un article pour la composition qui est basé sur une table avec les colonnes compteur, la procédure sp_addmergearticle stockées fournit ces options :

@auto_identity_range
Les valeurs attendues sont VRAI et FAUX. La valeur par défaut est FALSE. Si la valeur TRUE, la réplication de fusion gère les étendues d'identité sont allouées à chaque abonné de la table.

@pub_identity_range
Cette valeur détermine la taille de la plage identité qui est définie pour la table dans la base de données publiée. Si la table publiée comporte déjà des données, la nouvelle plage commence de la valeur maximale existante dans la colonne.

@identity_range
Cette valeur est la taille de la plage est définie pour la table de chaque base de données d'abonnés.

@Threshold
Cette valeur allant de 1 à 100 et définit le pourcentage de la plage qui provoque du processus de fusion et publipostage affecter une nouvelle plage. Par exemple, si la taille de la plage est 100, de 1 à 100 et le @threshold est 80, l'Agent de fusion s'affecter une nouvelle plage après la valeur 80.

Remarque : les mêmes paramètres de procédure stockée et les fonctionnalités de gestion des identités sont disponibles pour articles de réplication transactionnelle, dans la procédure sp_addarticle stockées.

Considérations particulières de réaffectation des plages

Il est important de réaliser que plages d'identité sont gérés à la composition et les bases de données de distribution, et qu'ils sont uniquement re-allocated lors du traitement réplication de fusion et publipostage. Plages gérés sont contrôlés via une contrainte CHECK sur les tables. Par conséquent, si les utilisateurs suffisamment insère pour remplir la plage de leur table, toutes les insertions ultérieure échouer avec l'erreur 548 (mentionnée dans la section « utilisateurs Ranged » de cet article). La seule façon obtenir une nouvelle plage d'une table abonné est d'exécuter l'Agent de fusion. Si plage un éditeur est plein, vous pouvez réaffecter une nouvelle plage sans exécuter l'Agent de fusion en appelant la procédure sp_adjustpublisheridentityrange stockées.

Les options de gestion des identités de planification

Avant d'implémenter gestion des identités ranged avec la réplication de fusion, vous devez tout d'abord considérer le nombre d'insertions seront effectuées par les utilisateurs et la fréquence à laquelle ils va être fusionner leurs modifications. Le principal objectif lorsque vous définissez les options d'identité d'un article est pour rendre les plages assez grandes que l'abonné ne fonctionnera pas de valeurs avant la fusion suivante.

Si les plages sont trop petites, les utilisateurs ne peuvent pas insérer nouvelles lignes après que la plage est pleine. Toutefois, si la taille de la plage est trop grande et chaque abonné utilise uniquement une petite partie de leur plage, il sera grands espaces dans les valeurs incrémentielles. Ceci peut être un problème de perception pour les utilisateurs habitués aux valeurs strictement incrémentielles. Il peut être possible pour les tranches alloués devenir très volumineux, qui rend les valeurs ont chiffres autant qu'ils se trouvent difficile pour les utilisateurs doivent saisir manuellement valeurs D'ID dans les pages Web ou autres interfaces utilisateur. Dans les cas extrêmes, il est possible pour les tranches alloués est supérieur aux limites pour le type de données de la colonne des identités.

Si intervalles sont acceptables et que vous avez un petit nombre d'abonnés, vous pouvez rendre la plage est assez grande afin que les abonnés devra probablement jamais une nouvelle plage. Vous pouvez également vous pouvez lui permettant leur suffit d'une nouvelle plage chaque jour, semaine ou mois, en fonction des besoins de l'application.

Vous pouvez également utiliser le @threshold valeur pour définir comment considérablement l'Agent de fusion alloue une nouvelle plage avant la plage ancienne pleine. Paramètre @threshold trop faible entraîne les plages est réaffectés bien avant qu'ils remplir, qui entraîne également intervalles supérieures s'affiche dans les valeurs incrémentielles. La valeur trop élevée defeats l'objectif de la valeur. L'Agent de fusion et ne pas affecter une nouvelle plage même si la plage ancienne est presque plein, rendant plus susceptible remplir et provoquer des erreurs avant la fusion suivante.

Considérations particulières pour republier

Avec la réplication de fusion vous pouvez répliquer des données entre une hiérarchie de éditeurs et abonnés. Par exemple, vous pourriez répliquer des données d'un serveur central d'entreprise à des serveurs régionaux et des serveurs régionaux pour Ville local abonnés. Tout d'abord vous publier les données à partir du serveur central et définir des souscriptions à partir des serveurs régionaux à l'éditeur central. Puis vous republiez les serveurs régionaux abonné et définir des souscriptions de la ville de nœud non-feuille abonnés pour les éditeurs régionaux.

Les exemples précédents présentés ont abordé la gestion des plages d'identité dans le contexte d'un seul éditeur et un ou plusieurs des abonnés. Lorsque plusieurs niveaux de éditeurs et abonnés est définis dans une topologie, vous devez conserver N'oubliez pas que plages des abonnés sont allouées à partir plage de leur Publisher. Lorsque plage l'éditeur est plein, que Publisher doit demander une nouvelle plage à partir de leur Publisher et ainsi de suite, haut vers le nœud supérieur. Pour cette raison, vous devez effectuer les plages assez grand pour les compositions de niveau supérieur et plus en plus petits pour les niveaux inférieurs de la hiérarchie.

Plages d'identité et plusieurs compositions

Avec la réplication de fusion et vous pouvez publier une seule table dans plus d'une publication de réplication de fusion, et le tableau Publisher peut être un abonné à une composition de réplication transactionnelle. Car les articles peuvent être définis avec paramètres identité ranged différente dans les compositions différentes, vous devez veillez à utiliser les mêmes paramètres pour @auto_identity_range , @pub_identity_range , @identity_range et @threshold sur toutes les compositions.

Alternatives à utilisateurs Ranged gérés

Personnalisé créé gestion des identités Range

Vous pouvez implémenter identité plages vous-même, indépendamment de la réplication. La configuration requise de base est la suivante :
  • Utiliser l'option non de réplication sur les colonnes Compteur.

  • Définir la valeur valeur de départ pour chaque base de données afin que chaque abonné démarre incrémentation à une autre valeur.

  • Définir une contrainte CHECK pour empêcher les valeurs de débordement de la plage de la base de données.
Les exemples de table dans la section « utilisateurs Ranged » de cet article expliquent comment implémenter des plages d'identité. Toutefois, comme indiqué dans cette section, la difficulté est Affectation de plages de nouveau lorsque la plage actuelle remplit des. En particulier si les bases de données déconnectés ne peut pas connectez à un serveur de contrôle unique qui gère les plages.

Cette option est particulièrement utile dans les cas lorsque sont relativement peu d'insertions dans la base de données, et que vous ne souhaitez pas que traiter les problèmes d'administration de l'aide des fonctionnalités de réplication de fusion.

Composé des clés primaires

Vous pourrez publier des tables avec des colonnes compteur et utilisez pas de plages gérés. Cependant, pour empêcher les violations de clé uniques, vous devez définir une contrainte de clé composée ou un index basé sur l'identité plus des autre valeur qui est dupliquée dans les bases de données.

Une bonne option consiste à inclure une colonne calculée dans la table qui utilise une fonction telle que @@SERVERNAME ou SUSER_SNAME(). Votre table est peut-être déjà une colonne utilisée dans un autre but répondant à ce besoin. Vous pouvez ensuite définir la clé primaire ou la contrainte unique en fonction de la colonne des identités et l'autre colonne.

Le premier problème est que la combinaison de valeurs dans la clé composée doit être unique dans la topologie de réplication. Si, par exemple, les utilisateurs peuvent se connecter à des serveurs différents, ces valeurs ne peuvent pas être uniques. Voici un exemple :
Un utilisateur, nommé « mergeuser » peut se connecter à deux serveurs différents et insérer une ligne. Les deux serveurs, la colonne qui calcule la fonction SUSER_SNAME maintenant contient la valeur mergeuser. Si la valeur de la colonne identité au serveur est le même (tels que 101), la clé composée n'est pas unique entre les deux serveurs et provoque une violation de clé en double sur une fusion ultérieure.
Le deuxième problème avec cette technique est que les valeurs D'ID sont fréquemment utilisées pour les besoins comme client et factures où ainsi que le nom du serveur ou au nom d'utilisateur de la valeur peut ne pas convenir.

Enfin, il existe des génériques problèmes avec des clés composées. Si elle est référencée par une contrainte de clé étrangère d'une autre table, cette table doit également posséder des deux colonnes. Cela rend Transact-SQL codage plus difficile et utilisant plusieurs colonnes dans l'index composés est peut-être moins optimal à colonne unique des index uniques.

Valeurs aléatoires

Vous pouvez également utiliser la fonction Transact-SQL ALEA pour générer des valeurs D'IDENTIFICATION. Toutefois, ces valeurs ne sont pas toujours acceptables pour les utilisateurs prévu des valeurs incrémentielles et d'autres types de cohérence dans les valeurs. Tandis que la fonction ALEA garantit caractère aléatoire, elle ne garantit pas leur caractère unique. Selon la façon dont la fonction ALEA est utilisée, il représente une probabilité statistique qu'une valeur aléatoire est dupliquée à un moment donné dans le futur.

Colonnes GUID (est UNIQUEIDENTIFIER)

L'alternative final à l'utilisation des valeurs incrémentielles consiste à utiliser « guid » colonnes, ou les colonnes qui sont définies avec le type de données est UNIQUEIDENTIFIER et qui est rempli avec les valeurs générées par la fonction NEWID. Ces valeurs sont toujours forcément être unique, ils peuvent être un bon candidat. Ces valeurs sont dans ce format :
9AAA35AE-D5F0-4 C 24 BF92-7EF20740C995
En raison de leur longueur et le format, elles ne sont pas très convivial pour les utilisateurs qui doivent être compatible avec les valeurs manuellement. Si les tables sont strictement accessible par le biais d'un code et pas utilisés par les utilisateurs, il s'agit en fait une très bonne option. Si vous publiez la table avec la réplication de fusion, la table doit comporter une colonne est UNIQUEIDENTIFIER (avec la propriété ROWGUIDCOL et un index unique), afin de ne pas avoir pour que les considérations spéciales pour les valeurs d'identité.

RÉFÉRENCES

En ligne de SQL Server 2000 ; rubriques: « gestion des identités valeurs » » à l'aide pas de réplication » "sp_adjustpublisheridentityrange"; « planification de développement d'applications »

Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 2000 Standard
Mots-clés : 
kbmt kbinfo KB322910 KbMtfr
Traduction automatiqueTraduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 322910  (http://support.microsoft.com/kb/322910/en-us/ )
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Partager
Options de support supplémentaire
Forums du support Microsoft Community
Nous contacter directement
Trouver un partenaire Microsoft Certified Partner
Microsoft Store