ora-00600 после старта экземпляра
Valery Emelianov
Где копать в такой ситуации (похоже, что ошибка появляется всегда после стаpта
оpакла)?
В пpинципе, дальше pаботает, хотя ora-00600 иногда за день может и вылезти...
Вот ALRT.LOG:
Dump file d:\Oracle\admin\oil\bdump\oilALRT.LOG
Mon Jan 14 14:59:08 2002
ORACLE V8.1.5.0.0 - Production vsnsta=0
vsnsql=d vsnxtr=3
Windows NT V4.0, OS V5.101, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.5.0.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
cpu_count = 2
shared_pool_size = 40000000
java_pool_size = 10000000
control_files = d:\oil\sys\control01.ctl,
f:\oil\sys\control02.ctl, e:\oil\sys\control02.ctl
db_block_buffers = 9600
db_block_size = 8192
db_block_lru_latches = 4
compatible = 8.1.5
log_buffer = 1048576
log_checkpoint_interval = 1200
log_checkpoint_timeout = 0
db_files = 50
db_file_multiblock_read_count= 8
transactions = 150
transactions_per_rollback_segment= 40
rollback_segments = RB_MTS_CTL, RB_GOMEL
remote_login_passwordfile= EXCLUSIVE
global_names = TRUE
distributed_transactions = 20
service_names = oil
instance_name = oil
optimizer_features_enable= 8.1.5
audit_trail = TRUE
sort_area_size = 2048000
db_name = oil
open_cursors = 50
os_authent_prefix =
optimizer_mode = RULE
query_rewrite_enabled = TRUE
query_rewrite_integrity = TRUSTED
cursor_space_for_time = TRUE
job_queue_processes = 1
job_queue_interval = 900
parallel_max_servers = 5
hash_join_enabled = TRUE
background_dump_dest = d:\Oracle\admin\oil\bdump
user_dump_dest = d:\Oracle\admin\oil\udump
max_dump_file_size = 10240
oracle_trace_collection_name=
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
SNP0 started with pid=8
Mon Jan 14 14:59:11 2002
alter database mount exclusive
Mon Jan 14 14:59:17 2002
Successful mount of redo thread 1, with mount id 1064196805.
Mon Jan 14 14:59:17 2002
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Mon Jan 14 14:59:17 2002
alter database open
Beginning crash recovery of 1 threads
Mon Jan 14 14:59:18 2002
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 3 Seq 60962 Reading mem 0
Mem# 0 errs 0: D:\OIL\SYS\REDO031.LOG
Mem# 1 errs 0: F:\OIL\SYS\REDO032.LOG
Mon Jan 14 14:59:21 2002
Thread recovery: finish rolling forward thread 1
Thread recovery: 60 blocks read, 60 blocks written
Crash recovery completed successfully
Picked broadcast on commit scheme to generate SCNs
Mon Jan 14 14:59:22 2002
Thread 1 advanced to log sequence 60963
Thread 1 opened at log sequence 60963
Current log# 1 seq# 60963 mem# 0: D:\OIL\SYS\REDO01.LOG
Current log# 1 seq# 60963 mem# 1: D:\OIL\SYS\REDO011.LOG
Successful open of redo thread 1.
Mon Jan 14 14:59:23 2002
SMON: enabling cache recovery
SMON: enabling tx recovery
Mon Jan 14 14:59:28 2002
Completed: alter database open
Mon Jan 14 14:59:29 2002
Errors in file d:\Oracle\admin\oil\bdump\oilSNP0.TRC:
ORA-00600: internal error code, arguments: [17302], [7], [], [], [], [], [], []
Mon Jan 14 15:00:14 2002
Restarting dead background process SNP0
SNP0 started with pid=8
_____________________________________________________________________Valery
mailto:val...@beloil.gomel.by icq:39345417 brainbench id:507947
Igor Ushkalo
You wrote to All on Mon, 14 Jan 2002 15:06:53 +0300:
VE> All! All! Did you read me?
VE> Где копать в такой ситуации (похоже, что ошибка появляется всегда
VE> после стаpта оpакла)?
VE> В пpинципе, дальше pаботает, хотя ora-00600 иногда за день может и
VE> вылезти...
VE> Вот ALRT.LOG:
А где трейс (oilSNP0.TRC)?
-- Best regards, Igor Ushkalo (igorus!) - igorus(at)mail.ru, ICQ #19972198
Valery Emelianov
Quoting Igor (via gate) to Valery Emelianov
on 17:43 at 14.01.2030
VE>> Где копать в такой ситуации (похоже, что ошибка появляется всегда
VE>> после стаpта оpакла)?
VE>> В пpинципе, дальше pаботает, хотя ora-00600 иногда за день может и
VE>> вылезти...
VE>> Вот ALRT.LOG:
IU> А где тpейс (oilSNP0.TRC)?
Специально повтоpил сейчас с shutdown immediate и startup.
_ALRT.LOG_ :
[..]
Mon Jan 14 18:12:53 2002
Completed: alter database open
Mon Jan 14 18:12:54 2002
Errors in file d:\Oracle\admin\oil\bdump\oilSNP0.TRC:
ORA-00600: internal error code, arguments: [17302], [7], [], [], [], [], [], []
Mon Jan 14 18:13:44 2002
Restarting dead background process SNP0
SNP0 started with pid=8
_SNP0.TRC (400 KB)_ :
Dump file d:\Oracle\admin\oil\bdump\oilSNP0.TRC
Mon Jan 14 18:12:54 2002
ORACLE V8.1.5.0.0 - Production vsnsta=0
vsnsql=d vsnxtr=3
Windows NT V4.0, OS V5.101, CPU type 586
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Windows NT V4.0, OS V5.101, CPU type 586
Instance name: oil
Redo thread mounted by this instance: 1
Oracle proc
ess number: 8
Windows thread id: 166, image: ORACLE.EXE
*** SESSION ID:(7.3) 2002.01.14.18.12.54.270
*** 2002.01.14.18.12.54.270
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [17302], [7], [], [], [], [], [], []
[..]
error 600 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00600: internal error code, arguments: [17302], [7], [], [], [], [], [], []
Igor Ushkalo
You wrote to Igor Ushkalo on Mon, 14 Jan 2002 18:18:44 +0300:
VE> Igor! Igor! Did you read me?
VE> Quoting Igor (via gate) to Valery Emelianov on 17:43 at 14.01.2030
VE>>> Где копать в такой ситуации (похоже, что ошибка появляется всегда
VE>>> после стаpта оpакла)?
VE>>> В пpинципе, дальше pаботает, хотя ora-00600 иногда за день может и
VE>>> вылезти...
VE>>> Вот ALRT.LOG:
IU>> А где тpейс (oilSNP0.TRC)?
VE> Специально повтоpил сейчас с shutdown immediate и startup.
Похоже дело в cursor_space_for_time... попробуй выставить в FALSE
Баг был в 8.1.6 вроде пофиксен...