szállítható Tablespace különböző platformokon
___________________________________________________
példánkban egy teszt nevű táblaterületet szállítunk. A tablespace legyen önálló nélkül tárgyak hivatkozva más tablespaces így, hogy ellenőrizze, hogy a tablespace os önálló használatával alábbi lekérdezés:
hajtsa végre a dbms_tts parancsot.transport_set_check (‘teszt’, TRUE, TRUE);
válasszon * – t a transport_set_violations közül;
ha kereszthivatkozott objektumokkal rendelkezik. Dobja el ezeket az objektumokat a teszt táblaterületről (kérjük, vegye figyelembe, hogy ez tesztkörnyezetben történik, így könnyen le tudom dobni a kereszthivatkozott objektumokat. Ne ejtsen le semmilyen tárgyat anélkül, hogy konzultálna a vezető DBA-val egy termelési környezetben. Soha nem tudhatod, hogy melyik tárgynak milyen függősége van. Tegyük fel, hogy a teszt táblaterületében indexek vannak, amelyek egy másik táblaterület tábláira mutatnak. Biztonságosan áthelyezheti ezeket az indexeket az alábbi pl / sql eljárás használatával:
kezdődik
a c1 in (Válassza index_name A1 származó user_indexes)
hurok
végre azonnali ‘alter index ‘||c1.a1 / / ‘ online táblaterület újjáépítése <táblaterület neve>’;
end loop;
end;
/
most folytassa és ellenőrizze újra a jogsértéseket. Ha olyan hibát kap, mint:
válasszon * FROM transport_set_violations;
jogsértések
—————————
megsértése 46: kapcsolat Oracle támogatás
megsértése 46: kapcsolat Oracle támogatás
megsértése 46 : kapcsolat Oracle támogatás
futtassa ezt a lekérdezést, hogy ellenőrizze, miért a jogsértés dobott
válassza 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 (ok)
FROM PLUGGABLE_SET_CHECK
ahol MESG_ID=46;
ez megadja a kimenetet arról, hogy pontosan mi a megsértés a hordozható tablespace számára. Javítsa ki ezeket a jogsértéseket, és indítsa el a táblaterület szállításának tényleges eljárását. Példámban átlátszó adattitkosítást(TDE) használtam az adatbázis néhány oszlopához. A lekérdezés arról számolt be, hogy titkosított oszlopok esetén nem használható a TT_TBS. Tehát vissza kellett dekódolnom azokat az oszlopokat, amelyeket egy lekérdezéssel titkosítottam.
válasszon * – tól dba_encrypted_columns;
ALTER TABLE fiók módosítása (kártyabirtokos dekódolása);
az oszlopok visszafejtése után. Tovább folytatjuk
1. Ellenőrizze mind a forrás, mind a cél ENDIAN verzióját az alábbi szkript segítségével:
—
— melyek a rendelkezésre álló hordozható Tablespace Platform lehetőségek?
—
válasszon
platform_neve
, endian_format
a v$transportable_platform
rendezés platform_neve szerint
;
—
— mi az adatbázisom és a platformom jelenlegi endi-ssége?
—
SELECT
D.name
, TP. endian_format
a
v$transportable_platform TP
, v$adatbázis D
ahol TP.platform_name = D. platform_name
;
jelenteni fogja, ha az ENDIAN “kicsi” vagy “nagy”. Ha az endian ugyanaz mind a cél, mind a forrás, akkor nem kell hordozható táblaterületre menni. Egyszerűen exportálhatja a táblaterületet, és importálhatja azt a célhoz. Ha nem jár, mint az alábbi
2. Változtassa meg a táblaterületet, és állítsa csak olvasható módba a forrásra. Példánkban egy teszt nevű táblaterületet szállítunk a célszerverre.
ALTER TABLESPACE teszt csak olvasható;
3. most exportálja a tablespace metaadatait.
##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
menjen a célhoz, és másolja a dumpfile-t bármely helyre az adott táblaterület adatfájljaival együtt.
imp \’sys/oracle as SYSDBA\’ TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.dmp adatfájlok= ‘ users_01.dbf’
4. Till fent van, ha exportál egy tablespace egy gép ugyanazt endian információkat. Ha egy másik endian jár, mint az alábbiakban. A Solaris 64 bites SPARC(BIG)-ről Windows 32 bites(Little)
5-re konvertálunk. Az adatfájlok konvertálása az RMAN és a db_file_name_convert használatával
#ne használja ezt a módszert: Forrásgépen: eredeti fájlnévvel
RMAN> a ‘TEST’
táblaterület konvertálása ‘Microsoft Windows IA (32 bites)’
format= ‘/ datafil/rmanbkp / %N_ % f ‘
párhuzamosság = 4;
## használja ezt a módszert: Forrásgépen: Konvertált fájlnévvel fájlnév
rman>’TEST’
2> táblaterület konvertálása ‘Microsoft Windows IA (32 bites)’
3> db_file_name_convert ‘/datafil/oradata/SWX’,’/datafil/rmanbkp’
4> párhuzamosság = 4;
a fájlok konvertálása után megtalálható a ‘/datafiles/rmanbkp’könyvtárban. Másolja ezeket a konvertált fájlokat együtt metaadatok kiírása TT_TBS és tedd a forráskiszolgáló és fuss import:
imp USERID= ‘rendszer / jelszó @ cél mint SYSDBA’
TRANSPORT_TABLESPACE = y
DATAFIL=’C:\datafiles\test01.DBF’,’C:\datafiles\test02.DBF ‘
TABLESPACES=teszt
FILE=test_repository.dmp
a fenti esetekben a fájlokat a forrásplatformon konvertáltuk. Ezt azonban a célplatformon is megteheti. Például másolhatja a test01 fájlt.dbf a metaadatok kiíratásával együtt egy Windows Server 2003 32 bites célgépen, és ott konvertálja:
RMAN> konvertálás
2> adatfájl ‘c:/users01.dbf ‘ ##könyvtár, ahová az adatfájlt a forráskiszolgálóról helyezi
3> formátum ‘c:/datafiles/rmanbkp/%N_%f’ # # könyvtár, ahol kapsz konvertált fájl
4> ;
ez a megközelítés létrehoz egy fájlt a könyvtárban megadott formátumban.
de miért szeretné pontosan átalakítani az adatfájlokat a célplatformon? Ennek egyik oka lehet a rövidebb állásidő, amely megköveteli, hogy a táblaterületek csak olvasható állapotban legyenek, csak a célállomásra történő másolás időtartama alatt. Lehet tripla tükör a datafile, hogy a tablespace csak olvasható, megtörni a harmadik tükör, és azonnal, hogy a tablespace olvasni / írni. Ezt a harmadik tükröt ezután fel lehet szerelni a célrendszerre, és szabadidejében átalakítani. Ez az elrendezés minimalizálja azt az időtartamot, amely alatt a táblaterületnek csak olvashatónak kell maradnia.
egy másik ok lehet a teljesítmény. Előfordulhat, hogy az OLTP adatbázis állandó terhelés alatt áll, és az RMAN convert művelet használata a kívántnál jobban megterhelheti a rendszert. Ehelyett a konverziót ki lehet tölteni az adattárház szerverére, ahol általában több CPU áll rendelkezésre a párhuzamos műveletekhez.
