Tablespace trasportabile su diverse piattaforme
___________________________________________________
Nel nostro esempio trasporteremo un tablespace chiamato TEST. Il tablespace dovrebbe essere autonomo senza oggetti che si riferiscono ad altri tablespace, quindi per questo controlla se il tablespace os è autonomo usando la query sottostante:
ESEGUIRE dbms_tts.transport_set_check (‘TEST’, TRUE, TRUE);
SELEZIONA * DA transport_set_violations;
Se si dispone di oggetti con riferimenti incrociati. Rilascia quegli oggetti dal tablespace di TEST (Si prega di notare che questo viene fatto in un ambiente di test in modo da poter eliminare facilmente gli oggetti con riferimenti incrociati. Non rilasciare oggetti senza consultare il DBA senior in un ambiente di produzione. Non si sa mai quale oggetto ha quale dipendenza. Supponiamo di avere indici nel tablespace di TEST che puntano a tabelle in un altro tablespace. È possibile spostare in modo sicuro quegli indici utilizzando la procedura pl / sql sottostante:
inizia
per c1 in (seleziona index_name a1 da user_indexes)
loop
esegui immediato ‘alter index ‘||c1.a1 / / ‘ rebuild online tablespace <tablespace name>’;
end loop;
end;
/
Ora procedi e controlla di nuovo le violazioni. Se si ottiene un errore come:
SELEZIONA * DA transport_set_violations;
VIOLAZIONI
—————————
Violazione 46: contattare il supporto Oracle
Violazione 46: contattare il supporto Oracle
Violazione 46 : contattare il supporto di Oracle
Esegui questa query per controllare il motivo per cui la violazione è il lancio di
SELECT TRIM(OBJ1_OWNER) || ‘, ‘ || TRIM(OBJ1_NAME) || ‘, ‘ ||
TRIM(OBJ1_SUBNAME) || ‘, ‘ || TRIM(OBJ1_TYPE) || ‘, ‘ ||
TRIM(TS1_NAME) || ‘, ‘ || TRIM(OBJ2_OWNER) || ‘, ‘ ||
TRIM(OBJ2_NAME) || ‘, ‘ || TRIM(OBJ2_SUBNAME) || ‘, ‘ ||
TRIM(OBJ2_TYPE) || ‘, ‘ || TRIM(TS2_NAME) || ‘, ‘ ||
TRIM(CONSTRAINT_NAME) || ‘, ‘ || TRIM(LA RAGIONE)
DA PLUGGABLE_SET_CHECK
DOVE MESG_ID=46;
Questo darà l’output di quale sia esattamente la violazione per il tablespace trasportabile. Correggere tali violazioni e avviare la procedura effettiva per il trasporto del tablespace. Nel mio esempio avevo usato Transparent Data Encryption(TDE) per alcune colonne sul database. La query ha riferito che non è possibile utilizzare TT_TBS quando si dispone di colonne crittografate. Quindi ho dovuto decifrare le colonne che ho crittografato usando una query come.
SELEZIONA * DA dba_encrypted_columns;
MODIFICA l’account DELLA TABELLA (DECODIFICA del titolare della carta);
Dopo aver decifrato le colonne. Procediamo ulteriormente
1. Controlla la versione ENDIAN di origine e destinazione usando lo script sottostante:
—
— Quali sono le possibilità di piattaforma Tablespace trasportabili disponibili?
—
SELEZIONARE
platform_name
,endian_format
v$transportable_platform
ORDER BY platform_name
;
—
— Qual è la corrente ENDIAN-ness del mio database e la piattaforma?
—
SELEZIONARE
D. nome
,TP.endian_format
DA
v$transportable_platform TP
,v$database di D
DOVE TP.platform_name = D. platform_name
;
segnalerà se l’ENDIAN è “piccolo” o “grande”. Se l’endian è lo stesso su target e source, non è necessario andare per tablespace trasportabile. Puoi semplicemente esportare il tablespace e importarlo nella destinazione. Se non procedere come sotto
2. Modificare il tablespace e metterlo in modalità di sola lettura sulla fonte. Nel nostro esempio trasporteremo un tablespace chiamato TEST sul server di destinazione.
ALTER TABLESPACE test SOLA LETTURA;
3. ora esportare i metadati tablespace.
##Windows # # #
exp USERID= ‘system/oracle @ Source AS SYSDBA’ TRANSPORT_TABLESPACE = y TABLESPACES=test FILE = test_repository.dmp log = test_repository.txt
###Unix # # #
exp \ ‘sys / oracle AS SYSDBA \’ TRANSPORT_TABLESPACE=y TABLESPACES=test FILE=test_repository.dmp log = test_repository.txt
Vai a destinazione e copia dumpfile in qualsiasi posizione insieme ai file di dati di quel tablespace.
imp \’sys/oracle AS SYSDBA\’ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.dmp datafiles= ‘ users_01.dbf’
4. Till above è per quando stai esportando un tablespace su una macchina con le stesse informazioni di endian. Se hai un endian diverso procedi come di seguito. Convertiremo da Solaris 64-bit SPARC (GRANDE) a Windows 32-bit (Piccolo)
5. Convertire i file di dati utilizzo di RMAN e db_file_name_convert
#non utilizzare questo metodo: Sulla macchina di Origine: Con il nome del file originale
RMAN> converti tablespace ‘TEST’
per piattaforma Microsoft Windows IA (32-bit)’
formato=’/datafiles/rmanbkp/%N_%f’
parallelismo = 4;
## utilizzare questo metodo: Sul computer di Origine: Con il nome del file convertito filename
RMAN> converti tablespace ‘TEST’
2> per piattaforma Microsoft Windows IA (32-bit)’
3> db_file_name_convert ‘/datafiles/oradata/SWX’,’/datafiles/rmanbkp’
4> parallelismo = 4;
Dopo la conversione dei file può essere trovato in ‘/datafiles/rmanbkp’. Copia questi file convertiti insieme al dump dei metadati di TT_TBS e mettilo sul server di origine ed esegui l’importazione:
imp USERID= ‘system / password @ target AS SYSDBA’
TRANSPORT_TABLESPACE = y
DATAFILES=’C:\datafiles\test01.DBF”,”C:\datafiles\test02.DBF ‘
TABLESPACES = test
FILE = test_repository.dmp
Nei casi precedenti, abbiamo convertito i file sulla piattaforma di origine. Tuttavia, puoi farlo anche sulla piattaforma di destinazione. Ad esempio, è possibile copiare il file test01.dbf insieme al dump dei metadati su una macchina di destinazione a 32 bit di Windows Server 2003 e convertirla lì:
RMAN> converti
2 > file di dati ‘c:/users01.dbf ‘ # # directory in cui inserirai il tuo file di dati dal server sorgente
3> formato ‘c:/datafiles/rmanbkp/%N_%f’ # # directory dove si ottiene il file convertito
4> ;
Questo approccio creerà un file nel formato specificato nella directory.
Ma perché si desidera convertire i file di dati sulla piattaforma di destinazione, esattamente? Un motivo potrebbe essere un tempo di inattività più breve, che richiede che i tablespace siano stati di SOLA LETTURA solo per la durata della copia sull’host di destinazione. È possibile eseguire il triplo mirroring del file di dati, rendere il tablespace in sola lettura, interrompere il terzo mirror e rendere immediatamente il tablespace in lettura/scrittura. Questo terzo specchio potrebbe quindi essere montato sul sistema di destinazione e convertito nel tempo libero. Questa disposizione riduce al minimo la durata per la quale il tablespace deve rimanere di sola lettura.
Un altro motivo potrebbe essere le prestazioni. Il database OLTP potrebbe essere sotto un carico costante e l’utilizzo dell’operazione RMAN convert potrebbe affaticare il sistema più del desiderato. Invece, la conversione può essere scaricata sul server di data warehouse, dove di solito sono disponibili più CPU per operazioni parallele.
