tag:blogger.com,1999:blog-456686155150137588.post1841811341436710599..comments2023-11-08T23:42:52.114+01:00Comments on Le blog Oracle d'Ahmed AANGOUR: Régler un problème de performance en 5 étapesAhmed AANGOURhttp://www.blogger.com/profile/03378785645074450748noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-456686155150137588.post-34489245420412151222022-01-08T16:08:56.454+01:002022-01-08T16:08:56.454+01:00Très intéressant. bravoooTrès intéressant. bravoooariahihttps://www.blogger.com/profile/11551423921000710889noreply@blogger.comtag:blogger.com,1999:blog-456686155150137588.post-14205608827130238412017-09-13T09:22:25.765+02:002017-09-13T09:22:25.765+02:00Grand merçi pour cet article si riche en enseignem...Grand merçi pour cet article si riche en enseignement pour les debutantssaibou.parehttps://www.blogger.com/profile/00127311889496500039noreply@blogger.comtag:blogger.com,1999:blog-456686155150137588.post-38854519800835353512015-09-04T18:48:53.568+02:002015-09-04T18:48:53.568+02:00Bonjour, effectivement je n'utilise jamais le...Bonjour, effectivement je n'utilise jamais le sql Tuning advisor. Je l'ai testé sur certains cas difficiles par le passé et il ne m'a jamais aidé, c'était même pire. Je pense que c'est plus un outil pour aider les DBAs qui ne savent pas du tout comment tuner une requête. Avec l'advisor on n'a aucune idée de la cause du pb et même si le plan est réglé par un sql profile il concernera uniquement cette requête et la root cause ne sera pas identifiée. Le pb risque de se reproduire plus tard sur une autre requête. Ahmed AANGOURhttps://www.blogger.com/profile/03378785645074450748noreply@blogger.comtag:blogger.com,1999:blog-456686155150137588.post-20908101767655840322015-09-04T18:26:16.485+02:002015-09-04T18:26:16.485+02:00Dans l'étape 3 : Analyse
Une fois que vous av...Dans l'étape 3 : Analyse <br />Une fois que vous aveze identifiez les requêtes SQL problématiques dans le <br />referentiel AWR, je voudrais savoir si on pouvait utilisez le fameux outils <br />dbms_sqltune en soumettant une analyze d'une requête via un task et ensuite générer <br />le rapport pour voir si la cause du problème pourrait apparaitre et correspond bien à <br />ce que vous avez pu trouver sur votre blog ??? <br />Je vous pose cette car, vous n'avez jamais utilisé cette fonctionnalité sur vos <br />blog de tuning des requettes, alors que vous utilisez toujours les statistiques <br />d'un plan d'éxécution pour identifier la lenteur de l'operation du PE (plan d'éxécution) .<br /><br />Ps: c'est juste pour comparer la rapidité et la simplicité utilisant différents outils <br /> (trace 10046, 10053, TKPROF, Plan d'éxécution mais aussi dbms_sqltune via un task(sql_id)) ??<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-456686155150137588.post-20127774099068768212013-05-06T16:40:47.459+02:002013-05-06T16:40:47.459+02:00Une belle narration d’un exemple concret tiré de l...Une belle narration d’un exemple concret tiré de la vie réelle d’une application. L’exemple est également formateur et peut servir de référence pour ceux ou celles qui souhaitent savoir par quel bout commencer la résolution d’un problème de performance.<br /><br />Le temps d’attente db file sequential read est fortement corrélé avec la partie SQL ordered by Gets. En effet, ce type de temps d’attente concerne une lecture séquentielle via index qui consomme beaucoup d’I/O ou de ‘’logical read’’. Je suppose que le SQL que vous avez identifié dans la partie SQL ordered by Elapsed time est le même que celui que vous allez trouver dans la partie SQL ordered by Gets. De plus, le temps moyen de lecture de ce événement d’attente n’est pas un temps idéal (8ms). Il fallait voir après votre ‘’tuning’’ si ce temps moyen a été réduit ou pas. Si ce n’est pas le cas alors il faut se poser des questions sur le disque et la rapidité par laquelle il est en train de servir la base de données.<br /><br />Revenons maintenant à cette opération IDX_OBJ_DATE INDEX SKIP SCAN. Je ne pense pas que le CBO ait fait un index skip scan parce que le prédicat est sur la deuxième colonne. Non, le prédicat est bien sur les deux colonnes de l’index (stv_date, stv_obj_id) deux fois sur la même table ; par contre la première fois il concerne une égalité sur les deux colonnes (d’où le premier INDEX RANGE SCAN sur IDX_OBJ_DATE dans l’opération 4) alors que lors du deuxième accès le prédicat est sur une inégalité de la première colonne de l’index (stv_date <= TO_DATE ('29-06-2012', 'dd-mm-yyyy')). Sur un index dont la première colonne n’est pas trop répétée, il n’y aurait eu aucun accès via index. Ici dans votre cas, il s’avère que stv_date contient peu de valeurs distinctes ce qui a conduit le CBO a préféré un catastrophique INDEX SKIP SCAN (opération 9).<br /><br />Lorsque vous avez crée le nouvel index IDX_STV_OBJ_ID, l’opération 9 s’est transformée en un INDEX RANGE SCAN plus un filtre beaucoup plus rapide sur la table en lieu et place d’un trop gourmant INDEX SKIP SCAN sur l’index IDX_OBJ_DATE couplé avec un double prédicat access/filter ( comme indiqué par le prédicat n°9)<br /><br />Notez bien aussi qu’en réécrivant la requête en utilisant les fonctions analytiques, l’index IDX_OBJ_DATE n’a même pas été utilisé.<br /><br />J’ai toujours été un peu déstabilisé par cette ‘’INTERNAL_FUNCTION’’ qui apparait dans la partie PREDICATE du plan d’exécution (comme dans votre cas ici : opération 20 dans le dernier plan d’exécution). Il y a moyen encore de gagner en temps de réponse en faisant uniquement une opération ACCESS sur cet index au lieu de faire un ACCESS+FILTER sur l’index IDX_MHR_LOHTHTLD. Mais pour cela il va falloir réussir à éviter la fonction INTERNAL_FUNCTION qui souvent se fait lorsqu’on manipule des dates ou de timestamp. Tanel Poder a fait un bon résumé sur cette fonction Interne d’Oracle dans le lien suivant<br />http://blog.tanelpoder.com/2013/01/16/what-the-heck-is-the-internal_function-in-execution-plan-predicate-section/<br /><br />De plus, l’accès à l’index IDX_MHR_LOHTHTLD est exécuté 1680 fois pour ramener 0 lignes et en consommant presque 100% du temps de réponse total de la requête. Je pense qu’il y a moyen d’éliminer cette opération ou de l’améliorer.<br /><br />Mohamed Houri<br /><br />PS: je n'ai pas pu mettre tout ce que j'avais à dire parce que le commentaire est limité à 4096 caractères. Tout ce que j'ai à dire peu même être contenu dans un nouvel article.Mohamed Hourihttps://www.blogger.com/profile/11687776847553675567noreply@blogger.comtag:blogger.com,1999:blog-456686155150137588.post-50093677951294307402013-05-01T21:18:21.794+02:002013-05-01T21:18:21.794+02:00Très intéressant.
Merci pour ce blog Oracle fourn...Très intéressant. <br />Merci pour ce blog Oracle fournissant un vrai regard d'expertAnonymousnoreply@blogger.com