ORA-01034: ORACLE not available nach Recovery

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo Leute,

wir hatten ein Systemcrash. Die Nacht davor haben wir noch ein Fullbackup mit FDR-Upstream gemacht. Nach der Rücksicherung und dem Versuch, die Datenbank (Oracle 10g R1) zu starten, kommt der Fehler:
„Bei einer nicht hochgefahrenen Instance angemeldet.
ORA-27100: shared memory realm already exists
Linux Error: 17: File exists
waiting …
Bei einer nicht hochgefahrenen Instance angemeldet.
select TABLESPACE_NAME from USER_TABLESPACES
*
FEHLER in Zeile 1:
ORA-01034: ORACLE not available“

Im alert.log steht (hab nur mal das Ende angehängt):

PMON started with pid=2, OS id=16262
MMAN started with pid=3, OS id=16264
SMON started with pid=7, OS id=16272
DBW0 started with pid=4, OS id=16266
LGWR started with pid=5, OS id=16268
CKPT started with pid=6, OS id=16270
RECO started with pid=8, OS id=16274
Fri Jul 25 07:03:36 2008
ALTER DATABASE MOUNT
Fri Jul 25 07:03:37 2008
Controlfile identified with block size 16384
Fri Jul 25 07:03:41 2008
Setting recovery target incarnation to 1
Fri Jul 25 07:03:41 2008
Successful mount of redo thread 1, with mount id 2508711368
Fri Jul 25 07:03:41 2008
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Fri Jul 25 07:03:41 2008
ALTER DATABASE OPEN
Fri Jul 25 07:03:41 2008
Beginning crash recovery of 1 threads
Fri Jul 25 07:03:41 2008
Started redo scan
Fri Jul 25 07:03:42 2008
Completed redo scan
6881 redo blocks read, 11 data blocks need recovery
Fri Jul 25 07:03:42 2008
Started redo application at
Thread 1: logseq 2815, block 4273, scn 0.0
Fri Jul 25 07:03:42 2008
Recovery of Online Redo Log: Thread 1 Group 3 Seq 2815 Reading mem 0
Mem# 0 errs 0: /opt/DB/oracledb/redo/redo03a.log
Fri Jul 25 07:03:42 2008
RECOVERY OF THREAD 1 STUCK AT BLOCK 1742 OF FILE 2
Fri Jul 25 07:03:42 2008
Completed redo application
Fri Jul 25 07:03:42 2008
RECOVERY OF THREAD 1 STUCK AT BLOCK 9 OF FILE 2
Fri Jul 25 07:03:42 2008
Errors in file /opt/DB/osoft/admin/DBase/bdump/DBase_p002_16284.trc:
ORA-00600: internal error code, arguments: [ktbtfscr], [0], [], [], [], [], [], []
Fri Jul 25 07:03:43 2008
Errors in file /opt/DB/osoft/admin/DBase/bdump/DBase_p002_16284.trc:
ORA-01578: ORACLE data block corrupted (file # 1, block # 47136)
ORA-01110: data file 1: ‚/opt/DB/oracledb/DBase/system01.dbf‘
ORA-10564: tablespace SYSTEM
ORA-01110: data file 1: ‚/opt/DB/oracledb/DBase/system01.dbf‘
ORA-10560: block type ‚195‘
ORA-00600: internal error code, arguments: [ktbtfscr], [0], [], [], [], [], [], []

Was kann man da noch machen?

Danke und Grüße
Bozi

#2

Hi!

Eigentlich wäre hier die Note:28814.1 angebracht (betrifft genau Deine Fehlerbeschreibung) - allerdings gibt es da einen kleinen Absatz, der mich zumindest Erschaudern läßt:
Note: If the problem is an ORA-1578 on STARTUP then please
contact your local support center for advice referencing
Note:106638.1 - this note is not visible to customers
but the relevant steps from it can be supplied by an experienced
support analyst.
Da werden wahrscheinlich ganz _böse_ Sachen gemacht, die Oracle anscheinend nicht mal DBAs zutraut …

Ran ans Telefon!

Grüße,
Tomh

#3

ORA-27100
Hi,

Hallo Leute,

wir hatten ein Systemcrash. Die Nacht davor haben wir noch ein
Fullbackup mit FDR-Upstream gemacht. Nach der Rücksicherung
und dem Versuch, die Datenbank (Oracle 10g R1) zu starten,
kommt der Fehler:
"Bei einer nicht hochgefahrenen Instance angemeldet.
ORA-27100: shared memory realm already exists

ORA-27100

Da liegt doch eher der Fehler.
ORA-01034 ist nur die Konsequenz.

schau mal hier…

http://www.dba-oracle.com/t_ora_27100_shared_memory_…

Auszug:
To resolve ORA-27100, you should execute the following instructions:

  • Move the spfile from its default location or rename the spfile .

  • Restart the service

  • Now the service will start the database using pfile , with old SGA settings. This should start your database successfully .

  • Create the new spfile from pfile.

Oder mal danach googlen.

Ich habe gelesen das das vorkommt wenn die Größe des RAMs geändert wird oder wenn schon eine Instanz mit diesem Namen läuft.
Bzw. eine Instanz mit dem Namen noch irgendwo angelegt ist.
Deswegen denke ich, der Fehler könnte behoben werden durch Hilfe des Artikels.

lass mal wissen ob oder was geklappt hat.

mfg
Martin

#4

Hallo Leute,

erstmal: vielen Dank für eure Hilfe! Habe mehreremale das spfile umbenannt und in SQLPlus als sysdba „create spfile from pfile“ abgesetzt. Hat aber nix genutzt. Die DB fuhr nur in den Status mount, aber nicht open (die Fehlermeldungen waren immer unterschiedlich. Manchmal „Linux Datei existiert schon“ und „unerwarteter Kommunikationsfehler“. Manchmal irgendwelche andere Fehlermeldungen.
Die Lösung war: Ich habe jemanden dran gesetzt, der im Gegensatz zu mir, Ahnung von Oracle hat. Ich frage ihn morgen mal, was er gemacht hat. Es war irgendwas mit einem „internen Recovery“. Ich poste dann die Lösung.

Nochmal Danke und Grüße
Bozi

#5

So, hab mal meinen Kollegen gefragt: Er sagt, er hat lediglich in SQLPlus „recovery database;“ oder „recover database;“ eingegeben.