Toutes les requetes dans la v$sqlarea ?

[bruninho]

Bonjour, je dois analyser des requêtes faites sur un DB oracle et on m'a informé qu'il était possible de le faire à l'aide de la vue v$sqlarea.

En lisant la documentation Oracle j'ai appris (si j'ai bien compris) que l'on peut voir que les requêtes SQL qui sont dans la mémoire, analysés, et prêtes pour l'exécution. C'est à dire ?
Je ne peux donc pas visualiser toutes les requêtes faites (durant les dernières 24h)?


Y a-t-il un autre moyen pour visualiser l'historique de toutes le requêtes ?

Merci de me donner un coup de pousse.

[Marc Musette]

la réponse à ta question dépend de la version de ta db mais aussi le but recherché (optimisation des requêtes les plus gourmandes ? ou audit "qui a fait quoi")

pour l'analyse des performances et si tu es en 10g, tu dois absolument utiliser les fonctionalités AWR (Automatic Workload Repository) qui te permettront de mettre en avant les requêtes qui consomment le plus de resources, qui sont le plus souvent utilisées ... rien ne sert de connaître toutes les requêtes qui ont été lancées ; il "suffit" simplement d'optimiser les plus fréquentes ou les plus gourmandes (et à toi de définir gourmand - à priori le temps d'exécution est un bon départ)

en 9i , il te faudra utiliser STATPACK

rmq : en v$sqlarea tu devrais trouver les requêtes les plus fréquemment utilisées, et à qui tu devrais accorder la priorité

si maintenant, tu veux simplement recenser qui fait quoi sur la base, il faut plutôt penser à installer de l'audit sur ta db.

[LeoAnderson]

attention aux licences AWR et de tous les advisors...

En 10g aussi le statpack est donc plus qu'utile !

[bruninho]

Oui le but est de recenser qui fait quoi sur la base, ou plutôt savoir pour certaines tables comment sont-elles utilisés (select, insert,etc..), et par qui.

Comme vous dites j'ai pensé à utiliser la fonctionnalité AUDIT_TRAIL dont apparemment mon supérieur (le client) est allergique. Il me dis que ça pose des problèmes du fait que c'est qqch d'assez lourd à faire tourner.

Alors il veut aller voir dans la V$sqlarea ! Selon moi comme il n'y a pas toutes le requêtes cella ne va servir à rien !
D'autre part est-il vrai que c'est lourd à mettre en place AUDIT_TRAIL.

Merci de me donner votre avis sur ces deux possibilités.

[juniorYanis]

Bonjour,

comment pourrais-je installé audit qui permet de retrouver toutes les requestes sql et répondreà la question qui et qui fait quoi ?

[petitfrere]

dbms_fga

un audit complet de toute les transactions...


exemple: (mais ca peut aller plus loin que ca)

exemple:

Code :

exec dbms_fga.add_policy (object_schema=>'TEST',object_name=>'TTEST',policy_name=>'NICO_TEST', statement_types => 'SELECT, INSERT, UPDATE, DELETE');

je fais un pti select: select * from TEST.TTEST


je sais tous ce qu'il se passe sur la table TTEST du shema TEST

exemple: pour voir le résultat

select session_id, timestamp , db_user, userhost, object_name, object_schema, policy_name, scn, sql_text, statement_type from dba_fga_audit_trail (pour voir le resultat)

10629;28/08/09;14:58 SYSTEM;belaf;TTEST;TEST;NICO_TEST;4877744;select * from TEST.TTEST;SELECT

Pour voir les FGA ACTIF:

Code :

SELECT * FROM DBA_AUDIT_POLiCIES

Pour la supprimer:

Code :

exec dbms_fga.drop_policy (object_schema=>'TEST',object_name=>'TTEST',policy_name=>'NICO_TEST');

[thotdba]

Bonjour,

si la base à auditer est en version >= 10g tu peux activer AUDIT_TRAIL au niveau de la base et ajouter l'option "db,extended" qui ajoutera le code SQL complet ainsi que la valeur des variables "binds" à la table SYS.AUD$ .

Code :

1
2
3
4
5
SQL> ALTER system SET AUDIT_TRAIL=db,extended scope=spfile;
 
SQL> shutdown immediate
 
SQL> startup