====== Online Redo Logs fehlen ======

Gehen alle Redo Logdateien (bzw. alle Mitglieder der Redo-Gruppen) einer Datenbank verloren, gehen auch die Daten der letzten Transaktionen verloren. Daher sollten die Dateien auf zwei verschiedenen Devices gespiegelt werden (wenn es von der Hardware her Sinn macht).
\\
Die Redolog Gruppen sind nicht immer alle in Verwendung, die DB arbeitet nur mit der aktiven Redolog Gruppe. Ist diese gefüllt, wird mit einem Logswitch auf die nächste Gruppe gewechselt und die vorherige Gruppe wird vom Archive als archiviertes Redolog gesichert.\\

Solange noch je ein Member dieser Gruppen existiert, entstehen keine Probleme, die DB läuft.\\

<note important>Achtung!\\
Regelmäßig Alert-Log prüfen, ob eine Member fehlt oder defekt ist!
</note>

===== 1) Mitglied einer Redo-Log Gruppe geht verloren =====

Geht nur eine Datei einer Gruppe verloren, ist dies kein größeres Problem.
<code plsql>
--DB ist noch geöffnet, Fehler suchen
sql>select group#,status,member from v$logfile;

  GROUP# STATUS     MEMBER
-------- ---------- ----------------------------------------
       4            D:\ORADATA\GPI\REDOLOG1\LOG4.ORA
       4            D:\ORADATA\GPI\REDOLOG2\LOG4.ORA
       3 INVALID    D:\ORADATA\GPI\REDOLOG2\LOG3.ORA
       3            D:\ORADATA\GPI\REDOLOG1\LOG3.ORA
--- Defekte Datei löschen
sql>alter database drop logfile member 'D:\ORADATA\GPI\REDOLOG2\LOG3.ORA';
Database altered.
--- Meue Member anlegen
sql>alter database add logfile member 'D:\ORADATA\GPI\REDOLOG2\LOG3.ORA' reuse to group 3;
Database altered.
</code>

===== 2) Verlust der inaktiven Redo-Log Gruppe Status INACTIVE in der v$log ===== 


Diese Gruppe wird gerade nicht für das Instance Recovery benötigt, der Archive hat die Gruppe bereits gesichert und die DB schreibt gerade nicht aktiv auf der Gruppe.
Ablauf:
<code plsql>
--Fehler suchen
sql>select group#,status,member from v$logfile;

  GROUP# STATUS     MEMBER
-------- ---------- ----------------------------------------
       4            D:\ORADATA\GPI\REDOLOG1\LOG4.ORA
       4            D:\ORADATA\GPI\REDOLOG2\LOG4.ORA
       3 INVALID    D:\ORADATA\GPI\REDOLOG2\LOG3.ORA
       3 INVALID    D:\ORADATA\GPI\REDOLOG1\LOG3.ORA

--Ursache beseitigen, (Platte defekt usw.)
--Alter Database clear Logfile 
sql>alter database clear logfile group 3;
Database altered.
</code>

Falls DB geschlossen ist, mit mount öffnen und Log Dateien mit Clear logfile neu initialisieren und DB öffnen.

===== 3) Verlust der aktiven Redo-Log Gruppe - Status AKTIVE in der v$log ===== 

AKTIVE bedeutet, die Redolog Gruppe enthält noch Daten, die die DB bei einem Instance Recovery benötigen würde.\\

Ablauf:
  * DB noch geöffnet
  * Ursache beseitigen

**Auf nächste Gruppe wechseln**\\
Nur Möglich wenn die nächste Gruppe noch vorhanden ist\\

<code plsql>
Alter database switch logfile;
</code>

Falls dies nicht funktioniert  -> Weiter wie bei Verlust inaktiver Gruppe Punkt 2 => [[dba:rac_internals#verlust_der_inaktiven_redo-log_gruppe_status_inactive_in_der_v_log|Punkt 2]]




===== 4. Verlust der current Redo-Log Gruppe - Status CURRENT in der v$log ===== 
CURRENT bedeutet, die DB versucht gerade in dieser Datei zu schreiben.

Ablauf:
  * DB stürzt ab
  * Ursache beseitigen
  * Unvollständiges Recovery der DB durchführen (until cancel)
  * Öffnen der Datenbank mit Reset Logs

siehe Punkt 5

===== 5. Verlust aller Redo Logdateien ===== 
Gehen alle Redo-Log Dateien verloren, muss die DB mit until cancel wiederhergestellt werden.

Ablauf:
  * DB stürzt ab
  * Ursache beseitigen
  * Unvollständiges Recovery der DB durchführen (until cancel)
  * Öffnen der Datenbank mit Reset Logs

Alert_log Eintrag:
<code>
Sun Aug 27 12:02:23 2006
Errors in file d:\oracle\admin\<MYSID>\bdump\<MYSID>_lgwr_3856.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\<MYSID>\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: Datei kann nicht geöffnet werden
O/S-Error: (OS 2) Das System kann die angegebene Datei nicht finden.
</code>

DB komplett stoppen und nur den Service neu starten:
<code winbatch>
cmd>oradim -shutdown -sid <MYSID> -SHUTMODE a
cmd>oradim -edit -sid <MYSID> -startmode m
cmd>oradim -startup -sid <MYSID> -starttype srvc
</code>

Letzte SEQUNCE nur eines Archivlogs bestimmen

<code plsql>
SQL> select max(SEQUENCE#) from v$archived_log;

MAX(SEQUENCE#)
--------------
            85
RMAN:
RMAN> connect target /
</code>

mit Zieldatenbank verbunden (nicht gestartet)

<code plsql>
RMAN> startup mount
Oracle-Instance gestartet
Datenbank angeschlossen
Gesamte System Global Area     294723488 Byte
Fixed Size                      454560 Byte
Variable Size                167772160 Byte
Database Buffers             125829120 Byte
Redo Buffers                    667648 Byte
RMAN> recover database until sequence 85 thread 0;

Starten recover um 27.08.06
Kontrolldatei der Zieldatenbank wird anstelle des Recovery-Katalogs verwendet
Zugewiesener Kanal: ORA_DISK_1
Kanal ORA_DISK_1: SID=12 Gerõtetyp=DISK

Starte Wiederherstellung des Datentrõgers
Wiederherstellung des Datentrõgers beendet

Beendet recover um 27.08.06
RMAN> sql "alter database open resetlogs";

SQL-Anweisung: alter database open resetlogs


Neu am RMAN anmelden und DB sichern!

RMAN> connect target /

Mit Ziel-Datenbank verbunden: <MYSID> (DBID=944794439)

RMAN> report need backup;

Kontrolldatei der Zieldatenbank wird anstelle des Recovery-Katalogs verwendet
RMAN-Sperr-Policy wird f³r den Befehl angewendet
RMAN-Sperr-Policy ist auf Redundanz 10 festgelegt
Bericht. Dateien mit weniger als 10 redundanten Backups
Datei #bkps Name
---- ----- -----------------------------------------------------
1    0     D:\ORACLE\ORADATA\<MYSID>\SYSTEM01.DBF
2    0     D:\ORACLE\ORADATA\<MYSID>\UNDOTBS01.DBF
3    0     D:\ORACLE\ORADATA\<MYSID>\INDX01.DBF
4    0     D:\ORACLE\ORADATA\<MYSID>\TOOLS01.DBF
5    0     D:\ORACLE\ORADATA\<MYSID>\USERS01.DBF
RMAN> backup database;
RMAN> backup archivelog all;
RMAN> backup current controlfile;
</code>

Fazit: Nie alle Redologs verlieren!