Discussion :

[debdba]

Bonsoir,

En oracle 10g sur AIX sans statpack comment calculer le nombre de requete par table et par heure
Merci

[Pomalaix]

Je ne suis pas convaincu que le nombre de requêtes par objet soit une métrique très pertinente, tant 2 requêtes peuvent être différentes. (C'est comme comptabiliser à la fois les éléphants et les fourmis, en considérant que ce sont tous des êtres vivants).

Ma première idée serait plutôt d'aller piocher dans V$SEGSTAT.

[debdba]

Bonjour,

Je précise ma question: j'aimerais connaitre par tranche horaire, le nombre de requetes passées et si possible cibler les objets les plus sollicités
Merci

[ojo77]

Pas de stratspack certes, mais avez vous une licence vous autorisant à utiliser AWR ? Sinon, qui vous interdit l'installation de statspack ?

[Mohamed.Houri]

Bonjour,

Je précise ma question: j'aimerais connaitre par tranche horaire, le nombre de requetes passées et si possible cibler les objets les plus sollicités
Merci

Il me semble que vous avez un problème de performance, que vous pensez avoir trouvé la raison mais que vous ne savez pas comment s’y prendre pour le confirmer et, donc, vous venez ici pour demander de l’aide sur le ''comment faire pour trouver la confirmation de ce que vous pensez être le problème’’. Ai-je raison?

Dans l'affirmative, Ce n’est vraiment pas, à mon humble avis, la méthode à suivre. Surtout lorsque vous voulez de l’aide. Posez plutôt clairement votre problème avec tous les détails possibles puis suggérez votre piste et laissez les autres apporter leurs contributions.

Ceci dit, si vous avez les licences nécessaires à cela, la réponse stricte à votre question se trouve dans le rapport AWR (Automatic Workload Repository) qui par défaut collecte les informations de performance chaque heure. Il suffit alors de consulter dans ce rapport les parties suivantes :

Code :

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

1
2
 
 SQL ordered by Execution (by Logical read, physical read, etc…)

et la partie Segment By pour les objets les plus sollicités

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
1.Segments by Logical Reads 
2.Segments by Physical Reads 
3.Segments by Physical Read Requests 
4.Segments by UnOptimized Reads 
5.Segments by Optimized Reads 
6.Segments by Direct Physical Reads 
7.Segments by Physical Writes 
8.Segments by Physical Write Requests 
9.Segments by Direct Physical Writes 
10.Segments by Table Scans 
11.Segments by DB Blocks Changes 
12.Segments by Row Lock Waits 
13.Segments by ITL Waits 
15.Segments by Buffer Busy Waits

[debdba]

Non pas vraiment aucun problème de perf, mais simplement mettre en évidence les pics d'utilisation de la base et plus précisement de certaines requetes et table.

En questionnant la v$sqlarea j'arrive à avoir cette information en prenant en compte la colonne exécution et sysdate.
A présent il va falloir que j'isole le nombre par heure et non pas le cumul depuis le début de l'ouverture de la base.

Code :

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

select sql_text, sysdate, executions from v$sqlarea where module like '%****%' ;

S'il y a mieux?????

merci

[Mohamed.Houri]

Non pas vraiment aucun problème de perf, mais simplement mettre en évidence les pics d'utilisation de la base et plus précisement de certaines requetes et table.

En questionnant la v$sqlarea j'arrive à avoir cette information en prenant en compte la colonne exécution et sysdate.
A présent il va falloir que j'isole le nombre par heure et non pas le cumul depuis le début de l'ouverture de la base.

Code :

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

select sql_text, sysdate, executions from v$sqlarea where module like '%****%' ;

S'il y a mieux?????

merci

Attention!

plus le nombre d'executions (dans v$sql ou v$sqlarea) est grand mieux c'est. Il faut plutôt dans votre cas vous concentrer sur les sql suivants

Code :

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

1
2
3
 
select * from v$sqlarea
where executions <=2;  -- 1 ou 2

S'il y en a, c'est que votre application n'utilise pas les ''bind variables'' qui dans ce cas (surtout dans un environnement OLTP) est catastrophique

[mnitu]

...S'il y a mieux?????

merci

Installez et utilisez statpack si pas de license pour AWR/ADDM.

[Pomalaix]

...plus le nombre d'executions (dans v$sql ou v$sqlarea) est grand mieux c'est...

Je comprends votre intention, mais la formulation est franchement excessive.

Moi je dirais plutôt qu'il faut ouvrir l'oeil face aux requêtes

1. qui ne sont exécutées qu'une fois
2. qui sont exécutées un très grand nombre de fois

Pour le premier cas, on peut utiliser cette excellente requête, fournie par Pachot, pour détecter le manque éventuel de variables de liaison : http://www.developpez.net/forums/d80...h/#post4629867

Pour le second, il faut se demander s'il est justifié qu'une même requête s'exécute des millions de fois. Ca peut être le signe d'une exécution procédurale (traitement ligne par ligne) pouvant être, éventuellement, remplacée par un traitement ensembliste.

[Mohamed.Houri]

Je comprends votre intention, mais la formulation est franchement excessive.

Moi je dirais plutôt qu'il faut ouvrir l'oeil face aux requêtes

1. qui ne sont exécutées qu'une fois
2. qui sont exécutées un très grand nombre de fois

Pour le premier cas, on peut utiliser cette excellente requête, fournie par Pachot, pour détecter le manque éventuel de variables de liaison : http://www.developpez.net/forums/d80...h/#post4629867

Pour le second, il faut se demander s'il est justifié qu'une même requête s'exécute des millions de fois. Ca peut être le signe d'une exécution procédurale (traitement ligne par ligne) pouvant être, éventuellement, remplacée par un traitement ensembliste.

Oui vous avez raison. Je me suis plus servi de v$sql pour traquer les sql executés une seule fois que l'inverse.

bind variables,shared pool and cursor sharing parameter

[debdba]

L'idée étant de mettre en évidence les moments de la journée où il y a le plus de trafic en base et sur quel objet se concentre ces trafics.
Il me semblait judicieux d'utiliser le nombre d'exécutions, car c'est la seule notion que j'ai trouvé pour mettre l'accent sur la charge par période.

Il n'est pas question de performance ni de blocage mais de cibler les moments de la journée les plus chargés.

J'avais aussi pensé à la vue v$sysstat

Code :

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

select name, value from v$sysstat where name = 'user commits';

, mais je n'ai pas la requete associée pour connaitre l'objet accédé.