[RS]DDL Replication Server [Résolu]

[diablolight]

Bonsoir,

J'ai quelques petits soucis avec le concept de base de Sybase Replication Server.
Voila, j'ai plusieurs bases sources (ASE 12.5.0.3 avec même modèle de donnée) qui doivent être répliquées en une seule (modèle identique si ce n'est l'ajout d'une colonne pour différencier les données).
Le problème se pose lorsqu'il y a changement (assez conséquent) du modèle sur les bases à répliquer (lors d'une nouvelle version), comment peut-on répercuter ce changement sur la base destination de façon relativement automatique et surtout sans avoir à refaire une matérialisation ?

Merci Beaucoup.

[mpeppler]

A priori il faut créer des scripts d'alter table appropriés - je ne sais pas si il existe déjà des outils qui font cela (peut être DBArtisan), mais autrement cela devrait être possible sans trop d'effort avec un script perl.

Michael

[diablolight]

Ok, effectivement j'ai appris qu'il existait plusieurs modes de Replication Server (REPDEF, MSA ou WSB).
Dans mon cas, il s'agit de REPDEF (cela signifie donc que ce mode autorise la redéfinition d'ordres SQL tel que 'create, alter...' ?
Apparamment, celui-ci se baserait sur le journal de transaction pour répliquer.
N'y a-t-il pas des limites notamment avec les opérations non journalisables comme le 'select into' ?
En gros, ce mode de réplication n'est-t-il pas obsolète par rapport aux autres ?

[mpeppler]

La répli Sybase passe toujours par le journal de transaction.
L'utilisation de repdefs est toujours d'actualité, tout dépend des besoins et de l'architecture utilisée.

Dans le cas présent les repdefs peuvent être modifiées (alter replication definition ...), ou alors droppées/recrées avec les modifs de DDL.

La réplication MSA est plus simple à mettre en oeuvre, mais il est nettement plus difficile d'appliquer des modifications de structure entre la source et la destination (ajout de colonne).

Michael

[diablolight]

Merci, cela répond largement à mes questions.

[DBRep]

Envoyé par diablolight

Voila, j'ai plusieurs bases sources (ASE 12.5.0.3 avec même modèle de donnée) qui doivent être répliquées en une seule (modèle identique si ce n'est l'ajout d'une colonne pour différencier les données).

Bonsoir,

Il serait plus simple, notamment en cas de resynchronisation des données, d'avoir le même modèle de donnée entre les bases sources et la base centrale, quitte à ajouter cette colonne dès la/les bases sources et ainsi, l'alimenter automatiquement dès la source.

De plus, si le modèle de donnée central contiens une colonne supplémentaire, l'utilisation des Replication Definition et la personnalisation des Function String sera inévitable.
Ceci impliquera des taches de mise à jour supplémentaires lors de l'évolution des modèles de donnée sources<=>central (mise à jour des Replication Definition et des Function String en plus de la mise à jour des modèles de donnée).


DBRep

[DBRep]

Envoyé par diablolight

Dans mon cas, il s'agit de REPDEF (cela signifie donc que ce mode autorise la redéfinition d'ordres SQL tel que 'create, alter...' ?

Non.
Les Replication Definition (RepDef) définissent le modèle de donnée tel qui devra être "publier".
Cela ne permet pas (ne sert pas) à la réplication des ordres DDL (tel que 'create ...', 'alter ...', etc...), uniquement les ordres DML.
Les Function String associées aux RepDef, permettent la redéfinition des ordres SQL DML.

Pour la réplication des DDL, il vous faudra mettre en place un système de réplication de type MSA (DB RepDef), mais dans ce cas, les modèles de données entre la source et la destination devront correspondre (d'ou mon premier post)

Envoyé par diablolight

Apparamment, celui-ci se baserait sur le journal de transaction pour répliquer.
N'y a-t-il pas des limites notamment avec les opérations non journalisables comme le 'select into' ?

Effectivement, la réplication Sybase se base sur le journal de transaction, ce qui implique que les opérations non journalisées ne pourrons être répliquées.


DBRep

[diablolight]

Bonsoir,

Vous avez raison DBRep, les Fonction String vont être pour l'occasion personnalisées et mise à jour à chaque changement de modèle de donnée (je dispose d'outils d'automatisations me permettant de réaliser ces taches sans trop d'effort !).
A priori, je n'ai malheureusement pas trop le choix de partir dans cette direction, l'ajout de la colonne au niveau des bases sources entrainerait un développement beaucoup trop important au niveau de la mise à jour de l'application cliente.
Finalement, je pense qu'il me reste quelques "moulinettes" à écrire (en particulier pour la mise à jour du modèle sur la base centrale à partir de DDLGEN source...)

Je vous remercie pour ces infos.

[DBRep]

Envoyé par diablolight

... l'ajout de la colonne au niveau des bases sources entrainerait un développement beaucoup trop important au niveau de la mise à jour de l'application cliente.

?!?
L'ajout d'une colonne dans une/les table(s) en lui associant une valeur par défaut, soit, differente pour chaque base source, ne devrait entrainer aucune mise à jour de l'application cliente ...
Normalement c'est un des avantages à travailler avec des SGDBRs ...


DBRep - 2cts

[Roller]

Envoyé par DBRep

?!?
L'ajout d'une colonne dans une/les table(s) en lui associant une valeur par défaut, soit, differente pour chaque base source, ne devrait entrainer aucune mise à jour de l'application cliente ...
Normalement c'est un des avantages à travailler avec des SGDBRs ...


DBRep - 2cts

Certains développeurs négligeants oublient de préciser le nom des colonnes lors des insert ou des select.

[diablolight]

Oui, pour mon cas il s'agit plutôt d'une application en fin de vie qui a subit pas mal d'évolutions en urgence (quelquefois par des développeurs peu expérimentés).
Pour finir, en lisant la documentation sur les définitions de la réplication, il me semble que chaque table répliquée doit obligatoirement avoir une clé primaire (paramètre "primary key" dans create replication definition) ?

[mpeppler]

Oui - mais cette PK est simplement une clé unique que le rep server utilise pour appliquer les modifs à la destination - il n'est donc pas nécessaire d'avoir une PK formelle.

Michael

[diablolight]

Je n'ai très bien compris le sens de la réponse, si c'est juste pour le repserver a-t-elle les mêmes fonctionnalités qu'une PK ?
Doit-elle être présente sur la source ou la destination ?

[mpeppler]

Le rep server prend les modifications pour une ligne dans une table, et les applique sur la destination via une commande d'update ou de delete. Cette commande devra comporter une clause WHERE qui défini quelle enregistrement est affecté. La PK sert à ceci sur la destination.

Un exemple permet peut-être d'être plus clair:

Admettons qu'on a une table source T1 comme ceci:

Code :

1
2
3
4
5
6
7
8
9
 
CREATE TABLE t1 (
pk   int,
col1 varchar(20),
col2 int,
... autres colonnes ...
)
CREATE UNIQUE INDEX i1 ON t1.pk
CREATE INDEX i2 ON t1.col2

où "pk" est une clé unique.
On a une repdef pour T1 comme ceci:

Code :

1
2
3
4
5
6
7
8
9
 
CREATE replication definition t1_repdef
...
( pk   int,
col1   varchar,
col2   int,
...
)
PRIMARY KEY ( pk )

Admettant qu'on applique un update sur cette table qui ne s'appuie pas sur la PK:

Code :

1
2
3
 
UPDATE t1 SET col1 = <valeur>
WHERE col2 = <autre_valeur>

Cet update peut affecter un nombre indéterminé d'enregistrement, puisqu'il n'y a pas de clé unique sur "col2". Pour chaque enregistrement mis à jour sur la source, repserver va générer un ordre d'update vers la destination, qui aura la forme suivante:

Code :

1
2
3
 
UPDATE t1 SET col1 = <valeur>
WHERE pk = <pk de l'enregistrement affecté>

Pour finir - ce que j'ai voulu dire par PK "formelle" c'est qu'il n'est pas nécessaire de définir des PK "declarative", du genre

Code :

1
2
 
ALTER TABLE ... ADD constraint ... PRIMARY KEY

puisqu'un index unique suffit.

Michael

[diablolight]

C'est très clair maintenant, merci Michael.