Oracle Data Pump: Export e Import con expdp e impdp

Quando si parla di gestione dei dati in ambienti Oracle, due strumenti emergono spesso per le operazioni di backup, ripristino e migrazione: Data Pump e RMAN. Sebbene entrambi siano fondamentali, le loro finalità e modalità operative sono distinte. Data Pump, con i suoi utility expdp e impdp, è la scelta privilegiata per le operazioni logiche, permettendo di esportare e importare schemi, tabelle o interi database a livello di oggetto, ideale per migrazioni tra versioni diverse di Oracle o per la creazione di ambienti di test. Ho usato Data Pump per migrare schemi complessi tra server, riducendo drasticamente i tempi di downtime e semplificando la gestione dei dati per un’organizzazione con centinaia di gigabyte di database.

Testato su: Oracle Database 19c · Oracle Linux 8 · Ottobre 2026

Data Pump o RMAN: a cosa serve ciascuno

Comprendere la differenza tra Oracle Data Pump e RMAN (Recovery Manager) è cruciale per scegliere lo strumento giusto per il compito. RMAN è un utility di backup e recovery a livello fisico. Opera sui file di dati, sui control file e sugli archivelog del database. È lo strumento primario per il backup completo o incrementale dell’intero database, per il recovery da un disastro e per la duplicazione di database (clonazione). RMAN è transazione-consistente e garantisce l’integrità dei dati a livello di blocco.

Data Pump, d’altra parte, è uno strumento per lo scarico e il caricamento logico dei dati. Lavora a livello di oggetti del database (schemi, tabelle, indici, stored procedures, ecc.). È l’ideale per:

• Migrazione di schemi o tabelle: Spostare oggetti da un database a un altro, anche tra versioni diverse di Oracle.
• Creazione di ambienti di sviluppo/test: Duplicare un sottoinsieme del database di produzione.
• Backup logici: Creare copie di sicurezza di dati specifici che possono essere poi importati in un ambiente diverso.
• Consolidamento di database: Unire più schemi da database diversi in un unico target.

La scelta dipende dalla natura dell’operazione: se hai bisogno di un backup fisico per il disaster recovery, usa RMAN; se devi spostare o duplicare dati a livello logico, Data Pump è la soluzione.

Creare la directory Oracle e dare i permessi

Prima di poter utilizzare expdp o impdp, è necessario definire una directory logica all’interno del database Oracle che punti a una directory fisica sul filesystem del server. Questa directory è dove Data Pump scriverà i file di dump e i log durante l’esportazione, o da dove leggerà i file di dump durante l’importazione. Non è possibile specificare percorsi arbitrari direttamente nei comandi expdp/impdp; si deve sempre fare riferimento a una directory Oracle predefinita.

Per creare una directory, connettiti come utente con privilegi SYSDBA o CREATE ANY DIRECTORY (ad esempio, system):

CREATE DIRECTORY dp_dir AS '/u01/export';

Questo comando crea una directory logica chiamata DP_DIR che punta al percorso /u01/export sul filesystem del server database. Assicurati che il percorso fisico esista e che l’utente del sistema operativo che esegue il processo Oracle abbia i permessi di lettura e scrittura su quella directory.

Successivamente, devi concedere i permessi di lettura e scrittura su questa directory all’utente o agli utenti che eseguiranno le operazioni expdp/impdp. Ad esempio, per l’utente SYSTEM:

GRANT READ, WRITE ON DIRECTORY dp_dir TO system;

Senza questi permessi, qualsiasi tentativo di eseguire expdp o impdp fallirà con errori relativi all’accesso alla directory. Leggi anche: Oracle DBA: Controlli Quotidiani con Output Reali

Esportare uno schema

L’esportazione di uno schema completo è una delle operazioni più comuni con Data Pump. Questo include tutte le tabelle, gli indici, le view, i trigger, le stored procedures e altri oggetti associati a quello schema. Il comando expdp offre molte opzioni per personalizzare l’esportazione.

Ecco un esempio per esportare lo schema APP nella directory dp_dir, generando file di dump con nomi basati su un pattern (app_%U.dmp) e un file di log, utilizzando 4 processi paralleli per velocizzare l’operazione:

expdp system/password@ORCLDB schemas=APP directory=dp_dir dumpfile=app_%U.dmp logfile=app_exp.log parallel=4

• system/password@ORCLDB: Credenziali dell’utente con privilegi sufficienti.
• schemas=APP: Specifica lo schema da esportare.
• directory=dp_dir: La directory Oracle definita in precedenza.
• dumpfile=app_%U.dmp: Il nome del file di dump. %U è un placeholder che Data Pump sostituisce con un numero sequenziale se si usa il parallelismo, creando app_01.dmp, app_02.dmp, ecc.
• logfile=app_exp.log: Il file dove vengono registrate tutte le informazioni sull’esportazione.
• parallel=4: Indica a Data Pump di utilizzare 4 processi worker per l’esportazione, migliorando le performance su database di grandi dimensioni o con molti oggetti. Leggi anche: pg_restore: Ripristinare Dump PostgreSQL e Errori

Esportare solo alcune tabelle o solo i metadati

Data Pump offre granularità elevata, permettendoti di esportare solo specifici oggetti o solo la loro struttura (metadati) senza i dati. Questo è utile per creare schemi vuoti o per spostare solo un sottoinsieme di tabelle.

Per esportare solo alcune tabelle da uno schema, usa l’opzione tables:

expdp system/password@ORCLDB tables=APP.ORDINI,APP.PRODOTTI directory=dp_dir dumpfile=ordini_prodotti.dmp logfile=ordini_prodotti_exp.log

Se invece hai bisogno solo della struttura degli oggetti (ad esempio, per replicare lo schema di un database senza i dati), puoi usare l’opzione content=METADATA_ONLY:

expdp system/password@ORCLDB schemas=APP directory=dp_dir dumpfile=app_metadata.dmp content=METADATA_ONLY logfile=app_metadata_exp.log

L’opzione content=DATA_ONLY farebbe l’opposto: esportare solo i dati, senza la struttura degli oggetti. L’impostazione predefinita è content=ALL, che esporta sia metadati che dati.

Importare in un altro schema (remap_schema)

Una delle funzionalità più potenti di impdp è la possibilità di rimappare gli oggetti durante l’importazione. Questo è fondamentale quando si spostano schemi da un ambiente all’altro e si desidera che lo schema di origine venga creato con un nome diverso nel database di destinazione, o quando si uniscono più schemi.

L’opzione remap_schema ti permette di specificare che tutti gli oggetti appartenenti a uno schema di origine vengano importati in un nuovo schema di destinazione. Ad esempio, per importare lo schema APP dal file di dump e crearlo come APP_TEST nel database di destinazione:

impdp system/password@ORCLDB directory=dp_dir dumpfile=app_%U.dmp remap_schema=APP:APP_TEST logfile=app_imp.log

Questo comando prenderà tutti gli oggetti originariamente nello schema APP e li creerà nello schema APP_TEST nel database corrente. Se APP_TEST non esiste, impdp lo creerà (se l’utente che esegue l’importazione ha i privilegi necessari).

Spostare tra tablespace (remap_tablespace)

Similmente al remap_schema, l’opzione remap_tablespace consente di reindirizzare gli oggetti da un tablespace di origine a un tablespace di destinazione durante l’importazione. Questo è utilissimo per ottimizzare l’allocazione dello spazio o per adattare lo schema importato alla configurazione del database di destinazione, che potrebbe avere nomi di tablespace diversi o una strategia di storage differente.

Per rimappare gli oggetti che originariamente risiedevano nel TABLESPACE_OLD al TABLESPACE_NEW durante l’importazione:

impdp system/password@ORCLDB directory=dp_dir dumpfile=app_%U.dmp remap_tablespace=TABLESPACE_OLD:TABLESPACE_NEW logfile=app_imp_ts.log

È possibile combinare remap_schema e remap_tablespace in un unico comando, offrendo la massima flessibilità per le migrazioni complesse:

impdp system/password@ORCLDB directory=dp_dir dumpfile=app_%U.dmp remap_schema=APP:APP_TEST remap_tablespace=USERS:APP_DATA logfile=app_imp_full.log

Questo comando importerà lo schema APP come APP_TEST e sposterà tutti gli oggetti che erano nel tablespace USERS nel nuovo tablespace APP_DATA.

Parallelismo e compressione

Le performance sono critiche, specialmente con database di grandi dimensioni. Data Pump offre due opzioni chiave per ottimizzare velocità e spazio: parallelismo e compressione.

Parallelismo (parallel): L’opzione parallel (già vista nell’esempio expdp) permette a Data Pump di utilizzare più processi worker contemporaneamente per eseguire le operazioni di export/import. Questo riduce significativamente il tempo totale richiesto. Il numero di processi paralleli dovrebbe essere bilanciato con le risorse del server (CPU, I/O) e il numero di file di dump. Se specifichi parallel=4 e dumpfile=app_%U.dmp, Data Pump creerà 4 file di dump e userà 4 processi per scriverli.

Compressione (compression): L’opzione compression riduce la dimensione dei file di dump, risparmiando spazio su disco e riducendo i tempi di trasferimento. È particolarmente utile per backup remoti o per archiviare grandi quantità di dati. Le opzioni di compressione includono ALL (default), DATA_ONLY, METADATA_ONLY, NONE, ENABLE. ALL comprime sia i dati che i metadati.

expdp system/password@ORCLDB schemas=APP directory=dp_dir dumpfile=app_comp.dmp logfile=app_comp_exp.log parallel=4 compression=ALL

Questa combinazione può accelerare un export/import di terabyte da giorni a ore. Leggi anche: Oracle RMAN: Ripristino Database Dopo Guasto

Leggere il log e gli errori ORA- più frequenti

Il file di log generato da expdp e impdp è la tua risorsa principale per monitorare lo stato dell’operazione e diagnosticare eventuali problemi. È fondamentale leggerlo attentamente, soprattutto in caso di errori.

Il log contiene:

• Dettagli sull’avvio dell’utility (versione, parametri).
• Elenco degli oggetti processati (tabelle, indici, ecc.).
• Statistiche di performance e riepilogo finale.
• Qualsiasi errore ORA- o avvertimento WARNING che si è verificato.

Errori ORA- comuni e troubleshooting:

• ORA-31626: job does not exist / ORA-31633: unable to create master table: Spesso causato da problemi di permessi sulla directory Oracle o da problemi di spazio sul tablespace SYSTEM (dove viene creata la master table del job Data Pump).
• Verifica i permessi READ, WRITE sulla directory.
• Controlla lo spazio libero nel tablespace SYSTEM.

• ORA-39002: invalid operation / ORA-39070: Unable to open the log file: Generalmente indica che il percorso fisico della directory non esiste o che l’utente Oracle non ha i permessi di scrittura sulla directory fisica del sistema operativo.
• Assicurati che /u01/export esista e che l’utente oracle (o l’utente che esegue il database) abbia rwx su di esso.

• ORA-01031: insufficient privileges: L’utente specificato per expdp/impdp non ha i privilegi necessari per esportare/importare gli oggetti richiesti o per accedere alla directory Oracle.
• Concedi i privilegi EXP_FULL_DATABASE e IMP_FULL_DATABASE (per import/export a livello di database intero), o i permessi READ, WRITE sulla directory specifica all’utente.

• ORA-31693: Table data object "SCHEMA"."TABELLA" failed to load/unload and is being skipped due to error:: Un problema specifico con una tabella. Controlla il log per l’errore ORA- dettagliato associato a questa riga. Potrebbe essere un problema di constraint, tipo di dato, o trigger.

Quando un errore si verifica, il log è il tuo migliore amico. Cerca i messaggi ORA- e consulta la documentazione Oracle per il codice specifico.

Errori comuni e troubleshooting

Oltre agli errori ORA- specifici, ci sono alcune problematiche ricorrenti con Data Pump:

1. Mancanza di spazio su disco: I file di dump possono essere molto grandi. Assicurati che il filesystem dove risiede la directory Oracle abbia spazio sufficiente. Un export di un database da 1TB può generare un dump di centinaia di GB anche con compressione.
2. Problemi di performance I/O: Su sistemi con I/O lento, anche con parallelismo elevato, le operazioni di Data Pump possono essere lente. Monitora l’I/O del disco durante l’esecuzione.
3. Encoding dei caratteri: Se l’ambiente di origine e quello di destinazione hanno character set diversi, potresti riscontrare problemi di corruzione dei dati o errori durante l’importazione. Verifica NLS_CHARACTERSET in entrambi i database.
4. Versioni diverse di Oracle: Sebbene Data Pump possa gestire migrazioni tra versioni diverse, ci sono limitazioni. Generalmente, un dump creato con una versione N può essere importato in una versione N o N+1, ma non in N-1. Verifica sempre la compatibilità nella documentazione ufficiale Oracle. Leggi anche: Catalogo ACN: Livelli Cloud QC1-QC4 Spiegati

FAQ — Domande Frequenti

Posso usare Data Pump per fare un backup completo del database per disaster recovery?

No, Data Pump esegue un backup logico. Non è adatto per il disaster recovery a livello di database. Per quello, devi usare RMAN, che gestisce i backup fisici e permette il ripristino dell’intero database, inclusi i control file e i redo log, garantendo la consistenza a livello di blocco e la possibilità di point-in-time recovery.

È possibile riprendere un’operazione Data Pump interrotta?

Sì, Data Pump supporta il restart di job interrotti. Ogni job Data Pump ha un nome. Puoi usare il comando ATTACH per riconnetterti a un job esistente e riprendere l’operazione da dove era stata interrotta, sia in caso di interruzione accidentale che volontaria. Questo è un grande vantaggio rispetto ai vecchi utility exp/imp.

Qual è la differenza tra FULL e SCHEMAS in expdp?

FULL=Y esporta l’intero database, inclusi tutti gli schemi, i tablespace, i ruoli e i profili. Richiede i privilegi EXP_FULL_DATABASE. SCHEMAS=nome_schema esporta solo gli oggetti all’interno dello schema specificato. È più granulare e spesso preferito per migrazioni o backup di singoli applicativi.

Posso escludere oggetti specifici dall’export/import?

Sì, Data Pump offre le opzioni EXCLUDE e INCLUDE che ti permettono di specificare quali tipi di oggetti (e.g., EXCLUDE=TABLE:"IN ('LOG_TABLE')") o quali oggetti specifici (e.g., INCLUDE=TABLE:"IN ('ORDER_ITEMS', 'CUSTOMERS')") vuoi includere o escludere dall’operazione. Questo è estremamente utile per filtrare dati non necessari o sensibili.

Serve riavviare il servizio dopo la modifica?

No, le operazioni di Data Pump (expdp e impdp) non richiedono il riavvio del servizio database. Sono utility client che interagiscono con il database tramite sessioni normali. Le modifiche ai dati o agli schemi avvengono in tempo reale e sono immediatamente disponibili, senza necessità di riavvii.

Conclusioni con takeaway operativi

Oracle Data Pump è uno strumento potente e flessibile per la gestione logica dei dati in ambienti Oracle. La sua capacità di gestire grandi volumi di dati con parallelismo e compressione lo rende indispensabile per DBA e architetti di database. Ricorda sempre di definire correttamente le directory Oracle, di assegnare i permessi adeguati e di sfruttare le opzioni di remap_schema e remap_tablespace per migrazioni senza intoppi. Il log è la tua bussola per il troubleshooting. Padroneggiare expdp e impdp significa ridurre i tempi di inattività, semplificare le operazioni di migrazione e migliorare la robustezza delle strategie di backup logico, un’abilità cruciale in qualsiasi ambiente enterprise.

Fonti

• Oracle Database Backup and Recovery User’s Guide – RMAN

Aggiornato: Ottobre 2026