ProgrammationDéveloppeur de bases de données

Comment réaliser et utiliser correctement les tables de journalisation (log tables) pour l'audit des modifications dans les bases de données SQL en production ? Quels pièges existent et comment minimiser leur impact sur les performances ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Les tables de journalisation des modifications (log/audit tables) sont des tables classiques dans lesquelles sont enregistrés les événements de modification des données dans les tables de production : qui, quand et quoi a été modifié. Cela est pertinent pour le secteur financier, le e-commerce, les organismes gouvernementaux.

Approches de mise en œuvre :

  1. Enregistrement explicite dans le journal via l'application ou une procédure.
  2. Utilisation de déclencheurs (triggers) pour suivre toute modification.
  3. Dans les nouvelles SGBD — mécanismes systèmes Change Data Capture (CDC) ou Temporal Tables.

Composition typique :

  • audit_id (PK), TableName, OperationType (I/U/D), RecordID, OldValue, NewValue, ChangedBy, ChangeDT

Exemple de code (déclencheur pour l'audit UPDATE)

CREATE TABLE ProductAudit ( AuditID int IDENTITY(1,1) PRIMARY KEY, ProductID int, OldPrice money, NewPrice money, ChangedBy sysname, ChangeDT datetime, OperationType char(1) ); GO CREATE TRIGGER trg_ProductAudit ON Products AFTER UPDATE AS BEGIN INSERT INTO ProductAudit(ProductID, OldPrice, NewPrice, ChangedBy, ChangeDT, OperationType) SELECT d.ProductID, d.Price, i.Price, SYSTEM_USER, GETDATE(), 'U' FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID WHERE i.Price <> d.Price; END

Pièges :

  • Un grand volume de la table d'audit peut ralentir la sélection.
  • Nécessité d'un partitionnement approprié/suppression des anciennes données.
  • Il faut surveiller les verrous et la dé-duplication des modifications.

Question piège.

Q : L'enregistrement inséré dans la table de log est-il automatiquement annulé lors du rollback de la transaction principale ?

R : Si le déclencheur est partie de la transaction, alors oui, l'insertion dans le journal est annulée avec l'opération principale. Cependant, lors de la journalisation au niveau de l'application ou avec une transaction distincte, la cohérence peut ne pas être présente.

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet.


Histoire

Dans un établissement de crédit, le mécanisme de nettoyage de la table d'audit n'a pas été mis en place. Le volume a dépassé plusieurs centaines de millions de lignes, ce qui a entraîné de longues sauvegardes, un manque d'espace et une dégradation des performances de la base de données entière.


Histoire

Un développeur a fait l'audit via une connexion distincte en dehors de la transaction. En conséquence, des enregistrements sur des événements inexistant apparaissaient (la transaction de la logique applicative était annulée, mais l'enregistrement dans le log ne l'était pas).


Histoire

Lors de la conception du journal des modifications, tous les champs ont été définis avec le type NVARCHAR(MAX) pour plus de polyvalence. Cela n'était pas nécessaire, mais a alourdi le stockage et l'indexation — les données n'étaient pas analysables efficacement.