Bonsoir,
En oracle 10g sur AIX sans statpack comment calculer le nombre de requete par table et par heure
Merci
Bonsoir,
En oracle 10g sur AIX sans statpack comment calculer le nombre de requete par table et par heure
Merci
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.
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
Pas de stratspack certes, mais avez vous une licence vous autorisant à utiliser AWR ? Sinon, qui vous interdit l'installation de statspack ?
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 :
et la partie Segment By pour les objets les plus sollicités
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 SQL ordered by Execution (by Logical read, physical read, etc )
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
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.
S'il y a mieux?????
Code : Sélectionner tout - Visualiser dans une fenêtre à part select sql_text, sysdate, executions from v$sqlarea where module like '%****%' ;
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
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
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 select * from v$sqlarea where executions <=2; -- 1 ou 2
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
- qui ne sont exécutées qu'une fois
- 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
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, mais je n'ai pas la requete associée pour connaitre l'objet accédé.
Code : Sélectionner tout - Visualiser dans une fenêtre à part select name, value from v$sysstat where name = 'user commits';
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager