Migration von Oracle 9i auf 10g Hans Pfeiffer Talkline Data Warehouse Elmshorn,

2 Ausgangspunkt Data Warehouse mit etwa 300 GB ( 1998 ) / 800 GB ( 2007 ) Datenvolumen –ursprünglich ( 1998 ) von Oracle auf migriert, dann auf 9i ( verschiedene Versionen + Patches ) gewechselt –intensive Nutzung von Partitionierung –Nutzung von Materialized Views in wegen gravierender funktionaler Einschränkungen nicht weiter verfolgt - MVs werden heute nur rudimentär verwendet

3 Motivation zur Migration von 9i auf 10g Vorläufer bei neuen Datenbank-Versionen im Hause Talkline –steigende Datenvolumina in allen Unternehmensbereichen führen zu hohen Anforderungen an Hard- und Software Kleinere Probleme mit 9i : – Probleme mit Database Links –Speicher-Management führte etwa alle 60 Tage zum Reboot der DB –gravierender Fehler bei compressed tables

4 Motivation zur Migration von 9i auf 10g Neue Features in der 10g für Data Warehousing waren keine Motivation zum Wechsel : –im Talkline Data Warehouse werden weder Materialized Views OLAP-Funktionalitäten JAVA-Funktionalitäten EXCEL-Funktionalitäten verwendet

5 Motivation zur Migration von 9i auf 10g An neuen Features werden hingegen eingesetzt : – Compress – Feature erhebliche Platzeinsparung –Verbesserungen im Bereich der analytischen Funktionen verbesserte Laufzeiten, kompaktere SQL-Statements –verbessertes und vereinfachtes Speicher-Management –Flashback, UNDO Segment

6 Durchführung der Migration auf 10g –White Paper von Oracle unterstützt die eigentliche Migration –Es werden verschiedene Migrationsskripte gestartet –Nach Migration müssen noch PL/SQL-Pakete neu kompiliert werden

7 Migrations-bezogene Probleme –Datenbank Links mußten neu angelegt werden Tipp : entsprechendes Skript anlegen und auf Passwörter achten ( sind unter 10g nicht mehr sichtbar ) –Snapshots mußten neu aufgebaut werden ( werden von externer Datenbank aufgebaut ) –Probleme gab es mit Oracle-Bibliotheken mit denen OraPerl angebunden wird Tipp : bei Verwendung von Embedded C / OraPerl sollte in einer 10er Testumgebung verifiziert werden, ob die Zugriffe auf die Datenbank noch funktionieren, eventuell Bibliotheken ausgewechselt oder die zu Grunde liegende Software neu kompiliert werden muss.

8 Migrations-bezogene Probleme –Execution-Pläne ändern sich u.U. erheblich Optimal wäre das Testen entsprechender SQL-Statements in einer 10er Testumgebunug – vielfach nicht machbar Tipp : Vor Migration sollten die Laufzeiten aller relevanten SQL- Statements erfaßt werden. Ergeben sich nach der Migration erhebliche Abweichungen, so kann auf iterativem Wege das Tunen der einzelnen SQL-Statements erfolgen

9 Erfahrungen nach der Migration –Die Migration auf Oracle 10g verlief größtenteils problemlos ( das DWH verwendet nur grundlegende Funktionen ) –Die Bereitstellung von Reports war in den ersten Tagen verzögert, da zahlreiche SQL-Statements neu getunt werden mußten ( HINTs ) ( hoher Aufwand, sollte unbedingt bei Projektplanung berücksichtigt werden ) –Durch entsprechende Kommunikation ins Unternehmen vor der Migration konnte Unmut über die Verzögerungen verhindert werden –Die Ausdauer der Endanwender wurden mit deutlichen Beschleunigungen bei SQL- Abfragen belohnt –Bestimmte Fremdapplikatione ( z.B. TOAD ) funktionierten nicht mit der 10g neue Version schaffte Abhilfe

10 Erfahrungen nach der Migration –Probleme mit Parallel Queries : ist eine Tabelle mit PARALLEL_DEGREE > 1 angelegt worden, können u.U. bei der Verwendung des PARALLEL-Hints doppelte Ergebnisse selektiert werden –Falsche Selektionsergebnisse nach SHRINK TABLE auf einer partitionierten Tabelle –Konsistenz der Systemtabellen durch viele Migrationen geschwächt

11 Vor einer Migration zu bedenken –Oracle führt automatisch den neuen Tablespace SYSAUX ein : prüfen, ob hierfür genügend Plattenplatz bereitgestellt werden kann –Prüfen, ob auf das UNDO-Tablespace umgeschwenkt werden soll –Genügend Zeit für Tests nach der Migration einplanen : sind alle Fremdapplikationen lauffähig ? die wichtigsten Reports inhaltlich prüfen ! –im Vorwege die Parameter-Einstellungen der INIT*ORA prüfen und festlegen –FALLBACK organisieren Sicherungen der Datenbank vor Migration verifizieren und umgehend nach Migration Vollsicherung durchführen !

12 Vor einer Migration zu bedenken –Prüfung, ob die Datenbank-Version migriert werden soll oder ob die gesamten Daten in eine frische 10er-Installation übernommen werden sollen Stichwort : Standby-Datenbank Konsistenz von System-Tabellen

13 SEE YOU