Risikominimierung bei der Migration von Datenbank und Application Server nach 10gR2. Referent: Dr. Peter Alteheld, Systemberater, MT AG

Transkript

1 Risikominimierung bei der Migration von Datenbank und Application Server nach 10gR2 Referent: Dr. Peter Alteheld, Systemberater, MT AG

2 MT AG managing technology Key-facts: 1994: Gründung als MT Software GmbH 2000: Umwandlung zur MT AG, Aktienkapital: 1,5 Mio. Anteile: In der Hand von Management und Aufsichtsrat Zurzeit: ca. 145 Festangestellte ca. 60 freie Mitarbeiter Die Die MT MT AG AG ist ist langjähriger IT-Beratungspartner von von Großunternehmen und und Mittelstand. Sie Sie steht steht für für Technologie-Know-how und und praxisnahe, effiziente IT-Dienstleistung: von von Strategie Strategie und und Beratung Beratung über über Entwicklung und und Integration Integration bis bis hin hin zu zu Wartung Wartung und und Administration von von IT-Infrastrukturen Risikominimierung bei der Migration nach 10gR2 2

3 Motivation Motivation für diese Präsentation: Erfahrungen bei einer umfangreichen Migration - Auffälligkeiten in der Vorbereitung - Probleme während der Migration - Erfahrungen nach Produktivsetzung Know-how für eine reibungslose Migration Motivation für Migration: Desupport, neue Features Risikominimierung bei der Migration nach 10gR2 3

4 Single biggest pressure in data centers Increasing rate of change and pressure to move faster Rate of c hange Cos t 24/7 availability Com plex ity B igges t P res s ure S ec ond B igges t P res s ure B us ines s value S ec urity P e rce nta ge of Re sponde nts Quelle: Gartner 25th Annual Data Center Conf. Interactive Polling Results, Dez Risikominimierung bei der Migration nach 10gR2 4

5 Migration: Business-Anforderungen schnell problemlos darf nicht viel kosten unmöglicher Auftrag Never change a running system attitude oft Herauszögern der Migration Risikominimierung bei der Migration nach 10gR2 5

6 Migration: Technische Anforderungen Anforderungen Übernahme aller Daten Bereitstellung aller Funktionalitäten mind. gleiche Performance gleiches oder besseres Lastverhalten Migration in begrenztem Zeitfenster ausfallfreier Betrieb Risikominimierung bei der Migration nach 10gR2 6

7 Migration: Anforderungen und Risiken Anforderungen Risiken Übernahme aller Daten Bereitstellung aller Funktionalitäten mind. gleiche Performance gleiches oder besseres Lastverhalten Migration in begrenztem Zeitfenster ausfallfreier Betrieb Datenverlust Verlust von Funktionalitäten Performance-Einbußen Performance-Verluste unter Last Migrationszeitfenster reicht nicht System- oder Teilsystem-Ausfall Risikominimierung bei der Migration nach 10gR2 7

8 Migration von DB und OAS in der Praxis Migration eines Bankenanwendungssystems Anwender, Zeitfenster, Projektteam Cold failover cluster (Veritas) für DB und OAS auf Solaris Datenbank GB, , WE8ISO8859P1 AL32UTF8, RLS Application Server - 9i Release 1, Version inkl. Infrastructure Anwendungen - Stored Procedures, Forms-Module, Reports-Berichte, Discoverer-Berichte, J2EE- Anwendung, Visual Basic-Anwendung.NET, Jobs, Beladungen Schnittstellen - Datenbank-Links, File-Transfers Risikominimierung bei der Migration nach 10gR2 8

9 Risiko: Datenverlust -1- Prüfung der vollständigen Datenübernahme Anzahl der Datenbankobjekte nach Objekttyp Anzahl der Tabellenzeilen Checksummen über ausgewählte Tabellenspalten Kein Datenverlust aufgetreten BIN$-Objekte Risikominimierung bei der Migration nach 10gR2 9

10 Risiko: Datenverlust -2- Vermeidung des Verlusts von Datenbankobjekten SYS-Objekte wie Tablespaces, Rollen, Profile, Contexte, Directories, Public Database Links, Systemprivilegien Systemtrigger werden durch Schema-Importe nicht übernommen Lösung: Create-Statements für diese Objekte mit dem Tool DDL-Wizard aus Full Database Export bereitstellen Datenbank-Jobs von Usern landeten beim Schema-Import im SYS-Schema Lösung: Job-Skripte aus 8i per TOAD abgespeichert. Nächste Ausführung angepaßt und in 10g eingespielt Risikominimierung bei der Migration nach 10gR2 10

11 Risiko: Datenverlust -3- Datenverlust bei großen VARCHAR2-Spalten In Vorstudie aufgefallen: komplette Spalte nicht übernommen Ursache: VARCHAR2 lässt maximal Byte zu in 8i wie in 10g Bei Konvertierung eines mit Zeichen gefüllten VARCHAR2- Feldes von WE8ISO8859P1 nach AL32UTF8 kann dieses größer als Byte werden Lösung: Abschneiden oder Konvertierung nach CLOB Risikominimierung bei der Migration nach 10gR2 11

12 Risiko: Verlust von Funktionalitäten -1- Vermeidung des Verlustes von Funktionalitäten: Testen aller Funktionalitäten auch der Jobs (Datenbank, Crontab, UC4, ) auch der Schnittstellen (Datenbank-Links, FileTransfer, ) auch der Nachverarbeitung (z.b. Lesen generierter Dateien mit anderen Tools) Funktionalitäten wurden erfolgreich umgestellt Risikominimierung bei der Migration nach 10gR2 12

13 Risiko: Verlust von Funktionalitäten -2- Zeichensatzänderung WE8ISO8859P1 AL32UTF8 Passwörter von Rollen und Usern, deren Namen Umlaute enthielten, stimmten nicht mehr Rücksetzen DBMS_OBFUSCATION_TOOLKIT verschlüsselt Strings anders Neuverschlüsselung erforderlich Per UTL_FILE erstellte Dateien hatten anderen Zeichensatz damit versorgte Schnittstellen kamen damit nicht klar Zeichensatzkonvertierung auf OS-Ebene Trotz Umstellung der Längensemantik auf CHAR werden Stored Procedures als BYTE importiert Nachkompilieren Forms- und Discoverer-Konfiguration so, daß dem Browser der Zeichensatz mitgeteilt wird Reports-Server: fehlende UTF8-Mapping-Information erschwert Konfiguration Risikominimierung bei der Migration nach 10gR2 13

14 Risiko: Verlust von Funktionalitäten -3- Erforderliche Datenbankanpassungen Rolle CONNECT hat in 10g weniger Rechte Rechte zugewiesen Profil DEFAULT_PROFILE erlaubt in 10g nur noch 10 Fehlanmeldungen auf UNLIMITED gesetzt Packages wie DBMS_LOCK erfordern in 10g explizites Execute-Grant Explizit Grants vergeben ORA-1466 bei Lesen aus global temporary table in Read-only-Transaction GROUP BY sortiert in 10g nicht mehr order by ggf. zugefügt GROUP BY-Tuning und -Bug Risikominimierung bei der Migration nach 10gR2 14

15 Risiko: Verlust von Funktionalitäten -4- Erforderliche Anpassungen am Application Server Forms-Masken: Unnötige Fehlermeldung beim Relation-Handling bei Multi-Record- Masterblocks Datenänderung auf Tabellen mit CLOBs speichert falsch Discoverer-Berichte: Einige Berichte zeigten nach Testmigration zu viele Daten. Discoverer Plus 10g interpretiert leeren Aufrufparameter als Wildcard während Discoverer 4i Plus den Wert als NULL übernimmt. Anpassung der Workbooks und Aufrufe Risikominimierung bei der Migration nach 10gR2 15

16 Risiko: Performance-Einbußen Vermeidung durch umfassende Funktionalitäts- und Last-Tests Erforderliche Anpassungen: Optimizer-Parameter im Logon-Trigger - Für alle Sitzungen: optimizer_secure_view_merging, _optim_peek_user_binds, _optimizer_cost_based_transformation, _pga_max_size, - Einzelfälle: Complex view merging, Hash group by Reduzierung von SYS_CONTEXT-Abfragen in VPD-Policy- Funktionen durch Speichern in global temporary table Detaillierteres Statistikensammeln als im Default-Job Discoverer: QPPEnable in pref.txt Ausreichende Performance Risikominimierung bei der Migration nach 10gR2 16

17 Risiko: Migrationszeitfenster reicht nicht -1- Vermeidungsstrategie: Beschleunigen des Vorgangs Testen aller während der Migration vorgesehenen Maßnahmen auch den Shakedown-Test Trotz einiger nicht getesteter Maßnahmen erfolgreich Risikominimierung bei der Migration nach 10gR2 17

18 Risiko: Migrationszeitfenster reicht nicht -2- Das vermeintlich Hot pluggable CPU-Board Eines der CPU-Boards sollte vom Altsystem ins Neusystem übernommen werden. Es war natürlich nicht hot pluggable. Datenbankabsturz Durch Veritas bedingter Startversuch während Verzeichnis an Failover-System gemountet wurde Korruption eines Index Zeitverzug durch Indexneuaufbau und Prüfen der anderen Datendateien mit DBVerify jedoch innerhalb des zur Verfügung stehenden Zeitfensters Risikominimierung bei der Migration nach 10gR2 18

19 Risiko: Migrationszeitfenster reicht nicht -3- Die parallel umzustellende Visual Basic-Client-Anwendung die gleichzeitig auf.net umgestellt wurde ließ sich nicht wie geplant auf die Clients verteilen nicht ausreichend getestet Zeitverzug durch Neuaufsetzen der Verteilung jedoch innerhalb des zur Verfügung stehenden Zeitfensters Risikominimierung bei der Migration nach 10gR2 19

20 Risiko: Migrationszeitfenster reicht nicht -4- Der vermeintlich nur lesende Lasttest zum Warmlaufen Der Lasttest sollte ausreichende Performance verifizieren Und er las doch nicht nur Zufällig im Shakedown-Test entdeckt Zeitverzug durch Recovery der Datenbank jedoch innerhalb des zur Verfügung stehenden Zeitfensters Risikominimierung bei der Migration nach 10gR2 20

21 Risiko: System- oder Teilsystem-Ausfall -1- Application Server-Ausfall nach wenigen Stunden Ursache: Wechsel zur Sun Java Virtual Machine Warum vom JInitiator zur Sun JVM? Hinweis aus Weblog eines Oracle Product Managers : So, with us certifying the Sun JVM, there is less need for JInitiator...we don t intend to rev it passed the 1.3 code line Erforderliche Anpassung von KeepAlive nicht vorgenommen Erfordernis nur in nichtöffentlicher Metalink-Note beschrieben KeepAlive auf off geändert Weiterer Forms-Container-Ausfall: Reports In-Process-Server? Vermeidungsstrategie: auch auf dem Application Server mit realer Last lange testen! Risikominimierung bei der Migration nach 10gR2 21

22 Risiko: System- oder Teilsystem-Ausfall -2- Reports-Server-Ausfall mehrfach täglich Ursache: Bug in der CORBA-Implementierung in der Java Virtual Machine 1.4.2_08 (Reports-Server nutzt CORBA) Upgrade der JVM im Application Server auf 1.4.2_14 Vermeidungsstrategie: auch Reports-Module mit realer Last lange testen! Durchstarten des Reports-Server Risikominimierung bei der Migration nach 10gR2 22

23 Risiko: System- oder Teilsystem-Ausfall -3- Datenbankausfall nach einwöchigem Betrieb Ursache: Automatic Shared Memory Management Speicherbelegung und -verwaltung durch SGA-Bereich kgh: no access ASMM ausgeschaltet Vermeidungsstrategie: Länger testen! Risikominimierung bei der Migration nach 10gR2 23

24 Lessons learned Damit Migrationen gelingen... das ganze System unter realer Last testen den Lasttest lange laufen lassen alle Migrationsschritte testen Die Risikominimierung erfordert viel Sorgfalt und eine umfassende Testphase! Risikominimierung bei der Migration nach 10gR2 24

25 Fragen und Antworten Dr. Peter Alteheld Systemberater MT AG Balcke-Dürr-Allee Ratingen Tel Fax Peter.Alteheld@mt-ag.com

26 Vielen Dank für Ihre Aufmerksamkeit! Dr. Peter Alteheld Systemberater MT AG Balcke-Dürr-Allee Ratingen Tel Fax Peter.Alteheld@mt-ag.com

27 Vorträge der MT AG DOAG 2007 Wann Thema Referent MT AG Di., ETL Monitoring & Tuning durch Auswertung der OWB Laufzeit- Metadaten Lutz Bauer Di., Erfahrungsbericht Einführung ARIS beim Kaufhof Hildgund von Alten- Krämer Mi., :00 11:45h Mi., :00 12:45h Do., :00 11:45h Do., :00 12:45h Oracle Warehouse Builder: Automatisierung von Designschritten bei der Bayer HealthCare AG So profitieren Unternehmen von Oracle Web-Center Suite: Wie sich Web 2.0-Features bewähren Praxisbericht: Database Vault in der Personalabteilung Beschleunigte Oracle-ADF-Entwicklung von Rich Client-Anwendungen im Bankenwesen Lutz Bauer Niels de Bruijn Detlef Müller/Oracle Volker Mach Tobias Otto Do., :00 13:45h Do., :00 14:45h Standby Risikominimierung bei der Migration von Datenbank und Application Server nach 10gR2 Best Practices: Entwicklung komplexer APEX-Applikationen Best Practices im Business-Reporting: So kombiniert man Hyperion Intelligence mit dem OWB Dr. Peter Alteheld Niels de Bruijn, Anja Wiegele Jens Wiesner Risikominimierung bei der Migration nach 10gR2 27