Un database Oracle può avere più di un tablespace per l'archiviazione dei dati?

Question

Il mio team gestisce un database Oracle che si trova a ca. Dimensione da 200 GB. Tutti i dati (tabelle, indici, ecc.) Risiedono in un unico spazio tabella "UTENTI". È una cattiva idea? Quali vantaggi ci sono per avere più tablespace e in quali circostanze dovrei aggiungere altro al mio database?

Grazie!

Answer 1

Il mio pregiudizio (e questo è in gran parte una questione di preferenze personali) è che se non c'è alcun vantaggio irresistibile nella creazione di spazi tabelle aggiuntivi, la vita è più semplice con un solo tablespace.

• Non c'è alcun vantaggio in termini di prestazioni nel mettere gli oggetti in tablespace diversi. Esiste un vecchio mito che separare tabelle e indici avrebbe alcuni vantaggi in termini di prestazioni. C'è un potenziale vantaggio nel diffondere I/O su tutti i mandrini disponibili, ma è meglio farlo con più file di dati in un unico tablespace e poi con più tablespace poiché Oracle esegue un'assegnazione di estensioni round-robin in diversi file di dati assumendo che la propria SAN non sia sto già facendo qualcosa per pareggiare l'I/O.
• Se si dispone di tabelle di ricerca/cronologia statiche di grandi dimensioni, in modo da poter portare una nuova copia del database sul sito del client semplicemente portando gli spazi tabelle transazionali più piccoli, sarebbe un motivo per considerare più tablespace. Ma ci sono pochissime applicazioni che hanno questo tipo di configurazione. Se devi portare tutti i 200 GB, non importa quanti spazi tabella hai.
• Lungo le stesse linee, se si dispone di oggetti di sola lettura di grandi dimensioni, inserirli in un tablespace di sola lettura può ridurre notevolmente il tempo e lo spazio necessari per i backup. Di nuovo, tuttavia, questo non è particolarmente comune nella pratica al di fuori dei data warehouse.
• Se l'applicazione può essere eseguita senza un sottoinsieme di oggetti, può essere utile creare spazi tabella separati in modo da poterne eseguire uno offline e eseguire un ripristino a livello di spazio di tabella. Ancora una volta, però, poche applicazioni potrebbero essere eseguite senza un set di oggetti - se perdi lo spazio tabella indice, ad esempio, l'applicazione è probabilmente morta come se avessi perso tutto.
• Se si dispone di un numero elevato di tabelle vuote o per lo più vuote e un numero di tabelle molto grandi, è possibile che gli spazi tabella separati con diverse politiche di allocazione dell'entità siano preferibili dal punto di vista dell'utilizzo dello spazio. Ciò accade occasionalmente con le app in pacchetto in cui una determinata installazione utilizza una percentuale relativamente piccola delle tabelle disponibili e non si desidera che a ciascuna delle tabelle vuote venga assegnata un'estensione relativamente grande. Con la gestione automatica dell'estensione in un tablespace gestito localmente, questo tende a non essere una preoccupazione importante, potrebbe essere più preoccupante se si desidera utilizzare estensioni uniformi.
• Se oggetti diversi hanno priorità diverse per le prestazioni del disco e sono disponibili diversi tipi di dischi, i tablespace separati possono consentire di inserire oggetti diversi su diversi set di dischi. In un data warehouse, ad esempio, potresti voler inserire dati più vecchi su un disco più lento e più economico e dati più recenti su un disco più costoso. Questo non succede molto con le applicazioni OLTP.

A meno che la richiesta non ricada in uno di questi casi speciali, l'unico vantaggio di avere spazi tabella separati è fare appello al senso dell'organizzazione di DBA. Personalmente, sono più che felice di essere in grado di evitare di specificare un nome tablespace ogni volta che creo un oggetto o di passare cicli spostando oggetti dallo spazio tabelle "errato" quando vengono inevitabilmente creati nello spazio tabella predefinito erroneamente. Personalmente, non sono eccessivamente preoccupato se alcune decine di MB di spazio vengono "sprecate" quando si utilizzano tablespace gestiti localmente con gestione automatica dell'estensione su un insieme ottimizzato a mano di tablespace con dimensioni di estensione uniformi differenti. D'altra parte, i buoni DBA tendono ad essere molto preoccupati per le cose organizzate "proprio così", quindi non mi oppongo militivamente se un DBA vuole avere spazi di tabelle di indice e dati separati solo perché questo fa appello al senso estetico di qualcuno.

Answer 2

Vedi http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/tspaces.htm

Vedere http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/physical.htm

È possibile utilizzare più spazi tabelle per eseguire le seguenti operazioni:

di controllo dello spazio su disco di allocazione per dati del database

assegnare quote di spazio specifico per gli utenti del database

la disponibilità di controllo dei dati prendendo singoli spazi tabelle online o offline

Eseguire il backup del database parziale o recupero operazioni

assegnare memoria di dati tra dispositivi per migliorare le prestazioni

Answer 3

S. Lott ha già fornito una buona lista di motivi generali per cui si potrebbe voler dividerlo su più tablespace.

più specifico per la tua situazione ...

mi chiedo se ci sono motivi specifici per cambiare le cose ora. Non è un compito piccolo quello di fare un cambiamento strutturale come quello. Ci sono problemi di prestazioni? Stai andando contro i limiti di spazio di archiviazione? Hai bisogno di assegnare quote di spazio? Il tuo attuale piano di backup e ripristino soddisfa le tue esigenze?

Se si potesse tornare indietro nel tempo e ripetere le cose dall'inizio si vorrebbe certamente pianificare di dividere sensibilmente il database in diversi tablespace. Ma ne vale la pena ora?

Answer 4

Un motivo per l'utilizzo di tablespace diversi sarebbe il desiderio di utilizzare il trasporto di tablespace per lo spostamento di dati tra database. Se si dispone di un insieme limitato di dati che si desidera spostare senza doverli esportare e importare, il trasporto spazio tabelle è una buona opzione, in particolare se per motivi di verifica è importante che i dati abbiano esattamente la stessa struttura fisica del sistema di origine (per il lavoro di analisi delle prestazioni, ad esempio).

Answer 5

Sono fortemente in disaccordo con la valutazione di Justin Caves. Un DBA di produzione probabilmente avrebbe un'opinione molto diversa.

Sono disponibili spazi tabelle trasportabili per spostare sottoinsiemi dei dati tra database, senza dover spostare l'intero database.

tablespace di sola lettura, quindi non si esegue il backup dell'intero database ogni settimana, il che potrebbe richiedere molte ore e non si può sopportare il calo di prestazioni per quel periodo di tempo, anche se si limita la velocità.

esegue il backup solo di determinati tablespace a date fisse a causa della dimensione pura, anche se molti posti non dispongono di database così grandi. lo stesso motivo del punto precedente.

A seconda dell'applicazione, diciamo che ci sono moduli che possono funzionare indipendentemente l'uno dall'altro sul lato dell'applicazione.Se ognuno di essi ha il proprio set di spazi tabella, è possibile portare offline uno spazio tabella app per eseguire una reorg senza influire sugli altri moduli ... possono essere eseguiti normalmente.

come per la separazione di dati e indici: il motivo tradizionale era di mettere i due su dischi diversi in modo che non fossero in competizione tra loro. Non tanto un problema con le funzionalità di archiviazione di oggi, come SAN, dove è tutto lo stesso spazio di archiviazione, ma c'è ancora la considerazione che si otterrà contesa a livello di intestazione del file anche con tablespace gestiti localmente se si Hai tutti i tuoi oggetti nello stesso tablespace in cui non puoi separare localmente gli indici dai tavoli !! Anche se si creano 20 file di dati in un tablespace, non si arriva a decidere dove vanno le tabelle e gli indici, e poi un giorno si nota che si ha una contesa maggiore a livello di intestazione del file a causa della massiccia attività contro il tavolo dove sono gli indici capita di essere nello stesso file di dati! In effetti lo scarto. se hai solo un ts, allora lo corrisponderà a senza dubbio a contesa sull'intestazione del file.

ci sono più motivi per avere quella separazione logica, e no, non si tratta di prestazioni per la maggior parte, si tratta più dell'amministrazione in un ambiente di produzione.