Index Organized Tables

Continua per me un periodo intenso che mi impedisce di scrivere con la regolarità che vorrei su questo blog. Gli impegni del lavoro sono in questo periodo molti e pressanti, in più a stento cerco di proseguire la mia preparazione per l’esame di certificazione Oracle database 10g OCP.

Per dare segni di vita scrivo velocemente questo breve post su uno degli argomenti dell’esame OCP, le Index Organized Tables (IOT). Si tratta di tabelle particolari, alternative alle tradizionali Heap Tables, che sono caratterizzata dal fatto che i dati sono organizzati allo stesso modo di un classico indice, cioò secondo un struttura ad albero di tipo B-Tree.

Sono molto utili ed il loro utilizzo è consigliabili ad esempio per le tabelle di lookup, più in generale per tutte le tabelle non eccessivamente grandi (si in termini di numero di record che in termini di dimensione media dei record) che vengono interrogate prevalentemente per chiave primaria. Il primo vantaggio è un risparmio di spazio, il secondo è un miglioramento delle prestazioni dovuto a due fattori legati fra loro. Faccio un esempio, una tabella di lookup o decodifica. Supponiamo di avere una tabella di tipologie di articoli che può avere da qualche unità a qualche centinaio di record. Parliamo di applicazioni prevalentemente OLTP, ad esempio un sistema di gestione ordini. Se questa tabella viene usata ad ogni transazione per la decodifica dei codici degli articoli, ad ogni transazione viene interrogata per codice per avere la descrizione, questo significa normalmente in un accesso all’indice e successivamente alla tabella per estrarre il record completo. Chiaramente se la tabella viene usata molto è probabile che sia i blocchi relativi all’indice che quelli alla tabella verranno mantenuti in cache. Se in questo caso si usa una IOT si ha da un lato un miglioramento delle prestazioni dovuto al fatto che non c’è il doppi passaggio indice-tabella, una trovata l’elemento dell’indice si hanno tutti i dati. In più vi è un risparmio di spazio in cache che può essere quindi usato per altri dati.

Sulle IOT possono essere creati anche indici, chiamati indici secondari. La particolarità è che le IOT non hanno ROWID come le tabelle heap ma utilizzano UROWID ovvero rowid logici che contengono sia la chiave primaria che l’informazione sul file fisico e il blocco iniziale del dato, come il rowid per le tabelle heap. L’indicazione sul blocco però viene chiamata supposizione e può essere sbagliata perchè essendo una IOT organizzata fisicamente come un B-Tree a seconda della variazioni dei dati vi possono essere degli spostamenti per la riorganizzazione dell’albero (leaf block splits). Quindi oracle prima prova a travare il record nel blocco indicato nel UROWID, se l’indicazione è sbagliata allora utilizza la chiave primaria. Per evitare questa situazione occorre ricostruire l’indice. Una alternativa è l’uso dell’istruzione “ALTER INDEX … UPDATE BLOCK REFERENCES” che può ossere fatta a caldo (online).

OVERFLOW

In caso di record grandi è possibile anche indicare ad oracle di mettere parte dei record (solo campi non appartenenti alla chiave primaria) in una area separata dalla struttura b-tree. Ad esempio:

CREATE TABLE tipoarticolo (
 codice varchar2(10),
 descrizione varchar2(255),
 descrizionelunga varchar2(1000),
 CONTSTRAINT  tipoarticolo_cod_pk
  PRIMARY KEY (codice))
ORGANIZATION INDEX
TABLESPACE indx
PCTTHRESHOLD 20
OVERFLOW TABLESPACE users;

Personalmente, ma senza aver fatto prove che lo confermino, intuisco e sospetto che l’uso dell’overflow riduca di molto i vantaggi delle IOT sulle tabelle heap.