Nel caso di un database Oracle avere più di una tabella per la memorizzazione dei dati?

Question

La mia squadra mantiene un database Oracle che è circa. 200 GB di dimensione. Tutti i dati (tabelle, indici, ecc) vive all'interno di un unico spazio tabelle 'Utenti'. Si tratta di una cattiva idea? Quali vantaggi ci sono per avere più spazi tabella, e in quali circostanze dovrei voler aggiungere di più per il mio database?

Grazie!

Answer 1

Il mio bias (e questo è in gran parte una questione di preferenza personale) è che se non v'è alcun beneficio convincente per la creazione di spazi tabelle aggiuntive, la vita è più facile con un singolo spazio tabella.

• Non v'è alcun miglioramento delle prestazioni a mettere gli oggetti in diverse tabelle. C'è un vecchio mito che le tabelle di separazione e gli indici potrebbero avere alcuni vantaggi prestazionali. V'è un potenziale beneficio per la diffusione di I / O su tutti i mandrini disponibili, ma che è meglio fatto con più file di dati in un unico spazio tabelle poi con più spazi tabella in quanto Oracle fa un allocazione round-robin di extent in diversi file di dati partendo dal presupposto che il vostro isn SAN 't già facendo qualcosa per uniformare I / O.
• Se si dispone di grandi, tabelle di ricerca / cronologia statici, tali che si potrebbe portare una nuova copia del database per il sito del cliente, semplicemente portando gli spazi tabelle transazionali più piccoli, che sarebbe un motivo per considerare più spazi tabella. Ma ci sono pochissime applicazioni che hanno questo tipo di configurazione. Se dovrete portare tutti 200 GB, non importa quanti spazi tabelle che hai.
• Sulla stessa linea, se si dispone di grandi lettura solo oggetti, mettendoli in un tablespace di sola lettura può notevolmente ridurre il tempo e lo spazio necessario per i backup. Ancora una volta, però, questo non è particolarmente comune nella pratica di fuori dei data warehouse.
• Se l'applicazione potrebbe funzionare senza un qualche sottoinsieme di oggetti, ci può essere un vantaggio per la creazione di spazi tabelle separate, in modo che si potrebbe prendere una linea e fare un ripristino a livello di spazio tabella. Anche in questo caso, però, alcune applicazioni potrebbero funzionare senza un insieme di objects-- se si perde tabelle di indice, per esempio, l'applicazione è probabile altrettanto morti come se aveste perso tutto.
• Se si dispone di un gran numero di tavoli vuoti o per lo più vuote e una serie di tabelle molto grandi, spazi tabelle separate con diverse politiche di allocazione misura può essere preferibile dal punto di vista utilizzo dello spazio. Questo succede di tanto in tanto con le applicazioni pacchettizzate in cui un dato di installazione sta usando una relativamente piccola percentuale delle tabelle disponibili e non si vuole ciascuno dei tavoli vuoti per avere un relativamente grande misura ad esso assegnato. Con la gestione automatica di misura in un tablespace gestito localmente, questo tende a non essere una preoccupazione importante, può essere più preoccupante se si desidera utilizzare extent uniformi.
• Se oggetti diversi hanno priorità diverse per le prestazioni del disco, e si dispone di diversi tipi di disco disponibile, spazi tabelle separate possono permetterà di mettere oggetti diversi su diversi set di dischi. In un data warehouse, per esempio, si può decidere di mettere i dati meno recenti su lento, su disco più conveniente ed i dati più recenti sui più costoso disco. Questo non accade molto con le applicazioni OLTP.

A meno che la vostra applicazione rientra in uno di questi casi particolari, l'unico vantaggio di avere spazi tabelle separati è di fare appello al senso di un DBA di organizzazione. Personalmente, io sono più che felice di essere in grado di evitare di specificare un nome spazio tabella ogni volta che creo un oggetto o di trascorrere cicli di oggetti in movimento dal tablespace "sbagliato", quando inevitabilmente si creano nello spazio tabelle di default per errore. Personalmente, io non sono eccessivamente preoccupati se poche decine di MB di spazio sono "sprecati" quando si usa tablespace gestite a livello locale con gestione automatica misura su un insieme ottimizzato a mano delle tabelle con differenti formati misura uniformi. D'altra parte, le buone DBA tendono ad essere molto preoccupati per le cose che sono organizzati "solo così", così io non sono militante contrario se un DBA vuole avere indici e dati tabelle separati solo perché che fa appello al senso di qualcuno di estetica.

Answer 2

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

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

  

È possibile utilizzare più spazi tabella a   effettuare le seguenti operazioni:

     

allocazione controllo spazio su disco per   dati del database

     

Assegna quote di spazio specifici per   gli utenti del database

     

disponibilità di controllo dei dati da prendere   singoli spazi tabelle in linea o   offline

     

Esegui backup del database parziale o   operazioni di recupero

     

allocare l'archiviazione dei dati su tutti i dispositivi   per migliorare le prestazioni

Answer 3

Una delle ragioni per l'utilizzo di diverse tabelle sarebbe un desiderio di utilizzare i mezzi spazio tabella per lo spostamento dei dati tra i database. Se si dispone di un numero limitato di dati che si desidera spostare senza dover esportare e importare poi il trasporto tablespace è una buona opzione, soprattutto se è importante per motivi di test che i dati hanno esattamente la stessa struttura fisica come il sistema di origine ( per il lavoro di analisi delle prestazioni, per esempio).

Answer 4

Non sono d'accordo con la valutazione fortemente Justin Grotte. Un DBA produzione sarebbe probabilmente un parere molto diverso.

tablespace trasportabili presentano per lo spostamento di sottoinsiemi di dati tra database, senza dover spostare l'intero database.

di sola lettura tablespace in modo non sei il backup dell'intero database ogni settimana, che potrebbe richiedere molte ore, e non si può stare il calo di prestazioni per quel lasso di tempo, anche se il vostro limitando la velocità.

solo determinati spazi tabelle di backup a date fisse a causa della vastità, anche se molti luoghi semplicemente non hanno basi di dati così grande. stessa ragione come punto precedente.

A seconda dell'applicazione in uso, diciamo che ci sono moduli che possono funzionare indipendentemente l'uno dall'altro sul lato di applicazione. Se ognuno ha il proprio set di tabelle, si può prendere uno applicazioni spazi tabelle in linea di fare un reorg senza influenzare gli altri moduli ... possono funzionare come normale.

come per la separazione dei dati e gli indici: il motivo tradizionale era dell'immissione due diversi dischi in modo che non erano in concorrenza tra loro prestazioni saggio. Non tanto di un problema con le funzionalità di oggi di storage, come SAN, dove è tutto davvero la stessa area di stoccaggio, ma non v'è ancora la considerazione che si sta andando ad ottenere contesa a livello di intestazione del file anche con gestito localmente tablespace se hai tutti gli oggetti nello stesso spazio tabelle in cui non si può locigally separare gli indici dalle tabelle !! Anche se si crea 20 file di dati in uno spazio tabelle, non si arriva a decidere dove le tabelle e gli indici vanno, e poi un giorno ti accorgi che hai importante contesa a livello intestazione del file a causa di attività di massa contro il tavolo dove è indici capita di essere nella stessa file di dati! Infatti rottami che. se hai solo uno ts, allora senza esperienza dubbio intestazione del file contesa.

ci sono più motivi per avere quella separazione logica, e non, non è circa le prestazioni per la maggior parte, è più circa la somministrazione in un ambiente di produzione.

Answer 5

S. Lott già dato un buon elenco di motivi generali per cui si potrebbe desiderare di dividere che fino su più tabelle.

Più specifico per la tua situazione ...

Mi chiedo se ci sono motivi specifici per cambiare le cose ora. Non è un compito facile per fare un cambiamento strutturale del genere. Ci sono problemi di prestazioni? Sei in esecuzione sulla base dei limiti di spazio di archiviazione? Avete bisogno di assegnare le quote di spazio? Il tuo attuale di backup e ripristino piano di soddisfare le vostre esigenze?

Se si potesse tornare indietro nel tempo e rifare le cose fin dall'inizio si sarebbe certamente desidera pianificare dividere sensibilmente il database in diversi spazi di tabella. Ma ne vale la pena ora?