Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 15 sur 15
  1. #1
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut [RS]DDL Replication Server

    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.

  2. #2
    Rédacteur/Modérateur

    Inscrit en
    janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 54

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 307
    Points : 1 650
    Points
    1 650

    Par défaut

    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
    Michael Peppler
    Membre de TeamSybase - www.teamsybase.com

    "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson

  3. #3
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

    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 ?

  4. #4
    Rédacteur/Modérateur

    Inscrit en
    janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 54

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 307
    Points : 1 650
    Points
    1 650

    Par défaut

    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
    Michael Peppler
    Membre de TeamSybase - www.teamsybase.com

    "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson

  5. #5
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

    Merci, cela répond largement à mes questions.

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 33
    Points : 40
    Points
    40

    Par défaut

    Citation 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

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 33
    Points : 40
    Points
    40

    Par défaut

    Citation 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)



    Citation 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

  8. #8
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

    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.

  9. #9
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2007
    Messages : 33
    Points : 40
    Points
    40

    Par défaut

    Citation 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

  10. #10
    Membre actif
    Inscrit en
    août 2007
    Messages
    134
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 134
    Points : 153
    Points
    153

    Par défaut

    Citation Envoyé par DBRep Voir le message
    ?!?
    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.

  11. #11
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

    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) ?

  12. #12
    Rédacteur/Modérateur

    Inscrit en
    janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 54

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 307
    Points : 1 650
    Points
    1 650

    Par défaut

    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
    Michael Peppler
    Membre de TeamSybase - www.teamsybase.com

    "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson

  13. #13
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

    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 ?

  14. #14
    Rédacteur/Modérateur

    Inscrit en
    janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 54

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 307
    Points : 1 650
    Points
    1 650

    Par défaut

    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
    Michael Peppler
    Membre de TeamSybase - www.teamsybase.com

    "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson

  15. #15
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 22
    Points : 15
    Points
    15

    Par défaut

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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •