Migration von 2 9i-DBs auf 2*4-Knoten-RAC unter Unbreakable Linux mit ASM, RMAN, NetApp. Dagmar Förster Christian Trieb

Transkript

1 DOAG 2007, Nürnberg 22. November 2007 Migration von 2 9i-DBs auf 2*4-Knoten-RAC unter Unbreakable Linux mit ASM, RMAN, NetApp Dagmar Förster Christian Trieb

2 Agenda 1. Kurzprofil Paragon Data Ausgangssituation Gründe für die Migration Ziele Herausforderungen Resümee und Ausblick Ihre Fragen

3 1. Kurzprofil Paragon Data Schwerpunkt Buchhandel: DBH, Hugendubel, Weltbild, Weiland etc. IT-Dienstleister Hosting und Betrieb von Oracle-Datenbanken BSI-zertifiziertes Rechenzentrum Oracle-Partner T-Systems-Partner

4 Kurzprofil: Unsere Kunden

5 2. Ausgangssituation: 2 Datenbanken CASH: Warenwirtschaft DWDB: Data Warehouse

6 Ausgangssituation: Datenbank CASH Warenwirtschaft 2-Knoten RAC unter Oracle 9i RedHad Advanced Server 3 9 GB RAM Größe der DB: 230 GB ca User

7 Ausgangssituation: Datenbank DWDB Data Warehouse Single Instance unter Oracle 9.2 RedHat Advanced Server 3 16 GB RAM ca. 500 GB Datenvolumen ca. 120 Benutzer

8 3. Gründe für Migration: technisch RAC unter 9i instabil: User-Verteilung oft ungleich, ab ca Usern stürzt ein Knoten ab alte Hardware Plattenplatz nicht erweiterbar zu wenig Memory für Data Warehouse

9 Gründe für Migration: Business Der Zusammenschluß mehrerer Buchhändler zur DBH Deutsche Buch Handels GmbH in 2006 bedeutet: Zusätzliche Filialen Erweiterte Ladenöffnungszeiten Mehr Benutzer Mehr Daten Höhere Anforderungen an die Verfügbarkeit

10 4. Ziele: die höchsten Prioritäten 1. Sehr hohe Verfügbarkeit und Ausfallsicherheit während der Ladenöffnungszeiten 2. Gute Performance für die Anwender

11 Ziele: 2 Cluster à 4 Knoten DataGuard rac01-rac04 DWDB RepositoryServer rac21-rac24 CASH

12 Ziele: 2 Cluster, Hardware, OS HP Proliant DL380 AMD 64DualCore-Processor je 16 GB Memory Oracle Unbreakable Linux vorher bereits RedHat, daher keine große Umstellung rac01-rac04 DWDB

13 Ziele: Neue Systeme, Oracle 4-Knoten-RAC Oracle Ausfallsicherheit und Lastverteilung mit RAC, aktuelle Oracle-Version Eigene $ORACLE_HOMEs und Binaries für jede Datenbank, Standby, CRS und Grid Vereinfachtes Patchen, Flexibilität Oracle-Parameter bleiben vorerst 3 kleinere Datenbanken werden zusätzlich auf die Maschinen verteilt

14 Ziele: Storage und Netz 2 gespiegelte NetApp-Filer FAS6030 (Metro-Ring) über 10 GB-Infiniband-Leitung Ausgesprochen robust und ausfallsicher RAC-Knoten über Fibrechannel via QLogic CoreSwitches 9200 ONStor Bobcat 2240 für Backup über NFS OCFS2 und Heartbeat über redundantes Cisco-Netz

15 Ziele: Neue Systeme, 4 Filesysteme Raw Devices für Voting- und Clusterregistry-Disken ASM für Datenbank-Files Gute Handhabbarkeit und Robustheit OCFS2 für gemeinsame Daten (z.b. alert.logs) Für gemeinsame Daten wie Trace- und Alert-Files und Skripte Stabiler als OCFS1 Neuste Info von Oracle: keine Weiterentwicklung mehr! NFS für Backup Günstige Lösung auf ONStor

16 Ziele: Neue Systeme DataGuard Über Kreuz = Standby von CASH auf DWDB-Cluster, Knoten #1 Single Instance, da RAC nicht möglich war Enterprise Manager Grid Control Version Besonders benutzt für Performance

17 Ziele: Grid 2. Datenbanken 3. cash 1. Ziele

18 Ziele: Grid Instanz cash1 Performance

19 Ziele: screen shots Historisch historisch, 24h Deadlock

20 -> nächste Seite: Top Aktivität Echtzeit

21 Ziele: screen shots Session- oder SQL-Ebene

22 Ziele: Neue Systeme Monitoring mit Intellipool Network Monitor 3.3 Eingebaute Monitore nicht ausreichend Neue Skripte integriert um z.b. Platz intablespaces und ASM zu überwachen, Alert-Logs auf ORA- und Deadlock-Fehler zu prüfen Prüfung alle x Minuten Alarm nach y Fehlversuchen Alarm-Meldung an -Adressen

23 Ziele: Intellipool Selbstgeschriebene SSH-Skripte

24 Beispiel: anz_fehler_alertlog Ziele: Intellipool if [ -e $ALERTLOGFILE ] then export erg=`grep ORA- $ALERTLOGFILE wc -l` echo $erg exit $erg else echo -1 exit -1 fi

25 Ziele: Backup und Recovery RMAN-Backup jede Nacht auf NFS-Laufwerk zweimal wöchentlich Full Export Einbindung von CommVault Galaxy 6.1: Linux- und Oracle-Client Backup zunächst auf Platte, danach auf Bandroboter Mehrere Generationen

26 Ziele: Übersicht

27 5. Herausforderungen zeitlich personell technisch

28 Herausforderungen: zeitlich enger Zeitrahmen: Projektstart Geplantes Live-Datum Ende Februar 2007 Möglichst detaillierte Planung im Vorfeld, insbesondere IP-Adressen, Namen, Netzkonfiguration

29 Herausforderungen: personell Anzahl der Mitarbeiter verdoppelt sich auf ca. 50 zwischen Januar und Juni 2007 Zusammenarbeit mit externen Consultants Hier ein herzlicher Dank an Herrn Griesel und Herrn Dörr von inconso Hohe Projektdichte durch Wachstum Zusammenarbeit und Überschneidungen zwischen Systemmanagern und DBAs

30 Herausforderungen: technisch Neue Technologien noch wenig Erfahrung Oracle- und CRS-Bugs /var/log/messages wird mit Meldungen vollgeschrieben: session opened for user oracrs by (uid=0) session closed for user oracrs Patch : ersetzt clsfmt.bin und weitere Patche

31 Herausforderungen: technisch OnStor instabil Export/Import für Datenmigration NFS-Share hängt sich häufig auf OCFS2-Version mit Fehlern Absturz von Knoten bei gewissen Netzwerk-Fehlern Version : Timeout konfigurierbar Multipath-Treiber

32 Herausforderungen: technisch Migration DWDB: ca. 500 MB Export 26 Stunden, Import 19 Stunden Verhältnismäßig unkritisch, paßt in ein Wochenende Vorteil: die alten Systeme bleiben unangetastet und dienen als Fallback

33 Herausforderungen: technisch Migration CASH: ca. 230 MB Export 5 Stunden, Import 16 Stunden Kritisch wegen Ladenöffnungszeiten Manuelle Arbeiten DBLinks anlegen, Views, Snapshots droppen, Invalid Objects, Bug: über DB-Link erstellte Tabellen nicht importierbar

34 6. Resümee Zeitlich im Rahmen: live Anfang und Mitte März RAC-System jetzt stabil Performance gut ausbaufähig bei Wachstum

35 Resümee: Erfolgsfaktoren gute Planung, insbesondere des komplexen Netzwerks enge Zusammenarbeit mit Systemmanagern Wissenstransfer zwischen DBAs fortlaufende Dokumentation Support für Oracle und andere eingesetzte Soft- und Hardware Andrea Held: Oracle 10g Hochverfügbarkeit

36 Ausblick Mehr Benutzer (Karstadt-Filialen...) schon jetzt 2000 User auf CASH Zusätzliches Memory Applikation braucht viel Memory, wenig CPU 2 zusätzliche Knoten pro Cluster, ggf. dedizierte Knoten für DataGuard und Jobs

37 Kontakt Dagmar Förster Christian Trieb Paragon Data GmbH Otto-Hahn-Str. 40 D Friedrichsdorf