Discussion :

[VinceSSJ]

Bonjour,

Je vous explique le problème en résumant :

Un trigger est posé sur une table.
A chaque action (update/delete/insert) sur une ligne de cette table, le trigger se déclenche et appelle une assembly préalablement déployée dans ma base (assembly codée en C# et déployée via VS2010) qui va aller alimenter une autre table (audit).

Jusque là tout va bien, sauf qu'en amont de ma base, j'ai un site web développé en ASP.NET et que beaucoup de monde utilisent.

Le problème donc, c'est que l'assembly met environ 30secondes à se lancer.

Je vous laisse donc imaginer le matin (ou lorsque le site n'a pas été utilisé depuis un moment) quand on se connecte sur le site : à la première action le site mouline pendant 30secondes le temps que l'assembly en base soit compilée et que le processus créé se lance. Là où ça devient critique c'est que parfois les actions se croisent sur le site et qu'un select est effectué sur la table en question alors que l'assembly n'a pas fini d'être compilée = plantage.
Ensuite une fois que l'audit est lancé, plus de problèmes jusqu'à ce que le processus du .exe (je suppose) résultant de la compilation de l'assembly soit arrêté par l'instance SQL Server..

Bref, j'ai beaucoup résumé, et désolé si je ne me suis pas bien fait comprendre, mais mes question sont :
- Comment rendre persistante la "compilation" d'une assembly sur SQL Server pour qu'il n'y ait plus à la recompiler ensuite ?
- Est ce que ça se paramètre quelque part ?
- Par défaut, de combien de temps le processus venant d'une assembly compilée reste actif ?

Merci d'avance !

[SQLpro]

les assemblies sont mis en cache avec le même algo LRU que toutes les données. Ce qui fait que si elle n'a pas été utilisée depuis longtemps, elle va dégager suite à pression mémoire.

Deux solutions :

• augmenter la RAM pour diminuer la pression mémoire
• faire de l'assembly "warm up" en lançant régulièrement cette assembly avec un paramètre bidon (via une planif de l'agent SQL

Petite question : que fait cette assembly dans le détail, car il existe de nombreux outils d'audit intégrés à MS SQL Server....

A +

[VinceSSJ]

Merci pour votre réponse.

Notre architecture est assez spécifique puisqu'elle basée sur des données cliniques donc sensibles. Tout doit être tracé. En gros à chaque action sur une table importante, on va alimenter une autre table d'audit unique à notre base en indiquant le type de l'action, nouvelle valeur, ancienne valeur, utilisateur connecté au site, description de la donnée, sa valeur, + d'autres colonnes bien spécifiques à notre architecture.

En gros pas de solution viable alors ?
Car si je comprends bien faire du "warm up" revient à lancer inutilement l'audit ce qui, du coup, va insérer des lignes "bidon" dans sa table (et on se peut pas trop se le permettre vu que la table atteint les centaines de milliers de lignes facilement), ou bien si on s'arrange, utiliser une table bidon avec des données bidon à laquelle on aurait posé un trigger bidon qui aurait juste à mettre en route l'assembly.. Mais là pareil on s'alourdit de données inutiles

On avait pensé aussi à retranscrire ce que fait notre assembly C# directement en proc stockée SQL (=performances accrues puisque pas besoin de recompiler)... ce qui s'avère vraiment compliqué !

[SQLpro]

Merci pour votre réponse.

Notre architecture est assez spécifique puisqu'elle basée sur des données cliniques donc sensibles. En gros à chaque action sur une table importante, on va alimenter une autre table d'audit unique à notre base en indiquant le type de l'action, nouvelle valeur, ancienne valeur, utilisateur connecté au site, description de la donnée, sa valeur, + d'autres colonnes bien spécifiques à notre architecture.

la fonctionnalité DATABASE AUDIT intégrée à SQL Server devrait suffir pour une bonne partie et est plus fiable et plus sécurisée que le code que vous avez sans doute écrit...

En gros pas de solution viable alors ?

via des déclencheurs classique il est possible de faire aussi cela et les customiser. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p8...on_des_donnees
On peut compléter cela avec des déclencheurs DDL qui créée les déclencheurs DML automatiquement à chaque fois qu'une table est ajoutée ou modifiée (ALTER)... J'avais fait cela dans le cadre d'un ERP pour l'hospitalisation....

Car si je comprends bien faire du "warm up" revient à lancer inutilement l'audit ce qui, du coup, va insérer des lignes "bidon" dans sa table (et on se peut pas trop se le permettre vu que la table atteint les centaines de milliers de lignes facilement), ou bien si on s'arrange, utiliser une table bidon avec des données bidon à laquelle on aurait posé un trigger bidon qui aurait juste à mettre en route l'assembly.. Mais là pareil on s'alourdit de données inutiles

Non, il suffit que vous ayez dans votre .exe un paramètre test qui, s'il est à 1, n'écrit rien du tout, mais déclenche l'assembly. Cela peut être une solution provisoire !

On avait pensé aussi à retranscrire ce que fait notre assembly C# directement en proc stockée SQL (=performances accrues puisque pas besoin de recompiler)... ce qui s'avère vraiment compliqué !

Ce serait mieux....

Inspirez vous de ce que j'avais fait pour cet ERP de santé !

NOTA : DATABASE AUDIT est aussi le seul moyen de tracer de la lecture de table, ce qui était indispensable dans notre cas de figure....

A +

[aieeeuuuuu]

Bonjour,

Bonjour,

Je vous explique le problème en résumant :

Un trigger est posé sur une table.
A chaque action (update/delete/insert) sur une ligne de cette table,
[...] qui va aller alimenter une autre table (audit).

Vous n'avez pas beaucoup détaillé le besoin, mais Change data capture pourrait aussi être une solution a envisager. Elle a l'avantage d'être asynchrone (lecture régulière du journal des transactions pour tracer les modifications...)