OVH Cloud OVH Cloud

Problème avec les plages d'identités sur les table d'une réplication de fusion

4 réponses
Avatar
Test recherche
Bonjour
Je dispose de plusieurs serveurs SQL 2000 sous windows 2000 serveur
Entre ces serveurs, il y a une réplication de fusion mise en place pour une
base de données.

J'utilise l'attribution automatique de plages d'identité pour les tables de
cette réplication
Les tailles des plages varient selon les utilisations de ces tables
Le seuil de renouvellement de ces plages est de 95%

Ayant lu dans un article sur le msdn que ces plages ne se renouvelle pas
forcément automatiquement,
j'execute un travail deux fois par jour pour recaler les plages d'identité
de mes tables par execution de la procédure stockée
Exec sp_adjustpublisheridentityrange @publication = 'Replication de fusion'

Depuis peu j'ai des problèmes avec les valeurs identity de mes tables
Je reçois des messages comme quoi il est impossible d'insérer un
enregistrement dans une table car il y a violation de la clé primaire avec
impossibilité d'insérer une clé en double
il me suffit de réxècuter le travail pour que le probème soit résolu car
apparament les plages d'identité n'étaient pas renouevller


Et ce matin même erreur sur une table sauf que la valeur Identity courante
est de 6015 alors que j'en étais déjà à 6049 dans la table

Est ce que quelqu'un pourrait m'expliquer pourquoi ces erreurs sur mes
plages d'identités arrivent
et si quelqu'un aurait une solution pour palier à ces problèmes.

Merci d'avance
Stéphane

4 réponses

Avatar
Sylvain Lafontaine
Je ne connais pas la réplication de SQL2000 mais peut-être que vos plages ne
sont pas assez grandes pour les besoins requis? Un seuil de 95% me semble
élevé et laisse peu de place à l'erreur. Vous devriez choisir quelque chose
comme 50% ou peut-être même moins.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF


"Test recherche" wrote in message
news:dj7qj5$c5s$
Bonjour
Je dispose de plusieurs serveurs SQL 2000 sous windows 2000 serveur
Entre ces serveurs, il y a une réplication de fusion mise en place pour
une
base de données.

J'utilise l'attribution automatique de plages d'identité pour les tables
de
cette réplication
Les tailles des plages varient selon les utilisations de ces tables
Le seuil de renouvellement de ces plages est de 95%

Ayant lu dans un article sur le msdn que ces plages ne se renouvelle pas
forcément automatiquement,
j'execute un travail deux fois par jour pour recaler les plages d'identité
de mes tables par execution de la procédure stockée
Exec sp_adjustpublisheridentityrange @publication = 'Replication de
fusion'

Depuis peu j'ai des problèmes avec les valeurs identity de mes tables
Je reçois des messages comme quoi il est impossible d'insérer un
enregistrement dans une table car il y a violation de la clé primaire avec
impossibilité d'insérer une clé en double
il me suffit de réxècuter le travail pour que le probème soit résolu car
apparament les plages d'identité n'étaient pas renouevller


Et ce matin même erreur sur une table sauf que la valeur Identity courante
est de 6015 alors que j'en étais déjà à 6049 dans la table

Est ce que quelqu'un pourrait m'expliquer pourquoi ces erreurs sur mes
plages d'identités arrivent
et si quelqu'un aurait une solution pour palier à ces problèmes.

Merci d'avance
Stéphane




Avatar
Med Bouchenafa
Je ne pense pas qu'il soit necessaire de lancer deux fois pqar jour la
procedure sp_adjustpublisheridentityrange
C'est normalement le role du Merge Agent de faire ce boulot.
Quel article MSDN fais-tu reference ?
Voici un article interessant sur le sujet
http://support.microsoft.com/?id22910

--
Bien cordialement
Med Bouchenafa


"Test recherche" wrote in message
news:dj7qj5$c5s$
Bonjour
Je dispose de plusieurs serveurs SQL 2000 sous windows 2000 serveur
Entre ces serveurs, il y a une réplication de fusion mise en place pour
une
base de données.

J'utilise l'attribution automatique de plages d'identité pour les tables
de
cette réplication
Les tailles des plages varient selon les utilisations de ces tables
Le seuil de renouvellement de ces plages est de 95%

Ayant lu dans un article sur le msdn que ces plages ne se renouvelle pas
forcément automatiquement,
j'execute un travail deux fois par jour pour recaler les plages d'identité
de mes tables par execution de la procédure stockée
Exec sp_adjustpublisheridentityrange @publication = 'Replication de
fusion'

Depuis peu j'ai des problèmes avec les valeurs identity de mes tables
Je reçois des messages comme quoi il est impossible d'insérer un
enregistrement dans une table car il y a violation de la clé primaire avec
impossibilité d'insérer une clé en double
il me suffit de réxècuter le travail pour que le probème soit résolu car
apparament les plages d'identité n'étaient pas renouevller


Et ce matin même erreur sur une table sauf que la valeur Identity courante
est de 6015 alors que j'en étais déjà à 6049 dans la table

Est ce que quelqu'un pourrait m'expliquer pourquoi ces erreurs sur mes
plages d'identités arrivent
et si quelqu'un aurait une solution pour palier à ces problèmes.

Merci d'avance
Stéphane




Avatar
Med Bouchenafa
Si c'est un bug comme le suggere l'article que tu cites, il est preferable
de passer sur un hotfix qui corrige ce bug
SP4 corrige pas mal de bugs concernant la replication

--
Bien cordialement
Med Bouchenafa

"Test recherche" wrote in message
news:djavut$3gl$
En fait, la synchronisation de mes abonnement est plannifié pour
s'éxecuter
au lancement de SQL Server avec un profil que synchronise toutes les 2
secondes
C'est une contrainte de le production de ma socété
et j'ai lu dans l'aide de SQL et cela m'a été confirmer par un autre
article
de microsoft que dans ce style de plannification, il y a un bogue dans SQL
qui n'effectue pas l'ajustement des plages d'identité. Ref
http://support.microsoft.com/default.aspx?scid=kb;fr;304706

Cordialement
Stéphane ZANON


"Med Bouchenafa" a écrit dans le message de
news:
Je ne pense pas qu'il soit necessaire de lancer deux fois pqar jour la
procedure sp_adjustpublisheridentityrange
C'est normalement le role du Merge Agent de faire ce boulot.
Quel article MSDN fais-tu reference ?
Voici un article interessant sur le sujet
http://support.microsoft.com/?id22910

--
Bien cordialement
Med Bouchenafa


"Test recherche" wrote in message
news:dj7qj5$c5s$
> Bonjour
> Je dispose de plusieurs serveurs SQL 2000 sous windows 2000 serveur
> Entre ces serveurs, il y a une réplication de fusion mise en place pour
> une
> base de données.
>
> J'utilise l'attribution automatique de plages d'identité pour les
> tables
> de
> cette réplication
> Les tailles des plages varient selon les utilisations de ces tables
> Le seuil de renouvellement de ces plages est de 95%
>
> Ayant lu dans un article sur le msdn que ces plages ne se renouvelle
> pas
> forcément automatiquement,
> j'execute un travail deux fois par jour pour recaler les plages


d'identité
> de mes tables par execution de la procédure stockée
> Exec sp_adjustpublisheridentityrange @publication = 'Replication de
> fusion'
>
> Depuis peu j'ai des problèmes avec les valeurs identity de mes tables
> Je reçois des messages comme quoi il est impossible d'insérer un
> enregistrement dans une table car il y a violation de la clé primaire


avec
> impossibilité d'insérer une clé en double
> il me suffit de réxècuter le travail pour que le probème soit résolu
> car
> apparament les plages d'identité n'étaient pas renouevller
>
>
> Et ce matin même erreur sur une table sauf que la valeur Identity


courante
> est de 6015 alors que j'en étais déjà à 6049 dans la table
>
> Est ce que quelqu'un pourrait m'expliquer pourquoi ces erreurs sur mes
> plages d'identités arrivent
> et si quelqu'un aurait une solution pour palier à ces problèmes.
>
> Merci d'avance
> Stéphane
>
>








Avatar
Test recherche
En fait, la synchronisation de mes abonnement est plannifié pour s'éxecuter
au lancement de SQL Server avec un profil que synchronise toutes les 2
secondes
C'est une contrainte de le production de ma socété
et j'ai lu dans l'aide de SQL et cela m'a été confirmer par un autre article
de microsoft que dans ce style de plannification, il y a un bogue dans SQL
qui n'effectue pas l'ajustement des plages d'identité. Ref
http://support.microsoft.com/default.aspx?scid=kb;fr;304706

Cordialement
Stéphane ZANON


"Med Bouchenafa" a écrit dans le message de
news:
Je ne pense pas qu'il soit necessaire de lancer deux fois pqar jour la
procedure sp_adjustpublisheridentityrange
C'est normalement le role du Merge Agent de faire ce boulot.
Quel article MSDN fais-tu reference ?
Voici un article interessant sur le sujet
http://support.microsoft.com/?id22910

--
Bien cordialement
Med Bouchenafa


"Test recherche" wrote in message
news:dj7qj5$c5s$
> Bonjour
> Je dispose de plusieurs serveurs SQL 2000 sous windows 2000 serveur
> Entre ces serveurs, il y a une réplication de fusion mise en place pour
> une
> base de données.
>
> J'utilise l'attribution automatique de plages d'identité pour les tables
> de
> cette réplication
> Les tailles des plages varient selon les utilisations de ces tables
> Le seuil de renouvellement de ces plages est de 95%
>
> Ayant lu dans un article sur le msdn que ces plages ne se renouvelle pas
> forcément automatiquement,
> j'execute un travail deux fois par jour pour recaler les plages


d'identité
> de mes tables par execution de la procédure stockée
> Exec sp_adjustpublisheridentityrange @publication = 'Replication de
> fusion'
>
> Depuis peu j'ai des problèmes avec les valeurs identity de mes tables
> Je reçois des messages comme quoi il est impossible d'insérer un
> enregistrement dans une table car il y a violation de la clé primaire


avec
> impossibilité d'insérer une clé en double
> il me suffit de réxècuter le travail pour que le probème soit résolu car
> apparament les plages d'identité n'étaient pas renouevller
>
>
> Et ce matin même erreur sur une table sauf que la valeur Identity


courante
> est de 6015 alors que j'en étais déjà à 6049 dans la table
>
> Est ce que quelqu'un pourrait m'expliquer pourquoi ces erreurs sur mes
> plages d'identités arrivent
> et si quelqu'un aurait une solution pour palier à ces problèmes.
>
> Merci d'avance
> Stéphane
>
>