Triggering asynchrone avec service Broker

Bonjour,

J'ai hésité entre Développement et Réplication. Désolé si j'ai choisis le mauvais endroit.

"Mes" développeurs me demandent une solution pour copier certaines tables d'une base OLTP sur une base remote OLAP, ceci afin de créer un environnement d'archivage pour ces tables et de permettre de faire du reporting dessus.
Ce n'est donc pas une image de tables que l'on veut. Si tel avait été le cas, j'aurais alors choisis un système de réplication. Là, ils veulent récupérer toutes l'activité (insert, update et delete) de certaines tables d'une instance oltp sur une instance olap remote et garder sur ces tables remote olap les données lors de purge sur les table source oltp. La gestion de la purge pourra se faire avec un simple flag dans une table que va gérer l'opérateur des purges. Si le flag purge est à oui alors ne pas prendre en compte le delete sur les table remote olap.

Je pensais mettre en place du triggering. Pas le triggering de base car il risquerait de perturber les tables oltp en cas de problème mais le triggering asynchrone avec le service Broker.
J'ai fait un test avec une table et qq données et cela fonctionne très bien. J'ai trouvé sur le net une solution qui explique ce mécanisme.
https://blog.actorsfit.com/a?ID=0010...c-81950f4665ae
Le trigger insert, update ou delete enregistre toutes les informations au format xml dans la queue en local sur l'instance oltp. Un process associé à la queue se charge en asynchrone d'envoyer l'opération (insert, update ou delete) sur l'instance olap via un linked server. Ca marche bien et ça répond vite... mais j'ai très peu de données dans mon jeu d'essai.

On m'a dit que le service Broker fonctionne toujours avec la base msdb pour stocker les informations et ensuite les transmet à la base locale concernée. En cas de charge trop importante, il paraît qu'il peut y avoir des blocages à plusieurs niveaux (msdb / base locale) et que cela peut perturber l'instance SQL Server. Ce qui pourrait être gênant dans mon cas car c'est une instance oltp de prod.
De plus, on m'a dit que le débogage en cas de problème n'est pas évident sur service Broker.
Quel est votre avis, quelle est votre position sur cette solution ?
Vous me la conseillez ? Vous pensez plutôt à une autre solution, un autre mécanisme ?

Merci par avance pour votre aide sur le sujet

Cdlt,

Franck

Service Broker est dédié à ce genre de chose et il est asynchrone, transactionné et sérialisé. Aucun autre système n'offre une telle qualité et les plantages sont souvent encore plus complexes à déboguer car entre temps, les données ont évoluées mais ne sont généralement pas pris en compte (Kafka par exemple) et il s'agit de système distribué, et comme il y en a partout, il faut vérifier sue les intances,k les partages de fichiers, le système, les services applicatifs.... Non courage (pour information en matière de réplication, mon tarif à la journée pour du conseil ou du débogage est de 2000€ histoire de décourages les clients, mais, même à ce tarif, certains craquent après avoir tourné en rond des jours durant... !)

Je ne sais pas ou vous avez été cherché que Service Broker utilise msdb.... Mais cela n'est pas vrai. Le service SB est intégré à la (ou les) base(s) d'origine(s) et de destination(s) et c'est tout, mis à part le point d'écoute HTTP de SB qui est de niveau instance SQL (dans l'explorateur d'objet : Objets Serveur/Points de terminaison système / Service broker).

Le débogage est extrêmement simple, car vous savez toujours ou se trouve l'information. Elle est soit dans la base source, soit dans la base de destination et il suffit d'interroger les files d'attentes ou à défaut les tables système d'écoute pour trouver, et l'information coincée et la raison.

Après le risque de boucle infini n'est pas impossible, c'est pourquoi il faut rajouter une gestion des messages "poisons" qui dans tous les cas nécessiterons une intervention manuelle pour la résolution !
https://docs.microsoft.com/fr-fr/sql...l-server-ver16

Je viens de mettre en place la réplication des données de gestion des villages pour le Club Med (300 sites) avec Service broker et ait déjà eu l'occasion par le passé de travailler dessus pour des industries comme par exemple Pasteur Mérieux pour la fabrication des vaccins.

A +

Bonjour Frédéric,

Comme d'habitude, vos réponses sont précieuses pour moi car claires et agrémentées d'une expérience certaine.
Vos propos confirment ce que je pensais.
J'avais fait un jeu d'essai avec SB et tout semblait bien fonctionner et me paraissait assez sympa à utiliser. La documentation sur SB m'incitait à l'utiliser.
Une personne m'a dit que SB utilisait MSDB mais j'avoue que personnellement je n'avais rien vu de cela dans les articles ou livres sur le sujet. J'étais étonné et je suis content d'avoir votre confirmation sur ce point
Pour moi, effectivement, comme vous le dites, tout se passe dans les bases concernées et les files.
Je note le côté "messages poisons" qui peut générer une boucle.
Votre retour d'expérience sur les 2 exemples est important pour moi.

SB apportait à SQL Server une capacité asynchrone très intéressante. Le retour négatif que j'ai eu récemment par une personne me gênait car je n'avais jamais lu jusqu'à présent de problème avec SB.
Par contre, je n'avais pas d'expérience. C'est pour cela que je voulais avoir votre avis.
C'est fait et ça me rassure.

Un grand merci encore à vous. :)

Franck