Discussion :

[Le-DOC]

Bonjour,
Je continue mon exploration dans le monde merveilleux, mais complexe d'oracle.
Apres avoir plus ou moins comprit RMAN, et le Grid Control, je m'attaque désormais a la fonction d'audit.

J'ai plusieurs questions a vous poser.

Est t'il possible d'auditer un utilisateur dans devoir redémarrer la base ?
Pourquoi il ne faut pas laisser le parametre audit_trail actif ?
Quel est la difference entre audit et sql_trace ?

Comment auditer facilement un utilisateur (voir les requetes qu'il éxecute) ?

Sur ma base de test, j'ai laissé audit_trail actif, mais aucun audit ne tourne. Comment se fait t'il que la table dba_audit se remplie concernant le user DBSNMP ?? (base supervisée par le Grid)

Par la suite, j'aimerais apprendre a utiliser l'explain plan afin de voir le plan d'execution d'une requete, mais ca n'a pas l'air bien méchant.

Merci en tout cas pour l'aide déja apportée.

[IndianaAngus]

Bonjour,

Est t'il possible d'auditer un utilisateur dans devoir redémarrer la base ?
Oui c'est possible.

exemple:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

audit all by monUser by access;

Pourquoi il ne faut pas laisser le parametre audit_trail actif ?
C'est à dire actif? le mettre à none? en fonction de vos besoins, l'audit peut être interessant mais attention à la taille de la DB, il faut prévoir des purges régulière de la table d'audit sys.aud$

Quel est la difference entre audit et sql_trace ?
L'audit est pour enregistrer les actions de certains utilisateur ou certains privilege (comme du create any par exemple)

Comment auditer facilement un utilisateur (voir les requetes qu'il éxecute) ?
exemple:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

audit all by monUser by access;

Mais attention à la quantité de données généré si votre user fait beaucoup d'opération

L'utilisateur DBSNMP fait des requêtes dans la DB et elles sont enregistrés car un paramètre de votre audit fait que ces actions sont enregistrés. C'est pour cela que la vue dba_audit se rempli.

Il est plus facile de configurer l'audit depuis Grid Control grace à l'interface graphique

J'espère que cela t'as aidé.

[a.presles]

lorsque j'active l'audit sur une base je met systématiquement en place un systém de purge automatique de sys.aud$ simultanément.
La solution qui me parait la plus élégante est un dbms_job qui delete qui détruit par exemple les entrées de plus de 31 jours. Ce jobs étant executer pendant la fenetre de maintenance touts les jours.

Mais attention on oubli facilement de purger une fois que l'on fait autre chose que de l'audit.

[Le-DOC]

Bonjour,

Il est plus facile de configurer l'audit depuis Grid Control grace à l'interface graphique

Merci pour ces élements, je vais voir ce que ca donne.

Concernant le Grid Control, J'ai du mal a voir ou cela peut se parametrer .

Je vois bien l'option "Parametre d'audit" dans le groupe Sécurité de l'onglet
Je vois comment rajouter de l'audit,
mais je vois pas comment consulter le rapport d'audit ?

[IndianaAngus]

Je ne crois pas qu'il y ai un rapport d'audit tout fait. Il faut faire des requêtes dans la vue dba_audit.
Dans mon cas, c'est un outil externe qui vient récupérer toutes les x minutes les events d'audit et qui permet de faire du reporting dessus.

[Le-DOC]

Je suis entrain de tester l'audit avec ta commande,

Je vois bien la table AUD$ qui se remplie, mais je ne vois pas les requetes que l'utilisateur execute ??
Je vois simplement un code d'action "LOGOFF" ;(

Comment se fait ce ?

[Le-DOC]

ok, m'a suis trompé

j'ai testé avec OEM, et ca remplie bien latable AUD$.

Par contre, je vois pas les variables ??
j'ai des requetes avec des variables, je vois pas les resultats de ces variables


Edit:

Ca m'apprendra a pas cherche :/
les variables sont dans le champ: SQL_BIND de la vue DBA_AUDIT_OBJECT