Datenwiederherstellung mit Oracle Data Guard, LogMiner und Flashback Query in einer SAP Umgebung

Datenwiederherstellung mit Oracle Data Guard, LogMiner und Flashback Query in einer SAP Umgebung Dr. Thimo Bastuck (Freudenberg IT) Claudia Hüffer (ORACLE Deutschland GmbH) SIG ORACLE und SAP St. Leon-Rot, 03.05.2010

03.05.2010 / Seite 2 Agenda 1 2 3 4 5 Einleitung LogMiner Theorie / Fallbeispiele Flashback Technologien Theorie / Fallbeispiel Data Guard Theorie / Fallbeispiele Zusammenfassung

03.05.2010 / Seite 4 Die Referenten Dr. Thimo Bastuck Seit 7 Jahren im Bereich Datenbanken- und SAP- Betrieb tätig Installationen, Migrationen, Releasewechsel von SAP-Systemen und Datenbanken Datenbank-Schwerpunkt Oracle, Hochverfügbarkeit Freudenberg IT Information Services KG, Team SAP Niederlassung Weinheim Claudia Hüffer Seit 16 Jahren im Oracle Umfeld tätig Datenbank, Hochverfügbarkeit, Disaster Recovery Principal Sales Consultant Server Technologies Competence Center Nord ORACLE Deutschland GmbH Geschäftsstelle Hamburg

03.05.2010 / Seite 5 FIT im Überblick IT-Dienstleister für den nationalen und internationalen Mittelstand Laut PAC die erfolgreichste deutsche IT-Ausgründung 2/3 des Umsatzes außerhalb der Unternehmensgruppe Freudenberg Finanziell sicher durch Zugehörigkeit zu der Unternehmensgruppe Freudenberg Niederlassungen in Europa, Nordamerika und Asien (16 Standorte) 11 Rechenzentren auf höchstem Qualitätsstandard Renommierte Kunden aus dem nationalen und internationalen Mittelstand

03.05.2010 / Seite 6 FIT im Überblick Durchgängiges Leistungsportfolio: Beratung, Betreuung und Betrieb Langjähriges und tiefes Prozessverständnis über 30 Jahre SAP Erfahrung Internationale und nationale Partnerschaften Qualitätsmanagement und Zertifizierungen Customer Support Center (international, zweisprachig 7/24)

03.05.2010 / Seite 7 Zertifizierungen/Auszeichnungen Internationale und nationale Zertifizierungen, welche die Kompetenz unserer Mitarbeiter und die Qualität unserer Services untermauern.

03.05.2010 / Seite 8 Oracle Hochverfügbarkeits-Lösungen

03.05.2010 / Seite 10 Was ist der LogMiner? Bestandteil der Oracle Datenbank seit Oracle 8i Schnittstelle zur Analyse von Redo Log-Einträgen Zwei Interfaces SQL*Plus Enterprise Manager Zugrunde liegende PL/SQL-Packages dbms_logmnr dbms_logmnr_d

03.05.2010 / Seite 11 Einsatzgebiete des LogMiner Ermittlung des Startzeitpunktes einer logischen Korruption Festlegung von Schritten für ein fine grained recovery Trend- und Kapazitätsanalysen, Anzahl Zugriffe auf Tabellen, Indizes, Audit von bereits stattgefundenen Transaktionen (Wann wurden Datensätze durch welchen User wie manipuliert,?) Basistechnologie für Oracle Streams und Oracle Data Guard Logical Standby Database (SQL Apply)

03.05.2010 / Seite 12 Komponenten des LogMiners Source Database (Quelldatenbank) Hier werden die Redo Log Einträge generiert Mining Database (Analyse-Datenbank) Hier werden die Redo Log-Einträge analysiert LogMiner Dictionary Übersetzt interne Object-IDs in lesbare Informationen Online catalog, extract in Redo Log, extract in flat file Redo Logs Enthalten das zu analysierende Transaktions-Protokoll v$logmnr_contents Analyse-Ergebnisse via SELECT-Statement oder GUI

03.05.2010 / Seite 13 Voraussetzungen für LogMiner Gleiches Betriebssystem für Quell- und Analyse-Datenbank Quell- und Analyse-Datenbank können getrennte oder gleiches System sein Character-Set der Analyse-Datenbank muss dem der Quelldatenbank entsprechen oder diesen als Superset enthalten LogMiner Dictionary muss auf Quelle erzeugt werden Alle Redo Logs müssen von gleicher DB mit gleicher Resetlog-Nummer stammen, mindestens Oracle 8.0 Supplemental Logging ab 10.2 zwingend, vorher dringend empfohlen

03.05.2010 / Seite 14 Datentypen-Unterstützung Unterstützte Datentypen CHAR, NCHAR, VARCHAR2 und VARCHAR, NVARCHAR2, NUMBER, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, INTERVAL YEAR TO MONTH, INTERVAL DAY TO SECOND, RAW, CLOB, NCLOB, BLOB, LONG, LONG RAW, BINARY_FLOAT, BINARY_DOUBLE, Index-organized tables (IOTs) mit overflow, Function-based indexes, XMLTYPE als CLOB (ab 11.1) Nicht unterstützte Datentypen BFILE, benutzerdefinierte Datentypen (ADTs), Nested tables und VARRAYs, Object refs, Tabellen mit Table Compression, Secure Files

03.05.2010 / Seite 15 Supplemental Logging Eintrag zusätzlicher Spalteninformationen (Supplemental Log Groups) in das Redo Log Ziel: eindeutige Identifizierung einzelner Zeilen ohne Verwendung der ROWID Unterschiedliche Stufen einstellbar Supplemental Log Groups können System- oder User-generiert sein, können auf Datenbank oder Tabellen-Ebene definiert sein Wahlweise Minimal Supplemental Logging (Minimalanforderung ab 10.2) oder Identification Key Logging Minimal Supplemental Logging ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Identification Key Logging ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL PRIMARY KEY UNIQUE FOREIGN KEY) COLUMNS;

03.05.2010 / Seite 16 v$logmnr_contents Analyse-Ergebnisse Bei jedem SELECT werden die angegebenen Redo Logs gelesen, Spool-Datei oder separate Ergebnis-Tabelle empfohlen Art des Statements (INS, UPD, DEL, DDL) in der OPERATION-Spalte Informationen: zu welcher SCN hat das Statement stattgefunden zu welcher SCN wurde die Transaktion committed Information über Transaktions-ID (XIDUSN, XIDSLT, XIDSQN) Tabellen- und Schemaname des betroffenen Objektes welcher Datenbank-User hat das DML/DDL ausgeführt das resultierende SQL-Statement für die betroffene Zeile (SQL_REDO) das resultierende Korrektur-SQL-Statement für die betroffene Zeile (SQL_UNDO) im Falle von DML, bei DDL oder Rollback bleibt SQL_UNDO=NULL

03.05.2010 / Seite 17 LogMiner Typischer Ablauf Einschalten von Supplemental Logging alter database add supplemental log data; Extraktion des LogMiner Dictionary EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOG); Angabe der zu analysierenden Redo Logs EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME =>'log01.log',options => DBMS_LOGMNR.NEW); OPTIONS => DBMS_LOGMNR.ADDFILE Start des LogMiners mit verschiedenen Optionen EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY); Abfrage auf v$logmnr_contents SELECT OPERATION, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'OE' AND SEG_NAME = 'ORDERS' AND OPERATION = 'DELETE' AND USERNAME = 'RON';

03.05.2010 / Seite 18 Fallbeispiele LogMiner Fallbeispiel 1: Datenverfälschung über mehrere Tage hinweg durch ein fehlerhaftes Programm: durch einen Entwicklerfehler wurden in der Tabelle KNMT über eine Woche hinweg mehrere tausend von insgesamt ca. 120.000 Sätzen verfälscht, indem alle Nicht-Schlüsselfelder, insbesondere die wichtigen Felder KDMAT und POSTX, auf leer gesetzt wurden. Fallbeispiel 2: Daten innerhalb der SAP Pool-Tabelle T030K ( Kontenfindung Steuerkonten ) wurden durch einen fehlerhaften Transport gelöscht (Anwenderfehler). Im Gegensatz zu Beispiel 1 war die Tabelle T030K jedoch nicht auf Datenbankebene angelegt, sondern im SAP Tabellenpool ATAB enthalten. Aus Datenbanksicht gab es daher nur die Tabelle ATAB, in deren Einträgen sich die Pool-Tabelle verbarg. Dies musste beim LogMining entsprechend berücksichtigt und ausgewertet werden.

03.05.2010 / Seite 19 Fallbeispiel 1: Datenrekonstruktion mit LogMiner Problem: Programm-Fehler Datenverfälschung in Tabelle KNMT über Tage hinweg (tausende Einträge von insgesamt 120.000 verfälscht) Folge: Beziehung eigene Materialnummer zu Kundenmaterialnummer verloren Bestelleingänge nicht mehr bearbeitbar (Kunde ist Händler)! Anforderung des Kunden: Rekonstruktion der Originalinhalte der verfälschten Sätze Hinweis: die falschen sind an leeren Feldern KDMAT und POSTX zu erkennen (wurden von Programm gelöscht) Lösung: das supplemental logging der DB war schon vor Fehler aktiv alle Redo Logs seit Fehler vorhanden, daher mit LogMiner auswertbar und Daten rekonstruierbar

03.05.2010 / Seite 20 Fallbeispiel 1: Datenrekonstruktion mit LogMiner Lösung im Detail: Restore der Redo Logs ab Beginn des Programm-Fehlers (hier ca. 300 Redo Logs à 140 MB) Generierung von Analyse-Skripten zur Auswertung von je 10 Logs Ergebnis-Analyse mittels shell-skript Filterung derjenigen Änderungen, bei denen SQL_REDO die KDMAT von nicht leer auf leer setzen fachliche (inhaltliche) Analyse des Resultats durch Kunden Kunde identifiziert eindeutige SQL_UNDOs, die direkt auf prod. DB angewandt werden sollen und bearbeitet Rest von nicht eindeutigen SQL_UNDOs manuell mit Standard-SAP-Mitteln Dauer der Analyse: ca. 2,5 Stunden Bereitstellung der korrigierten Daten inkl. Kundenanalyse innerhalb eines Tages Fazit: durch schleichende Datenverfälschung bei parallelem Weiter-Betrieb waren Daten sinnvoll nur durch LogMining ohne Verlust rekonstruierbar

03.05.2010 / Seite 21 Fallbeispiel 1: Datenrekonstruktion mit LogMiner orap11> cat redo_analyze_134303.sql /* Analyse von Redo Log Nr. 134303 bis 134312 */ spool redo_analyze_134303.log set echo on connect / as sysdba set lines 2000 set pagesize 9999 set timing on col SQL_REDO for a850 col SQL_UNDO for a850 Beispiel für Analyse-Skript -- auszuwertende Redo Logs definieren: execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134303.dbf', dbms_logmnr.new) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134304.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134305.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134306.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134307.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134308.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134309.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134310.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134311.dbf', dbms_logmnr.addfile) execute dbms_logmnr.add_logfile( '/oracle/p11/oraarch2/p11arch1_134312.dbf', dbms_logmnr.addfile) -- Start des LogMiners, Verwendung Online Catalog: execute dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog) -- Abfrage der relevanten SQL_Redo und SQL_UNDO Statements: select SCN, to_char(timestamp,'dd-mon-yyyy HH24:MI:SS') as TIMESTAMP, SQL_REDO, SQL_UNDO from v$logmnr_contents where SEG_NAME='KNMT'; spool off

03.05.2010 / Seite 22 Fallbeispiel 1: Datenrekonstruktion mit LogMiner Beispiel-Output: Zeile 1: Felder waren schon gelöscht Zeile 2: Beispiel für Fehler + Behebung: SQL-Redo zeigt fehlerhafte Anweisung SQL-Undo liefert Korrektur Zeile 3: Felder waren schon gelöscht

03.05.2010 / Seite 23 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Problem: Anwender-Fehler Daten in SAP Pool-Tabelle T030K ( Kontenfindung Steuerkonten ) durch Transport gelöscht Folge: Sachkonto im Produktivsystem gelöscht Anforderung des Kunden: bitte gelöschte Werte benennen Lösung: das supplemental logging der DB war schon vor Fehler aktiv Redo Logs zum Fehler vorhanden, daher mit LogMiner auswertbar im Gegensatz zu Beispiel 1 jedoch die Besonderheit, dass Tabelle T030K nicht auf DB existiert, sondern in SAP Tabellenpool ATAB

03.05.2010 / Seite 24 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Lösung im Detail: Ermittlung des Tabellenpools zu T030K ATAB Ermittlung Fehlerzeitraum anhand SAP-Transportlog (Start+Ende) Ermittlung und Restore der Redo Logs dieses Zeitraums (wenige Minuten) LogMining prinzipiell analog Fall 1 gesucht werden Änderungen an ATAB für TABNAME= T030K, Beispiel: select SCN, to_char(timestamp,'dd-mon-yyyy HH24:MI:SS') as TIMESTAMP, SQL_UNDO from v$logmnr_contents where SEG_NAME='ATAB' and SQL_UNDO like '%T030K%'; SCN TIMESTAMP ---------- -------------------------- SQL_UNDO ---------------------------------------------------------------- 220517473 29-SEP-2008 16:13:50 insert into "SAPDAT"."ATAB"("TABNAME","VARKEY","DATALN","VARDATA") values ('T030K','110PYINVSTD9','40',HEXTORAW '0028003000300030003000310035003400360036003000300030003000300031003500340 03600360030'));

03.05.2010 / Seite 25 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Lösung im Detail: (Fortsetzung) Interpretation des SQL_UNDO zur Ermittlung des vorherigen Wertes: insert into "SAPDAT"."ATAB"("TABNAME","VARKEY","DATALN","VARDATA") values ('T030K','110PYINVSTD9','40',HEXTORAW '0028003000300030003000310035003400360036003000300030003000300031003500340 03600360030')); VARKEY = '110PYINVSTD9' = MANDT(3)+KTOPL(4)+KTOSL(3)+MWSKZ(2) gemäß SAP-Tabellendefinition also: MANDT=110 KTOPL=PYIN KTOSL=VST MWSKZ=D9 VARDATA = KONTS(10)+KONTH(10) gemäß SAP-Tabellendefinition, hier in HEX HEX-Darstellung der Werte in VARDATA wird in ASCII übersetzt: (hier immer 2 Byte für 1 Zeichen, da Unicode-System): 0028: erstes double byte gibt String-Länge an, hier: dezimal 40 (bytes); 0030 0030 0030 0030 0031 0035 0034 0036 0036 0030 HEX KONTS 0 0 0 0 1 5 4 6 6 0 ASCII KONTS 0030 0030 0030 0030 0031 0035 0034 0036 0036 0030 HEX KONTH 0 0 0 0 1 5 4 6 6 0 ASCII KONTH

03.05.2010 / Seite 26 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Lösung im Detail: (Fortsetzung) Zusammenfassung des SQL_UNDOS aus SAP-Sicht: insert in "T030K" mit key: MANDT=110 KTOPL=PYIN KTOSL=VST MWSKZ=D9 values: KONTS=0000154660 KONTH=0000154660 Kunde pflegt Daten mit Standard-SAP-Mitteln wieder in System ein Fazit: bei Kenntnis des SAP Datenmodells auch komplexere Strukturen mit LogMiner analysierbar

03.05.2010 / Seite 27 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Eigenschaften der SAP-Tabelle T030K (se11): auf DB existiert nicht Tabelle T030K, sondern nur Tabellen- Pool ATAB: SQL> desc sapdat.t030k ERROR: ORA-04043: object sapdat.t030k does not exist SQL> desc sapdat.atab Name Null? Type ----------------------------------------- -------- ---------------------------- TABNAME NOT NULL VARCHAR2(30) VARKEY NOT NULL VARCHAR2(150) DATALN NOT NULL NUMBER(5) VARDATA LONG RAW

03.05.2010 / Seite 28 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner SAP Pool-Tabelle allgemein (siehe SAP Doku): Speicherung der Pooltabelleninhalte in Tabellenpool (=Datenbanktabelle): 1. Name der Tabelle in TABNAME 2. Schlüsselfelder (Key) als String in VARKEY 3. Datenfelder als String in VARDATA 4. DATALN gibt die Länge des Datenfeld-Strings (in VARDATA) an Quelle der Grafik: http://help.sap.com/saphelp_45b/helpdata/de/cf/21f083446011d189700000e8322d00/content.htm

03.05.2010 / Seite 29 Fallbeispiel 2: SAP Pool-Tabelle Datenrekonstruktion mit LogMiner Eigenschaften der SAP-Tabelle T030K (se11): (Fortsetzung) Struktur der T030K: Schlüsselfelder: MANDT, KTOPL, KTOSL, MWSKZ Werte: KONTS, KONTH in ATAB: VARKEY VARDATA

03.05.2010 / Seite 31 Flashback-Technologien (1) Flashback Query (seit Oracle 9i) Erlaubt die Abfrage von Tabelleninhalten zu einem Zeitpunkt in der Vergangenheit SELECT * FROM employee AS OF TIMESTAMP TO_TIMESTAMP('19-APR- 05 02:00:00 PM') WHERE Flashback Versions Query Anzeige aller Änderungen an einem Datensatz seit einem bestimmten Punkt in der (nahen) Vergangenheit bis zum aktuellen Datum SELECT * FROM employee VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('19-APR-09 02:00:00 PM') AND TIMESTAMP TO_TIMESTAMP('20-APR-09 03:00:00 PM') WHERE Flashback Transaction Query Anzeige aller durch eine Transaktion veränderten Datensätze und gibt auch Informationen über ein eventuell notwendiges UNDO-Statement. SELECT * FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = '000200030000002D';

03.05.2010 / Seite 32 Flashback-Technologien (2) Flashback Transaction Eine abgeschlossene Transaktion und ggf. davon abhängige Transaktionen können gezielt zurückgerollt werden. Verwendung mit PL/SQL Prozedur DBMS_FLASHBACK.TRANSACTION_BACKOUT() Flashback Table Eine Tabelle auf einen Stand in der Vergangenheit zurücksetzen FLASHBACK TABLE orders, order_items TIMESTAMP TO TIMESTAMP('07-APR-2009 02:33:00 PM'); Flashback Drop Ab Oracle 10g werden gelöschte Tabellen in den Recyle Bin verschoben. Wiederherstellung mit FLASHBACK TABLE employee TO BEFORE DROP; Flashback Database Zurücksetzen der gesamten Datenbank auf eine Zeitpunkt in der Vergangenheit FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP('19-APR-05 02:05:00 PM');

03.05.2010 / Seite 33 Flashback Technologien Flashback Query Flashback Tables Flashback Database Flashback Data Archive and Transaction

03.05.2010 / Seite 34 Fallbeispiel Flashback-Technologien Fallbeispiel: Durch einen Anwenderfehler wurden veraltete Stände der Tabellen CEPC und CEPCT ( Profit-Center-Stammdaten ) vom Entwicklungssystem in das Produktivsystem transportiert. Fehlerhafte Änderungen lagen 20 Stunden zurück

03.05.2010 / Seite 35 Fallbeispiel: Datenrekonstruktion mit Flashback Query Problem: Anwender-Fehler veraltete Stände von CEPC und CEPCT ( Profit-Center-Stammdaten ) ins PRD-System transportiert Folge: Erfassung neuer Kundensätze nicht mehr möglich Anforderung des Kunden: Original-Stände der produktiven Tabellen im DEV-System bereitstellen Lösung: before images der Tabellen noch in Undo-Tablespace vorhanden, obwohl Fehler schon 20 Stunden früher (Tablespace groß) Flashback Query und Sicherung der rekonstruierten Original-Daten

03.05.2010 / Seite 36 Fallbeispiel: Datenrekonstruktion mit Flashback Query Lösung im Detail: PRD: Fehlerzeitpunkt aus SAP-Transportlog bestimmen; Ergebnis: 25.06.2009-22:04:22 PRD: Versuch, Daten von früherem Stand in neue Tabelle zu kopieren: SQL> create table sapdat.cepc_2009_06_25_22_04_00 as (select * from sapdat.cepc as of timestamp to_timestamp('2009-06-25:22:04:00','yyyy-mm-dd:hh24:mi:ss')); Table created. Daten also wirklich noch vorhanden (ebenso CEPCT)! PRD: Export der Daten: oraprd> exp sapdat/<pwd> file=exp_cepc_restore.dmp log=exp_cepc_restore.log tables=$cepc_2009_06_25_22_04_00,cepct_2009_06_25_22_04_00$ DEV: Import imp sapdat/<pwd> file=exp_cepc_restore.dmp full=y DEV: Anlegen der Tabellen im ABAP-Dictionary für SAP-Zugriff

03.05.2010 / Seite 37 Fallbeispiel: Datenrekonstruktion mit Flashback Query Lösung im Detail: (Fortsetzung) DEV: Umbenennung der Tabellen nach SAP-Konventionen DEV/PRD: normaler SAP-Transport der korrekten Daten nach Prüfung durch Kunde Dauer der Datenwiederherstellung: inkl. Analyse ca. 1 Stunde Fazit: andere Verfahren wären bei dieser 2 TB Datenbank erheblich aufwendiger gewesen

03.05.2010 / Seite 39 Was ist Oracle Data Guard? Seit Oracle 9i neuer Name für Standby Datenbank Oracle s Disaster Recovery Lösung für Oracle DBs Feature der Oracle Database Enterprise Edition Automatisiert das Anlegen und den Betrieb einer oder mehrerer transaktionskonsistenter Kopien (Standby-DBs) der Produktiv-Instanz (Primary) Wenn die Produktiv-Instanz ausfällt, kann eine Standby-Datenbank aktiviert werden und die Rolle der Produktiv-Datenbank übernehmen (auch automatisierbar)

03.05.2010 / Seite 40 Oracle Data Guard Architektur

03.05.2010 / Seite 41 Oracle Data Guard Architektur Transactions Oracle Net Physical/Logical Standby Database LGWR RFS MRP/ LSP Online Redo Logs Primary Database ARCH FAL Standby Redo Logs Transform Redo to SQL for SQL Apply Backup / Reports ARCH Archived Redo Logs Archived Redo Logs

03.05.2010 / Seite 42 DIGITAL DATA STORAGE Oracle Data Guard Physical Standby Database (REDO Apply) Clients Clients Primary Site Physical Standby Backup LAN/WAN Redo Logs Blockweise identische Kopie der Primary Im Recovery und/oder Read-Only geöffnet Entlastung der Primary bei Backups Ab Oracle 11g Active Data Guard möglich Apply durch Recovery der Logs Redo Apply

03.05.2010 / Seite 43 Oracle Data Guard Logical Standby Database (SQL Apply) Clients Primary Site Gleichzeitig Apply und geöffnet! LAN/WAN Gleiche Inhalte logische Kopie Struktur kann sich von Primary unterscheiden Zusätzliche Indixes/MVs möglich Kann zusätzliche Objekte enthalten Apply durch LogMining der Redo Logs SQL-Apply Redo Logs Logical Standby

03.05.2010 / Seite 44 Oracle Data Guard Administration 3 Möglichkeiten zur Administration Pures SQL DataGuard Broker und DGMGRL DataGuard Broker und EM GridControl

03.05.2010 / Seite 45 Oracle Data Guard Welche Standby für welchen Zweck? Physical Standby DR-Lösung mit HA-Funktionalitäten Reporting-Möglichkeit Verschiedene Protection Modi möglich Blockweise identische Kopie der Primär-DB Logical Standby Real-Time-Reporting mit Real Time Apply zusätzliche Indizes und MAVs möglich Logische Kopie der Primär-DB Vorschlag: Physical Standby für Failover/DR, Readonly Reporting, Applikations-Test, Logical Standby für Reporting, Upgrades, Tests,

03.05.2010 / Seite 46 Fallbeispiele Data Guard (DG) Fallbeispiel 1: Durch einen Benutzer-Fehler wurden aus drei kundeneigenen Tabellen (Y*) jeweils mehrere Millionen Datensätze gelöscht. Ein kompletter Geschäftsbereich des Kunden konnte keine Auftragsverarbeitung mehr durchführen, somit war das Geschäft des Kunden (Händler) zu einem beträchtlichen Teil lahmgelegt. Nutzung von Physical Standby mit Delayed Apply Fallbeispiel 2: Korruption eines Datenfiles durch Hardware-Fehler Teile einer Kundenanwendung im SAP-System waren nicht mehr funktionsfähig, da wegen der physikalischen Korruption des Datenfiles eine Kundentabelle nicht mehr lesbar war. Reparatur des korrupten Datenfiles mittels Standby Datenbank (Data Guard) Fallbeispiel 3: Durch einen Admin-Fehler wurde bei einem SAP-Releasewechsel ein Report zur Sicherung von Statistik-Daten (MONI/st03n) des alten Releases nicht ausgeführt, wodurch diese im neuen Release nicht mehr zu Verfügung standen. Nutzung der vor dem Releasewechsel abgekoppelten Physical Standby, um dort den Report noch nachträglich auszuführen und die Daten verfügbar zu machen.

03.05.2010 / Seite 47 Fallbeispiel 1: Datenrekonstruktion mit DG Delayed Apply Problem: Benutzer-Fehler aus drei Y*-Tabellen mehrere Mio Datensätze gelöscht! Folge: keine Auftragsverarbeitung mehr in gesamten Geschäftsbereich großer Teil des Geschäfts lahmgelegt (Kunde ist Händler)! Anforderung des Kunden: Bereitstellung der betroffenen Y*-Tabellendaten auf Stand vor 3 Stunden im QA-System Zurücksetzen auf Prod. nicht möglich wegen Abhängigkeiten und noch intakter/genutzter Datenbereiche der Tabellen Lösung: Data Guard im Einsatz, Zeitversatz 4 h auf Standby Seite gelöschte Daten auf Standby Seite noch vorhanden Extraktion der Daten von Standby möglich

03.05.2010 / Seite 48 Fallbeispiel 1: Datenrekonstruktion mit DG Delayed Apply Lösung im Detail: Standby: Managed Recovery stoppen SQL> recover managed standby database cancel; Standby: Vorfahren auf Zeit vor Fehler (Kundenvorgabe) SQL> recover standby database UNTIL TIME '2008-03-06:15:20:00'; Standby: read-only öffnen SQL> alter database open; alert.log: Physical standby database opened for read only access. Standby: Export der Tabellen oraprd> exp sapdat/<passwd> file=export_yint0101.dmp log=yint0101.log tables=yint0101 indexes=no direct=yes... Standby/QA-System: Übertragen der Exportdaten: scp... QA-System: Stand der QA-Tabellen sichern SQL> create table YINT0101_backup as select * from YINT0101;... QA-System: SAP stoppen

03.05.2010 / Seite 49 Fallbeispiel 1: Datenrekonstruktion mit DG Delayed Apply Lösung im Detail: (Fortsetzung) QA-System: QA-Tabellen umbenennen SQL> alter table YINT0103 rename to YINT0103_orig; QA-System: menügeführter Import der obigen Exporte: imp... QA-System: SAP starten QA-System: Freigabe an Kunden zur Datenprüfung/Exktraktion aus QA- System mit Standard SAP-Methoden (!) Standby: Managed Recovery nach Kundenfreigabe fortsetzen SQL> alter database recover managed standby database disconnect from session; QA-System: nach Abschluß der Datenextrakte und Kundenfreigabe: Löschen (drop) der importierten Tabellen + zurück-benennen (rename) der..._orig Primary (Prod.): Daten-Import durch Kunden mit Standard SAP-Methoden (!) Dauer aller genannten Aktionen: inklusive Abstimmungen mit dem Kunden ca. eine Stunde

03.05.2010 / Seite 50 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Problem: Korruption eines Datenfiles auf Primary durch Hardware-Fehler Folge: Teile einer Kundenapplikation in SAP nicht mehr funktionsfähig, da wegen physikalischer Korruption eines Datenfiles Tabelle unlesbar Anforderung des Kunden: schnellstmögliche Reparatur mit geringstmöglicher Störung des Produktivbetriebs Lösung: Data Guard im Einsatz, Zeitversatz 4 h auf Standby Seite Hardware-Fehler betraf nur Primary, daher File auf Standby noch intakt und konnte File auf Primary ersetzen

03.05.2010 / Seite 51 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Lösung im Detail: (hier: Oracle 9i) Standby: Zeitversatz deaktivieren und so alle Redo Logs applizieren DGMGRL> alter resource 'PRD_stdby_site_A_PRD' set property 'ApplyNoDelay'=YES; Parallel dazu Prüfung des betroffenen Datenfiles auf Primary und Standby: Primary: Verifizierung des Defektes, den die Applikation beim Tabellenzugriff gemeldet hat Standby: Prüfung des Files zur Verifizierung, dass dort intakt

03.05.2010 / Seite 52 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Verifizierung des Defektes auf Primary: prima:oraprd 1> dbv FILE=/oracle/PRD/sapdata12/prdybm01d_3/prdybm01d.data3 BLOCKSIZE=8192 DBVERIFY: Release 9.2.0.7.0 - Production on Thu Jan 10 21:33:57 2008 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. DBVERIFY - Verification starting : FILE = /oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3 Page 17302 is influx - most likely media corrupt *** Corrupt block relative dba: 0x21004396 (file 132, block 17302) Fractured block found during dbv: Data in bad block - type: 6 format: 2 rdba: 0x21004396 last change scn: 0x0002.e6625842 seq: 0x1 flg: 0x06 consistency value in tail: 0x5ebd0601 check value in block header: 0x3353, computed block checksum: 0x7f9 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** DBVERIFY - Verification complete Total Pages Examined : 76800 Total Pages Processed (Data) : 75617 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 934 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 248 Total Pages Marked Corrupt : 1 Total Pages Influx : 1 Highest block SCN : 12466041301 (2.3876106709) Korruption gefunden, wie von Applikation gemeldet

03.05.2010 / Seite 53 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Prüfung des gleichen Files auf Standby: stdby:oraprd 1> dbv FILE=/oracle/PRD/sapdata12/prdybm01d_3/prdybm01d.data3 BLOCKSIZE=8192 DBVERIFY: Release 9.2.0.7.0 - Production on Thu Jan 10 21:47:24 2008 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. DBVERIFY - Verification starting : FILE = /oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3 DBVERIFY - Verification complete Total Pages Examined : 76800 Total Pages Processed (Data) : 75618 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 934 also keine Korruption, Total Pages Processed (Seg) : 0 File intakt Total Pages Failing (Seg) : 0 Total Pages Empty : 248 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Highest block SCN : 12465638558 (2.3875703966)

03.05.2010 / Seite 54 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Lösung im Detail: (Fortsetzung) Primary: korruptes Datenfile offline setzen (betroffene Applikation ist schon durch Kunde gestoppt) SQL> alter database datafile '/oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3' offline; Standby: Datenbank stoppen (nachdem Zeitversatz aufgeholt ) SQL> shutdown immediate; Primary: korruptes File durch intaktes von Standby ersetzen prima:/oracle/prd/sapdata12/prdybm01d_3> rcp -p stdby:/oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3. Standby: Instanz wieder starten (mount + managed Recovery durch DG) SQL> startup nomount; Primary: Datenfile recovern, um auf aktuellen Stand zu bringen SQL> recover datafile '/oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3'; Primary: Datenfile wieder online setzen SQL> alter database datafile '/oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3' online;

03.05.2010 / Seite 55 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Lösung im Detail: (Fortsetzung) Primary: Verifizierung, dass File jetzt wieder intakt Standby: Zeitversatz wieder einschalten DGMGRL> alter resource 'PRD_stdby_site_A_PRD' set property 'ApplyNoDelay'=NO; Dauer der Reparatur: ca. 1 Stunde (inkl. Analysen)

03.05.2010 / Seite 56 Fallbeispiel 2: Datenfile-Reparatur mittels Data Guard Prüfung des Files auf Primary nach Reparatur : prima:oraprd 2> dbv FILE=/oracle/PRD/sapdata12/prdybm01d_3/prdybm01d.data3 BLOCKSIZE=8192 DBVERIFY: Release 9.2.0.7.0 - Production on Thu Jan 10 22:16:06 2008 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. DBVERIFY - Verification starting : FILE = /oracle/prd/sapdata12/prdybm01d_3/prdybm01d.data3 DBVERIFY - Verification complete Total Pages Examined : 76800 Total Pages Processed (Data) : 75618 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 934 also keine Korruption mehr, Total Pages Processed (Seg) : 0 File wieder intakt Total Pages Failing (Seg) : 0 Total Pages Empty : 248 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Highest block SCN : 12467019967 (2.3877085375)

03.05.2010 / Seite 57 Fallbeispiel 3: Datenrettung durch Aktivierung der Standby Problem: Admin-Fehler (Report nicht ausgeführt) in Releasewechsel gingen Statistik-Daten verloren (MONI/st03n) Folge: Nachweis der Einhaltung von SLAs auf Antwortzeiten nicht mehr möglich Kunde unglücklich legt hohen Wert auf diese Statistiken Anforderung des Kunden: Statistik-Daten des Alt-Releases wieder herstellen und im bereits wieder produktiven Release-gewechselten System bereitstellen nicht gestarteter Report kann nur in Alt-Release laufen Lösung: Data Guard vor Releasewechsel im Einsatz, Standby Seite zu Beginn Downtime gestoppt auf Standby Seite SAP in Alt-Release starten und Report ausführen Extraktion der Daten von Standby möglich

03.05.2010 / Seite 58 Fallbeispiel 3: Datenrettung durch Aktivierung der Standby Ausgangssituation: DG im Einsatz Standby DB lief bis zum Beginn der Downtime des SAP Releasewechsels (4.6C ECC6) synchron mit Standby wurde dann gestoppt (für Fallback -Szenario), Releasewechsel auf Primärseite normal durchgeführt Lösung im Detail: (Skizze) Zur Sicherheit, damit kein Connect zur (produktiven!) Primary stattfindet: Isolierung der Standby Seite; hier: DG Broker deaktivieren Löschen der DG Konfiguration Löschen der DB-Parameter/TNS-Einträge zur Primary (spfile, tnsnames.ora)

03.05.2010 / Seite 59 Fallbeispiel 3: Datenrettung durch Aktivierung der Standby Lösung im Detail: (Fortsetzung) manuelle Aktivierung der Standby: (lt. Oracle Doku müßte bei failover mit DG Broker die Primary unten sein) SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; SQL> ALTER DATABASE OPEN; Parameter der vorkonfigurierten SAP-Instanz auf Standby prüfen/anpassen Batch-Prozesse auskommentieren (damit zunächst kein Job laufen kann!) SAP-Start + Anmeldung als DDIC (wg. locksys durch Upgrade!) Prüfung: alle Jobs durch Upgrade suspendiert, also System wieder mit Batch starten Transport-Auftrag für benötigten Statistik-Report importieren (mit Tricks: Transportwesen dieser Standby anpassen, Umgehung der Upgrade-Transportsperre etc.)

03.05.2010 / Seite 60 Fallbeispiel 3: Datenrettung durch Aktivierung der Standby Lösung im Detail: (Fortsetzung) Report zur Rettung der Statistiken ausführen klappt rsmigr12 kopiert MONI-Daten in ZWNCMOMIGR Export (SAP-Transport) der ZWNCMOMIGR zwecks Datenübertragung zur Primary (wieder mit Tricks, da DDIC eigentlich nicht exportieren darf,...) normaler Import auf Primary und dort restliche Verarbeitung im Neu-Release gemäß Leitfaden Dauer der Aktionen: wenige Stunden (inkl. workaround Tricks )

03.05.2010 / Seite 62 Zusammenfassung Die Oracle Datenbank bietet zahlreiche Funktionen für Hochverfügbarkeit und Datensicherheit. Architektonisch konzeptionelle Features wie Real Application Cluster oder Oracle Data Guard Built-In Features wie z.b. der LogMiner oder die Flashback Technologien Dank dieser teilweise im Markt einzigartigen Funktionalitäten war es der Freudenberg IT möglich, in den gehosteten SAP-Umgebungen, wie in den gezeigten Fallbeispielen erläutert, auf die unterschiedlichsten Fehlersituationen flexibel reagieren und eine zügige Wiederverfügbarkeit einer SAP-Applikation gewährleisten zu können. Dabei war es unerheblich, ob es sich um durch einen Hardware-Defekt verursachte physikalische Korruptionen oder um eine durch einen Benutzerprogrammfehler verursachte logische Korruption handelte.

03.05.2010 / Seite 63 VIELEN DANK FÜR IHRE AUFMERKSAMKEIT! Ihr persönlicher Ansprechpartner: Freudenberg IT Dr. Thimo Bastuck Team SAP Telefon: +49 (0) 6201 80 8000 Mail: thimo.bastuck@freudenberg-it.com Weitere Informationen erhalten Sie unter: Freudenberg IT / www.freudenberg-it.com / info@freudenberg-it.com Copyright 2010 Freudenberg IT (FIT). All other trademarks are registered property of the respective manufacturers. Subject to change and errors.