transportable Tablespace pe diferite platforme
___________________________________________________
în exemplul nostru vom transporta o tabelăspațiu numit TEST. Tablespace ar trebui să fie de sine stătătoare, fără obiecte care se referă la alte spații de masă, astfel încât pentru a verifica dacă sistemul de operare tablespace de sine stătătoare folosind interogarea de mai jos:
executați dbms_tts.transport_set_check (‘TEST’, TRUE, TRUE);
selectați * din transport_set_violations;
dacă aveți obiecte de referință încrucișate. Aruncați acele obiecte din spațiul tabelului de TEST(vă rugăm să rețineți că acest lucru se face într-un mediu de testare, astfel încât să pot renunța cu ușurință la obiectele cu referință încrucișată. Nu aruncați obiecte fără a vă consulta DBA senior într-un mediu de producție. Nu știi niciodată ce obiect are ce dependență. Să presupunem că aveți indici în spațiul de testare care indică tabele într-un alt spațiu de masă. Puteți muta în siguranță aceste indexuri folosind procedura pl/sql de mai jos:
începe
pentru c1 în (selectați index_name a1 din user_indexes)
buclă
executa imediat ‘alter index ‘||c1.A1 / / ‘ rebuild online tablespace < nume tablespace>’;
end loop;
end;
/
acum continuați și verificați din nou încălcările. Dacă primiți o eroare cum ar fi:
selectați * din transport_set_violations;
încălcări
—————————
încălcarea 46: contactați Oracle support
încălcarea 46: contactați Oracle support
încălcarea 46 : contactați Oracle support
rulați această interogare pentru a verifica de ce încălcarea aruncă
selectați 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 (motiv)
din PLUGGABLE_SET_CHECK
unde MESG_ID=46;
acest lucru va da de ieșire a ceea ce este exact încălcarea pentru spațiul de masă transportabil. Remediați aceste încălcări și începeți procedura reală pentru transportul spațiului de masă. În exemplul meu am folosit criptarea transparentă a datelor(TDE) pentru câteva coloane din Baza de date. Interogarea a raportat că nu puteți utiliza tt_tbs atunci când aveți coloane criptate. Așa că a trebuit să decriptez coloanele pe care le-am criptat folosind o interogare ca.
selectați * din dba_encrypted_columns;
ALTER TABLE cont modifica (titularul cardului decripta);
după decriptarea coloanelor. Continuăm mai departe
1. Verificați versiunea ENDIAN atât sursă și țintă folosind script-ul de mai jos:
—
— care sunt posibilitățile disponibile ale platformei Tablespace transportabile?
—
selectați
nume_platformă
, endian_format
din v $ transportable_platform
comandă după nume_platformă
;
—
— care este ENDIAN-ness-ul actual al bazei de date și platformei mele?
—
selectați
D.name
, TP. endian_format
din
v$transportable_platform TP
, v$baza de date D
unde TP.platform_name = D. platform_name
;
va raporta dacă ENDIANUL este „mic” sau „mare”. Dacă endianul este același atât pe țintă, cât și pe sursă, nu este nevoie să mergeți la spațiul de masă transportabil. Puteți exporta pur și simplu spațiul de masă și îl puteți importa la țintă. Dacă nu procedați ca mai jos
2. Modificați spațiul de masă și puneți-l în modul read-only pe sursă. În exemplul nostru vom transporta un spațiu de masă numit TEST către serverul țintă.
ALTER TABLESPACE test numai pentru citire;
3. acum exportați metadatele 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 ca SYSDBA \’ TRANSPORT_TABLESPACE = y TABLESPACES=test FILE = test_repository.dmp log = test_repository.txt
du-te la țintă și copia dumpfile la orice locație, împreună cu fișierele de date ale acelui spațiu de masă.
imp \’SYS/oracle ca SYSDBA\’ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.dmp datafiles= ‘ users_01.dbf’
4. Până mai sus este pentru atunci când exportați un spațiu de masă la o mașină cu aceleași informații endian. Dacă un alt endian proceda ca mai jos. Vom converti de la Solaris pe 64 de biți SPARC (mare) la Windows pe 32 de biți(mic)
5. Conversia fișierelor de date folosind RMAN și db_file_name_convert
#nu utilizați această metodă: pe mașină sursă: cu nume de fișier original
RMAN> conversia tablespace ‘TEST’
la platforma ‘Microsoft Windows IA (32-bit)’
format=’/datafiles / rmanbkp / %N_ % F ‘
paralelism = 4;
## utilizați această metodă: pe mașina sursă: Cu nume de fișier convertit nume de fișier
RMAN> conversia tablespace ‘ TEST ‘
2> la platforma’Microsoft Windows IA (32-bit) ‘
3> db_file_name_convert’/datafiles/oradata/SWX’,’ / datafiles/rmanbkp ‘
4> paralelism = 4;
după ce fișierele sunt convertite pot fi găsite în ‘/datafiles/rmanbkp’. Copiați aceste fișiere convertite împreună cu groapa de metadate a TT_TBS și puneți-o pe serverul sursă și rulați importul:
imp USERID=’sistem/parolă@țintă ca SYSDBA’
TRANSPORT_TABLESPACE=y
DATAFILES = ‘ C:\datafiles\test01.DBF’,’C:\datafiles\test02.DBF ‘
TABLESPACES=test
FILE=test_repository.dmp
în cazurile de mai sus, am convertit fișierele de pe platforma sursă. Cu toate acestea, puteți face acest lucru și pe platforma țintă. De exemplu, puteți copia fișierul test01.dbf împreună cu groapa de metadate pe o mașină țintă Windows Server 2003 pe 32 de biți și convertiți-o acolo:
RMAN> convert
2> fișier de date ‘c:/users01.DBF ‘ # # director în cazul în care veți pune fișierul de date de la serverul sursă
3> format ‘c:/datafiles/rmanbkp/%N_%f’ # # director în cazul în care veți obține fișierul convertit
4> ;
această abordare va crea un fișier în formatul specificat în director.
dar de ce ați dori să convertiți fișierele de date pe platforma țintă, mai exact? Un motiv ar putea fi timpul de nefuncționare mai scurt, care necesită ca spațiile de masă să fie citite numai pe durata copiei către gazda țintă. Ai putea tripla-oglindă fișierul de date, face tablespace doar citit, rupe a treia oglindă, și imediat face tablespace citire/scriere. Această a treia oglindă ar putea fi apoi montată pe sistemul țintă și transformată în timpul liber. Acest aranjament minimizează durata pentru care spațiul de masă trebuie să rămână numai în citire.
un alt motiv ar putea fi performanța. Baza de date OLTP poate fi sub o sarcină constantă și utilizarea operației de conversie RMAN poate tensiona sistemul mai mult decât se dorește. În schimb, conversia poate fi descărcată pe serverul data warehouse, unde mai multe procesoare sunt de obicei disponibile pentru operații paralele.
