Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Démarche d'analyse pour problèmes de performances
Bonjour,
j'aurais souhaité connaître quelle démarche vous adoptez lorsque vous devez analyser une base pour laquelle les utilisateurs vous disent qu'il y'a des problèmes de performances (ex: traitement batch qui dure plus longtemps que d'habitude, requêtes à l'IHM qui rament etc.).
merci à ceux qui prendront le temps de répondre et qui feront partager leur expérience
v$session_wait, v$system_event, éventuellement statspack ou la dbconsole... ça permet déjà de pas mal débroussailler le terrain. Avant ça, si on peut identifier le code qui pose problème c'est encore mieux. Il faut aussi définir un objectif de performance clair.
Tu ne regardes pas en 1er les paramètres de la base ?
J'ai du mal à interpréter les informations de v$session_event et v$session_wait.
Comment t'interprète ces événements(ex:control file sequential read, buffer busy waits, log file sequential read, log file single write, log file switch completion...)
Quels sont les évènements les plus importants ? qu'indiquent-ils?
Comment ça se fait que je ne trouve pas d'infos sur le web sur ce sujet?
c'est quoi la Dbconsole?
Oui mais ça donne quoi ? Quel paramètre tu changes si tu ne sais pas d'où vient le problème ? Et puis, s'intéresser aux paramètres qui changent le comportement de toute la base quand c'est un batch qui pose problème c'est plus que scabreuxEnvoyé par farenheiit
Il faut lire la doc
Si tu vois des db scattered read ou des buffer chain à gogo tu peux commencer à te poser des questions. Tu peux aussi vérifier la fréquence des switchs et la vitesse de lecture/écriture (cf statspack).
Tu ne sais pas chercher ou tu cherches mal surement
http://oracle.developpez.com/guide/tuning/statpack/
http://oracle.developpez.com/guide/tuning/
Et l'excellent Oracle Performance Diagnostic Guide
c'est la console d'administration d'Oracle 10g
Bonjour,
Pour moi la démarche naturelle dans ce cas, c'est:
- un statspack report (ou AWR) couvrant la période concernée par le problème de perf. Et pas trop long non plus.
- voir s'il y a une relle activité: (DB time / Elapsed time), load profile
- voir les Top 5 events
- voir la définition de ces events dans Oracle Reference Manual
- en fonction de ces events, voir les SQL responsable de ces events (triés par physical reads si events i/o, triés par logical reads si events buffer ou cpu, etc)
Une fois les requêtes identifées: explain plan et tkprof
C'est pas le plus joli (par rapport aux outils graphiques) mais c'est le plus rigoureux pour ne pas faire de mauvaise interprétation des statistiques.
Cordialement,
Franck.
+1 pour pachot.
A zieuter également : les temps d'accès des datafiles. Quelques surprises parfois. A voir avec les admin stockage.
Parenthèse : j'ai vu un rapport de perf d'oracle, basé sur statspack (base en 9.2 sous unix), dans lequel la majorité des datafiles a des avg read time de l'ordre de 100-200 ms et quelques datafiles (les temporaires) avec des read time > 1000 ms. Et l'expert Oracle ne s'inquiète pas car c'est une base décisionnelle. Bizarre. Je ne connais pas encore le type de baie, de fs ou de raid. Mais si j'étais le client, j'investiguerai mon stockage.
Je regarde également (quand le report est de niveau 7) les buffer busy waits, locks, top 5 physical et logical reads (partie basse du report).
Viens ensuite le plus fastidieux mais plus efficaces : l'amélioration des requêtes mais c'est un second temps.
Je dirais plutôt: trace SQL et TKPROF.
Ca m'est arrivé aussi, j'ai mis plus de 2 semaines pour réussir à faire lacher le morceau aux admins système... en fait la dégradation de perf était intervenue juste après l'activation du mirroring sur les baiesParenthèse : j'ai vu un rapport de perf d'oracle, basé sur statspack (base en 9.2 sous unix), dans lequel la majorité des datafiles a des avg read time de l'ordre de 100-200 ms et quelques datafiles (les temporaires) avec des read time > 1000 ms. Et l'expert Oracle ne s'inquiète pas car c'est une base décisionnelleCa faisait pourtant 2 semaines qu'ils me baladaient en me disant qu'ils avaient une nouvelle baie ultra performantes
Exact. C'est en général une bonne idée de comparer les débits des différentes resources (par exemple disque en io/s ou Mo/s) avec ce qu'on peut en attendre (d'après des test de calibration, ou les specs constructeurs du SAN...)
Et enfin, il est toujours interressant de jetter un coup d'oeuil au système avant de regarder oracle. Par exemple, le % de wait i/o ou le load average sous Unix
Un exemple: si le système est surchargé (load average très supérieur au nombre de CPU) à cause d'une utilisation intense de CPU, même si les i/o sont rapides, les wait events oracle vont y rajouter le temps passé en runqueue à attendre un cpu de libre.
On verra des problèmes d'i/o dans le Top 5 du statspack, mais le vrai bottleneck c'est la cpu et pas les i/o
Oups, une question comme ça on peut en parler des heures
Cordialement,
Franck.
y'a un moyen d'imprimer le contenu des pages Oracle performence guide???
bah oui, tu utilises la fonction d'impression de ton navigateur internet
lol
non justement quand j'accède à la page Performance Diagnostic Guide ça m'ouvre une fenêtre mais sans menu
finalement ça marche avec IE mais pas avec FireFox
Ctrl + P pour imprimer
Répondre avec citation
Partager