SQL2000 - Réplication

loggti · 04/10/2006, 11h01

Bonjour,

je suis confronté à une problématique qui me paraît assez étrange. J'ai mis en place une réplication de base. Jusque là pas de soucis, les modifcations dans ma base EDITEUR (Insert, Update, Delete) sont bien impactées dans ma base ABONNEE.

Par contre, dès lors qu'une ligne est supprimée dans ma base ABONNEE, l'agent de Distribution se met en échec, et la réplication ne fonctionne plus, bien évidemment. Est-ce un comportemant normal ? Y a-t-il un moyen de contournement ou bien faut il s'assurer qu'il n'y aura absolument aucune modification dans la base ABONNEE ?

Je suis débutant dans ce domaine, il me manque peut-être certains concepts.

Merci d'avance.
Cordialement,

Jo

SQLpro · 04/10/2006, 11h43

Comencez par indiquer le mode de réplication et l'architecture de la réplication : ou se trouve les éditeurs, la publication et les abonnés.

A +

loggti · 04/10/2006, 12h15

oui effectivement je n'ai pas été très précis.
La réplication est en mode transactionnel.

l'architecture est une architecture de test, les trois bases, EDITEUR, DISTRIBUTION et ABONNEE sont sur un même serveur.

SQLpro · 04/10/2006, 14h06

C'est donc parfaitement normal. Dans ce mode une base ne pout être à la fois abonné et éditeur. Ce mode de réplication est UNIDIRECTIONNEL. La base cible (abonnée) doit être en lecture seule en principe ou bien les tuples mis à jour ne doivent pas eux-mêmes faire l'objet d'une publication.

Si vous voulez tout répliquer dans tous les sens (ce qui n'est jamais conseillé) il vous faut une réplication de fusion. Cela implique que vous aurez TOUJOURS des conflits de réplication, que vous pourrez résoudre, soit de manière automatique (règle de priorité par défaut) soit de manière fonctionnelle en récrivant les triggers de réplication.

Dernier élément, quelque soit le mode de réplication, une base de données se doit d'être PARFAITEMENT normalisée, c'est à dire au moins 3NF + BNCF.

A +

loggti · 04/10/2006, 14h38

Merci pous vos réponses rapides.
je crois que je n'ai pas dû être très clair dans mes explications, je suis désolé.

J'ai bien 3 bases distinctes, une base editeur (Pub par exemple), une base ditribution, et une base abonnee (Abo_Pub par exemple). Ces trois sont cependant sur le même serveur, même s'il est conseillé de mettre la base de distribution sur un serveur dédié.

La réplication que je souhaite est donc bien unidirectionnelle, de ma base Pub vers Abo_Pub. Ce qui se semble parfaitement fonctionner, les lignes rajoutées, modifiées dans Pub se retrouvent bien dans Abo_Pub.
Par contre dès q'une ligne d'une table de la base Abo_Pub est supprimée (à prioiri ça ne devrait jamais être le cas, mais on ne sait jamais !), tout se plante ...

J'ai donc choisi la réplication transactionnelle, justement parceque je ne voulais pas de réplication dans les deux sens, et qu'il existe une option de Snapshot lors de la première exécution.

04/10/2006, 11h01	#1
loggti Nouveau Membre du Club Inscription : mai 2006 Messages : 98 Détails du profil Informations forums : Inscription : mai 2006 Messages : 98 Points : 36 Points : 36	SQL2000 - Réplication Bonjour, je suis confronté à une problématique qui me paraît assez étrange. J'ai mis en place une réplication de base. Jusque là pas de soucis, les modifcations dans ma base EDITEUR (Insert, Update, Delete) sont bien impactées dans ma base ABONNEE. Par contre, dès lors qu'une ligne est supprimée dans ma base ABONNEE, l'agent de Distribution se met en échec, et la réplication ne fonctionne plus, bien évidemment. Est-ce un comportemant normal ? Y a-t-il un moyen de contournement ou bien faut il s'assurer qu'il n'y aura absolument aucune modification dans la base ABONNEE ? Je suis débutant dans ce domaine, il me manque peut-être certains concepts. Merci d'avance. Cordialement, Jo
	00

04/10/2006, 11h43	#2
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	Comencez par indiquer le mode de réplication et l'architecture de la réplication : ou se trouve les éditeurs, la publication et les abonnés. A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

04/10/2006, 14h06	#4
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	C'est donc parfaitement normal. Dans ce mode une base ne pout être à la fois abonné et éditeur. Ce mode de réplication est UNIDIRECTIONNEL. La base cible (abonnée) doit être en lecture seule en principe ou bien les tuples mis à jour ne doivent pas eux-mêmes faire l'objet d'une publication. Si vous voulez tout répliquer dans tous les sens (ce qui n'est jamais conseillé) il vous faut une réplication de fusion. Cela implique que vous aurez TOUJOURS des conflits de réplication, que vous pourrez résoudre, soit de manière automatique (règle de priorité par défaut) soit de manière fonctionnelle en récrivant les triggers de réplication. Dernier élément, quelque soit le mode de réplication, une base de données se doit d'être PARFAITEMENT normalisée, c'est à dire au moins 3NF + BNCF. A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

04/10/2006, 12h15	#3
loggti Nouveau Membre du Club Inscription : mai 2006 Messages : 98 Détails du profil Informations forums : Inscription : mai 2006 Messages : 98 Points : 36 Points : 36	oui effectivement je n'ai pas été très précis. La réplication est en mode transactionnel. l'architecture est une architecture de test, les trois bases, EDITEUR, DISTRIBUTION et ABONNEE sont sur un même serveur.
	00

04/10/2006, 14h38	#5
loggti Nouveau Membre du Club Inscription : mai 2006 Messages : 98 Détails du profil Informations forums : Inscription : mai 2006 Messages : 98 Points : 36 Points : 36	Merci pous vos réponses rapides. je crois que je n'ai pas dû être très clair dans mes explications, je suis désolé. J'ai bien 3 bases distinctes, une base editeur (Pub par exemple), une base ditribution, et une base abonnee (Abo_Pub par exemple). Ces trois sont cependant sur le même serveur, même s'il est conseillé de mettre la base de distribution sur un serveur dédié. La réplication que je souhaite est donc bien unidirectionnelle, de ma base Pub vers Abo_Pub. Ce qui se semble parfaitement fonctionner, les lignes rajoutées, modifiées dans Pub se retrouvent bien dans Abo_Pub. Par contre dès q'une ligne d'une table de la base Abo_Pub est supprimée (à prioiri ça ne devrait jamais être le cas, mais on ne sait jamais !), tout se plante ... J'ai donc choisi la réplication transactionnelle, justement parceque je ne voulais pas de réplication dans les deux sens, et qu'il existe une option de Snapshot lors de la première exécution.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email