Oggi tratto un argomento vecchio, benché Oracle 10g e Data Pump siano stati rilasciati da molti anni e questa utility per esportare su file parti di database sia stabile, comoda e flessibile, mi capita ancora di dover maneggiare file di dump creati con le vecchie versioni del programma di export di Oracle, se non altro perché ho ancora a che fare con database versione 9.2
Più per tradizione e per adeguarci alla richiesta di molti clienti anche noi applichiamo tutt’ora la classica suddivisione di tablespace per i dati e per gli indici, pur non vedendo alcun motivo scientifico per fare ciò. Quando però si fanno export/import di tipo tradizionale, e si vuole mantenere tale suddivisione ma con nomi di tablespace diversi la cosa non è immediata. Con datapump è stato introdotto il comodissimo parametro REMAP_TABLESPACES, ma sul vecchio import non c’è una soluzione diretta, se non ci sono tablespace con lo stesso nome del database di origine, gli oggetti vengono creati sul tablespace di default dello schema su cui si importano gli oggetti. Le tecniche per ovviare a ciò sono diverse, ma ieri ne ho collaudata una che non avevo mai provato e che però mi è sembrata molto comoda, la riassumo brevemente:
1) impostazione per l’utente/schema della tablespace di default quella dei dati (tabelle)
2) importazione del dump senza indici, ovvero con parametro INDEXES=no
3) impostazione per l’utente/schema della tablespace di default quella degli indici
4) importazione del dump senza dati, quindi con parametro ROWS=no IGNORE=yes INDEXES=yes
il parametro IGNORE=yes fa si che l’import non termini con errore perché trova gia le tabelle.
In passato una delle tecniche che ho utilizzato è stata quella di utilizzare il parametro INDEXFILE per generare su file i DDL degli indici, modificare il file opportunamente e lanciare da sqlplus la creazione degli indici, oppure importare tutto e poi spostare gli indici ma quest’ultimo è sicuramente il metodo più scomodo perché richiede di allocare più spazio nella tablespace dei dati e un po’ di manovre per generare lo script di spostamento per tutti gli indici.
Oracle and other 
C’è da dire che, con entrambi i sistemi, gli indici associati a primary/unique keys vengono comunque creati nella tablespace di default dell’utente.
Mi capita anche a me ogni tanto di dover trattare con dump fatti con exp. Un sistema comodo che evita anche la questione constraints, disponibile però solo da Oracle10g, è rinominare preventivamente le tablespaces in cui dovranno finire gli oggetti, con i nomi delle tablespaces di origine (e finito il lavoro ri-rinominare).
Questo sistema non si adatta certo a tutte le situazioni, e richiede che il database target sia almeno 10g.
Ciao,
vorrei dirti che apprezzo molto il tuo sito, la semplicita’ con cui affronti e comunichi i problemi e le soluzioni che trovi, la tua capacita’ di rapportarti con gli altri.
Sono molto contento di leggere cio’ che tu fai ma soprattutto come tu ti rapporti.
Cordiali saluti da un “collega” che all’eta’ di 71 lavora ancora su oracle e ha fatto consulenza e porting di oracle dalla release 3.1
lottini
Ringrazio moltissimo per i compliementi e ricambio per la notevole esperienza!