Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

triggers crée un lock


Sujet :

Développement SQL Server

  1. #1
    Membre éprouvé
    triggers crée un lock
    Bonjour,

    j'en perds mon latin. J'essaie d'implémenter une table d'audit. J'ai:

    table audit_log

    Table A et table B

    A et B ont un trigger qui en cas d'insert ou delete, font un insert dans audit_log, du genre

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    insert into audit_log (x, y, z) select x, y, z from inserted where macolonne is not null;


    je découvre que le select x,y,z from inserted (ou deleted) crée un lock et donc je ne peux pas insérer dans A dans une transaction 1 et insérer dans B dans une transaction 2 en même temps, il faut que la transaction 1 soit commitée pour que la 2 puisse finir.

    Pour info, la db n'est pas en RCSI.

    help ! je ne comprends pas ce qui se passe. si j'enlève le select from inserted et le remplace par un "values (x,y,z)" je n'ai pas ce problème ... (sauf que je ne peux pas ...)

    avez vous une idée ?

  2. #2
    Expert éminent sénior
    Citation Envoyé par epsilon68 Voir le message
    Bonjour,
    je decouvre que le select x,y,z from inserted (ou deleted) crée un lock et donc je ne peux pas inserer dans A dans une transaction 1 et inserer dans B dans une transaction 2 en meme temps, il faut que la transaction 1 soit commitée pour que la 2 puisse finir.
    avez vous une idée ?
    Vu de loin, je ne vois pas le problème. Tes insertions provenant de 2 transactions distinctes dans la table d'audit seront sérialisés comme attendu. Si tes transactions sont courtes et sélectives le verrou ne devrait pas plus déranger que cela.

    Est-ce le cas ?

    ++

  3. #3
    Membre éprouvé
    j'ai trouvé mon problème, en fait je faisais

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    with mes_ids (select id from matable order by id fetch next 10 rows only)
    delete from matable where id in (Select id from mes_ids)


    le select dans le with, faisait en fait le lock...

    ca m'a quand même fait perdre quelques heures cette histoire...

  4. #4
    Expert éminent sénior
    Donc le but de ce trigger est de supprimer physiquement les lignes dont la valeur d'identifiant fait partie des 10 plus petites valeurs, ce qui ne veut pas forcément dire qu'il s'agit des plus anciens.
    Etrange de faire des DELETE sans critère fonctionnel... quel est le contexte ?

  5. #5
    Membre éprouvé
    Citation Envoyé par escartefigue Voir le message
    Donc le but de ce trigger est de supprimer physiquement les lignes dont la valeur d'identifiant fait partie des 10 plus petites valeurs, ce qui ne veut pas forcément dire qu'il s'agit des plus anciens.
    Etrange de faire des DELETE sans critère fonctionnel... quel est le contexte ?
    non, le but du trigger est de logger les valeurs lors de l'insert, update et delete. C'est un trigger pour auditer les données.
    Le "delete from" que je faisais était pour tester le trigger, et je voulais effacer seulement n lignes... mais je me suis tiré dans le pied.

  6. #6
    Rédacteur

    Ce n'est pas avec un déclencheur que l'on audite. C'est avec le DATABASE AUDIT !

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  7. #7
    Modérateur

    Bonjour

    Pour information, vous pourriez probablement faire plus simple en mettant en place le CHANGE TRACKING

  8. #8
    Membre éprouvé
    Citation Envoyé par SQLpro Voir le message
    Ce n'est pas avec un déclencheur que l'on audite. C'est avec le DATABASE AUDIT !

    A +
    je ne savais pas que les données étaient trackées, vous devriez mettre à jour votre article où vous donnez un moyen d'auditer les données avec des triggers et de l'xml (d'ailleurs beaucoup trop lente en recherche)

  9. #9
    Membre éprouvé
    Citation Envoyé par aieeeuuuuu Voir le message
    Bonjour

    Pour information, vous pourriez probablement faire plus simple en mettant en place le CHANGE TRACKING
    perso, je ne suis pas DBA et la mise en oeuvre me parait compliqué, sans compter la facon de restituer.
    D'autre part, j'ai compris que l'ensemble du record est loggé quand un des champs est changé, ce qui est impossible quand beaucoup de records sont mis à jour très fréquemment.

    Si vous avez un article plus détaillé ou une expérience réelle vécue, je suis quand même preneur.

  10. #10
    Modérateur

    en soit, la mise en œuvre n'est pas compliquée, il suffit d'activer la fonctionnalité, et de spécifier les tables à suivre.
    il faudra aussi effectuer quelques réglages en fonction de vos besoins (durée de rétention, ...).

    quand à la restitution... ça reste du SQL, et il y a en plus des fonctions intégrées pour vous y aider...

    En revanche, notez que c'est un processus asynchrone (relecture du journal des transactions), donc pas de verrou !

###raw>template_hook.ano_emploi###