Question

J'essaie d'optimiser les performances des requêtes et j'ai dû recourir à des astuces d'optimisation. Mais je n’ai jamais appris si l’optimiseur utiliserait plus d’une indication à la fois.

par exemple

SELECT /*+ INDEX(i dcf_vol_prospect_ids_idx)*/
       /*+ LEADING(i vol) */ 
       /*+ ALL_ROWS */ 
       i.id_number,
       ...
  FROM i_table i
  JOIN vol_table vol on vol.id_number = i.id_number
  JOIN to_a_bunch_of_other_tables...
 WHERE i.solicitor_id = '123'
   AND vol.solicitable_ind = 1;

Le plan d'explication indique le même coût, mais je sais qu'il ne s'agit que d'une estimation.

Veuillez supposer que toutes les statistiques de table et d'index ont été calculées. Pour votre information, l’index dcf_vol_prospect_ids_idx figure dans la colonne i.solicitor_id.

Merci,

Ragoût

Était-ce utile?

La solution

Essayez de spécifier tous les conseils dans un seul bloc de commentaires, comme indiqué dans cet exemple, à partir de la merveilleuse documentation Oracle ( http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/hintsref.htm ).

  

16.2.1 Spécification d'un ensemble complet d'indices

     

Lorsque vous utilisez des astuces, dans certains cas, vous   peut-être besoin de spécifier un ensemble complet de   astuces afin d'assurer l'optimum   plan d'exécution. Par exemple, si vous   avoir une requête très complexe, qui   se compose de nombreuses jointures de table, et si   vous ne spécifiez que l'indice INDEX pour un   tableau donné, alors l'optimiseur a besoin   pour déterminer l'accès restant   chemins à utiliser, ainsi que les   méthodes de jointure correspondantes. Donc,   même si vous avez donné l'indice INDEX,   l'optimiseur peut ne pas nécessairement   utiliser cet indice, parce que l'optimiseur   aurait pu déterminer que le   index demandé ne peut pas être utilisé en raison de   les méthodes de jointure et les chemins d'accès   sélectionné par l'optimiseur.

     

Dans l'exemple 16-1, l'indicateur LEADING   spécifie l'ordre de jointure exact pour être   utilisé; les méthodes de jointure à utiliser sur   les différentes tables sont aussi   spécifié.

     

Exemple 16-1 Spécification d'un ensemble complet de   Conseils

SELECT /*+ LEADING(e2 e1) USE_NL(e1) INDEX(e1 emp_emp_id_pk)
           USE_MERGE(j) FULL(j) */
    e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal  
FROM employees e1, employees e2, job_history j
WHERE e1.employee_id = e2.manager_id
  AND e1.employee_id = j.employee_id
  AND e1.hire_date = j.start_date
GROUP BY e1.first_name, e1.last_name, j.job_id   ORDER BY total_sal;

Autres conseils

En fait, Jonathan Lewis, auteur des principes de base d'Oracle basés sur les coûts, recommande que si l'OCB ne parvient pas à trouver le bon plan, vous devez prendre en charge le travail de l'OCB et "couche de montage". les astuces - une moyenne de deux astuces par table dans la requête.

La raison en est qu’une allusion pourrait mener à un autre plan, mauvais et peut-être même pire, que le CBO n’obtiendrait sans aide. Si le CBO a tort, vous devez lui donner l’ensemble du plan, et pas seulement un coup de pouce dans la bonne direction.

Oracle 19c a présenté la fonctionnalité de rapport d'utilisation des astuces :

EXPLAIN PLAN FOR
SELECT /*+ INDEX(i dcf_vol_prospect_ids_idx)*/
       /*+ LEADING(i vol) */ 
       /*+ ALL_ROWS */ 
       i.id_number,
       ...
  FROM i_table i
  JOIN vol_table vol on vol.id_number = i.id_number
  JOIN to_a_bunch_of_other_tables...
 WHERE i.solicitor_id = '123'
   AND vol.solicitable_ind = 1;

SELECT * FROM table(DBMS_XPLAN.DISPLAY(FORMAT=>'BASIC +HINT_REPORT'));
                                                     --============

Cela affiche une autre section Rapport de conseil :

Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: ...
---------------------------------------------------
...
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top