Migrazione utilizzando le tablespace trasportabili Oracle - Amazon Relational Database Service
Panoramica delle tablespace trasportabili OracleFase 1: configurazione dell'host di origineFase 2: preparazione del backup completo delle tablespaceFase 3: creazione e trasferimento dei backup incrementaliFase 4: trasporto delle tablespaceFase 5: convalida delle tablespace trasportateFase 6: rimozione dei file residui

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Migrazione utilizzando le tablespace trasportabili Oracle

È possibile utilizzare la funzionalità di tablespace trasportabili di Oracle per copiare un set di tablespace da un database Oracle locale a un'istanza per Oracle DB. RDS A livello fisico, trasferisci i file di dati di origine e i file di metadati all'istanza DB di destinazione utilizzando Amazon EFS o Amazon S3. La funzionalità tablespace trasportabili utilizza il pacchetto. rdsadmin.rdsadmin_transport_util Per la sintassi e la semantica di questo pacchetto, vedi. Trasporto di tablespace

Per i post di blog che spiegano come trasportare le tablespace, consulta Migrare i database Oracle all'utilizzo di tablespace trasportabili e Amazon RDS per AWS l'utilizzo di tablespace trasportabili di Oracle. RMAN

Panoramica delle tablespace trasportabili Oracle

Un set di tablespace trasportabili è composto da file di dati per il set di tablespace da trasportare e da un file di dump di esportazione contenente i metadati delle tablespace. In una soluzione di migrazione fisica come le tablespace trasportabili, si trasferiscono file fisici, ovvero file di dati, file di configurazione e file di dump di Data Pump.

Vantaggi e svantaggi delle tablespace trasportabili

Ti consigliamo di utilizzare tablespace trasportabili quando devi migrare una o più tablespace di grandi dimensioni verso un ambiente con tempi di inattività minimi. RDS Rispetto alla migrazione logica, le tablespace trasportabili offrono i seguenti vantaggi:

  • I tempi di inattività sono inferiori rispetto alla maggior parte delle altre soluzioni di migrazione Oracle.

  • Poiché la funzionalità Tablespace trasportabile copia solo i file fisici, vengono evitati gli errori di integrità dei dati e il danneggiamento logico che si possono verificare nella migrazione logica.

  • Non è richiesta alcuna licenza aggiuntiva.

  • È possibile eseguire la migrazione di un set di tablespace su diverse piattaforme e tipi di endianità, ad esempio, da una piattaforma Oracle Solaris a Linux. Tuttavia, il trasporto di tablespace da e verso i server Windows non è supportato.

    Nota

    Linux è completamente testato e supportato. UNIXNon tutte le varianti sono state testate.

Se utilizzi tablespace trasportabili, puoi trasportare i dati utilizzando Amazon S3 o Amazon: EFS

  • Quando li utilizziEFS, i backup rimangono nel EFS file system per tutta la durata dell'importazione. È possibile rimuovere i file in seguito. Con questa tecnica, non è necessario effettuare il provisioning EBS dello storage per l'istanza DB. Per questo motivo, consigliamo di utilizzare Amazon EFS anziché S3. Per ulteriori informazioni, consulta EFSIntegrazione con Amazon.

  • Quando usi S3, scarichi i RMAN backup sullo EBS storage collegato alla tua istanza DB. I file rimangono nello EBS storage durante l'importazione. Dopo l'importazione, è possibile liberare questo spazio, che rimane allocato all'istanza database.

Lo svantaggio principale delle tablespace trasportabili è dato dal fatto che è necessaria una conoscenza relativamente avanzata del database Oracle. Per ulteriori informazioni, consulta l'argomento relativo al trasporto delle tablespace tra database nel manuale Oracle Database Administrator's Guide (Guida per gli amministratori di Oracle Database).

Limitazioni relative alle tablespace trasportabili

Le limitazioni di Oracle Database per le tablespace trasportabili si applicano quando si utilizza questa funzionalità in for Oracle. RDS Per ulteriori informazioni, consulta l'argomento relativo alle limitazioni delle tablespace trasportabili e alle limitazioni generali relative al trasporto dei dati nel manuale Oracle Database Administrator's Guide. Nota le seguenti limitazioni aggiuntive per le tablespace trasportabili in for Oracle: RDS

  • Né il database di origine né quello di destinazione possono utilizzare Standard Edition 2 (). SE2 È supportata solo la versione Enterprise Edition.

  • Non è possibile utilizzare un database Oracle Database 11g come origine. La funzionalità di tablespace trasportabili RMAN multipiattaforma si basa sul meccanismo di RMAN trasporto, che Oracle Database 11g non supporta.

  • Non è possibile migrare i dati da un'RDSistanza For Oracle DB utilizzando tablespace trasportabili. È possibile utilizzare solo tablespace trasportabili per migrare i dati verso un'istanza per Oracle DB. RDS

  • Il sistema operativo Windows non è supportato.

  • Non è possibile effettuare il trasporto delle tablespace in un database di una versione inferiore. Il database di destinazione deve essere della stessa versione o di una versione successiva rispetto al database di origine. Ad esempio, non è possibile effettuare il trasporto delle tablespace da Oracle Database 21c a Oracle Database 19c.

  • Non è possibile effettuare il trasporto delle tablespace amministrative, ad esempio SYSTEM e SYSAUX.

  • Non è possibile trasportare oggetti non contenenti dati come SQL pacchetti PL/, classi Java, viste, trigger, sequenze, utenti, ruoli e tabelle temporanee. Per trasportare oggetti non contenenti dati, creali manualmente o utilizza l'esportazione e l'importazione dei metadati di Data Pump. Per ulteriori informazioni, vedere My Oracle Support Note 1454872.1.

  • Non è possibile effettuare il trasporto di tablespace crittografate o utilizzare colonne crittografate.

  • In caso di trasferimento di file utilizzando Amazon S3, la dimensione massima supportata è di 5 TiB.

  • Se il database di origine utilizza opzioni Oracle come Spatial (Spaziale), non è possibile effettuare il trasporto delle tablespace a meno che le stesse opzioni non siano configurate anche nel database di destinazione.

  • Non è possibile trasportare tablespace in un'istanza di database RDS for Oracle in una configurazione di replica Oracle. Come soluzione alternativa, è possibile eliminare tutte le repliche, effettuare il trasporto delle tablespace e quindi ricreare le repliche.

Prerequisiti per le tablespace trasportabili

Prima di iniziare, completa le seguenti attività:

Fase 1: configurazione dell'host di origine

In questo passaggio, si copiano gli script delle tablespace di trasporto forniti da My Oracle Support e si impostano i file di configurazione necessari. Nei passaggi seguenti, l'host di origine esegue il database contenente le tablespace da trasportare nell'istanza di destinazione.

Configurazione dell'host di origine

  1. Accedere all'host di origine come proprietario della Oracle home.

  2. Assicurarsi che le variabili di ambiente ORACLE_HOME e ORACLE_SID puntino al database di origine.

  3. Accedere al database come amministratore e verificare che la versione del fuso orario, il set di caratteri del database e il set di caratteri nazionali siano gli stessi del database di destinazione.

    SELECT * FROM V$TIMEZONE_FILE;
SELECT * FROM NLS_DATABASE_PARAMETERS 
  WHERE PARAMETER IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

  4. Configurare l'utilità Tablespace trasportabile come descritto in Oracle Support note 2471245.1 (Nota del Supporto Oracle 2471245.1).

    La configurazione include la modifica del file xtt.properties sull'host di origine. Il file xtt.properties di esempio seguente specifica i backup delle  tre tablespace nella directory /dsk1/backups. Si tratta delle tablespace da trasportare nell'istanza database di destinazione. Specifica inoltre l'ID della piattaforma di origine per convertire automaticamente l'endiannes.

    Nota

    Per una piattaforma validaIDs, consulta Data Guard Support per standby primari e fisici eterogenei nella stessa configurazione Data Guard (ID doc 413484.1). 

    #linux system 
platformid=13
#list of tablespaces to transport
tablespaces=TBS1,TBS2,TBS3
#location where backup will be generated
src_scratch_location=/dsk1/backups
#RMAN command for performing backup
usermantransport=1

Fase 2: preparazione del backup completo delle tablespace

In questa fase, si esegue il backup delle tablespace per la prima volta, si trasferiscono i backup sull'host di destinazione e quindi li si ripristina utilizzando la procedura rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces. Dopo aver completato questa fase, i backup iniziali delle tablespace si trovano nell'istanza database di destinazione e possono essere aggiornati mediante backup incrementali.

Passaggio 1: esecuzione del backup delle tablespace sull'host di origine

In questo passaggio, si utilizza lo script xttdriver.pl per eseguire un backup completo delle tablespace. L'output di xttdriver.pl è archiviato nella variabile di ambiente TMPDIR.

Esecuzione del backup delle tablespace

  1. Se le tablespace sono in modalità di sola lettura, accedere al database di origine come utente con il privilegio ALTER TABLESPACE e impostare le tablespace sulla modalità di lettura/scrittura. Altrimenti, passare alla fase successiva.

    L'esempio seguente imposta tbs1, tbs2 e tbs3 sulla modalità lettura/scrittura.

    ALTER TABLESPACE tbs1 READ WRITE;
ALTER TABLESPACE tbs2 READ WRITE;
ALTER TABLESPACE tbs3 READ WRITE;

  2. Eseguire il backup delle tablespace utilizzando lo script xttdriver.pl. Facoltativamente, è possibile specificare --debug per eseguire lo script in modalità di debug.

    export TMPDIR=location_of_log_files
cd location_of_xttdriver.pl
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup

Passaggio 2: trasferimento dei file di backup nell'istanza database di destinazione

In questo passaggio, vengono copiati i file di backup e la configurazione dalla posizione temporanea  all'istanza database di destinazione. Selezionare una delle seguenti opzioni:

  • Se gli host di origine e di destinazione condividono un EFS file system Amazon, utilizza un'utilità del sistema operativo, cp ad esempio per copiare i file di backup e il res.txt file dalla tua posizione virtuale a una directory condivisa. Quindi passa a Passaggio 3: importazione delle tablespace nell'istanza database di destinazione.

  • Se è necessario preparare i backup in un bucket Amazon S3, completare i seguenti passaggi.

Trasferisci file utilizzando Amazon S3 o Amazon. EFS

Passaggio 2.2: caricamento dei backup nel bucket Amazon S3

Caricare i backup e il file res.txt dalla cartella temporanea al bucket Amazon S3. Per ulteriori informazioni, consulta Caricamento degli oggetti nella Guida per l'utente di Amazon Simple Storage Service.

Passaggio 2.3: scaricamento dei backup dal bucket Amazon S3 all'istanza database di destinazione

In questo passaggio, utilizzi la procedura rdsadmin.rdsadmin_s3_tasks.download_from_s3 per scaricare i backup sulla tua istanza DB RDS for Oracle.

Scaricamento dei backup dal bucket Amazon S3

  1. Avvia SQL *Plus o Oracle SQL Developer e accedi alla tua istanza DB RDS per Oracle.

  2. Scarica i backup dal bucket Amazon S3 sull'istanza DB di destinazione utilizzando la procedura RDS Amazon rdsadmin.rdsadmin_s3_tasks.download_from_s3 per d. L'esempio seguente illustra come scaricare tutti i file da un bucket Amazon S3 denominato amzn-s3-demo-bucket nella directory DATA_PUMP_DIR.

    EXEC UTL_FILE.FREMOVE ('DATA_PUMP_DIR', 'res.txt');
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
  p_bucket_name    =>  'amzn-s3-demo-bucket',
  p_directory_name =>  'DATA_PUMP_DIR') 
AS TASK_ID FROM DUAL;

    L'istruzione SELECT restituisce l'ID dell'attività in un tipo di dati VARCHAR2. Per ulteriori informazioni, consulta Download di file da un bucket Amazon S3 a un'istanza database Oracle.

Passaggio 3: importazione delle tablespace nell'istanza database di destinazione

Per ripristinare i tablespace sull'istanza DB di destinazione, utilizza la procedura. rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces Questa procedura converte automaticamente i file di dati nel formato endian corretto.

Se importate da una piattaforma diversa da Linux, specificate la piattaforma di origine utilizzando il parametro p_platform_id quando chiamate. import_xtts_tablespaces Assicuratevi che l'ID della piattaforma specificato corrisponda a quello specificato nel xtt.properties file inPassaggio 2: esportazione dei metadati delle tablespace nell'host di origine.

Importazione delle tablespace nell'istanza database di destinazione

  1. Avvia un SQL client Oracle e accedi all'istanza Target RDS for Oracle DB come utente principale.

  2. Eseguire la procedura rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces, specificando le tablespace da importare e la directory contenente i backup.

    L'esempio seguente importa i tablespace TBS1, TBS2e TBS3 dalla directory DATA_PUMP_DIR. La piattaforma di origine è AIX Based Systems (64 bit), che ha l'ID di piattaforma di6. È possibile trovare la piattaforma IDs eseguendo una query. V$TRANSPORTABLE_PLATFORM

    VAR task_id CLOB

BEGIN
  :task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(
        'TBS1,TBS2,TBS3',
        'DATA_PUMP_DIR',
        p_platform_id => 6);
END;
/

PRINT task_id

  3. (Facoltativo) Monitorare l'avanzamento eseguendo una query sulla tabella rdsadmin.rds_xtts_operation_info. La colonna xtts_operation_state mostra il valore EXECUTING, COMPLETED oFAILED.

    SELECT * FROM rdsadmin.rds_xtts_operation_info;
    Nota

    Per operazioni con tempi di esecuzione lunghi, è anche possibile eseguire una query su V$SESSION_LONGOPS V$RMAN_STATUS e V$RMAN_OUTPUT.

  4. Visualizzare il log dell'importazione completata utilizzando l'ID attività del passaggio precedente.

    SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||'&task_id'||'.log'));

    Assicurarsi che l'importazione sia stata completata correttamente prima di passare alla fase successiva.

Fase 3: creazione e trasferimento dei backup incrementali

In questa fase, si effettuano e si trasferiscono periodicamente backup incrementali mentre il database di origine è attivo. Questa tecnica riduce le dimensioni del backup finale delle tablespace. Se vengono eseguiti più backup incrementali, è necessario copiare il file res.txt dopo l'ultimo backup incrementale prima di poterlo applicare all'istanza di destinazione.

I passaggi sono gli stessi di quelli indicati in Fase 2: preparazione del backup completo delle tablespace, tranne per il fatto che il passaggio di importazione è facoltativo.

Fase 4: trasporto delle tablespace

In questa fase, si esegue il backup delle tablespace di sola lettura e si esportano i metadati di Data Pump, questi file vengono quindi trasferiti nell'host di destinazione e infine vengono importati sia le tablespace che i metadati.

Passaggio 1: esecuzione del backup delle tablespace di sola lettura

Questo passaggio è identico a Passaggio 1: esecuzione del backup delle tablespace sull'host di origine, con una differenza fondamentale: le tablespace vengono impostate sulla modalità di sola lettura prima di eseguirne il backup per l'ultima volta.

L'esempio seguente imposta tbs1, tbs2 e tbs3 sulla modalità di sola lettura.

ALTER TABLESPACE tbs1 READ ONLY;
ALTER TABLESPACE tbs2 READ ONLY;
ALTER TABLESPACE tbs3 READ ONLY;

Passaggio 2: esportazione dei metadati delle tablespace nell'host di origine

Esportare i metadati delle tablespace eseguendo l'utilità expdb nell'host di origine. L'esempio seguente esporta i tablespace TBS1, TBS2e TBS3 per scaricare il file xttdump.dmp nella cartella DATA_PUMP_DIR.

expdp username/pwd \
dumpfile=xttdump.dmp \
directory=DATA_PUMP_DIR \
statistics=NONE \
transport_tablespaces=TBS1,TBS2,TBS3 \
transport_full_check=y \
logfile=tts_export.log

Se DATA_PUMP_DIR è una directory condivisa in AmazonEFS, vai aPassaggio 4: importazione delle tablespace nell'istanza database di destinazione.

Passaggio 3: (solo Amazon S3) trasferimento dei file di backup ed esportazione nell'istanza database di destinazione

Se si utilizza Amazon S3 per preparare i backup delle tablespace e il file di esportazione di Data Pump, completare i seguenti passaggi.

Passaggio 3.1: caricamento dei backup e del file di dump dall'host di origine al bucket Amazon S3

Caricare i file di backup e i file di dump dall'host di origine al bucket Amazon S3. Per ulteriori informazioni, consulta Caricamento degli oggetti nella Guida per l'utente di Amazon Simple Storage Service.

Passaggio 3.2: scaricamento dei backup e del file di dump dal bucket Amazon S3 all'istanza database di destinazione

In questo passaggio, si utilizza la procedura rdsadmin.rdsadmin_s3_tasks.download_from_s3 per scaricare i backup e il file di dump nell'istanza DB RDS for Oracle. Seguire la procedura riportata in Passaggio 2.3: scaricamento dei backup dal bucket Amazon S3 all'istanza database di destinazione.

Passaggio 4: importazione delle tablespace nell'istanza database di destinazione

Utilizzare la procedura rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces per ripristinare le tablespace. Per la sintassi e la semantica di questa procedura, consulta Importazione di tablespace trasportate nell'istanza database

Importante

Dopo aver completato l'importazione finale delle tablespace, il passaggio successivo prevede l'importazione dei metadati di Oracle Data Pump. Se l'importazione non riesce, è importante ripristinare lo stato dell'istanza database precedente all'errore. Pertanto, è consigliabile creare uno snapshot DB dell'istanza database seguendo le istruzioni riportate in Creazione di uno snapshot DB per un'istanza DB Single-AZ per Amazon RDS. Lo snapshot conterrà tutte le tablespace importate. Pertanto, se l'importazione non riesce, non sarà necessario ripetere il processo di backup e importazione.

Se l'istanza DB di destinazione ha i backup automatici attivati e Amazon RDS non rileva che uno snapshot valido è stato avviato prima di importare i metadati, RDS tenta di creare uno snapshot. A seconda dell'attività dell'istanza, questo snapshot potrebbe riuscire o meno. Se non viene rilevato uno snapshot valido o non è possibile avviarne uno, l'importazione dei metadati viene terminata con errori.

Importazione delle tablespace nell'istanza database di destinazione

  1. Avvia un SQL client Oracle e accedi all'istanza Target RDS for Oracle DB come utente principale.

  2. Eseguire la procedura rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces, specificando le tablespace da importare e la directory contenente i backup.

    L'esempio seguente importa i tablespace TBS1, TBS2e TBS3 dalla directory DATA_PUMP_DIR.

    BEGIN
  :task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces('TBS1,TBS2,TBS3','DATA_PUMP_DIR');
END;
/
PRINT task_id

  3. (Facoltativo) Monitorare l'avanzamento eseguendo una query sulla tabella rdsadmin.rds_xtts_operation_info. La colonna xtts_operation_state mostra il valore EXECUTING, COMPLETED oFAILED.

    SELECT * FROM rdsadmin.rds_xtts_operation_info;
    Nota

    Per operazioni con tempi di esecuzione lunghi, è anche possibile eseguire una query su V$SESSION_LONGOPS V$RMAN_STATUS e V$RMAN_OUTPUT.

  4. Visualizzare il log dell'importazione completata utilizzando l'ID attività del passaggio precedente.

    SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||'&task_id'||'.log'));

    Assicurarsi che l'importazione sia stata completata correttamente prima di passare alla fase successiva.

  5. Eseguire uno snapshot DB manuale seguendo le istruzioni riportate in Creazione di uno snapshot DB per un'istanza DB Single-AZ per Amazon RDS.

Passaggio 5: importazione dei metadati delle tablespace nell'istanza database di destinazione

In questo passaggio, si importano i metadati trasportabili del tablespace nella propria istanza di database RDS for Oracle utilizzando la procedura. rdsadmin.rdsadmin_transport_util.import_xtts_metadata Per la sintassi e la semantica di questa procedura, consulta Importazione dei metadati delle tablespace trasportabili nell'istanza database. Durante l'operazione, lo stato dell'importazione viene visualizzato nella tabella rdsadmin.rds_xtts_operation_info.

Importante

Prima di importare i metadati, è vivamente consigliabile di verificare che sia stato creato correttamente uno snapshot DB dopo aver importato le tablespace. Se la fase di importazione ha esito negativo, ripristinare l'istanza database, correggere gli errori di importazione e riprovare l'importazione.

Importa i metadati Data Pump nella tua istanza DB per Oracle RDS

  1. Avvia il tuo SQL client Oracle e accedi all'istanza DB di destinazione come utente principale.

  2. Se non esistono già, creare gli utenti proprietari degli schemi nelle tablespace trasportate.

    CREATE USER tbs_owner IDENTIFIED BY password;

  3. Importare i metadati, specificando il nome del file di dump e la sua posizione nella directory.

    BEGIN
  rdsadmin.rdsadmin_transport_util.import_xtts_metadata('xttdump.dmp','DATA_PUMP_DIR');
END;
/

  4. (Facoltativo) Eseguire una query sulla tabella della cronologia delle tablespace trasportabili per visualizzare lo stato dell'importazione dei metadati.

    SELECT * FROM rdsadmin.rds_xtts_operation_info;

    Al termine dell'operazione, le tablespace sono in modalità di sola lettura.

  5. (Facoltativo) Visualizzare il file di log.

    L'esempio seguente elenca il contenuto della BDUMP directory e quindi interroga il log di importazione.

    SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'BDUMP'));

SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file(
  p_directory => 'BDUMP',
  p_filename => 'rds-xtts-import_xtts_metadata-2023-05-22.01-52-35.560858000.log'));

Fase 5: convalida delle tablespace trasportate

In questo passaggio facoltativo, le tablespace trasportate vengono convalidate utilizzando la procedurardsadmin.rdsadmin_rman_util.validate_tablespace, quindi vengono impostate sulla modalità di lettura/scrittura.

Convalida dei dati trasportati

  1. Avvia SQL *Plus o SQL Developer e accedi all'istanza DB di destinazione come utente principale.

  2. Convalidare le tablespace utilizzando la procedura rdsadmin.rdsadmin_rman_util.validate_tablespace.

    SET SERVEROUTPUT ON
BEGIN
    rdsadmin.rdsadmin_rman_util.validate_tablespace(
        p_tablespace_name     => 'TBS1',
        p_validation_type     => 'PHYSICAL+LOGICAL',
        p_rman_to_dbms_output => TRUE);
    rdsadmin.rdsadmin_rman_util.validate_tablespace(
        p_tablespace_name     => 'TBS2',
        p_validation_type     => 'PHYSICAL+LOGICAL',
        p_rman_to_dbms_output => TRUE);
    rdsadmin.rdsadmin_rman_util.validate_tablespace(
        p_tablespace_name     => 'TBS3',
        p_validation_type     => 'PHYSICAL+LOGICAL',
        p_rman_to_dbms_output => TRUE);
END;
/

  3. Impostare le tablespace sulla modalità lettura/scrittura.

    ALTER TABLESPACE TBS1 READ WRITE;
ALTER TABLESPACE TBS2 READ WRITE;
ALTER TABLESPACE TBS3 READ WRITE;

Fase 6: rimozione dei file residui

In questo passaggio facoltativo, tutti i file non necessari vengono rimossi. Usa la procedura rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files per elencare i file di dati che sono rimasti orfani dopo un'importazione tablespace, quindi utilizza la procedura rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files per eliminarli. Per la sintassi e la semantica di queste procedure, consulta Elenco dei file orfani dopo un'importazione della tablespace e Eliminazione di file di dati rimasti orfani dopo un'importazione della tablespace.

Rimozione dei file residui

  1. Rimuovi i vecchi backup in DATA_PUMP_DIR come segue:

    1. Elencare i file di backup eseguendo rdsadmin.rdsadmin_file_util.listdir.

      SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'DATA_PUMP_DIR'));

    2. Rimuovere i backup uno a uno chiamando UTL_FILE.FREMOVE.

      EXEC UTL_FILE.FREMOVE ('DATA_PUMP_DIR', 'backup_filename');

  2. Se è stata eseguita l'importazione delle tablespace, ma non dei relativi metadati, è possibile eliminare i file di dati orfani nel seguente modo:

    1. Elencare i file di dati orfani da eliminare. L'esempio seguente esegue la procedura rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files.

      SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files);

FILENAME       FILESIZE
-------------- ---------
datafile_7.dbf 104865792
datafile_8.dbf 104865792

    2. Eliminare i file orfani eseguendo la procedura rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import.

      BEGIN
  rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import('DATA_PUMP_DIR');
END;
/

      L'operazione di rimozione genera un file di log che utilizza il formato di nome rds-xtts-delete_xtts_orphaned_files-YYYY-MM-DD.HH24-MI-SS.FF.log nella directory BDUMP.

    3. Leggere il file di log generato nel passaggio precedente. Il seguente esempio legge il log rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log.

      SELECT * 
FROM TABLE(rdsadmin.rds_file_util.read_text_file(
       p_directory => 'BDUMP',
       p_filename  => 'rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log'));

TEXT
--------------------------------------------------------------------------------
orphan transported datafile datafile_7.dbf deleted.
orphan transported datafile datafile_8.dbf deleted.

  3. Se è stata eseguita l'importazione sia delle tablespace che dei relativi metadati, ma sono stati restituiti errori di compatibilità o si sono verificati problemi di altro tipo con Oracle Data Pump, rimuovere i file di dati parzialmente trasportati nel seguente modo:

    1. Elencare le tablespace contenente i file di dati parzialmente trasportati mediante una query su DBA_TABLESPACES.

      SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE PLUGGED_IN='YES';

TABLESPACE_NAME
--------------------------------------------------------------------------------
TBS_3

    2. Rimuovere le tablespace e i file di dati parzialmente trasportati.

      DROP TABLESPACE TBS_3 INCLUDING CONTENTS AND DATAFILES;