oracle performance tuning parallel
Oracle - Exécuter une requête en parallèle
Imaginons une table avec 1 millions de lignes :
SQL> select count(*) from t_number; COUNT(*) ---------- 1000000
Regardons son plan d'exécution :
SQL> explain plan for select count(*) from t_number; Explained. SQL> select * from table(dbms_xplan.display); Plan hash value: 1871832226 ----------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ----------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 644 (2)| 00:00:08 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T_NUMBER | 997K| 644 (2)| 00:00:08 | -----------------------------------------------------------------------
La requête fait bien TABLE ACCESS FULL avec un coût de 644. Les performances pourraient se dégrader très vite avec plus de données dans la table. Il est donc recommandé de créer les index necéssaires pour éviter le TABLE ACCESS FULL. Mais si cela est inévitable, il est possible de lancer la requête en parallèle. Pour cela, le mieux est d'utiliser un HINT :
SQL> select /*+ parallel(t_number,4) */ count(*) from t_number; COUNT(*) ---------- 1000000
Regardons à nouveau son plan d'exécution :
SQL> explain plan for select /*+ parallel(t_number,4) */ count(*) from t_number; Explained. SQL> select * from table(dbms_xplan.display); Plan hash value: 3051343549 -------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | -------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 179 (2)| 00:00:03 | | | | | 1 | SORT AGGREGATE | | 1 | | | | | | | 2 | PX COORDINATOR | | | | | | | | | 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | Q1,00 | P->S | QC (RAND) | | 4 | SORT AGGREGATE | | 1 | | | Q1,00 | PCWP | | | 5 | PX BLOCK ITERATOR | | 997K| 179 (2)| 00:00:03 | Q1,00 | PCWC | | | 6 | TABLE ACCESS FULL| T_NUMBER | 997K| 179 (2)| 00:00:03 | Q1,00 | PCWP | | --------------------------------------------------------------------------------------------------------
Cette fois, la requête a un coût de seulement 179, ce qui correspond à une amélioration de 70% environ. On remarquera aussi que le temps d'exécution est du coup passé de 8 secondes à 3.