Cet outil écrit en Java ( environnement de test: AIX6, JVM 1.6, instance 11.2.0.2 ) permet de créer n threads. Pour chaque thread, il utilise une session créée par un pool de connexion UCP et exécute une transaction ( select ou procédure stockée ) m fois. Entre chaque exécution, un sleep permet de stresser plus au moins l'instance.
Il est disponible ici.
Pour l'utiliser, il suffit de compiler les fichiers source ( javac ) après avoir paramétré votre environnement unix ( voir fichier env_java ). Il se lance de cette manière: java Pilote nb_thread delay_ms nb_execution. Le premier paramètre indique le nombre de threads, le second paramètre la valeur du sleep en ms et le troisième paramètre le nombre d'exécutions de chaque transaction.
Il se configure à l'aide de deux fichiers xml, config.xml et scenario.xml. Le fichier config.xml permet de définir les caractéristiques de l'instance via une url jdbc et de configurer le pool de connexion UCP. Le fichier scenario.xml permet de définir un test de charge; il décrit la transaction de chaque thread. L'outil ne traite que les select et les procédures. L'utilisation des variables bindées est possible.
Affichage des articles dont le libellé est Détection de problème. Afficher tous les articles
Affichage des articles dont le libellé est Détection de problème. Afficher tous les articles
jeudi 28 novembre 2013
mercredi 29 mai 2013
Outils
Voici un lien sur quelques outils pouvant être utiles pour votre administration de bases Oracle.
Ils sont compatibles 10g et 11g et fonctionnent sur des machines ( ou partitions ) de type Unix. Ils n'ont besoin que du shell sh et de sqlplus.
db_block est un outil permettant de détecter les sessions bloquantes et bloquées pour les locks de type TX et TM. Il s'agit du type de hang le plus classique, mais en vous appuyant sur la vue v$lock, vous pouvez étendre les recherches sur d'autres enqueues.
L'outil db_shared_pool permet d'analyser une erreur ORA-4031 au niveau du shared pool.
L'outil db_perf permet de détecter les requêtes coûteuses exécutées récemment. Il donne leurs caractéristiques ( texte de la requête, statistiques d'exécution, plan d'exécution ) , quelques conseils pour les optimiser ( sql tuning advisor, sql access advisor ) et des statistiques sur l'instance durant leur exécution ( AWR, ASH ).
Ils sont compatibles 10g et 11g et fonctionnent sur des machines ( ou partitions ) de type Unix. Ils n'ont besoin que du shell sh et de sqlplus.
db_block est un outil permettant de détecter les sessions bloquantes et bloquées pour les locks de type TX et TM. Il s'agit du type de hang le plus classique, mais en vous appuyant sur la vue v$lock, vous pouvez étendre les recherches sur d'autres enqueues.
Si un hang vous empêche tout accès à une instance, il ne reste plus qu'à utiliser l'option -prelim de sqlplus, puis à exécuter l'instruction suivante : oradebug hanganalyze 3 pour analyser le problème ( note 215858.1 ).
L'outil db_shared_pool permet d'analyser une erreur ORA-4031 au niveau du shared pool.
L'outil db_perf permet de détecter les requêtes coûteuses exécutées récemment. Il donne leurs caractéristiques ( texte de la requête, statistiques d'exécution, plan d'exécution ) , quelques conseils pour les optimiser ( sql tuning advisor, sql access advisor ) et des statistiques sur l'instance durant leur exécution ( AWR, ASH ).
mardi 30 mars 2010
Méthode de détection d'un problème ( partie 2 )
Si les vues associées aux wait events ne donnent aucun indice, on peut alors étudier les statistiques d'une session. Pour ce faire, on utilise les vues v$sesstat et v$statname. Pour information, une description succincte des statistiques est disponible dans une annexe du document de référence ( 11g: http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/stats.htm#i29468 ).
L'outil de T.Poder, snapper, permet entre autres de visualiser les statistiques d'une session. Il est décrit à cette adresse: http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper.
Par ailleurs, vous pouvez analyser un problème à partir des outils d'Oracle ( statspack ou awr ). Ce lien http://jonathanlewis.wordpress.com/statspack-examples/ vous aidera à interpréter ce type de rapport. L'outil ADDM permet également de recueillir quelques pistes d'optimisation.
Si tous ces outils ne vous permettent pas de résoudre votre problème, il reste alors à utiliser un outil comme dtrace ( http://hub.opensolaris.org/bin/view/Community+Group+dtrace/WebHome ), l'idée étant de descendre au niveau de la couche système pour détecter l'origine du problème.
L'outil de T.Poder, snapper, permet entre autres de visualiser les statistiques d'une session. Il est décrit à cette adresse: http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper.
Par ailleurs, vous pouvez analyser un problème à partir des outils d'Oracle ( statspack ou awr ). Ce lien http://jonathanlewis.wordpress.com/statspack-examples/ vous aidera à interpréter ce type de rapport. L'outil ADDM permet également de recueillir quelques pistes d'optimisation.
Si tous ces outils ne vous permettent pas de résoudre votre problème, il reste alors à utiliser un outil comme dtrace ( http://hub.opensolaris.org/bin/view/Community+Group+dtrace/WebHome ), l'idée étant de descendre au niveau de la couche système pour détecter l'origine du problème.
jeudi 28 janvier 2010
Méthode de détection d'un problème ( partie 1 )
Sur ce sujet, je vous conseille de consulter les différents messages de Tanel Poder et James Morle:
- http://jamesmorle.wordpress.com/2009/11/09/the-oracle-wait-interface-is-useless-sometimes-pt/
- http://blog.tanelpoder.com/2010/01/15/beyond-oracle-wait-interface-part-2/
- http://jamesmorle.wordpress.com/2010/01/18/the-oracle-wait-interface-is-useless-sometimes-part-3a/
- http://jamesmorle.wordpress.com/2010/02/16/the-oracle-wait-interface-is-useless-sometimes-part-3b/
Pour détecter un problème dans une instance Oracle, on peut commencer par utiliser l' interface des wait events.
Un wait event représente une attente d'un processus utilisateur ( session ) ou de l'instance ( PMON, SMON ... ). Elle peut être liée à l'accès à une ressource ( données du cache, verrous ... ) . Par exemple, une session qui a besoin d'un bloc d'index absent dans la SGA effectue une demande de lecture au système, puis attend la réception du bloc. Ce temps d'attente est un type de wait event, en l'occurence le wait event db file sequential read.
Les deux vues utiles sont v$session_wait ( niveau session ) et v$system_event ( niveau instance ). Le script sw.sql de T.Poder donne un exemple d'utilisation de la vue v$session_wait.
Une description détaillée des wait events est disponible à cette adresse: http://sites.google.com/site/embtdbo/wait-event-documentation.
L'event trace de type 10046 permet aussi de récupérer les wait events. Au niveau d'une session, on l'active de la manière suivante:
- alter session set timed_statistics = true; -- Activation des Extended SQL Trace
- alter session set max_dump_file_size = unlimited;
- alter session set events '10046 trace name context forever, level 8';
- alter session set events '10046 trace name context off';
Pour tracer une session autre que la sienne, on peut utiliser la méthode set_ev du package dbms_system ou l'outil de debug d'Oracle, oradebug.
On peut récupérer les traces dans le répertoire indiqué par le paramètre d'initialisation USER_DUMP_DEST. Le suffixe des fichiers trace est trc ou TRC. On peut faciliter l'identification du fichier trace via cette commande: alter session set tracefile_identifier = 'MonFichierTrace'. L'utilitaire tkprof permet de mettre en forme les fichiers trace.
Le chapitre 5 du livre de Cary Millsap, Optimizing Oracle Performance, constitue une introduction intéressante pour la compréhension des traces SQL étendues. Une mise à jour est disponible à cette adresse: http://method-r.com/downloads/doc_details/72-mastering-performance-with-extended-sql-trace.
Si nécessaire, l'analyse du problème peut être étendue à la couche système. Pour commencer, on utilise la commande vmstat pour avoir une vision générale du système ( CPU, mémoire virtuelle ). Puis, on peut étudier plus en détail les processus ou threads ( top, topas, prstat ), la CPU ( mpstat ), les interruptions (intrstat ), les appels système ( truss, strace ).
- http://jamesmorle.wordpress.com/2009/11/09/the-oracle-wait-interface-is-useless-sometimes-pt/
- http://blog.tanelpoder.com/2010/01/15/beyond-oracle-wait-interface-part-2/
- http://jamesmorle.wordpress.com/2010/01/18/the-oracle-wait-interface-is-useless-sometimes-part-3a/
- http://jamesmorle.wordpress.com/2010/02/16/the-oracle-wait-interface-is-useless-sometimes-part-3b/
Pour détecter un problème dans une instance Oracle, on peut commencer par utiliser l' interface des wait events.
Un wait event représente une attente d'un processus utilisateur ( session ) ou de l'instance ( PMON, SMON ... ). Elle peut être liée à l'accès à une ressource ( données du cache, verrous ... ) . Par exemple, une session qui a besoin d'un bloc d'index absent dans la SGA effectue une demande de lecture au système, puis attend la réception du bloc. Ce temps d'attente est un type de wait event, en l'occurence le wait event db file sequential read.
Les deux vues utiles sont v$session_wait ( niveau session ) et v$system_event ( niveau instance ). Le script sw.sql de T.Poder donne un exemple d'utilisation de la vue v$session_wait.
Une description détaillée des wait events est disponible à cette adresse: http://sites.google.com/site/embtdbo/wait-event-documentation.
L'event trace de type 10046 permet aussi de récupérer les wait events. Au niveau d'une session, on l'active de la manière suivante:
- alter session set timed_statistics = true; -- Activation des Extended SQL Trace
- alter session set max_dump_file_size = unlimited;
- alter session set events '10046 trace name context forever, level 8';
- alter session set events '10046 trace name context off';
Pour tracer une session autre que la sienne, on peut utiliser la méthode set_ev du package dbms_system ou l'outil de debug d'Oracle, oradebug.
On peut récupérer les traces dans le répertoire indiqué par le paramètre d'initialisation USER_DUMP_DEST. Le suffixe des fichiers trace est trc ou TRC. On peut faciliter l'identification du fichier trace via cette commande: alter session set tracefile_identifier = 'MonFichierTrace'. L'utilitaire tkprof permet de mettre en forme les fichiers trace.
Le chapitre 5 du livre de Cary Millsap, Optimizing Oracle Performance, constitue une introduction intéressante pour la compréhension des traces SQL étendues. Une mise à jour est disponible à cette adresse: http://method-r.com/downloads/doc_details/72-mastering-performance-with-extended-sql-trace.
Si nécessaire, l'analyse du problème peut être étendue à la couche système. Pour commencer, on utilise la commande vmstat pour avoir une vision générale du système ( CPU, mémoire virtuelle ). Puis, on peut étudier plus en détail les processus ou threads ( top, topas, prstat ), la CPU ( mpstat ), les interruptions (intrstat ), les appels système ( truss, strace ).
Inscription à :
Articles (Atom)
