19 janvier 2019

Générer la trace 10053 du CBO : quelques pièges à éviter - Generate trace 10053 of the CBO: some pitfalls to avoid

  IntroductionCet article ne décrit pas comment lire la trace 10053, d'autres sites ont déjà traité le sujet. En revanche la génération de cette trace révèle quelques pièges et c'est de cela dont je veux parler puisque ces sites font en général l'impasse dessus.  Points d'attentionAucun. Base de testsN'importe quelle base Oracle. Exemples============================================================================================Générer la trace : rôle DBA suffisant ou user SYS... [Lire la suite]
Posté par David DBA à 11:08 - - Permalien [#]
Tags : , ,

05 janvier 2019

Autotrace : liste des statistiques différentes selon qu'on utilise SQL*Plus, SQLcl, Toad ou SQL Developer

  IntroductionLa commande AUTOTRACE permet d'afficher, pour un ordre SQL, un plan d'exécution mais aussi des statistiques relatives à cet ordre. Là où la situation se complique, c'est qu'Oracle, et les éditeurs tiers, proposent des stats différentes selon les outils utilisés; c'est ce que nous allons voir.  Points d'attentionAucun. Base de testsUne base Oracle 12 avec au moins sqlcl installé. Exemples============================================================================================Stats Autotrace avec... [Lire la suite]
Posté par David DBA à 13:55 - - Permalien [#]
Tags : , ,
16 octobre 2017

ORDER BY et déduplication SQLNet : un ORDER BY ne ralentit pas toujours une requête - ORDER BY and SQLNet deduplication

IntroductionDans mon précédent article "ORDER BY et Consistents gets réduits par 10 : un ORDER BY ne ralentit pas toujours une requête!", je parlais du fait qu'un ORDER BY ne ralentit pas toujours un SELECT, voir même peut l'accélérer en divisant considérablement le nombre de Consistents gets. Dans cet article nous allons voir que le ORDER BY peut aussi diminuer la taille des données échangées entre le client et le serveur via de la déduplication des données identiques et que cela contribue à rendre le SELECT plus rapide. Points... [Lire la suite]
Posté par David DBA à 23:13 - - Permalien [#]
Tags : , ,
08 octobre 2017

ORDER BY et Consistents gets réduits par 10 : un ORDER BY ne ralentit pas toujours une requête! - ORDER BY and Consistents gets

IntroductionVous savez qu'un ORDER BY dans une requête SQL va générer au niveau d'Oracle un SORT des données. Cette opération de tri est très consommatrice en terme de ressources mais, sur le coût total du plan d'exécution, ce coût peut être annulé en gagnant sur d'autres opérations. Nous allons voir qu'une requête avec un ORDER BY peut être aussi rapide voir même plus rapide qu'une requête sans le ORDER BY. Points d'attentionRéfléchissez bien avant de faire un ORDER BY car cette opération est très lourde pour Oracle et dans... [Lire la suite]
Posté par David DBA à 14:21 - - Permalien [#]
Tags : , ,
08 juin 2017

Plan d'exécution : la ligne la plus indentée n'est pas exécutée en premier - The most indented line is not executed first

IntroductionUn plan d'exécution Oracle peut rapidement devenir incompréhensible dès qu'il comporte des dizaines de lignes. On peut s'aider de Google ou de livres d'administration Oracle pour le décrypter mais, curieusement, même les DBA les plus connus ne sont pas d'accord sur l'ordre dans lequel Oracle exécute les différentes opérations de ce plan! Pour rappel, il est fondamental de comprendre l'exécution de ce plan pour tuner un ordre SQL! Si on ne sait pas quelle est la première opération exécutée, il est impossible de mettre en... [Lire la suite]
Posté par David DBA à 21:33 - - Permalien [#]
Tags : ,