La 11g avait apporté les index invisibles: on peut créer des index qui sont maintenus, mais ne sont pas utilisés par les requêtes. Pour pouvoir les tester par exemple.
Mais il était toujours impossible de tester un différent type d’index sur des colonnes déjà indexées (pour le passer en bitmap, en reverse, le compresser,…).
L’erreur était:
Cause: A CREATE INDEX statement specified a column that is already indexed. A single column may be indexed only once. Additional indexes may be created on the column if it is used as a portion of a concatenated index, that is, if the index consists of multiple columns.
Action: Do not attempt to re-index the column, as it is unnecessary. To create a concatenated key, specify one or more additional columns in the CREATE INDEX statement.
En 12c, cette restriction est levée dans le cas où l’index que l’on crée est invisible.
Par exemple, je n’ai pas d’erreur en exécutant ceci:
create unique index TEST2 on TEST(num) reverse invisible;
On a donc 2 index sur les mêmes colonnes. Ils sont maintenus (donc utilisables) mais un seul n’est utilisé: celui qui est visible.
Il est facile de passer de l’un à l’autre en changeant leur visibilité: c’est une opération online (pas de verrou).
Deux gros avantage:
- créer un index peut être long. On peut le faire online, mais le fait de devoir supprimer l’ancien avant nous laissait un certain temps dans index.
- si on ne le crée pas online, la création du nouvel index peut être très rapide car elle utilise l’ancien.
On a donc le choix: maximiser la disponibilité de l’application en le créant online, ou minimiser le temps de création de l’index.
Si l’index supporte une contrainte d’intégrité, c’est un peu plus complexe.
Le détail dans la demo avec une introduction sur de nouvelles opérations online apportées par la 12c (drop index et drop constraint).