=====Datenbank SCN Problem - "data block SCN is ahead of the current SCN" ===== Folgender Fehler tritt nach dem Neustart einer DB Instance auf, kurz bevor die Datenbank aufgeht: alter database open resetlogs; alter database open resetlogs * FEHLER in Zeile 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2663], [0], [343435698030], [0], [343435698038], [], [], [], [], [], [], [] Prozess-ID: 824 Session-ID: 9 Seriennummer: 3 Hintergrund: Nach einem Stromausfall einer VM Maschine konnte die DB nicht mehr gestartet werden, Online Redo Logs scheinen defekt zu sein. Vollständige Sicherung der defekten Datenbank anfertigen um bei einem Fehler wieder von vorne anfangen zu können! Die Datenbank ist noch eine 11.2.0.1, dbverify in dieser Version zeigt keine defekten Blöcke in den Datendateien bei den folgenden Fehler an! Um die defekten Online Redo Logs zu reparieren: * Parameter "_allow_resetlogs_corruption"=TRUE gesetzt * Controlfile trace angelegt mit "alter database backup controlfile to trace 'd:\temp\gpidb_ctl.trace'" * Controlfile mit Hilfe der SQL Befehle im Traces neu angelegt * SCN in den Header Dateien ermitteln mit select status,checkpoint_change#,checkpoint_time, resetlogs_change#,resetlogs_time,fuzzy from v$datafile_header; * Datenbank mit ALTER DATABASE RECOVER UNTIL CHANGE USING BACKUP CONTROLFILE; recovert, Fehlermeldung mit "ORA-01194: file 1 needs more recovery to be consistent" ignorieren * Datenbank mit alter database open resetlogs öffnen * DB stürzt nun fast bevor die DB aufzugehen scheint mit "ORA-00600: internal error code, arguments: [2663], [0], [343435698030]" ab Im Alert Log Fehler: ORA-00600: Interner Fehlercode, Argumente: [2663], [0], [343435698030], [0], [343435698038], [], [], [], [], [], [], [] Die Zahlen in den eckigen Klammern nach dem Fehler [2663] weisen auf die SCN's hin, die hier schief liegen! ORA-600 [2663] [a] [b] [c] [d] [] ARGUMENTS: * Arg [a] Current SCN WRAP * Arg [b] Current SCN BASE * Arg [c] dependent SCN WRAP * Arg [d] dependent SCN BASE **Ursache**: SCN in den Datendateien bzw einen Datenblock ist höher als die Currrent SCN im File Header der Datendatei **Lösung A**: **Falls Wartungsvertrag: Oracle Support einschalten!** Siehe zuvor die Node unter Quellen Mit einer höheren Version von DBVerify die Datenbank prüfen, hier sollte der Fehler erkannt werden! als highest scn die SCN aus der Abfrage des File Headers angeben dbv file=SYSTEM01.dbf HIGH_SCN=343435698030 ... Page 1905 SCN 3434355648030 exceeds highest scn to check 343435698030 .... **Lösung B**: Datenbank mehrfach öffnen, die SCN zählt sich hoch und passt dann evtl.wieder zu der SCN die notwendig wäre damit das wieder passt. Mit viel Glück geht das dann noch auf.... Sollte die DB doch mal wieder aufgehen => Sofort einen Full Export mit Datapump durchführen! (siehe [[dba:datapump_import|Oracle Data Pump Schema Export und Import]]) **Weitere Lösungen** Siehe noch mehr Informationen dazu unter => http://www.anbob.com/archives/2098.html ==== Quellen ==== Siehe diesen Hinweis im Support Portal: Ab der Version 11.2.0.2, 11.2.0.3, 11.2.0.4 and 12c ist der Fix in der DB schon enthalten, muss aber aktiviert werden, siehe Parameter dazu in folgender Node: * ALERT Description and fix for Bug 8895202: ORA-1555 / ORA-600 [ktbdchk1: bad dscn] ORA-600 [2663] in Physical Standby after switchover (Doc ID 1608167.1) Hier ein sehr altes Dokument mit Informationen zu dem Thema =>http://edu.fors.ru/velpuri2/Backup%20and%20Recovery/scnDEREASED ==== Der ORA-600 Stack Trace dazu ==== ORA-00600: Interner Fehlercode, Argumente: [2663], [0], [343435698030], [0], [343435698038], [], [], [], [], [], [], [] ** DBGRL Error: ARB Alert Log ** DBGRL Error: SLERC_OERC, 48180 ** DBGRL Error: OSD-00001: Zusätzliche Fehlerinformation O/S-Error: (OS 1392) Die Datei oder das Verzeichnis ist beschädigt und nicht lesbar. ..... ========= Dump for incident 308799 (ORA 600 [2663]) ======== dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ..... ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- _skdstdst()+121 CALLrel _kgdsdst() D7ADAEC 2 _ksedst1()+93 CALLrel _skdstdst() D7ADAEC 0 1 436646 435BE2 436646 _ksedst()+49 CALLrel _ksedst1() 0 1 _dbkedDefDump()+367 CALLrel _ksedst() 0 2 _ksedmp()+44 CALLrel _dbkedDefDump() 3 2 _ksfdmp()+56 CALLrel _ksedmp() 3EB ...