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 !