ORA 600 정리


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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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.

= 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] [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:

  1. 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.
  2. Provide a reproducible test case or dial-in information to development.
  3. Where relevant, determine if generic or port-specific issue.

ORA-600 [3339]    Corrupt Block Detected

ORA-600 [3339] [a] [b] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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


Comments

comments

haisins

오라클 DBA 박용석 입니다. haisins@gmail.com 으로 문의 주세요.

ORA 600 정리”의 2개의 댓글

  • 2018-11-18 1:49 오전
    Permalink

    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

    댓글달기
  • 2019-03-05 3:21 오전
    Permalink

    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

    댓글달기

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다