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 ?

[rudib]

J'essaie encore de comprendre : tu dis que la base abonnée doit refléter le publisher, et tu mets des deux côtés un identity, donc sur le subscriber, il va faire un SET IDENTITY_INSERT ON, pour insérer les mêmes id que sur le publisher. Donc du côté du subscriber, il n'y a pas d'incrémentation de l'identity de toute manière. Cela voudrait dire qu'il y a simplement un doublon d'id, dû par exemple à une désynchronisation, ou à un ajout manuel. Peux-tu comparer les deux tables avec la version trial d'un outil comme Red Gate SQL Data Compare ou SQLDelta, et corriger à la main, ou regénérer un snapshot pour reprendre la réplication proprement ?
N'hésite pas à me corriger si je n'ai pas bien compris.

[Peck777]

c comme ça que ça doit marcher, effectivement !

j'ai comparer avec Apex Diff 2005 (trial) et les deux bases sont parfaitement identiques. ce qui confirme l'absence d'erreur dans le moteur de réplication.
c'est déjà ça

j'ai essayé en redémarrant sql server et sql server agent, mais rien.
je vais faire d'autres essais ce week end. je suis d'astreinte (et oui )

[Peck777]

je n'ai po réussi ! même en reconstruisant l'index, rien n'y fait.

c vraiment bizarre, j'ai d'autres tables qui fonctionnent sur le même principe, et tout va bien. à la seule exception près que la clé primaire de ces tables n'est pas la colonne ID mais une clé composé d'autres colonnes.

c'est peut-être ça l'astuce ?

en tout cas, je pense de plus en plus à un bug de SP1, voire pire, une modif prévue mais non documentée.

une autre idée ?

[rudib]

C'est logique qu'en reconstruisant l'index ça ne change rien, ça prouve qu'il n'y a pas de problème avec l'index.

Peut-être qu'il y a désynchronisation, comme je le suggérais, et que SQL Server essaie de réinsérer une valeur déjà présente.

Ce que tu peux peut-être faire est de supprimer temporairement la contrainte de clé primaire sur le subscriber, lancer la réplication, supprimer éventuellement le doublon s'il s'est créé, et remettre la contrainte. A voir ensuite si le problème se reproduit.

[Peck777]

Bon, je pense avoir trouvé !!

j'ai cherché du côté des tables systèmes et j'ai remarqué avec stupeur que TOUTES mes clés primaires ont disparus de la table sys.indexes

causes possibles :
1- passage du SP1 de SQL 2005 qui ne sait pas fait correctement.
2- les index ont changer de place depuis la SP1, mais le moteur cherche toujours dans sys.indexes ???!!!

je n'ose pas restaurer la sauvegarde de mes tables systèmes avant SP1, j'ai peur de perdre des données importante.

je ne sais pas trop quoi faire ?

j'essaierais bien ta solution rudib, mais je ne sais pas arréter la réplication, elle tourne en continu...

RECTIFICATION : c'est ne pas les index qui ont sauté, mais le moteur lui-même qui ne gère plus mes plages automatiques. je ne sais pas pourquoi; mais je n'ai plus envie de chercher. je vire la réplication et je recommence

merci rudib pour tes réponses

à +