Discussion :

[pulls]

Bonjour,

J'ai 5 bases de données distribuées dans 5 régions distantes A,B,C,D,E. je voudrais que les données de chaque base soient mises à jour dans une base de données centrale en temps réel. je ne sais pas quelle technologie utilisée, je sais pas si la réplication des données peut m'aider à régler ce problème.

Mes bases de données sont sur SQLSERVER 2008

Aidez moi s'il vous plait.

[SQLpro]

Oui la réplication transactionnelle répondrait sans doute à votre besoin.

A +

[pulls]

Merci SQL PRO,

Vous venez de me mettre sur une piste. Je vais faire des recherches sur les réplications transactionnelles. Je serai heureux si vous pouvez me définir quelques procédures de mise en œuvre. Merci

[pulls]

S'il vous plait SQL PRO, je voudrais que vous sachez que chaque base de données régionale ( distribuée) est un sous ensemble de la base de données centrale. vous me confirmez bien que la réplication transactionnelle va faire la mise à jour de la base de données centrale pour chaque insertion ou modification des bases de données distribuées ( régionales).
Si oui je vous prie de me définir quelques procédures de mise en œuvre. Merci

[SQLpro]

Oui tout à fait. C'est l'idéal pour consolider des données sur un serveur central en provenance de plusieurs sites distants.

Pour un résumé de la chose, le site de Microsoft est LE point de départ :
https://docs.microsoft.com/fr-fr/sql...ql-server-2017

Il existe toute une série d'assistants dans SSMS pour la mise en œuvre de ce type de réplication.

A +

[pulls]

S'il vous plait est ce qu'on peut bien implémenter une réplication stable avec la version sqlserver 2008 standard? Nous nous proposons de migrer vers sqlserver 2016 standard, mais le projet est encore à l'étude par l'administration, avec toutes les contraintes budgétaires qu'on peut imaginer. Merci de nous dire si la version actuelle peut tenir.

[Waldar]

Pas de soucis, la réplication SQL-Server est quelque chose qui fonctionne très bien (depuis au moins la version 2008) et qui en plus n'est pas si complexe à mettre en œuvre.
Utilisez l'interface graphique, mais enregistrez bien les scripts SQL générés par l'assistant, pour tracer, comprendre voire automatiser.

[SQLpro]

ho que oui !!!! Il faut absolument tracer tous les scripts SQL pissés par l'assistant sinon, en cas de problème, vous ne vous y retrouverez pas !

A +

[pulls]

S'il vous plait. est-ce que la table source( bd distribuée) et la table cible (bd centrale) doivent avoir forcement la même structure? peut être la question est bête. Merci

[SQLpro]

oui

A +

[pulls]

Merci

[Michel.Priori]

je voudrais que les données de chaque base soient mises à jour dans une base de données centrale en temps réel.

La réplication va entrainer un temps de latence. Faible mais existant.

est-ce que la table source( bd distribuée) et la table cible (bd centrale) doivent avoir forcement la même structure?

C'est préférable.
Bien penser à ce que :
1- les tables sources ont bien une colonne du type "source_Id" correspondant aux régions distantes (A,B,C,D,E)
2-que les clés soient uniques entre les différentes régions. La fonction NEWSEQUENTIALID() a été créée pour
ou que
Chaque réplication pointe vers ses propres tables. Par exemple en les séparant par un schéma différent et en créant un schéma supplémentaire pour créer les vues UNION pour voir les données de l'ensemble des différentes sources.

Bien tester les scénario de RESTORE pour chaque base et par rapport à la logique de cohérence globale.

[SQLpro]

La réplication va entrainer un temps de latence. Faible mais existant.



C'est préférable.
Bien penser à ce que :
1- les tables sources ont bien une colonne du type "source_Id" correspondant aux régions distantes (A,B,C,D,E)

Pas forcément on peut utiliser l'Identity avec un modulo

2-que les clés soient uniques entre les différentes régions. La fonction NEWSEQUENTIALID() a été créée pour

Non, pas de clef de type UNIQUEIDENTIFIER, c'est une plaie

A +

[Michel.Priori]

Pas forcément on peut utiliser l'Identity avec un modulo

Pour en avoir fait l'amère expérience, , c'est pas top :
* problème avec reseed
* problème avec SET IDENTITY_INSERT ON
* problème avec les scripts (douteux) de recréation de la table

Si c'est la solution retenue, il faut penser à doubler le coup avec une contrainte CHECK

Perso je trouve que c'est alambiqué et, les années aidant, difficile à maintenir (ajout de site = reprise du code)

[Michel.Priori]

Non, pas de clef de type UNIQUEIDENTIFIER, c'est une plaie

C'est pourtant LA solution officielle en cas de réplication de fusion.

A noter que :
* la fonction NEWSEQUENTIALID() apporte une solution à la fragmentation des données
* il n'est pas impératif que la clé soit l'index cluster

[SQLpro]

C'est pourtant LA solution officielle en cas de réplication de fusion.

A noter que :
* la fonction NEWSEQUENTIALID() apporte une solution à la fragmentation des données
* il n'est pas impératif que la clé soit l'index cluster

Non, pas du tout. La PK est une chose, le tag de type UNIQUEIDENTIFIER en est une autre. Il sert à indiquer quelle est la source des données. En matière de PK un GUID c'est trop long et cela provoque des pertes de performances et des "hot spot" même avec du SEQUENTIAL.

A +

[pulls]

Bonjour, j'ai implémenté une réplication transactionnelle avec MMS comme vous m'avez conseillé. j'ai commencé par la région A et ça marche très bien: le serveur A est le serveur de distribution et le serveur central l'abonné, le tout implémenté sur le serveur A.
Ensuite je suis passé à la région B avec la même logique d'implémentation. Mais hélas, qu'est ce que je constate ? pendant la replication des données de région B , les donnée de la région A de la meme table sont effacées dans la base de données centrale et vice versa.
s'il vous plaît comment faire de sorte que la réplication des données d'une région n'efface pas les données des autres régions dans la base centrale.
aidez moi s'il vous plaît.

[Michel.Priori]

En matière de PK un GUID c'est trop long et cela provoque des pertes de performances

Oui, on est bien d'accord que ce n'est pas le top ; MAIS c'est la seule solution dans ce cas d'usage (réplication de fusion).

Je m'explique :
Une PK permet d'identifier une ligne de manière unique.
Le type GUID permet de stocker le résultat de la fonction NEWSEQUENTIALID().
Or la fonction NEWSEQUENTIALID() devrait fournir un numéro unique peut importe le temps, peu importe la machine source.

Utiliser une clé composite (identity & Numero de machine) n'est ni performant ni pratique.
Créer une colonne calculée pour, ensuite en faire la PK n'est pas recommandé non plus (et c'est pas simple à mettre en oeuvre et une fois définie c'est immuable, la redéfinition de la formule de calcul impose la création d'une nouvelle colonne et un jeu de pousse-pousse pour remplacer l'ancienne)

De plus la réplication de fusion IMPOSE une colonne GUID.
Autant faire d'une pierre 2 coups.

Pour ce qui est du choix de l'index cluster :
Il est habituel de ne pas se poser la question et de prendre la PK comme cluster.
Ici vu la taille du type, la question du choix se pose.

Il est vrai que pas mal de jointures font se faire selon les FK qui pointent généralement les PK.
Du coup on a un rapprochement de GUID à faire.
C'est largement moins performant que sur un INT. On est d'accord.
C'est à contre balancer par son contournement qui consiste à avoir une colonne GUID imposée par la réplication de fusion auquel on ajoute une mécanique de PK plus 'soft'.

De ce qu'il m'a été donné à voir, faire une PK de type GUID est le moins pire.

[SQLpro]

Bonjour, j'ai implémenté une réplication transactionnelle avec MMS comme vous m'avez conseillé. j'ai commencé par la région A et ça marche très bien: le serveur A est le serveur de distribution et le serveur central l'abonné, le tout implémenté sur le serveur A.
Ensuite je suis passé à la région B avec la même logique d'implémentation. Mais hélas, qu'est ce que je constate ? pendant la replication des données de région B , les donnée de la région A de la meme table sont effacées dans la base de données centrale et vice versa.
s'il vous plaît comment faire de sorte que la réplication des données d'une région n'efface pas les données des autres régions dans la base centrale.
aidez moi s'il vous plaît.

À mon avis vous n'avez pas implémenté la solution de réplication transactionnelle (mais fait du snapshot par exemple) ou bien mal implémentée (transactionnelle PEER to PEER à mettre en œuvre).
Il faudrait connaître la structure de vos tables répliquées et décrire ce que vous voulez faire avec un exemple concret.

A +

[SQLpro]

Oui, on est bien d'accord que ce n'est pas le top ; MAIS c'est la seule solution dans ce cas d'usage (réplication de fusion).

Je m'explique :
Une PK permet d'identifier une ligne de manière unique.
Le type GUID permet de stocker le résultat de la fonction NEWSEQUENTIALID().
Or la fonction NEWSEQUENTIALID() devrait fournir un numéro unique peut importe le temps, peu importe la machine source.

Oui, on est d'accord...

Utiliser une clé composite (identity & Numero de machine) n'est ni performant ni pratique.

Oui, on est toujours d'accord...

Créer une colonne calculée pour, ensuite en faire la PK n'est pas recommandé non plus (et c'est pas simple à mettre en oeuvre et une fois définie c'est immuable, la redéfinition de la formule de calcul impose la création d'une nouvelle colonne et un jeu de pousse-pousse pour remplacer l'ancienne)

Oui, on est encore d'accord...

De plus la réplication de fusion IMPOSE une colonne GUID.

Elle n'impose pas, mais MS dans sa réplication de fusion la créée pour les besoins de réplication et non comme éléments sémantique ni PK !

Autant faire d'une pierre 2 coups.

Non, ça c'est stupide, car les PK en GUID sont TOUJOURS contre performantes ! Et en pratique il est dangereux de mélanger différents principes de gestion en un seul (PK + identifiant de réplication) !

Pour ce qui est du choix de l'index cluster :
Il est habituel de ne pas se poser la question et de prendre la PK comme cluster.
Ici vu la taille du type, la question du choix se pose.

Il est vrai que pas mal de jointures font se faire selon les FK qui pointent généralement les PK.
Du coup on a un rapprochement de GUID à faire.
C'est largement moins performant que sur un INT. On est d'accord.
C'est à contre balancer par son contournement qui consiste à avoir une colonne GUID imposée par la réplication de fusion auquel on ajoute une mécanique de PK plus 'soft'.

De ce qu'il m'a été donné à voir, faire une PK de type GUID est le moins pire.

Il y a beaucoup plus simple : distribuer les clefs auto incrémentées.... Le principe est le suivant : sur chaque serveur la clef autoincrémentée commence à une valeur différentes avec un pas calculé sur le nombre potentiel de machine en réplication.
par exemple si vous pensez n'avoir jamais plus de 100 machines, alors la machine 1 commence à 1 avec un pas de 100 (IDENTITY(1, 100)...), la machine 2, commence à 2 avec un pas de 100...
Il y a ainsi un quadruple avantage :
1) on reste avec des PK IDENTITY qui sont plus performantes
2) on ne mélange pas l'utilisation d'une clef primaire avec un tag de réplication
3) aucun problème d'index cluster
4) en calculant le modulo 100 sur la clef, on sait de quelle machine vient l'information

C'est ce que nous avons fait sur de nombreux sites web commerçant comme FNAC.com... À l'époque (1998) ou j'étais chef de projet dans une SSCI qui a monté les principaux site web marchand performants (SQL Server : ASP).

A +