Déclencheur sur fichier de log / log trigger

Version imprimable

28/07/2017, 17h01
Thaminox

Déclencheur sur fichier de log / log trigger

Bonjour,

J'aimerai mettre en place un système de surveillance de certaines tables SQL Server pour provoquer des traitements sur l'arrivée de nouvelles entrées ou des modifications.

La solution que l'on peut tout de suite envisager est de créer des triggers SQL... Mais ça ne me convient pas car c'est totalement intrusif pour la base de données.
De plus, au delà de l'utilisation des ressources que cela implique, La BDD étant dépendante des mises à jour et autres mécanismes d'administration de l'application qui l'utilise, les triggers pourraient être perdus...

Bref, j'aimerai donc me tourner vers l'autre solution qui est l'analyse des fichiers de logs de la BDD et donc une solution non intrusive.
J'ai effectué quelques recherches, mais sans parler de certaines solutions obscures et coûteuses d'éditeurs, je n'ai rien trouvé de concluant.
J'aimerai pouvoir soit utiliser un connecteur existant open source et fiable ou créer ma propre solution d'analyse de log (en java) si ça reste dans le domaine du possible (par rapport à la complexité).

Donc ma question à la communauté : Est-ce envisageable ? Si oui avez-vous des informations / technologies / guides vers lesquels je peux me tourner ?

Un grand merci par avance.

Thaminox
28/07/2017, 17h22
aieeeuuuuu

Bonjour,

il faudrait nous donner plus de de détail sur ce que vous voulez faire comme traitement et sur le contexte
Je ne comprend pas bien pourquoi un trigger ne convient pas par exemple.

en attendant, vous pouvez jeter un œil aux fonctionnalités comme CHANGE DATA CAPTURE ou CHANGE TRACKING
28/07/2017, 20h41
Invité

J'ai déjà mis en place des systèmes de surveillances par des jobs récurrentes qui envoyait des courriels.
Je ne sais pas si ça correspondrait vraiment à ton besoin.
Par expérience, le besoin initial est souvent que l'on a besoin d'être informé tout de suite, sans délai.
Mais quand tu discutes un peu plus en profondeur, le besoin se réduit souvent à un test par heure aux heures ouvrables, voir un par jour.

L'argumentaire que j'emploie :
* Est-ce que tu réagi tout de suite lorsque tu reçois cette alerte ?
* Est-ce que tu es prêt à recevoir 50 messages par heures ?
* Est-ce c'est si important que ton cellulaire doit sonné à 3 heures du matin toutes les 5 minutes ?

Généralement, ça refroidi un peu les ardeurs du demandeur qui va aussi recevoir les alertes !
31/07/2017, 15h41
Thaminox

Merci pour vos réponses.

7gyY9w1ZY6ySRgPeaefZ> Mon besoin n'est pas un caprice d'un utilisateur mais répond réellement à une exigence métier. L'idée est de créer un traitement automatique au fil de l'eau de la récupération des nouvelles données dans une table pour les répliquer dans une autre application.
Créer des tâches récurrentes à fréquence élevée pourrait répondre au besoin si cela n'apportait pas les problèmes cités dans mon premier message, c'est à dire l'utilisation d'une session SQL qui interroge très régulièrement certaines tables utilisant ainsi une partie des ressources de la BDD.

aieeeuuuuu> Je veux récupérer seulement la nouvelle information (pas besoin de CDC ou de Change traking qui vont s'intéressé plus à la traçabilité/historisation des données).

Je reprécise mon besoin en essayant d'être un peu plus clair :
Je souhaite détecter une modification / insertion dans une table pour prendre ces nouvelles valeurs (et enclencher des traitements d'intégration dans une autre application).
Je ne souhaite pas passer par des triggers car c'est intrusif pour la BDD d'une application.
J'avais entendu parler d'une solution à partir de l'analyse de log de BDD, est-ce viable ? Et comment mettre cela en place?
01/08/2017, 13h10
julien94320

La destination est elle SQL Server ?

Si oui pourquoi ne pas répliquer simplement la base de données sur la destination ?

La solution de log est le log Shipping, maintenant il existe plusieurs nouvelles solutions comme la réplication voir always on

Peut être qu'avec un peut d'aide :

https://docs.microsoft.com/en-us/sql...ups-sql-server
https://docs.microsoft.com/fr-fr/sql...of-replication
02/08/2017, 10h07
aieeeuuuuu

Citation:

Envoyé par Thaminox

aieeeuuuuu> Je veux récupérer seulement la nouvelle information (pas besoin de CDC ou de Change traking qui vont s'intéressé plus à la traçabilité/historisation des données).

Je reprécise mon besoin en essayant d'être un peu plus clair :
Je souhaite détecter une modification / insertion dans une table pour prendre ces nouvelles valeurs (et enclencher des traitements d'intégration dans une autre application).
Je ne souhaite pas passer par des triggers car c'est intrusif pour la BDD d'une application.
J'avais entendu parler d'une solution à partir de l'analyse de log de BDD, est-ce viable ? Et comment mettre cela en place?

CHANGE DATA CAPTURE semble pourtant tout indiqué. C'est d'ailleurs ce qu'il fait sous le capot : relecture du journal des transactions pour en "déduire" les modifications effectuées.
Il est configurable afin de ne suivre que les informations qui vous intéressent.
En plus il est asynchrone, et ne devrait donc pas perturber l'existant.
Il a toutefois quelques contraintes, mais je pense qu'il peut parfaitement convenir pour votre besoin.
03/08/2017, 15h52
julien94320

Le CDC peut convenir parfaitement effectivement après une réplication de fusion peut être une solution approprié aussi ...

Regardez les solutions évoqués et faite nous votre retour ;)
04/08/2017, 11h56
Thaminox

julien94320 > La destination est une application et non une base de données donc la réplication ne convient hélas pas à mon besoin. :?

aieeeuuuuu > Je n'ai jamais utilisé le système de CHANGE DATA CAPTURE, mais pour ce que j'ai lu au niveau de la doc en ligne SQL Server (cf : https://docs.microsoft.com/fr-fr/sql...ure-sql-server), même si effectivement le système fonctionne avec le journal, il utilise de nombreuses procédures stockées et de nouvelles tables de traçabilité générées sur la base de données, ce qui me semble assez intrusif.
A moins que je n'ai pas compris son fonctionnement...? :(

Si je veux surveiller les insertions/modifications de ma table A de ma BBD de mon ERP et envoyer les nouvelles données détectées à un web service par exemple.
J'ai mon programme java qui s'occupe de faire l'appel du web service mais comment dois-je configurer le CDC de ma BDD pour pouvoir faire communiquer le CDC avec mon programme java ? Est-ce forcément à mon programme java d'appeler périodiquement via les procédures stockées pour détecter les modifs?
Est-ce la bonne/seule méthode de mise en place ?

Merci une nouvelle fois pour vos réponses.
04/08/2017, 15h06
Invité

Citation:

Envoyé par Thaminox

aieeeuuuuu > Je n'ai jamais utilisé le système de CHANGE DATA CAPTURE, mais pour ce que j'ai lu au niveau de la doc en ligne SQL Server (cf : https://docs.microsoft.com/fr-fr/sql...ure-sql-server), même si effectivement le système fonctionne avec le journal, il utilise de nombreuses procédures stockées et de nouvelles tables de traçabilité générées sur la base de données, ce qui me semble assez intrusif.

Même si tu fais un truc maison, tu seras bien obligé d'avoir ce genre de nouveaux objets :mouarf: Et pas sûr que tu fasses mieux en plus. (Réinventer la roue, toussa...)