C'è qualche ragione logica per avere un tablespace diverso per gli indici?

Question

Salve Alcuni possono farmi sapere perché abbiamo creato un tablespace diverso per Index e dati.

Answer 1

È opinione diffusa che mantenere indici e tabelle in spazi di tabella separati migliora le prestazioni. Questo è ora considerato un mito da molti rispettabili esperti (vedi questo thread Chiedi a Tom - cerca "mito" ), ma è ancora una pratica comune perché le vecchie abitudini sono dure a morire!

Modifica di terze parti

Estratto da asktom: " Index Tablespace " dal 2001 per Oracle versione 8.1.6 la domanda

• È comunque una buona idea mantenere gli indici nel proprio spazio tabella?
• Ciò migliora le prestazioni o è più un problema di recupero?
• La risposta differisce da una piattaforma all'altra?

Prima parte della risposta

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices. 

Answer 2

Ha senso negli anni '80, quando non c'erano molti utenti e le dimensioni del database non erano troppo grandi. A quel tempo era utile memorizzare indici e tabelle nei diversi volumi fisici.

Ora ci sono i volumi logici, il raid e così via e non è necessario memorizzare gli indici e le tabelle in diversi tablespace.

Ma tutti i tablespace devono essere gestiti localmente con dimensioni delle estensioni uniformi. Da questo punto di vista, gli indici devono essere archiviati in un tablespace diverso poiché la tabella con le 50 colonne potrebbe essere memorizzata nel tablespace con dimensioni di estensione di 5 Mb, quando il tablespace per gli indici sarà sufficiente con dimensioni estese di 512 KB.

Answer 3

• Prestazioni. Dovrebbe essere analizzato caso per caso. Penso che mantenere tutto insieme in un tablespace diventi anche un altro mito! Dovrebbe essere abbastanza mandrini, abbastanza luns e prendersi cura della coda nel sistema operativo. se qualcuno pensa che creare un tablespace sia sufficiente ed è uguale a molti tablespace senza prendere in considerazione tutti gli altri fattori, significa di nuovo un altro mito. Dipende!
• Alta disponibilità. l'utilizzo di tablespace separati può migliorare l'alta disponibilità del sistema nel caso in cui una certa correzione dei file, corruzione del file system, blocco della corruzione. Se il problema si verifica solo al tablespace dell'indice, è possibile effettuare il ripristino online e la nostra applicazione sarà ancora disponibile per il cliente. vedi anche: http : //richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
• l'utilizzo di tablespace separati per indici, dati, BLOB, clob, eventualmente alcune singole tabelle può essere importante per la gestibilità e i costi. Possiamo usare il nostro sistema di archiviazione per archiviare i nostri BLOB, clob, eventualmente archiviarli in un diverso livello di archiviazione con diversa qualità del servizio