Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dba:oracle_ora_600_2663_2662 [2016/01/27 23:43] – [Datenbank SCN Problem - data block SCN is ahead of the current SCN] gpipperr
+++ dba:oracle_ora_600_2663_2662 [2016/01/28 00:10] – gpipperr
@@ Zeile 1: / Zeile 1: @@
 =====Datenbank SCN Problem - "data block SCN is ahead of the current SCN" =====
-Folgender Fehler tritt nach dem Neustart einer DB Instance kurz bevor die Datenbank aufgeht auf:
+Folgender Fehler tritt nach dem Neustart einer DB Instance auf,  kurz bevor die Datenbank aufgeht:
 <code sql>
@@ Zeile 18: / Zeile 18: @@
 </code>
-Hintergrund: Nach einem Stromausfall einer VM Maschine konnte die DB nicht mehr gestartet werden, Online Redo Logs scheinen defekt zu sein.
+Hintergrund:
+Nach einem Stromausfall einer VM Maschine konnte die DB nicht mehr gestartet werden, Online Redo Logs scheinen defekt zu sein.
 <note warning>Vollständige Sicherung der defekten Datenbank anfertigen um bei einem Fehler wieder von vorne anfangen zu können!</note>
-Die Datenbank ist noch eine 11.2.0.1, dbverify in dieser Version keine defekten Blöcke in den Datendateien an!
+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 current controlfile as "d:\temp\gpidb_ctl.trace"
+  * 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 <code sql>
@@ Zeile 50: / Zeile 54: @@
-**Ursache**: SCN in den Datendateien bzw einen Datenblock ist höher als die Currrent SCN im File header der Datendatei
+**Ursache**: SCN in den Datendateien bzw einen Datenblock ist höher als die Currrent SCN im File Header der Datendatei
-**Lösung**:
+**Lösung A**:
 <fc #800000>**Falls Wartungsvertrag:  Oracle Support einschalten!**</fc>
@@ Zeile 59: / Zeile 63: @@
 Siehe zuvor die Node unter Quellen
+Mit einer höheren Version von DBVerify die Datenbank prüfen, hier sollte der Fehler erkannt werden!
-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....
+**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]])
-Siehe noch mehr Informationen dazu  unter =>  http://www.anbob.com/archives/2098.html
+**Weitere Lösungen**
+Siehe noch mehr Informationen dazu unter =>  http://www.anbob.com/archives/2098.html
@@ Zeile 80: / Zeile 87: @@
-==== Stack Trace ====
+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 ====
 <code>
 ORA-00600: Interner Fehlercode, Argumente: [2663], [0], [343435698030], [0], [343435698038], [], [], [], [], [], [], []
@@ Zeile 97: / Zeile 109: @@
 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
+.....
 ----- Call Stack Trace -----
@@ Zeile 110: / Zeile 123: @@
 _ksedmp()+44         CALLrel  _dbkedDefDump()      3 2
 _ksfdmp()+56         CALLrel  _ksedmp()            3EB
+...
 </code>