Indice cluster in SQL Server vs indice tabelle organizzate in Oracle

Sto effettuando la transizione come sviluppatore di database da SQL Server a Oracle e ho già trovato alcune fantastiche risorse qui ( Come effettuare una transizione da DBA SQL Server a Oracle? E come DBA, come potrei fare per passare da Oracle a SQL Server ? ) ma non riesco a trovare buone informazioni sull'uso delle tabelle organizzate indice in Oracle.

Nella mia vita precedente, abbiamo fatto ampio uso di indici cluster in SQL Server nel nostro datamart OLTP con grande successo. Le tabelle organizzate indicizzate sono utili in Oracle?

Se stai passando da SQL Server a Oracle, ti consiglio di provare inizialmente le tabelle heap perché sono la forma standard di archiviazione dei dati in Oracle. Per la maggior parte dei carichi di lavoro, le tabelle heap con indici regolari in Oracle sono le forme di archiviazione più bilanciate per quanto riguarda DML e prestazioni delle query.

Se in seguito riscontri problemi di prestazioni o colli di bottiglia, dovresti esaminare metodi di archiviazione avanzati specializzati come IOT, partizionamento, cluster, indici a chiave inversa, ecc.

Per quanto riguarda in particolare IOT, sconsiglio il loro uso generalizzato perché ci sono molti "trucchi" che potresti non voler prendere come principiante:

• IOT non ha un vero rowid (perché non c'è una tabella in sé).
• di conseguenza, gli indici secondari su IOT non hanno veri puntatori alle righe ma solo semplici congetture che possono portare a scansioni degli indici inefficienti.
• Alcune funzionalità sono disabilitate su IOT come colonne virtuali , compressione di tabelle , partizionamento composito.
• Al momento della creazione, è necessario decidere dove archiviare le colonne non indice (in linea o in un segmento di overflow), portando potenzialmente a prestazioni disastrose per alcune query.

Gli IOT in Oracle non sono esattamente gli stessi degli indici cluster in SS perché le statistiche Oracle includono la dispersione fisica delle righe, mentre SS non include la posizione fisica nelle sue statistiche. Vedi questo dibattito tra Lewis e Fritchey su Statistics in Oracle e SQL Server per maggiori informazioni. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ) Ecco perché un cluster L'indice in SS è meglio di un heap. L'indice cluster aggiunge i dati sulla posizione fisica alle statistiche. Gli IOT sono validi quando si sa che l'indice fornisce la colocation delle righe di dati che verranno ricercate, ad esempio l'indice su order_date e il cliente per una tabella degli ordini farebbe un buon IOT.

Vincent mette in luce alcuni aspetti importanti degli IOT, ma puoi trarne anche alcuni vantaggi significativi.

Personalmente penso che siano significativamente sottoutilizzati in Oracle e dovrebbero essere considerati molto più ampiamente - non solo la soluzione possibile ai problemi di prestazioni. Poiché è necessario ricreare la tabella per la conversione tra IOT e heap, si tratta di una modifica che è improbabile che accada su un database sempre attivo e molto utilizzato a meno che i problemi di prestazioni non siano gravi.

Martin Widlake ha una grande serie di post sugli IOT. Ci sono alcuni vantaggi significativi che puoi ottenere usandoli:

• Ridurre significativamente le letture IO fisiche e logiche
• Uso più efficiente della cache buffer, che può avvantaggiare le prestazioni a livello di sistema
• Spazio risparmiato poiché stai solo mantenendo un indice, non anche una tabella (a meno che tu non abbia segmenti di overflow)

Tuttavia, per ottenere questi vantaggi hai bisogno di tabelle in cui (quasi) includi sempre le colonne principali della chiave primaria nelle query e probabilmente recupererai più righe contemporaneamente. Alcuni esempi comuni di tali tabelle sono:

• Dettagli anagrafici multipli come spesso si trovano negli ordini: articoli ordine, fatture - righe fattura ecc.
• Tabelle di risoluzione molti-a-molti che sono generalmente interrogate "a senso unico". ad esempio in una customer_addressestabella, è molto più comune trovare tutti gli indirizzi per un cliente, piuttosto che tutti i clienti per un indirizzo.

Un aspetto negativo è che l'inserimento dei dati è più lento, quindi è necessario valutare costi e benefici. In definitiva, si tratta di conoscere i tuoi dati e capire come devono essere utilizzati che dovrebbero guidare la decisione.