Transportable Tablespace over verschillende Platforms
___________________________________________________
in ons voorbeeld transporteren we een tablespace genaamd TEST. De tablespace moet op zichzelf staan zonder objecten die verwijzen naar andere tablespaces, dus voor die controle of de tablespace os op zichzelf staat met behulp van onderstaande query:
DBMS_TTS uitvoeren.transport_set_check (‘TEST’, TRUE, TRUE);
selecteer * uit transport_set_violations;
als u objecten met kruisverwijzingen hebt. Drop die objecten uit de TEST tablespace (let op: dit wordt gedaan in een testomgeving, zodat ik de objecten met kruisverwijzingen gemakkelijk kan laten vallen. Laat geen objecten vallen zonder uw senior DBA te raadplegen in een productieomgeving. Je weet nooit welk object welke afhankelijkheid heeft. Stel dat u indexen in de testtablespace hebt die naar tabellen in een andere tablespace wijzen. U kunt veilig verplaatsen die indexen met behulp van onderstaande pl / sql procedure:
begin
voor c1 in (selecteer index_naam a1 uit user_indexes)
loop
voer onmiddellijk ‘alter index ‘||c1 uit.a1 / / ‘ rebuild online tablespace <tablespace name>’;
End loop;
end;
/
ga nu verder en controleer overtredingen opnieuw. Als je een fout als:
selecteer * uit transport_set_violations;
schendingen
—————————
overtreding 46: neem contact op met Oracle support
overtreding 46: neem contact op met Oracle support
overtreding 46 : neem contact op met Oracle support
deze query Uitvoeren om te controleren waarom de strijd gooit
SELECTEER TRIMMEN(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(REDEN)
VAN PLUGGABLE_SET_CHECK
WAAR MESG_ID=46;
dit geeft de uitvoer van wat de overtreding precies is voor de transporteerbare tablespace. Fix die schendingen en start de werkelijke procedure voor het vervoer van de tafelruimte. In mijn voorbeeld had ik Transparent Data Encryption(TDE) gebruikt voor enkele kolommen in de database. De query meldde dat u TT_TBS niet kunt gebruiken als u kolommen versleuteld hebt. Dus ik moest de kolommen die ik versleuteld met behulp van een query als decoderen.
selecteer * uit dba_encrypted_columns;
TABELACCOUNT wijzigen (Kaarthouder decoderen);
na het decoderen van de kolommen. We gaan verder
1. Controleer de ENDIAN versie van zowel bron als doel met behulp van onderstaande script:
—
— Wat zijn de beschikbare Transportable Tablespace Platform mogelijkheden?
—
SELECTEER
platform_name
,endian_format
FROM v$transportable_platform
OM DOOR platform_name
;
—
— Wat is de huidige ENDIAN-heid van mijn database en platform?
—
SELECTEER
D. naam
,TP.endian_format
VAN
v$transportable_platform TP
,v$database D
WAAR TP.platform_name = D. platform_name
;
het zal rapporteren of het ENDIAN “klein” of “groot”is. Als de endian hetzelfde is op zowel doel als bron, hoeft u niet te gaan voor transporteerbare tablespace. U kunt gewoon de tablespace exporteren en importeren naar het doel. Zo niet, ga dan verder zoals hieronder
2. Wijzig de tablespace en zet het in alleen-lezen modus op de bron. In ons voorbeeld transporteren we een tablespace genaamd TEST naar de doelserver.
alter TABLESPACE test alleen-lezen;
3. exporteer nu de tablespace metadata.
##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
Ga naar doel en kopieer het dumpbestand naar elke locatie samen met de databestanden van die tablespace.
imp \ ‘sys / oracle AS SYSDBA \’ TABLESPACES = test TRANSPORT_TABLESPACE = y FILE = test_repository.dmp datafiles= ‘ users_01.dbf’
4. Till hierboven is voor wanneer je een tablespace exporteert naar een machine met dezelfde endian informatie. Als u een andere endian ga verder zoals hieronder. We zullen converteren van Solaris 64-bit SPARC (BIG) naar Windows 32-bit(Little)
5. Converteer de databestanden met RMAN en db_file_name_convert
#gebruik deze methode niet: op bronmachine: met originele bestandsnaam
RMAN> converteer tablespace ‘TEST’
naar platform ‘ Microsoft Windows IA (32-bit)’
format=’ / datafiles / rmanbkp/ % N_ % f ‘
parallellisme = 4;
## gebruik deze methode: op de bronmachine: Met geconverteerde bestand bestandsnaam
RMAN> zetten tablespace ‘TEST’
2> naar platform ‘Microsoft Windows IA (32-bits)’
3> db_file_name_convert ‘/datafiles/oradata/SWX’,’/datafiles/rmanbkp’
4> parallellisme = 4;
Nadat de bestanden zijn geconverteerd kan worden gevonden in ‘/datafiles/rmanbkp’. Kopieer deze geconverteerde bestanden samen met metadata dump van TT_TBS en zet het op de bronserver en voer importeren uit:
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
in de bovenstaande gevallen hebben we de bestanden op het bronplatform geconverteerd. Echter, u kunt dat doen op het doelplatform ook. U kunt bijvoorbeeld het bestand test01 kopiëren.dbf samen met de metadata dump op een Windows Server 2003 32-bit doel machine en zet het daar:
RMAN> convert
2> databestand “c:/users01.dbf ‘# # directory where you ‘ ll put your datafile from source server
3> format ‘c:/datafiles/rmanbkp/%N_%f’ # # directory where you ‘ ll get converted file
4> ;
deze aanpak maakt een bestand aan in het formaat dat in de map is gespecificeerd.
maar waarom zou u de databestanden precies op het doelplatform willen converteren? Een reden zou kunnen zijn kortere downtime, die vereist dat de tablespaces alleen lezen staat alleen voor de duur van de kopie naar de doelhost. Je zou het databestand drievoudig kunnen spiegelen, de tablespace alleen-lezen maken, de derde spiegel breken en onmiddellijk de tablespace lezen / schrijven. Deze derde spiegel kan dan op het doelsysteem worden gemonteerd en op uw gemak worden omgebouwd. Deze regeling minimaliseert de duur waarvoor de tablespace alleen-lezen moet blijven.
een andere reden zou prestaties kunnen zijn. De OLTP database kan onder een constante belasting en het gebruik van de RMAN convert operatie kan het systeem meer dan gewenst belasten. In plaats daarvan, de conversie kan worden offload naar de data warehouse server, waar meer CPU ‘ s zijn meestal beschikbaar voor parallelle operaties.
