ORA-00600 [kghstack_free2] + ORA-00604 ORA-08103
By: Date: 20.01.2012 Categories: !RUS,Errors,ORACLE Метки:

База не стартует и соединиться с ней не получается. В alert вот это

Dump file c:\admin\pgr\bdump\alert_pgr.log
Fri Jan 20 10:24:04  2012
ORACLE V10.2.0.5.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows XP Version V5.1 Service Pack 2
CPU                 : 2 - type 586
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:403M/1014M, Ph+PgF:1926M/2442M, VA:1924M/2047M
Fri Jan 20 10:24:04  2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as C:\Oracle10g\RDBMS
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.5.0.
System parameters with non-default values:
  processes                = 150
  __shared_pool_size       = 230686720
  __large_pool_size        = 4194304
  __java_pool_size         = 4194304
  __streams_pool_size      = 0
  nls_language             = RUSSIAN
  nls_territory            = RUSSIA
  sga_target               = 528482304
  control_files            = C:\ORADATA\PGR\CONTROL01.CTL
  db_block_size            = 8192
  __db_cache_size          = 281018368
  compatible               = 10.2.0.5.0
  db_file_multiblock_read_count= 16
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  job_queue_processes      = 10
  audit_file_dest          = C:\ADMIN\PGR\ADUMP
  background_dump_dest     = C:\ADMIN\PGR\BDUMP
  user_dump_dest           = C:\ADMIN\PGR\UDUMP
  core_dump_dest           = C:\ADMIN\PGR\CDUMP
  db_name                  = pgr
  open_cursors             = 500
  pga_aggregate_target     = 175112192
PMON started with pid=2, OS id=2868
PSP0 started with pid=3, OS id=2864
MMAN started with pid=4, OS id=580
DBW0 started with pid=5, OS id=1356
LGWR started with pid=6, OS id=2876
CKPT started with pid=7, OS id=2328
SMON started with pid=8, OS id=2880
RECO started with pid=9, OS id=2844
CJQ0 started with pid=10, OS id=1396
MMON started with pid=11, OS id=2252
MMNL started with pid=12, OS id=2256
Fri Jan 20 10:24:04  2012
alter database mount exclusive
Fri Jan 20 10:24:08  2012
Setting recovery target incarnation to 1
Fri Jan 20 10:24:08  2012
Successful mount of redo thread 1, with mount id 2522192580
Fri Jan 20 10:24:08  2012
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Fri Jan 20 10:24:08  2012
alter database open
Fri Jan 20 10:24:08  2012
Beginning crash recovery of 1 threads
 parallel recovery started with 2 processes
Fri Jan 20 10:24:09  2012
Started redo scan
Fri Jan 20 10:24:09  2012
Completed redo scan
 58 redo blocks read, 5 data blocks need recovery
Fri Jan 20 10:24:09  2012
Started redo application at
 Thread 1: logseq 419, block 3
Fri Jan 20 10:24:09  2012
Recovery of Online Redo Log: Thread 1 Group 2 Seq 419 Reading mem 0
  Mem# 0: C:\ORADATA\PGR\REDO02.LOG
Fri Jan 20 10:24:09  2012
Completed redo application
Fri Jan 20 10:24:09  2012
Completed crash recovery at
 Thread 1: logseq 419, block 61, scn 18854265
 5 data blocks read, 5 data blocks written, 58 redo blocks read
Fri Jan 20 10:24:10  2012
Thread 1 advanced to log sequence 420 (thread open)
Thread 1 opened at log sequence 420
  Current log# 3 seq# 420 mem# 0: C:\ORADATA\PGR\REDO03.LOG
Successful open of redo thread 1
Fri Jan 20 10:24:10  2012
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jan 20 10:24:10  2012
SMON: enabling cache recovery
Fri Jan 20 10:24:11  2012
Successfully onlined Undo Tablespace 1.
Fri Jan 20 10:24:11  2012
SMON: enabling tx recovery
Fri Jan 20 10:24:11  2012
Database Characterset is CL8MSWIN1251
Fri Jan 20 10:24:11  2012
Errors in file c:\admin\pgr\bdump\pgr_p000_2228.trc:
ORA-00600: Internal error code, arguments: [kghstack_free2], [], [], [], [], [], [], []

Fri Jan 20 10:24:12  2012
Errors in file c:\admin\pgr\udump\pgr_ora_2872.trc:
ORA-00604: Error occurred at recursive SQL level 1
ORA-08103: Object no longer exists

Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604

Поиск в лоб по ORA-00600 [kghstack_free2] — ничего не дал. Решил заглянуть в пользовательский трейс c:\admin\pgr\udump\pgr_ora_2872.trc. Начало там не заинтересовало, а вот где-то после середины обратил внимание на это

----- End of Call Stack Trace -----
===================================================
PROCESS STATE
-------------
Process global information:
     process: 2F260608, call: 2F37EC30, xact: 00000000, curses: 2F35ABC8, usrses: 2F35ABC8
  ----------------------------------------
  SO: 2F260608, type: 2, owner: 00000000, flag: INIT/-/-/0x00
  (process) Oracle pid=14, calls cur/top: 2F37EC30/2F37EC30, flag: (0) -
            int error: 0, call error: 0, sess error: 0, txn error 0
  (post info) last post received: 0 0 260
              last post received-location: kxfprienq: slave
              last process to post me: 2f25e208 1 22
              last post sent: 0 0 33
              last post sent-location: ksrpublish
              last process posted by me: 2f25e208 1 22
    (latch info) wait_event=0 bits=10
      holding    (efd=9) 2e1934a4 Child redo copy level=4 child#=1
        Location from where latch is held: kcrfw_redo_gen: nowait:
        Context saved from call: 0
        state=busy, wlstate=free
    Process Group: DEFAULT, pseudo proc: 2F29451C
    O/S info: user: SYSTEM, term: POGAR, ospid: 2228
    OSD pid info: Windows thread id: 2228, image: ORACLE.EXE (P000)
    (FOB) flags=2 fib=2E28A52C incno=0 pending i/o cnt=0
     fname=C:\ORADATA\PGR\SYSAUX01.DBF
     fno=3 lblksz=8192 fsiz=32000
    (FOB) flags=2 fib=2E289E9C incno=0 pending i/o cnt=0
     fname=C:\ORADATA\PGR\SYSTEM01.DBF
     fno=1 lblksz=8192 fsiz=55040
    ----------------------------------------

Решил проверить файлы SYSTEM01.DBF и SYSAUX01.DBF на целостность с помощью DBVERIFY и оказался прав, файл SYSAUX01.DBF оказался битым.

Самое простое и быстрое решение восстановить файл из резервной копии.