ORA-600 [1113] State object being moved to freelist already free
ORA-600[1113][]
kss – Kernel Service State object manager.
Problem Description:
This error occurs when removing a state object to the free list and it is determined that the object already exists on the free list. A system state dump will generally accompany this error.
Call Stack Trace:
location point arg values
_ksedmp+136 0x0 0x5f4000 0x4e 0x34 0x4a7778 0x0
_ksfdmp+24 _ksedmp 0x3 0x5f4000 0x0 0x2 0x0 0x0
_kgeriv+220 _ksfdmp 0x5f33a4 0x3 0x258 0x4a72c0 0x114b 0x0
_kgeasi+76 _kgeriv 0x5f33a4 0x258 0x114b 0x0 0xefffe488 0x5f3408
_ktcrsp+856 _kgeasi 0x5f33a4 0x60365c 0x114b 0x2 0x0 0xaf
_ksuxds+1228 _ktcrsp 0xe0032924 0x0 0xe003290c 0x7fffffff 0xe006a508 0x4
_ksudel+8 _ksuxds 0xe0024658 0x2 0xe0024658 0x1 0xe001dea8 0xe0004904
_ksudls+928 _ksudel 0xe0024658 0x2 0xe001dea8 0x0 0x5f3408 0xefffe7ec
_opises+420 _ksudls 0x0 0xe0024658 0xefffe6a4 0x1 0xefffe6a4 0x60f938
_opiodr+3936 _opies 0x1 0x7 0xeffff7a0 0x811f8 0x0 0x1
_ttcpip+4784 _opiodr 0x5f5400 0x5f5400 0x811f8 0xd87d0 0x811f8 0x8bb50
_opitsk+1536 _ttcpip 0x5f4b9c 0xefffecec 0x1a 0xefffecec 0x4 0x7
_opiino+1380 _opitsk 0x5f4ba0 0x0 0x0 0xa 0x0 0x5f4b9c
_opiodr+3936 _opiino 0xeffffefc 0x5f4b9c 0x2811 0xeffffefc 0xeffffaac 00
_opidrv+1348 _opiodr 0x5f5400 0x5f5400 0x81078 0xe0cd0 0x81078 0x8baf0
_sou2o+16 _opidrv 0x3c 0x5f3408 0x0 0x5f3408 0x1 0xeffffd40
_main+148 _sou2o 0xefffff0c 0x3c 0x4 0xeffffefc 0x3 0x0
start+68 _main 0x2 0x0 0xefffff98 0x5de400 0x0 0x0
Other Information:
This problem was caused by the kernel not resetting the current transaction when a new session was created via upiscr().
Source Code: TBDL
SOLUTION TO ORA-600 [1113]
ORA-00600 [1113]
Oracle, while removing a state object to the freelist, discovers that the object is already marked as being on the freelist (bit(so->kssobflg, KSSOFLST)), and so dumps the state object and system state dump and logs ORA-00600 [1113].
If you experience this problem, collect the relevant trace and alert log files and contact Worldwide Customer Support
Bugs Filed:
168822 fixed at release 7.0.13.1.
184652 fixed (by rewrite) at 7.3. Associated with dropping sequences.
169822 specific to DEC Alpha VMS. Similar to 168822. Fixed at 7.0.13.1.
128961 fixed in 6.0.36.0.1
130548 fixed in 6.0.36.5
ORA-600 [1114] State Object parent links uninitialized
ORA-600[1114][]
kss – Kernel Service State object manager
Problem Description:
This error occurs when adding an object from the freelist and the parent object links have not been initialized.
Call Stack Trace:
calling location point argument list…
ksedmp()+132 sdtcs()+0 0x0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
kgeriv()+224 ksedmp() 0x3 0x3 0x258 0x0 0x0 0x0
kgesiv()+20 kgeriv() 0x6b49f4 0x6bdc34 0x45a 0x0 0xdfffb570 0x6b4a58
ksesic0()+48 kgesiv()+0 0x6b49f4 0x6bdc34 0x45a 0x0 0xdfffb570 0xba131a
kssadf()+452 ksesic0() 0x45a 0x0 0x0 0x6b4a58 0xdfffc6b0 0x6b4a58
kcbzgs()+172 kssadf()+0 0x6 0xba6b0240 0xb3643a88 0xba45668c 0x3 0xba45
kcbgcur()+268 kcbzgs()+0 0x4945 0x4945 0xba6afc3c 0xba650f6c 0x181 0xba4
kdddgb()+380 kcbgcur() 0x0 0x2 0x8000021 0x6c0174 0x40000d7 0x1a2160
kdusru()+392 kdddgb() 0x6c014c 0x6c0270 0x6c0174 0x300 0x1 0xb8087f50
kauupd()+32 kdusru() 0x6bfe68 0x6c014c 0x4000 0x0 0x6c0208 0x6bee6c
updexe()+2896 kauupd() 0x6c0338 0x0 0x6c014c 0x0 0x6bee70 0x6bee84
opiexe()+7524 updexe() 0x4 0x4 0x4 0x40000d7 0x6bee70 0xb7f7a7c0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
opiodr()+3940 opiexe() 0xb7f7aa38 0x8 0xb7f7aa38 0xc 0x6ca274 0x6ca280
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
smcstk()+100 opiodr() 0x6ca1d0 0x100020 0x802000 0x0 0x2 0x2
rpidru()+108 smcstk()+0 0x0 0x108958 0xf618 0x4 0x3 0xdfffd474
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
rpiswu()+1452 rpidru() 0x3 0x6b4a58 0xdfffd594 0x6b4a58 0x59c01e 0xdff
rpidrv()+1928 rpiswu()+0 0x4 0x7 0xfffffffc 0x4 0x6bfe54 0x6bfe58
rpiexe()+32 rpidrv() 0xdfffd594 0x6b4a58 0x8 0xdfffd3e8 0xdfffd360 0
kqdsnu()+660 rpiexe()+0 0x2 0x9 0xb7f81368 0x1a 0x1 0x0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
Kqrfpo()+980 kqdsnu() 0xb7f81258 0x3 0xe 0x118 0x5d98d8 0x2
kdnwtd()+1128 kqrfpo()+0 0x12a 0xb7f81258 0xb7f81258 0x12a 0x3 0x3
kdnfsh()+56 kdnwtd()+0 0xb80e1acc 0x1 0xb80c7840 0x0 0xb8087f50 0xb808
kdncls()+204 kdnfsh()+0 0xb80e1acc 0x1 0xb80c7840 0xba109878 0x4 0xb80e
adbdrv()+4200 kdncls() 0x0 0x0 0xba1df110 0xb80df77c 0xb80e1acc 0xb80d
opiexe()+9012 adbdrv() 0x6b4a58 0x7 0xdfffd914 0x6b4a58 0x441 0x0
opiosq()+2564 opiexe() 0x37c 0x6c6660 0x6bf75c 0xb2ab9fa8 0xb2aba034 0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
Piodr()+3940 opiosq() 0x0 0x0 0x6b49f4 0x64 0x6b4a58 0x0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
Ttcpip()+4868 opiodr() 0xfffe 0x1 0x1 0x0 0x1 0x1
opitsk()+1592 ttcpip() 0x6b61e0 0x1a 0x0 0xdfffe928 0x4 0xf
opiino()+1340 opitsk()+0 0x6b61e0 0x6b622c 0x6b6228 0x0 0xa 0x0
Did not find loadable Program Segment in /opt/oracle/bin/oracle.
opiodr()+3940 opiino() 0x0 0x6b6000 0x64 0x6b4a58 0x0 0x6b5fdc
opidrv()+1388 opiodr()+0 0x0 0x1 0x1 0x0 0x0 0x6b61e4
sou2o()+16 opidrv() 0x6b4a58 0x0 0x0 0x3c 0x0 0x6b4a58
main()+140 sou2o()+0 0xdffffbbc 0x3c 0x4 0xdffffbac 0x3 0x0
_start()+92 main() 0x2 0x0 0xdffffc48
Other Information:
If the state object gets corrupted in the SGA, this error will occur.
Source Code: TBDL
SOLUTION TO ORA-600 [1114]
ORA-00600 [1114]
Oracle is creating a new state object by grabbing an unused object from the freelist, when it is discovers that the unused object has an uninitialized pointer. This could indictate a corruption and so ORA-00600 [1114] is logged along with pointer information and a system state dump.
If you encounter this problem, collect the relevant trace and alert log files and contact Worldwide
Customer Support.
Bugs Filed:
323437 Ongoing
205399 Fixed in 7.2.2 (See also 173585)
282296 Ongoing
112427 Fixed in 6.0.36.7
137122 Fixed in 6.0.36.5
ORA-600 [1117] State Object to be freed already on freelist
ORA-600[1117][]
kss – Kernal Service State object manager.
Problem Description:
Generally, this problem occurs when adding a state object to the freelist it is discovered that the parent object is already on the freelist.
Call Stack Trace:
location call type point argument values in hex
opipio+f4 bl rwstab+2c0 105D7D18
ksledt+488 bl opipio+38 1056DBD8
+3c58 bl li8615+e8
+4174 bl +3b88 10316EA8 2000C980 64 40005C02FF1F2D4
100CBDB0 bl +4118 2000C980 2004258C FEB 2 1 0 2FF1F2D4
10319E38 bl 100CBA0C 067CBB 2FF1F354 2FF1F35C 2FF1F378 2FF1F2
103A4028 bl 10318D44 47F8805C 0 B 0 20174378 0
1039E0E4 bl 103A3D5C 2004479C 20001010 0 4504EC54 1 2FF202CC 0
100EDC70 bl li8615+e8
100EF298 bl 100ED570 20014F28
1039BF64 bl 100EE280 2007C4DC
103B064C bl 1039BCB4 20094434 3
10283450 bl li8615+e8
1027879C bl li8615+e8
102824BC bl 10277D20 57B 1 2FF21D28 0 2000D8B0 0 D10000 1
103E0234 bl 10281D20 2FF22EEA
10283450 bl li8615+e8
_lilt$c$+5ec bl 10282980 3C 4 0 0
_lilt$c$+258 bl
_lilt$c$+29c bl 3C 0 0 pgahtop_+108
_lilt$c$+22c bl 0 0 0 0
sksdud_+fc bl pgahtop_+48 0 0
Other Information:
Dumping the stack trace in SQLDBA yields useful information:
ALTER SESSION SET EVENTS ‘IMMEDIATE TRACE NAME ERROR_STACK LEVEL 1’
Known Bugs:
Bug Version Platform Fixed
268200 7.1.4.1.0 Microsoft Windows 7.2.2
333789 7.1.6.2 HP/UX HP 98XX series 7.2.2
305378
310192 7.1.4.1.0 SCO UNIX 386 7.2.2
308878 7.1.6.2.0 IBM RS/6000 AIX 7.2.2
166338 7.0.12.1.0 Sun SunOS 4.X 7.2.2
Source Code: TBDL
SOLUTION TO ORA-600 [1117]
Solution Description:
The best bet here is to gather relevent alert log, trace files and system state object dumps and call Oracle Worldwide Support. Generally, some form of SGA corruption is possible.
ORA-600 [1191] Unexpected Instance Lock condition
ORA-600[1191][req]
ksi – Kernel Service layer Instance locks
Problem Description:
This error is as a result of an unexpected lock status condition. It is trapped in a layer of code that sits on top of the system dependent instance lock interface.
Problem Explanation:
This error is port specific but logged on a number of platforms. It involves a resource situation where insufficient locks are available.
Other Information:
DLM locks can be increased/decreased by the lock manager.
Known Bugs:
311166 7.1.4
299454 7.1.4.1.3
Source Code: TBDL
SOLUTION FOR ORA-600 [1191]
Solution Description:
Generally, a LCKn trace file will accompany this error. It will be obvious from the errors in the trace file that more lock resources are required to operate.
Other errors usually included with this error condition are:
ORA-09956: scgcm: unexpected lock status condition.
ORA-00050: O/S error occured while obtaining an enqueue. See O/S error.
Solution Explanation:
When DLM locks are insufficient, this error will result. This is not a bug but correct behavior for the RDBMS kernel. The second argument [6] refers to the system operating system dependent (SOSD) layer handling the unexpected or unhandled return code.
Workaround(s):
Start the lock manager with more locks allocated:
dbtool -lmstart -opts :-l <number of locks needed>:
ORA-600 [12011] Compile time Job Queue problem
ORA-600[12011][failures]
kkj.c – Kernel Kompiletime Job queue
Problem Description:
This error is signalled in parallel query when a job fails to execute in the correct predetermined sequence. Generally, a predecessor process fails prohibiting the entire query (operation) from completing. This error is signalled by kkjexe().
Other Information:
The second argument identifies the number of failures in this session.
Known Bugs:
Bug Version Platform Result
288289 7.1.4 IBM AIX/RS6000/RISC 91
Source Code: TBDL
Solution Description:
Retry the query (operation). One or more of the predecessor jobs failed causing this error to occur.Usually this is related to recursive transactions failing.
ORA-600 [12201] Shared Compilation Problem
ORA-600[12201][]
kks.c – Kernel Kompile Shared
Problem Description:
This is a problem in the DDL Drivers where a cursor that is being closed is placed into the cursor cache. The cursor should have been unlocked and unpinned at the end of the parse call. The lock and pin have already been deleted since they hang off of the call.
Problem Explanation:
There existed an incorrect assumption that after unpinning and repinning an object, it had to be found at the same memory location.
Other Information:
This error often appears when selecting from a view.
Known Bugs:
Bug Version Platform Status
208394 7.0.16 Sequent DYNIX/ptx (G) Fixed in 7.1.3
216959 7.0.15 HP/UX HP 98XX series “
Source Code: TBDL
SOLUTION TO ORA-600 [12201]
Solution Description:
Most likely, if the version of RDBMS is prior to 7.1.3, this is probably bug 208394. A workaround of flushing the shared pool has been known to work frequently.
Solution Explanation:
Often the shadow process will be using a large percent of the CPU when the application process hangs.
Workaround(s):
ALTER SYSTEM FLUSH SHARED_POOL;
ORA-600 [12235] Oracle process has no purpose in life !
ORA-600 [12235] [] [] [] [] []
Versions: 7.0.16 – 7.2.2
Source: opirip.c
Meaning:
An Oracle process was started but it cannot work out what it is suposed to be doing. Hence it exits.
Diagnosis:
– There is no DB corruption involved here – this is not generally serious unless the SGA is corrupt and the error keeps occuring.
– Depending on version the trace file may contain an SGA dump.
Check out the situations below first.
– This can be caused in some releases by just typing ‘oracle’at the command line. To eliminate this you can add a dummy ‘oracle’ shell script in a bin directory in the users PATH BEFORE the $ORACLE_HOME/bin directory.
– Are they using: PQO ?, MTS ?, Prespawned Servers ? etc..
– Is the V2 listener the same release or higher if using net2 ?
– For UNIX a debug program may be used to help determine what the process name was. This may / may not be of help and requires time to set up. See <NotePart:33174.1:DBGCODE>
– If you get any decent information update <Bug:141220>
Known Bugs:
Fixed I n. Bug No. Description
7.1.5 Bug:225677 12235 using PARALLEL hint above PARALLEL_MAX_SERVERS.
No Fix Bug:141220 12235 extra debugging added.
ORA-600 [12261] SQL Parse Problem
ORA-600[12261][]
opiosq – ORACLE Program Interface O SQL (parse only)
Problem Description:
This error occurs when a SQL statement is incorrectly terminated.
Problem Explanation:
The SQL parser has determined that the statement terminator is invalid. This usually
originates from the application or internally from recursive SQL.
Call Stack Trace:
location point arg values
_ksedmp+136 0x0 0x58d000 0x4f 0x3a 0x598340 0x0
_ksfdmp+24 _ksedmp 0x3 0x58d000 0x0 0x2 0x0 0x0
_kgeriv+220 _ksfdmp 0x58c37c 0x3 0x258 0x3a8408 0x2fe5 0x0
_kgesiv+20 _kgeriv 0x58c37c 0x258 0x2fe5 0x0 0xefffbd10 0x58c3d4
_ksesic0+48 _kgesiv 0x58c37c 0x62c1b4 0x2fe5 0x0 0xefffbd10 0x0
_opiosq+516 _ksesic0 0x2fe5 0x3 0xe0b96350 0x40000a 0x576f 0xefffc45c
_opiodr+3936 _opiosq 0x63265c 0x632644 0x632644 0x0 0xe0b96350 0x576f
_smcstk+96 _opiodr 0xe0 0x632644 0x530aa0 0xc3560 0x530aa0 0xc5
_rpidru+116 _smcstk 0x0 0x92ba8 0xf618 0x4a 0xf 0xefffc45c
_rpiswu+1388 _rpidru 0xefffc320 0x58c3d4 0x8 0xefffc104 0x58c3d4 0xf
_rpidrv+2028 _rpiswu 0x62ea24 0x62e360 0x62ea24 0x5313ef 0x62ea24 0x58c\ d4
_psddrv+344 _rpidrv 0x7 0xefffc320 0xefffc29c 0xc7a24 0xc7b18 0x32
_psdosq+156 _psddrv 0xe 0x4a 0xefffc45c 0x0 0x1 0xefffc458
_psdnal+500 _psdosq 0xefffe4d0 0x0 0x0 0xe 0xe0b96350 0x576f
_pricar+436 001CBD04 0x637428 0x637428 0xefffe4d0 0x64bd18 0x64be54 0x6\
_pricbr+768 _pricar 0xefffe4d0 0xefffe2fc 0x3 0x66e3dc 0x1b1 0x637428
_prient2+1352 _pricbr 0x1b1 0xefffe2fc 0x66eaa4 0x0 0xe0bb4558 0xe0bb60c\
_peirep+76 _prient2 0x637428 0x637428 0x637428 0x66e3dc 0x637428 0xeff\
_kkxrex+1584 _peirep 0xefffe4d0 0x64bf34 0x63caa0 0x3 0x66e214 0x6d4
_kporrcv+2532 _kkxrex 0x63caa0 0x1b1 0x1b1 0x62e360 0x1b1 0x65d6f8
_kpostr+672 _kporrcv 0x58db60 0x65d6f8 0x58dbac 0x63caa0 0x1b1 0x0
_opiodr+3936 _kpostr 0x58dbac 0x11 0x63ca88 0x1 0x63ca74 0x58db60
_ttcpip+4784 _opiodr 0x58e400 0x58e400 0x530b30 0x383f98 0x530b30 0x52f\84
_opitsk+1452 _ttcpip 0x58db60 0xeffff800 0x52e320 0xefffecd0 0xeffff7b0\ 0x11
_opiino+1380 _opitsk 0x58db64 0x0 0x0 0xa 0x0 0x58db60
_opiodr+3936 _opiino 0xeffffecc 0x58db60 0x2801 0xeffffecc 0xeffffa7c 0\ 623888
_opidrv+1348 _opiodr 0x58e400 0x58e400 0x5309c0 0xbb018 0x5309c0 0x52f3\ 8
_sou2o+16 _opidrv 0x3c 0x58c3d4 0x0 0x58c3d4 0x1 0xeffffd10
_main+148 _sou2o 0xeffffedc 0x3c 0x4 0xeffffecc 0x3 0x0
start+68 _main 0x2 0x0 0xefffff68 0x520400 0x0 0x0
Other Information:
Usually the SQL string passed to the parser is not properly null terminated.
Known Bugs:
Bug Version Platform Status
286423 7.0.16.6 IBM RS/6000 AIX 91
261858 7.0.16.6.2 DEC Alpha VMS series 91
259473 7.1.3 Sequent DYNIX/ptx 91
251995 7.1.3.2 Sequent DYNIX/ptx 91
250083 7.1.3 HP/UX HP 98XX series 11
Source Code: TBDL
SOLUTION TO ORA-600 [12261]
Solution Description:
This error is PL/SQL related and is resolved in RDBMS version 7.1.4.
Workaround(s):
For PL/SQL related issues prior to 7.1.4, dropping and recreating the package is a valid workaround.Also, by splitting large packages into two separate (smaller) packages will get by this error on occasion. Pinning the package and force recompilation of the package body will workaround this error with frequency.
ORA-600 [12325] Illegal predicate in View expansion
ORA-600 [12325] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.3
Source: v/vop.c
Meaning:
Illegal operation on a view optimize / copy. The operands being set up should not be in the predicate.
Argument Description:
a. opntyp Operation type requested (see opndef.h)
Diagnosis:
Check out the PROCESSSTATE for the current SQL statement. Check the expansion of any views in the statement – does the statement look legal?
ORA-600 [12333] Fatal Two Task Protocol violation
ORA-600 [12333] [a] [b] [c] [d] [e]
Versions: 7.1.3 – 7.1.6
Source: opitsk.c
Meaning:
This is a communication mismatch between the Oracle executable and the client program. Ie: A two task protocol violation.
Argument Description:
a. TTI Layer Function code received.
b. Function code
c. Sequence
Diagnosis:
In most cases this is probably masking an unexpected exception condition on some operation which throws the TTC out of sync.
Argument [a] shows us what Function code we received.
We cannot generally progress these unless there is reproducible test case or reproducible environment. There are hundreds of ‘could not reproduce’ style Known Bugs:so basically unless there is a constant problem we cannot progress the issue.
The error can be due to underlying network problems.
Known Bugs:
Fixed In. Bug No. Description
4.0.12.1.17 <Bug:214362> Referencing a NULL DATE Bind variable in forms PLS
7.1.4 <Bug:195946> UPDATE of missing row mishandled.
ORA-600 [1236] Service User: ?
ORA-600[1236][]
ksu – Kernel Service User management.
Problem Description:
In earlier versions of the RDBMS (6.0, 7.0) this was a problem with shared memory collisions between instances of a database. Multiple instances appear to be running off of the same set of datafiles (not Oracle Parallel Server). In more recent versions of the RDBMS (7.1, 7.2) this error is usually parallel query related.
Call Stack Trace:
0 00496c24-sdtcs (0x0, 0x4, 0x1, 0x0) [sdtcs.c:177]
1 0047f53c-ssexhd (0x4, 0x1006046c, 0x0, 0x0) [ssexhd.c:263]
2 009073c4-sigvec (0x2, 0x1003c0a8, 0xf, 0x1) [../sigvec.s:109]
3 00907550-_cerror (0x2, 0x1003c0a8, 0xf, 0x1) [../cerror.s:26]
signal handler assertion failed (_longjmp)
st_dump_frame returns error: -1 at pc= 008ff2bc
ssexhd+108 (0x47f53c): sdtcs(0x0, 0x0, 0x4, 0x7fff5354, 0x0)
sigvec+164 (0x9073c4): ssexhd(0x4, 0x7fff5354, 0x0, 0x0, 0x2)
_longjmp+160 (0x8ff2bc): abort(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)
_longjmp+160 (0x8ff2bc): _longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)
_longjmp+160 (0x8ff2bc): _longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)
_longjmp+160 (0x8ff2bc): _longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)
_longjmp+160 (0x8ff2bc): _longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)
_longjmp+160 (0x8ff2bc): _longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0).
.
Other Information:
Sometimes this error is parallel query related where a slave query process will fail and report this error along with other errors.
Known Bugs:
Bug Version Platform Status
308813 7.1.6.2.0 IBM SP AIX 91
260277 7.1.3.0.1 AT&T System 3000 91
257903 7.0.13.1 DEC MIPS Ultrix 96
257901 Base
Source Code: TBDL
SOLUTION TO ORA-600 [1236]
Solution Description:
This internal error is as a result of popping one too many errors of off the error stack and losing the much needed information.
If you encounter this problem, collect the relevant trace and alert log files and contact Worldwide Customer Support.
ORA-600 [1237] Invalid Session while changing SO
ORA-600[1237][]
kss – Kernel Service User management.
Problem Description:
This error occurs when pushing a user call while making state object changes across the program interface where the calling session is not a valid session.
Other Information:
This error occurs on heavily loaded systems running MTS.
Known Bugs:
Bug Version Platform Status
273358 7.1.3.2 Sequent DYNIX/ptx 7.1.6.2
293524 7.0.16.6 DEC Alpha VMS series 7.1.6.2
284547 7.1.4 HP 93xx HP/UX 7.1.6.2
276665 7.1.4 Sun Solaris V2 UNIX 7.1.6.2
274323 7.1.3.2 DEC Alpha VMS series 7.1.6.2
27335 7.1.3.2 Sequent DYNIX/ptx
269572 7.1.3.2 HP 98xx HP/UX
240140 Base Fixed 7.1.6.2
Source Code: TBDL
SOLUTION FOR ORA-600 [1237]
Solution Description:
Bug 240140 was resolved in version 7.1.6.2 of the RDBMS. Many platforms experienced this problem using tuxedo, XA and Multi-Threaded Server (MTS).
Generally, gather all relevent information such as trace files, alert log and any kind of dumps and call Oracle Worldwide Customer Support.
ORA-600 [12700] Index points to missing ROWID
ORA-600 [12700] [a] [b] [c] [d] [e]
Versions: 7.0.15 – 7.1.6
Meaning:
A mismatch between the index and the data block it is pointing at in that a row in the index points at a non-existant row in the data block.
Argument Description:
a. DBA on some versions ?
Diagnosis:
This can be due to a real corruption OR due to a consistent read problem.
– ANALYZE TABLE <tname> VALIDATE STRUCTURE CASCADE to show if it is a real corruption or not – or perform a full range scan via the index.
If this shows as a problem treat the issue as a corruption and rebuild the index. It would be wise to dump the affected blocks / redo first if further analysis may be required.
– If the analyze succeeds this is probably a consistent read problem.
The most common cause of the problem is a long(ish) running query
which scans through an index on which dml (update/insert) is
currently occurring and causing ‘index-splitting’ to occur.
In this case the longer running the query the more chance of it
hitting one of these blocks thus forcing a CR (consistent
read) back to a pre-split time. The CR block can in this case have
an index entry marked as valid (incorrectly) whereas the data-block
has the row marked deleted (correctly).
Workarounds:
Try not to use the index.
Force a dummy sort to pre-allocate the row source up front.
Evidence:
For NEW issues:
– Tracefile
– Redo for the INDEX and DATA blocks
– Application logic
– Current dumps of redo / data blocks
– If easily reproducible after bouncing the DB put 10226 on.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
7.1.4 Bug:194593 CR problem
7.1.5 Bug:226468 CR problem
ORA-600 [1301] Process Cleanup of pseudo child
ORA-600[1301][child]
ksucln – Kernel Service User management CLeaNup process.
Problem Description:
This kernel runtime facility finds pseudo child processes that were created by a process or circuit that is no longer active (dead or logged off).
Problem Explanation:
Generally, a bogus pseudo child process is found that has been orphaned. Also, when a child of a pseudo process is not a session, this error will be flagged. The pseudo process is a place holder for sessions. When clients are running XA, sessions temporarily move to the pseudo process when they become detached from a terminal.
Other Information:
Previous recovery problems will indicate block clean out on the itl was performed incorrectly.
Known Bugs:
189549 XA environment.
181935 Increase timeout.
Source Code: TBDL
SOLUTION TO ORA-600 [1301]
Solution Description:
The following recommended steps will aid in determining the course of action to take:
Get system state dump immediately after the instance is started:
ALTER SESSION SET EVENTS “IMMEDIATE TRACE NAME SYSTEMSTATE LEVEL 10”;
Set event 10246 in init.ora for additional PMON trace information.
event = “10246 trace name context forever, level 10”;
Get the log files from XA and Tuxedo if applicable.
Solution Explanation:
If the XA interface is involved, the Session Time (SesTm) can be increased to the order of a couple of hours. for this timeout will not work and is not recommended. PMON possibly deleted the session because the detached timeout expired or its owner process has died. This information is readily apparent in the 10246 generated trace file. If the session is still there it can be removed by the following command:
ALTER SYSTEM KILL SESSION n,m
The session can also be removed at the operating system level.
Workaround(s):
XA = increase timeout value to hours.
ORA-600 [13011] Problem occurred when trying to delete a row.
ORA-600 [13011] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: delexe.c
Meaning:
Problem occurred when trying to delete a row.
Argument Description:
a. Pass count. (If greater than 5000 then this is what’s exceeded).
b. Code.
c. DBA of block containing the row to be deleted.
d. Row slot number.
e. DBA of block being updated (should be same as ‘c.’) ?
Diagnosis:
Most probably a corrupted index.
Check object that this DBA points to.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
Bug:189281 Suggests this is caused by bad index or consistent read problem.
Bug:111890 Deleting the same row twice.
ORA-600 [13012] Update Row Piece predicate Failure
ORA-600 [13012]
Versions: 7.1.4 – 7.2.3
Source: u/updexe.c
Meaning:
indicates that we were trying to update a row that we believe was already locked but that we got a predicate failure.
Diagnosis:
Trace includes a Buffer Cache dump & lots of diagnostics.
If the trace file is truncated we may not be able to tell the cause. Are there multiple triggers on the table ? See <Bug:318811>
ANALYZE table VALIDATE STRUCTURE CASCADE;
Check for chained rows.
Known Bugs:
Fixed In. Bug No Description
<Bug:318811> Introduced in 7.1.5 – multiple triggers
<Bug:200344> Chained row corruption could cause this.
ORA-600 [13013] Bad block found during UPDATE
ORA-600 [13013] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Meaning:
Inconsistency between index and data block in the DB found during update.
Argument Description:
a. Pass count (>5000)
b. Code
c. DBA of block containing the row to be updated
d. Row slot number.
e. DBA of block being updated (should be same as ‘c.’) ?
Diagnosis:
Check what object is at this DBA.
ANALYZE TABLE VALIDATE STRUCTURE CASCADE may be worth running.
Recreate if an index.
If you are having problems identifying the object / row set <Event:10219> at level 4999. This will dump the environment on each pass.
ORA-600 [15803] Parallel Query message out of order
ORA-600[15803][severity_code]
kxfx.c – Kernel eXecute Fast (parallel) sql eXecution
Problem Description:
This error relates to a client/server parallel query message protocol/ transmission breakdown.
Problem Explanation:
Generally, a message notification or response is out of sequence or unexpected.
Other Information:
This feature (Oracle Parallel Query) is new for RDBMS version 7.1. Each query is parallelized and broken down by rowid. A number of slave processes will be created to concurrently execute the SQL statement(s). An extensive messaging system controls the separation and combining of the process operations resulting in the finalized query.
Source Code: TBDL
SOLUTION TO ORA-600 [15803]
Solution Description:
Restart the query.
Solution Explanation:
Query slave processes have failed implementing SQL fetch, parse, bind, or execute operations.
Generally a sequence of events occured out of order or an unexpected message response was received.
ORA-600 [16224] Error Cleaning OBJ$
ORA-600 [16224] [a] [b] [c] [d] [e]
Versions: 7.1.3 – 7.1.4
Source: kql.c
Meaning:
kqlclo() KQL CLean Obj$ tried to delete a non existant object
Diagnosis:
If 7.1.4 and startup see <Bug:235565>
Setting event “10052” will avoid this as it prevents clean up of obj$.
Known Bugs:
Fixed In. Bug No. Description
7.1.5 Bug:235565 Views on Dicationary tables can cause ORA 600 16224
ORA-600 [17066] KGL Anonymous object list not empty
ORA-600 [17066]
Versions: 7.0.15 – 7.1.6
Source: kgh.c
Meaning:
KGL Anonymous object list not empty during KGL shutdown.
DIAGNOSIS FOR ORA-600[17066]
Solution Description:
The behavior of this error can be observed through the system state dump trace file. (This may also be in the trace file generated by the ORA-600 error.)
During shutdown all the Library object handles are released from memory and hence you should see all the BUCKETS in LIBRARY CACHE HASH TABLE empty (cleaned up.)
Here are some examples where the handles were not able to be released, and therefore returning the ora-600[17066] error. These are sections of trace files with library cache dumps.
Format:
in the BUCKET, we are looking at the line that starts with:
kk-dd-aa-ll=00-01-00-01 lock=.. pin=..
This line will show the handle that Oracle could not release.
Example 1:
Observe Bucket 3157: has a handle in which is pinned exclusive.
When shutting down the instance, all the BUCKETS supposed to contain nothing, but BUCKET 3157 handle is pinned (thinks in use) unable to clean up results in ora-600[17066] error.
BUCKET 3157:
LIBRARY OBJECT HANDLE: handle=4cfcc70
name=MPM_ERROR
hash=fa780e28
namespace=PIPE flags=RON/PN0/SML/[12010000]
kk-dd-aa-ll=00-01-00-01 lock=0 pin=X
lwt=4cfcc88[4cfcc88,4cfcc88] ltm=4cfcc90[4cfcc90,4cfcc90]
pwt=4cfcca0[4cfcca0,4cfcca0] ptm=4cfccf4[4cfccf4,4cfccf4]
ref=4cfcc78[4cfcc78,4cfcc78]
LIBRARY OBJECT: object=4cfca50
type=PIPE flags=EXS/NRC[0401] status=VALD load=0
DATA BLOCKS:
data# heap pointer status pins change
0 4cfe990 4cfcab0 I/P/A 0 NONE
BUCKET 3158:
Example 2:
Observe Bucket 713: has a handle in which the lock=? [ which is a invalid lock type.When shutting down the instance, all the BUCKETS supposed to contain nothing, but BUCKET 713 has a handle with invalid lock type ( NOT X, S, or N). unable to clean up, results in ora-600[17066] error.
BUCKET 713:
LIBRARY OBJECT HANDLE: handle=69f0da8
name=INV.MTL_TRANSACTIONS_INTERFACE
hash=e3ee231f timestamp=11-19-1994 09:50:39
namespace=TABL/PRCD flags=TIM/SML/[02000000]
kk-dd-aa-ll=00-00-00-00 lock=? pin=0
lwt=69f0dc0[69f0dc0,69f0dc0] ltm=69f0dc8[69f0dc8,69f0dc8]
pwt=69f0dd8[69f0dd8,69f0dd8] ptm=69f0e2c[69f0e2c,69f0e2c]
ref=69f0db0[69f0db0,69f0db0]
LOCK OWNERS:
lock user session count mode flags
69f0fa8 160002 f00 0 0 [00]
BUCKET 714:
References:
BUG-192548, BUG-183630
Known Bugs:
Fixed In. Bug No. Description
7.0.16 <Bug:166545> Error on shutdown.
ORA-600 [17090] Empty error stack when signalling error
ORA-600 [17090] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.3
Source: kg/kge.c
Meaning:
Oracle tried to resignal an error but the error stack in the PGA is empty ?
Explanation:
Basically we are trying to resignal an error in kgerse() but there appears to be no error stack.
Diagnosis:
– Is auditing being used ? See <Bug:207830>
– Check Stack trace If KKXEXE() at the top then see <Bug:234356>
– Is a remote DB involved ?
– Check if any Oracle EVENTS are set – unset them.
Known Bugs:
Fixed In. Bug No. Description
7.1.6 Bug:234356 PL/SQL blocks raise 17090 from kkxexe()
7.1.4 Bug:207830 Auditing INSERTs or DDL
Bugs Filed:
Bug No. Description Bug No. Dscription
261002 Fixed in 7.2.2 265315 ixed in 7.3
306313 Ongoing 296446 ixed in 7.3.2
302107 Ongoing 277709 Fixed in 7.2
290399 Ongoing 265892 Fixed in SQL*NET 1.1.1.16
245843 Fixed in 7.1.6 200344 Fixed in 7.1.3
231590 Fixed in 7.2 225034 Fixed in 7.1.5
207830 Fixed in 7.1.4 166504 Fixed in 7.0.15
ORA-600 [17114] KGH Bad magic number in header
ORA-600 [17114]
Versions: 7.0.15 – 7.1.6
Source: kgh.c
Meaning:
The header of a chunk of heap memory did not have the correct MAGIC NUMBER in the header.
Diagnosis:
Bounce the instance.
If 7.0 upgrade. Otherwise refer to
COMMON SOURCE OF HEAP CORRUPTIONS
Problem Description:
The definition of a heap is the section of memory where addresses are stored. These addresses can be interpreted as pointers to structures or other addresses. These addresses and pointers constantly change as needed during run time. A heap corruption occurs when the pointers or addresses get overwitten when they are not ready to be freed yet. When Oracle tries to read that part of the heap and encounters incorrect information errors will be signalled.
Usually this is an ORA-600 [17xxx] error.
Why would an address get overwritten before Oracle is ready to free it?
1. Some application will write to the address for some reason, losing the data already in it.
2. It is a bug.
Bug 236856 is a common source of session heap corruptions in RDBMS 7.0.16 to 7.1 before the problem was fixed in 7.1.5. The problem can manifest itself as memory overwrites where the last chunk before the overwrite was a part of the bind variable heap, or it may appear that kgh is attempting to free a chunk of memory that has already been freed.
Note that this problem can also cause memory corruptions in the parent heap of the session heap if the chunk of memory allocated to the bind variable heap is the last chunk in an extent of the session heap. This means that the parent heap of the session heap can be corrupted — normally the pga heap, or the sga heap in MTS mode. The most common occurence of this bug, however, is a session heap corruption.
The best way to classify that you have a heap corruption is by looking in the trace file. As mentioned above, heap corruptions usually return an ORA-600 error. The ORA-600 should generate a trace file. With that file, we can understand more about the corruption.
NOTE: Since we are dealing with memory and heap dumps, diagnosing the problem will be specific to each platform. Another factor to keep in mind is where in the code Oracle is encountering this corruption (this can be determined by the stack trace).
The following is an EXAMPLE trace file of a heap corruption so that you may recognize some of signs and understand heap corruptions more in general. To get a definitive resolution, please check the existing bugs or consult with a Senior Analyst.
Example 1 :
1. This is the first thing you will see in a heap trace file:
Fri Jun 30 07:03:23 1995
*** SESSION ID:(6.8008)
********** Internal heap ERROR 17112 addr=0xc0ca0338 *********
….
…..
2. Notice that the ERROR 17112 indicates the internal error and also the address that the error is occuring on.
3. From that information, we can look in the memory dump of the address.
4. Here is the format of the dump of this memory trace file:
address byte1 byte2 byte3 byte4 byte5 byte6 byte7 byte8
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678
The address shows where in the heap we are and the bytes are the data in the addresses. So, because the addr=0xc0c0a0338, we know that the heap corruption occurs between the addresses C0C0A320 and C0C0A340.
***** Dump of memory around addr 0xc0ca0338:
C0CA0120 0FFF0600 00000120
C0CA0140 C0F5FBB8 00000000 5C0000E8 00000000 00000000 000000D8 000C0000 0000008
….
…..
C0CA0320 00000000 00000000 00400000 02000000 00000742 00000000 00000000 00000000
C0CA0340 00000000 00000000 00000000 C11A7D38 4C0000A0 00000000 C11A7E98 000000A0
C0CA0360 000C0000 00000770 00000000 00000000 026E0301 00010300 00000000 C0CA0380
….
…..
5. The next thing to look for is the actual HEAP DUMP (which is usually after the memory dump) and where the chunk is c0ca0338.
Here is the format for this heap dump:
Chunk address size—— type of chunk “chunk content” internal info
HEAP DUMP heap name=”sga heap” desc=0xc0adb010
extent sz=0xfc8 alt=44 het=32767 rec=1 flg=2 opc=0
parent=0 owner=0 nex=0 xsz=0x1
EXTENT 0
Chunk c0ae4350 sz= 685968 perm “perm ” alo=685968
Chunk c0b8bae0 sz= 1240 freeable “sql area ” ds=c0d64958
….
…..
Chunk c0b8c900 sz= 352 freeable “sql area ” ds=c10b4ce8
Chunk c0b8ca60 sz= 568 freeable “library cache ” ds=c0da8c58
Chunk c0b8cc98 sz= 296 recreate “KGL handles ” latch=c0ae232c
Chunk c0b8cdc0 sz= 2104 recreate “PL/SQL MPCODE ” latch=c0ae23a8
….
…..
Chunk c0ca0230 sz= 264 recreate “library cache ” latch=c0ae232c
ds c0ca0478 sz= 3104
c0ecec40 sz= 568
c0bce178 sz= 568
c0c462d8 sz= 568
c1276620 sz= 568
c125e090 sz= 568
Chunk c0ca0338 sz= 0 ERROR, BAD MAGIC NUMBER (0)
Total heap size = 1818600
FREE LISTS:
….
…..
6. Notice that at that address, the size has been zeroed out and there is an ERROR, BAD MAGIC NUMBER (0).
Bugs Filed :
249498 Fixed in 7.1.6
163759 Fixed in PL/SQL 2.0.18
182024 Fixed in PL/SQL 1.0.10
175552 Fixed in 7.0.17
221563 Ongoing
207836 Fixed in 7.0.17
ORA-600 [17148] KGH Bad magic number (Recreatable chunk)
ORA-600 [17148]
Versions: 7.0.15 – 7.1.6
Source: kgh.c
Meaning:
The header of a chunk of RECREATABLE memory did not have the correct MAGIC NUMBER in the header.
Diagnosis:
Bounce the instance.
If 7.0 upgrade, otherwise: refer to COMMON SOURCE OF HEAP CORRUPTIONS in ORA-600 [17114]
BUGS FOR ORA-600[17148]
Solution Description:
Many bugs have been filed for this issue. For a comprehensive list and new bugs please check bug database.
The following is a list of bugs that have been confirmed by development and a
short explanation.
BUG#271669 workaround available Base bug#205399 RDBMS7.1.4 fixe 7.2.2
Symptom:
Receive an ora-600 [730] during shutdown.
The database starts up fine, but start to receive ora-600[17148] errors
Diagnosis & resolution:
It appears that the user attempted a shutdown, then when it failed, the user then attempted an ‘alter database close normal’ or another shutdown normal.
Since the old sga was still mapped, and much of the memory associated with various subsystems had been removed, this probably cause some problem
with memory, resulting in the [17148]. Please inform the user that after the space leak error, the proper thing to do is a shutdown abort. Once the customer gets the patch, this problem should go away.
BUG#254415 [17148] not coming after removing the _sql_connect_capability_code.
RDBMS 7.1.3.2 C
Symptom :
Setting the parameter _sql_connect_capability_code=7 generates [17148] if you have two databases one is V6 and other is V7.1.3 This parameter is specified in README.doc in V7.1.3.
Resolution :
_sql_connect_capability_code was added for compatibility between early V7 versions and 7.1. See bug 180903. This parameter is NOT for use with version 6.
Here is another instance where the [17148] occurs:
Symptom :
ora-600[730][64][space leak] and ora-600[17148][2178120720] when logging out
of a sessionThere are triggers on aud$.
Diagnosis :
1) they turn off auditing and create a table petrol.aud$ as select * from sys.aud$
2) they rename sys.aud$ to sys.aud$.old
3) as sys they create a synonym “aud$” that points to petrol.aud$
4) then they create an after update trigger on petrol.aud$ – the trigger checks
for a user logout and then gets the user’s statistics and inserts that info into another table
When he simulates a logout by updating the petrol.aud$ as sys – the trigger fires fine and there are no errors. However, when a user actually logs out and causes the trigger to fire they get an ora-600[729][..][space leak] error.
Resolution/workaround:
(1) Change the trigger to an ‘before update’ trigger instead of an after update trigger solved the problem.
BUG#250143 ORA-600[17148] IN RUNNING REMOTE PROCEDURE CALLS
RDBMS 7.1.3 – fixed in Generic BUG#249498 fixed in 7.1.6
MEMORY CORRUPTION: RPC OF PLSQL TABLE WITH CHAR/VARCHAR2/RAW ELEMENTS
BUG#242509 CREATE TRIGGER SCRIPT CAUSES INSTANCE TO CRASH RESULTING IN ORA-3113
Duplicate bug#222792 fixed in 7.1.3 Generic bug.
Symptoms:
Running SQL script to create the triggers:
– 1st attempt killed the instance
– subsequent attempts create some triggers, hangs on specific CREATE TRIGGER
statements. Customer waits ~10 minutes for one of the hanging statements
to complete before terminating.
When using Export written on Ultrix, Importing into OSF/1 machine, where both are running 7.0.16:
Multiple occurrences of ORA-600 [17148],[10482848] in the alert.log
Customer has to SHUTDOWN ABORT and restart.
Problem:
Bug 222792 allows you to create a trigger with a text that is a multiple of 1024, but it cannot be reloaded it later without getting the error. The important fact here is that during the creation of a new trigger, all other triggers that have been previously created on the same table are loaded.
The trigger causing the problem is not the one being created, but one that has been previously created on the table. The trigger that is actually causing the problem needs to be located. It is possible that the problem trigger will not cause a seg fault when dropped, but will only corrupt memory causing the next trigger loaded to fail.
ORA-600 [2103] Control File Enqueue Timeout
ORA-600 [2103] [a] [b] [c] [d] [e]
Versions: 7.0.12 – 7.1.4
Meaning:
Timeout on control file enqueue (15 minutes).
Argument Description:
a. Number of seconds that it timed out on (normally 900).
Diagnosis:
What operation was being performed. Eg: Drop tablespace or was this during normal operation.
a. Determine if async IO is in use in any form.
b. Determine if multiple DB writers in use.
>> If BOTH async and multiple DB writers back one out.
>> If just AsyncIO turn this OFF using the relevant init.ora parameter as this usually seems to occur with async IO.
>> If multiple DB writers back down to 1 db writer
Take care with this error. If the above are not true note that this error can arise on a very slow / hung system.
– Check OS error logs for ‘stuck’ OS writes or repeat writes
– Check if the whole system appears to be hung.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
7.0.12.1 Bug:187656 Too many open files.
? Bug:161165 Using db_writers > 1 on Sun4.
? Bug:180728 Using asynch I/O on AIX.
? Bug:169343 db_writers > 1 and drop tablespace.
ORA-600 [2130] Attempt to access non-existant control fileentry.
ORA-600 [2130] [a] [b] [c] [d] [e]
Versions: 7.0.15 – 7.1.x
Source: kcc.c
Meaning:
We were asked to get / update a non-existant entry in the controlfile.
Argument Description:
a. Entry number
b. Maximum entry in controlfile of this type
c. Type (See kcc.h)
KCCDEDBI 0 DB info entry
KCCDERTH 1 Redo thread
KCCDELOG 2 log file entries
KCCDEDBF 3 database file entries
KCCDENAM 4 names for files in the database
KCCDEARC 5 Locations of archived logs
d. [OPS only – mount id]
Diagnosis:
The error is actually a problem trying to read some information from the controlfile and can occur for a number of reasons.
Eg: block corruptions (bad chain dba) etc…
Chained row corruptions are likely to show as:
[2130] [FNO] [MAX] [3] with FNO>MAX (Ie: chained DBA points at non-existant file)
Make sure you check the stack trace for the error. This shows us what
we were doing when we tried to access the controlfile information.
Also locate the current SQL statement for a clue as to the operation being performed and any block dumps in the trace file.
Check any objects for block corruptions.
Eg: Use ANALYZE table VALIDATE STRUCTURE CASCADE and also see
Note:
It is possible for 2130 to be signalled while trying to dump information for some other internal error and thus hide the true error.
Eg: An ASSERT fails so Oracle dumps various diagnostics and 2130 gets signalled while dumping these diagnostics. The original error may never be seen.
Known Bugs:
Fixed In. Bug No. Description
Bug:200344 Corruption on chained row [2130][x][y][3].
Bug:215724 Analyze Table ESTIMATE stats (use COMPUTE instead)
ORA-600 [2256] Bad ADJUST_SCN value
ORA-600 [2256] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.4
Source: knl/kcm.c
Meaning:
You attempted to ADJUST_SCN but the level supplied would be less that the current SCN.
Argument Description:
a. Requested SCN WRAP
b. Requested SCN BASE
c. Current SCN WRAP
d. Current SCN BASE
Diagnosis:
If you really mean to adjust the SCN use a higher level.
Check that you do not have ADJUST_SCN still set.
ORA-600 [2657] Sync RBA > Current RBA – Help
ORA-600 [2657] [a] [b] [c] [d] [e]
Versions: 7.1.4 – 7.2.2
Source: kcrfw.c
Meaning:
The SYNC RBA is > the current RBA. This is impossible.
Detected when we ask to SYNC up to a specific RBA.
Argument Description:
a. RBA Sequence we want to Sync to
b. RBA Block we want to Sync to
c. Current LOG Sequence
d. Current LOG Base Block
e. Current LOG block being filled
f. Flag (kcrfh.h):
KCRFSFTOP 0x01 /* Thread OPen */
KCRFSFRGO 0x02 /* Redo Generation Ok */
KCRFSFBAD 0x04 /* single process died in BAD state flag. */
KCRFSFSAR 0x08 /* log switch for space Stuck on ARchiver */
KCRFSFRBA 0x10 /* RBA capture Ok */
KCRFSFSCL 0x20 /* log switch for space Stuck on CLearing */
Diagnosis:
This is pretty fatal. Can be related to latching / memory problems so check for other similar memory corruption type errors.
ORA-600 [2662] Block SCN is ahead of Current SCN
ORA-600 [2662] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.3
Source: kcrf.h MACRO
Meaning:
WARNING: There are 2 places this error could occur (in 7.0.16)
1 Argument:
If there is only 1 argument this is a problem generating an offline immediate log marker (kcrfwg).
*THIS IS NOT DOCUMENTED HERE*
4 + Arguments:
The SCN found on a block was ahead of the current SCN.
This is the more common occurance .
Argument Description:
a. Current SCN WRAP
b. Current SCN BASE
c. Blocks SCN WRAP
d. Blocks SCN BASE
e. Source of the SCN (not in 7.0.16)
Diagnosis:
– Once this has occurred you would normally want to rebuild the database via exp/rebuild/imp asthere is no guarantee that some other blocks are not ahead of time.
– Attempting a startup serveral times may bypass this if the SCNs in the error are very close as startup bumps the SCN even if open fails.
– If some recovery steps have just been performed review these steps as the mismatch may be due to open resetlogs with _allow_resetlogs_corruption enabled or similar.
– ** You can bump the SCN on open using <Event:ADJUST_SCN>
Be aware that you should really rebuild the DB if you use this option.
– If parallel server check both nodes are using the same lock manager instance & point at the same control files.
– If not Parallel Server check that 2 instances havent mounted the same database (Is there a second PMON process around ?? – shut down any other instances to be sure)
Known Bugs:
Fixed In. Bug No. Description
Bug:195115 Miscalculation of SCN on startup for distributed TX ?
ORA-600 [2740] Log file unavailable
ORA-600[2740][log#]
kcrf – Kernel Cache Redo File management component implementation.
Problem Description:
During an add log file operation in version 7.2, the kernel initializes the log header and adds the log to the control file. If for some reason the log file is unavailable to oracle, this error condition will exist.
In version 6.0 of the RDBMS, this error was returned when extending or adding a new chunk to the current redo log and it failed the validity check. It appeared multiple instances were running on the same database.
Bugs Filed:
205340 6.0.37.3.1
205341 6.0.37.3.1
Source Code: TBDL
SOLUTION TO ORA-600 [2740]
Solution Description:
The caller to this routine should have the log locked and it should exist. If the log gets deleted inadvertently, this error results. Make the redo log available.
ORA-600 [2845] Read of bad DBA Requested
ORA-600 [2845] [a] [b] [c] [d] [e]
Version: 7.1.3 – 7.1.6
Source: ./knl/kcf.c
Meaning:
When asked to read a block in kcfrbd() {foreground} either the file number or block number for the DBA was invalid.
Argument Description:
a. File number requested (should be >0 and <= MAX)
b. Maximum valid file number
c. Block number requested.
Diagnosis:
NOTE: If you did a manual block dump this error could be reported.
if the DBA requested in the blockdump was incorrect or mistyped.
Get the trace file. The stack should show what operations are in progress.
Determine the DBA causing the problem and:
Dump the DBA
Dump the segment header for the object (See to find the object name)
If segment freelist shows that the head=0 and the tail=some_dba
AND a parallel create/load has occurred on this object at some time in
the past see <Bug:251325>. The object will need rebuilding.
Otherwise see <Bug:226468>.
Known Bugs:
Fixed In. Bug No. Description
7.1.5 Bug:226468 CR problem
7.1.6 Bug:251325 Parallel create/load caused corruption
ORA-600 [2846] Block past end of file ?
ORA-600 [2846] [a] [b] [c] [d]
Versions: 7.1.3 – 7.1.4
Source: kcf.c
Meaning:
Request for a BLOCK which is beeyond the end of the data file.
Argument Description:
a. File number
b. Block number requested
c. Number of blocks requested
d. File Size in blocks
Diagnosis:
Using the ANALYZE command with ESTIMATE ?
– Use compute or upgrade to 7.1.6 or higher
ANALYZE TABLE VALIDATE STRUCTURE CASCADE for the table indicated in the CURRENT SQL statement.
ORA-600 [2854] Invalid Block Read Request
ORA-600 [2845] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: knl/kcf.c
Meaning:
Foreground process read was asked to read an invalid DBA.
Argument Description:
[a] = File Number asked for.
[b] = Max File Number allowed.
[c] = Block number asked for (Should be >1)
Diagnosis:
– This can be due to actual corruption of an index or table so:
analyze table <tname> validate structure cascade;
– Also check the table with a Full Table Scan of the table.
– If not a corruption see <Bug:226468> below.
Known Bugs:
Fixed In. Bug No. Description
Bug:226468 CR problem
ORA-600 [3020] Stuck Recovery
ORA-600 [3020] [a] [b] [c] [d] [e]
Versions: 7.0.X – 7.1.4
Source: knl/kcrp.c
Meaning:
Recovering database and REDO entry has an INC/SEQUENCE number greater than that on the database block by at least 2.
This is called ‘STUCK RECOVERY’.
Argument Description:
a. Block DBA
b. Redo Thread
c. Redo RBA Seq
d. Redo RBA Block No
e. Redo RBA File No.
Diagnosis:
– Has customer restored a backup, open the DB, closed the DB and then tried to recover without re-loading the backup ??
** If they say no GET THE ALERT LOG and prove it – it’s easy to waste a lot of time when this was the real cause.
– The quick option here is to restore and recover UP TO an SCN just before the problem. Customer will lose some data as this is an incomplete recovery so you need to know the priority:
a) TIME or b) Minimal Data Loss.
– Check the tracefile for the 3020 report. It is possible to signal OERI(3020) if the datafile block is corrupt.
Eg: OERI(3020) with Inc=0 Seq=1 reported for the disk block is possibly a zeroed out data-block on the datafile and NOT a redo issue.
– parallel server being used ?
If so another thread may have the required changes and they havent been read for some reason. Check for OS and DLM errors.
Try to make sure only ONE instance attempts any recovery by shutting down other instances.
– Are hot backups being used ??
Check that the backups are occuring correctly between BEGIN and END backup commands.
– You can try to skip the error using the hidden
parameter:CORRUPT_BLOCKS_ON_STUCK_RECOVERY
– For logging a bug you need:
-
Where an error is reported, get any trace files produced and relevant redo log dumps if necessary. Document completely the circumstances leading up to the error.
-
Provide a reproducible test case or dial-in information to development.
-
Where relevant, determine if generic or port-specific issue.
ORA-600 [3339] Corrupt Block Detected
ORA-600 [3339] [a] [b] [c] [d] [e] 72/134
Versions: 7.0.12 – 7.1.4
Meaning:
A corrupt block has been detected. The dba found in memory (which could have just been read from disk) does not match the DBA sought.
This could be due to either:
1. An on disk corruption OR
2. A corruption in memory after or during the block read from disk.
Argument Description:
a. This is the DBA found in the block itself (corrupt).
b. This is the DBA that we are searching for.
c. Trusted Oracle Only – the Trusted Database Address
Diagnosis:
– Calculate the File and Block number for the bad block
– Follow the block corruption steps
– NOTE: If there appears to be no segment with the DBA requested:
It could be a memory corruption
It could be a duff UBA in a block referencing a non existant DBA
– As OS dump of the block may be useful to determine if it looks like media OR memory.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
7.2 Bug:183357 Analyze table compute statistics.
7.1.2 Bug:186270 * Direct loader and hot backup – Query against loaded data.
7.0.17 Bug:179290 Enable constraints/analyze table..validate structure.
ORA-600 [3382] DBWR found an unexpected dirty block
ORA-600 [3382] [a] [b] [c] [d] [e]
Versions: 7.1.4 – 7.2.2
Source: kcbb.c
Meaning:
We are invalidating a range of blocks in the cache and found a block that was dirty ! It shouldnt be dirty as no-one should be using it.
Argument Description:
a. Pass through the invalidation loop
b. Low DBA of range being invalidated.
c. High DBA of range being invalidated
Diagnosis:
– Is the customer using TRUNCATE ? If so check if they are truncating the table that we get errors on, or one of its indexes etc..
Try to avoid truncate as there are numerous issues before 7.3.
– Is it occuring repeatedly ? and is it the same DBA range each time ?
– Get the file and block numbers for the DBA range and check what object they refer to:
SELECT segment_name , segment_type , owner , tablespace_nam
FROM sys.dba_extents
WHERE file_id = &bad_file_id
AND &bad_block_id BETWEEN block_id and block_id+blocks-1
– Check for overlapping extents. See
Known Issues:
Fixed In. Bug No. Description
7.3 Bug:146216 Possible errors from Truncate.
ORA-600 [3398] Corrupt block detected by DBWR on before WRITE
ORA-600 [3398] [a] [b] [c] [d] [e] [f]
Versions: 7.0.12 – 7.1.4
Meaning:
We are about to flush a dirty block to disk but the block is considered corrupt so we therefore give this error and exit before completing the flush. The things that are checked are the cached block’s DBA, version and incarnation against what we think they should be.
This basically implies the block was corrupted in memory as we should have detected an error on read otherwise.
Argument Description:
a. DBA expected.
b. DBA found.
c. Version number of cached block. (Should equal 1)
d. The last 4 bytes of the block (Should match INC#SEQ# low order bytes)
e. Incarnation of cached block.
f. Sequence no of the cached block.
Diagnosis:
Very difficult as it is likely due to an overwrite from an adjacent write to the SGA or is due to some memory corruption.
The saving grace is that the block will NOT have been written to disk.
Bouncing the database several times may help show if this is a hardware problem.
Also try resizing the SGA (especially try to fit it into a single shared memory segment to rule out any multi-segment problems).
If the problem is on STARTUP then setting the event 10210 (and 10211) can avoid these errors being reported as the DATA layer will then soft corrupt the block thus rebuilding it.
This may allow you to at least get a DB open.
Alternatively for startup:
– identify the file ID of the file with the bad block
– Mount the database and get the filename from v$datafile
– You can try offlining the file. Obviously it depends what the DBA object is and what else is in this TABLESPACE but you may be able to avoid the problem this way.
3398 can often be caused by redo or undo corrupting the block in memory as it is applied. If this is suspected another option is to restore a backup and roll forward to before the corruption occurs.
ORA-600 [4146] Undo Block not new enough
ORA-600 [4146] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: ktur.c
Meaning:
Block not new enough (Undo)
Argument Description:
a. UBA Sequence expected ?
b. Sequence on the Undo block header ?
Diagnosis:
Basically a corruption.
How to find the segment causing an ora-600 [4146] / [4147]
1. In the trace file find the characters: uba (undo block address) which will give the fileid and blockid of the uba with the problem.
After this will be a number. The number will either be in decimal or
2. Then run the following query:
SELECT segment_name,segment_type
FROM sys.dba_extents
WHERE file_id = <fileid>
and <blockid> between block_id and block_id + blocks – 1
eg.
SELECT segment_name,segment_type
FROM sys.dba_extents
WHERE file_id = 2
and 1450 between block_id and block_id + blocks – 1
This should return one row. If not then recheck the above.
Example output from the trace file
—————————————–
Dump file /usr/oracle/rdbms/log/22_24397.trc
ORACLE RDBMS V6.0.37.3.1 transaction processing option – Production
ORACLE_HOME = /usr/oracle
ORACLE_SID = gsm01
Oracle process number: 22 Unix process if:24397
System name: HP-UX
Node name: hydrogen
Release: A.09.01
Version: A
Machine: 9000/755
Dump of buffer cache at level 2
BH #5837 (0x802fb030) dba: 500006eb class 14 ba:81112c00
…..
Call Stack Trace
…..
at end of trace
BH #755 (0x802573c8) dba: 80000003 class 1 ba: 80725c00
hash: [80340024,8038c3c4], lru: [802912e8,8033657c]
use: [803886a0,803886a0], wait: [NULL]
st: CR, md: EXCL, rsop: 0
cr:[[scn: 0.00dbbeab],[xid:07.1b.5849],[uba: 500004e6.206a.02], sfl: 1
flags: buffer_dirty_only_sequential_access
L:[0.0.0] H:[0.0.0] R:[0.0.0]
Using State Objects
In this example, uba address is: 500004e6 which translates to:
file_id=20, block_id=1254
undo segment # = 07
3. If this does not return any rows, then one can dump the rollback segment
header which will show the extent map to determine the whether the query should have returned any rows.
To dump the rollback segment header.
1. Before the uba: there should be the characters xid:
eg. xid: 07.xx.xxxxx uba:
For the first number after xid: this is the undo segment # which is giving the problem.
To find the undo segment
select * from sys.undo$ where id# = <undo segment #>
eg. select * from sys.undo$ where id# = 7;
This will return one row. Find the values in the columns
file_id = <ff>
block_id = <bbbbb>
These are in decimal. Change to hex and use to dump the rollback segment header.
>From sqlplus:
alter session set events ‘immediate trace name blockdump level <nnnnnnnn>
This will produce a trace file in user_dump_dest which will show the extent map for the rollback segment.
Can be caused by:
a) A lost write – Get OS / hardware checked
or b) Database has been forced open
Eg: _allow_resetlogs_corruption used.
ORA-600 [4147] Undo Block not new enough
ORA-600 [4147] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: ktur.c
Meaning:
Block not new enough (Undo). Sequences match but count wrong.
Argument Description:
a. Count expected ?
b. Count on the Undo block header ?
Diagnosis:
Basically a corruption.
How to find the segment causing an ora-600 [4146] / [4147]
same as ora-600[4146]
ORA-600 [4306] Duplicate row in fet$/uet$ dropping Temp Segment
ORA-600 [4306] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: kts.c
Meaning:
Duplicate row in fet$/uet$ when dropping a Temp Segment.
Argument Description:
a. File Number of duplicate entry
b. Block Number of duplicate entry
Diagnosis:
Use event 10061 to get around – See bug (search on 4302/10061)
Check fet$/uet$ using:
select * from fet$
where file#=n
and b between block# and block# +length -1
/
Select * from uet$
where file#=n
and b between block# and block# +length -1
/
If no rows in uet$ (can widen search for just file#=n) then just try straight startup if none found.
If both entries found then recreate the TEMP tspace.
ORA-600 [4310] Bad Starting Extent
ORA-600 [4310] [a] [b] [c] [d] [e]
Versions: 7.X.X – 7.2.2
Source: kts.c(ktslex)
Meaning:
When retrieving details of the extents within a segment the number of the starting extent was greater than the total number of extents.
Argument Description:
a. Starting extent returned
b. Number of extents
Diagnosis:
Can arise when selecting from a truncated table.
The error is likely to be a one off as there is a small window where the problem can occur.
Known Bugs:
Fixed In. Bug No. Description
7.3 Bug:146216 Truncate & set transaction read only Errors.
7.3 Bug:270684 Changes to ROWID verification
ORA-600 [4414] Error popping Errorstack Savepoint
ORA-600 [4414] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.3
Source: include/ktc.h
Meaning:
We went to pop an errorstack savepoint but there was no savepoint
NOTE: This could occur in many places in the code whereever the the macro ‘ktcpos()’ is used.
Argument Description:
a. Old error
b. Old level
c. Current error ?
d. Current level ?
Diagnosis:
– Check in the trace file for ORA 1092 or a similar shutdown message.
If this is the case then this is probably <Bug:177032> and this
error is not the CAUSE of a problem but is the result of either:
– a) A shutdown immediate / abort being issued manually
– b) A DB crash caused by some other problem – so look for other trace information.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
7.2 Bug:177032 ORA 600 4414 Signalled during shutdown.
ORA-600 [4421] Rollback but no transaction control block
ORA-600[4421][N]
ktc – Kernel Transaction Control
Problem Description:
Generally, this error occurs while aborting a transaction with a ^C while auditing is turned on. A system state dump will accompany this error under these circumstances.
Problem Explanation:
This error occured on a number of platforms predominately in RDBMS version 6.0.XX. Initial indicators point to the rollback segments in many logged situations. A DML operation (insert) will trigger this error when interrupted abnormally (^C).
Bugs Filed:
85073 6.0.34
135883 6.0.34
78013 6.0.33
Source Code: TBDL
ORA-600 [4502] ITL lock count doesnt tally with rows.
ORA-600 [4502] [a]
Versions: 7.0.16 – 7.2.2
Source: ktb.c
Meaning:
During ITL cleanout we clear all row locks but the ITL entry still thinks there is an uncleared lock.
Ie: ITL has a locked row but there are no locked rows in the block ?
Argument Description:
a. ITL entry with a lock count
Diagnosis:
Raised in ktbrcl() – ITL cleanout redo routine.
– There should be a current mode buffer pinned in the processstate dump with the error.
See the ITL section of .
Confirm the pinnd block is incorrect and then note:
1) the bad DBA
2) the problem object id.
– Current block is corrupt so check if the problem is repeatable (FTS on the table)
Bottom line: Get onto 7.1.6 or higher. Prior to this any of:
Adding Longs to existing table ?
Trailing nulls ?
RBS extension problems (minextents!=maxextents)
Bugs Filed:
Fixed In. Bug No. Description
7.1.3 Bug:198383 Corruptions during cleanout of MRP.
7.1.4 Bug:208665 Problems with trailing nulls.
Eg: fb: KCHDFLPN lb: 0xff in buffer dump.
7.2.3 Bug:282541 7.2 Bad UNDO for “Move Row Piece” ops. Possibly??
ORA-600 [4519] Clock Corruption Detected – Cache type wrong
ORA-600 [4519] [a] [b] [c] [d] [e]
Version: 7.0.12 – 7.1.4
Source: KTR.C
Meaning:
We found a corrupted block when trying to read a block using consistent read. An invalid block type was found (we were looking for one with type K_BTTRDA [6 – managed data block] but found one with type as indicated in argument ‘b’).
Argument Description:
a. DBA of the corrupt block.
b. Block type found.
Diagnosis:
These can be in memory corruptions so bouncing the database may be a good initial step, and set events as below to trap the errors. After restarting dump/select from one of the dba’s returned from 4519 just to make sure it is OK on disk.
Work out the object and perform an FTS and scan via any relevant index to see if the error repeats. Failing indexes may be rebuilt.
a. Use db_block_cache_protect parameter if available on the port.
b. Use archivelogmode to help to see when corruption occurs.
c. Use the event 10200 to show blocks obtained by consistent read.
New event 10208 ??? (Introduced later for ktrget() bug).
d.Enable data/index block checking using events 10210 andd 10211.
e.Use event 10288 to skip this check (block type) on the block.
(NOT RECOMMENDED)
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
? Bug:185395 Alter table add constraint on NCR.
7.2 Bug:183357 Using analyze table using 7.1. (Bugged under 7.0.13).
7.0.15 Bug:161236 Updating a table under specific conditions.
ORA-600 [504] Trying to obtain a latch which is already held
ORA-600 [504] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: KSL.C
Meaning:
We are checking if a latch is already held at this level or higher and trying to attain the latch. We have been told by the calling process to continue to get the latch, (and we are in cleanup ?).
Argument Description:
a. Address(?) of latch we are trying to lock.
b. Level of latch we have currently got.
This is a bit array of 1-16. Latches only used (according to comments in ksl.h) from 1-9. Therefore, convert this decimal number to binary to find the latches currdenty owned.
c. Level of latch we are trying to obtain ?
d. Description of the lock/latch we are attempting to attain.
Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)
Fixed In. Bug No. Description
? Bug:182130 On startup. [row cache objects].
7.0.13 Bug:179115 NCR create indexes. [lock element parent latch].
7.0.15 Bug:177900 P.Server: PMON gives [504] for row cache latch.
– Bug:179850 Dumping using systemstate. [lock element parent latch].
? Bug:172589 While dumping using alter session/event.
7.0.17 Bug:177818 When dropping user. [lock element parent latch].
ORA-600 [510] Latching Problem
ORA-600[510][latch_addr][child_latch][]
ksl.c – Kernel Service layer Latching & Wait-post Implementation
Problem Description:
This error indicates a call was made to free a child latch that is unowned.
Problem Explanation:
The second argument indicates the address of the latch in question. The third argument indicates the type of child latch that the kernel attempted to free.
Call Stack Trace:
SP PC Name
0x7ff779c8 0x0051de4c sdtcs(a0=0x0) = 0x51dda8 + 0xa4
0x7ff77d48 0x004f9598 ssexhd(a0=0x4) = 0x4f94ec + 0xac
0x7ff77d68 0x6fc1f110 <unknown> — nearest symbol is sigsetjmp(, a2=0x7ff77da04
0x7ff77d90 0x3102b0f8 () = 0x0 + 0x3102b0f8
Unable to continue due to an illegal address (0x2ffffffc).
Other Information:
Other platform specific init.ora parameters to consider are:
_latch_spin_count
_latch_wait_posting
_max_sleep_holding_latch
_db_block_multiple_hashchain_latches
if they are default values – you may want to vary the values.
Known Bugs:
Bug Version Platform Status
329487 7.3.1.0.0 HP/UX HP 98XX series 7.3.2
315721 7.1.4 Sequent DYNIX/ptx 91
305330 7.1.4.1.1 Silicon Graphics Unix 90
296257 7.0.15 Pyramid DC/OSx MIPS Unix 91
Source Code: TBDL
SOLUTION TO ORA-600 [510]
Solution Description:
If this error is reproducible, or if there is a slowdown period where you can query some of the dynamic performance tables (V$) it will be worthwhile to run the following query:
Select count(*) number_of_waiters
from v$session_wait w, v$latch l
where w.wait_time = 0
and w.event = ‘latch free’
and w.p2 = l.latch#
and l.name like ‘library%’;
If you have more than 2 processes waiting for the library cache or library cache pin latch then this could be the problem. Dumping the system state periodically will also reveal helpful information with respect to time:
alter session set events ‘immediate trace name systemstate level 10’;
It is also very useful to just select from v$session_wait to determine what else is causing slowdown:
select * from v$session_wait
where event != ‘client message’
and event not like ‘%NET%’
and wait_time = 0
and sid > 5;
Solution Explanation:
There are numerous bulletins on how to extract data froming a hanging database.
Selecting from v$latch will show you which latches have the worst hit rates and more importantly which latches are causing a lot of sleeps. If the library cache latch is causing the most number of sleeps then you may have a problem. One thing to watch out for here is that this information is accumulated since the database starts, and so it may not show problems that are intermittent in nature.
ORA-600 [512] Latching Problem
ORA-600[512][][][]
ksl.c – Kernel Service layer Latching & Wait-post Implementation
Problem Description:
This error indicates an Operating System Dependent (OSD) free latch routine returned an error.
Generally this error is accompanied by another error (sometimes ORA-600[510] (trying to free an unowned child latch)).
Problem Explanation:
Usually a background process or user process will die with the occurance of this error. Note that it is Operating System Dependent and usually will be handled differently depending upon the platform.
Other Information:
Other platform specific init.ora parameters to consider are:
_latch_spin_count
_latch_wait_posting
_max_sleep_holding_latch
_db_block_multiple_hashchain_latches
if they are default values – you may want to vary the values.
Known Bugs:
Bug Version Platform Status
291773 7.0.16.6.2 Siemens-Nixdorf RM-400 91
198261 7.0.15.4 HP 98xx HP/UX 91
268553 7.0.16.4.0 DG AViiON 30
Source Code: TBDL
SOLUTION TO ORA-600 [512]
Solution Description:
Gather all necessary information from the alert log, trace files and dumps.
If this error is reproducible, or if there is a slowdown period where you can query some of the dynamic performance tables (V$) it will be worthwhile to run the following query:
select count(*) number_of_waiters
from v$session_wait w, v$latch l
where w.wait_time = 0
and w.event = ‘latch free’
and w.p2 = l.latch#
and l.name like ‘library%’;
If you have more than 2 processes waiting for the library cache or library cache pin latch then this could be the problem. Dumping the system state periodically will also reveal helpful information with respect to time:
alter session set events ‘immediate trace name systemstate level 10’;
It is also very useful to just select from v$session_wait to determine what
else is causing a slowdown:
select * from v$session_wait
where event != ‘client message’
and event not like ‘%NET%’
and wait_time = 0
and sid > 5;
Solution Explanation:
There are numerous bulletins on how to extract data froming a hanging database.
Selecting from v$latch will show you which latches have the worst hit rates and more importantly which latches are causing a lot of sleeps. If the library cache latch is causing the most number of sleeps then you may have a problem. One thing to watch out for here is that this information is
accumulated since the database starts, and so it may not show problems that are intermittent in nature.
ORA-600 [6008] Invalid Opcode operating on Index Block/Key
ORA-00600[6008][N]
kdi – Kernel Data layer Index component
Problem Description:
An invalid opcode is encountered while operating on an index block or key.
Problem Explanation:
This error has been logged multiple times on version 6 of the RDBMS. It is generally accompanied by some form of corruption (ora-600[3398]). This section of the code has not changed from version 6 to 7.2.2. It is a default case condition for a switch that should never occur. The second argument is the evaluated result of the switch vector.
Could be as a result of kernel cache buffer corruption causing the switch to traverse the default condition. Other Known Bugs:have included ORA-1578 which indicates data block corruption. All Known Bugs:logged have been non-reproducible.
Known Bugs:
173919 Sun4 Could not reproduce.
147224 OS/2 Closed, not a bug.
Solution Description:
Rebuilding the objects involved is the best insurance for object integrity.
This error condition is infrequent and has not been reproducible. Much speculation on how this error occurs but little has been proven. This error is more passive and does not crash the instance.
Note that some form of corruption usually accompanied these errors in the bug reports. Either buffer cache or block corruption possibly has contributed to this error. Block checking could also aid in the prevention of this error.
Other Information:
Turn on block checking in init.ora:
(_)DB_BLOCK_CACHE_PROTECT=TRUE.
Workaround(s):
The workaround is to analyze the table (index) associated with the error.
Based on the results of the analyze, rebuild the objects necessary:
Determine which table is involved with the error.
Alert logs and trace files assist in this determination.
Analyze the objects involved:
ANALYZE TABLE tblname VALIDATE STRUCTURE CASCADE (table and index)
ANALYZE INDEX idxname VALIDATE STRUCTURE (index only)
Rebuild index / table.
Procedure:
Drop table.
Drop index.
Import table.
Create index.
ORA-600 [6009] Problem with Index ITL slot.
ORA-600 [6009] [a] [b] [c] [d] [e]
Versions: 7.0.15 – 7.1.6
Source: kdi.c
Meaning:
On a purge hole (kdipurgeshole) from an index a service transaction had problems getting the service ITL.
Argument Description:
a. itl space
Diagnosis:
This can be from a corrupt index or a CR issue.
First step is to:
ANALYZE TABLE XXX VALIDATE STRUCTURE CASCADE;
If this succeeds (statement processed) it is probably a CR issue.
Otherwise treat it as a corruption. See the trace file produced by the ANALYZE command.
Additional Notes:
kdipurgeshole() purges all committed split holes (rows marked deleted and split) from the argument leaf block. The purge is done within a newly created service transaction.
Known Bugs:
Fixed In. Bug No. Description
<Bug:190929> 600 6009 CR problem.
ORA-600 [6590] Block corruption
ORA-600 [6590] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.X.X
Source: kdo.c
Meaning:
If block checking is on we have found a corrupt block.
Argument Description:
a. Check number indicates corruption found.
Diagnosis:
The block should be dumped to trace with:
redo record, before-image, and after image
Check [a] for the type of corruption (kdb.h):
KDBCHKOK 0 /* block ok */
KDBCHKNE 1 /* row locked by non-existent transaction */
KDBCHKRB 2 /* row begins beyond end of block */
KDBCHKRE 3 /* row ends beyond end of block */
KDBCHKRM 4 /* row begins in the middle of another */
KDBCHKRA 5 /* row ends in the middle of another */
KDBCHKFN 6 /* free list not ordered */
KDBCHKFS 7 /* free slots not on the free list */
KDBCHKXM 8 /* xaction header lock count mismatch */
KDBCHKBX 9 /* bogus transaction locks present */
KDBCHKSU 10 /* space used is not equal to block size */
KDBCHKSC 11 /* space available on commit is incorrect */
KDBCHKKT 12 /* Key in Table other than zero */
KDBCHKCT 13 /* Cluster row in table zero */
KDBCHKKR 14 /* Key reference count incorrect */
KDBCHKFB 15 /* row Forwards to same Block */
KDBCHKBB 16 /* row has Backward reference to same Block */
KDBCHKFC 17 /* Free list beyond row Count in block */
KDBCHKNR 18 /* Negative current Reference count on key */
KDBCHKCL 19 /* Current refs Less than com refs */
KDBCHKNC 20 /* Negative Com reference count on key */
KDBCHKCW 21 /* Com reference count on key Wrong */
KDBCHKFW 22 /* Flush flag wrong */
KDBCHKLI 23 /* row Length Inconsistency */
KDBCHKTO 24 /* Table Offset incorrect */
KDBCHKRC 25 /* Row Count in table index incorrect */
KDBCHKAB 26 /* Available space count Bad */
KDBCHKTB 27 /* Total space count Bad */
KDBCHKAT 28 /* Available space greater than Total */
KDBCHKFO 29 /* Free Space beginning Offset bad */
KDBCHKFE 30 /* Free space Ending offset bad */
KDBCHKKL 31 /* Key Links bad */
KDBCHKTN 32 /* Trailing Null column stored */
KDBCHKBS 33 /* Bad Stub size (will not forward properly) */
KDBCHKUL 34 /* Undo for piece will be too Large */
KDBCHKRO 35 /* Row Offset is not between kdbhfseo and ktbidl */
KDBCHKKI 36 /* Key locking Itl is not KTBSRVI */
KDBCHKIS 37 /* Illegal Service transaction */
KDBCHKTK 38 /* Too many (> KDRMAXCK) cluster keys in block */
KDBCHKDK 39 /* Duplicate cluster Keys in block */
KDBCHKNK 40 /* Non-existent Key referenced */
KDBCHKBC 41 /* Bad Clustering; HF, and not C */
KDBCHKCS 42 /* bad Cleanout System commit number */
KDBCHKFF 43 /* fixed hash area block on freelist */
KDBCHKMK 44 /* hash and cluster keys mixed */
KDBCHKBR 1000 /* KDBCHKBR+kdrchk error code */
ORA-600 [729] UGA Space Leak
ORA-600 [729] [a] [b] [c] [d] [e]
Versions: 7.1.3 – 7.1.6
Source: ./knl/ksm.c
Meaning:
A space (memory) leak has been detected in the UGA
Argument Description:
a. This is the number of bytes leaked
Diagnosis:
NOTE: There is NO data corruption as a result of this error.
It is purely an internal memory housekeeping problem.
Obtain the trace file as this should show the heap dump which helps show what the leaked space belonged to. This leak error is raised at logoff time.
To see the leak look at the owner of the ‘freeable’ chunks of memory. The sum of these ‘freeable’chunks should be the same as the total leak reported in the error.
If the dump shows ‘loader’ chunks and the word ‘kcllqr’ it is a leak from SQL*Loader. See <Bug:214529> below. If using direct path load try conventional path loads.
Look in TecRep for the name of the freeable chunk.
Eg: Chunk 6ef7f8 sz=136 freeable “evauct “so query TecRep for ‘evauct’.
Event < OERR:10262> can be used to set a maximum size of memory to leak before an error is raised.Typically this is not very useful for this error as the leaked space can be very large and it is not a good idea to hide large memory leaks.
Ramifications of large leaks:
If NOT using MTS the UGA is in the PGA and this is freed when the process exits so there is no real problem.
If you are using MTS the UGA is in the SGA and so the leak is bad news.
Articles:
<Event:10262> Minimum memory leak to allow.
Known Bugs:
Fixed In. Bug No. Description
7.1.6 Bug:214529 SQL*Loader leaks memory (ORA 600 729)
7.3.1 Bug:279593 Replication leak if destination crashes.
ORA-600 [730] SGA Space Leak on Shutdown
ORA-600 [730] [a] [b] [c] [d] [e]
Versions: 7.1.3 – 7.1.6
Source: knl/ksm.c
Meaning:
SGA is checked for Space leaks at shutdown time and a leak was found.
Argument Description:
a. Number of leaked bytes
b. “space leak” description of the error
Diagnosis:
If this occured on shutdown and the third argument is “space leak” this is most likely <Bug:205399>. This is not definite though as a space leak could be caused almost anywhere. The full trace file will show what TYPE the unfreed segment was.
Basically on shutdown we free everything in the SGA and then see if there is anything left. If there is we report this error.
<Bug:205399> is a very common cause of this – if a patch for this doesnt cure things then we need to see the trace file.
To diagnose this properly you need the trace file and look at the LABEL next to the unfreed items. This shows who owned the unfreed chunks.
Work Around:
Interestingly in 7.1.3 if event 10262 is set to a number (of bytes) then checking will only report leaks of a size above the event level.
This has been tested (thanks Jim) and works fine. If you choose a sensible maximum leakage, say about 2000 bytes, then this could save sending out a patch.
Eg: In init.ora add:
event=”10262 trace name context forever, level 2000″
Note that 10262 also affects UGA and PGA leak checking.
Known Bugs:
Fixed In. Bug No. Description
7.2 <Bug:205399> SGA leak due to SORT chunks
<Bug:317895> KEPT KGL Handles leak
7.3.2 <Bug:317231> General KGL Handles leak
ORA-600 [9] Bad Date Representation
ORA-600 [9] [a] [b] [c] [d] [e]
Versions: 7.0.16 – 7.1.6
Diagnosis:
Generally there is either an invalid date already in the database or there is a problem performing a conversion.
The stored data for dates can be found with:
select DUMP(date_column) from table where …
Use ‘oranum’ to see if the stored value is garbage.
It is possible to store bad dates using OCI or PLSQL. See <Bug:228296>
Known Bugs:
Fixed In. Bug No. Description
7.2.2 <Bug:175254> Invalid DATE inserted via PL/SQL, ORA 600 [9] upon Fetch
7.2.2 <Bug:247871> Calls to ‘Char’ functions with a bad DATE
Hello there,
My name is Aly and I would like to know if you would have any interest to have your website here at epac.to promoted as a resource on our blog alychidesign.com ?
We are in the midst of updating our broken link resources to include current and up to date resources for our readers. Our resource links are manually approved allowing us to mark a link as a do-follow link as well
.
If you may be interested please in being included as a resource on our blog, please let me know.
Thanks,
Aly
Hello there,
My name is George, and I was wondering if you would like to have your website epac.to promoted as a resource on my blog georgemartjr.com ?
We are updating our broken link resources to include up to date resources for our readers. Our resource links are manually approved as a do follow link.
If you are interested in having your site included as a resource on our blog, please let me know.
Thanks for your consideration,
George