 |
Conseils Oracle par Burleson Consulting |
Au sein de ces deux optimiseurs, Oracle propose plusieurs modes d’optimiseur. Un mode optimiseur peut être défini pour l’ensemble de la base de données ou pour une session Oracle spécifique. Les modes optimiseur incluent rule, first_rows, all_rows et choose. Examinons de plus près chacun de ces objectifs.
Mode règle
L’indice de règle ignore le CBO et les statistiques et génère un plan d’exécution basé uniquement sur les informations de base du dictionnaire de données. C’est toujours une bonne idée d’essayer de régler une instruction SQL spécifique en utilisant le RBO en utilisant un indice de règle ou en émettant la règle alter session set optimizer_goal=. Cependant, rappelez-vous toujours que le RBO peut choisir un index moins qu’idéal pour traiter une requête.
Optimizer_mode= choisissez
Le mode choisir l’optimiseur permet à Oracle de choisir l’objectif d’optimiseur le plus approprié. Il s’agit du mode optimiseur par défaut dans Oracle, et il utilise généralement la présence de statistiques pour déterminer l’optimiseur à invoquer. Si aucune statistique n’existe, Oracle utilisera l’objectif de la règle. Si des statistiques existent, Oracle choisira first_rows ou all_rows, en fonction de la présence d’index et des paramètres de parallélisme et de db_file_multiblock_read_count.
Avertissement: Avoir des statistiques incomplètes avec le mode choisir l’optimiseur peut entraîner d’énormes ralentissements. Si Oracle détecte une seule table dans une requête avec des statistiques, il utilisera l’optimiseur basé sur les coûts et calculera des statistiques pour les autres tables au moment de l’exécution. Cela peut entraîner un énorme ralentissement de l’exécution de SQL. Ce problème est très courant avec les débutants Oracle Remote DBA car le mode par défaut est choisir et parce que les DBA distants débutants émettent parfois de manière sélective la commande analyze, sans se rendre compte qu’ils effectuent des temps d’exécution SQL.
mode first_rows
Il s’agit d’un mode d’optimisation basé sur les coûts qui renverra des lignes dès que possible, même si la requête globale s’exécute plus longtemps ou consomme plus de ressources. Le mode d’optimisation first_rows implique généralement de choisir un balayage d’index complet plutôt qu’un balayage parallèle de table complète. Étant donné que le mode first_rows favorise les analyses d’index par rapport aux analyses de table complète, le mode first_rows est le plus approprié pour les systèmes en ligne où l’utilisateur final souhaite voir certains résultats le plus rapidement possible.
mode all_rows
Il s’agit d’un mode d’optimisation basé sur les coûts qui garantit que le temps de requête global est minimisé, même s’il faut plus de temps pour recevoir la première ligne. Cela implique généralement de choisir une analyse de table complète parallèle plutôt qu’une analyse d’index complet. Étant donné que le mode all_rows favorise les analyses de table complète, le mode all_rows est le mieux adapté aux requêtes orientées par lots où les lignes intermédiaires ne sont pas nécessaires pour la visualisation.
Quel est le « meilleur » ? Exécution rapide par rapport à une utilisation minimale des ressources.
Pour comprendre la philosophie d’Oracle concernant l’exécution rapide et la consommation minimale de ressources, nous devons regarder un exemple simple. Pour illustrer la différence entre all_rows et first_rows avec un exemple trop simpliste, considérons la requête suivante :
select
last_name
from
customer
order by
last_name;
Cette requête peut être traitée de deux manières:
-
Analyse de la table complète – Ici, nous effectuons une analyse de la table complète en parallèle et trions les lignes dans l’espace de table TEMPORAIRE. Par souci d’illustration, supposons que ce plan d’exécution produit le temps d’exécution global le plus rapide et une utilisation minimale des ressources (figure 2).
Figure 2: Effectuer une analyse complète de la table et un tri (all_rows)
-
Analyse complète de l’index – Ici, nous récupérons les lignes dans l’ordre de last_name en utilisant un last_name_index. Cette technique se traduit par des lectures plus physiques, mais commence à renvoyer des lignes triées presque immédiatement (figure 3).
Figure 3: Effectuez à nouveau une récupération d’index (first_rows)
, en supposant que nous acceptons l’analyse de la table complète et que le tri est moins intensif en E / S que l’analyse de l’index complet, nous pouvons clairement voir la différence dans les objectifs de l’optimiseur. L’analyse de l’index complet commencera à renvoyer des lignes presque immédiatement au détriment des E / S supplémentaires, tandis que l’analyse de la table complète nécessitera moins de ressources, mais le jeu de résultats ne sera disponible qu’à la fin de la requête.
Ceci est un extrait de « Oracle High-Performance SQL Tuning » de Donald K. Burleson, publié par Oracle Press.
