Changements de coût des Index Skip Scan entre 10g et 11g

Si vous êtes attentifs aux changements de plans lors de vos migrations entre versions de base de données, vous avez sûrement remarqué que les plans mettant en oeuvre les algorithmes Index Skin Scan sont largement favorisés lors du passage en 11g. Pour vous en persuader, reprenez la table exemple de l’article précédent et lancez l’ordre SQL ci-dessous en 10.2 et en 11.2 :

select  /*+index_ss(t)*/ count(text) 
from t
where col2=1;

En 10g, vous êtes obligé d’utiliser le hint pour forcer l’algorithme d’Index Skip Scan ! En 11g, l’algorithme a un coût plus faible qu’un accès complet à la table. Le pourquoi tient donc évidemment dans le calcul du coût. On le on voit dans les traces 10053 avec les 2 versions; dans le premier cas, en 10g, le coût en I/O (resc_io) est très proche du nombre de la cardinalité de la colonne « skippée » :

Access Path: index (skip-scan)
SS sel: 1.0000e-05 ANDV (#skips): 100000
SS io: 100000.00 vs. table scan io: 3326.00
Skip Scan chosen
Access Path: index (SkipScan)
Index: T_COL12
resc_io: 100002.00 resc_cpu: 712158633
ix_sel: 1.0000e-05 ix_sel_with_filters: 1.0000e-05
Cost: 100027.10 Resp: 100027.10 Degree: 1
Best:: AccessPath: IndexRange Index: T_COL12
Cost: 100027.10 Degree: 1 Resp: 100027.10 Card: 1.00 Bytes: 0

En 11g, le coût en I/O est quant à lui beaucoup plus proche du nombre de blocs de l’index :

Access Path: index (skip-scan)
SS sel: 0.000010 ANDV (#skips): 100000.000000
SS io: 290.000000 vs. table scan io: 4118.000000
Skip Scan chosen
Access Path: index (SkinpScan)
Index: T_COL12
resc_io: 292.00 resc_cpu: 2079850
ix_sel: 0.000010 ix_sel_with_filters: 0.000010
Cost: 292.09 Resp: 292.09 Degree: 1
Best:: AccessPath: IndexRange
Index: T_COL12
Cost: 292.09 Degree: 1 Resp: 292.09 Card: 1.00 Bytes: 0

La question qui vient à l’esprit, c’est « Est-ce que l’algorithme a changé ? » ; il ne semble pas que ce soit le cas au moins d’après les statistiques d’exécutions qui sont très proches entre les 2 versions et de l’estimation de la 11g :

Statistics
---------------------------------------------------
0 recursive calls
0 db block gets
292 consistent gets
0 physical reads
0 redo size
414 bytes sent via SQL*Net to client
400 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

Evidemment, il faudrait regarder les appels internes lors de l’exécution pour s’en assurer… Mais bon : une idée à tester pour ceux qui seraient encore en 10g et pour lesquels la situation se présenterait !

2 réflexions sur “Changements de coût des Index Skip Scan entre 10g et 11g”

  1. Walid,

    292.09 ;-).

    Je n’ai pas la formule. Il faut faire un peu de recherche. Si on s’en réfère à l’algorithme, cela devrait dépendre du nombre de valeurs des colonnes « skippées », de la sélectivité des accés, de la taille de l’index, de l’accès à la table. Pas simple à deviner !

    Grégory

  2. Bonjour Grégory,
    Je suis en train d’etudier une trace 10053 suite à un problème de performance chez un de mes clients.
    J’aimerais avoir plus de visibilité sutr comment Oracle estime le cout dans le cas d’un index skip scan.
    J’ai une liste de formule qui est évaluée selon le cas d’accès mais pas le cas d’un skip scan.
    Unique Scan :Blevel + 1
    Fast Full Scan: Leaf_blocks/k
    Index-only :Blevel + FF*leaf_blocks
    Range scan Blevel+FF*leaf_blocks+FF*clustering factor
    Cordialement,
    Walid

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *