Oracle 10g Hochverfügbarkeit

Transkript

1 Andrea Held Oracle 10g Hochverfügbarkeit Effizient konfigurieren, optimieren und verwalten An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam

2 3 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle- Umgebungen Die Gesamtstrategie zur Sicherung der Verfügbarkeit einer Anwendung betrifft verschiedene Bereiche: Angefangen bei der Technik bis hin zu einem Notfallplan müssen grundlegende Entscheidungen getroffen werden. Der Fokus dieses Kapitels liegt auf jenen Technologien, die den Datenbankserver betreffen. Kernpunkte sind: X geeignete High Availability-Technologie(n) für Oracle DB-Server X geeignete High Availability-Technologie(n) für Middle Tier und Application Server X geeignete Maßnahmen bezüglich der Infrastruktur X geeignete Hardware X Wartungsmaßnahmen, Personaleinsatz und Notfallplan Auf jeden einzelnen Aspekt wird in den nächsten Abschnitten genauer eingegangen. 3.1 Oracle High Availability-Technologien Es gibt zahlreiche Möglichkeiten, Verfügbarkeit und Hochverfügbarkeit herzustellen. Um die für eine bestimmte Umgebung passende Strategie zu entwickeln, ist es wichtig, mögliche Architekturen und Strukturen zu kennen. Man unterscheidet einige grundsätzliche Architekturen, die im Umfeld von Oracle-Datenbanken realisiert und teilweise auch miteinander kombiniert werden können. Jede der von Oracle angebotenen Technologien adressiert bestimmte Fehlertypen. Die meisten Technologien lassen sich miteinander kombinieren. So kann in einem Real Application Cluster eine Standby-Datenbank verwendet werden, in der wiederum Oracle Flashback eingesetzt wird. Eine solche Kombination deckt nahezu alle Fehlertypen ab: Der Ausfall eines Rechners wird durch einen zweiten Clusterknoten des Real Application Cluster aufgefangen, Benutzerfehler werden durch Flashback abgefedert. Fällt ein komplettes Rechenzentrum aus, so steht die Standby-Datenbank des Remote-Rechenzentrums zur Verfügung. Ob tatsächlich alle diese Maßnahmen notwendig sind, ist im Rahmen der Bedarfsanalyse zu bestimmen. Nicht immer ist der finanzielle und technische Aufwand gerechtfertigt. Oft genügt auch eine recht einfache Struktur, um die zuvor ermittelten Anforderungen abzudecken.

3 54 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Generell lassen sich jene Oracle-Technologien, die (Hoch-)Verfügbarkeit gewährleisten, in drei Kategorien unterteilen: X Redundanz auf Rechnerebene X Online-Technologien X Automatic Storage Management (ASM) und Fast Recovery Oracle und Rechnerredundanz Rechnerredundanz kann auf unterschiedlichen Wegen hergestellt werden. Die wichtigsten Verfahren für Oracle-Datenbankserver sind: Failover Cluster, Standby- Datenbanken, Oracle Real Application Clusters, Geo Cluster, Datenbankspiel und Replikation. Sie werden im Folgenden dargestellt. Oracle Failover Cluster (Cold Standby) Als Cold Standby bezeichnet man HA-Lösungen, deren Anwendungen im Fehlerfall auf einem Ersatzsystem zur Verfügung gestellt werden. Der Standby-Rechner ist solange nicht in Betrieb, bis das Primärsystem ausfällt. Die Server sind redundant ausgelegt. Der Ersatzrechner ist dabei im Normalbetrieb deaktiviert. Der Primärserver sendet einen Heartbeat. Fällt er aus, so erkennt dies das Ersatzsystem und aktiviert sich selbst. Es startet dann automatisch, fährt ggf. Dienste hoch und übernimmt den Betrieb. U.U. ist das Primärsystem funktionsfähig, aber eine Anwendung, z.b. der Oracle DB Service, ist nicht ansprechbar. Über spezielle Cluster-Agenten können daher auch Anwendungen gemonitort werden. In der Regel werden Agenten für Standard-Software wie das Oracle DBMS mit der Cluster Software ausgeliefert. Es können jedoch auch angepasste Agenten verwendet werden. Vorgefertigte Oracle-Agenten prüfen das Vorhandensein der Oracle-Prozesse. Jedoch ist dies nicht unbedingt aussagekräftig: Ein Prozess kann durchaus gestartet sein, aber nicht korrekt arbeiten. Einige Hersteller versuchen daher einen Connect zur Datenbank Instance, gelegentlich auch eine Transaktion wie ein Insert in eine für den Agenten vorgefertigte Tabelle. Schlägt diese Aktion fehl, wird nach einer vorgefertigten Prozedur verfahren und der Failover eingeleitet. Typischer Vertreter des Cold Standby im Oracle-Umfeld ist ein Failover Cluster. In diesem ist entweder Rechner A oder Rechner B aktiv. Ressourcen wie Storage, logische IP-Adressen und Hostnamen, aber auch Dienste wie Oracle-Instanzen und Oracle Listener werden in einem Failover Cluster in so genannten Ressourcengruppen verwaltet. Der jeweils aktive Rechner nutzt Ressourcengruppen exklusiv. So kann z.b. der Storage nur von maximal einem Rechner gemountet werden. Ob der jeweils andere Rechner aktiv ist, wird in einem Failover Cluster über den Cluster Heartbeat überprüft. Beide Rechner sind hierfür mit einem privaten, exklusiv für den Cluster genutzten Netzwerk verbunden. Über dieses wird der Heartbeat gesandt, der dem jeweils anderen Rechner das Signal gibt, dass das eigene System funktionsfähig, also»am Leben«ist. Verstummt der Heartbeat des Primärrechners, so geht der Standby-Knoten davon aus, dass er den Betrieb übernehmen muss.

4 Oracle High Availability-Technologien 55 Dazu übernimmt er die Ownership der Clusterressourcen. Er mountet den Storage, übernimmt logische IP-Adressen und Hostnamen, startet die Oracle-Dienste und stellt damit die Betriebsfähigkeit des Datenbank-Backend-Systems wieder her. Je nach Ausfallursache und Größe der Datenbank dauert dies zwischen wenigen Minuten und etwa einer halben Stunde. Damit eine Übernahme der Funktionalitäten möglich ist, müssen beide Rechner einen Zugriff auf bestimmte Ressourcen haben. So müssen beide Rechner den Storage, auf dem die Datenbankdateien liegen, mounten können. Hier muss externer Storage verwendet werden, an den mehrere Hosts angeschlossen werden können. Möglich ist dies bei Nutzung von SCSI-Storage, durch Einsatz eines SAN (Storage Area Networks), iscsi (IP-basiertes SCSI) oder NAS (Network Attached Storage). Die beiden letztgenannten Optionen werden zwar unterstützt. Erfahrungsgemäß ist die Nutzung von SCSI-Storage und SAN-Technologie unbedingt vorzuziehen. Die Verbindung zwischen beiden Rechnern wird über das Private Network Interface realisiert. Zum Einsatz kommen hier häufig einfache Ethernet-Netzwerkkarten. Für eine schnellere Verbindung werden oft auch proprietäre Lösungen des Hardwareherstellers verwendet. Das Private Network sollte unbedingt wie andere Komponenten auch redundant ausgelegt werden. Zwischen beiden Rechnern sollten mindestens zwei Schnittstellen implementiert werden, sodass auch das Private Network keinen SPOF bildet und bei Ausfall einer Netzwerkkarte die jeweils andere die Aufgaben übernehmen kann. Fallen doch einmal alle Verbindungen des Private Network aus, besteht die Gefahr, dass beide Knoten die Ressourcen übernehmen wollen. Gerade der konkurrierende Zugriff auf die eigentlich exklusiv zu nutzenden Ressourcen wie den Storage kann zu erheblichen Datenkorruptionen führen. Aufgefangen wird dies in der Regel durch einen Mechanismus über ein Quorum Device bzw. eine Voting Disk. Die Verfahrensweise ist im Grunde recht einfach: Auch wenn im Cluster über keines der Network Interfaces Kommunikation möglich ist, besteht immer noch Kontakt zum gemeinsam angeschlossen Storage. Kann ein Rechnerknoten auch darauf nicht mehr zugreifen, so kann er die Datenbank sowieso nicht mehr mounten und ist betriebsunfähig. In diesem Fall stellt er auch keine Gefahr dar: Ein unkontrollierter konkurrierender Zugriff beider Knoten auf den exklusiv zu nutzenden Storage ist in diesem Fall ausgeschlossen. Können aber beide Knoten auf den Storage zugreifen, so können sie auch hierüber kommunizieren. Nur jener Knoten, der über die Voting Disk die Ownership erlangt, übernimmt die entsprechenden Clusterresourcen und stellt die Betriebsfähigkeit wieder her. Der andere Knoten fährt automatisch herunter. Das Private Network wird exklusiv für die Kommunikation im Cluster verwendet. Keinesfalls sollte dieses mit Funktionalitäten des Public Networks belastet werden, da es sonst zu nicht unerheblichen Seiteneffekten kommen kann. So könnte das Network Interface den Cluster Heartbeat bei starkem Netzwerkverkehr nicht korrekt oder nicht rechtzeitig weiterleiten. Timeout-Zeiten werden möglicherweise überschritten. Der Effekt: Der zweite Rechner im Cluster nimmt an, dass der Primärknoten ausgefallen ist, und versucht die Betriebsfunktionalität zu übernehmen.

5 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Client Client Client Client Client Public Network aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv Storage (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung eines Failover Cluster Die Verbindung zu Clients wie Applikationsserver erfolgt über das Public Network. Dieses bildet die Netzwerkschnittstelle zur Außenwelt. Auch hier sollten pro Rechner mindestens zwei Netzwerkkarten zum Einsatz kommen, um einen SPOF zu vermeiden. Diese werden in das Unternehmensnetz eingebunden und erlauben den Zugriff auf den Failover Cluster von außen. Cold Standby-Systeme benötigen einen gesonderten Cluster Layer, der nicht von Oracle geliefert, sondern von Drittanbietern eingekauft werden muss. So bietet Sun den Sun Cluster für Solaris. Unter AIX kann HACMP, für HPUX der HP MC/Service- Guard eingesetzt werden. Veritas bietet den Veritas Cluster für verschiedene Plattformen wie Sun Solaris, HPUX und Linux an. Notwendige Komponenten eines Cold Standby-Systems sind: X zwei Server mit mindestens je zwei Private und zwei Public Network Interfaces X an beide Server angeschlossener Storage (externes SCSI, SAN, iscsi, NAS) X Cluster Management-Software wie Sun Cluster, Veritas Cluster, HACMP oder ServiceGuard Für Planung und Implementierung sind neben Datenbank und Netzwerk-Knowhow auch Kenntnisse der Cluster Management-Software nötig. Die Oracle-Datenbank selbst wird ähnlich aufgesetzt wie ein normales Single Instance-System und anschließend über Resourcengruppen in den Cluster eingebunden.

6 Oracle High Availability-Technologien 57 Vorteile eines Oracle Failover Cluster: X Übernahme der Funktionalität bei Ausfall eines Servers ohne administrativen Eingriff Nachteile eines Oracle Failover Cluster: X erhöhter Zeitaufwand (im Vergleich zu Warm und Hot Standby) für Wiederanlauf X Bei Ausfall eines Rechenzentrums (z.b. durch einen Brand) fällt der gesamte Cluster aus X Redundante Hardware kann im Normalbetrieb nicht genutzt werden Oracle Standby-Datenbanken (Warm Standby) Auch in einem Warm Standby-System sind die Server redundant ausgelegt. Anders als beim Cold Standby ist hier jedoch der zweite Rechner bereits betriebsbereit und kann daher bei einem Ausfall des Primärservers die Funktionalität schneller übernehmen. Typische Vertreter im Oracle-Umfeld sind replizierte und Standby-Datenbanken. In einer Standby-Datenbank wird eine transaktionskonsistente Kopie der Primärdatenbank auf einem zweiten vollständigen System gehalten. Primär- und Standby System haben dabei in der Regel ihren eigenen privaten Storage. Es gibt Ausnahmen hierzu, die in Kapitel 5»Standby-Datenbanken und Data Guard«behandelt werden. Initial wird die Primärdatenbank einmalig über ein Backup auf das Standby-System übertragen. Anschließend werden alle Transaktionen des Primärsystems auf das Standby-System repliziert. Die Replikation kann in Echtzeit oder auch zeitverzögert erfolgen. Zeitverzögerte Verarbeitung wird häufig zum Abfangen von Benutzerfehlern eingesetzt. Wird in einer Standby-Datenbank eine Zeitverzögerung von 30 Minuten implementiert, so werden auch Benutzerfehler erst nach diesem Zeitraum appliziert. Fällt das Primärsystem aus, so müssen die Transaktionen der letzten 30 Minuten auf dem Standby-System nachgefahren werden, bevor dieses die Betriebsfähigkeit wiederherstellen kann. Ab Oracle 10g ist es nicht mehr notwendig, ein solches Delay einzusetzen, um Benutzerfehler abfangen zu können. Vielmehr kann hier die Oracle Flashback- Technologie eingesetzt werden (siehe auch Kapitel 3.1.2»Oracle und Online-Technologien«). Diese erlaubt ein vorübergehendes Zurücksetzen einer Datenbank in einen früheren konsistenten Zustand. Flashback lässt sich auch auf einer Standby- Datenbank ausführen, um von hier aus die Daten über einen Datenbank-Link zurück zur Primärdatenbank zu übertragen. Abschließend kann die Standby- Datenbank durch Wiederholung aller Transaktionen des Primärsystems wieder auf den aktuellen Zustand der Primärdatenbank vorgerollt werden. Standby-Datenbanken können weiterhin als Disaster Recovery-Strategie eingesetzt werden. Man kann Standby-Datenbanken lokal oder auch in entfernten Rechenzentren betreiben. Beides lässt sich auch innerhalb einer Standby-Konfiguration miteinander verbinden: Eine Standby-Datenbank kann beispielsweise lokal, eine

7 58 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen zweite entfernt betrieben werden. Dabei sind sehr große Distanzen auch über Kontinente hinweg möglich. Bei Ausfall eines der Rechenzentren kann der Betrieb weiterhin aufrechterhalten werden. Client Client Client Client Client Public Network WAN Primär- Datenbank Standby Datenbank (lokal) Standby Datenbank (in entferntem Rechenzentrum) Storage Storage Storage Abbildung 3.2: Schematische Darstellung einer Konfiguration mit Standby-Datenbanken Es ist möglich, bis zu neun Standby-Datenbanken an einer Primärdatenbank zu betreiben. So bietet es sich in manchen Umgebungen an, zwei Standby-Datenbanken zu verwenden. Dies gilt insbesondere bei Verwendung spezieller Protection Modes, die garantieren, dass kein Datenverlust entsteht. Komponenten für den Einsatz von Standby-Datenbanken sind: X ein Primärsystem und ein Standby-System (jeweils mit eigenem Storage) X eine Netzwerkverbindung zwischen Primär- und Standby-System Vorteile einer Standby-Datenbank: X bei Verwendung von Oracle Data Guard: Übernahme der Funktionalität bei Ausfall eines Servers ohne administrativen Eingriff X Bei Ausfall eines Rechenzentrums kann unter Verwendung einer entfernten Standby-Datenbank der Betrieb weiter aufrechterhalten werden X Disaster-Schutz durch Einsatz eines Remote-Rechenzentrums möglich X Schutz vor Benutzerfehlern (abhängig von der Verzögerungsdauer bzw. bei Einsatz von Flashback Database auf der Standby-Seite) X Nutzung der Standby Database für das Reporting

8 Oracle High Availability-Technologien 59 Nachteile einer Standby-Datenbank: X Übernahme der Betriebsfähigkeit durch Standby benötigt etwas mehr Zeit als bei Hot Standby X erhöhte Netzlast durch Übertragung der Redo Log Informationen zwischen Primär- und Standby System; evtl. sollte zusätzliche Bandbreite zur Verfügung gestellt werden Oracle Real Application Cluster (Hot Standby) Bei Nutzung des Oracle Real Application Cluster sind im Normalbetrieb zwei oder mehrere Rechnerknoten im Cluster aktiviert. Der Vorteil: Fällt ein Rechner aus, so können Clients unmittelbar und ohne Wiederanlaufzeit auf einen verbleibenden Rechnerknoten konnektieren. Zudem können Lasten auf alle Clusterknoten verteilt werden. Langlaufende Operationen können mittels Parallel Slave-Prozessen auch über den gesamten Cluster parallelisiert werden. So ist neben der erhöhten Verfügbarkeit auch das Thema Skalierung eine der Stärken des Real Application Cluster. Redundante Hardware wird nicht nur im Fehlerfall eingesetzt, sondern kann anders als bei Failover Clustern im Normalbetrieb genutzt werden. Ähnlich wie in einem Oracle Failover Cluster wird auch hier ein Private Network für den Cluster Heartbeat sowie ein davon separiertes Public Network benötigt. Allerdings wird im Oracle Real Application Cluster konkurrierend auf die Datenbankdateien eines Shared Storages zugegriffen. Dies erfordert zusätzlichen Kommunikationsaufwand zwischen den Knoten, der zur Abstimmung von Sperren und veränderten Block-Images nötig ist. Diese Clusterkommunikation erfolgt über das Private Network. In Real Application Clusterumgebungen ist es daher wichtig, einen möglichst schnellen privaten Cluster Interconnect zu nutzen. Mindestens Gigabit-Ethernet sollte eingesetzt werden. Besser noch sind spezielle, oft proprietäre Lösungen mit höherer Bandbreite. Beispiele sind Memory Channel (alphabasierte HP Cluster), Myrinet (Linux Systeme), Scalable Coherent Interconnect (SUN), Veritas LLT (verschiedene Plattformen) oder HP Hyper Fabric HMP. Notwendige Komponenten für den Einsatz eines Oracle Real Cluster sind: X Shared Storage für alle beteiligten Cluster Nodes (konkurrierender Zugriff) X Verwendung von Cluster-Filesystem, ASM oder Raw Devices auf dem Shared Storage X für jeden Clusterknoten mindestens je zwei Private und zwei Public Network Interfaces X Oracle Cluster Ready Services oder Cluster Mangement-Software eines Drittherstellers

9 60 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Client Client Client Client Client Public Network Node 1 (Aktiv) Node 2 (Aktiv) Node 3 (Aktiv) Node 4 (Aktiv) Private Network Private Network Private Network Shared Storage Abbildung 3.3: Schematische Darstellung des Real Application Cluster Vorteile eines Oracle Real Application Cluster: X Übernahme der Funktionalität bei Ausfall eines Servers ohne administrativen Eingriff X kein Zeitaufwand für Wiederanlauf, Client Reconnect direkt ohne Zeitversatz auf den Ersatzknoten X Redundante Hardware kann auch während des Normalbetriebs genutzt werden X Parallelisierung über alle Clusterknoten hinweg realisierbar X dynamische Zuordnung von Services möglich Nachteile eines Oracle Real Application Cluster: X Bei Ausfall eines Rechenzentrums (z.b. durch einen Brand) fällt der gesamte Cluster aus. Dieser Fehlerfall kann bei Bedarf durch Einsatz einer zusätzlichen Standby-Datenbank in Kombination mit Oracle Real Application Cluster abgefangen werden. Geo Cluster, Datenbankspiegel und Hardware-Replikation Einige Drittanbieter wie Veritas oder Libelle bieten erweiterte Möglichkeiten der Disaster-Absicherung. Geo Cluster erlauben Clustering ohne geografische Grenzen. Je nach Architektur können die Clusterknoten in Rechenzentren stehen, die von einigen wenigen bis zu mehr als hundert Kilometer entfernt sind. Manche Hersteller bieten auch Lösungen, die Spiegel- und Replikationsmechanismen über Kontinente hinweg unterstützen. Die Architekturen der einzelnen Hersteller sind ebenso unterschiedlich wie die Implementierung. Verfahren wie Hardware-Replikation und Datenbankspiegel schützen ebenfalls vor logischen und physikalischen Ausfällen. Kernkonzept ist die Spiegelung über große Distanzen. Das Ergebnis ist von der Funktionalität her ähnlich einer Standby- Datenbank. Der Layer zur Realisierung liegt jedoch unterhalb der Datenbank-

10 Oracle High Availability-Technologien 61 managementschicht: Hardware-Spiegel und Spiegel auf Filesystemebene sind die häufigsten Vertreter dieser Architektur. Replikation kann auch innerhalb der Datenbank implementiert werden. Snapshot und Multimaster-Replikation sowie Oracle Streams bieten hier weitere Möglichkeiten, erhöhte Verfügbarkeit umzusetzen. Diese darzustellen würde den Rahmen dieses Buches sprengen. Daher muss hier auf weiterführende Literatur verwiesen werden; siehe auch [ORACLE_2004_01] und [ORACLE_2004_02]. Voraussetzungen zur Implementierung von Geo Clustern und Datenbankspiegeln: X abhängig vom Anbieter, sehr unterschiedliche Implementierungen Vorteile: X Datensicherheit und Verfügbarkeit auch bei Disastern Nachteile: X Kosten für Lizenzen der Drittanbieter-Software X oftmals erhöhte Bandbreite nötig Cluster-Technologien allein schützen also nicht vor Katastrophen wie Feuer, Wasser und Blitz. Soll ein System auch vor solchen Gefahren geschützt werden, so müssen die Cluster- und RAID-Systeme räumlich voneinander getrennt werden. Zudem sollte das Backup-System nicht im gleichen Gebäude bzw. Brandabschnitt stehen. Für den Cluster ist dies meist noch relativ einfach zu realisieren, die Mehrkosten halten sich in Grenzen. Die räumliche Trennung eines RAID-Systems jedoch bedeutet einen erheblichen technischen Aufwand und verursacht enorme Mehrkosten. Zur Realisierung wird in der Regel ein weiteres gleiches RAID-System in einem anderen Gebäude, eine exklusiv für die Datenspiegelung genutzte Glasfaserverbindung sowie spezielle Controller und Software benötigt. Kosten hierfür gehen schnell in die Hunderttausende Oracle und Online-Technologien Online-Reorganisation und Redefinition Sind Daten in der Datenbank stark fragmentiert, wird u.u. eine Reorganisation notwendig. Mussten früher Daten exportiert und wieder importiert werden, so kann dies heute ohne Downtime online, also im laufenden Betrieb geschehen. Trotzdem sollte man natürlich nicht Zeiten der Hochlast für eine Reorganisation wählen. Schließlich benötigen auch Online Vorgänge einige Ressourcen. Eine Tabellenspalte umzubenennen, eine Spalte hinzuzufügen oder zu entfernen, Speicherplatzklauseln zu verändern oder ein Datensegment von einem Tablespace in einen anderen zu verschieben, war früher eine aufwändige Angelegenheit. Online-Redefinition erlaubt diese Arbeiten im laufenden Betrieb. Das klingt nach einer Selbstverständlichkeit. Doch bedenkt man, dass zum Umbenennen einer Tabellenspalte in älteren Oracle-Versionen eine Temporärtabelle angelegt, die Ori-

11 62 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen ginaltabelle gelöscht, mit dem geänderten Spaltennamen erzeugt und abschließend mit den Daten aus der Temporärtabelle befüllt werden musste, so ist Online- Redefinition ein enormer Fortschritt im Hinblick auf Verfügbarkeit. Voraussetzungen: X keine Vorteile des Einsatzes von Online-Reorganisation und -Redefinition: X keine Downtimes X einfache Handhabung Nachteile des Einsatzes von Online-Reorganisation und -Redefinition: X keine Dynamic Reconfiguration Bereits mit Oracle 9i wurde die dynamische System Global Area (SGA), also ein dynamisch veränderbarer Aufbau des von der Oracle-Instanz genutzten Arbeitsspeichers, eingeführt. In älteren Versionen war es notwendig, die Instanz nach der Anpassung entsprechender Werte im Parameterfile der Datenbank neu zu starten. Auch wenn die Downtimes hierfür meist nur wenige Minuten dauerten, so bietet Dynamic Reconfiguration durch Änderungen der SGA im laufenden Betrieb eine höhere Verfügbarkeit. Voraussetzungen: X Verwendung dynamischer Speicherparameter Vorteile des Einsatzes von Dynamic Reconfiguration: X Änderungen der Datenbankinstanz im laufenden Betrieb ohne Restart der Instanz möglich. Nachteile des Einsatzes von Dynamic Reconfiguration: X keine Oracle und Fast Backup und Recovery Ist der Fehlerfall doch einmal eingetreten, gilt es, die Systemumgebung schnellstmöglich wiederherzustellen. Oracle 10g bietet dazu verbesserte Fast Recovery-Möglichkeiten. Ein neu eingeführter Flash Recovery-Bereich nimmt Flashback- und Archive-Logs sowie Disk-Based-Backups auf. Dies gewährleistet zusätzliche Redundanz auf Speicherebene und schnelle Wiederherstellungsmöglichkeiten von Disk. Zudem wurden Backup-Prozeduren in 10g automatisiert. Direkt bei Datenbankerstellung kann das Automated Backup aktiviert werden. Aber auch Automatic Storage Management bietet neue Möglichkeiten, um Redundanz auf Storage-Ebene zu vereinfachen.

12 Oracle High Availability-Technologien 63 Flashback Oracle Flashback bietet hervorragende Wiederherstellungsmöglichkeiten bei Benutzerfehlern. Tabellen, die gelöscht wurden, können in Sekundenschnelle wiederhergestellt werden. Wurden Daten versehentlich geändert, so lassen sich diese auf Tabellenebene auf einen bestimmten Zeitpunkt zurücksetzen. Auch die gesamte Datenbank kann auf einen früheren Zeitpunkt zurückgerollt werden. Dazu musste früher ein Backup eingespielt und anschließend»point in Time«recovert werden. Heute genügt ein einfacher SQL-Befehl. Möglich wird dies durch spezielle Flashback Logs. Flashback lässt sich ebenfalls mit Standby-Datenbanken kombinieren. So kann im Fehlerfall die Standby-Datenbank zurückgesetzt werden, um anschließend den alten Datenbestand zurück in das Produktionssystem zu übertragen. Dieses kann durchgehend in Betrieb bleiben. Für manche Umgebungen wie z.b. ein Auskunftssystem (Fahrplanabfrage, Telefonauskunft, Katalogdaten u.ä.) kann auf diese Weise ohne Downtime die Wiederherstellung versehentlich gelöschter oder veränderter Daten erfolgen. Aber auch für andere Systeme bildet Flashback eine schnelle Wiederherstellungsmöglichkeit in Situationen, in denen früher der enorm zeitaufwändige Restore der gesamten Datenbank mit anschließendem Point-in-Time- Recovery nötig war. Voraussetzungen zur Implementierung von Flashback: X ausreichend großer Undo Tablespace für die Wiederherstellung auf Tabellenebene X Archive Log Mode und Flashback Mode für die Wiederherstellung auf Datenbankebene Vorteile des Einsatzes von Flashback: X sehr schnelle Wiederherstellung von Daten bei logischen Fehlern Nachteile des Einsatzes von Flashback: X höherer Verbrauch an Festplattenspeicher für Undo-Informationen und Flash Recovery Logs abhängig von der exakten Konfiguration Fast Recovery und RMAN Ist der Ernstfall doch einmal eingetreten, wird im schlechtesten Fall die Wiederherstellung der Datenbank aus einem Backup nötig. Hier kommt der Recovery Manager zum Einsatz. Unter Fast Recovery ist die schnellstmögliche Wiederherstellung eines Systems zu verstehen. Diese kann je nach Fehlertyp über ein Flashback Database, ein diskbasierendes oder ein tape-basierendes Restore mit Recovery erfolgen. Oracle 10g bietet mit Automatic Disk Based Backup eine wesentlich schnellere Wiederherstellungsmöglichkeit, als sie bisherige Verfahren gewährleisten konnten. Dabei wird ein Speicherbereich, die Flash Recovery Area, genutzt, die günstigere Zugriffsmöglichkeiten als Tapes bietet. Die im Flash Recovery Area gespeicherten Backups können automatisiert auf Band archiviert werden. So liegen die neuesten Backups in Form von Files auf Disk vor, ältere Backups können wenn auch mit mehr Zeitaufwand von Tape wiederhergestellt werden.

13 64 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Die Wiederherstellungsmöglichkeiten aus Automated Disk Based Backups decken alle Level ab: Angefangen von Block Level Media Recovery über einzelne Data Files bis hin zur gesamten Datenbank wird jede manuelle oder in Oracle Recovery Manager (RMAN) zur Verfügung gestellte Restore-Option unterstützt. Der Recovery verhielt sich bei seiner Einführung wie dies häufig bei Einführung neuer Optionen der Fall ist recht unzuverlässig. Vielen Oracle-Anwendern blieb er zudem mit seiner teilweise recht kryptischen Syntax und den damals noch recht zahlreichen Bugs eher suspekt. Dieses inzwischen nicht mehr gerechtfertigte Image ist sicherlich der Grund dafür, dass RMAN heute nicht häufiger eingesetzt wird. RMAN gestattet inkrementelle Backups (Verringerung der Backup-Fenster), schnelle Wiederherstellung defekter Datenbankbereiche, Verwendung von Disk Based Backup und Recovery sowie Reparatur von Block Corruptions im laufenden Betrieb und vieles mehr. Oracle 10g arbeitet mit einem Change Tracking-Verfahren. Hierbei wird ein Bitmap mitgeführt, das jene Blöcke kennzeichnet, die seit dem letzten Backup geändert wurden. Dies ermöglicht mit RMAN ein um etwa Faktor 20 schnelleres inkrementelles Backup. Aber auch das Recovery ist wesentlich schneller, die Bedienung über die grafischen Werkzeuge des Oracle Enterprise Manager DBControl und Grid Control zudem einfacher. Die Einrichtung dieser Werkzeuge wird ausführlich in Kapitel 13 beschrieben. Voraussetzungen zur Implementierung: X keine Vorteile des Einsatzes von RMAN: X zahlreiche Erweiterungen in Oracle 10g, die Backup und Recovery Time enorm verkürzen können Nachteile des Einsatzes von RMAN: X bei Einsatz eines Repository: Erhöhte Komplexität sowie eigene Backup-Strategie für die Repository Datenbank Automatic Storage Management Mit Oracle 10g wurde Automatic Storage Management (ASM) eingeführt. Es bietet Funktionalitäten wie Disk Striping und Mirroring. Das ist im Grunde nichts Neues. Jedoch musste bisher entweder Software von Drittanbietern (Logical Volume Manager) oder aber intelligente und damit teure Hardware eingesetzt werden. Mit ASM bietet Oracle einen Built In-Spiegel auf Hard Disk-Basis, der in Version 11 sicher ein Standard sein wird. Voraussetzungen zur Implementierung von ASM: X Verwendung einer ASM-Instanz Vorteile des Einsatzes von ASM: X Mirror und Striping ohne externe Hilfsmittel innerhalb Oracle DBMS möglich Nachteile des Einsatzes von ASM: X Hardware RAID ist noch immer performanter

14 Übersicht von Downtime-Kategorien und Oracle-Technologien Übersicht von Downtime-Kategorien und Oracle-Technologien Alle der in den letzten Abschnitten dargestellten Oracle-Technologien adressieren bestimmte Typen von Downtime. Oracle Real Application Cluster sowie Failover Cluster sichern den Ausfall eines Rechners ab, der Datenbankdienste zur Verfügung stellt. Standby-Datenbanken, die in einem entfernten Rechenzentrum bereitgehalten werden, gewährleisten auch bei so genannten Site-Fehlern die Verfügbarkeit eines Datenbankservers. Der Ausfall eines Rechners, des Storage aber auch des gesamten Rechenzentrum durch Brand, Feuer oder Hochwasser kann damit abgesichert werden. Online Reorganisation und Dynamic Reconfiguration erlauben Wartungsarbeiten am laufenden Produktionssystem ohne Restart des Rechners oder der Datenbankdienste. Flashback federt Benutzerfehler ab und Automatic Storage Management den Ausfall eines Festplatten-Devices. Fast Recovery schließlich gewährleistet in Notfällen eine zumindest relativ schnelle Systemwiederherstellung. Systempflege Dynamic Reconfiguration Standby Datenbank / Data Guard Real Application Clusters Geplante Downtime Hardware Wartung Automatic Storage Management Standby Datenbank / Data Guard Real Application Clusters Upgrades und Patches Standby Datenbank / Data Guard Real Application Clusters Desaster / Katastrophen Standby Datenbank / Data Guard Datenbankspiegel Recovery Manager Systemfehler Real Application Clusters Fast Restart Ungeplante Downtime Menschliche Fehler Flashback und/oder Standby Datenbanken Logische Fehler der Anwendung Flashback und/oder Standby Datenbanken Datenkorruption Recovery Manager Abbildung 3.4: Downtime-Kategorien und korrelierende Oracle-Technologien In 2.3»Downtime-Kategorien«wurden bereits einige Downtime-Kategorien vorgestellt. Abbildung 3.4 zeigt die passenden Technologien, die Oracle bietet, um den

15 66 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen jeweiligen Typ eines Ausfalles abzufangen und eine ununterbrochene Verfügbarkeit des Datenbankservers zu gewährleisten. Eine Gesamtübersicht der Fähigkeiten einzelner Oracle-Technologien in Bezug auf mögliche Fehlertypen und Ausfallursachen zeigt Tabelle 3.1. Schutz vor logischen Fehlern Schutz vor Datenverlust Disaster- Schutz Rechnerverfügbarkeit Failover Cluster Nein Nein Siehe 1 Ja Nein Wiederanlaufzeiten der einzelnen Verfahren Volle Resourcennutzung Standby-Datenbanken Nein Ja Siehe 2 Ja Teilweise 3 Real Application Cluster Nein Nein Siehe 4 Siehe 5 Ja Geo Cluster Nein Ja Ja Ja Siehe 6 Datenbankspiegel Siehe 7 Ja Ja Ja Siehe 8 Dynamic Reorganisation Nein Nein Nein Nein Ja Dynamic Reconfiguration Nein Nein Nein Nein Ja Flashback Ja Ja Nein Ja Recovery Manager Ja Ja Ja Nein Automatic Storage Management Nein Siehe 9 Nein Ja Infrastrukturmaßnahmen Nein Ja Ja Ja Hardware-Redundanz Nein Siehe 10 Nein Siehe 11 Tabelle 3.1: Übersicht der Schutzmaßnahmen Je nach Fehlerfall und -typ unterscheiden sich die Wiederanlaufzeiten z.t. enorm. Doch selbst innerhalb eines Fehlertyps variiert der Zeitraum, der für die Wiederherstellung der Verfügbarkeit eines Oracle-Datenbankservers benötigt wird. So benötigt ein Standby-System für den Failover eine Initialisierung durch einen Administrator und muss möglicherweise zunächst noch Redo-Informationen verarbeiten, bevor die Datenbankinstanz auf dem Standby-System gestartet werden kann Bei Distanz zwischen Rechnerknoten: Ja 2 Bei Verwendung von Remote Standby-DB: Ja 3 Reporting auf Standby DB möglich 4 Nein (Ausnahme: entfernte Clusterknoten) 5 Ja, auch bei Hardwareausfall: Unterbrechungsfreier Betrieb möglich 6 Abhängig vom Hersteller 7 Bei zeitversetzter Spiegelung: Ja 8 Abhängig vom Hersteller 9 Auf Hardware-Level: Ja 10 Bei Verwendung von RAID 1 oder 5: Ja 11 Bei Hardwareausfall: Unterbrechungsfreier Betrieb möglich

16 Übersicht von Downtime-Kategorien und Oracle-Technologien 67 Bei einem Cold Standby-System müssen Ressourcengruppen den Clusterknoten wechseln. Entsprechende Disk Devices müssen gemountet werden, bevor die Oracle- Datenbank angesprochen werden kann. Eine Hot Standby-Lösung dagegen gestattet einen enorm schnellen Failover: Da weitere Instanzen bereits geöffnet und betriebsbereit sind, muss nur ein Client- Failover erfolgen, der insbesondere bei Anwendungen, die cluster aware sind, in weniger als einer Minute realisiert werden kann. Als cluster aware werden Anwendungen bezeichnet, die über Schnittstellen mit dem Cluster Manager kommunizieren bzw. auf clusterspezifische Fehlermeldungen reagieren. Andere Technologien wiederum vermeiden Downtimes. Dynamic Reconfiguration und Online Reorganisation gestatten Wartungsarbeiten an der Datenbank im laufenden Betrieb. Tabelle 3.2 zeigt eine Übersicht von Oracle-Technologien und deren Wiederanlaufzeiten. Downtime- Kategorie Geplant und ungeplant Geplant und ungeplant Geplant und ungeplant Geplant und ungeplant Downtime-Ursachen Oracle-Technologie Wiederanlaufzeit Wartungsarbeiten Rechnerausfall Wartungsarbeiten Benutzerfehler Komponentenausfall Rechnerausfall Disaster mit Rechnerverlust Wartungsarbeiten Rechnerausfall Wartungsarbeiten Benutzerfehler Komponentenausfall Rechnerausfall Disaster mit Rechnerverlust Tabelle 3.2: Oracle-Technologieübersicht 1 Cold Standby mit Failover Cluster Warm Standby mit Standby-Datenbanken Hot Standby mit Oracle Real Application Clusters 1 Geo Cluster und Datenbankspiegel Ungeplant Ausfall einer Festplatte Automatic Storage Management Ungeplant Medienfehler Disaster Fast Recovery / Fast Restart 1 bis 30 Minuten 1 bis 20 Minuten Wenige Sekunden bis zu 2 Minuten 1 bis 30 Minuten Keine Ausfallzeit (Hot Swap) Abhängig von Ausfallgrund und wiederherzustellender Datenmenge Ungeplant Benutzerfehler Flashback Keine Ausfallzeit Ungeplant Datenkorruptionen Datenverlust Recovery Manager Abhängig vom Ausfallgrund Rechnerverlust Geplant Rekonfiguration Dynamic Keine Reconfiguration Geplant Reorganisation Online Reorganisation Keine 1 Bietet zusätzlich Lastverteilung und Skalierung

17 68 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen 3.3 Maßnahmen für Middle Tier und Application Server Im Middle Tier finden Technologien wie Load Balancing, aber auch Clustering und Failover Anwendung. Beim Load Balancing werden Requests über mehrere Applikationsserver verteilt. Oracle erweitert mit dem Internet Application Server die Verfügbarkeit auf die gesamte Oracle Internet-Plattform über die Datenbankserver hinaus bis zu Middle-Tier-Lösungen. Mit dem Oracle E-Business Continuity Program können Unternehmen Technologien im Dauerbetrieb für ihre grundlegendsten, wichtigsten Geschäftsabläufe nutzen, unabhängig davon, wo diese ablaufen. 3.4 Infrastrukturmaßnamen Neben der Architektur einer hochverfügbaren Systemumgebung sind auch generelle Maßnahmen bezüglich der Infrastruktur zu überdenken. Dazu gehören insbesondere die Stromversorgung, aber auch Klimatechnik und Schutz vor Feuer, Nässe und Blitzschlägen Sicherung der Stromversorgung Damit ein Ausfall der Stromversorgung nicht zum Ausfall des Rechnersystems führt, wird dieses durch eine unterbrechungsfreie Stromversorgung (USV), durch ein Notstromaggregat oder durch beides gesichert. Muss der Betrieb bei Stromausfall nicht zwangsläufig aufrechterhalten werden, reicht es oft auch schon aus, den Stromausfall festzustellen und am Rechner ein Interrupt auszulösen. Ein solches Power-Fail-Interrupt wird in der Regel vom Netzteil ausgelöst. Das Netzteil speichert meist in Kondensatoren Energie. Fällt die Spannung unter einen kritischen Wert, wird ein Interrupt ausgelöst. Dem Steuerungssystem bleibt dann noch eine kurze Zeitspanne, um das System in einen sicheren Status und die Steuerung in einen konsistenten Zustand zu bringen Klimatechnik Überhitzung ist eine der häufigeren Ursachen für Rechnerausfälle. Sie führt oft zunächst zu schwer prüfbaren, sporadischen Fehlern, gelegentlich auch zum Totalausfall. Adäquate Klimatechnik schafft hier Abhilfe. Natürlich sollte auch gegen den Ausfall der dazu notwendigen Klimatechnik vorgebeugt werden. Eine redundante Auslegung der Klimaanlage ist nicht nur in großen Rechenzentren durchaus üblich Schutz vor Feuer, Nässe, Blitzschlag und Einbruch Rechnerräume sollten speziell vor Feuer, Nässe und Blitzschlag sowie vor Einbrüchen gesichert werden. Auch der Aufbewahrungsort von Backup Tapes sollte dieser Anforderung genüge tun.

18 Hardware-Redundanz Hardware-Redundanz Welche Maßnahmen zur Vermeidung von SPOFs auf Rechnerebene ergriffen werden, sollte ebenfalls geprüft werden. Hier spielt insbesondere die Redundanz von System- und Einzelkomponenten als auch der Einsatz von RAID Storage eine wichtige Rolle Redundanz der Systemkomponenten Durch Redundanz kann wie dargestellt die Verfügbarkeit erhöht werden. Bei diesem Ansatz ist es jedoch problematisch, den Ausfall festzustellen, den Systemzustand des ausgefallenen Systems auf die redundante Ersatzkomponente zu übertragen und diese schließlich zu aktivieren. Die Überwachung einer redundant ausgelegten Komponente muss auf Systemebene erfolgen. Dazu kann beispielsweise eine Überwachungs- bzw. Koppeleinrichtung dienen. Diese kann aktiv oder passiv die Komponente kontrollieren. Wird die Komponente passiv überwacht, muss die aktive Komponente in periodischen Abständen ein Lifesign (Lebenszeichen) übermitteln. Dieses Lifesign setzt in der Überwachungseinrichtung einen Watchdog zurück. Wird der Watchdog nicht rechtzeitig zurückgesetzt, schaltet die Überwachungseinrichtung auf die redundante Komponente um. In der Literatur sowie in Dokumentationen wird dieses Lifesign auch häufig als Cluster Heartbeat bezeichnet. Bei der aktiven Überwachung wird die zu überwachende Komponente periodisch mit einer Anforderung beschickt, die das System im funktionstüchtigen Zustand beantwortet. Beispiel: Eine Netzkomponente kann überwacht werden, indem man ihr regelmäßig ein»echo request«-paket sendet. Da die Komponenten meistens interne Zustände besitzen, müssen diese beim Ausfall bekannt sein und auf die redundante Ersatzkomponente übertragen werden, um Informationsverlust zu vermeiden. Dieses stellt die größte Herausforderung dar: Bei Systemen im Hot Standby wird der interne Zustand regelmäßig mit dem Ersatzsystem abgeglichen. Dieser Abgleich muss so häufig erfolgen, dass ein Umschalten ohne Informationsverlust zu jedem beliebigen Zeitpunkt möglich ist. Die wohl verbreitetste Technologie, ein redundantes System im Hot Standby zu betreiben, ist, dass das Ersatzsystem parallel mit der aktiven Komponente arbeitet. Es bekommt die gleichen Eingangsinformationen und berechnet mit den gleichen Applikationen die Ausgabewerte. Solange die aktive Komponente funktionstüchtig ist, leitet die Überwachungs- bzw. Koppeleinrichtung diese Ausgabewerte nicht an den technischen Prozess weiter. Im Cold Standby muss die Komponente ihren Systemzustand ständig (oder zumindest an den relevanten Punkten) auf ein Medium sichern, auf das das Ersatzsystem auch beim Ausfall der Komponente Zugriff hat. Hierbei ist auch der Fall zu berücksichtigen, dass sowohl die Komponente als auch das Medium, auf das der Zustand gesichert wird, ausfallen kann (aus»material zur Vorlesung Prozesssteuerung/ Hochschule Niederrhein«).

19 70 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Redundanz der Einzelkomponenten Auf Komponentenebene werden mindestens CPU, Speicher, Festplatten (RAID), Netzwerkkarten, Lüfter und Netzteile redundant ausgelegt RAID RAID steht für Redundant Array of Inexpensive Disks. Unter diesem Begriff werden verschiedene Technologien zusammengefasst, die einzelne Festplatten zu einem preiswerten, schnellen und sicheren Platten-Cluster verbinden. Dabei werden insgesamt sechs RAID-Level spezifiziert, die unterschiedliche Eigenschaften bezüglich Zuverlässigkeit und Zugriffsgeschwindigkeit aufweisen. Alle Festplatten bestehen aus logischer Sicht zunächst aus einer Anzahl von sequentiell hintereinander liegenden Blöcken. In einem RAID-System wird eine spezifizierte Anzahl derartiger Blöcke Stripe (Streifen) genannt. Unabhängig von der Anzahl der verwendeten Festplatten wird dem System eine einzige virtuelle Festplatte zur Verfügung gestellt. RAID-Level 0 dient allein zur Erhöhung der Zugriffsgeschwindigkeit. Der RAID- Level 0 basiert auf zwei oder mehr Festplatten. Ein Performancegewinn beim Zugriff wird dadurch erreicht, dass die dem System zur Verfügung gestellte Sicht auf das Speichermedium aus abwechselnd einem Stripe der beiden Platten besteht. Liest das System mehrere sequentielle Blöcke, wird die Last auf die beteiligten Platten verteilt, die Zugriffe sind insgesamt schneller als bei anderen RAID-Leveln. Bei RAID 1 werden die Partitionen einer Platte auf eine zweite Platte gespiegelt. Bei Ausfall einer der beiden Platten, steht noch die jeweils redundante Platte zur Verfügung. Nachteilig ist, dass bei der Verwendung von zwei Platten nur der Speicherplatz einer Platte zur Verfügung steht. RAID 2 und 3 spielen heute kaum mehr eine Rolle. Beide sind Spezialfälle von RAID 4. RAID 2 speichert anstelle der Parity-Information ECC-Information, RAID-Level 3 benutzt die kleinstmögliche Stripe-Größe, sodass jeder Zugriff zu einem Zugriff auf allen Platten führt. Auch RAID 4 wird zur Erhöhung der Verfügbarkeit des Plattensystems verwendet. Wie bei RAID 0 werden abwechselnd die Stripes der Platten als eine virtuelle Platte dem Rechnersystem zur Verfügung gestellt. Darüber hinaus wird aber noch auf einer eigenen Platte Parity-Information abgespeichert, sodass der Ausfall einer N- Platte toleriert werden kann. Die Speicherkapazität entspricht damit bei n+1 Platten jener von genau n Platten. Die Zugriffsgeschwindigkeit auf den Plattenstapel ist insbesondere beim Schreiben sehr niedrig, da nicht nur die Daten, sondern die Paritätsinformation sowohl gelesen als auch geschrieben werden muss. Da diese Information für sämtliche Stripes auf der Parity-Platte liegt, stellt die Parity-Platte einen Flaschenhals dar. Bei RAID-Level 5 wird die Paritätsinformation auf sämtliche Platten verteilt. RAID 5 ist aufgrund der Berechnung der Paritätsinformation beim Schreiben nicht sehr performant. Daher ist bei Dateien mit hoher Schreiblast wie z.b. Redo Logfiles von der Verwendung von RAID 5 abzuraten. Für Leseoperationen bietet dieser RAID-Level aufgrund der Verteilung der Plattenzugriffe jedoch eine gute Performanz.

20 Software 71 Im Datenbankumfeld wird häufig eine Kombination aus RAID 1 und 0 für hohe Transaktionsraten sowie RAID 5 für weniger schreibintensive Operationen eingesetzt Weitere Maßnahmen, die nicht auf Redundanz beruhen Während sich durch Redundanz die Verfügbarkeit eines Gesamtsystems erhöhen kann, kann die Verfügbarkeit der Einzelkomponenten durch folgende Maßnahmen gesteigert werden: X Auswahl zuverlässiger Bauelemente X Steigerung der mechanischen Festigkeit (Schutz vor Vibrationen, Bruchschutz) X Fixierung löslicher Elemente (Lackierung von Schrauben) X Wärmeschutz X Vorbeugende Wartung Durch eine Betriebsdatenüberwachung können Temperaturen und Spannungen innerhalb der Komponenten überwacht und geregelt werden. Eine zu hohe Temperatur bei einem Rechnerkern kann beispielsweise dazu führen, dass dem Prozessor durch Untertaktung weniger Leistung abverlangt wird. Eine Betriebsdatenüberwachung wird von einigen Herstellern bereits bei gängiger Hardware angeboten. 3.6 Software Um eine hohe Verfügbarkeit zu gewährleisten, ist auch softwareseitig eine Reihe von Maßnahmen notwendig: X Software ermöglicht die Überwachung der Systemkomponenten bzw. auch die Diagnose der Fehlerursache. X Das Umschalten und der Abgleich zwischen dem aktiven System und dem Ersatzsystem müssen im Regelfall durch Software unterstützt werden. X Um Informationsverlust bei Ausfall eines Systems vorzubeugen, muss eine Backup-Strategie für Daten und Systemzustände existieren. X Auch innerhalb der Applikation sind entsprechende Maßnahmen zum Schutz vor Datenverlust vorzusehen. 3.7 Management Grundlegende Entscheidungen zu Wartung, zum Personaleinsatz und zur Vorgehensweise in Notfällen fallen in den Bereich des Managements Wartung Kritische Systeme müssen ständig überwacht und gewartet werden. Auch der regelmäßige Austausch wichtiger (alternder) Komponenten kann sinnvoll sein. Ein großes und oft wenig beachtetes Problem bei Systemen mit langer Laufzeit besteht darin, dass Ersatzkomponenten nicht mehr verfügbar sind.

21 72 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen Personaleinsatz Fällt das System oder auch nur eine Komponente des Systems aus, sind Eingriffe durch den Menschen notwendig, um es wieder in den funktionstüchtigen Zustand zu bringen: Die Fehlerursache muss festgestellt und analysiert, redundante Systeme müssen aktiviert und Ersatzteile eingebaut werden. Aus diesem Grunde muss sichergestellt werden, dass kompetente Mitarbeiter erreichbar und in kürzester Zeit vor Ort sind oder remote eingreifen können. Gerade bei unternehmenskritischen Anwendungen sollte außerdem darauf geachtet werden, dass Mitarbeiter auf mehrere Standorte verteilt sind. Dies gewährleistet, dass im Katastrophenfall ein anderer Standort die Aufgaben übernehmen kann Notfallplan Um Stillstands- bzw. Ausfallzeiten zu verkürzen, sind Notfallpläne unumgänglich. Einer Studie des britischen Marktforschungsunternehmens Macarthur Stroud International zufolge besitzen rund ein Fünftel der befragten Unternehmen überhaupt keine Notfallstrategie für einen Systemausfall. Viele Unternehmen vernachlässigen das Risiko und übersehen die Tatsache, dass mit der Unterbrechung der IT-Systeme u.u. eine unternehmensbedrohliche Situation entstehen kann. Notfallpläne beinhalten strukturiert und Punkt für Punkt alle notwendigen Maßnahmen, um die Systeme in der kürzestmöglichen Zeit wieder in Betriebsbereitschaft zu überführen. Ein durchdachter Handlungsablauf für den Fall des Falles ist ein essentieller Bestandteil jeder wirksamen Katastrophenplanung. Zunächst sollten für den Notfall abzulaufende Prozeduren näher bestimmt und bis auf einzelne Schritte heruntergebrochen werden. Für die Durchführung der einzelnen Schritte ist es notwendig, dass die dafür relevanten Ressourcen jederzeit zugänglich und für mehrere Personen verfügbar sind. Was nützt eine Tape-Sicherung mit den wichtigsten Systemdaten für eine schnelle Disaster Recovery, wenn ihr Aufbewahrungsort nur einem Mitarbeiter bekannt ist, der gerade nicht erreichbar ist? Sinnvoll ist es daher, ein Team zu bilden, dessen Mitglieder immer über alle Informationen verfügen. So kann im Notfall jeder Einzelne alle notwendigen Maßnahmen einleiten. Bei größeren Unternehmen sollten dabei möglichst Mitarbeiter aus mehreren Niederlassungen einbezogen werden. Die einzelnen Schritte des Notfallplans sollten schriftlich hinterlegt werden, damit sie auch dann verfügbar sind, wenn der verantwortliche Administrator nicht erreichbar ist. Der Aufbewahrungsort des schriftlichen Planes sowie aller relevanten Ressourcen muss allen Beteiligten bekannt und problemlos zugänglich sein. Ausgehend vom Fehlerbild enthalten die Notfallpläne Listen, die zur Identifikation der defekten Komponente führen (Fehlerlokalisierung, Diagnose). Wichtig ist, in einem regelmäßigen Turnus zu überprüfen, ob der einmal erstellte Plan noch Gültigkeit hat und die Strategie noch zu den aktuellen Anforderungen passt. Regelmäßige Tests zeigen, ob der Plan im realen Fall noch funktionieren würde. Dabei sollte insbesondere dem gestiegenden Datenvolumen, der aktuellen Nutzeranzahl, aber auch den allgemeinen Richtlinien, wie gesetzlichen Bestimmungen oder betrieblichen Richtlinien, Rechnung getragen werden.

22 Bestimmung der Maßnahmen 73 Auf folgende Punkte sollte der Notfallplan geprüft werden: X Gibt es mehrere Teammitglieder (möglichst an unterschiedlichen Standorten)? X Ist ein vollständiger Notfallplan für die Anwendung vorhanden? X Ist der Plan für alle Teammitglieder zugänglich? X Ist der Notfallplan schriftlich hinterlegt und wissen alle Mitglieder, wo der Notfallplan hinterlegt wurde? X Sind alle Teammitglieder über den Inhalt des Notfallplans informiert? X Wurde der Notfallplan innerhalb der letzten sechs Monate erfolgreich getestet? Gerade der letzte Punkt wird in der Praxis häufig übergangen. Doch der schönste Plan nutzt wenig, wenn relevante Änderungen nicht berücksichtigt wurden. Ein typisches und leider häufiges Beispiel: Ein Backup, das ein neu hinzugefügtes Datenfile nicht mitsichert, weil vergessen wurde, dieses in das Backup Script aufzunehmen, führt zum Verlust der Daten des gesamten Tablespace Fehlerklassifizierung Nicht alle auftretenden Fehler sind gleich kritisch. Insbesondere lassen sich nicht tolerierbare Fehler von den tolerierbaren Fehlern unterscheiden. Unter tolerierbaren Fehlern versteht man den Umstand, dass trotz des Fehlers das System dennoch die geforderte Funktion erbringen kann, weil beispielsweise automatisch auf ein Ersatzsystem umgeschaltet wird. Auch wird die Informationspolitik davon bestimmt, wie kritisch ein Fehler ist: Wer informiert werden muss Techniker, Manager, Kunden, hängt entscheidend davon ab. 3.8 Bestimmung der Maßnahmen Es sollte exakt spezifiziert werden, welche Maßnahmen zu ergreifen sind. Relevant sind dabei die Ergebnisse der Bedarfsanalyse, die zur Klärung der folgenden Punkte herangezogen wird: X Klären Sie genau, was hochverfügbar gemacht werden muss. Müssen bestimmte Daten, ein Dienst eines speziellen Servers oder eine gesamte Applikation zur Verfügung stehen? X Prüfen Sie, welche Ausfallzeiten tolerierbar sind. X Prüfen Sie, welcher Datenverlust tolerierbar ist. X Stellen Sie fest, welche Auswirkungen ein Ausfall auf die Geschäftsabläufe hat. X Ermitteln Sie, was eine Stunde Ausfall Ihr Unternehmen kostet. Das liefert Anhaltspunkte über den notwendigen Grad an Verfügbarkeit. X Wenn in der Vergangenheit bereits Ausfälle aufgetreten sind, stellen Sie deren Ursachen fest und gewichten Sie diese nach Häufigkeit, Ausfallzeitraum und Auswirkungen auf Ihre Geschäftsprozesse. Neben Hard- und Software-Ausfällen spielen die Infrastruktur sowie menschliches Versagen oft eine wichtige Rolle.