È buona norma usare indici invertiti su chiavi surrogate? (Oracle)

Question

Dire che ho una tabella con una chiave surrogata auto-incrementante.

Questo sarebbe un buon caso per l'utilizzo di un indice inverso?

Ho ragione nel dire:

inserimenti (in indice) sarebbe più veloce .. dal momento che i nuovi valori sarebbero stati inseriti in modo casuale, invece di andando sempre più a destra del foglio (in costante forzatura riequilibra).

Le ricerche dell'indice sarebbero leggermente più lente .. poiché il db avrebbe dovuto impiegare (un po ') tempo a rovesciare l'indice.

Poiché è una chiave surrogata. Non avrei davvero bisogno dell'abilità di scansione di intervallo (che non è possibile fare con gli indici inversi).

(Nota, non sto usando Oracle RAC)

Answer 1

In generale, se non si sta usando RAC, non ci sarebbe alcun motivo per utilizzare un indice di reverse-chiave.

Dal punto di vista delle prestazioni, si sta molto meglio avere uno o due blocchi caldi in un dato punto nel tempo che sono soggetti a inserti perché garantisce essenzialmente che i blocchi caldi saranno nella cache buffer e l'INSERT won Devo sostenere il costo di leggere il blocco dal disco. Se gli inserti sono inseriti in blocchi casuali in un indice, esiste una probabilità molto maggiore che il blocco desiderato venga invecchiato fuori dalla cache e possa sostenere il costo di un I/O fisico.

Il costo di mantenere un indice bilanciato è piuttosto limitato ma anche quello favorisce un indice standard. Se hai una chiave primaria generata in sequenza con un indice normale, Oracle eseguirà un 90/10 block split nel blocco più a destra quando il blocco si riempie. Al contrario, se hai un indice di chiave inversa, Oracle deve fare 50/50 block splits ogni volta che un determinato blocco si riempie. Un blocco 50/50 suddivide metà dei dati dal vecchio blocco al nuovo blocco, un blocco di 90/10 solo copia il valore di dati più a destra nel nuovo blocco. Il blocco di 90/10, quindi, è molto più economico di un blocco di 50/50 e tu dovrai eseguire approssimativamente lo stesso numero di blocchi a prescindere dal tipo di indice che scegli. Quindi il costo di mantenere un indice regolare è inferiore al costo di mantenere un indice di chiave inversa, ignorando anche l'effetto della cache.

Il motivo per cui si intende utilizzare un indice di chiave inversa sarebbe che si sta utilizzando RAC e si desidera evitare il costo di avere molti nodi RAC che si contendono tutti lo stesso blocco a caldo. Se si deve spedire costantemente il blocco a caldo da un nodo a un altro per fare il prossimo inserimento, può valere la pena utilizzare un indice di chiave inversa per ridurre tale contesa. Se è stata concessa in licenza l'opzione di partizionamento, sarebbe preferibile comunque utilizzare un indice partizionato con hash (questo può essere fatto indipendentemente dal fatto che le tabelle siano partizionate o meno). Se non è stata concessa in licenza l'opzione di partizionamento, un indice di chiave inversa può essere sufficiente per risolvere la contesa sul blocco attivo per non richiedere la licenza del partizionamento.