přenosný Tablespace napříč různými platformami
___________________________________________________
v našem příkladu dopravíme tabulkuprostor nazvaný TEST. Tablespace by měl být samostatný bez jakýchkoli objektů odkazujících na jiné stolní prostory, takže pro tuto kontrolu, zda je tablespace os Samostatně obsažený pomocí níže uvedeného dotazu:
spustit dbms_tts.transport_set_check (‚TEST‘, TRUE, TRUE);
vyberte * z transport_set_violations;
pokud máte křížově odkazované objekty. Drop tyto objekty z TEST tablespace (Upozorňujeme, že se to děje v testovacím prostředí, takže mohu klesnout křížově odkazované objekty snadno. Nenechávejte žádné předměty bez konzultace s nadřízeným DBA ve výrobním prostředí. Nikdy nevíte, jaký objekt má jakou závislost. Předpokládejme, že v testovacím prostoru máte indexy ukazující na tabulky v jiném prostoru tabulky. Tyto indexy můžete bezpečně přesunout pomocí níže uvedené procedury PL / sql:
začněte
pro c1 v (vyberte index_name a1 z user_indexes)
smyčka
spusťte okamžitý ‚alter index‘ | / c1.a1 / / ‚ rebuild online tablespace <tablespace name>‘;
end loop;
end;
/
nyní pokračujte a znovu zkontrolujte porušení. Pokud se zobrazí chyba jako:
vyberte * z transport_set_violations;
porušení
—————————
porušení 46: kontaktujte podporu Oracle
porušení 46: kontaktujte podporu Oracle
porušení 46 : kontaktujte podporu Oracle
spusťte tento dotaz a zkontrolujte, proč je porušení házení
vyberte 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 (REASON)
z PLUGGABLE_SET_CHECK
kde MESG_ID=46;
tím se získá výstup toho, co přesně je porušení pro přenosnou plochu stolu. Opravte tato porušení a spusťte skutečný postup pro přepravu stolu. V mém příkladu jsem použil transparentní šifrování dat (TDE) pro několik sloupců v databázi. Dotaz oznámil, že nelze použít TT_TBS, pokud máte šifrované sloupce. Takže jsem musel dešifrovat sloupce, které jsem zašifroval pomocí dotazu jako.
vyberte * z dba_encrypted_columns;
změnit účet tabulky upravit (dešifrovat držitele karty);
po dešifrování sloupců. Pokračujeme dále
1. Zkontrolujte ENDIAN verzi zdroje i cíle pomocí níže uvedeného skriptu:
—
— jaké jsou dostupné možnosti platformy pro přenos stolů?
—
SELECT
název_ platformy
, endian_format
z v$transportable_platform
Seřadit podle název_ platformy
;
—
— jaká je aktuální ENDIANITA mé databáze a platformy?
—
SELECT
D.name
, TP. endian_format
z
v$transportable_platform TP
, v$database D
kde TP.platform_name = D. platform_name
;
bude hlásit, zda je ENDIAN „malý“ nebo „velký“. Pokud je endian stejný jak na cíl, tak na zdroj, není třeba jít na přenosný stůl. Stůl můžete jednoduše exportovat a importovat do cíle. Pokud tomu tak není pokračovat jako níže
2. Změňte stůl a vložte jej do režimu pouze pro čtení na zdroji. V našem příkladu přeneseme tablespace nazvaný TEST na cílový server.
ALTER TABLESPACE test pouze pro čtení;
3. nyní exportujte metadata tablespace.
##Windows# # #
exp USERID= ‚system/oracle @ Source AS SYSDBA‘ TRANSPORT_TABLESPACE=y tablespace=test FILE=test_repository.dmp log=test_repository.txt
###Unix# # #
exp \’sys/oracle AS SYSDBA \‘ TRANSPORT_TABLESPACE=y tablespace=test FILE=test_repository.dmp log=test_repository.txt
přejděte na cíl a zkopírujte dumpfile na libovolné místo spolu s datovými soubory této tabulky.
imp \ ‚sys / oracle AS SYSDBA \‘ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.dmp datafiles=’users_01.dbf‘
4. Až výše je pro export tablespace do počítače se stejnými endianovými informacemi. Pokud jiný endian postupujete jako níže. Převedeme z Solaris 64-bit SPARC (velký) na Windows 32-bit(malý)
5. Převod datových souborů pomocí RMAN a db_file_name_convert
#nepoužívejte tuto metodu: na zdrojovém počítači: s původním názvem
RMAN> převést tablespace ‚TEST‘
na platformu ‚ Microsoft Windows IA (32-bit)‘
format=‘ / datafiles / rmanbkp / %N_%f ‚
paralelismus = 4;
## použijte tuto metodu: na zdrojovém stroji: S převedeným názvem souboru filename
RMAN> convert tablespace ‚TEST‘
2> to platform ‚Microsoft Windows IA (32-bit)‘
3> db_file_name_convert ‚/datafiles/oradata/SWX‘, ‚/datafiles/rmanbkp ‚
4> paralelismus = 4;
poté, co jsou soubory převedeny lze nalézt v ‚/ datafiles / rmanbkp‘. Zkopírujte tyto převedené soubory spolu s výpisem metadat TT_TBS a vložte je na zdrojový server a spusťte import:
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
ve výše uvedených případech jsme převedli soubory na zdrojovou platformu. Můžete to však udělat i na cílové platformě. Můžete například zkopírovat soubor test01.dbf spolu s výpisem metadat na 32bitovém cílovém počítači Windows Server 2003 a převést jej tam:
RMAN> převést
2> datový soubor ‚c:/users01.dbf ‚ # # adresář, kam vložíte datový soubor ze zdrojového serveru
3> formát ‚c:/datafiles/rmanbkp/%N_%f‘ # # adresář, kde získáte převedený soubor
4> ;
tento přístup vytvoří soubor ve formátu určeném v adresáři.
ale proč byste chtěli převést datové soubory na cílovou platformu, přesně? Jedním z důvodů může být kratší prostoje, což vyžaduje, aby tabulky byly pouze pro čtení pouze po dobu trvání kopie cílovému hostiteli. Dalo by se triple-zrcadlit datový soubor, aby tablespace pouze pro čtení, rozbít třetí zrcadlo, a okamžitě učinit tablespace číst / psát. Toto třetí zrcadlo pak mohlo být namontováno na cílový systém a přeměněno ve volném čase. Toto uspořádání minimalizuje dobu, po kterou musí stůl zůstat pouze pro čtení.
dalším důvodem může být výkon. Databáze OLTP může být pod konstantním zatížením a použití operace RMAN convert může napnout systém více, než je požadováno. Místo toho může být konverze přenesena na server datového skladu, kde je obvykle k dispozici více procesorů pro paralelní operace.
