Audit dans Oracle

Question

J'ai besoin d'aide pour auditer Oracle. Nous avons une base de données avec beaucoup de tables et nous voulons être en mesure d'auditer chaque changement apporté à n'importe quelle table dans n'importe quel champ. Donc, les choses que nous voulons avoir dans cette vérification sont:

• utilisateur qui a modifié
• temps du changement est survenu
• ancienne valeur et la nouvelle valeur

donc nous avons commencé à créer le déclencheur qui a été censé effectuer l'audit pour une table, mais a eu des problèmes ...

Comme je l'ai mentionné auparavant, nous avons tellement de tables et nous ne pouvons pas aller créer un déclencheur pour chaque table. L'idée est donc de créer un déclencheur maître qui peut se comporter dynamiquement pour n'importe quelle table qui déclenche le déclencheur. J'essayais de le faire mais pas de chance du tout ... il semble qu'Oracle limite l'environnement de déclenchement juste pour une table qui est déclarée par le code et pas dynamiquement comme nous voulons le faire.

Avez-vous une idée sur la façon de faire ceci ou d'autres conseils pour résoudre ce problème?

Answer 1

Vous n'avez pas besoin d'écrire vos propres déclencheurs.

Oracle est livré avec des services de pistes de vérification flexibles et à grains fins. Jetez un oeil à this document (9i) comme point de départ. (. Edit: Voici un lien pour 10g et 11g versions du même document)

Vous pouvez vérifier si bien qu'il peut être like drinking from the firehose - et qui peuvent nuire à la performance du serveur à un moment donné, ou pourrait vous laisser avec tant Beaucoup d'informations d'audit que vous ne serez pas en mesure d'extraire rapidement des informations significatives, et/ou vous pourriez finir par manger beaucoup d'espace disque. Prenez le temps de réfléchir à la quantité d'informations d'audit dont vous avez vraiment besoin, et combien de temps vous aurez besoin de le garder. Pour ce faire, vous devrez peut-être commencer par une configuration de base, puis l'adapter après avoir obtenu un échantillon du type de volume de données de piste d'audit que vous collectez actuellement.

Answer 2

Si vous avez une édition d'entreprise 10g, vous devriez consulter la page Fine-Grained Auditing d'Oracle. C'est certainement mieux que de rouler les vôtres.

Mais si vous avez une version moindre ou pour une raison quelconque FGA n'est pas à votre goût, voici comment le faire. L'élément clé est: créer une table d'audit distincte pour chaque table d'application. Je sais que ce n'est pas ce que vous voulez entendre, car il ne correspond pas à la structure de la table que vous avez décrit ci-dessus. Mais le stockage d'une rangée avec les anciens et nouvelles valeurs pour chaque colonne affectée par une mise à jour est une très mauvaise idée:

1. Il ne l'échelle (une mise à jour simple toucher dix colonnes fraie dix inserts)
2. Qu'en est-il quand vous insérez un enregistrement?
3. Il est une douleur complète pour assembler l'état d'un dossier à un moment donné

Ainsi, ont une table d'audit pour chaque table d'application, avec une structure identique. Cela signifie inclure CHANGED_TIMESTAMP et CHANGED_USER dans la table d'application, mais ce n'est pas une mauvaise chose.Enfin, et vous savez où cela mène, ayez un déclencheur sur chaque table qui insère un enregistrement entier avec seulement les valeurs: NEW dans la table d'audit. Le déclencheur devrait se déclencher sur INSERT et UPDATE. Cela donne l'historique complet, il est assez facile de différencier deux versions de l'enregistrement. Pour un DELETE, vous insérerez un enregistrement d'audit avec seulement la clé primaire remplie et toutes les autres colonnes vides.

Votre objection sera que vous avez trop de tables et trop de colonnes pour implémenter tous ces objets. Mais il est assez simple pour générer la table et déclencher des instructions DDL à partir du dictionnaire de données (user_tables, user_tab_columns).