Discussion :

[ariesnojf]

Bonjour à tous,

On a actuellement une DB, mise en production depuis peu, et comportant une cinquantaine de tables pour lesquelles systématiquement, le développeur a mis en place un audit trail de toutes les transactions sur ces tables via triggers, et qui alimente deux tables (dans cette même db). La plus grosse table ayant environ 9 millions d'enregistrements au bout d'une semaine.
Le fichier physique de données pèse 4 Go, et le fichier de transaction peut monter jusqu'à 15 Go. La sauvegarde transactionnelle peut peser autant, et cette sauvegarde à lieu toutes les heures ...

Question :
Est ce gênant qu'un fichier de transaction puisse peser 3 fois plus que le fichier de données ? (j'ai cru comprendre que la règle est 30%
du fichier de données)
J'imagine que si le fichier augmente, cela est dû aux triggers de chaque table, y-a-t-il une option pour que le ficher de transaction n'enregistre pas les transactions liés aux triggers ? (heu, est-ce une bonne idée ? )
Peut-on ou doit-on ajouter un autre fichier de transaction ou dois je laisser comme cela ?

D'une façon plus générale, je ne sais pas s'il faut laisser cela tel quel, ou faut-il faire quelque chose ?

Pourriez vous m'éclairer,

Merci d'avance.

[bvesan]

Bonjour,

si votre base est en mode de recouvrement Complet, toutes les transactions seront nécessairement conservées dans le fichier de journaux transactionnels jusqu'à ce qu'une sauvegarde des journaux soit lancée.
Si par contre elle est en mode de recouvrement Simple, elles seront recyclées très rapidement. Votre fichier de journaux de transactionnels n'atteindra donc a priori jamais une telle volumétrie.
A ma connaissance, il n'est pas possible avec SQL Server de désactiver la gestion transactionnelle pour un objet en particulier.

Donc avec le mécanisme actuel, à moins de passer votre base en mode de recouvrement Simple, vous êtes condamné à lancer le plus souvent possible des sauvegardes du journal de transactions. A noter qu'à partir de la version 2008R2, vous avez la possibilité de compresser les sauvegardes de bases et de transactions, pour un gain de place souvent significatif.

Il n'y a rien de gênant à ce qu'un journal de transaction soit plus volumineux que la partie données d'une base. Lorsque l'on évoque le ration 1/3, c'est principalement par constat. Vous avez la possibilité d'ajouter un ou plusieurs fichiers à journal de transactions si besoin.

L'audit est-il mis en place à partir du mécanisme Change Tracking ?
Si votre développeur est prêt à faire évoluer son modèle, il peut être intéressant de jeter un coup d'oeil à Change Data Capture, plus souple, moins intrusif, et moins consommateur sur la partie journal de transaction.


Cordialement.

[Invité]

Est ce gênant qu'un fichier de transaction puisse peser 3 fois plus que le fichier de données ? (j'ai cru comprendre que la règle est 30% du fichier de données)

Je ne sais pas d'où sort cette « règle » des 30 % mais c'est totalement idiot dans le monde réel.
Ce rapport dépend de l'activité de la base de données : j'ai une bd qui fait beaucoup de transactions à courte durée. Résultat : j'ai un fichier de log qui fait trois fois celui du fichier de data.
À l'inverse, j'ai des bds peu actives avec un fichier de log de 5 Mo pour un datafile de 15 Go.
Je ne me pose pas vraiment la question de savoir si ça rentre dans une norme ou pas, c'est le fonctionnement de la bd qui va dicter le rapport fichier log / fichier data POINT !

Autre question, pourquoi un audit de toutes les tables sur votre bd de prod ?
Vous n'avez aucune confiance dans votre application ?
Je comprends l'intérêt potentiel en DEV mais en PROD, ça me semble beaucoup plus discutable.

[SQLpro]

Bonjour à tous,

On a actuellement une DB, mise en production depuis peu, et comportant une cinquantaine de tables pour lesquelles systématiquement, le développeur a mis en place un audit trail de toutes les transactions sur ces tables via triggers, ...

Pourquoi faire, mal ce qui est fait bien en standard ?
SQL Server dispose de différents moyens d'audit nettement moins gourmands :
1) Database Audit pour la sécurité (version Enterprise)
2) Change Tracking (version Standard) pour le changement
3) Change Data Capture (version Enterprise) pour le changement

A +

[ariesnojf]

Bonjour à tous,

Merci de prendre du temps à mon sujet.

Autre question, pourquoi un audit de toutes les tables sur votre bd de prod ?
Vous n'avez aucune confiance dans votre application ?

C'est une application dans le milieu médical et dont les données sont sensibles, et toutes données doivent être auditées, à savoir qui fait quoi et quand. Le fait d'avoir confiance sur l'application ou pas dépend du développeur, moi mon soucis est plutôt sur les performances et tailles que cette base peut générer, pour ne pas perturber les autres DB du serveur.

Pourquoi faire, mal ce qui est fait bien en standard ?
SQL Server dispose de différents moyens d'audit nettement moins gourmands :
1) Database Audit pour la sécurité (version Enterprise)
2) Change Tracking (version Standard) pour le changement
3) Change Data Capture (version Enterprise) pour le changement

A +

Comme mentionné par bvesan & SQLpro, je vais proposer différents moyens d'audit SQL (j'avoue n'avoir pas penser à cela ...).

Merci à vous.

[SQLpro]

Et si vous en voulez plus, il y a aussi :
l'audit C2 (voir sp_configure)
SOX via : http://www.microsoft.com/downloads/d...displaylang=en

A +