Migration von Oracle 9i auf Oracle 10g bei der Deutschen Bahn AG

Migration von Oracle 9i auf Oracle 10g bei der Deutschen Bahn AG

KONFERENZ
Mittwoch, 10. November 2004
12h00, Variohalle 5
Migration von Oracle 9i auf Oracle 10g bei
der Deutschen Bahn AG
Jens Behring
its-people Hochtaunus GmbH, Oberursel
Schlüsselworte:
Oracle 10g, Migration, Transportable Tablespaces, Erfahrungsbericht
Zusammenfassung
Bei der DB Netz AG, einer Tochter der Deutschen Bahn AG, ist das geographische Auskunftssystem STREDA.X im Einsatz. Weiterentwicklungen sowie
Ergänzungen dieses Systems haben eine Migration notwendig werden lassen.
Der Vortrag beschreibt verschiedene Migrationswege: zum einen mittels der
DBNEWID Funktionalität, eines vorhandenen Offline-Backups sowie des
"Database Upgrade Assistent" von Oracle 10g, zum anderen mittels transportabler Tablespaces.
Probleme während und nach der Migration und die entsprechenden Lösungen
werden vorgestellt.
Einleitung
Im geographischen Auskunftssystem STREDA.X der DB Netz AG wird die heutige Ausstattung des Streckennetzes der Deutschen Bahn mit Elektronischen
Stellwerken abgebildet. Zusätzlich werden dort die Planungszustände d.h. die
mittelfristige und langfristige strategische Abdeckung des Streckennetzes mit
Elektronischen Stellwerken definiert.
Dieses System basierte bisher auf einer Oracle 9.2 Datenbank auf die mittels
OC4J, Apache oder HTMLDB zugegriffen wird.
Vorbereitung der Migration
Vor der Migration sollte natürlich ein Backup vorhanden sein, um jederzeit auf
die bisher vorhandene Umgebung zurückgreifen zu können. In unserem Fall
hatten wir das Problem, keinen separaten Rechner zur Verfügung zu haben, auf
dem die Migration durchgeführt werden konnte und nach derem erfolgreichen
Abschluss sämtliche Applikationen zu einem definierten Zeitpunkt umgestellt
werden konnten. Aus diesem Grund wurde parallel zur vorhandenen Produktiv-Datenbank auf dem gleichen Rechner eine zweite identische Datenbank
aufgesetzt und migriert. Zum Erstellen dieser Kopie wurde die Funktionalität
DBNEWID genutzt.
DBNEWID
DBNWEWID ist ein seit Oracle 9.2 vorhandenes Feature um den "Datenbanknamen" (DBNAME) und den "internal database identifier" (DBID) zu verändern. Bis zu diesem Zeitpunkt konnten Datenbankkopien durch Kopieren
der Datenbankdateien und Erzeugen von neuen Kontrolldateien erstellt werden, ein Ändern der DBID war allerdings nicht möglich.
Nach einer Änderung der DBID mittels DBNWEWID sind alle bisherigen Backups und Archive-Log-Dateien nicht mehr brauchbar, die Datenbank muss mit
der Option RESETLOGS gestartet werden.
Bei Änderung des Datenbanknamens muss lediglich daran gedacht werden,
den Initialisierungsparameter DB_NAME entsprechend zu ändern.
Die Nutzung von DBNEWID erwies sich als überaus einfach und problemlos. Es
waren nur folgende Statements nötig, um die vorhandene Datenbank umzubenennen:
SQL>SHUTDOWN IMMEDIATE
SQL>STARTUP MOUNT
C:\oracle\ora10\bin\nid TARGET=sys/sys@jbe DBNAME=jbe_2
SQL>SHUTDOWN IMMEDIATE
SQL>STARTUP MOUNT
SQL>ALTER DATABASE OPEN RESETLOGS;
Nachdem auf diese Art und Weise die vorhandene Datenbank umbenannt
wurde, konnte nun das ursprüngliche Backup der Originaldatenbank wieder
eingespielt werden und auf dem Rechner befanden sich zwei identische Datenbanken.
DBUA – Database Upgrade Assistant
Die Migration wurde mit dem "Database Upgrade Assistant" durchgeführt. Mit
Hilfe dieses Tools ist es möglich, Datenbanken der Versionen 8.0.6, 8i, 9.0.1
und 9.2.0 zu migrieren. Installierte Datenbanken dieser Versionen werden in
einer Auswahlliste präsentiert, aus der die zu migrierende Datenbank auszuwählen ist.
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
Oracle 10g benötigt einen sog. Auxiliary Tablespace, in dem Metadaten folgender Optionen bzw. Features hinterlegt werden:
Option / Feature
OLAP
Text
Ultra Search
Intermedia / Spatial
Workspace Manager
Data Mining
EM Repository
Streams
LogMiner
Logical Standby
Statspack
Job Scheduler
Schema
CWMLITE
CTSYS
WKSYS
ORDSYS
WMSYS
DMSYS
SYSMAN
SYS
SYSTEM
SYSTEM
PERFSTAT
SYS
Dieser Tablespace wird im zweiten Schritt angelegt. Der Anwender kann hier
die Lage sowie die Größe der Datendatei angeben.
In einem weiteren Schritt hat der Anwender die Wahl, den "Database Upgrade
Assistant" ein Backup durchführen zu lassen. Wird diese Option gewählt, so
wird im Falle eines Fehlers dieses Backup automatisch eingespielt. Andernfalls
muss dies durch den Anwender vorgenommen werden.
Sind alle Angaben getätigt, läuft der "Upgrade Assistant" im Grunde ohne
Problem durch. Lediglich beim ersten Versuch ergab sich ein Problem. Der
"Upgrade Assistant" hatte den Wert des Initalisierungsparameters OPEN_CURSORS von ursprünglich 100000 auf 32767 gesetzt und sich danach mit der
Fehlermeldung beendet, dass maximal ein Wert von 32766 erlaubt sei. Laut
Oracle ist dieses Problem aber mit dem Patch 10.1.0.3 behoben.
Einspielen des Patches 10.1.0.3
Kurz nach der Migration auf Oracle 10g wurde der Patch 10.1.0.3 ausgeliefert
und bei uns installiert. Bei der Installation dieses Patches kam es zur Fehlermeldung
"Mit den Programmen, die Sie ausgewählt haben, sind keine Dienste verknüpft".
Die Fehlerdetails enthielten den Hinweis
"orageneric10.dll (Prozesseinstiegspunkt kgmindl konnte in der Dynamic Link Library
nicht gefunden werden)"
Sowohl bei OTN als auch bei Metalink konnte zu dieser Fehlermeldung kein
Hinweis gefunden werden. Ein erneutes Aufrufen des Oracle Installers ergab,
dass die "Required Support Files" nicht installiert wurden. Ein erneuter Installationsversuch verlief erfolgreich.
Die Fehlermeldung konnte reproduziert werden, wenn bei einem Einspielen
des Patches ein SQL-Fenster geöffnet war. Vermutlich hat noch ein Prozess die
angegebene DLL blockiert und damit diesen Fehler verursacht.
Erfahrungen
Migration
Die Durchführung der Migration erwies sich, von kleinen Problemen abgesehen, als recht einfach. Der "Database Upgrade Assistent" erwiess sich als ein
sehr ausgereiftes Tool, um Datenbanken auf 10g zu migrieren. Die Migration
kann auch manuell über die Kommandozeile erfolgen. Diesen Weg haben wir
allerdings nicht ausprobiert.
TOAD
Leider war es nach der Migration nicht mehr möglich, mittels TOAD (Version
7.5) auf Tabellen, die Oracle-Spatial-Daten enthalten, zuzugreifen. Auch
externe Tabellen konnten nicht mehr angezeigt werden. Erst durch die Verwendung der neuen Version 8.0 konnten diese Probleme behoben werden.
Verbindungen zu Oracle 8.0.4 und älter
Unter Oracle 10g ist es nicht mehr möglich, sich gegen Datenbanken der Versionen 8.0.4 und früher zu verbinden. Dies betrifft sowohl die Verwendung
von SQL-Plus als auch von Datenbank-Links. Bei der Nutzung von DatenbankLinks ist es allerdings möglich, eine Oracle 9i Datenbank zwischenzuschalten
und somit Zugriff auf eine Datenbank der Version 8.0.4 zu erhalten (s. Abb. 1).
Abb. 1: Zugriff auf Datenbanken der Versionen 8.0.x
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
Hierzu wird auf einer Oracle 9i Datenbank ein View eingerichtet, der über
einen Datenbank-Link die Daten aus einer Datenbank der Version 8.0.4 erhält.
Auf den View in der Oracle 9i Datenbank kann nun über einen Datenbank-Link
aus Oracle 10g zugegriffen werden.
HTMLDB
Unsere HTMLDB-Anwendung (HTMLDB 10g) erfuhr nach der Migration eine
deutliche Performancesteigerung, ohne dass an der Anwendung etwas verändert wurde.
Apache
Die eigentliche Oracle 10g Installation benötigt nur noch eine CD. Dies wurde
dadurch erreicht, dass mit dieser CD nur die Datenbank installiert wird. Tools
wie die bereits erwähnte HTMLDB oder der Apache Webserver müssen von der
Companion CD installiert werden.
Optimizer
Bei einigen SQL-Statements ist zu beobachten, dass der Optimizer sich gegenüber der Oracle 9.2 Datenbank anders verhält. Unter Oracle 10g führen diese
Statements zu einem Full-Table-Scan, wo hingegen für das gleiche Statement
unter Oracle 9i ein Index genutzt wird. Auch eine Aktualisierung der Statistiken konnte dieses Problem bisher nicht beheben.
Initialisierungsparameter COMPATIBLE
Der Initialisierungsparameter COMPATIBLE steht nach der Migration zunächst
auf 9.2.0. Dies führt dazu, dass zunächst nicht alle neuen Features von Oracle
10g genutzt werden können. Ein neues Feature von Oracle 10g ist die Möglichkeit, Informationen im Undo-Tablespace eine garantierte Zeit vorzuhalten.
Dies geschieht durch Angabe von
ALTER TABLESPACE undo_jbe_ts_1 RETENTION GUARANTEE
Eine Nutzung dieses Features war jedoch erst nach einer Änderung des Initialisierungsparameter COMPATIBLE auf 10.1.0.0 möglich.
Registry
Eine Änderung, die nur unter Microsoft Windows auffällt, betrifft die Windows
Registry. Bisher fanden sich unter HKEY_LOCAL_MACHINE\SOFTWARE\
ORACLE\ Schlüssel der Form HOME0, HOME1, etc.
Ab Oracle 10g tragen diese Schlüssel den Namen KEY_<ORACLE_HOME>, z.B
KEY_ORACLE_10g. Die Zeichenfolgen innerhalb dieser Schlüssel haben sich
allerdings nicht verändert.
Transportable Tablespaces
Einleitung
Um Daten zwischen Datenbanken auszutauschen gibt es neben der Möglichkeit des Exports und Imports auch die Funktionalität der "Transportable Tablespaces". Da hierbei lediglich Dateien kopiert werden müssen, ist dies wesentlich
schneller als die Nutzung von Export und Import. Die beteiligten Datenbanken
müssen allerdings mindestens Oracle 8i EE sein.
Seit Oracle 10g ist es möglich, Tablespaces zwischen verschiedenen Plattformen
zu kopieren. Eine Übersicht, welche Plattformen möglich sind, erhält man
durch folgenden SQL-Befehl:
SQL> SELECT * FROM v$transportable_platform;
Das Ergbnis ist folgende Tabelle:
PLATFORM_ID
1
2
7
10
6
3
5
4
11
15
8
9
13
16
12
17
PLATFORM_NAME
Solaris[tm] OE (32-bit)
Solaris[tm] OE (64-bit)
Microsoft Windows IA (32-bit)
Linux IA (32-bit)
AIX-Based Systems (64-bit)
HP-UX (64-bit)
HP Tru64 UNIX
HP-UX IA (64-bit)
Linux IA (64-bit)
HP Open VMS
Microsoft Windows IA (64-bit)
IBM zSeries Based Linux
Linux 64-bit for AMD
Apple Mac OS
Microsoft Windows 64-bit for AMD
Solaris Operating System (x86)
ENDIAN_FORMAT
Big
Big
Little
Little
Big
Big
Little
Big
Little
Little
Little
Big
Little
Big
Little
Little
Bei Plattformen mit unterschiedlichem ENDIAN_FORMAT ist beim Transfer ein
zusätzlicher Schritt nötig, der später erläutert wird.
Bzgl. des Transfers bestehen folgende Einschränkungen:
• Quell- und Zieldatenbank müssen das gleiche Character Set und National
Character Set nutzen
• Der Tablespace-Name darf in der Zieldatenbank noch nicht genutzt werden
(ein Umbenennen des zu tranportierenden Tablespaces ist möglich)
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
• Alle abhängigen Objekte müssen im selben Tablespace liegen (z.B. bei Materialized Views)
• Der System-Tablespace kann nicht transportiert werden
Durchführung
Anhand eines Beispiels soll die Nutzung von Transportable Tablespaces
beschrieben werden. Zunächst wird ein Tablespace im Quellsystem (Oracle 9.2,
Windows 2003 Server) angelegt:
SQL> CREATE TABLESPACE transport_test DATAFILE
'e:\oracle\oradata\stredaxe\transport_test' SIZE 20 M;
Anlegen und füllen einer Tabelle in diesem Tablespace:
SQL> CREATE TABLE TRANSPORT_TABLE
(ID NUMBER, TEXT VARCHAR2(4000 BYTE)
) TABLESPACE TRANSPORT_TEST
SQL>INSERT INTO transport_table VALUES (1, 'Text 1');
SQL>INSERT INTO transport_table VALUES (2, 'Text 2');
Die zu transportierenden Tablespaces müssen READ_ONLY sein:
SQL> ALTER TABLESPACE transport_test READ ONLY;
Auf dem Server der Quelldatenbank wird nun die Metadatenstruktur exportiert:
C:\> EXP transport_tablespace=y tablespaces=(transport_test)
file=transport.dmp
Nun werden sowohl die Datendatei sowie die eben erzeugt Dump-Datei auf
den Zielserver kopiert.
Auf dem Server der Zieldatenbank (Oracle 10.1.0.3, Windows NT 4.0) kann nun
der Tablespace eingebunden werden:
C:\>
IMP
transport_tablespace=y
file=transport.dmp
datafiles='E:\oracle\oradata\stredaxe\TRANSPORT_TEST.DBF'
tablespaces=transport_test tts_owners=(stredax_stage)
fromuser=(stredax_stage) touser=(stredax_stage)
Bei Plattformen mit verschiedenen Angaben für ENDIAN_FORMAT muss vor
dem Kopiervorgang mit Hilfe von RMAN eine Konvertierung vorgenommen
werden:
RMAN> CONVERT TABLESPACE transport_test TO PLATFORM
´Microsoft Windows NT´ FORMAT ´/temp/%U´.
Eine solche Konvertierung war bei uns im Projekt nicht notwendig, daher gibt
es dazu auch keine Erfahrungswerte.
Nach dem Einbinden des Tablespaces in die Zieldatenbank befindet sich dieser
im Modus READ ONLY. Sollen in diesem Tablespace Änderungen vorgenommen werden, muss dies natürlich geändert werden.
Es ist möglich, einen Tablespace und damit ein und dieselbe Datendatei in
mehreren Datenbanken auf dem oben beschriebenen Weg einzubinden, um
von mehreren Datenbanken auf die Daten zugreifen zu können. In diesem Fall
darf der Tablespace in keiner der Datenbanken auf READ WRITE gesetzt werden. Ein Löschen des Tablespaces ist in einer der beteiligten Datenbanken möglich, in den anderen Datenbanken bleibt dieser Tablespace aber erhalten.
Die Nutzung von Transportable Tablespaces verlief in unserem Projekt bisher
ohne Probleme, sofern die oben angegebenen Bedingungen eingehalten wurden. Genutzt wurde dieses Feature für Tablespaces zwischen 20MB und 2GB
Größe. Ein erstes Test, Tablespaces von einem Linux-Rechner auf Windows zu
kopieren verlief ebenfalls ohne Probleme, allerdings steht ein produktiver Einsatz noch aus.
Referenzen
• Oracle Database Documentation,
Oracle 9i Database Utilities Release 2 (9.2)
Part No. A96652-01
• Oracle Database Documentation
Oracle Database Installation Guide 10g Release 1 (10.1.0.2.0) for Windows
Part No. B10130-01
• Oracle Database Documentation
Oracle Database Adminstrator’s Guide 9i Release 2 (9.2)
Part No. A96521-01
• Oracle Database Documentation
Oracle Database Adminstrator’s Guide 10g Release 1 (10.1)
Part No. B10739-01
• Oracle Metalink (http://metalink.oracle.com)
10g: SYSAUX Tablespace
Doc ID: 243246.1
Kontaktadresse:
Jens Behring
its-people Hochtaunus GmbH
Nassauer Str. 60
D-61440 Oberursel
Telefon:
E-Mail:
Internet:
+49-172-7824137
[email protected]
www.its-people.de
Database
17. Deutsche ORACLE-Anwenderkonferenz