Discussion :

[Peck777]

Bonjour,

J'ai un problème plutot urgent à régler sur la bdd de mon client. voilà le problème.
tout d'abord c'est une base répliqué (transctionnelle avec mise à jour).
un programme rempli une des tables très régulièrement, cette table possède une clé primaire clustered avec un id (compteur auto). cette colonne est 'pas pour la réplication', ce qui permet au moteur sql de gérer des plages automatiquement sur les 2 serveurs en question (ce que dit la doc).
sauf que ce matin, le programme sort systématiquement une exception de violation de clé primaire sur cette table, donc sur le compteur auto. ce qui m'étonne, il doit gérer cette contrainte automatiquement, non ?

alors, je me suis penché sur la question des plages, et je trouve pas d'explication, encore moins de solutions pour sortir de ce merdier.
(excuser moi du terme, mais là je suis à peine grossier vu la situation)

si vous avez déjà rencontrer ce problème, ou tout simplement connaissez l'astuce, je vous paie une bouteille de champagne !! c'est pas des conneries, je suis reellement prêt à le faire.

Peck777 dans le caca juste au coup

[Peck777]

autre indication :

pour satisfaire la demande pressante de mon client, j'effectue les insertion dans cette table sur le 2ième serveur (l'abonné en fait), ça marche plutot bien mais le temps de réplication ne me permet pas d'être performant.
de plus, une fois les lignes insérées, je vois bien qu'une plage différente a été utilisée...

[rudib]

Bonjour,

Le NOT FOR REPLICATION ne gère pas les plages automatiquement. Tu dois manuellement indiquer sur chaque serveur quelle est la plage d'identity en utilisant le seed.

Tu as un peu d'aide sur le sujet, en anglais, ici :
http://www.quest-pipelines.com/newsletter-v4/0903_F.htm

[Peck777]

désolé de te contredire mais la doc stipule le contraire :

"Automatique. Utilisée pour la réplication de fusion et la réplication transactionnelle avec des mises à jour sur l'Abonné. Spécifiez des plages de taille pour le serveur de publication et les Abonnés, et la réplication gère automatiquement l'affectation des nouvelles plages. La réplication définit l'option NOT FOR REPLICATION pour la colonne d'identité sur l'Abonné, de sorte que seules les insertions des utilisateurs provoquent l'incrémentation de la valeur sur l'Abonné [...]"

de plus, les seeds ne me servent pas pour cette table puisque l'appli qui la rempli est exécuter sur le publisher uniquement.

merci quand même

Débat relancé ...

[rudib]

Ok, ce que tu veux dire c'est que la table n'est mise à jour que sur le publisher ? Donc tu n'as pas besoin de gestion d'identity sur les subscribers, c'est ça ? Simplement un problème de violation de clé. Si c'est le cas, tu n'as pas besoin d'avoir de NOT FOR REPLICATION et de mettre les subscribers en identity. A moins que je n'ai pas bien compris encore une fois.

Si c'est un problème de clé existante sur une table sur un subscriber, ne peux-tu pas vider la table du subscriber dans une table temporaire, lancer la réplication et remettre les lignes non doublonnées de nouveau dans la table à partir de la table temporaire ?

[Peck777]

bon, je sais que je n'ai surement pas opté pour la bonne structure, car ce projet a été défini au fur et à mesure du développment.
ceci dit, tu as raison dans le principe. je n'ai pa besoin des identity sur les abonné, sauf que l'assistant de réplication sql 2k5 ne m'en a pas laissé le choix. je devais le mettre.
de plus, cette base abonnée doit refléter exactement le publisher au cas de crash du publisher. je dois donc tout répliquer.
c clair que ça ne ma facilite pas la tache mais je n'ai pas le choix, ce système est situé en 2 sites distants, ça doit marcher, point barre (dixit mon client)

bref, pour t'éclairer un peu plus, je détaille :
la table en question comptait exactement 28898 enregistrements et l'id était à 53755. l'écart est dû à des suppressions de lignes de tests au début du projet.
tout à très bien fonctionné jusque là, aucun problème, réplication parfaite depuis maintenant 4 mois.

mais ce matin (vendredi 25/08) à 8h30 environ, violation de clé primaire inexpliquée.
comme si il n'arrivait plus à incrémenter l'id et passer à 53755

petite indication qui a peut-être son importance : installation du SP1 sur les deux serveurs effectuée le mardi et mercredi précédent. Mais je pense que cette violation aurait dû apparaitre dès ce jour là si cela venait du SP1...

dans les propriétés de l'article, le pramétrage de l'indexation semble correct. sans changer les paramètres par défaut : plage du publicateur = 10000 ; plage des abonnés = 1000 ; incrément = 1 ; %age de remplissage = 80.
la prochaine id pour le plublicateur est à 61000, ce qui est normal vu qu'en déplaçant mon appli sur l'abonné, il a inseré des id à partir de 60000.
à l'heure où j'écris l'id en est à 60454.

le moteur de publication a l'air de bien fonctionner, n'est pas ?