Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall des Speichersubsystems: Redundanz via RAID System... Redundant ausgelegtes SAN mit synchronem Mirroring (z.b. PPRC) Ausfall des Rechners: Hot Standby Cluster Oracle RAC (alles basierend auf shared disk) Es sind jeweils Transparenz und Recovery Zeiten zu betrachten! Was ist, wenn sich die Instanz nicht starten lässt? => Datenkorruption
2. Datenkorruption Aussage: Datenkorruption kann mit Backup- und (Media) Recovery Mechanismen begegnet werden. Backup- und Recovery Verfahren sind komplex und müssen regelmäßig trainiert werden! Backups sollten operativen Betrieb nicht behindern! Backup kann online erfolgen, Synchronisation mit Redo Log Archivierung ist gegeben bei Einsatz der zur Verfügung stehenden Datenbank Features. Media Recovery Zeiten müssen (oft hohe) Anforderungen erfüllen: Durch Verwendung von Mechanismen des Speichersubsystems (z.b. Split Mirrors, Flash Copy) können die Zeiten für (Backup und) Restore dramatisch reduziert werden. Es bleibt jedoch noch die Rollforward Recovery! Recovery Zeit im wesentlichen durch Rollforward Recovery bestimmt => Problem mit der Hochverfügbarkeit Und: Datenkorruption im Redo Log bedeutet i.a. Datenverlust.
3. Replikation Hochverfügbarkeitslösungen basieren auf Redundanz => Replikation Was sollte repliziert werden? Datenkorruption auf Block Ebene ist am wahrscheinlichsten, also sollte man nicht Blöcke replizieren. Datenkorruption im Redo Log ist weit weniger wahrscheinlich, also ist eine logbasierte Replikation vorzuziehen. Die Propagation der Datenkorruption ist kein Thema, wenn die (ändernden) SQL-Statements auf beiden Systemen angewandt werden, wobei die Steuerung synchron über 2PC (Two phase commit) erfolgt (Systemstillstand bei Ausfall der Verbindung zum Sekundärsystem!) oder ein Replikationsmechanismus synchron, sofern möglich imlementiert wird. Es ist dabei generell zu bevorzugen, dass ein Applikationsserver (Transaktionsmonitor) die Steuerung der Zugriffe übernimmt.
Logbasierte Replikation => Prinzipiell auch in Oracle Data Guard eingesetzt und anhand dessen diskutiert. Freiheitsgrade sind Zeitpunkt der Übertragung Zeitpunkt der Anwendung Art der Übertragung Zeitpunkt der Übertragung: Synchron (Primärsystem kann nicht weiterarbeiten, wenn (Verbindung zum) Sekundärsystem) ausfällt!) Synchron, falls Verbindung zum Sekundärsystem vorhanden Asynchron Sobald möglich Zeit- bzw. ereignisgesteuert Zeitpunkt der Anwendung: Sofort / Zeitversetzt Art der Übertragung: Physical Standby (Log Records werden auf Sekundärdatenbank angewandt) => Recovery Modus oder Read Only Zugriff auf Sekundärdatenbank Logical Standby (Aus den Log Records werden SQL Statements konstruiert, die auf der Sekundärdatenbank angewandt werden) => Read Write Zugriff auf sekundäre Datenbank.
4. Applikations- und Administrationsfehler Datenverlust i.a. nicht zu vermeiden! Media Recovery Mechanismen: Point in Time Recovery => globaler Datenverlust, zumindest auf Tablespace Ebene Zeitversetzte Replikation => gleiches Problem (Oracle) Flashback Query => Zustand ausgewählter Daten zu einem vorgegebenen Zeitpunkt in der Vergangenheit wird wiederhergestellt, falls möglich (Problem: DDL Statements)
5. High Level Oracle Referenzarchitektur für Rechenzentrum: SAN mit synchroner Spiegelung (synchron wenn möglich!) Cluster Oracle RAC ---------------------- Oracle Data Guard Mehrstufig (kaskadierend): Stufe 1: Absicherung gegen Datenkorruption synchrone Übertragung (wenn möglich) und Anwendung, logical standby Stufe 2: Absicherung gegen Anwendungs- und Administrationsfehler Synchrone Übertragung (wenn möglich), zeitversetzte Anwendung, logical standby Backup & Recovery ( Absicherung gegen Datenkorruption sowie Anwendungs- und Administrationsfehler Flashback Query Absicherung gegen Anwendungs- und Administrationsfehler
6. Disaster Recovery (Ausfall eines Rechenzentrums) Synchrone Spiegelung auf der Ebene des Speichersubsystems? Cluster? Data Guard / Replikation: synchron? Backup & Recovery! 7. Business Continuity Das Geschäft geht weiter: Mitarbeiter Arbeitsplätze... Disaster Recovery und Business Continuity müssen geplant werden!