Transportable Tablespace na różnych platformach
___________________________________________________
w naszym przykładzie przetransportujemy tablespace o nazwie TEST. Tablespace powinny być samodzielne bez żadnych obiektów odnoszących się do innych tablespaces tak do tego sprawdzić, czy tablespace OS autonomiczne za pomocą poniższego zapytania:
Uruchom dbms_tts.transport_set_check (’TEST’, TRUE, TRUE);
SELECT * FROM transport_set_violations;
jeśli masz powiązane obiekty. Upuść te obiekty z przestrzeni testowej (należy pamiętać, że odbywa się to w środowisku testowym, dzięki czemu mogę łatwo upuścić powiązane obiekty. Nie upuszczaj żadnych przedmiotów bez konsultacji ze swoim starszym DBA w środowisku produkcyjnym. Nigdy nie wiadomo, jaki obiekt ma zależności. Załóżmy, że masz indeksy w testowej przestrzeni stołowej wskazujące na tabele w innej przestrzeni stołowej. Możesz bezpiecznie przenosić te indeksy za pomocą poniższej procedury pl / sql:
begin
for c1 in (select index_name A1 from user_indexes)
loop
execute immediate 'alter index '||c1.A1 / / 'rebuild online tablespace <TABLESPACE name>’;
End loop;
end;
/
teraz kontynuuj i ponownie sprawdź naruszenia. Jeśli pojawi się błąd jak:
SELECT * FROM transport_set_violations;
—————————
naruszenie 46: skontaktuj się z Pomocą techniczną Oracle
naruszenie 46: skontaktuj się z Pomocą techniczną Oracle
naruszenie 46 : skontaktuj się z Pomocą techniczną Oracle
Uruchom to zapytanie, aby sprawdzić, dlaczego naruszenie dotyczy
SELECT TRIM(OBJ1_OWNER) || ’, ’ || TRIM(OBJ1_NAME) || ’, ’ ||
TRIM (OBJ1_SUBNAME)//’, ’ / / TRIM (OBJ1_TYPE) || ’, ’ ||
TRIM (TS1_NAME)||’, ’ / / TRIM (OBJ2_OWNER) || ’, ’ ||
TRIM (OBJ2_SUBNAME)//’, ’ / / TRIM (OBJ2_SUBNAME) || ’, ’ ||
TRIM (OBJ2_TYPE)||’, ’ / / TRIM(TS2_NAME) || ’, ’ ||
TRIM (CONSTRAINT_NAME)||’, ’ / / TRIM(REASON)
FROM PLUGGABLE_SET_CHECK
WHERE MESG_ID=46;
to da wynik tego, co dokładnie jest naruszeniem dla przenośnej powierzchni stołu. Napraw te naruszenia i rozpocznij rzeczywistą procedurę transportu łyżki stołowej. W moim przykładzie użyłem Transparent Data Encryption(TDE) dla kilku kolumn w bazie danych. W zapytaniu podano, że nie można użyć TT_TBS, gdy masz zaszyfrowane kolumny. Więc musiałem odszyfrować kolumny, które zaszyfrowałem za pomocą zapytania takiego jak.
SELECT * FROM dba_encrypted_columns;
Zmień konto tabeli Modyfikuj (odszyfruj posiadacza karty);
po odszyfrowaniu kolumn. Idziemy dalej
1. Sprawdź wersję ENDIAN zarówno źródła, jak i celu za pomocą poniższego skryptu:
—
— jakie są dostępne możliwości platformy Transportable Tablespace?
—
SELECT
platform_name
, endian_format
FROM v$transportable_platform
ORDER BY platform_name
;
—
— jaka jest aktualna wartość mojej bazy danych i platformy?
—
wybierz
D.name
, TP.endian_format
FROM
v$transportable_platform TP
, v$database D
WHERE TP.platform_name = D. platform_name
;
zgłosi, czy ENDIAN jest „mały”, czy „duży”. Jeśli endian jest taki sam zarówno na celu, jak i źródle, nie ma potrzeby sięgania po przenośną powierzchnię stołu. Możesz po prostu wyeksportować powierzchnię stołu i zaimportować ją do celu. Jeśli nie postępować jak poniżej
2. Zmień powierzchnię stołu i ustaw go w trybie tylko do odczytu na źródle. W naszym przykładzie przetransportujemy tablespace o nazwie TEST na serwer docelowy.
Zmień test TABLESPACE tylko do odczytu;
3. teraz wyeksportuj metadane przestrzeni tabel.
##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
przejdź do target i skopiuj dumpfile do dowolnej lokalizacji wraz z plikami danych tej przestrzeni.
imp \’sys/oracle AS SYSDBA\’ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.DMP datafiles= ’ users_01.dbf’
4. Do powyższego jest dla, gdy eksportujesz tablespace do maszyny z tej samej informacji endian. Jeśli inny endian postępować jak poniżej. Przekonwertujemy z Solarisa 64-bitowego SPARC(BIG) Na Windows 32-bitowy (Little)
5. Konwertuj pliki danych za pomocą RMAN i db_file_name_convert
#nie używaj tej metody: na maszynie źródłowej: z oryginalną nazwą pliku
RMAN>Konwertuj tablespace 'TEST’
na platformę 'Microsoft Windows IA (32-bit)’
format=’/datafiles/rmanbkp/%N_%f ’
równoległość = 4;
## użyj tej metody: na maszynie źródłowej: Z przekonwertowaną nazwą pliku nazwa pliku
RMAN>Konwertuj tablespace 'TEST’
2>na platformę 'Microsoft Windows IA (32-bit)’
3>db_file_name_convert '/datafiles/ORADATA/SWX’,’/datafiles/RMANBKP’
4> równoległość = 4;
po przekonwertowaniu plików można go znaleźć w '/datafiles / rmanbkp’. Skopiuj te przekonwertowane pliki wraz z zrzutem metadanych TT_TBS i umieść go na serwerze źródłowym i uruchom 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
w powyższych przypadkach przekonwertowaliśmy pliki na platformę źródłową. Można to jednak zrobić również na platformie docelowej. Na przykład możesz skopiować plik test01.dbf wraz z zrzutem metadanych na 32-bitowym komputerze docelowym Windows Server 2003 i przekonwertować go tam:
RMAN> convert
2> datafile „c:/users01.dbf ’ # # katalog, w którym umieścisz swój plik danych z serwera źródłowego
3> format 'c:/datafiles/rmanbkp/%N_%f’ # # katalog gdzie dostaniesz skonwertowany plik
4 > ;
to podejście utworzy plik w formacie określonym w katalogu.
ale po co dokładnie konwertować pliki danych na docelową platformę? Jednym z powodów może być krótszy czas przestoju, który wymaga, aby przestrzenie tabel były tylko do odczytu tylko przez czas kopiowania do hosta docelowego. Możesz potroić lustro pliku danych, sprawić, że powierzchnia stołu będzie tylko do odczytu, złamać trzecie lustro i natychmiast dokonać odczytu/zapisu powierzchni stołu. To trzecie lustro mogło być następnie zamontowane na systemie docelowym i przekształcone w czasie wolnym. Taki układ minimalizuje czas, przez który przestrzeń stołu musi pozostać tylko do odczytu.
innym powodem może być wydajność. Baza danych OLTP może być stale obciążana, a Użycie operacji konwersji RMAN może bardziej obciążać system niż jest to pożądane. Zamiast tego konwersja może zostać przeniesiona do serwera hurtowni danych, gdzie zwykle dostępnych jest więcej procesorów do operacji równoległych.
