transportabel Tablespace på tværs af forskellige platforme
___________________________________________________
i vores eksempel vil vi transportere en spisesked kaldet TEST. Tablespace skal være selvstændig uden objekter, der henviser til andre tablespaces, så for at kontrollere, om tablespace os selvstændig ved hjælp af nedenstående forespørgsel:
udfør dbms_tts.transport_set_check (‘TEST’, TRUE, TRUE);
vælg * fra transport_set_violations;
hvis du har krydsrefererede objekter. Drop disse objekter fra testen tablespace(Bemærk Dette sker i et testmiljø, så jeg kan slippe de krydsrefererede objekter nemt. Tab ikke genstande uden at konsultere din senior DBA i et produktionsmiljø. Du ved aldrig, hvilket objekt der har hvilken afhængighed. Antag, at du har indekser i testtabellen, der peger på tabeller i en anden tablespace. Du kan sikkert flytte disse indekser ved hjælp af nedenstående pl/kvm-procedure:
begynd
for c1 i (Vælg indeks_navn a1 fra bruger_indekser)
loop
udfør øjeblikkeligt ‘alter indeks ‘||c1.a1 / / ‘ Genopbyg online tablespace <tablespace name>’;
end loop;
end;
/
fortsæt nu og kontroller overtrædelser igen. Hvis du får en fejl som:
vælg * fra transport_set_overtrædelser;
overtrædelser
—————————
overtrædelse 46 : kontakt Oracle support
overtrædelse 46: kontakt Oracle support
overtrædelse 46 : kontakt Oracle support
Kør denne forespørgsel for at kontrollere, hvorfor overtrædelsen kaster
vælg TRIM(OBJ1_EJER)||’, ‘ | | TRIM (OBJ1_NAME) || ‘, ‘ ||
TRIM (OBJ1_SUBNAME)//’, | / / TRIM (OBJ1_TYPE) || ‘, ‘ ||
TRIM (TS1_NAME)//’, ‘ | / TRIM (OBJ2_EJER) || ‘, ‘ ||
TRIM (OBJ2_NAME)//’, | / / TRIM (OBJ2_SUBNAME) || ‘, ‘ ||
TRIM (OBJ2_TYPE)//’, | / / TRIM (TS2_NAME) || ‘, ‘ ||
TRIM(CONSTRAINT_NAME) || ‘, ‘ || TRIM (årsag)
fra PLUGGABLE_SET_CHECK
hvor MESG_ID=46;
dette vil give output af, hvad der præcist overtrædelsen er for den transportable tablespace. Løs disse overtrædelser og start den faktiske procedure for transport af tablespace. I mit eksempel havde jeg brugt Transparent datakryptering(TDE) for få kolonner på databasen. Forespørgslen rapporterede, at du ikke kan bruge TT_TBS, når du har krypterede kolonner. Så jeg var nødt til at dekryptere de kolonner, som jeg krypterede ved hjælp af en forespørgsel som.
vælg * fra dba_encrypted_columns;
ALTER TABLE konto modificere (Kortholder dekryptere);
efter dekryptering af kolonnerne. Vi fortsætter videre
1. Tjek den ENDISKE version af både kilde og mål ved hjælp af nedenstående script:
—
— Hvad er de tilgængelige Transportable Tablespace Platform muligheder?
—
vælg
platformnavn
, endian_format
fra V$transportable_platform
Bestil efter platformnavn
;
—
— hvad er den nuværende ENDIAN-ness af min database og platform?
—
vælg
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 “lille” eller “stor”. Hvis endian er den samme på både mål og kilde, ingen grund til at gå til transportabel tablespace. Du kan blot eksportere tablespace og importere den til målet. Hvis ikke fortsæt som nedenfor
2. Ændre tablespace og sætte det i skrivebeskyttet tilstand på Kilde. I vores eksempel transporterer vi en tablespace kaldet TEST til målserveren.
ALTER TABLESPACE test skrivebeskyttet;
3. Eksporter nu tablespace-metadataene.
##vinduer# # #
eksp USERID=’system/oracle@Source as SYSDBA’ TRANSPORT_TABLESPACE=y TABLESPACES=test FILE=test_repository.dmp log=test_repository.TST
### # # #
eksp \ ‘sys / oracle as SYSDBA \’ TRANSPORT_TABLESPACE=y TABLESPACES=test FILE=test_repository.dmp log=test_repository.
gå til mål og kopier dumpfile til ethvert sted sammen med datafilerne i det pågældende tablespace.
imp \’sys/oracle AS SYSDBA\’ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.DMP datafiler= ‘ users_01.dbf’
4. Till ovenfor er for, når du eksporterer en tablespace til en maskine med samme endian oplysninger. Hvis du en anden endian fortsætter som nedenfor. Vi vil konvertere fra Solaris 64-bit SPARC(stor) til vinduer 32-bit (lille)
5. Konverter datafiler ved hjælp af RMAN og db_file_name_convert
#brug ikke denne metode: på Kildemaskine: med originalt filnavn
RMAN > konverter tablespace ‘TEST’
til platform ‘Microsoft vinduer IA (32-bit)’
format=’ / datafiler / rmanbkp/ % N_ % f ‘
parallelisme = 4;
## brug denne metode: på Kildemaskine: Med konverteret filnavn filnavn
RMAN > konverter tablespace’TEST’
2 >til platform ‘Microsoft vinduer IA (32-bit)’
3>db_file_name_convert ‘/datafiler/oradata/SV’,’/datafiler/rmanbkp’
4> parallelisme = 4;
når filerne er konverteret, kan den findes i ‘/ datafiles / rmanbkp’. Kopier disse konverterede filer sammen med metadata dump af TT_TBS og sætte det på source server og køre import:
imp USERID= ‘system / adgangskode@target as SYSDBA’
TRANSPORT_TABLESPACE=y
datafiler=’C:\datafiles\test01.DBF’, ‘ C:\datafiles\test02.DBF ‘
TABLESPACES=test
fil=test_repository.dmp
i ovenstående tilfælde konverterede vi filerne på kildeplatformen. Du kan dog også gøre det på målplatformen. For eksempel kan du kopiere fil test01.dbf sammen med metadata dump på en Vinduer Server 2003 32-bit mål maskine og konvertere det der:
RMAN> konverter
2 > datafil ‘c:/users01.DBF ‘ # # mappe, hvor du vil sætte din datafil fra kildeserver
3 > format ‘c:/datafiles/rmanbkp/%N_%f’ # # directory hvor du får konverteret fil
4 > ;
denne tilgang opretter en fil i det format, der er angivet i biblioteket.
men hvorfor vil du gerne konvertere datafilerne på målplatformen, præcis? En af grundene kan være kortere nedetid, hvilket kræver, at tablespaces kun skal læses kun i varigheden af kopien til målværten. Du kan tredoble spejlet datafilen, gøre tablespace skrivebeskyttet, bryde det tredje spejl og straks gøre tablespace læse/skrive. Dette tredje spejl kunne derefter monteres på målsystemet og konverteres i fritiden. Dette arrangement minimerer den varighed, som tablespace skal forblive skrivebeskyttet.
en anden grund kunne være ydeevne. OLTP-databasen kan være under konstant belastning, og ved hjælp af RMAN-konverteringsoperationen kan systemet belastes mere end ønsket. I stedet kan konverteringen aflæsses til datalagerserveren, hvor flere CPU ‘ er normalt er tilgængelige til parallelle operationer.
