Discussion :

[Exsilius]

Bonjour à tous

Nous sommes confrontés à un problème aussi délicat qu'urgent.

Nous avons une base centrale qui créé réguliérement un certain nombre de publication (une quarantaine par semaine) et plusieurs base satellites qui s'abonne (nous utilisons la réplication de fusion).

La création des publications plante assez facilement dans certaines conditions de tests identifiés (interruption forcée, ...) mais également de manière inopinée. Si vous avez des retours d'expériences sur ce point nous serions déjà intéressé.

Le problème principal réside dans le fait que dés qu'une publication est plantée, la base entière (et parfois seulement une table) est verrouillé en ecriture. Nous n'avons pas de DBA qualifié pour ce genre de problèmatique et votre aide nous serais précieuse.

A l'heure actuelle, le seul moyen que nous avons identifié pour débloquer la base (ou la table) est de supprimer toutes les publications. Ce qui ne sera évidemment pas acceptable dans le cycle de production...

Merci d'avance.

[kagemaru]

qq détails à nous fournir :

vous dropper et recréer 40 pubs chaque semaine ou vous ajoutez 40 pubs chaque semaine (ce qui doit en faire pas mal au bout d'un an :-/

Pour éviter de verrouiller vos tables à la génération des pubs, il y a l'option de non-concurrence à cocher dans les propriétés de la pub, celle-ci sera utile à la génération du snapshot puisque les tables restent accessibles.

et pour les plantages inopinés, il serait utile de fournir les messages d'erreur, pour nous permettre de bien comprendre ce qu'il se passE.

[Exsilius]

Merci, nous allons regarder le paramètre de non-concurrence.

Pour les compléments d'infos :
- Les publications sont configurées pour être détruites au bout de 14 jours (ce qui nous fera environ 120 pub en simultané grand maximum)
- Le dernier message d'erreur que nous avons eu s'est produit sur un blocage de table :
* L'erreur se produit sous SQL Server Management Studio lors de l'insertion d'une occurence dans la table verouillé
* L'erreur produite est un mystérieux "appel à msMerge_Expand_sp_<id>"

Je n'ai pas l'info du message d'erreur lorsque c'est un blocage complet de la base qui se produit. Mais bien que le message soit différent, il me semble que la cause, les symptômes et le moyen de résoudre (suppression de toutes les publications) semblent être identique...

[Exsilius]

++

Nous n'avons pas identifié l'option de non-concurrence sur la publication.
Un coup de main serait la bienvienue

Toutes autre pistes également...

[SQLpro]

Utiliser la réplication de fusion est déjà quelque chose de lourd et de compliqué et nécessite de bonne connaissances des mécanisme de réplication et d'administration derrière...

Mais en plus ajouter et supprimer régulièrement des publications est assez casse gueule et semble montrer que votre fonctionnel est en cause.

En principe la réplication est a établir une fois pour toute sur chaque serveur. Après on y touche plus.
Soit vous n'avez pas compris ce qu'est une réplication, soit vous l'utilisez anormalement. Dans les deux cas il faut revoir votre mode fonctionnel et passer à autre chose !

Décrivez donc plus en avant pourquoi et dans quel contexte fonctionnel vous avez choisit cette technique....

A +

[Exsilius]

Je prends note de vos remarques, SQLpro. Et bien que j'imagine assez aisément que nous ne sommes pas les seuls au monde à devoir créer dynamiquement des publications pour réplication de fusion, je vais vous présenter certaines spécifications du projet car je suis évidemment ouvert à toutes propositions répondant à nos besoins.

Trés schématiquement nous avons 2 types d'éléments :
- Des éléments principaux
- Des sous-éléments
Chaque élément principal est amené à contenir des sous-élément en fin de process.

Nous avons un centre principal et plusieurs centres de production en divers endroits de la planète.
- Le centre principal est le seul habilité à créer les éléments principaux de la base. Il utilise donc une application de gestion relativement classique pour créér hebdomadairement ces éléments principaux.
- Les centres de production ont pour rôle de créer les sous-éléments d'une partie prédéfinie des éléments principaux. Ils utilisent une application de saisie spécialisée.

La solution que nous avons adopté est de créer une publication à chaque création d'un élément principal.
Une application supplémentaire, dans les centres de production, permet de créer l'abonnement en local et de lancer la réplication afin de transférer l'élément principal.
Une fois le travail du centre de production effectué (création des sous-éléments de l'élément rappatrié), la réplication de fusion est relançée afin de renvoyer au centre principal les sous-éléments traités.

Plusieurs centres peuvent travailler sur un même élément, mais travaille obligatoirement sur des sous-éléments de nature différente.
La réplication de fusion est une solution qui répond parfaitement à l'ensemble de ces besoins. Tout fonctionne parfaitement et assez simplement, tant que la publication ne plante pas.

Pour rappel, mon problème initial réside dans le fait que dés qu'une publication plante (ce qui constitue un premier problème), la base centrale est bloqué en ecriture. Or, le seul moyen que nous avons identifié pour dévérouiller la base est de supprimer toutes les publications.