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:

---

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 ?

Citation:

---

Envoyé par epsilon68

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 ?

++

j'ai trouvé mon problème, en fait je faisais

Code:

---

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... :aie:

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 ?

Citation:

---

Envoyé par escartefigue

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.

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

A +

Bonjour

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

Citation:

---

Envoyé par SQLpro

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)

Citation:

---

Envoyé par aieeeuuuuu

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.

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 !