Home ORDIX AG             Dienstleistung             Trainingsshop    Kunden / Referenzen Aktuelles    Kontakt
Home  Pfeil  ORDIX News  Pfeil  2/2006  Pfeil  Datenbanken
suche: 
Der Artikel richtet sich an Datenbankadministratoren und Entscheider, die sich über weitere neue Features der Version 10.2 informieren wollen.

Glossar

Recovery Manager (RMAN)
Oracles Tool zur Sicherung von Oracle Datenbanken.
Transportable Tablespace
Ein Verfahren, um sehr einfach und schnell Tablespaces von einer Oracle Datenbank in eine andere zu übertragen.
Externe Tabellen
Tabellen, die in der Datenbank definiert, deren Daten aber außerhalb gespeichert sind.
BFILE
Binäre Daten, die im Filesystem gespeichert werden, aber auf die mit Datenbankmitteln zugegriffen werden kann.
Directory
Ein directory definiert einen Alias für ein Verzeichnis im Filesystem.

Neues bei Oracle: 10gR2 (Teil III)

RMAN Convert Database

In der ORDIX News 1/2006, Seite 4, beschäftigten wir uns mit den neuen Data Guard Möglichkeiten von Oracle 10gR2. In dieser Ausgabe werden wir weitere Features näher betrachten.

Cross-Platform Database Transport

Wie sieht der übliche Weg aus, den wir bei einer Migration von einer Serverplattform zu einer anderen, z. B. von Sun zu HP, beschreiten?

Wir exportieren (exp/Datapump) die Daten aus der aktuellen Plattform und importieren (imp/Datapump) sie auf der neuen Plattform. Meist geht damit auch eine Migration auf ein neueres Oracle Release einher. Insgesamt ein sehr aufwändiges Verfahren.

Ab Oracle 10gR2 steht uns dafür ein neuer Weg zur Verfügung. Dieser Weg heißt Cross-Platform Database Transport. Das passende Recovery Manager (RMAN) Kommando heißt CONVERT DATABASE.

Rückblick

Zur Erinnerung: Seit Oracle 10gR1 besteht die Möglichkeit, mit dem Recovery Manager transportable Tablespaces zwischen beliebigen Plattformen zu verschieben. Einen Überblick über die unterstützten Plattformen sowie das zugrunde liegende SQL-Statement, das diese Liste liefert, finden Sie in Abbildung 1.

SQL> select * from v$transportable_platform order by platform_id;
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
1 Solaris[tm] OE (32-bit) Big
2 Solaris[tm] OE (64-bit) Big
3 HP-UX (64-bit) Big
4 HP-UX IA (64-bit) Big
5 HP Tru64 UNIX Little
6 AIX-Based Systems (64-bit) Big
7 Microsoft Windows IA (32-bit) Little
8 Microsoft Windows IA (64-bit) Little
9 IBM zSeries Based Linux Big
10 Linux IA (32-bit) Little
11 Linux IA (64-bit) Little
12 Microsoft Windows 64-bit for AMD Little
13 Linux 64-bit for AMD Little
15 HP Open VMS Little
16 Apple Mac OS Big
Abb. 1: Unterstützte Zielplattformen für einen transportablen Tablespace auf einer beliebigen Plattform.

Nun wollen wir betrachten, wie das Ganze funktioniert.

Voruntersuchung Teil 1

Bevor wir mit dem Transport der Datenbank beginnen, untersuchen wir, ob der von uns gewünschte Pfad unterstützt wird.

Ein select * from v$DB_TRANSPORTABLE_PLATFORM auf einem Linux Server gibt einen ersten Überblick über die unterstützten Plattformen (siehe Abbildung 2).

PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
7 Microsoft Windows IA (32-bit) Little
10 Linux IA (32-bit) Little
5 HP Tru64 UNIX Little
11 Linux IA (64-bit) Little
15 HP Open VMS Little
8 Microsoft Windows IA (64-bit) Little
13 Linux 64-bit for AMD Little
12 Microsoft Windows 64-bit for AMD Little
17 Solaris Operating System (x86) Little
Abb. 2: Unterstützte Plattformen auf einem Linux Server.

Zusätzlich hilft die Funktion DBMS_TDB.CHECK_DB bei der Voranalyse.

Schauen wir uns das Ganze an einem Beispiel an. Dabei wollen wir von Linux IA (32-bit) nach Linux 64-bit for AMD wechseln. Den passenden String für den Plattformnamen erhalten wir aus dem Ergebnis der vorherigen Abfrage.

Vor dem Ausführen dieses Packages und für die weiteren Schritte muss die Datenbank read-only geöffnet werden, da es ansonsten zu einer entsprechenden Fehlermeldung kommt. Das kleine Skript in Abbildung 3 hilft uns dabei.

set serveroutput on
declare
db_ready boolean;
begin
db_ready := dbms_tdb.check_db(
	'Linux 64-bit for AMD', 
	dbms_tdb.skip_none);
end;
/
  
PL/SQL procedure successfully completed.
Abb. 3: Skript zum Aufruf der Funktion DBMS_TDB.CHECK_DB.

Damit ist endgültig klar, dass einer "direkten" Migration nichts im Weg steht.

Voruntersuchung Teil 2

Vor der Konvertierung müssen wir noch untersuchen, ob unsere Datenbank externe Tabellen, BFILEs oder directories enthält. Diese können von CONVERT DATABASE nicht bearbeitet werden und müssen separat behandelt, d. h. mit Betriebssystemmitteln kopiert werden. Zur Ermittlung gibt es die DBMS_TDB.CHECK_EXTERNAL Funktion.

Auch hier hilft uns ein kleines Skript (siehe Abbildung 4).

set serveroutput on
declare
external boolean;
  begin
    external := dbms_tdb.check_external;
  end;

The following directories exist in the database:
SYS.DATA_PUMP_DIR, SYS.ADMIN_DIR, SYS.WORK_DIR

PL/SQL procedure successfully completed.
Abb. 4: Skript zur Ermittlung von externen Tabellen, BFILEs und directories.

Konvertierung

Nach diesen Vorarbeiten ist unsere Datenbank fertig für das Konvertieren auf die neue Plattform.

Das RMAN Kommando CONVERT DATABASE erzeugt dabei die drei notwendigen Bestandteile:

  1. Eine vollständige Kopie aller Datenbankdateien
  2. Ein Transport Skript zum Anlegen der Datenbank auf dem neuen Server
  3. Ein pfile für die neue Datenbank

Ein Beispiel mit der entsprechenden Ausgabe liefert Abbildung 5. Die hier entstandenen Dateien werden nun auf den neuen Server kopiert.

CONVERT DATABASE NEW DATABASE 'newdb'
transport script '/tmp/transport/transportskript'
to platform 'Linux 64-bit for AMD'
db_file_name_convert '/oradata/ak102' '/tmp/transport';
-------------------------------------------------------------
Starting convert at 05.04.06
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=42 devtype=DISK

Directory SYS.DATA_PUMP_DIR found in the database
Directory SYS.ADMIN_DIR found in the database
Directory SYS.WORK_DIR found in the database

User SYS with SYSDBA and SYSOPER privilege found in password file
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00001 name=/oradata/ak102/system01.dbf
converted datafile=/tmp/transport/system01.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:35
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00002 name=/oradata/ak102/undotbs01.dbf
converted datafile=/tmp/transport/undotbs01.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00003 name=/oradata/ak102/sysaux01.dbf
converted datafile=/tmp/transport/sysaux01.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00004 name=/oradata/ak102/users01.dbf
converted datafile=/tmp/transport/users01.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
Run SQL script /tmp/transport/transportskript on the target platform 
	to create database
Edit init.ora file /oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora. 
This PFILE will be used to create the database on the target platform
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the 
	target platform
To change the internal database identifier, use DBNEWID Utility
Finished backup at 05.04.06
Abb. 5: Kommando und Ergebnis für die Konvertierung einer Datenbank mit CONVERT DATABASE.

Transport Skript

Nun schauen wir uns das Transport Skript näher an, das RMAN für uns gebaut hat (siehe Abbildung 6). Wir stellen fest, dass es sich um ein ganz normales create controlfile Skript handelt, da beim CONVERT DATABASE zwar die Datenbank Dateien gesichert wurden, aber kein Backup der Control-Datei angelegt wurde.

STARTUP NOMOUNT PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora'
CREATE CONTROLFILE REUSE SET DATABASE "NEWDB" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 1168
LOGFILE
  GROUP 1 (
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-145_T-1_A-565987116_00hfpe8c',
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-145_T-1_A-565987116_01hfpe8c'
  ) SIZE 10M,
  GROUP 2 (
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-143_T-1_A-565987116_00hfpe8c',
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-143_T-1_A-565987116_01hfpe8c'
  ) SIZE 10M,
  GROUP 3 (
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-144_T-1_A-565987116_00hfpe8c',
    '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-144_T-1_A-565987116_01hfpe8c'
  ) SIZE 10M
DATAFILE
  '/tmp/transport/system01.dbf',
  '/tmp/transport/undotbs01.dbf',
  '/tmp/transport/sysaux01.dbf',
  '/tmp/transport/users01.dbf'
CHARACTER SET WE8ISO8859P1;
-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE 
		'/oracle/product/10.2/dbs/data_D-NEWDB_I-3659488684_TS-TEMP_FNO-1_00hfpe8c'
     SIZE 20971520  AUTOEXTEND ON NEXT 655360  MAXSIZE 536870912 ;
-- End of tempfile additions.
--
set echo off
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prompt * Your database has been created successfully!
prompt * There are many things to think about for the new database. Here
prompt * is a checklist to help you stay on track:
prompt * 1. You may want to redefine the location of the directory objects.
prompt * 2. You may want to change the internal database identifier (DBID) 
prompt *    or the global database name for this database. Use the 
prompt *    NEWDBID Utility (nid).
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SHUTDOWN IMMEDIATE 
STARTUP UPGRADE PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora'
@@ ?/rdbms/admin/utlirp.sql 
SHUTDOWN IMMEDIATE 
STARTUP PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora'
-- The following step will recompile all PL/SQL modules.
-- It may take serveral hours to complete.
@@ ?/rdbms/admin/utlrp.sql 
set feedback 6;
Abb. 6: Transport Skript. (vergrößern!).

Dadurch werden wir automatisch dazu gebracht, die Pfade zu den Dateien auf den gewünschten Stand zu bringen. Das von CONVERT DATABASE angelegte pfile ist selbstverständlich vorher den Gegebenheiten anzupassen (siehe Abbildung 7). 

# Please change the values of the following parameters:
  control_files            	= "/oracle/product/10.2/dbs/cf_D-NEWDB_id-3659488684_00hfpe8c"
  db_recovery_file_dest    	= "/oracle/product/10.2/dbs/flash_recovery_area"
  db_recovery_file_dest_size= 2147483648
  background_dump_dest     	= "/oracle/product/10.2/dbs/bdump"
  user_dump_dest           	= "/oracle/product/10.2/dbs/udump"
  core_dump_dest           	= "/oracle/product/10.2/dbs/cdump"
  audit_file_dest          	= "/oracle/product/10.2/dbs/adump"
  db_name                  	= "NEWDB"

# Please review the values of the following parameters:
  __shared_pool_size       	= 54525952
  __large_pool_size        	= 4194304
  __java_pool_size         	= 4194304
  __streams_pool_size      	= 0
  __db_cache_size          	= 37748736
  remote_login_passwordfile		= "SHARED"
  db_domain                	= ""

# The values of the following parameters are from source database:
  processes                	= 50
  sessions                 	= 60
  sga_max_size             	= 104857600
  nls_territory            	= "GERMANY"
  sga_target               	= 104857600
  db_block_size            	= 8192
  compatible               	= "10.2.0.1.0"
  db_file_multiblock_read_count	= 16
  db_flashback_retention_target	= 120
  undo_management         		= "AUTO"
  undo_tablespace          	= "UNDOTBS1"
  job_queue_processes      	= 10
  open_cursors             	= 300
  pga_aggregate_target     	= 16777216
Abb. 7: Das von CONVERT DATABASE angelegte pfile. (vergrößern!).

Fazit

Sind alle Dateien auf das neue System gespielt, das "Transport Skript" und das Pfile angepasst, so steht - letztlich mit vergleichsweise wenig Aufwand - die Datenbank auf einem neuen Server zur Verfügung. Allerdings funktioniert das in dieser Form nur für eine "endian Variante".

Oracle hat uns jedoch bereits mit 10g R1 gezeigt, dass es möglich ist, Tablespaces von einer Plattform auf eine beliebige andere Plattform zu migrieren. Von daher ist CONVERT DATABASE zwar eine gute Idee, aber vollständig ist das Ganze erst, wenn man damit Datenbanken beispielweise von Windows nach Solaris Sparc konvertieren kann.

Sie wollen mehr über Oracles Recovery Manager (RMAN) erfahren? Besuchen Sie den 4-tägigen ORDIX Recovery Manager Workshop. Weitere Informationen zu diesem Workshop finden Sie in unserem Online-Trainingsshop unter http://training.ordix.de.

Andreas Kother (info@ordix.de).