{"id":3610,"date":"2018-03-19T09:53:16","date_gmt":"2018-03-19T00:53:16","guid":{"rendered":"http:\/\/haisins.epac.to\/wordpress\/?p=3610"},"modified":"2018-03-19T09:53:16","modified_gmt":"2018-03-19T00:53:16","slug":"ora-600-%ec%a0%95%eb%a6%ac","status":"publish","type":"post","link":"http:\/\/haisins.synology.me\/wordpress\/?p=3610","title":{"rendered":"ORA 600 \uc815\ub9ac"},"content":{"rendered":"

ORA-600 [1113]\u00a0\u00a0\u00a0\u00a0State object being moved to freelist already free
\n<\/strong><\/span><\/p>\n

ORA-600[1113][]<\/p>\n

kss – Kernel Service State object manager.<\/p>\n

Problem Description:<\/p>\n

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.<\/p>\n

Call Stack Trace:<\/p>\n

location\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 arg values
\n<\/span><\/p>\n

_ksedmp+136\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x0 0x5f4000 0x4e 0x34 0x4a7778 0x0<\/p>\n

_ksfdmp+24\u00a0\u00a0\u00a0\u00a0_ksedmp \u00a0\u00a0\u00a0\u00a00x3 0x5f4000 0x0 0x2 0x0 0x0<\/p>\n

_kgeriv+220 \u00a0\u00a0\u00a0\u00a0_ksfdmp \u00a0\u00a0\u00a0\u00a00x5f33a4 0x3 0x258 0x4a72c0 0x114b 0x0<\/p>\n

_kgeasi+76\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_kgeriv\u00a0\u00a0\u00a0\u00a00x5f33a4 0x258 0x114b 0x0 0xefffe488 0x5f3408<\/p>\n

_ktcrsp+856 \u00a0\u00a0\u00a0\u00a0_kgeasi \u00a0\u00a0\u00a0\u00a00x5f33a4 0x60365c 0x114b 0x2 0x0 0xaf<\/p>\n

_ksuxds+1228 \u00a0\u00a0\u00a0\u00a0_ktcrsp\u00a0\u00a0\u00a0\u00a00xe0032924 0x0 0xe003290c 0x7fffffff 0xe006a508 0x4<\/p>\n

_ksudel+8\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_ksuxds \u00a0\u00a0\u00a0\u00a00xe0024658 0x2 0xe0024658 0x1 0xe001dea8 0xe0004904<\/p>\n

_ksudls+928 \u00a0\u00a0\u00a0\u00a0_ksudel\u00a0\u00a0\u00a0\u00a00xe0024658 0x2 0xe001dea8 0x0 0x5f3408 0xefffe7ec<\/p>\n

_opises+420 \u00a0\u00a0\u00a0\u00a0_ksudls \u00a0\u00a0\u00a0\u00a00x0 0xe0024658 0xefffe6a4 0x1 0xefffe6a4 0x60f938<\/p>\n

_opiodr+3936\u00a0\u00a0\u00a0\u00a0_opies\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x1 0x7 0xeffff7a0 0x811f8 0x0 0x1<\/p>\n

_ttcpip+4784\u00a0\u00a0\u00a0\u00a0_opiodr\u00a0\u00a0\u00a0\u00a00x5f5400 0x5f5400 0x811f8 0xd87d0 0x811f8 0x8bb50<\/p>\n

_opitsk+1536\u00a0\u00a0\u00a0\u00a0_ttcpip\u00a0\u00a0\u00a0\u00a00x5f4b9c 0xefffecec 0x1a 0xefffecec 0x4 0x7<\/p>\n

_opiino+1380\u00a0\u00a0\u00a0\u00a0_opitsk\u00a0\u00a0\u00a0\u00a00x5f4ba0 0x0 0x0 0xa 0x0 0x5f4b9c<\/p>\n

_opiodr+3936\u00a0\u00a0\u00a0\u00a0_opiino\u00a0\u00a0\u00a0\u00a00xeffffefc 0x5f4b9c 0x2811 0xeffffefc 0xeffffaac 00<\/p>\n

_opidrv+1348\u00a0\u00a0\u00a0\u00a0_opiodr\u00a0\u00a0\u00a0\u00a00x5f5400 0x5f5400 0x81078 0xe0cd0 0x81078 0x8baf0<\/p>\n

_sou2o+16\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_opidrv\u00a0\u00a0\u00a0\u00a00x3c 0x5f3408 0x0 0x5f3408 0x1 0xeffffd40<\/p>\n

_main+148\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_sou2o\u00a0\u00a0\u00a0\u00a00xefffff0c 0x3c 0x4 0xeffffefc 0x3 0x0<\/p>\n

start+68\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_main\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x2 0x0 0xefffff98 0x5de400 0x0 0x0<\/p>\n

Other Information:<\/p>\n

This problem was caused by the kernel not resetting the current transaction when a new session was created via upiscr().<\/p>\n

Source Code:\u00a0\u00a0\u00a0\u00a0TBDL<\/p>\n

SOLUTION TO ORA-600 [1113]
\n<\/strong><\/p>\n

ORA-00600 [1113]<\/p>\n

Oracle, while removing a state object to the freelist, discovers that the object is already marked as being on the freelist (bit(so->kssobflg,\u00a0\u00a0\u00a0\u00a0KSSOFLST)), and so dumps the state object and system state dump and logs ORA-00600 [1113].<\/p>\n

If you experience this problem, collect the relevant trace and alert log files and contact Worldwide Customer Support<\/p>\n

Bugs Filed:<\/p>\n

168822 fixed at release 7.0.13.1.<\/p>\n

184652 fixed (by rewrite) at 7.3.\u00a0\u00a0\u00a0\u00a0Associated with dropping sequences.<\/p>\n

169822 specific to DEC Alpha VMS.\u00a0\u00a0\u00a0\u00a0Similar to 168822.\u00a0\u00a0\u00a0\u00a0Fixed at 7.0.13.1.<\/p>\n

128961 fixed in 6.0.36.0.1<\/p>\n

130548 fixed in 6.0.36.5<\/p>\n

ORA-600 [1114]\u00a0\u00a0\u00a0\u00a0State Object parent links uninitialized
\n<\/strong><\/span><\/p>\n

ORA-600[1114][]<\/p>\n

kss – Kernel Service State object manager<\/p>\n

Problem Description:<\/p>\n

This error occurs when adding an object from the freelist and the parent object links have not been initialized.<\/p>\n

Call Stack Trace:<\/p>\n

calling location\u00a0\u00a0\u00a0\u00a0point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0argument list…
\n<\/span><\/p>\n

ksedmp()+132 \u00a0\u00a0\u00a0\u00a0sdtcs()+0 \u00a0\u00a0\u00a0\u00a0 0x0<\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

kgeriv()+224\u00a0\u00a0\u00a0\u00a0ksedmp()\u00a0\u00a0\u00a0\u00a00x3 0x3 0x258 0x0 0x0 0x0<\/p>\n

kgesiv()+20\u00a0\u00a0\u00a0\u00a0kgeriv() \u00a0\u00a0\u00a0\u00a00x6b49f4 0x6bdc34 0x45a 0x0 0xdfffb570 0x6b4a58<\/p>\n

ksesic0()+48\u00a0\u00a0\u00a0\u00a0kgesiv()+0\u00a0\u00a0\u00a0\u00a00x6b49f4 0x6bdc34 0x45a 0x0 0xdfffb570 0xba131a<\/p>\n

kssadf()+452\u00a0\u00a0\u00a0\u00a0ksesic0()\u00a0\u00a0\u00a0\u00a00x45a 0x0 0x0 0x6b4a58 0xdfffc6b0 0x6b4a58<\/p>\n

kcbzgs()+172\u00a0\u00a0\u00a0\u00a0kssadf()+0\u00a0\u00a0\u00a0\u00a00x6 0xba6b0240 0xb3643a88 0xba45668c 0x3 0xba45<\/p>\n

kcbgcur()+268 \u00a0\u00a0\u00a0\u00a0kcbzgs()+0\u00a0\u00a0\u00a0\u00a00x4945 0x4945 0xba6afc3c 0xba650f6c 0x181 0xba4
\n<\/span><\/p>\n

kdddgb()+380\u00a0\u00a0\u00a0\u00a0kcbgcur()\u00a0\u00a0\u00a0\u00a00x0 0x2 0x8000021 0x6c0174 0x40000d7 0x1a2160<\/p>\n

kdusru()+392\u00a0\u00a0\u00a0\u00a0kdddgb()\u00a0\u00a0\u00a0\u00a00x6c014c 0x6c0270 0x6c0174 0x300 0x1 0xb8087f50<\/p>\n

kauupd()+32\u00a0\u00a0\u00a0\u00a0kdusru()\u00a0\u00a0\u00a0\u00a00x6bfe68 0x6c014c 0x4000 0x0 0x6c0208 0x6bee6c<\/p>\n

updexe()+2896 \u00a0\u00a0\u00a0\u00a0kauupd()\u00a0\u00a0\u00a0\u00a00x6c0338 0x0 0x6c014c 0x0 0x6bee70 0x6bee84<\/p>\n

opiexe()+7524 \u00a0\u00a0\u00a0\u00a0updexe()\u00a0\u00a0\u00a0\u00a00x4 0x4 0x4 0x40000d7 0x6bee70 0xb7f7a7c0<\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

opiodr()+3940 \u00a0\u00a0\u00a0\u00a0opiexe() \u00a0\u00a0\u00a0\u00a00xb7f7aa38 0x8 0xb7f7aa38 0xc 0x6ca274 0x6ca280
\n<\/span><\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

smcstk()+100\u00a0\u00a0\u00a0\u00a0opiodr()\u00a0\u00a0\u00a0\u00a00x6ca1d0 0x100020 0x802000 0x0 0x2 0x2<\/p>\n

rpidru()+108\u00a0\u00a0\u00a0\u00a0smcstk()+0\u00a0\u00a0\u00a0\u00a00x0 0x108958 0xf618 0x4 0x3 0xdfffd474<\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

rpiswu()+1452 \u00a0\u00a0\u00a0\u00a0rpidru()\u00a0\u00a0\u00a0\u00a00x3 0x6b4a58 0xdfffd594 0x6b4a58 0x59c01e 0xdff
\n<\/span><\/p>\n

rpidrv()+1928 \u00a0\u00a0\u00a0\u00a0rpiswu()+0\u00a0\u00a0\u00a0\u00a00x4 0x7 0xfffffffc 0x4 0x6bfe54 0x6bfe58<\/p>\n

rpiexe()+32\u00a0\u00a0\u00a0\u00a0rpidrv()\u00a0\u00a0\u00a0\u00a00xdfffd594 0x6b4a58 0x8 0xdfffd3e8 0xdfffd360 0<\/p>\n

kqdsnu()+660\u00a0\u00a0\u00a0\u00a0rpiexe()+0\u00a0\u00a0\u00a0\u00a00x2 0x9 0xb7f81368 0x1a 0x1 0x0
\n<\/span><\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

Kqrfpo()+980\u00a0\u00a0\u00a0\u00a0kqdsnu()\u00a0\u00a0\u00a0\u00a00xb7f81258 0x3 0xe 0x118 0x5d98d8 0x2<\/p>\n

kdnwtd()+1128\u00a0\u00a0\u00a0\u00a0kqrfpo()+0\u00a0\u00a0\u00a0\u00a00x12a 0xb7f81258 0xb7f81258 0x12a 0x3 0x3<\/p>\n

kdnfsh()+56\u00a0\u00a0\u00a0\u00a0kdnwtd()+0\u00a0\u00a0\u00a0\u00a00xb80e1acc 0x1 0xb80c7840 0x0 0xb8087f50 0xb808<\/p>\n

kdncls()+204\u00a0\u00a0\u00a0\u00a0kdnfsh()+0\u00a0\u00a0\u00a0\u00a00xb80e1acc 0x1 0xb80c7840 0xba109878 0x4 0xb80e
\n<\/span><\/p>\n

adbdrv()+4200 \u00a0\u00a0\u00a0\u00a0kdncls()\u00a0\u00a0\u00a0\u00a00x0 0x0 0xba1df110 0xb80df77c 0xb80e1acc 0xb80d
\n<\/span><\/p>\n

opiexe()+9012 \u00a0\u00a0\u00a0\u00a0adbdrv()\u00a0\u00a0\u00a0\u00a00x6b4a58 0x7 0xdfffd914 0x6b4a58 0x441 0x0<\/p>\n

opiosq()+2564 \u00a0\u00a0\u00a0\u00a0opiexe()\u00a0\u00a0\u00a0\u00a00x37c 0x6c6660 0x6bf75c 0xb2ab9fa8 0xb2aba034 0<\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

Piodr()+3940 \u00a0\u00a0\u00a0\u00a0opiosq()\u00a0\u00a0\u00a0\u00a00x0 0x0 0x6b49f4 0x64 0x6b4a58 0x0
\n<\/span><\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

Ttcpip()+4868 \u00a0\u00a0\u00a0\u00a0opiodr()\u00a0\u00a0\u00a0\u00a00xfffe 0x1 0x1 0x0 0x1 0x1<\/p>\n

opitsk()+1592 \u00a0\u00a0\u00a0\u00a0ttcpip()\u00a0\u00a0\u00a0\u00a00x6b61e0 0x1a 0x0 0xdfffe928 0x4 0xf<\/p>\n

opiino()+1340 \u00a0\u00a0\u00a0\u00a0opitsk()+0\u00a0\u00a0\u00a0\u00a00x6b61e0 0x6b622c 0x6b6228 0x0 0xa 0x0<\/p>\n

Did not find loadable Program Segment in \/opt\/oracle\/bin\/oracle.
\n<\/span><\/p>\n

opiodr()+3940 \u00a0\u00a0\u00a0\u00a0opiino()\u00a0\u00a0\u00a0\u00a00x0 0x6b6000 0x64 0x6b4a58 0x0 0x6b5fdc<\/p>\n

opidrv()+1388 \u00a0\u00a0\u00a0\u00a0opiodr()+0\u00a0\u00a0\u00a0\u00a00x0 0x1 0x1 0x0 0x0 0x6b61e4<\/p>\n

sou2o()+16\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0opidrv()\u00a0\u00a0\u00a0\u00a00x6b4a58 0x0 0x0 0x3c 0x0 0x6b4a58<\/p>\n

main()+140\u00a0\u00a0\u00a0\u00a0sou2o()+0\u00a0\u00a0\u00a0\u00a00xdffffbbc 0x3c 0x4 0xdffffbac 0x3 0x0<\/p>\n

_start()+92\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0main()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x2 0x0 0xdffffc48<\/p>\n

Other Information:<\/p>\n

If the state object gets corrupted in the SGA, this error will occur.<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [1114]
\n<\/strong><\/p>\n

ORA-00600 [1114]<\/p>\n

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.<\/p>\n

If you encounter this problem, collect the relevant trace and alert log files and contact Worldwide<\/p>\n

Customer Support.<\/p>\n

Bugs Filed:<\/p>\n

323437\u00a0\u00a0\u00a0\u00a0Ongoing<\/p>\n

205399\u00a0\u00a0\u00a0\u00a0Fixed in 7.2.2 (See also 173585)<\/p>\n

282296\u00a0\u00a0\u00a0\u00a0Ongoing<\/p>\n

112427\u00a0\u00a0\u00a0\u00a0Fixed in 6.0.36.7<\/p>\n

137122\u00a0\u00a0\u00a0\u00a0Fixed in 6.0.36.5<\/p>\n

ORA-600 [1117]\u00a0\u00a0\u00a0\u00a0State Object to be freed already on freelist
\n<\/strong><\/span><\/p>\n

ORA-600[1117][]<\/p>\n

kss – Kernal Service State object manager.<\/p>\n

Problem Description:<\/p>\n

Generally, this problem occurs when adding a state object to the freelist it is discovered that the parent object is already on the freelist.<\/p>\n

Call Stack Trace:<\/p>\n

location\u00a0\u00a0\u00a0\u00a0 call type\u00a0\u00a0\u00a0\u00a0point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0argument values in hex
\n<\/span><\/p>\n

opipio+f4\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0rwstab+2c0\u00a0\u00a0\u00a0\u00a0105D7D18<\/p>\n

ksledt+488\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0opipio+38\u00a0\u00a0\u00a0\u00a01056DBD8<\/p>\n

+3c58\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0li8615+e8<\/p>\n

+4174\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0+3b88\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a010316EA8 2000C980 64 40005C02FF1F2D4<\/p>\n

100CBDB0\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0+4118\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a02000C980 2004258C FEB 2 1 0 2FF1F2D4<\/p>\n

10319E38\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0100CBA0C\u00a0\u00a0\u00a0\u00a0067CBB 2FF1F354 2FF1F35C 2FF1F378 2FF1F2<\/p>\n

103A4028\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a010318D44\u00a0\u00a0\u00a0\u00a047F8805C 0 B 0 20174378 0<\/p>\n

1039E0E4\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0103A3D5C\u00a0\u00a0\u00a0\u00a02004479C 20001010 0 4504EC54 1 2FF202CC 0<\/p>\n

100EDC70\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0li8615+e8<\/p>\n

100EF298\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0100ED570\u00a0\u00a0\u00a0\u00a020014F28<\/p>\n

1039BF64\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0100EE280\u00a0\u00a0\u00a0\u00a02007C4DC<\/p>\n

103B064C\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a01039BCB4\u00a0\u00a0\u00a0\u00a020094434 3<\/p>\n

10283450\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0li8615+e8<\/p>\n

1027879C\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0li8615+e8<\/p>\n

102824BC\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a010277D20\u00a0\u00a0\u00a0\u00a057B 1 2FF21D28 0 2000D8B0 0 D10000 1<\/p>\n

103E0234\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a010281D20\u00a0\u00a0\u00a0\u00a02FF22EEA<\/p>\n

10283450\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0li8615+e8<\/p>\n

_lilt$c$+5ec\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a010282980\u00a0\u00a0\u00a0\u00a03C 4 0 0<\/p>\n

_lilt$c$+258\u00a0\u00a0\u00a0\u00a0bl<\/p>\n

_lilt$c$+29c\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a03C 0 0 pgahtop_+108<\/p>\n

_lilt$c$+22c\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a00 0 0 0<\/p>\n

sksdud_+fc\u00a0\u00a0\u00a0\u00a0bl\u00a0\u00a0\u00a0\u00a0pgahtop_+48\u00a0\u00a0\u00a0\u00a00 0<\/p>\n

Other Information:<\/p>\n

Dumping the stack trace in SQLDBA yields useful information:<\/p>\n

ALTER SESSION SET EVENTS ‘IMMEDIATE TRACE NAME ERROR_STACK LEVEL 1’<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Version\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Fixed<\/span><\/p>\n

268200\u00a0\u00a0\u00a0\u00a07.1.4.1.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Microsoft Windows\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.2.2<\/p>\n

333789\u00a0\u00a0\u00a0\u00a07.1.6.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0HP\/UX HP 98XX series \u00a0\u00a0\u00a0\u00a07.2.2<\/p>\n

305378
\n<\/span><\/p>\n

310192\u00a0\u00a0\u00a0\u00a07.1.4.1.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0SCO UNIX 386\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 7.2.2<\/p>\n

308878\u00a0\u00a0\u00a0\u00a07.1.6.2.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0IBM RS\/6000 AIX\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.2.2<\/p>\n

166338\u00a0\u00a0\u00a0\u00a07.0.12.1.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Sun SunOS 4.X\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.2.2<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [1117]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

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.<\/p>\n

ORA-600 [1191]\u00a0\u00a0\u00a0\u00a0Unexpected Instance Lock condition
\n<\/strong><\/span><\/p>\n

ORA-600[1191][req]
\n<\/span><\/p>\n

ksi – Kernel Service layer Instance locks
\n<\/span><\/p>\n

Problem Description:<\/p>\n

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.<\/p>\n

Problem Explanation:<\/p>\n

This error is port specific but logged on a number of platforms. It involves a resource situation where insufficient locks are available.<\/p>\n

Other Information:<\/p>\n

DLM locks can be increased\/decreased by the lock manager.<\/p>\n

Known Bugs:<\/p>\n

311166\u00a0\u00a0\u00a0\u00a07.1.4<\/p>\n

299454\u00a0\u00a0\u00a0\u00a07.1.4.1.3<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION FOR ORA-600 [1191]<\/p>\n

\u200d<\/p>\n

Solution Description:<\/p>\n

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.
\n<\/span><\/p>\n

Other errors usually included with this error condition are:<\/p>\n

ORA-09956: scgcm: unexpected lock status condition.<\/p>\n

ORA-00050: O\/S error occured while obtaining an enqueue. See O\/S error.
\n<\/span><\/p>\n

Solution Explanation:<\/p>\n

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\u00a0\u00a0\u00a0\u00a0unexpected or unhandled return code.<\/p>\n

Workaround(s):<\/p>\n

Start the lock manager with more locks allocated:<\/p>\n

dbtool -lmstart -opts :-l <number of locks needed>:<\/p>\n

ORA-600 [12011] Compile time Job Queue problem
\n<\/strong><\/span><\/p>\n

ORA-600[12011][failures]
\n<\/span><\/p>\n

kkj.c – Kernel Kompiletime Job queue
\n<\/span><\/p>\n

Problem Description:<\/p>\n

This error is signalled in parallel query when a job fails to execute in the correct predetermined sequence.\u00a0\u00a0\u00a0\u00a0Generally, a predecessor process fails prohibiting the entire query (operation) from completing. This error is signalled by kkjexe().
\n<\/span><\/p>\n

Other Information:<\/p>\n

The second argument identifies the number of failures in this session.<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Result
\n<\/span><\/p>\n

288289\u00a0\u00a0\u00a0\u00a0 7.1.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0IBM AIX\/RS6000\/RISC\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

Source Code: TBDL<\/p>\n

Solution Description:<\/p>\n

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.
\n<\/span><\/p>\n

ORA-600 [12201]\u00a0\u00a0\u00a0\u00a0Shared Compilation Problem
\n<\/strong><\/span><\/p>\n

ORA-600[12201][]<\/p>\n

kks.c – Kernel Kompile Shared<\/p>\n

Problem Description:<\/p>\n

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.\u00a0\u00a0\u00a0\u00a0The lock and pin have already been deleted since they hang off of the call.<\/p>\n

Problem Explanation:<\/p>\n

There existed an incorrect assumption that after unpinning and repinning an object, it had to be found at the same memory location.<\/p>\n

Other Information:<\/p>\n

This error often appears when selecting from a view.<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0 Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Status <\/span><\/p>\n

208394\u00a0\u00a0\u00a0\u00a07.0.16\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Sequent DYNIX\/ptx (G) Fixed in\u00a0\u00a0\u00a0\u00a07.1.3<\/p>\n

216959\u00a0\u00a0\u00a0\u00a07.0.15\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 HP\/UX HP 98XX series \u00a0\u00a0\u00a0\u00a0“<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [12201]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

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.<\/p>\n

Solution Explanation:<\/p>\n

Often the shadow process will be using a large percent of the CPU when the application process hangs.
\n<\/span><\/p>\n

Workaround(s):<\/p>\n

ALTER SYSTEM FLUSH SHARED_POOL;<\/p>\n

ORA-600 [12235] Oracle process has no purpose in life !
\n<\/strong><\/span><\/p>\n

ORA-600 [12235] [] [] [] [] []<\/p>\n

Versions: 7.0.16 – 7.2.2<\/p>\n

Source: opirip.c<\/p>\n

Meaning:<\/p>\n

An Oracle process was started but it cannot work out what it is suposed to be doing. Hence it exits.<\/p>\n

Diagnosis:<\/p>\n

– There is no DB corruption involved here – this is not generally\u00a0\u00a0\u00a0\u00a0serious unless the SGA is corrupt and the error keeps occuring.
\n<\/span><\/p>\n

– Depending on version the trace file may contain an SGA dump.
\n<\/span><\/p>\n

Check out the situations below first.<\/p>\n

– 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.
\n<\/span><\/p>\n

– Are they using: PQO ?, MTS ?, Prespawned Servers ? etc..
\n<\/span><\/p>\n

– Is the V2 listener the same release or higher if using net2 ?
\n<\/span><\/p>\n

– 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>
\n<\/span><\/p>\n

– If you get any decent information update <Bug:141220>
\n<\/span><\/p>\n

Known Bugs:<\/p>\n

Fixed I n.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

7.1.5\u00a0\u00a0\u00a0\u00a0Bug:225677 12235 \u00a0\u00a0\u00a0\u00a0using PARALLEL hint above PARALLEL_MAX_SERVERS.<\/p>\n

No Fix\u00a0\u00a0\u00a0\u00a0Bug:141220 12235 \u00a0\u00a0\u00a0\u00a0extra debugging added.<\/p>\n

\n

ORA-600 [12261]\u00a0\u00a0\u00a0\u00a0SQL Parse Problem
\n<\/strong><\/span><\/p>\n

ORA-600[12261][]<\/p>\n

opiosq – ORACLE Program Interface O SQL (parse only)<\/p>\n

Problem Description:<\/p>\n

This error occurs when a SQL statement is incorrectly terminated.<\/p>\n

Problem Explanation:<\/p>\n

The SQL parser has determined that the statement terminator is invalid.\u00a0\u00a0\u00a0\u00a0This usually<\/p>\n

originates from the application or internally from recursive SQL.<\/p>\n

Call Stack Trace:<\/p>\n

location\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0 point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0arg values
\n<\/span><\/p>\n

_ksedmp+136\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x0 0x58d000 0x4f 0x3a 0x598340 0x0<\/p>\n

_ksfdmp+24\u00a0\u00a0\u00a0\u00a0_ksedmp\u00a0\u00a0\u00a0\u00a00x3 0x58d000 0x0 0x2 0x0 0x0<\/p>\n

_kgeriv+220 \u00a0\u00a0\u00a0\u00a0_ksfdmp\u00a0\u00a0\u00a0\u00a00x58c37c 0x3 0x258 0x3a8408 0x2fe5 0x0<\/p>\n

_kgesiv+20\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_kgeriv\u00a0\u00a0\u00a0\u00a00x58c37c 0x258 0x2fe5 0x0 0xefffbd10 0x58c3d4<\/p>\n

_ksesic0+48 \u00a0\u00a0\u00a0\u00a0_kgesiv\u00a0\u00a0\u00a0\u00a00x58c37c 0x62c1b4 0x2fe5 0x0 0xefffbd10 0x0<\/p>\n

_opiosq+516 \u00a0\u00a0\u00a0\u00a0_ksesic0\u00a0\u00a0\u00a0\u00a00x2fe5 0x3 0xe0b96350 0x40000a 0x576f 0xefffc45c<\/p>\n

_opiodr+3936\u00a0\u00a0\u00a0\u00a0_opiosq\u00a0\u00a0\u00a0\u00a00x63265c 0x632644 0x632644 0x0 0xe0b96350 0x576f<\/p>\n

_smcstk+96\u00a0\u00a0\u00a0\u00a0_opiodr\u00a0\u00a0\u00a0\u00a00xe0 0x632644 0x530aa0 0xc3560 0x530aa0 0xc5<\/p>\n

_rpidru+116 \u00a0\u00a0\u00a0\u00a0_smcstk\u00a0\u00a0\u00a0\u00a00x0 0x92ba8 0xf618 0x4a 0xf 0xefffc45c<\/p>\n

_rpiswu+1388\u00a0\u00a0\u00a0\u00a0_rpidru\u00a0\u00a0\u00a0\u00a00xefffc320 0x58c3d4 0x8 0xefffc104 0x58c3d4 0xf<\/p>\n

_rpidrv+2028\u00a0\u00a0\u00a0\u00a0_rpiswu\u00a0\u00a0\u00a0\u00a00x62ea24 0x62e360 0x62ea24 0x5313ef 0x62ea24 0x58c\\ d4<\/p>\n

_psddrv+344 \u00a0\u00a0\u00a0\u00a0_rpidrv\u00a0\u00a0\u00a0\u00a00x7 0xefffc320 0xefffc29c 0xc7a24 0xc7b18 0x32<\/p>\n

_psdosq+156 \u00a0\u00a0\u00a0\u00a0_psddrv\u00a0\u00a0\u00a0\u00a00xe 0x4a 0xefffc45c 0x0 0x1 0xefffc458<\/p>\n

_psdnal+500 \u00a0\u00a0\u00a0\u00a0_psdosq\u00a0\u00a0\u00a0\u00a00xefffe4d0 0x0 0x0 0xe 0xe0b96350 0x576f<\/p>\n

_pricar+436 \u00a0\u00a0\u00a0\u00a0001CBD04\u00a0\u00a0\u00a0\u00a00x637428 0x637428 0xefffe4d0 0x64bd18 0x64be54 0x6\\<\/p>\n

_pricbr+768 \u00a0\u00a0\u00a0\u00a0_pricar\u00a0\u00a0\u00a0\u00a00xefffe4d0 0xefffe2fc 0x3 0x66e3dc 0x1b1 0x637428<\/p>\n

_prient2+1352 \u00a0\u00a0\u00a0\u00a0_pricbr\u00a0\u00a0\u00a0\u00a00x1b1 0xefffe2fc 0x66eaa4 0x0 0xe0bb4558 0xe0bb60c\\<\/p>\n

_peirep+76\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_prient2\u00a0\u00a0\u00a0\u00a00x637428 0x637428 0x637428 0x66e3dc 0x637428 0xeff\\<\/p>\n

_kkxrex+1584\u00a0\u00a0\u00a0\u00a0_peirep\u00a0\u00a0\u00a0\u00a00xefffe4d0 0x64bf34 0x63caa0 0x3 0x66e214 0x6d4<\/p>\n

_kporrcv+2532 \u00a0\u00a0\u00a0\u00a0_kkxrex\u00a0\u00a0\u00a0\u00a00x63caa0 0x1b1 0x1b1 0x62e360 0x1b1 0x65d6f8<\/p>\n

_kpostr+672 \u00a0\u00a0\u00a0\u00a0_kporrcv\u00a0\u00a0\u00a0\u00a00x58db60 0x65d6f8 0x58dbac 0x63caa0 0x1b1 0x0<\/p>\n

_opiodr+3936\u00a0\u00a0\u00a0\u00a0_kpostr\u00a0\u00a0\u00a0\u00a00x58dbac 0x11 0x63ca88 0x1 0x63ca74 0x58db60<\/p>\n

_ttcpip+4784\u00a0\u00a0\u00a0\u00a0_opiodr\u00a0\u00a0\u00a0\u00a00x58e400 0x58e400 0x530b30 0x383f98 0x530b30 0x52f\\84<\/p>\n

_opitsk+1452\u00a0\u00a0\u00a0\u00a0_ttcpip\u00a0\u00a0\u00a0\u00a00x58db60 0xeffff800 0x52e320 0xefffecd0 0xeffff7b0\\ 0x11
\n<\/span><\/p>\n

_opiino+1380\u00a0\u00a0\u00a0\u00a0_opitsk\u00a0\u00a0\u00a0\u00a00x58db64 0x0 0x0 0xa 0x0 0x58db60<\/p>\n

_opiodr+3936\u00a0\u00a0\u00a0\u00a0_opiino\u00a0\u00a0\u00a0\u00a00xeffffecc 0x58db60 0x2801 0xeffffecc 0xeffffa7c 0\\ 623888<\/p>\n

_opidrv+1348\u00a0\u00a0\u00a0\u00a0_opiodr\u00a0\u00a0\u00a0\u00a00x58e400 0x58e400 0x5309c0 0xbb018 0x5309c0 0x52f3\\ 8
\n<\/span><\/p>\n

_sou2o+16\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_opidrv\u00a0\u00a0\u00a0\u00a00x3c 0x58c3d4 0x0 0x58c3d4 0x1 0xeffffd10<\/p>\n

_main+148\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_sou2o\u00a0\u00a0\u00a0\u00a00xeffffedc 0x3c 0x4 0xeffffecc 0x3 0x0<\/p>\n

start+68\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0_main\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00x2 0x0 0xefffff68 0x520400 0x0 0x0<\/p>\n

Other Information:<\/p>\n

Usually the SQL string passed to the parser is not properly null terminated.<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Status <\/span><\/p>\n

286423\u00a0\u00a0\u00a0\u00a07.0.16.6\u00a0\u00a0\u00a0\u00a0IBM RS\/6000 AIX\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

261858\u00a0\u00a0\u00a0\u00a07.0.16.6.2 \u00a0\u00a0\u00a0\u00a0DEC Alpha VMS series \u00a0\u00a0\u00a0\u00a091<\/p>\n

259473 \u00a0\u00a0\u00a0\u00a07.1.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Sequent DYNIX\/ptx\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

251995 \u00a0\u00a0\u00a0\u00a07.1.3.2\u00a0\u00a0\u00a0\u00a0Sequent DYNIX\/ptx\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

250083 \u00a0\u00a0\u00a0\u00a07.1.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0HP\/UX HP 98XX series \u00a0\u00a0\u00a0\u00a011<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [12261]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

This error is PL\/SQL related and is resolved in RDBMS version 7.1.4.<\/p>\n

Workaround(s):<\/p>\n

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.\u00a0\u00a0\u00a0\u00a0Pinning the package and force recompilation of the package body will workaround this error with frequency.
\n<\/span><\/p>\n

ORA-600 [12325]\u00a0\u00a0\u00a0\u00a0Illegal predicate in View expansion
\n<\/strong><\/span><\/p>\n

ORA-600 [12325] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16 – 7.1.3
\n<\/span><\/p>\n

Source: v\/vop.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Illegal operation on a view optimize \/ copy.\u00a0\u00a0\u00a0\u00a0The operands being set up should not be in the predicate.<\/p>\n

Argument Description:<\/p>\n

a. opntyp Operation type requested (see opndef.h)<\/p>\n

Diagnosis:<\/p>\n

Check out the PROCESSSTATE for the current SQL statement.\u00a0\u00a0\u00a0\u00a0Check the expansion of any views in the statement – does the statement look legal?<\/p>\n

ORA-600 [12333]\u00a0\u00a0\u00a0\u00a0Fatal Two Task Protocol violation
\n<\/strong><\/span><\/p>\n

ORA-600 [12333] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.1.3\u00a0\u00a0\u00a0\u00a0– 7.1.6
\n<\/span><\/p>\n

Source: opitsk.c
\n<\/span><\/p>\n

Meaning:
\n<\/span><\/p>\n

This is a communication mismatch between the Oracle executable and the client program. Ie: A two task protocol violation.<\/p>\n

Argument Description:<\/p>\n

a. TTI Layer Function code received.<\/p>\n

b. Function code<\/p>\n

c. Sequence<\/p>\n

Diagnosis:<\/p>\n

In most cases this is probably masking an unexpected exception condition on some operation which throws the TTC out of sync.<\/p>\n

Argument [a] shows us what Function code we received.<\/p>\n

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.<\/p>\n

The error can be due to underlying network problems.<\/p>\n

Known Bugs:<\/p>\n

Fixed In. \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

4.0.12.1.17 \u00a0\u00a0\u00a0\u00a0<Bug:214362> \u00a0\u00a0\u00a0\u00a0Referencing a NULL DATE Bind variable in forms PLS
\n<\/span><\/p>\n

7.1.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<Bug:195946>\u00a0\u00a0\u00a0\u00a0UPDATE of missing row mishandled.
\n<\/span><\/p>\n

\n

ORA-600 [1236]\u00a0\u00a0\u00a0\u00a0Service User: ?
\n<\/strong><\/span><\/p>\n

ORA-600[1236][]<\/p>\n

ksu – Kernel Service User management.<\/p>\n

Problem Description:<\/p>\n

In earlier versions of the RDBMS (6.0, 7.0) this was a problem with shared memory collisions between instances of a database.\u00a0\u00a0\u00a0\u00a0Multiple instances appear to be running off of the same set of datafiles (not Oracle Parallel Server).\u00a0\u00a0\u00a0\u00a0In more recent versions of the RDBMS (7.1, 7.2) this error is usually parallel query related.<\/p>\n

Call Stack Trace:<\/p>\n

0 00496c24-sdtcs (0x0, 0x4, 0x1, 0x0) [sdtcs.c:177]<\/p>\n

1 0047f53c-ssexhd (0x4, 0x1006046c, 0x0, 0x0) [ssexhd.c:263]<\/p>\n

2 009073c4-sigvec (0x2, 0x1003c0a8, 0xf, 0x1) [..\/sigvec.s:109]<\/p>\n

3 00907550-_cerror (0x2, 0x1003c0a8, 0xf, 0x1) [..\/cerror.s:26]<\/p>\n

signal handler assertion failed (_longjmp)
\n<\/span><\/p>\n

st_dump_frame returns error: -1 at pc= 008ff2bc
\n<\/span><\/p>\n

ssexhd+108 (0x47f53c): \u00a0\u00a0\u00a0\u00a0sdtcs(0x0, 0x0, 0x4, 0x7fff5354, 0x0)<\/p>\n

sigvec+164 (0x9073c4): \u00a0\u00a0\u00a0\u00a0ssexhd(0x4, 0x7fff5354, 0x0, 0x0, 0x2)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0abort(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0_longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0_longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0_longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0_longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0)<\/p>\n

_longjmp+160 (0x8ff2bc): \u00a0\u00a0\u00a0\u00a0_longjmp(0x1001487c, 0x14, 0x5013a428, 0x0, 0x10054dd0).<\/p>\n

.<\/p>\n

Other Information:<\/p>\n

Sometimes this error is parallel query related where a slave query process will fail and report this error along with other errors.<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Status
\n<\/span><\/p>\n

308813\u00a0\u00a0\u00a0\u00a07.1.6.2.0 \u00a0\u00a0\u00a0\u00a0IBM SP AIX\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

260277\u00a0\u00a0\u00a0\u00a07.1.3.0.1 \u00a0\u00a0\u00a0\u00a0AT&T System 3000 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

257903\u00a0\u00a0\u00a0\u00a07.0.13.1 \u00a0\u00a0\u00a0\u00a0DEC MIPS Ultrix\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a096<\/p>\n

257901\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Base<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [1236]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

This internal error is as a result of popping one too many errors of off the error stack and losing the much needed information.<\/p>\n

If you encounter this problem, collect the relevant trace and alert log files and contact Worldwide Customer Support.<\/p>\n

ORA-600 [1237]\u00a0\u00a0\u00a0\u00a0Invalid Session while changing SO
\n<\/strong><\/span><\/p>\n

ORA-600[1237][]<\/p>\n

kss – Kernel Service User management.<\/p>\n

Problem Description:<\/p>\n

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.<\/p>\n

Other Information:<\/p>\n

This error occurs on heavily loaded systems running MTS.<\/p>\n

Known Bugs:<\/p>\n

Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Status
\n<\/span><\/p>\n

273358\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.3.2\u00a0\u00a0\u00a0\u00a0Sequent DYNIX\/ptx\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.6.2<\/p>\n

293524\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.0.16.6\u00a0\u00a0\u00a0\u00a0DEC Alpha VMS series \u00a0\u00a0\u00a0\u00a07.1.6.2<\/p>\n

284547\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0HP 93xx HP\/UX\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.6.2<\/p>\n

276665\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Sun Solaris V2 UNIX\u00a0\u00a0\u00a0\u00a07.1.6.2<\/p>\n

274323 \u00a0\u00a0\u00a0\u00a0 7.1.3.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DEC Alpha VMS series \u00a0\u00a0\u00a0\u00a07.1.6.2<\/p>\n

27335\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.3.2\u00a0\u00a0\u00a0\u00a0Sequent DYNIX\/ptx<\/p>\n

269572\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.1.3.2\u00a0\u00a0\u00a0\u00a0HP 98xx HP\/UX<\/p>\n

240140\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Base Fixed\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 7.1.6.2<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION FOR ORA-600 [1237]<\/p>\n

Solution Description:<\/p>\n

Bug 240140 was resolved in version 7.1.6.2 of the RDBMS.\u00a0\u00a0\u00a0\u00a0Many platforms experienced this problem using tuxedo, XA and Multi-Threaded Server (MTS).
\n<\/span><\/p>\n

Generally, gather all relevent information such as trace files, alert log and any kind of dumps and call Oracle Worldwide Customer Support.
\n<\/span><\/p>\n

\n

ORA-600 [12700] Index points to missing ROWID
\n<\/strong><\/span><\/p>\n

ORA-600 [12700] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.15 – 7.1.6
\n<\/span><\/p>\n

Meaning:<\/p>\n

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.<\/p>\n

Argument Description:<\/p>\n

a. DBA on some versions ?<\/p>\n

Diagnosis:<\/p>\n

This can be due to a real corruption OR due to a consistent read problem.
\n<\/span><\/p>\n

– ANALYZE TABLE <tname> VALIDATE STRUCTURE CASCADE to show if it is a\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0real corruption or not – or perform a full range scan via the index.<\/p>\n

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.<\/p>\n

– If the analyze succeeds this is probably a consistent read problem.
\n<\/span><\/p>\n

The most common cause of the problem is a long(ish) running query
\n<\/span><\/p>\n

which scans through an index on which dml (update\/insert) is
\n<\/span><\/p>\n

currently occurring and causing ‘index-splitting’ to occur.
\n<\/span><\/p>\n

In this case the longer running the query the more chance of it
\n<\/span><\/p>\n

hitting one of these blocks thus forcing a CR (consistent
\n<\/span><\/p>\n

read) back to a pre-split time. The CR block can in this case have
\n<\/span><\/p>\n

an index entry marked as valid (incorrectly) whereas the data-block
\n<\/span><\/p>\n

has the row marked deleted (correctly).
\n<\/span><\/p>\n

Workarounds:<\/p>\n

Try not to use the index.<\/p>\n

Force a dummy sort to pre-allocate the row source up front.<\/p>\n

Evidence:<\/p>\n

For NEW issues:<\/p>\n

– Tracefile<\/p>\n

– Redo for the INDEX and DATA blocks<\/p>\n

– Application logic<\/p>\n

– Current dumps of redo \/ data blocks<\/p>\n

– If easily reproducible after bouncing the DB put\u00a0\u00a0\u00a0\u00a010226 on.<\/p>\n

Known Bugs: \u00a0\u00a0\u00a0\u00a0(Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0 Bug No.\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0 Description<\/span><\/p>\n

7.1.4\u00a0\u00a0\u00a0\u00a0Bug:194593 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0CR problem<\/p>\n

7.1.5\u00a0\u00a0\u00a0\u00a0Bug:226468 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0CR problem<\/p>\n

ORA-600 [1301]\u00a0\u00a0\u00a0\u00a0Process Cleanup of pseudo child
\n<\/strong><\/span><\/p>\n

ORA-600[1301][child]
\n<\/span><\/p>\n

ksucln – Kernel Service User management CLeaNup process.
\n<\/span><\/p>\n

Problem Description:<\/p>\n

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).<\/p>\n

Problem Explanation:<\/p>\n

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.\u00a0\u00a0\u00a0\u00a0The pseudo process is a place holder for sessions.\u00a0\u00a0\u00a0\u00a0When clients are running XA, sessions temporarily move to the pseudo process when they become detached from a terminal.<\/p>\n

Other Information:<\/p>\n

Previous recovery problems will indicate block clean out on the itl was performed incorrectly.<\/p>\n

Known Bugs:<\/p>\n

189549 XA environment.<\/p>\n

181935 Increase timeout.<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [1301]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

The following recommended steps will aid in determining the course of action to take:
\n<\/span><\/p>\n

Get system state dump immediately after the instance is started:<\/p>\n

ALTER SESSION SET EVENTS “IMMEDIATE TRACE NAME SYSTEMSTATE LEVEL 10”;<\/p>\n

Set event 10246 in init.ora for additional PMON trace information.<\/p>\n

event = “10246 trace name context forever, level 10”;<\/p>\n

Get the log files from XA and Tuxedo if applicable.<\/p>\n

Solution Explanation:<\/p>\n

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:<\/p>\n

ALTER SYSTEM KILL SESSION n,m<\/p>\n

The session can also be removed at the operating system level.<\/p>\n

Workaround(s):<\/p>\n

XA = increase timeout value to hours.<\/p>\n

ORA-600 [13011]\u00a0\u00a0\u00a0\u00a0Problem occurred when trying to delete a row.
\n<\/strong><\/span><\/p>\n

ORA-600 [13011] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16 – 7.X.X
\n<\/span><\/p>\n

Source: delexe.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Problem occurred when trying to delete a row.<\/p>\n

Argument Description:<\/p>\n

a. Pass count. (If greater than 5000 then this is what’s exceeded).<\/p>\n

b. Code.<\/p>\n

c. DBA of block containing the row to be deleted.<\/p>\n

d. Row slot number.<\/p>\n

e. DBA of block being updated (should be same as ‘c.’) ?<\/p>\n

Diagnosis:<\/p>\n

Most probably a corrupted index.<\/p>\n

Check object that this DBA points to.<\/p>\n

Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

Bug:189281\u00a0\u00a0\u00a0\u00a0Suggests this is caused by bad index or consistent read problem.<\/p>\n

Bug:111890\u00a0\u00a0\u00a0\u00a0Deleting the same row twice.<\/p>\n

ORA-600 [13012]\u00a0\u00a0\u00a0\u00a0Update Row Piece predicate Failure
\n<\/strong><\/span><\/p>\n

ORA-600 [13012]<\/p>\n

Versions: 7.1.4\u00a0\u00a0\u00a0\u00a0– 7.2.3<\/p>\n

Source: u\/updexe.c<\/p>\n

Meaning:<\/p>\n

indicates that we were trying to update a row that we believe was already locked but that we got a predicate failure.<\/p>\n

Diagnosis:<\/p>\n

Trace includes a Buffer Cache dump & lots of diagnostics.<\/p>\n

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><\/p>\n

ANALYZE table VALIDATE STRUCTURE CASCADE;<\/p>\n

Check for chained rows.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

<Bug:318811>\u00a0\u00a0\u00a0\u00a0Introduced in 7.1.5 – multiple triggers<\/p>\n

<Bug:200344>\u00a0\u00a0\u00a0\u00a0Chained row corruption could cause this.<\/p>\n

ORA-600 [13013]\u00a0\u00a0\u00a0\u00a0Bad block found during UPDATE
\n<\/strong><\/span><\/p>\n

ORA-600 [13013] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16 – 7.X.X
\n<\/span><\/p>\n

Meaning:<\/p>\n

Inconsistency between index and data block in the DB found during update.<\/p>\n

Argument Description:<\/p>\n

a. Pass count (>5000)<\/p>\n

b. Code<\/p>\n

c. DBA of block containing the row to be updated<\/p>\n

d. Row slot number.<\/p>\n

e. DBA of block being updated (should be same as ‘c.’) ?<\/p>\n

Diagnosis:<\/p>\n

Check what object is at this DBA.<\/p>\n

ANALYZE TABLE VALIDATE STRUCTURE CASCADE may be worth running.<\/p>\n

Recreate if an index.<\/p>\n

If you are having problems identifying the object \/ row set <Event:10219> at level 4999. This will dump the environment on each pass.<\/p>\n

ORA-600 [15803]\u00a0\u00a0\u00a0\u00a0Parallel Query message out of order
\n<\/strong><\/span><\/p>\n

ORA-600[15803][severity_code]
\n<\/span><\/p>\n

kxfx.c – Kernel eXecute Fast (parallel) sql eXecution
\n<\/span><\/p>\n

Problem Description:<\/p>\n

This error relates to a client\/server parallel query message protocol\/ transmission breakdown.<\/p>\n

Problem Explanation:<\/p>\n

Generally, a message notification or response is out of sequence or unexpected.<\/p>\n

Other Information:<\/p>\n

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.<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [15803]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

Restart the query.<\/p>\n

Solution Explanation:<\/p>\n

Query slave processes have failed implementing SQL fetch, parse, bind, or execute operations.<\/p>\n

Generally a sequence of events occured out of order or an unexpected message response was received.<\/p>\n

ORA-600 [16224]\u00a0\u00a0\u00a0\u00a0Error Cleaning OBJ$
\n<\/strong><\/span><\/p>\n

ORA-600 [16224] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.1.3 – 7.1.4
\n<\/span><\/p>\n

Source: kql.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

kqlclo() KQL CLean Obj$ tried to delete a non existant object<\/p>\n

Diagnosis:<\/p>\n

If 7.1.4 and startup see <Bug:235565><\/p>\n

Setting event “10052” will avoid this as it prevents clean up of obj$.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

7.1.5\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:235565\u00a0\u00a0\u00a0\u00a0Views on Dicationary tables can cause ORA 600 16224
\n<\/span><\/p>\n

ORA-600 [17066] KGL Anonymous object list not empty
\n<\/strong><\/span><\/p>\n

ORA-600 [17066]<\/p>\n

Versions: 7.0.15 – 7.1.6<\/p>\n

Source: kgh.c<\/p>\n

Meaning:<\/p>\n

KGL Anonymous object list not empty during KGL shutdown.<\/p>\n

DIAGNOSIS FOR ORA-600[17066]<\/p>\n

Solution Description:<\/p>\n

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.)<\/p>\n

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.)<\/p>\n

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.<\/p>\n

Format:<\/p>\n

in the BUCKET, we are looking at the line that starts with:<\/p>\n

kk-dd-aa-ll=00-01-00-01 lock=.. pin=..<\/p>\n

This line will show the handle that Oracle could not release.<\/p>\n

Example 1:<\/p>\n

Observe Bucket 3157: has a handle in which is pinned exclusive.<\/p>\n

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.<\/p>\n

BUCKET 3157:<\/p>\n

LIBRARY OBJECT HANDLE: handle=4cfcc70<\/p>\n

name=MPM_ERROR<\/p>\n

hash=fa780e28<\/p>\n

namespace=PIPE flags=RON\/PN0\/SML\/[12010000]<\/p>\n

kk-dd-aa-ll=00-01-00-01 lock=0 pin=X<\/p>\n

lwt=4cfcc88[4cfcc88,4cfcc88] ltm=4cfcc90[4cfcc90,4cfcc90]<\/p>\n

pwt=4cfcca0[4cfcca0,4cfcca0] ptm=4cfccf4[4cfccf4,4cfccf4]<\/p>\n

ref=4cfcc78[4cfcc78,4cfcc78]<\/p>\n

LIBRARY OBJECT: object=4cfca50<\/p>\n

type=PIPE flags=EXS\/NRC[0401] status=VALD load=0<\/p>\n

DATA BLOCKS:<\/p>\n

data#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0heap \u00a0\u00a0\u00a0\u00a0pointer \u00a0\u00a0\u00a0\u00a0status \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0pins \u00a0\u00a0\u00a0\u00a0change <\/span><\/p>\n

0 \u00a0\u00a0\u00a0\u00a04cfe990 \u00a0\u00a0\u00a0\u00a04cfcab0\u00a0\u00a0\u00a0\u00a0I\/P\/A \u00a0\u00a0\u00a0\u00a00 \u00a0\u00a0\u00a0\u00a0NONE<\/p>\n

BUCKET 3158:<\/p>\n

Example 2:<\/p>\n

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.<\/p>\n

BUCKET 713:<\/p>\n

LIBRARY OBJECT HANDLE: handle=69f0da8<\/p>\n

name=INV.MTL_TRANSACTIONS_INTERFACE<\/p>\n

hash=e3ee231f timestamp=11-19-1994 09:50:39<\/p>\n

namespace=TABL\/PRCD flags=TIM\/SML\/[02000000]<\/p>\n

kk-dd-aa-ll=00-00-00-00 lock=? pin=0<\/p>\n

lwt=69f0dc0[69f0dc0,69f0dc0] ltm=69f0dc8[69f0dc8,69f0dc8]<\/p>\n

pwt=69f0dd8[69f0dd8,69f0dd8] ptm=69f0e2c[69f0e2c,69f0e2c]<\/p>\n

ref=69f0db0[69f0db0,69f0db0]<\/p>\n

LOCK OWNERS:<\/p>\n

\u00a0\u00a0\u00a0\u00a0lock \u00a0\u00a0\u00a0\u00a0user \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0session \u00a0\u00a0\u00a0\u00a0count mode \u00a0\u00a0\u00a0\u00a0flags
\n<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a069f0fa8 \u00a0\u00a0\u00a0\u00a0160002 \u00a0\u00a0\u00a0\u00a0f00 \u00a0\u00a0\u00a0\u00a00 \u00a0\u00a0\u00a0\u00a00 \u00a0\u00a0\u00a0\u00a0[00]<\/p>\n

BUCKET 714:<\/p>\n

References:<\/p>\n

BUG-192548, \u00a0\u00a0\u00a0\u00a0BUG-183630<\/p>\n

Known Bugs:<\/p>\n

Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

7.0.16\u00a0\u00a0\u00a0\u00a0<Bug:166545> \u00a0\u00a0\u00a0\u00a0Error on shutdown.<\/p>\n

ORA-600 [17090] Empty error stack when signalling error
\n<\/strong><\/span><\/p>\n

ORA-600 [17090] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16\u00a0\u00a0\u00a0\u00a0– 7.1.3
\n<\/span><\/p>\n

Source: kg\/kge.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Oracle tried to resignal an error but the error stack in the PGA is empty ?<\/p>\n

Explanation:<\/p>\n

Basically we are trying to resignal an error in kgerse() but there appears to be no error stack.<\/p>\n

Diagnosis:<\/p>\n

– Is auditing being used ? See <Bug:207830><\/p>\n

– Check Stack trace\u00a0\u00a0\u00a0\u00a0If KKXEXE() at the top then see <Bug:234356><\/p>\n

– Is a remote DB involved ?<\/p>\n

– Check if any Oracle EVENTS are set – unset them.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

7.1.6\u00a0\u00a0\u00a0\u00a0Bug:234356 \u00a0\u00a0\u00a0\u00a0PL\/SQL blocks raise 17090 from kkxexe()<\/p>\n

7.1.4\u00a0\u00a0\u00a0\u00a0Bug:207830 \u00a0\u00a0\u00a0\u00a0Auditing INSERTs or DDL<\/p>\n

Bugs Filed:<\/p>\n

Bug No.\u00a0\u00a0\u00a0\u00a0Description\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Dscription
\n<\/span><\/p>\n

261002 \u00a0\u00a0\u00a0\u00a0Fixed in 7.2.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0265315 \u00a0\u00a0\u00a0\u00a0ixed in 7.3<\/p>\n

306313 \u00a0\u00a0\u00a0\u00a0Ongoing \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0296446 \u00a0\u00a0\u00a0\u00a0ixed in 7.3.2<\/p>\n

302107 \u00a0\u00a0\u00a0\u00a0Ongoing \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0277709\u00a0\u00a0\u00a0\u00a0Fixed in 7.2<\/p>\n

290399 \u00a0\u00a0\u00a0\u00a0Ongoing \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0265892\u00a0\u00a0\u00a0\u00a0Fixed in SQL*NET 1.1.1.16<\/p>\n

245843 \u00a0\u00a0\u00a0\u00a0Fixed in 7.1.6 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0200344 \u00a0\u00a0\u00a0\u00a0Fixed in 7.1.3<\/p>\n

231590 \u00a0\u00a0\u00a0\u00a0Fixed in 7.2 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0225034 \u00a0\u00a0\u00a0\u00a0Fixed in 7.1.5<\/p>\n

207830 \u00a0\u00a0\u00a0\u00a0Fixed in 7.1.4 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0166504 \u00a0\u00a0\u00a0\u00a0Fixed in 7.0.15<\/p>\n

\n

ORA-600 [17114]\u00a0\u00a0\u00a0\u00a0KGH Bad magic number in header
\n<\/strong><\/span><\/p>\n

ORA-600 [17114]<\/p>\n

Versions: 7.0.15\u00a0\u00a0\u00a0\u00a0– 7.1.6<\/p>\n

Source: kgh.c<\/p>\n

Meaning:<\/p>\n

The header of a chunk of heap memory did not have the correct MAGIC NUMBER in the header.<\/p>\n

Diagnosis:<\/p>\n

Bounce the instance.<\/p>\n

If 7.0 upgrade. Otherwise refer to<\/p>\n

COMMON SOURCE OF HEAP CORRUPTIONS<\/p>\n

Problem Description:<\/p>\n

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.<\/p>\n

Usually this is an ORA-600 [17xxx] error.<\/p>\n

Why would an address get overwritten before Oracle is ready to free it?<\/p>\n

1. Some application will write to the address for some reason, losing the data already in it.<\/p>\n

2. It is a bug.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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).<\/p>\n

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.<\/p>\n

Example 1 :<\/p>\n

1. This is the first thing you will see in a heap trace file:<\/p>\n

Fri Jun 30 07:03:23 1995<\/p>\n

*** SESSION ID:(6.8008)<\/p>\n

********** Internal heap ERROR 17112 addr=0xc0ca0338 *********<\/p>\n

….<\/p>\n

…..<\/p>\n

2. Notice that the ERROR 17112 indicates the internal error and also the address that the error is occuring on.<\/p>\n

3. From that information, we can look in the memory dump of the address.<\/p>\n

4. Here is the format of the dump of this memory trace file:<\/p>\n

address byte1 \u00a0\u00a0\u00a0\u00a0byte2 \u00a0\u00a0\u00a0\u00a0 byte3\u00a0\u00a0\u00a0\u00a0 byte4 byte5 \u00a0\u00a0\u00a0\u00a0 byte6 byte7 \u00a0\u00a0\u00a0\u00a0 byte8<\/p>\n

12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678<\/p>\n

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.<\/p>\n

***** Dump of memory around addr 0xc0ca0338:<\/p>\n

C0CA0120 0FFF0600 00000120<\/p>\n

C0CA0140 C0F5FBB8 00000000 5C0000E8 00000000 00000000 000000D8 000C0000 0000008
\n<\/span><\/p>\n

….
\n<\/span><\/p>\n

…..<\/p>\n

C0CA0320 00000000 00000000 00400000 02000000 00000742 00000000 00000000 00000000
\n<\/span><\/p>\n

C0CA0340 00000000 00000000 00000000 C11A7D38 4C0000A0 00000000 C11A7E98 000000A0
\n<\/span><\/p>\n

C0CA0360 000C0000 00000770 00000000 00000000 026E0301 00010300 00000000 C0CA0380
\n<\/span><\/p>\n

….
\n<\/span><\/p>\n

…..<\/p>\n

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.<\/p>\n

Here is the format for this heap dump:<\/p>\n

Chunk address\u00a0\u00a0\u00a0\u00a0size—— type of chunk “chunk content” internal info
\n<\/span><\/p>\n

HEAP DUMP heap name=”sga heap” desc=0xc0adb010<\/p>\n

extent sz=0xfc8 alt=44 het=32767 rec=1 flg=2 opc=0<\/p>\n

parent=0 owner=0 nex=0 xsz=0x1<\/p>\n

EXTENT 0<\/p>\n

Chunk c0ae4350\u00a0\u00a0\u00a0\u00a0sz= 685968 perm \u00a0\u00a0\u00a0\u00a0“perm \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0” alo=685968<\/p>\n

Chunk c0b8bae0\u00a0\u00a0\u00a0\u00a0sz= 1240 \u00a0\u00a0\u00a0\u00a0freeable \u00a0\u00a0\u00a0\u00a0“sql area \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0” ds=c0d64958<\/p>\n

….<\/p>\n

…..<\/p>\n

Chunk c0b8c900 sz= 352 \u00a0\u00a0\u00a0\u00a0freeable \u00a0\u00a0\u00a0\u00a0“sql area \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0” ds=c10b4ce8<\/p>\n

Chunk c0b8ca60 sz= 568 \u00a0\u00a0\u00a0\u00a0freeable \u00a0\u00a0\u00a0\u00a0“library cache \u00a0\u00a0\u00a0\u00a0” ds=c0da8c58<\/p>\n

Chunk c0b8cc98 sz= 296 \u00a0\u00a0\u00a0\u00a0recreate \u00a0\u00a0\u00a0\u00a0“KGL handles \u00a0\u00a0\u00a0\u00a0” latch=c0ae232c<\/p>\n

Chunk c0b8cdc0 sz= 2104 \u00a0\u00a0\u00a0\u00a0recreate \u00a0\u00a0\u00a0\u00a0“PL\/SQL MPCODE\u00a0\u00a0\u00a0\u00a0” latch=c0ae23a8<\/p>\n

….<\/p>\n

…..<\/p>\n

Chunk c0ca0230 sz= 264 recreate\u00a0\u00a0\u00a0\u00a0“library cache\u00a0\u00a0\u00a0\u00a0” latch=c0ae232c<\/p>\n

ds c0ca0478 sz= 3104<\/p>\n

c0ecec40 sz= 568<\/p>\n

c0bce178 sz= 568<\/p>\n

c0c462d8 sz= 568<\/p>\n

c1276620 sz= 568<\/p>\n

c125e090 sz= 568<\/p>\n

Chunk c0ca0338 sz= 0 ERROR, BAD MAGIC NUMBER (0)<\/p>\n

Total heap size = 1818600<\/p>\n

FREE LISTS:<\/p>\n

….<\/p>\n

…..<\/p>\n

6. Notice that at that address, the size has been zeroed out and there is an ERROR, BAD MAGIC NUMBER (0).<\/p>\n

Bugs Filed :<\/p>\n

249498 Fixed in 7.1.6<\/p>\n

163759 Fixed in PL\/SQL 2.0.18<\/p>\n

182024 Fixed in PL\/SQL 1.0.10<\/p>\n

175552 Fixed in 7.0.17<\/p>\n

221563 Ongoing<\/p>\n

207836 Fixed in 7.0.17<\/p>\n

ORA-600 [17148]\u00a0\u00a0\u00a0\u00a0KGH Bad magic number (Recreatable chunk)
\n<\/strong><\/span><\/p>\n

ORA-600 [17148]<\/p>\n

Versions: 7.0.15\u00a0\u00a0\u00a0\u00a0– 7.1.6<\/p>\n

Source: kgh.c<\/p>\n

Meaning:<\/p>\n

The header of a chunk of RECREATABLE memory did not have\u00a0\u00a0\u00a0\u00a0the correct MAGIC NUMBER in the header.<\/p>\n

Diagnosis:<\/p>\n

Bounce the instance.<\/p>\n

If 7.0 upgrade, otherwise: refer to COMMON SOURCE OF HEAP CORRUPTIONS in ORA-600 [17114]<\/p>\n

BUGS FOR ORA-600[17148]<\/p>\n

Solution Description:<\/p>\n

Many bugs have been filed for this issue. For a comprehensive list and new bugs please check bug database.<\/p>\n

The following is a list of bugs that have been confirmed by development and a<\/p>\n

short explanation.<\/p>\n

BUG#271669<\/strong> workaround available Base bug#205399 RDBMS7.1.4 fixe 7.2.2<\/p>\n

Symptom:<\/p>\n

Receive an ora-600 [730] during shutdown.<\/p>\n

The database starts up fine, but start to receive ora-600[17148] errors<\/p>\n

Diagnosis & resolution:<\/p>\n

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.<\/p>\n

Since the old sga was still mapped, and much of the memory associated with various subsystems had been removed, this probably cause some problem<\/p>\n

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.<\/p>\n

BUG#254415<\/strong> [17148] not coming after removing the _sql_connect_capability_code.<\/p>\n

RDBMS 7.1.3.2 C<\/p>\n

Symptom :<\/p>\n

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.<\/p>\n

Resolution :<\/p>\n

_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.<\/p>\n

Here is another instance where the [17148] occurs:<\/p>\n

Symptom :<\/p>\n

ora-600[730][64][space leak] and ora-600[17148][2178120720] when logging out<\/p>\n

of a sessionThere are triggers on aud$.<\/p>\n

Diagnosis :<\/p>\n

1) they turn off auditing and create a table petrol.aud$ as select * from sys.aud$<\/p>\n

2) they rename sys.aud$ to sys.aud$.old<\/p>\n

3) as sys they create a synonym “aud$” that points to petrol.aud$<\/p>\n

4) then they create an after update trigger on petrol.aud$ – the trigger checks<\/p>\n

for a user logout and then gets the user’s statistics and inserts that info into another table<\/p>\n

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.<\/p>\n

Resolution\/workaround:<\/p>\n

(1) Change the trigger to an ‘before update’ trigger instead of an after update trigger solved the problem.<\/p>\n

BUG#250143<\/strong> ORA-600[17148] IN RUNNING REMOTE PROCEDURE CALLS<\/p>\n

RDBMS 7.1.3 – fixed in Generic BUG#249498 fixed in 7.1.6<\/p>\n

MEMORY CORRUPTION: RPC OF PLSQL TABLE WITH CHAR\/VARCHAR2\/RAW ELEMENTS<\/p>\n

BUG#242509<\/strong> CREATE TRIGGER SCRIPT CAUSES INSTANCE TO CRASH RESULTING IN ORA-3113<\/p>\n

Duplicate bug#222792 fixed in 7.1.3 Generic bug.<\/p>\n

Symptoms:<\/p>\n

Running SQL script to create the triggers:<\/p>\n

– 1st attempt killed the instance<\/p>\n

– subsequent attempts create some triggers, hangs on specific CREATE TRIGGER<\/p>\n

statements. Customer waits ~10 minutes for one of the hanging statements<\/p>\n

to complete before terminating.<\/p>\n

When using Export written on Ultrix, Importing into OSF\/1 machine, where both are running 7.0.16:<\/p>\n

Multiple occurrences of ORA-600 [17148],[10482848] in the alert.log<\/p>\n

Customer has to SHUTDOWN ABORT and restart.<\/p>\n

Problem:<\/p>\n

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.<\/p>\n

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.<\/p>\n

ORA-600 [2103]\u00a0\u00a0\u00a0\u00a0Control File Enqueue Timeout
\n<\/strong><\/span><\/p>\n

ORA-600 [2103] [a] [b] [c] [d] [e]<\/p>\n

Versions: 7.0.12 – 7.1.4<\/p>\n

Meaning:<\/p>\n

Timeout on control file enqueue (15 minutes).<\/p>\n

Argument Description:<\/p>\n

a. Number of seconds that it timed out on (normally 900).<\/p>\n

Diagnosis:<\/p>\n

What operation was being performed. Eg: Drop tablespace or was this during normal operation.<\/p>\n

\u00a0\u00a0\u00a0\u00a0a. Determine if async IO is in use in any form.<\/p>\n

b. Determine if multiple DB writers in use.<\/p>\n

\u00a0\u00a0\u00a0\u00a0 >> If BOTH async and multiple DB writers back one out.<\/p>\n

>> If just AsyncIO turn this OFF using the relevant init.ora parameter as this usually seems to occur with async IO.<\/p>\n

\u00a0\u00a0\u00a0\u00a0 >> If multiple DB writers back down to 1 db writer<\/p>\n

Take care with this error. If the above are not true note that this error can arise on a very slow \/ hung system.<\/p>\n

– Check OS error logs for ‘stuck’ OS writes or repeat writes<\/p>\n

– Check if the whole system appears to be hung.<\/p>\n

Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

7.0.12.1\u00a0\u00a0\u00a0\u00a0Bug:187656 \u00a0\u00a0\u00a0\u00a0Too many open files.<\/p>\n

?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:161165 \u00a0\u00a0\u00a0\u00a0Using db_writers > 1 on Sun4.<\/p>\n

?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:180728 \u00a0\u00a0\u00a0\u00a0Using asynch I\/O on AIX.<\/p>\n

?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:169343 \u00a0\u00a0\u00a0\u00a0db_writers > 1 and drop tablespace.<\/p>\n

ORA-600 [2130]\u00a0\u00a0\u00a0\u00a0Attempt to access non-existant control fileentry.
\n<\/strong><\/span><\/p>\n

ORA-600 [2130] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.15 – 7.1.x
\n<\/span><\/p>\n

Source: kcc.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

We were asked to get \/ update a non-existant entry in the controlfile.<\/p>\n

Argument Description:<\/p>\n

a. Entry number<\/p>\n

b. Maximum entry in controlfile of this type<\/p>\n

c. Type (See kcc.h)<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDEDBI\u00a0\u00a0\u00a0\u00a0 0 \u00a0\u00a0\u00a0\u00a0DB info entry<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDERTH\u00a0\u00a0\u00a0\u00a0 1 \u00a0\u00a0\u00a0\u00a0Redo thread<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDELOG 2 \u00a0\u00a0\u00a0\u00a0log file entries<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDEDBF\u00a0\u00a0\u00a0\u00a0 3 \u00a0\u00a0\u00a0\u00a0database file entries<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDENAM 4 \u00a0\u00a0\u00a0\u00a0names for files in the database<\/p>\n

\u00a0\u00a0\u00a0\u00a0KCCDEARC\u00a0\u00a0\u00a0\u00a0 5 \u00a0\u00a0\u00a0\u00a0Locations of archived logs<\/p>\n

d. [OPS only – mount id]<\/p>\n

Diagnosis:<\/p>\n

The error is actually a problem trying to read some information from the controlfile and can occur for a number of reasons.<\/p>\n

Eg: block corruptions (bad chain dba) etc…<\/p>\n

Chained row corruptions are likely to show as:<\/p>\n

[2130] [FNO] [MAX] [3] with FNO>MAX (Ie: chained DBA points at non-existant file)<\/p>\n

Make sure you check the stack trace for the error. This shows us what<\/p>\n

we were doing when we tried to access the controlfile information.<\/p>\n

Also locate the current SQL statement for a clue as to the operation being performed and any block dumps in the trace file.<\/p>\n

Check any objects for block corruptions.<\/p>\n

Eg: Use ANALYZE table VALIDATE STRUCTURE CASCADE and also see<\/p>\n

Note:<\/p>\n

It is possible for 2130 to be signalled while trying to dump information for some other internal error and thus hide the true error.<\/p>\n

Eg: An ASSERT fails so Oracle dumps various diagnostics and 2130 gets signalled while dumping these diagnostics. The original error may never be seen.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0 Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

Bug:200344\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Corruption on chained row [2130][x][y][3].<\/p>\n

Bug:215724\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Analyze Table ESTIMATE stats (use COMPUTE instead)
\n<\/span><\/p>\n

\n

ORA-600 [2256]\u00a0\u00a0\u00a0\u00a0Bad ADJUST_SCN value
\n<\/strong><\/span><\/p>\n

ORA-600 [2256] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16\u00a0\u00a0\u00a0\u00a0– 7.1.4
\n<\/span><\/p>\n

Source: knl\/kcm.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

You attempted to ADJUST_SCN but the level supplied would be less that the current SCN.<\/p>\n

Argument Description:<\/p>\n

a.\u00a0\u00a0\u00a0\u00a0Requested SCN WRAP<\/p>\n

b.\u00a0\u00a0\u00a0\u00a0Requested SCN BASE<\/p>\n

c.\u00a0\u00a0\u00a0\u00a0Current SCN WRAP<\/p>\n

d.\u00a0\u00a0\u00a0\u00a0Current SCN BASE<\/p>\n

Diagnosis:<\/p>\n

If you really mean to adjust the SCN use a higher level.<\/p>\n

Check that you do not have ADJUST_SCN still set.<\/p>\n

ORA-600 [2657]\u00a0\u00a0\u00a0\u00a0Sync RBA > Current RBA – Help
\n<\/strong><\/span><\/p>\n

ORA-600 [2657] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.1.4 – 7.2.2
\n<\/span><\/p>\n

Source: kcrfw.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

The SYNC RBA is > the current RBA. This is impossible.<\/p>\n

Detected when we ask to SYNC up to a specific RBA.<\/p>\n

Argument Description:<\/p>\n

a.\u00a0\u00a0\u00a0\u00a0RBA Sequence we want to Sync to<\/p>\n

b.\u00a0\u00a0\u00a0\u00a0RBA Block we want to Sync to<\/p>\n

c.\u00a0\u00a0\u00a0\u00a0Current LOG Sequence<\/p>\n

d.\u00a0\u00a0\u00a0\u00a0Current LOG Base Block<\/p>\n

e.\u00a0\u00a0\u00a0\u00a0Current LOG block being filled<\/p>\n

f.\u00a0\u00a0\u00a0\u00a0Flag (kcrfh.h):<\/p>\n

KCRFSFTOP 0x01 \/* Thread OPen *\/<\/p>\n

KCRFSFRGO 0x02 \/* Redo Generation Ok *\/<\/p>\n

KCRFSFBAD 0x04 \/* single process died in BAD state flag. *\/<\/p>\n

KCRFSFSAR 0x08 \/* log switch for space Stuck on ARchiver *\/<\/p>\n

KCRFSFRBA 0x10 \/* RBA capture Ok *\/<\/p>\n

KCRFSFSCL 0x20 \/* log switch for space Stuck on CLearing *\/<\/p>\n

Diagnosis:<\/p>\n

This is pretty fatal. Can be related to latching \/ memory problems so check for other similar memory corruption type errors.<\/p>\n

ORA-600 [2662]\u00a0\u00a0\u00a0\u00a0Block SCN is ahead of Current SCN
\n<\/strong><\/span><\/p>\n

ORA-600 [2662] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16\u00a0\u00a0\u00a0\u00a0– 7.1.3
\n<\/span><\/p>\n

Source: kcrf.h MACRO
\n<\/span><\/p>\n

Meaning:<\/p>\n

WARNING: There are 2 places this error could occur (in 7.0.16)<\/p>\n

1 Argument:<\/p>\n

If there is only 1 argument this is a problem generating an offline immediate log marker (kcrfwg).<\/p>\n

*THIS IS NOT DOCUMENTED HERE*
\n<\/span><\/p>\n

4 + Arguments:<\/p>\n

The SCN found on a block was ahead of the current SCN.<\/p>\n

This is the more common occurance .<\/p>\n

Argument Description:<\/p>\n

a.\u00a0\u00a0\u00a0\u00a0Current SCN WRAP<\/p>\n

b.\u00a0\u00a0\u00a0\u00a0Current SCN BASE<\/p>\n

c.\u00a0\u00a0\u00a0\u00a0Blocks SCN WRAP<\/p>\n

d.\u00a0\u00a0\u00a0\u00a0Blocks SCN BASE<\/p>\n

e.\u00a0\u00a0\u00a0\u00a0Source of the SCN\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0(not in 7.0.16)<\/p>\n

Diagnosis:<\/p>\n

– 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.<\/p>\n

– Attempting a startup serveral times may bypass this if the SCNs in\u00a0\u00a0\u00a0\u00a0the error are very close as startup bumps the SCN even if open fails.<\/p>\n

– 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.<\/p>\n

– ** You can bump the SCN on open using <Event:ADJUST_SCN><\/p>\n

Be aware that you should really rebuild the DB if you use this option.<\/p>\n

– If parallel server check both nodes are using the same lock manager instance & point at the same control files.<\/p>\n

– 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)<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

Bug:195115\u00a0\u00a0\u00a0\u00a0Miscalculation of SCN on startup for distributed TX ?<\/p>\n

\n

ORA-600 [2740] \u00a0\u00a0\u00a0\u00a0Log file unavailable
\n<\/strong><\/span><\/p>\n

ORA-600[2740][log#]<\/p>\n

kcrf – Kernel Cache Redo File management component implementation.<\/p>\n

Problem Description:<\/p>\n

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.<\/p>\n

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.<\/p>\n

Bugs Filed:<\/p>\n

205340 6.0.37.3.1<\/p>\n

205341 6.0.37.3.1<\/p>\n

Source Code: TBDL<\/p>\n

SOLUTION TO ORA-600 [2740]
\n<\/strong><\/p>\n

Solution Description:<\/p>\n

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.<\/p>\n

ORA-600 [2845]\u00a0\u00a0\u00a0\u00a0Read of bad DBA Requested
\n<\/strong><\/span><\/p>\n

ORA-600 [2845] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Version: 7.1.3 – 7.1.6
\n<\/span><\/p>\n

Source: .\/knl\/kcf.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

When asked to read a block in kcfrbd() {foreground} either the file number or block number for the DBA was invalid.<\/p>\n

Argument Description:<\/p>\n

a. File number requested (should be >0 and <= MAX)<\/p>\n

b. Maximum valid file number<\/p>\n

c. Block number requested.<\/p>\n

Diagnosis:<\/p>\n

NOTE: If you did a manual block dump this error could be reported.<\/p>\n

if the DBA requested in the blockdump was incorrect or mistyped.<\/p>\n

Get the trace file. The stack should show what operations are in progress.
\n<\/span><\/p>\n

Determine the DBA causing the problem and:
\n<\/span><\/p>\n

Dump the DBA
\n<\/span><\/p>\n

Dump the segment header for the object\u00a0\u00a0\u00a0\u00a0(See\u00a0\u00a0\u00a0\u00a0to find the object name)
\n<\/span><\/p>\n

If segment freelist shows that the head=0 and the tail=some_dba
\n<\/span><\/p>\n

AND a parallel create\/load has occurred on this object at some time in
\n<\/span><\/p>\n

the past see <Bug:251325>. The object will need rebuilding.
\n<\/span><\/p>\n

Otherwise see <Bug:226468>.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0 Description
\n<\/span><\/p>\n

7.1.5\u00a0\u00a0\u00a0\u00a0Bug:226468\u00a0\u00a0\u00a0\u00a0 CR problem<\/p>\n

7.1.6\u00a0\u00a0\u00a0\u00a0Bug:251325\u00a0\u00a0\u00a0\u00a0 Parallel create\/load caused corruption<\/p>\n

ORA-600 [2846]\u00a0\u00a0\u00a0\u00a0Block past end of file ?
\n<\/strong><\/span><\/p>\n

ORA-600 [2846] [a] [b] [c] [d]
\n<\/span><\/p>\n

Versions: 7.1.3 – 7.1.4
\n<\/span><\/p>\n

Source: kcf.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Request for a BLOCK which is beeyond the end of the data file.<\/p>\n

Argument Description:<\/p>\n

a. File number<\/p>\n

b. Block number requested<\/p>\n

c. Number of blocks requested<\/p>\n

d. File Size in blocks<\/p>\n

Diagnosis:<\/p>\n

Using the ANALYZE command with ESTIMATE ?<\/p>\n

– Use compute or upgrade to 7.1.6 or higher<\/p>\n

ANALYZE TABLE VALIDATE STRUCTURE CASCADE for the table indicated in the CURRENT SQL statement.<\/p>\n

ORA-600 [2854]\u00a0\u00a0\u00a0\u00a0Invalid Block Read Request
\n<\/strong><\/span><\/p>\n

ORA-600 [2845] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.16 – 7.X.X
\n<\/span><\/p>\n

Source: knl\/kcf.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Foreground process read was asked to read an invalid DBA.<\/p>\n

Argument Description:<\/p>\n

[a] = File Number asked for.<\/p>\n

[b] = Max File Number allowed.<\/p>\n

[c] = Block number asked for (Should be >1)<\/p>\n

Diagnosis:<\/p>\n

– This can be due to actual corruption of an index or table so:<\/p>\n

analyze table <tname> validate structure cascade;<\/p>\n

– Also check the table with a Full Table Scan of the table.<\/p>\n

– If not a corruption see <Bug:226468> below.<\/p>\n

Known Bugs:<\/p>\n

Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
\n<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0Bug:226468\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0CR problem<\/p>\n

ORA-600 [3020]\u00a0\u00a0\u00a0\u00a0Stuck Recovery
\n<\/strong><\/span><\/p>\n

ORA-600 [3020] [a] [b] [c] [d] [e]
\n<\/span><\/p>\n

Versions: 7.0.X\u00a0\u00a0\u00a0\u00a0– 7.1.4
\n<\/span><\/p>\n

Source: knl\/kcrp.c
\n<\/span><\/p>\n

Meaning:<\/p>\n

Recovering database and REDO entry has an INC\/SEQUENCE number greater than that on the database block by at least 2.<\/p>\n

This is called ‘STUCK RECOVERY’.<\/p>\n

Argument Description:<\/p>\n

a. Block DBA<\/p>\n

b. Redo Thread<\/p>\n

c. Redo RBA Seq<\/p>\n

d. Redo RBA Block No<\/p>\n

e. Redo RBA File No.<\/p>\n

Diagnosis:<\/p>\n

– \u00a0\u00a0\u00a0\u00a0Has customer restored a backup, open the DB, closed the DB and then tried to recover without re-loading the backup ??<\/p>\n

** 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.<\/p>\n

–\u00a0\u00a0\u00a0\u00a0The 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:<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0a) TIME\u00a0\u00a0\u00a0\u00a0or\u00a0\u00a0\u00a0\u00a0b) Minimal Data Loss.<\/p>\n

–\u00a0\u00a0\u00a0\u00a0Check the tracefile for the 3020 report. It is possible to signal OERI(3020) if the datafile block is corrupt.<\/p>\n

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.<\/p>\n

–\u00a0\u00a0\u00a0\u00a0parallel server being used ?<\/p>\n

If so another thread may have the required changes and they havent been read for some reason. Check for OS and DLM errors.<\/p>\n

Try to make sure only ONE instance attempts any recovery by shutting down other instances.<\/p>\n

– \u00a0\u00a0\u00a0\u00a0Are hot backups being used ??<\/p>\n

Check that the backups are occuring correctly between BEGIN and END backup commands.<\/p>\n

– \u00a0\u00a0\u00a0\u00a0You can try to skip the error using the hidden<\/p>\n

parameter:CORRUPT_BLOCKS_ON_STUCK_RECOVERY<\/p>\n

– \u00a0\u00a0\u00a0\u00a0For logging a bug you need:<\/p>\n

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

    ORA-600 [3339]\u00a0\u00a0\u00a0\u00a0Corrupt Block Detected
    \n<\/strong><\/span><\/p>\n

    ORA-600 [3339] [a] [b] [c] [d] [e]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a072\/134<\/p>\n

    Versions: 7.0.12 – 7.1.4<\/p>\n

    Meaning:<\/p>\n

    A corrupt block has been detected. The dba found in memory (which\u00a0\u00a0\u00a0\u00a0could have just been read from disk) does not match the DBA sought.<\/p>\n

    This could be due to either:<\/p>\n

    1. An on disk corruption OR<\/p>\n

    2. A corruption in memory after or during the block read from disk.<\/p>\n

    Argument Description:<\/p>\n

    a. This is the DBA found in the block itself (corrupt).<\/p>\n

    b. This is the DBA that we are searching for.<\/p>\n

    c. Trusted Oracle Only – the Trusted Database Address<\/p>\n

    Diagnosis:<\/p>\n

    – Calculate the File and Block number for the bad block<\/p>\n

    – Follow the block corruption steps<\/p>\n

    – NOTE: If there appears to be no segment with the DBA requested:<\/p>\n

    It could be a memory corruption<\/p>\n

    It could be a duff UBA in a block referencing a non existant DBA<\/p>\n

    – As OS dump of the block may be useful to determine if it looks like media OR memory.<\/p>\n

    Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    7.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:183357\u00a0\u00a0\u00a0\u00a0Analyze table compute statistics.<\/p>\n

    7.1.2\u00a0\u00a0\u00a0\u00a0Bug:186270\u00a0\u00a0\u00a0\u00a0* Direct loader and hot backup – Query against loaded data.<\/p>\n

    7.0.17\u00a0\u00a0\u00a0\u00a0Bug:179290\u00a0\u00a0\u00a0\u00a0Enable constraints\/analyze table..validate structure.<\/p>\n

    ORA-600 [3382]\u00a0\u00a0\u00a0\u00a0DBWR found an unexpected dirty block
    \n<\/strong><\/span><\/p>\n

    ORA-600 [3382] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.1.4 – 7.2.2
    \n<\/span><\/p>\n

    Source: kcbb.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    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.<\/p>\n

    Argument Description:<\/p>\n

    a. Pass through the invalidation loop<\/p>\n

    b. Low DBA of range being invalidated.<\/p>\n

    c. High DBA of range being invalidated<\/p>\n

    Diagnosis:<\/p>\n

    – 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..<\/p>\n

    Try to avoid truncate as there are numerous issues before 7.3.<\/p>\n

    – Is it occuring repeatedly ? and is it the same DBA range each time ?<\/p>\n

    – Get the file and block numbers for the DBA range and check what object they refer to:<\/p>\n

    \u00a0\u00a0\u00a0\u00a0SELECT\u00a0\u00a0\u00a0\u00a0segment_name ,\u00a0\u00a0\u00a0\u00a0segment_type ,\u00a0\u00a0\u00a0\u00a0owner , tablespace_nam<\/p>\n

    FROM\u00a0\u00a0\u00a0\u00a0sys.dba_extents<\/p>\n

    WHERE\u00a0\u00a0\u00a0\u00a0file_id = &bad_file_id<\/p>\n

    AND\u00a0\u00a0\u00a0\u00a0&bad_block_id BETWEEN block_id and block_id+blocks-1<\/p>\n

    – Check for overlapping extents. See<\/p>\n

    Known Issues:<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    7.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:146216\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Possible errors from Truncate.<\/p>\n

    ORA-600 [3398]\u00a0\u00a0\u00a0\u00a0Corrupt block detected by DBWR on before WRITE
    \n<\/strong><\/span><\/p>\n

    ORA-600 [3398] [a] [b] [c] [d] [e] [f]
    \n<\/span><\/p>\n

    Versions: 7.0.12 – 7.1.4
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    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.<\/p>\n

    This basically implies the block was corrupted in memory as we should have detected an error on read otherwise.<\/p>\n

    Argument Description:<\/p>\n

    a. DBA expected.<\/p>\n

    b. DBA found.<\/p>\n

    c. Version number of cached block. (Should equal 1)<\/p>\n

    d. The last 4 bytes of the block (Should match INC#SEQ# low order bytes)<\/p>\n

    e. Incarnation of cached block.<\/p>\n

    f. Sequence no of the cached block.<\/p>\n

    Diagnosis:<\/p>\n

    Very difficult as it is likely due to an overwrite from an adjacent write to the SGA or is due to some memory corruption.<\/p>\n

    The saving grace is that the block will NOT have been written to disk.<\/p>\n

    Bouncing the database several times may help show if this is a hardware problem.<\/p>\n

    Also try resizing the SGA (especially try to fit it into a single shared memory segment to rule out any multi-segment problems).<\/p>\n

    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\u00a0\u00a0\u00a0\u00a0soft corrupt the block thus rebuilding it.<\/p>\n

    This may allow you to at least get a DB open.<\/p>\n

    Alternatively for startup:<\/p>\n

    – identify the file ID of the file with the bad block<\/p>\n

    – Mount the database and get the filename from v$datafile<\/p>\n

    – You can try offlining the file. Obviously it depends what the DBA object is and what else is in this\u00a0\u00a0\u00a0\u00a0 TABLESPACE but you may be able to avoid the problem this way.<\/p>\n

    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.<\/p>\n

    ORA-600 [4146]\u00a0\u00a0\u00a0\u00a0Undo Block not new enough
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4146] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16 – 7.X.X
    \n<\/span><\/p>\n

    Source: ktur.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    Block not new enough (Undo)<\/p>\n

    Argument Description:<\/p>\n

    a. UBA Sequence expected ?<\/p>\n

    b. Sequence on the Undo block header ?<\/p>\n

    Diagnosis:<\/p>\n

    Basically a corruption.<\/p>\n

    How to find the segment causing an ora-600 [4146] \/ [4147]<\/p>\n

    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.<\/p>\n

    After this will be a number. The number will either be in decimal or<\/p>\n

    2. Then run the following query:<\/p>\n

    SELECT segment_name,segment_type<\/p>\n

    FROM sys.dba_extents<\/p>\n

    WHERE file_id = <fileid><\/p>\n

    and <blockid> between block_id and block_id + blocks – 1<\/p>\n

    eg.<\/p>\n

    SELECT \u00a0\u00a0\u00a0\u00a0segment_name,segment_type<\/p>\n

    FROM \u00a0\u00a0\u00a0\u00a0sys.dba_extents<\/p>\n

    WHERE \u00a0\u00a0\u00a0\u00a0file_id = 2<\/p>\n

    and \u00a0\u00a0\u00a0\u00a01450 between block_id and block_id + blocks – 1<\/p>\n

    This should return one row. If not then recheck the above.<\/p>\n

    Example output from the trace file<\/p>\n

    —————————————–<\/p>\n

    Dump file \/usr\/oracle\/rdbms\/log\/22_24397.trc<\/p>\n

    ORACLE RDBMS V6.0.37.3.1 transaction processing option – Production<\/p>\n

    ORACLE_HOME = \/usr\/oracle<\/p>\n

    ORACLE_SID = gsm01<\/p>\n

    Oracle process number: 22 Unix process if:24397<\/p>\n

    System name: HP-UX<\/p>\n

    Node name: hydrogen<\/p>\n

    Release: A.09.01<\/p>\n

    Version: A<\/p>\n

    Machine: 9000\/755<\/p>\n

    Dump of buffer cache at level 2<\/p>\n

    BH #5837 (0x802fb030) dba: 500006eb class 14 ba:81112c00<\/p>\n

    …..<\/p>\n

    Call Stack Trace<\/p>\n

    …..<\/p>\n

    at end of trace<\/p>\n

    BH #755 (0x802573c8) dba: 80000003 class 1 ba: 80725c00<\/p>\n

    hash: [80340024,8038c3c4], lru: [802912e8,8033657c]<\/p>\n

    use: [803886a0,803886a0], wait: [NULL]<\/p>\n

    st: CR, md: EXCL, rsop: 0<\/p>\n

    cr:[[scn: 0.00dbbeab],[xid:07.1b.5849],[uba: 500004e6.206a.02], sfl: 1<\/p>\n

    flags: buffer_dirty_only_sequential_access<\/p>\n

    L:[0.0.0] H:[0.0.0] R:[0.0.0]<\/p>\n

    Using State Objects<\/p>\n

    In this example, uba address is: 500004e6 which translates to:<\/p>\n

    file_id=20, block_id=1254<\/p>\n

    undo segment # = 07<\/p>\n

    3. If this does not return any rows, then one can dump the rollback segment<\/p>\n

    header which will show the extent map to determine the whether the query should have returned any rows.<\/p>\n

    To dump the rollback segment header.<\/p>\n

    1. Before the uba: there should be the characters xid:<\/p>\n

    eg. xid: 07.xx.xxxxx uba:<\/p>\n

    For the first number after xid: this is the undo segment # which is giving the problem.<\/p>\n

    To find the undo segment<\/p>\n

    select * from sys.undo$ where id# = <undo segment #><\/p>\n

    eg. select * from sys.undo$ where id# = 7;<\/p>\n

    This will return one row. Find the values in the columns<\/p>\n

    file_id = <ff><\/p>\n

    block_id = <bbbbb><\/p>\n

    These are in decimal. Change to hex and use to dump the rollback segment header.<\/p>\n

    >From sqlplus:<\/p>\n

    alter session set events ‘immediate trace name blockdump level <nnnnnnnn><\/p>\n

    This will produce a trace file in user_dump_dest which will show the extent map for the rollback segment.<\/p>\n

    Can be caused by:<\/p>\n

    \u00a0\u00a0\u00a0\u00a0a) A lost write\u00a0\u00a0\u00a0\u00a0 – Get OS \/ hardware checked<\/p>\n

    or\u00a0\u00a0\u00a0\u00a0b) Database has been forced open<\/p>\n

    Eg: _allow_resetlogs_corruption used.<\/p>\n

    ORA-600 [4147]\u00a0\u00a0\u00a0\u00a0Undo Block not new enough
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4147] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16 – 7.X.X
    \n<\/span><\/p>\n

    Source: ktur.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    Block not new enough (Undo). Sequences match but count wrong.<\/p>\n

    Argument Description:<\/p>\n

    a. Count expected ?<\/p>\n

    b. Count on the Undo block header ?<\/p>\n

    Diagnosis:<\/p>\n

    Basically a corruption.<\/p>\n

    How to find the segment causing an ora-600 [4146] \/ [4147]<\/p>\n

    same as ora-600[4146]<\/p>\n

    ORA-600 [4306]\u00a0\u00a0\u00a0\u00a0Duplicate row in fet$\/uet$ dropping Temp Segment
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4306] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16 – 7.X.X
    \n<\/span><\/p>\n

    Source: kts.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    Duplicate row in fet$\/uet$ when dropping a Temp Segment.<\/p>\n

    Argument Description:<\/p>\n

    a. File Number of duplicate entry<\/p>\n

    b. Block Number of duplicate entry<\/p>\n

    Diagnosis:<\/p>\n

    Use event 10061 to get around – See bug (search on 4302\/10061)<\/p>\n

    Check fet$\/uet$ using:<\/p>\n

    select * from fet$<\/p>\n

    where file#=n<\/p>\n

    and b between block# and block# +length -1<\/p>\n

    \/<\/p>\n

    Select * from uet$<\/p>\n

    where file#=n<\/p>\n

    and b between block# and block# +length -1<\/p>\n

    \/<\/p>\n

    If no rows in uet$ (can widen search for just file#=n) then just try straight startup if none found.<\/p>\n

    If both entries found then recreate the TEMP tspace.<\/p>\n

    ORA-600 [4310]\u00a0\u00a0\u00a0\u00a0Bad Starting Extent
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4310] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.X.X\u00a0\u00a0\u00a0\u00a0– 7.2.2
    \n<\/span><\/p>\n

    Source: kts.c(ktslex)
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    When retrieving details of the extents within a segment the number of the starting extent was greater than the total number of extents.<\/p>\n

    Argument Description:<\/p>\n

    a. Starting extent returned<\/p>\n

    b. Number of extents<\/p>\n

    Diagnosis:<\/p>\n

    Can arise when selecting from a truncated table.<\/p>\n

    The error is likely to be a one off as there is a small window where the problem can occur.<\/p>\n

    Known Bugs:<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0 Bug No.\u00a0\u00a0\u00a0\u00a0 Description
    \n<\/span><\/p>\n

    7.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Bug:146216\u00a0\u00a0\u00a0\u00a0Truncate & set transaction read only Errors.<\/p>\n

    7.3\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Bug:270684\u00a0\u00a0\u00a0\u00a0Changes to ROWID verification<\/p>\n

    ORA-600 [4414]\u00a0\u00a0\u00a0\u00a0Error popping Errorstack Savepoint
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4414] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16\u00a0\u00a0\u00a0\u00a0– 7.1.3
    \n<\/span><\/p>\n

    Source: include\/ktc.h
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    We went to pop an errorstack savepoint but there was no savepoint<\/p>\n

    NOTE: This could occur in many places in the code whereever\u00a0\u00a0\u00a0\u00a0the the macro ‘ktcpos()’ is used.<\/p>\n

    Argument Description:<\/p>\n

    a. Old error
    \n<\/span><\/p>\n

    b. Old level
    \n<\/span><\/p>\n

    c. Current error ?
    \n<\/span><\/p>\n

    d. Current level ?
    \n<\/span><\/p>\n

    Diagnosis:<\/p>\n

    – Check in the trace file for ORA 1092 or a similar shutdown message.<\/p>\n

    If this is the case then this is probably <Bug:177032> and this<\/p>\n

    error is not the CAUSE of a problem but is the result of either:<\/p>\n

    – a) A shutdown immediate \/ abort being issued manually<\/p>\n

    – b) A DB crash caused by some other problem – so look for other trace information.<\/p>\n

    Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

    Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    7.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:177032 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ORA 600 4414 Signalled during shutdown.<\/p>\n

    ORA-600 [4421]\u00a0\u00a0\u00a0\u00a0Rollback but no transaction control block
    \n<\/strong><\/span><\/p>\n

    ORA-600[4421][N]<\/p>\n

    ktc – Kernel Transaction Control<\/p>\n

    Problem Description:<\/p>\n

    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.<\/p>\n

    Problem Explanation:<\/p>\n

    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).<\/p>\n

    Bugs Filed:<\/p>\n

    85073 6.0.34<\/p>\n

    135883 6.0.34<\/p>\n

    78013 6.0.33<\/p>\n

    Source Code: TBDL<\/p>\n

    ORA-600 [4502]\u00a0\u00a0\u00a0\u00a0ITL lock count doesnt tally with rows.
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4502] [a]
    \n<\/span><\/p>\n

    Versions: 7.0.16\u00a0\u00a0\u00a0\u00a0– 7.2.2
    \n<\/span><\/p>\n

    Source: ktb.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    During ITL cleanout we clear all row locks but the ITL entry still thinks there is an uncleared lock.<\/p>\n

    Ie: ITL has a locked row but there are no locked rows in the block ?<\/p>\n

    Argument Description:<\/p>\n

    a. ITL entry with a lock count<\/p>\n

    Diagnosis:<\/p>\n

    Raised in ktbrcl() – ITL cleanout redo routine.<\/p>\n

    – There should be a current mode buffer pinned in the processstate dump with the error.<\/p>\n

    See the ITL section of .<\/p>\n

    Confirm the pinnd block is incorrect and then note:<\/p>\n

    1)\u00a0\u00a0\u00a0\u00a0the bad DBA<\/p>\n

    2)\u00a0\u00a0\u00a0\u00a0the problem object id.<\/p>\n

    – Current block is corrupt so check if the problem is repeatable\u00a0\u00a0\u00a0\u00a0(FTS on the table)<\/p>\n

    Bottom line: Get onto 7.1.6 or higher. Prior to this any of:<\/p>\n

    Adding Longs to existing table ?<\/p>\n

    Trailing nulls ?<\/p>\n

    RBS extension problems (minextents!=maxextents)<\/p>\n

    Bugs Filed:<\/p>\n

    Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No. \u00a0\u00a0\u00a0\u00a0Description<\/span><\/p>\n

    7.1.3 Bug:198383 \u00a0\u00a0\u00a0\u00a0Corruptions during cleanout of MRP.<\/p>\n

    7.1.4 Bug:208665 \u00a0\u00a0\u00a0\u00a0Problems with trailing nulls.<\/p>\n

    \u00a0\u00a0\u00a0\u00a0Eg: fb: KCHDFLPN lb: 0xff in buffer dump.<\/p>\n

    7.2.3 Bug:282541 \u00a0\u00a0\u00a0\u00a07.2 Bad UNDO for “Move Row Piece” ops. Possibly??<\/p>\n

    \n

    ORA-600 [4519]\u00a0\u00a0\u00a0\u00a0Clock Corruption Detected – Cache type wrong
    \n<\/strong><\/span><\/p>\n

    ORA-600 [4519] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Version: 7.0.12 – 7.1.4
    \n<\/span><\/p>\n

    Source: KTR.C
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    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’).<\/p>\n

    Argument Description:<\/p>\n

    a. DBA of the corrupt block.<\/p>\n

    b. Block type found.<\/p>\n

    Diagnosis:<\/p>\n

    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.<\/p>\n

    Work out the object and perform an FTS and scan via any relevant\u00a0\u00a0\u00a0\u00a0index to see if the error repeats. Failing indexes may be rebuilt.<\/p>\n

    a. Use db_block_cache_protect parameter if available on the port.<\/p>\n

    b. Use archivelogmode to help to see when corruption occurs.<\/p>\n

    c. Use the event 10200 to show blocks obtained by consistent read.<\/p>\n

    New event 10208 ??? (Introduced later for ktrget() bug).<\/p>\n

    d.Enable data\/index block checking using events 10210 andd 10211.<\/p>\n

    e.Use event 10288 to skip this check (block type) on the block.<\/p>\n

    (NOT RECOMMENDED)<\/p>\n

    Known Bugs: (Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

    Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    ?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:185395 \u00a0\u00a0\u00a0\u00a0Alter table add constraint on NCR.<\/p>\n

    7.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:183357 \u00a0\u00a0\u00a0\u00a0Using analyze table using 7.1. (Bugged under 7.0.13).<\/p>\n

    7.0.15\u00a0\u00a0\u00a0\u00a0Bug:161236 \u00a0\u00a0\u00a0\u00a0Updating a table under specific conditions.<\/p>\n

    ORA-600 [504]\u00a0\u00a0\u00a0\u00a0Trying to obtain a latch which is already held
    \n<\/strong><\/span><\/p>\n

    ORA-600 [504] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16 – 7.X.X
    \n<\/span><\/p>\n

    Source: KSL.C
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    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 ?).<\/p>\n

    Argument Description:<\/p>\n

    a.\u00a0\u00a0\u00a0\u00a0Address(?) of latch we are trying to lock.<\/p>\n

    b.\u00a0\u00a0\u00a0\u00a0Level of latch we have currently got.<\/p>\n

    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.<\/p>\n

    c.\u00a0\u00a0\u00a0\u00a0Level of latch we are trying to obtain ?<\/p>\n

    d.\u00a0\u00a0\u00a0\u00a0Description of the lock\/latch we are attempting to attain.<\/p>\n

    Known Bugs: \u00a0\u00a0\u00a0\u00a0(Those Known Bugs:that are fixed after version 7.0.12.0.0)<\/p>\n

    Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/p>\n

    ?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:182130 \u00a0\u00a0\u00a0\u00a0On startup. \u00a0\u00a0\u00a0\u00a0[row cache objects].<\/p>\n

    7.0.13\u00a0\u00a0\u00a0\u00a0Bug:179115 \u00a0\u00a0\u00a0\u00a0NCR create indexes.\u00a0\u00a0\u00a0\u00a0[lock element parent latch].<\/p>\n

    7.0.15\u00a0\u00a0\u00a0\u00a0Bug:177900 \u00a0\u00a0\u00a0\u00a0P.Server: PMON gives [504] for row cache latch.<\/p>\n

    –\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:179850 \u00a0\u00a0\u00a0\u00a0Dumping using systemstate. \u00a0\u00a0\u00a0\u00a0[lock element parent latch].
    \n<\/span><\/p>\n

    ?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:172589 \u00a0\u00a0\u00a0\u00a0While dumping using alter session\/event.<\/p>\n

    7.0.17\u00a0\u00a0\u00a0\u00a0Bug:177818 \u00a0\u00a0\u00a0\u00a0When dropping user.\u00a0\u00a0\u00a0\u00a0[lock element parent latch].<\/p>\n

    ORA-600 [510]\u00a0\u00a0\u00a0\u00a0Latching Problem
    \n<\/strong><\/span><\/p>\n

    ORA-600[510][latch_addr][child_latch][]
    \n<\/span><\/p>\n

    ksl.c – Kernel Service layer Latching & Wait-post Implementation
    \n<\/span><\/p>\n

    Problem Description:<\/p>\n

    This error indicates a call was made to free a child latch that is unowned.<\/p>\n

    Problem Explanation:<\/p>\n

    The second argument indicates the address of the latch in question.\u00a0\u00a0\u00a0\u00a0The third argument indicates the type of child latch that the kernel attempted to free.<\/p>\n

    Call Stack Trace:<\/p>\n

    SP \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0PC\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Name
    \n<\/span><\/p>\n

    0x7ff779c8 \u00a0\u00a0\u00a0\u00a00x0051de4c \u00a0\u00a0\u00a0\u00a0sdtcs(a0=0x0) = 0x51dda8 + 0xa4<\/p>\n

    0x7ff77d48 \u00a0\u00a0\u00a0\u00a00x004f9598 \u00a0\u00a0\u00a0\u00a0ssexhd(a0=0x4) = 0x4f94ec + 0xac<\/p>\n

    0x7ff77d68 \u00a0\u00a0\u00a0\u00a00x6fc1f110 \u00a0\u00a0\u00a0\u00a0<unknown> — nearest symbol is sigsetjmp(, a2=0x7ff77da04<\/p>\n

    0x7ff77d90 \u00a0\u00a0\u00a0\u00a00x3102b0f8 \u00a0\u00a0\u00a0\u00a0() = 0x0 + 0x3102b0f8<\/p>\n

    Unable to continue due to an illegal address (0x2ffffffc).<\/p>\n

    Other Information:<\/p>\n

    Other platform specific init.ora parameters to consider are:<\/p>\n

    _latch_spin_count<\/p>\n

    _latch_wait_posting<\/p>\n

    _max_sleep_holding_latch<\/p>\n

    _db_block_multiple_hashchain_latches<\/p>\n

    if they are default values – you may want to vary the values.<\/p>\n

    Known Bugs:<\/p>\n

    Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Status
    \n<\/span><\/p>\n

    329487\u00a0\u00a0\u00a0\u00a07.3.1.0.0\u00a0\u00a0\u00a0\u00a0HP\/UX HP 98XX series\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a07.3.2<\/p>\n

    315721\u00a0\u00a0\u00a0\u00a07.1.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Sequent DYNIX\/ptx\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

    305330\u00a0\u00a0\u00a0\u00a07.1.4.1.1\u00a0\u00a0\u00a0\u00a0Silicon Graphics Unix\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a090<\/p>\n

    296257\u00a0\u00a0\u00a0\u00a07.0.15\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Pyramid DC\/OSx MIPS Unix\u00a0\u00a0\u00a0\u00a091<\/p>\n

    Source Code: TBDL<\/p>\n

    SOLUTION TO ORA-600 [510]
    \n<\/strong><\/p>\n

    Solution Description:<\/p>\n

    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:<\/p>\n

    Select count(*) number_of_waiters<\/p>\n

    from v$session_wait w, v$latch l<\/p>\n

    where w.wait_time = 0<\/p>\n

    \u00a0\u00a0\u00a0\u00a0and\u00a0\u00a0\u00a0\u00a0w.event\u00a0\u00a0\u00a0\u00a0 = ‘latch free’<\/p>\n

    and\u00a0\u00a0\u00a0\u00a0w.p2\u00a0\u00a0\u00a0\u00a0= l.latch#<\/p>\n

    and\u00a0\u00a0\u00a0\u00a0l.name\u00a0\u00a0\u00a0\u00a0like ‘library%’;<\/p>\n

    If you have more than 2 processes waiting for the library cache or library cache pin latch then this could be the problem.\u00a0\u00a0\u00a0\u00a0Dumping the system state periodically will also reveal helpful information with respect to time:
    \n<\/span><\/p>\n

    alter session set events ‘immediate trace name systemstate level 10’;
    \n<\/span><\/p>\n

    It is also very useful to just select from v$session_wait to determine what else is causing slowdown:
    \n<\/span><\/p>\n

    select * from v$session_wait<\/p>\n

    where event != ‘client message’
    \n<\/span><\/p>\n

    and event not like ‘%NET%’
    \n<\/span><\/p>\n

    and wait_time = 0
    \n<\/span><\/p>\n

    and sid > 5;
    \n<\/span><\/p>\n

    Solution Explanation:<\/p>\n

    There are numerous bulletins on how to extract data froming a hanging database.<\/p>\n

    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.<\/p>\n

    ORA-600 [512]\u00a0\u00a0\u00a0\u00a0Latching Problem
    \n<\/strong><\/span><\/p>\n

    ORA-600[512][][][]<\/p>\n

    ksl.c – Kernel Service layer Latching & Wait-post Implementation<\/p>\n

    Problem Description:<\/p>\n

    This error indicates an Operating System Dependent (OSD) free latch routine returned an error.<\/p>\n

    Generally this error is accompanied by another error (sometimes ORA-600[510] (trying to free an unowned child latch)).<\/p>\n

    Problem Explanation:<\/p>\n

    Usually a background process or user process will die with the occurance of this error.\u00a0\u00a0\u00a0\u00a0Note that it is Operating System Dependent and usually will be handled differently depending upon the platform.<\/p>\n

    Other Information:<\/p>\n

    Other platform specific init.ora parameters to consider are:<\/p>\n

    _latch_spin_count
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0_latch_wait_posting
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0_max_sleep_holding_latch
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0_db_block_multiple_hashchain_latches
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0if they are default values – you may want to vary the values.
    \n<\/span><\/p>\n

    Known Bugs:<\/p>\n

    Bug\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Version\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Platform\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Status
    \n<\/span><\/p>\n

    291773\u00a0\u00a0\u00a0\u00a07.0.16.6.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Siemens-Nixdorf RM-400\u00a0\u00a0\u00a0\u00a091<\/p>\n

    198261\u00a0\u00a0\u00a0\u00a07.0.15.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0HP 98xx HP\/UX\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a091<\/p>\n

    268553\u00a0\u00a0\u00a0\u00a07.0.16.4.0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DG AViiON\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a030<\/p>\n

    Source Code: TBDL<\/p>\n

    SOLUTION TO ORA-600 [512]
    \n<\/strong><\/p>\n

    Solution Description:<\/p>\n

    Gather all necessary information from the alert log, trace files and dumps.
    \n<\/span><\/p>\n

    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:
    \n<\/span><\/p>\n

    select count(*) number_of_waiters
    \n<\/span><\/p>\n

    from v$session_wait w, v$latch l
    \n<\/span><\/p>\n

    where w.wait_time = 0
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0and w.event = ‘latch free’<\/p>\n

    and w.p2 = l.latch#<\/p>\n

    and l.name like ‘library%’;<\/p>\n

    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:<\/p>\n

    alter session set events ‘immediate trace name systemstate level 10’;<\/p>\n

    It is also very useful to just select from v$session_wait to determine what
    \n<\/span><\/p>\n

    else is causing a slowdown:
    \n<\/span><\/p>\n

    select * from v$session_wait<\/p>\n

    where event != ‘client message’
    \n<\/span><\/p>\n

    and event not like ‘%NET%’
    \n<\/span><\/p>\n

    and wait_time = 0
    \n<\/span><\/p>\n

    and sid > 5;
    \n<\/span><\/p>\n

    Solution Explanation:<\/p>\n

    There are numerous bulletins on how to extract data froming a hanging database.
    \n<\/span><\/p>\n

    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.\u00a0\u00a0\u00a0\u00a0If the library cache latch is causing the most number of sleeps then you may have a problem.\u00a0\u00a0\u00a0\u00a0One thing to watch out for here is that this information is
    \n<\/span><\/p>\n

    accumulated since the database starts, and so it may not show problems that are intermittent in nature.
    \n<\/span><\/p>\n

    ORA-600 [6008]\u00a0\u00a0\u00a0\u00a0Invalid Opcode operating on Index Block\/Key
    \n<\/strong><\/span><\/p>\n

    ORA-00600[6008][N]<\/p>\n

    kdi – Kernel Data layer Index component<\/p>\n

    Problem Description:<\/p>\n

    An invalid opcode is encountered while operating on an index block or key.<\/p>\n

    Problem Explanation:<\/p>\n

    This error has been logged multiple times on version 6 of the RDBMS.\u00a0\u00a0\u00a0\u00a0It is generally accompanied by some form of corruption (ora-600[3398]).\u00a0\u00a0\u00a0\u00a0This section of the code has not changed from version 6 to 7.2.2.\u00a0\u00a0\u00a0\u00a0It is a default case condition for a switch that should never occur. The second argument is the evaluated result of the switch vector.
    \n<\/span><\/p>\n

    Could be as a result of kernel cache buffer corruption causing the switch to traverse the default condition.\u00a0\u00a0\u00a0\u00a0Other Known Bugs:have included ORA-1578 which indicates data block corruption. All Known Bugs:logged have been non-reproducible.
    \n<\/span><\/p>\n

    Known Bugs:<\/p>\n

    173919 \u00a0\u00a0\u00a0\u00a0Sun4\u00a0\u00a0\u00a0\u00a0Could not reproduce.<\/p>\n

    147224 \u00a0\u00a0\u00a0\u00a0OS\/2\u00a0\u00a0\u00a0\u00a0Closed, not a bug.<\/p>\n

    Solution Description:<\/p>\n

    Rebuilding the objects involved is the best insurance for object integrity.
    \n<\/span><\/p>\n

    This error condition is infrequent and has not been reproducible.\u00a0\u00a0\u00a0\u00a0Much speculation on how this error occurs but little has been proven.\u00a0\u00a0\u00a0\u00a0This error is more passive and does not crash the instance.
    \n<\/span><\/p>\n

    Note that some form of corruption usually accompanied these errors in the bug reports.\u00a0\u00a0\u00a0\u00a0Either buffer cache or block corruption possibly has contributed to this error. Block checking could also aid in the prevention of this error.<\/p>\n

    Other Information:<\/p>\n

    Turn on block checking in init.ora:<\/p>\n

    (_)DB_BLOCK_CACHE_PROTECT=TRUE.<\/p>\n

    Workaround(s):<\/p>\n

    The workaround is to analyze the table (index) associated with the error.<\/p>\n

    Based on the results of the analyze, rebuild the objects necessary:<\/p>\n

    Determine which table is involved with the error.<\/p>\n

    Alert logs and trace files assist in this determination.<\/p>\n

    Analyze the objects involved:<\/p>\n

    ANALYZE TABLE tblname VALIDATE STRUCTURE CASCADE\u00a0\u00a0\u00a0\u00a0(table and index)<\/p>\n

    ANALYZE INDEX idxname VALIDATE STRUCTURE (index only)<\/p>\n

    Rebuild index \/ table.<\/p>\n

    Procedure:<\/p>\n

    Drop table.<\/p>\n

    Drop index.<\/p>\n

    Import table.<\/p>\n

    Create index.<\/p>\n

    ORA-600 [6009]\u00a0\u00a0\u00a0\u00a0Problem with Index ITL slot.
    \n<\/strong><\/span><\/p>\n

    ORA-600 [6009] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.15\u00a0\u00a0\u00a0\u00a0– 7.1.6
    \n<\/span><\/p>\n

    Source: kdi.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    On a purge hole (kdipurgeshole) from an index a service transaction had problems getting the service ITL.<\/p>\n

    Argument Description:<\/p>\n

    a. itl space<\/p>\n

    Diagnosis:<\/p>\n

    This can be from a corrupt index or a CR issue.<\/p>\n

    First step is to:<\/p>\n

    ANALYZE TABLE XXX VALIDATE STRUCTURE CASCADE;<\/p>\n

    If this succeeds (statement processed) it is probably a CR issue.
    \n<\/span><\/p>\n

    Otherwise treat it as a corruption. See the trace file produced by the ANALYZE command.
    \n<\/span><\/p>\n

    Additional Notes:<\/p>\n

    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.
    \n<\/span><\/p>\n

    Known Bugs:<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0<Bug:190929>\u00a0\u00a0\u00a0\u00a0600 6009 CR problem.<\/p>\n

    ORA-600 [6590]\u00a0\u00a0\u00a0\u00a0Block corruption
    \n<\/strong><\/span><\/p>\n

    ORA-600 [6590] [a] [b] [c] [d] [e]
    \n<\/span><\/span><\/p>\n

    Versions: 7.0.16 – 7.X.X
    \n<\/span><\/p>\n

    Source: kdo.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    If block checking is on we have found a corrupt block.<\/p>\n

    Argument Description:<\/p>\n

    a. Check number indicates corruption found.
    \n<\/span><\/p>\n

    Diagnosis:<\/p>\n

    The block should be dumped to trace with:<\/p>\n

    redo record, before-image, and after image<\/p>\n

    Check [a] for the type of corruption (kdb.h):<\/p>\n

    KDBCHKOK\u00a0\u00a0\u00a0\u00a00\u00a0\u00a0\u00a0\u00a0\/* block ok *\/
    \n<\/span><\/p>\n

    KDBCHKNE\u00a0\u00a0\u00a0\u00a01\u00a0\u00a0\u00a0\u00a0\/* row locked by non-existent transaction *\/
    \n<\/span><\/p>\n

    KDBCHKRB\u00a0\u00a0\u00a0\u00a02\u00a0\u00a0\u00a0\u00a0\/* row begins beyond end of block *\/
    \n<\/span><\/p>\n

    KDBCHKRE\u00a0\u00a0\u00a0\u00a03\u00a0\u00a0\u00a0\u00a0\/* row ends beyond end of block *\/
    \n<\/span><\/p>\n

    KDBCHKRM\u00a0\u00a0\u00a0\u00a04\u00a0\u00a0\u00a0\u00a0\/* row begins in the middle of another *\/
    \n<\/span><\/p>\n

    KDBCHKRA\u00a0\u00a0\u00a0\u00a05\u00a0\u00a0\u00a0\u00a0\/* row ends in the middle of another *\/
    \n<\/span><\/p>\n

    KDBCHKFN\u00a0\u00a0\u00a0\u00a06\u00a0\u00a0\u00a0\u00a0\/* free list not ordered *\/
    \n<\/span><\/p>\n

    KDBCHKFS\u00a0\u00a0\u00a0\u00a07\u00a0\u00a0\u00a0\u00a0\/* free slots not on the free list *\/
    \n<\/span><\/p>\n

    KDBCHKXM\u00a0\u00a0\u00a0\u00a08\u00a0\u00a0\u00a0\u00a0\/* xaction header lock count mismatch *\/
    \n<\/span><\/p>\n

    KDBCHKBX\u00a0\u00a0\u00a0\u00a09\u00a0\u00a0\u00a0\u00a0\/* bogus transaction locks present *\/
    \n<\/span><\/p>\n

    KDBCHKSU \u00a0\u00a0\u00a0\u00a010\u00a0\u00a0\u00a0\u00a0\/* space used is not equal to block size *\/
    \n<\/span><\/p>\n

    KDBCHKSC \u00a0\u00a0\u00a0\u00a011\u00a0\u00a0\u00a0\u00a0\/* space available on commit is incorrect *\/
    \n<\/span><\/p>\n

    KDBCHKKT \u00a0\u00a0\u00a0\u00a012\u00a0\u00a0\u00a0\u00a0\/* Key in Table other than zero *\/
    \n<\/span><\/p>\n

    KDBCHKCT \u00a0\u00a0\u00a0\u00a013\u00a0\u00a0\u00a0\u00a0\/* Cluster row in table zero *\/
    \n<\/span><\/p>\n

    KDBCHKKR \u00a0\u00a0\u00a0\u00a014\u00a0\u00a0\u00a0\u00a0\/* Key reference count incorrect *\/
    \n<\/span><\/p>\n

    KDBCHKFB \u00a0\u00a0\u00a0\u00a015\u00a0\u00a0\u00a0\u00a0\/* row Forwards to same Block *\/
    \n<\/span><\/p>\n

    KDBCHKBB \u00a0\u00a0\u00a0\u00a016\u00a0\u00a0\u00a0\u00a0\/* row has Backward reference to same Block *\/
    \n<\/span><\/p>\n

    KDBCHKFC \u00a0\u00a0\u00a0\u00a017\u00a0\u00a0\u00a0\u00a0\/* Free list beyond row Count in block *\/
    \n<\/span><\/p>\n

    KDBCHKNR \u00a0\u00a0\u00a0\u00a018\u00a0\u00a0\u00a0\u00a0\/* Negative current Reference count on key *\/
    \n<\/span><\/p>\n

    KDBCHKCL \u00a0\u00a0\u00a0\u00a019\u00a0\u00a0\u00a0\u00a0\/* Current refs Less than com refs *\/
    \n<\/span><\/p>\n

    KDBCHKNC \u00a0\u00a0\u00a0\u00a020\u00a0\u00a0\u00a0\u00a0\/* Negative Com reference count on key *\/
    \n<\/span><\/p>\n

    KDBCHKCW \u00a0\u00a0\u00a0\u00a021\u00a0\u00a0\u00a0\u00a0\/* Com reference count on key Wrong *\/
    \n<\/span><\/p>\n

    KDBCHKFW \u00a0\u00a0\u00a0\u00a022\u00a0\u00a0\u00a0\u00a0\/* Flush flag wrong *\/
    \n<\/span><\/p>\n

    KDBCHKLI \u00a0\u00a0\u00a0\u00a023\u00a0\u00a0\u00a0\u00a0\/* row Length Inconsistency *\/
    \n<\/span><\/p>\n

    KDBCHKTO \u00a0\u00a0\u00a0\u00a024\u00a0\u00a0\u00a0\u00a0\/* Table Offset incorrect *\/
    \n<\/span><\/p>\n

    KDBCHKRC \u00a0\u00a0\u00a0\u00a025\u00a0\u00a0\u00a0\u00a0\/* Row Count in table index incorrect *\/
    \n<\/span><\/p>\n

    KDBCHKAB \u00a0\u00a0\u00a0\u00a026\u00a0\u00a0\u00a0\u00a0\/* Available space count Bad *\/
    \n<\/span><\/p>\n

    KDBCHKTB \u00a0\u00a0\u00a0\u00a027\u00a0\u00a0\u00a0\u00a0\/* Total space count Bad *\/
    \n<\/span><\/p>\n

    KDBCHKAT \u00a0\u00a0\u00a0\u00a028\u00a0\u00a0\u00a0\u00a0\/* Available space greater than Total *\/
    \n<\/span><\/p>\n

    KDBCHKFO \u00a0\u00a0\u00a0\u00a029\u00a0\u00a0\u00a0\u00a0\/* Free Space beginning Offset bad *\/
    \n<\/span><\/p>\n

    KDBCHKFE \u00a0\u00a0\u00a0\u00a030\u00a0\u00a0\u00a0\u00a0\/* Free space Ending offset bad *\/
    \n<\/span><\/p>\n

    KDBCHKKL \u00a0\u00a0\u00a0\u00a031\u00a0\u00a0\u00a0\u00a0\/* Key Links bad *\/
    \n<\/span><\/p>\n

    KDBCHKTN \u00a0\u00a0\u00a0\u00a032\u00a0\u00a0\u00a0\u00a0\/* Trailing Null column stored *\/
    \n<\/span><\/p>\n

    KDBCHKBS \u00a0\u00a0\u00a0\u00a033\u00a0\u00a0\u00a0\u00a0\/* Bad Stub size (will not forward properly) *\/
    \n<\/span><\/p>\n

    KDBCHKUL \u00a0\u00a0\u00a0\u00a034\u00a0\u00a0\u00a0\u00a0\/* Undo for piece will be too Large *\/
    \n<\/span><\/p>\n

    KDBCHKRO \u00a0\u00a0\u00a0\u00a035\u00a0\u00a0\u00a0\u00a0\/* Row Offset is not between kdbhfseo and ktbidl *\/
    \n<\/span><\/p>\n

    KDBCHKKI \u00a0\u00a0\u00a0\u00a036\u00a0\u00a0\u00a0\u00a0\/* Key locking Itl is not KTBSRVI *\/
    \n<\/span><\/p>\n

    KDBCHKIS \u00a0\u00a0\u00a0\u00a037\u00a0\u00a0\u00a0\u00a0\/* Illegal Service transaction *\/
    \n<\/span><\/p>\n

    KDBCHKTK \u00a0\u00a0\u00a0\u00a038\u00a0\u00a0\u00a0\u00a0\/* Too many (> KDRMAXCK) cluster keys in block *\/
    \n<\/span><\/p>\n

    KDBCHKDK \u00a0\u00a0\u00a0\u00a039\u00a0\u00a0\u00a0\u00a0\/* Duplicate cluster Keys in block *\/
    \n<\/span><\/p>\n

    KDBCHKNK \u00a0\u00a0\u00a0\u00a040\u00a0\u00a0\u00a0\u00a0\/* Non-existent Key referenced *\/
    \n<\/span><\/p>\n

    KDBCHKBC \u00a0\u00a0\u00a0\u00a041\u00a0\u00a0\u00a0\u00a0\/* Bad Clustering; HF, and not C *\/
    \n<\/span><\/p>\n

    KDBCHKCS \u00a0\u00a0\u00a0\u00a042\u00a0\u00a0\u00a0\u00a0\/* bad Cleanout System commit number *\/
    \n<\/span><\/p>\n

    KDBCHKFF \u00a0\u00a0\u00a0\u00a043\u00a0\u00a0\u00a0\u00a0\/* fixed hash area block on freelist *\/
    \n<\/span><\/p>\n

    KDBCHKMK \u00a0\u00a0\u00a0\u00a044\u00a0\u00a0\u00a0\u00a0\/* hash and cluster keys mixed *\/
    \n<\/span><\/p>\n

    KDBCHKBR \u00a0\u00a0\u00a0\u00a01000 \u00a0\u00a0\u00a0\u00a0\/* KDBCHKBR+kdrchk error code *\/<\/p>\n

    ORA-600 [729]\u00a0\u00a0\u00a0\u00a0UGA Space Leak
    \n<\/strong><\/span><\/p>\n

    ORA-600 [729] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.1.3 – 7.1.6
    \n<\/span><\/p>\n

    Source: .\/knl\/ksm.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    A space (memory) leak has been detected in the UGA<\/p>\n

    Argument Description:<\/p>\n

    a. This is the number of bytes leaked<\/p>\n

    Diagnosis:<\/p>\n

    NOTE: There is NO data corruption as a result of this error.<\/p>\n

    It is purely an internal memory housekeeping problem.<\/p>\n

    Obtain the trace file as this should show the heap dump which helps show what the leaked space belonged to.\u00a0\u00a0\u00a0\u00a0This leak error is raised at logoff time.<\/p>\n

    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.<\/p>\n

    If the dump shows ‘loader’ chunks and the word ‘kcllqr’ it is a leak from SQL*Loader. See <Bug:214529> below.\u00a0\u00a0\u00a0\u00a0If using direct path load try conventional path loads.<\/p>\n

    Look in TecRep for the name of the freeable chunk.<\/p>\n

    Eg: Chunk 6ef7f8 sz=136 freeable “evauct “so query TecRep for ‘evauct’.<\/p>\n

    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.<\/p>\n

    Ramifications of large leaks:<\/p>\n

    If NOT using MTS the UGA is in the PGA and this is freed when the process exits so there is no real problem.<\/p>\n

    If you are using MTS the UGA is in the SGA and so the leak is bad news.<\/p>\n

    Articles:<\/p>\n

    <Event:10262> \u00a0\u00a0\u00a0\u00a0Minimum memory leak to allow.<\/p>\n

    Known Bugs:<\/p>\n

    Fixed In. \u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0Description
    \n<\/span><\/p>\n

    7.1.6\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Bug:214529\u00a0\u00a0\u00a0\u00a0SQL*Loader leaks memory (ORA 600 729)
    \n<\/span><\/p>\n

    7.3.1\u00a0\u00a0\u00a0\u00a0Bug:279593\u00a0\u00a0\u00a0\u00a0Replication leak if destination crashes.<\/p>\n

    ORA-600 [730]\u00a0\u00a0\u00a0\u00a0SGA Space Leak on Shutdown
    \n<\/strong><\/span><\/p>\n

    ORA-600 [730] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.1.3 – 7.1.6
    \n<\/span><\/p>\n

    Source: knl\/ksm.c
    \n<\/span><\/p>\n

    Meaning:<\/p>\n

    SGA is checked for Space leaks at shutdown time and a leak was found.<\/p>\n

    Argument Description:<\/p>\n

    a. Number of leaked bytes
    \n<\/span><\/p>\n

    b. “space leak” description of the error
    \n<\/span><\/p>\n

    Diagnosis:<\/p>\n

    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.<\/p>\n

    Basically on shutdown we free everything in the SGA and then see if there is anything left. If there is we report this error.<\/p>\n

    <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.<\/p>\n

    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.<\/p>\n

    Work Around:<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Eg: In init.ora add:<\/p>\n

    event=”10262 trace name context forever, level 2000″<\/p>\n

    Note that 10262 also affects UGA and PGA leak checking.<\/p>\n

    Known Bugs:<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description <\/span><\/p>\n

    7.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<Bug:205399> \u00a0\u00a0\u00a0\u00a0SGA leak due to SORT chunks<\/p>\n

    \u00a0\u00a0\u00a0\u00a0<Bug:317895> \u00a0\u00a0\u00a0\u00a0KEPT KGL Handles leak<\/p>\n

    7.3.2\u00a0\u00a0\u00a0\u00a0<Bug:317231> \u00a0\u00a0\u00a0\u00a0General KGL Handles leak<\/p>\n

    ORA-600 [9]\u00a0\u00a0\u00a0\u00a0Bad Date Representation
    \n<\/strong><\/span><\/p>\n

    ORA-600 [9] [a] [b] [c] [d] [e]
    \n<\/span><\/p>\n

    Versions: 7.0.16 – 7.1.6
    \n<\/span><\/p>\n

    Diagnosis:<\/p>\n

    Generally there is either an invalid date already in the database or there is a problem performing a conversion.<\/p>\n

    The stored data for dates can be found with:<\/p>\n

    select DUMP(date_column) from table where …<\/p>\n

    Use ‘oranum’ to see if the stored value is garbage.<\/p>\n

    It is possible to store bad dates using OCI or PLSQL. See <Bug:228296><\/p>\n

    Known Bugs:<\/p>\n

    Fixed In.\u00a0\u00a0\u00a0\u00a0Bug No.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Description\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span><\/p>\n

    7.2.2\u00a0\u00a0\u00a0\u00a0<Bug:175254>\u00a0\u00a0\u00a0\u00a0Invalid DATE inserted via PL\/SQL, ORA 600 [9] upon Fetch<\/p>\n

    7.2.2\u00a0\u00a0\u00a0\u00a0<Bug:247871>\u00a0\u00a0\u00a0\u00a0Calls to ‘Char’ functions with a bad DATE<\/p>\n","protected":false},"excerpt":{"rendered":"

    ORA-600 [1113]\u00a0\u00a0\u00a0\u00a0State 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 […]<\/p>\n","protected":false},"author":1,"featured_media":3612,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"spay_email":""},"categories":[14],"tags":[1027,1028,1029,1030],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/haisins.synology.me\/wordpress\/wp-content\/uploads\/2018\/03\/oracle-2.png?fit=579%2C213","amp_enabled":true,"_links":{"self":[{"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3610"}],"collection":[{"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3610"}],"version-history":[{"count":2,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3610\/revisions"}],"predecessor-version":[{"id":3613,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3610\/revisions\/3613"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=\/wp\/v2\/media\/3612"}],"wp:attachment":[{"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3610"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3610"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/haisins.synology.me\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3610"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}