Kosmous beyond the clouds: Sviluppo, Formazione e Consulenza Informatica

Oracle DBA 9i - Cap. 7

In questa parte del corso analizzeremo una delle strutture più importanti per un DBA: i Tablespaces e la gestione dello spazio fisico che accoglie i dati.
Cominceremo dai Tablespace e poi ci addentreremo sempre più nel dettaglio passando per i Datafiles, i Blocchi, gli Extents, i Segments ed infine vedremo uno degli oggetti più importanti: le Tabelle.

Il Tablespace è un contenitore logico, visibile solo da Oracle, costituito fisicamente da uno o più files chiamati DATA-FILES (DF). Il Sistema Operativo vede solamente i Data Files, mentre Oracle gestisce sia i data files che il loro raggruppamento logico.

Il Tablespace può essere visto come una parte dell'intero database, un suo sottoinsieme.
Il database più piccolo potrebbe essere costituito da un solo tablespace, SYSTEM, che è l'unico tablespace sempre presente in qualunque database Oracle in quanto riveste un ruolo particolarmente importante: è il contenitore fisico del Data Dictionary (DD), cioè di tutti gli oggetti del database necessari al funzionamento dello stesso.
Ad esempio contiene la tabella degli utenti, con tutte le informazioni relative quali login e password, contiene la tabella con l'elenco di tutti i files del database, la tabella con l'elenco di tutti gli oggetti del database, la tabella con tutti i privilegi assegnati agli utenti e così via.

Generalmente un database Oracle è costituito anche da altri tablespaces che permettono di suddividere fisicamente gli oggetti in esso memorizzati. Ad esempio esisterà un tablespace che conterrà gli oggetti degli utenti (USERS), un altro che conterrà gli indici (INDX), un altro per gli oggetti temporanei (TEMP), un altro per i RollBack Segments (UNDO) e così via. Ma mentre questi ultimi possono esistere o meno, e possono avere un qualsivoglia nome, SYSTEM invece deve sempre esistere.

A livello funzionale, la presenza di più tablespace è importantissima. Mi permette infatti di suddividere il database in più unità, ognuna della quale conterrà solo elementi tra loro correlati. Poiché ogni tablespace fisicamente è costituita da almeno un DF, ho la possibilità di appoggiarmi fisicamente a files diversi, che posso decidere di memorizzare su dischi differenti al fine di migliorare le prestazioni complessive del database: se il database è correttamente progettato i dati verranno fisicamente memorizzati su DF distinti posizionati su un certo numero di Hard Disks, i quali lavoreranno in contemporanea, migliorando le performance del Db, per soddisfare le query lanciate.
Per ogni utente posso inoltre stabilire su quale tablespace egli potrà creare oggetti, e quanto spazio massimo utilizzare, permettendo un controllo globale molto preciso.
Tali impostazioni sono tra l'altro trasparenti per gli utenti, i quali possono ignorare totalmente dove verranno fisicamente memorizzati i loro oggetti, dando loro eventualmente la possibilità di scegliere a livello di tablespace.

Riassumendo i vantaggi di avere più tablespace :

  • Separazione del DD dagli altri dati, e quindi riduzione delle contese di accesso a disco (se ovviamente ho separato i DF che costituiscono i vari tablespaces mettendoli su dischi diversi).
  • Gestione delle quote per singolo utente, in quanto posso fissare il limite massimo di spazio su singolo tablespace che un utente può utilizzare.
  • Gestione più efficiente degli oggetti temporanei (ad esempio per le grosse operazioni di Sort) che vengono trattati solo su uno specifico tablespace, in genere TEMP.
  • Gestione più efficiente dei Segmenti di Roll Back (tablespace UNDO), che sono i dati necessari a permettere l'utilizzo del comando "RollBack"
  • Gestione più efficiente delle applicazioni che usano lo stesso database: se infatti raggruppo le applicazioni usando un tablespace diverso per ognuna, in caso di manutenzione, una parte delle applicazioni potrebbero non funzionare (quelle che si appoggiano ai tablespaces in manutenzione o recovery) mentre le altre non risentono del disservizio.
  • Posso gestire le operazioni di Back Up e Recovery per singolo tablespace
  • Posso rendere una parte del tablespace Read-Only, prevenendone modifiche accidentali.
Prima di proseguire con l'approfondimento dei tablespaces, accenniamo brevemente alle altre strutture fisiche, che verranno trattate in maniera approfondita nei capitoli successivi, allo scopo di fornire una panoramica generale che permetta di comprendere meglio alcuni concetti affrontati in questo capitolo.

All'estremo opposto della gerarchia, rispetto ai tablespaces, stanno i blocchi (blocks, vedi la seconda figura del capitolo 1). Il blocco è l'unita minima di allocazione gestibile da Oracle. All'interno dei blocchi verranno memorizzati i record delle tabelle. I blocchi vengono allocati su file in insiemi chiamati Extents. Un Extent (ext) non è altro che un insieme di blocchi contigui.
Gli extents a loro volta vengono raggruppati in Segments. Un Segment, costituito da extent anche non contigui, corrisponde ad un oggetto (object).
Quando si crea una tabella in un tablespace, Oracle allocherà su uno o più DF del tablespace un segment, cioè un insieme di extent, aventi certe dimensioni, e costituiti a loro volta da un insieme di blocchi contigui. A mano a mano che verranno inseriti records all'interno della tabella, essi verranno memorizzati all'interno dei blocchi appartenenti al segment. Quando tutti i blocchi allocati nel segments saraano pieni di dati, Oracle allocherà su uno dei DF del tablespace dei nuovi extents.

Dopo questa breve premessa, ritorniamo al nostro Tablespace.

Al momento della creazione di un tablespace viene fisicamente allocato sul filesytem un DF, avente la dimensione specificata. Tale DF sarà inizialmente vuoto, ma verrà strutturato in modo da ospitare i futuri oggetti che verranno creati in esso. Oracle 9i ha due modalità per gestirne lo spazio interno, memorizzando le informazioni nel DD oppure all'interno del tablespace stesso. Pertanto, in funzione della modalità scelta posso suddividere i tablespaces in:

DICTIONARY-MANAGED:
Le informazioni necessarie per la gestione dello spazio (come la dimensione degli extents, lo spazio libero, quello in uso etc.) sono memorizzate nel DD. Ciò implica che ad ogni modifica dello stato di un blocco viene eseguito un update su una specifica tabella del DD. Tale operazione implica l'ulteriore creazione di una informazione di UNDO, necessaria per un eventuale Rollback.
Questo tipo di tablespace è l'unico disponibile nelle versione precedenti ad Oracle 9i.

LOCALLY-MANAGED:
Le informazioni necessarie per la gestione dello spazio sono memorizzate nel tablespace stesso, in genere nell'header di ogni singolo DF, utilizzando una matrice di bitmaps.
Ogni bit della matrice corrisponde ad un blocco o ad un gruppo di blocchi, indicando se il blocco è utilizzato o è libero.
Se un blocco cambia il suo stato, la modifica non genera informazioni di UNDO, in quanto non viene eseguito nessun update su tabelle del DD.
Questo tipo di tablespace permette quindi di avere prestazioni superiori, ma posso utilizzarlo solo a partire da Oracle 9i.


7.1 Creazione di un Tablespace

La creazione di un nuovo tablespace avviene utilizzando il comando CREATE TABLESPACE seguito da una serie di clausole e parametri. Di essi l'unico obbligatorio è il nome del tablespace, mentre tutto il resto posso ometterlo, nel qual caso verranno usati dei valori di default:
Il tablespace sarà di tipo locally-managed, la gestione degli extents verrà fatta in maniera automatica, verrà creato un DF all'interno della directory specificata dal parametro DB_CREATE_FILE_DEST, avente un nome fisico tipo "ora_applicat_zyykpt00.dbf" e dimensione pari a 100MB. Il DF avrà inoltre abilitata l'opzione Autoextent On, cioè sarà libero di crescere automaticamente finchè c'è spazio nel filesystem.

Il nome del tablespace dovrà inoltre sottostare alle regole standard di nomenclatura, e cioè dovrà essere formato da un massimo di 30 caratteri, di cui il primo deve essere una lettera, e potrà contenere i soli caratteri speciali #, _ e $.

Se invece volessi specificare manualmente le varie opzioni, dovrò usare la sintassi di seguito indicata. Per comodità del lettore, in questo manuale Oracle 9i abbiamo preferito distinguere le sintassi utilizzabili per categorie. La prima categoria che analizzeremo riguarda la gestione di un Tablespace Dictionary Managed.

E' doveroso fare una precisazione: se il tablespace SYSTEM è di tipo Locally managed, non è possibile creare tablespace di tipo Dictionary.

7.1.1 Dictionary Managed

Sintassi:

CREATE TABLESPACE nome_tablespace 
	DATAFILE 'nome_df' SIZE nn[K|M] 
	DEFAULT STORAGE ( 
			INITIAL nn[K|M]
			NEXT nn[K|M]
			MINEXTENTS n 
			PCTINCREASE n 
			MAXEXTENTS n) 
	BLOCKSIZE nK 
	MINIMUM EXTENT nn[K|M]
	LOGGING 
	ONLINE 
	PERMANENT 
	EXTENT MANAGEMENT DICTIONARY;

Dove:
DEFAULT STORAGE
Indica i parametri con cui verranno fisicamente memorizzati gli oggetti creati dentro questo tablespace se non vengono esplicitamente specificati all'atto della creazione. Essi sono:

    INITIAL
    Indica la dimensione del primo extent allocato per l'oggetto, dimensione espressa in byte, ma posso usare anche K (per Kb) e M (per Mb).
    Il valore di default è pari alla dimensione occupata da 5 blocchi, mentre il valore minimo è di 3 blocchi per i tablespace locally-managed (2 blocchi + 1 per ogni freelist group del segmento) e 2 blocchi per dictionary-managed.
    Se specifico un valore inferiore, Oracle usa lo stesso il valore minimo, ignorando quindi il parametro.

    NEXT
    Indica la dimensione del secondo extent allocato, espressa anche in questo caso in byte o Kb (devo usare K) o Mb (devo usare M). Il valore di default è 5 blocchi, mentre il valore minimo è 1 blocco.

    PCTINCREASE
    A partire dal terzo extent in poi, la dimensione viene calcolata basandosi sulla dimensione dell'ultimo extent allocato per quell'oggetto, aumentata di una percentuale pari al valore specificato da questo parametro. Il default è 50 (tranne per i Segmenti di rollback), mentre valore minimo è 0, che significa che tutti gli extent avranno la stessa dimensione.
    In ogni caso, qual che sia la dimensione esplicitamente impostata o calcolata, la dimensione effettiva di ogni extent allocato è arrotondata ad un multiplo della dimensione del blocco.

    MINEXTENTS
    Indica il numero iniziale di extents che devono essere allocati al momento della creazione degli oggetti. Tutti gli extents successivi verranno allocati automaticamente man mano che vengono inseriti records nell'oggetto, riempiendo gli extent già allocati.
    Il valore di default coincide col valore minimo è pari a 1.

    MAXEXTENTS
    Indica il numero massimo di extents che possono essere allocati per l'oggetto. Il valore minimo è 1, mentre il default dipende dalla dimensione del blocco.
    Il parametro può assumere anche il valore UNLIMITED, che significa che l'oggetto può crescere senza limiti fintanto che nel tablespace c'è spazio sufficiente per allocare extents.

    MINIMUM EXTENT
    Per limitare la frammentazione all'interno dei DF che costituiscono un tablespace, posso limitare la dimensione degli extents a valori prefissati: in questo modo tutti gli extents avranno una dimensione che è un multiplo del valore specificato dal parametro. Anche INITIAL e NEXT devono essere multipli di tale valore.

BLOCKSIZE
Indica la dimensione del blocco da usare, e se non viene specificato viene usato il valore di DB_BLOCK_SIZE. I valori che posso utilizzare sono 2K, 4K, 8K , 16K e 32K, ma devo prevedere all'interno della SGA lo spazio per gestirli, tramite parametro DB_nK_CACHE_SIZE con n uguale alla dimensione del blocco usato.
NB: i tablespace di tipo temporary devono avere la dimensione dei blocchi standard.

LOGGING
Serve per forzare la scrittura sui RLF delle operazioni DDL e degli INSERT con Direct-load. Tuttavia se utilizzo la clausola NOLOGGING nei singoli comandi, essa prende priorità rispetto alle impostazioni di default del tablespaces. Se non volessi permettere ai singoli comandi di avere la priorità, posso forzare il tablespace con FORCE LOGGING.
LOGGING è il default, se non lo voglio specifico NOLOGGING.

ONLINE
Anche questo è il default, ed indica che il tablespace è subito disponibile per memorizzare oggetti. L'alternativa è l'utilizzo di OFFLINE.

PERMANENT
Indica che il tablespace conterrà oggetti permanenti come le tabelle, ed è il valore di default.
Altrimenti posso specificare TEMPORARY, nel quale non posso creare oggetti permanenti.

EXTENT MANAGEMENT
Indica se voglio la gestione Locally o Dictionary Managed. Il default è LOCALLY, ma in questa sezione stiamo vedendo le clausole e le opzioni del caso DICTIONARY.

SEGMENT SPACE MANAGEMENT
posso usare questa opzione solo con i Locally-Managed. Può assumere due valori:
    MANUAL che è il default
    AUTO che implica la gestione dello spazio libero tramite bit maps invece che freelist. In questo caso vengono ignorati eventuali parametri di storage (come PCTUSED, FREELIST e FREELIST GROUPS).
Esempio:

CREATE TABLESPACE APPL_DATA 
	DATAFILE 'c:oradataorclappl_data01.dbf' SIZE 100M 
	DEFAULT STORAGE ( 
			INITIAL 256K 
			NEXT 256K 
			MINEXTENTS 2 
			PCTINCREASE 0 
			MAXEXTENTS 4096) 
	BLOCKSIZE 4K 
	MINIMUM EXTENT 256K 
	LOGGING 
	ONLINE 
	PERMANENT 
	EXTENT MANAGEMENT DICTIONARY ;


7.1.2 Locally Managed


Sintassi:
CREATE TABLESPACE nome_tablespace 
	DATAFILE 'nome_df' SIZE nn[K|M] 
	BLOCKSIZE nK 
	MINIMUM EXTENT nn[K|M]
	LOGGING 
	ONLINE 
	PERMANENT 
	EXTENT MANAGEMENT LOCAL 
AUTOALLOCATE | UNIFORM [ SIZE n [K|M]]
SEGMENT SPACE MANAGEMENT { MANUAL | AUTO };
Innanzi tutto si noti la mancanza della clausola DEFAULT STORAGE. Nella realtà potrei utilizzare anche le clausole di Default Storage insieme con EXTENT MANAGEMET LOCAL, Oracle non restituisce un errore, ma semplicemente le ignora impostando in automatico determinati valori per gli altri parametri. Si consiglia di consultare la documentazione ufficiale (SQL Reference, Capitolo sul Create Tablespace) per approfondire tale argomento.


I parametri che differiscono sono:

AUTOALLOCATE
E' il default per la gestione degli extent, che vengono gestiti automaticamente da Oracle sia in numero che in dimensione.

UNIFORM
In alternativa ad AUTOALLOCATE posso usare UNIFORM che implica che tutti gli exents avranno la stessa dimensione, pari al valore specificato con size. Se non valorizzo SIZE, verrà utilizzato il default che è pari ad 1 Mb.

SEGMENT SPACE MANAGEMENT
Questo parametro serve a specificare come deve essere gestito lo spazio libero ed usato di ogni singolo oggetto, e può assumere due valori:
    MANUAL: Vengono usate le freelists, ed è il default.
    AUTO: Vengono usati i bitmaps

La freelist è un elenco dei blocchi liberi che viene consultato ogni volta che viene eseguito un INSERT sulla tabella. Ciò implica che se vengono eseguiti molti INSERT in contemporanea, la consultazione del Freelist potrebbe rappresentare un collo di bottiglia. In questo caso è possibile creare più freelist su una singola tabella, oppure utilizzare i bitmaps dell'opzione AUTO.
Nel caso dell'utilizzo di AUTO, le opzioni della tabella FREELISTS, FREELISTS GROUP e PCTUSED perdono di validità.

Esempio:

CREATE TABLESPACE APPL_DATA 
	DATAFILE 'c:oradataorclappl_data01.dbf' SIZE 100M 
	BLOCKSIZE 4K 
	MINIMUM EXTENT 256K 
	LOGGING 
	ONLINE 
	PERMANENT 
	EXTENT MANAGEMENT LOCAL
	UNIFORM SIZE 256K 
SEGMENT SPACE MANAGEMENT AUTO;

7.1.3 Temporary Tablespace

Un particolare tipo di tablespace è il TEMPORARY. Esso serve per permettere ad Oracle di memorizzare dati od oggetti temporaneamente, facendo una sorta di SWAP ogni qual volta la Ram a disposizione non è sufficiente.
L'utilizzo più frequente avviene durante le operazioni di ordinamento (SORT) necessarie per eseguire certe query. All'interno del tablespace viene creato un Segment particolare, chiamato SORT SEGMENT, condiviso da tutti gli utenti del Db, e costituito da un certo numero di extents (ogni transazione userà un extent in maniera esclusiva). Tale segment viene allocato nel momento della prima operazione di sort.
Non è possibile creare esplicitamente oggetti al suo interno.

La sintassi per creare un tablespace temporaneo è leggermente diversa a secondo se si tratti di Dictionary (è il default) o Locally Managed.

DICTIONARY:

SQL> CREATE TABLESPACE TEMP 
DATAFILE 'c:oradataorcltemp01.dbf' SIZE 200M 
          DEFAULT STORAGE (INITIAL 1M 
                           NEXT 1M  
                           PCTINCREASE 0 
                           MAXEXTENTS UNLIMITED) 
          TEMPORARY;

NB: INITIAL e NEXT devono esseri uguali, e la loro dimensione deve essere un multiplo di SORT_AREA_SIZE aumentato di DB_BLOCK_SIZE per evitare frammentazione.
PCTINCREASE invece deve essere pari a 0.

Esempio:
SORT_AREA_SIZE= 64KB e BLOCK_SIZE=8KB.
Allora posso impostare:
INITIAL = n x 64 + 8 = 2 x 64 + 8 = 128 + 8 = 136KB

LOCALLY:

Posso creare un tablespace temporary Locally-managed usando il comando:

SQL> CREATE TEMPORARY TABLESPACE TEMP 
	TEMPFILE 'c:oradataorcltemp01.dbf' SIZE 300M 
	EXTENT MANAGEMENT LOCAL 
	UNIFORM SIZE 5M;

Da notare la presenza di "TEMPORARY" subito dopo il CREATE e l'uso di TEMPFILE al posto di DATAFILE.

La clausola EXTENT MANAGEMENT LOCAL è opzionale è può essere omessa (si specifica solo per leggibilità).
Se non viene specificata clausola UNIFORM SIZE, viene impostato default ad 1Mb


7.1.4 Undo Tablespace


Questo tipo di tablespace viene utilizzato internamente per consentire l'operazione di ROLLBACK. Oracle memorizza temporaneamente nel tablespace i dati che vengono modificati, permettendo di annullare le transazioni terminate erroneamente od esplicitamente dagli utenti. Tratteremo questo argomento in maniera più approfondita più avanti.

La creazione di questo tablespace può essere fatta contestualmente alla creazione del Db (CREATE DATABASE) mediante la clausola …UNDO TABLESPACE …, oppure utilizzando la sintassi vista nei paragrafi successivi, utilizzando la clausola UNDO:

SQL> CREATE UNDO TABLESPACE UNDOTBS
	DATAFILE 'c:oradataorclundotbs01.dbf' SIZE 200M;
NB: A partire dalla versione Oracle 9i, se all'atto del CREATE DATABASE non viene esplicitamente indicato il tablespace UNDO, ne verrà creato automaticamente uno avente il nome SYS_UNDOTBS.
Se all'avvio dell'istanza non viene individuato un tablespace di UNDO verrà utilizzato il RollBack Segment "SYSTEM" presente nel Tablespace SYSTEM, evento particolarmente sconsigliabile.

7.2 Alter Tablespace

Dopo aver creato un tablespace, posso modificarne alcune caratteristiche utilizzando il comando ALTER TABLESPACE. Tra le operazioni permesse ricordiamo:

  • aggiungere nuovi DF o TF (Temporary files);
  • rinominare i files ;
  • modificare i parametri di storage dei tablespace dictionary-managed;
  • modificare l'allocazione degli extents.
  • modificare disponibilità del tablespace (ONLINE - OFFLINE);
  • mettere il tablespace in modalità BACKUP;
  • passare da READ-ONLY a READ-WRITE e viceversa;
  • passare da LOGGING a NOLOGGING e viceversa.
  • passare da PERMANENT a TEMPORARY e viceversa. Tale operazione ha alcune limitazioni: nel caso dei dictionary-managed, il tablespace non deve contenere dati ed inoltre la dimensione dei blocchi deve essere standard. Se è locally-managed posso solo passare da temporary a permanent (utilizzando il comando ALTER TABLESPACE … TEMPORARY), ma non posso fare contrario.
Non posso:
  • specificare più clausole contemporaneamente in ALTER TABLESPACE, dovrò eventualmente lanciare più comandi separati;
  • passare da locally a dictionary managed e viceversa.

7.2.1 Online - Offline

Vediamo qualche dettaglio sulla disponibilità (ONLINE, OFFLINE).
Mettere un tablespace offline significa che il suo contenuto diviene temporaneamente inaccessibile. Inoltre Oracle rilascia i Lock detenuti sui rispettivi files del Sistema Operativo, permettendo la loro cancellazione e/o spostamento e/o sostituzione. Tale operazione viene infatti utilizzata durante le fasi di ripristino del singolo tablespace. Il comando è:
SQL> ALTER TABLESPACE users OFFLINE  [modalità];
dove modalità può essere:

NORMAL I dirty buffer vengono scaricati prima di mettere tablespace offline, quindi i DF devono essere online e raggiungibili affinché il comando abbia esito positivo. Non necessito del recovery se lo riporto online.
SQL> ALTER TABLESPACE users OFFLINE NORMAL;
TEMPORARY
Viene eseguito il Checkpoint di tutti DF online. Viene eseguito anche se qualche DF del tablespace è offline, nel qual caso, quando lo riporto online, necessito del recovery di quei files

IMMEDIATE
Non viene eseguito il checkpoint e non viene controllato che i DF siano online. Necessito del recovery quando lo riporto online.

FOR RECOVER
Questa opzione è rimasta per compatibilità con le versioni precedenti. Con questa clausola Oracle mette il tablespace offline per eseguire un point-in-time recovery, quindi dovrò prendere i files da precedente BK ed applicarvi gli ARLF


7.2.2 Read Only - Read Write


A volte può essere utile mettere un intero tablespace in modalità READ ONLY, per evitare di modificare accidentalmente gli oggetti in esso memorizzati. In questo modo non possono più essere eseguiti comandi di INSERT, DELETE e UPDATE.
Gli header dei DF non vengono più aggiornati dal checkpoint.
Per poter trasformare un tablespace in Read-only non devo avere transazioni pendenti su di esso, altrimenti il tablespace viene messo in uno stato di transizione, e non posso eseguire nessun altro comando DML tranne Commit o Rollback.
Attenzione perché è comunque possibile cancellare gli oggetti esistenti (tabelle ed indici).
SQL> ALTER TABLESPACE user READ ONLY;
Per riportarlo nello stato normale, cioè READ WRITE uso:
SQL> ALTER TABLESPACE user READ WRITE;
Un tablespace Read-only potrebbe anche essere memorizzato su un CDROM, ed è inoltre possibile evitare il controllo sulla disponibilità dei suoi DF all'avvio del Database: basta impostare il parametro READ_ONLY_OPEN_DELAYED=TRUE. In questo modo il controllo sulla disponibilità degli oggetti, e quindi dei DF, viene fatto solo quando viene eseguito accesso ad un oggetto in esso contenuto.

7.2.3 Aggiungere un DF

Per aggiungere un DF ad un tablespace esistente si utilizza il comando:

SQL> ALTER TABLESPACE nome ADD [ DATAFILE | TEMPFILE ]
	'c:oracleoradatanomefile03.dbf' SIZE 10M;
Attenzione perché non è possibile togliere un DF da un tablespace, per cui in caso di errore dovrò ricorrere a altri strumenti (come imp ed exp) per eseguire un backup del tablespace, distruggerlo e ricrearlo correttamente. In alternativa si potrebbe ridurre la dimensione del DF (RESIZE) ad un valore prossimo allo 0, ma bisogna sempre tenere il file, soluzione non proprio ottimale.


7.2.4 Cancellare un Tablespace

Per cancellare un Tablespace posso usare il comando:
SQL> DROP TABLESPACE USER;
Se il tablespace non è vuoto ma contiene oggetti, devo usare:
SQL> DROP TABLESPACE USER INCLUDING CONTENTS;
Se nel tablespace ci sono constraints (FK) devo usare:
SQL> DROP TABLESPACE USER INCLUDING CONTENTS CASCADE CONSTRAINTS;
Infine, se volessi eliminare anche i DF dal SO, e non sto usando OMF, utilizzo:
SQL> DROP TABLESPACE USER INCLUDING CONTENTS AND DATAFILES;


7.2.5 Ricavare informazioni sui Tablespaces



Tra le tante viste consultabili per ricavare informazioni sui tablespace evidenziamo:

DBA_TABLESPACES & USER_TABLESPACES
Da esse ricavo informazione sullo stato fisico come i parametri di storage, la dimensione dei blocchi, degli extents, etc.

V$TABLESPACE
Ricavo informazioni sullo stato di backup. Posso metterla in relazione con V$DATAFILE per ricavare da quali DF sono costituiti i vari tablespaces, oppure posso utilizzare la DBA_DATA_FILES

DBA_FREE_SPACE
Utile per avere informazioni sugli Extent liberi in tutti i tablespaces.

USER_FREE_SPACE
Coma la DBA_FREE_SPACE, ma si riferisce allo spazio libero accessibile dall'utente che ha eseguito la query.


V$SORT_USAGE
Utile per ricavare informazioni sulle operazioni di SORT attive. Da utilizzare in Join con V$SESSION o V$SQL


DBA_SEGMENTS & USER_SEGMENTS
Utile per ricavare informazioni sui Segments, come la tipologia e la dimensione.


DBA_EXTENTS & USER_EXTENTS
Utile per ricavare informazioni sugli Extents

DBA_TEMP_FILES
Mostra i TF (temporary files) appartenenti ai locally-managed temporary tablespaces.

V$TEMP_EXTENT_MAP
Mostra informazioni sugli extents di un locally managed temporary tablespace.

V$TEMP_EXTENT_POOL
Mostra lo spazio temporary usato ed in cache per l'instanza corrente, per i locally managed temporary tablespaces.

V$TEMP_SPACE_HEADER
Mostra lo spazio usato e libero in ciascun temporary tablespace files.

V$SORT_SEGMENT
Mostra informazioni sui sort segments.

DBA_USERS
Mostra informazioni sui tablespace di default e temporary assegnati agli utenti.







Per commenti, eventuali segnalazioni di errore e quant'altro vi invitiamo ad inviarci una segnalazione all'autore: risorse@kosmous.com



Questo documento non è un documento ufficiale della Oracle Corporation. Oracle detiene tutti i diritti sulla propria documentazione. Alcuni termini usati sono trademarks registrati. In caso di dubbi o incertezze consultate la documentazione ufficiale di Oracle o contattate il Customer Support di Oracle.
<< Capitolo 6 Capitolo 8 >>
Commenti (1)2005-05-20

06/08/2012 - Andrea scrive:
Scusa, ma la vista DBA_USERS NON mostra le informazioni sui tablespace di default e temporary, ma mostra semplicemente le informazioni sugli tutti gli utenti presenti nel DB. E' una vista sugli utenti, non sui tablespace.