Transportabelt Tabellområde På Forskjellige Plattformer
___________________________________________________
I vårt eksempel vil vi transportere en tabellplass kalt TEST. Tabellplass bør være selvstendig uten objekter henviser til andre tabellplasser så for at sjekk om tabellplass os selv inneholdt ved hjelp under spørring:
UTFØR dbms_tts.transport_set_check (‘TEST’, TRUE, TRUE);
VELG * fra transport_set_violations;
hvis du har kryssrefererte objekter. Slipp disse objektene FRA TESTTABELLEN(Vær oppmerksom på at dette gjøres i et testmiljø, slik at jeg enkelt kan slippe de kryssrefererte objektene. Ikke slipp noen gjenstander uten å konsultere senior DBA i et produksjonsmiljø. Du vet aldri hvilket objekt som har hvilken avhengighet. Anta at du har indekser I TESTTABELLOMRÅDET som peker på tabeller i et annet tabellområde. Du kan trygt flytte disse indeksene ved hjelp av under pl / sql-prosedyre:
begynn
for c1 i (velg index_name a1 fra user_indexes)
sløyfe
utfør umiddelbar ‘ alter index | / / c1.a1 / / ‘ gjenoppbygge online tabellplass < tabellplassnavn >’;
end loop;
end;
/
fortsett nå og kontroller brudd på nytt. Hvis du får en feil som:
VELG * fra transport_set_violations;
BRUDD
—————————
Brudd 46: kontakt oracle support
Brudd 46: kontakt oracle support
Brudd 46 : kontakt oracle support
Kjør denne spørringen for å sjekke hvorfor bruddet kaster
VELG 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 (BEGRENSNING)||’, ‘ / / TRIM(GRUNN)
FRA PLUGGABLE_SET_CHECK
HVOR MESG_ID=46;
Dette vil gi utdata av hva nøyaktig bruddet er for det transportable tabellområdet. Løs disse bruddene og start den faktiske prosedyren for transport av tabellplassen. I mitt eksempel hadde jeg brukt Transparent Datakryptering (TDE) for få kolonner på databasen. Spørringen rapporterte at DU ikke kan bruke TT_TBS når du har krypterte kolonner. Så jeg måtte dekryptere kolonnene som jeg krypterte med en spørring som.
VELG * fra dba_encrypted_columns;
ENDRE TABELL konto ENDRE (KORTHOLDER DEKRYPTERE);
etter dekryptering av kolonnene. Vi fortsetter videre
1. Sjekk ENDIAN-versjonen av både kilde og mål ved hjelp av under skript:
—
— Hva er De Tilgjengelige Transportable Tablespace Plattform muligheter?
—
VELG
plattformnavn
, endian_format
FRA v $ transportable_platform
BESTILL etter plattformnavn
;
—
— Hva er GJELDENDE ENDIAN-ness av min database og plattform?
—
VELG
D.name
,tp.endian_format
FRA
v$transportable_platform TP
,V$database D
HVOR TP.platform_name = d. platform_name
;
det vil rapportere om ENDIAN er «liten» eller «stor». Hvis endian er den samme på både mål og kilde, trenger du ikke å gå for transportabel tabellplass. Du kan bare eksportere tabellplass og importere den til målet. Hvis ikke fortsett som nedenfor
2. Endre tabellplass og sette den i skrivebeskyttet modus på kilde. I vårt eksempel vil vi transportere en tabellplass kalt TEST til målserveren.
ENDRE TABELLPLASS test SKRIVEBESKYTTET;
3. nå eksportere tabellplass metadata.
##Windows # # #
exp USERID= ‘system / oracle@Kilde SOM SYSDBA’ TRANSPORT_TABLESPACE=Y TABLESPACES=test FIL = test_repository.dmp logg=test_repository.txt
###Unix # # #
exp \ ‘sys / oracle AS SYSDBA \’ TRANSPORT_TABLESPACE=Y TABELLPLASSER=testfil = test_repository.dmp logg=test_repository.txt
Gå til mål og kopier dumpfile til et hvilket som helst sted sammen med datafilene til det tabellområdet.
imp \ ‘sys / oracle SOM SYSDBA \’ TABLESPACES=test TRANSPORT_TABLESPACE=Y FIL=test_repository.dmp datafiles= ‘ users_01.dbf’
4. Till ovenfor er for når du eksporterer en tabellplass til en maskin med samme endian informasjon. Hvis du en annen endian fortsette som nedenfor. Vi konverterer Fra Solaris 64-bit SPARC (STOR) Til Windows 32-bit(Liten)
5. Konverter datafiler ved HJELP AV RMAN og db_file_name_convert
#ikke bruk denne metoden: På Kildemaskinen: med originalt filnavn
rman> konverter tabellplass ‘TEST’
til plattform ‘Microsoft Windows IA (32-bit)’
format=’ / datafiles / rmanbkp/%n_ % f’
parallellisme = 4;
## bruk denne metoden: På Source machine: Med konvertert filnavn filnavn
rman> konverter tabellplass ‘TEST’
2> til plattform ‘Microsoft Windows IA (32-bit)’
3> db_file_name_convert ‘/datafiler/oradata/SWX’,’/datafiler/rmanbkp’
4> parallellisme = 4;
etter at filene er konvertert kan det bli funnet i ‘/ datafiles / rmanbkp’. Kopier disse konverterte filer sammen med metadata dump AV TT_TBS og sette den på kildeserver og kjøre import:
imp USERID= ‘system / passord@mål SOM SYSDBA’
TRANSPORT_TABLESPACE=y
DATAFILES=’C:\datafiles\test01.DBF’, ‘ C:\datafiles\test02.DBF ‘
TABELLPLASSER=test
FIL=test_repository.dmp
i de ovennevnte tilfellene konverterte vi filene på kildeplattformen. Du kan imidlertid gjøre det på målplattformen også. For eksempel kan du kopiere filen test01.dbf sammen med metadata dump På En Windows Server 2003 32-bit målmaskin og konvertere den der:
RMAN> konverter
2 > datafil ‘c:/users01.dbf ‘ # # katalog hvor du vil sette datafilen din fra kildeserver
3 > format ‘c:/datafiles/rmanbkp/%N_%f’ # # katalog hvor du får konvertert fil
4 > ;
denne tilnærmingen vil opprette en fil i formatet som er angitt i katalogen.
men hvorfor vil du konvertere datafilene på målplattformen, akkurat? En grunn kan være kortere nedetid, noe som krever at tabellrommene BARE SKAL LESES i løpet av kopien til målverten. Du kan tredoble speilet datafilen, gjøre tabellplassen skrivebeskyttet, bryte det tredje speilet,og umiddelbart gjøre tabellplassen lese / skrive. Dette tredje speilet kan da monteres på målsystemet og konverteres på fritiden. Denne ordningen minimerer varigheten som tabellområdet må forbli skrivebeskyttet.
En annen grunn kan være ytelse. OLTP-databasen kan være under konstant belastning, og VED HJELP AV rman convert-operasjonen kan systemet belastes mer enn ønsket. I stedet kan konverteringen lastes av til datalagerserveren, der flere Cpuer vanligvis er tilgjengelige for parallelle operasjoner.
