ORA-00600 [kgmgchd1]

ORA-00600: internal error code, arguments: [kgmgchd1] appeared on 11.1.0.7 (11.1.0.7.9).

There are number of bugs related to this 11792492 which also duplicated as bug 6769075.

Download and apply Patch 6769075.

ORA-00600 [kgmgchd1] in 11.1.0.7 [ID 1333584.1]

ORA 03137 TTC protocol internal error

Some useful metalink notes for ora-03137.

Intermittant Ora-03137, Ora-03106, Ora-03124 When Forking Across Connections (Doc ID 859472.1)

ora-600 [12333] / ora-3137 [12333] Troubleshooting (Doc ID 828123.1)

ORA-03137: TTC Protocol Internal Error : [12333] Using JDBC Driver (Doc ID 752297.1)

Bug 8625762 - ORA-3137 [12333] due to bind data not read from wire (Doc ID 8625762.8)

ORA-600 [kccsbck_first]

Starting an oracle instance in an cluster could throw up the following error.

SQL> startup
ORACLE instance started.

Total System Global Area 6413680640 bytes
Fixed Size                  2171672 bytes
Variable Size            1107299560 bytes
Database Buffers         5284823040 bytes
Redo Buffers               19386368 bytes
ORA-00600: internal error code, arguments: [kccsbck_first], [1], [3224794587],
[], [], [], [], [], [], [], [], []

On Linux x86_64 restarting the cluster would resolve this error.

More information on metalink note 157536.1 ORA-600 [kccsbck_first] - What to Check

Excessive logging on crsd.log after applying PSU 11.2.0.1.2

Excessive logging on the crsd.log could be seen after applying the PSU 11.2.0.1.2. As part of the updated information on metalink note 1089071.1, with regard the ASM Home issue it is suggested For Linux x86 and Linux x86-64 platforms, install either (A) the bug fix for 8898852 in the GI home and the Database PSU Patch 9654983 in the Database home, or (B) the Grid Infrastructure PSU Patch 9655006 to both homes.
When GI PSU is applied following log information is logged on the crsd every second

2010-08-10 15:02:42.687: [UiServer][1087850816] S(0x3ba9da0): set Properties ( root,0x2aaaac405f30)
2010-08-10 15:02:42.698: [UiServer][1548937536] processMessage called
2010-08-10 15:02:42.698: [UiServer][1548937536] Sending message to PE. ctx= 0x2aaaac3d5ba0
2010-08-10 15:02:42.699: [   CRSPE][1544735040] Processing PE command id=1060. Description: [Stat Resource : 0x2aaab0005300]
2010-08-10 15:02:42.699: [   CRSPE][1544735040] PE Command [ Stat Resource : 0x2aaab0005300 ] has completed
2010-08-10 15:02:42.700: [   CRSPE][1544735040] UI Command [Stat Resource : 0x2aaab0005300] is replying to sender.
2010-08-10 15:02:42.700: [UiServer][1548937536] Done for ctx=0x2aaaac3d5ba0
2010-08-10 15:02:43.687: [UiServer][1087850816] S(0x3ba9da0): set Properties ( root,0x2aaaac3e9d20)
2010-08-10 15:02:43.698: [UiServer][1548937536] processMessage called
2010-08-10 15:02:43.698: [UiServer][1548937536] Sending message to PE. ctx= 0x2aaaac3d02b0
2010-08-10 15:02:43.699: [   CRSPE][1544735040] Processing PE command id=1061. Description: [Stat Resource : 0x2aaab0005300]
2010-08-10 15:02:43.699: [   CRSPE][1544735040] PE Command [ Stat Resource : 0x2aaab0005300 ] has completed
2010-08-10 15:02:43.700: [   CRSPE][1544735040] UI Command [Stat Resource : 0x2aaab0005300] is replying to sender.
2010-08-10 15:02:43.700: [UiServer][1548937536] Done for ctx=0x2aaaac3d02b0
2010-08-10 15:02:44.687: [UiServer][1087850816] S(0x3ba9da0): set Properties ( root,0x2aaaac05aab0)
2010-08-10 15:02:44.698: [UiServer][1548937536] processMessage called
2010-08-10 15:02:44.698: [UiServer][1548937536] Sending message to PE. ctx= 0x2aaaac3e98f0
2010-08-10 15:02:44.698: [   CRSPE][1544735040] Processing PE command id=1062. Description: [Stat Resource : 0x2aaab0005300]
2010-08-10 15:02:44.699: [   CRSPE][1544735040] PE Command [ Stat Resource : 0x2aaab0005300 ] has completed
2010-08-10 15:02:44.700: [   CRSPE][1544735040] UI Command [Stat Resource : 0x2aaab0005300] is replying to sender.

Normally this is done every five minutes. So PSU for the GI was rollback and bug fix for 8898852 was applied to the GI home as suggested on the above mentioned doc note. Then the logging went back to its usual frequency.

010-08-13 10:39:04.592: [UiServer][1553340736] S(0x2aaaac3f3ba0): set Properties ( root,0x2aaab00385a0)
2010-08-13 10:39:04.603: [UiServer][1551239488] processMessage called
2010-08-13 10:39:04.603: [UiServer][1551239488] Sending message to PE. ctx= 0x2aaab0034a90
2010-08-13 10:39:04.604: [   CRSPE][1547036992] Processing PE command id=873. Description: [Stat Resource : 0x2aaab40093b0]
2010-08-13 10:39:04.604: [   CRSPE][1547036992] PE Command [ Stat Resource : 0x2aaab40093b0 ] has completed
2010-08-13 10:39:04.604: [   CRSPE][1547036992] UI Command [Stat Resource : 0x2aaab40093b0] is replying to sender.
2010-08-13 10:39:04.605: [UiServer][1551239488] Done for ctx=0x2aaab0034a90
2010-08-13 10:44:04.645: [UiServer][1553340736] S(0x2aaaac3f3ba0): set Properties ( root,0x2aaab00571d0)
2010-08-13 10:44:04.656: [UiServer][1551239488] processMessage called
2010-08-13 10:44:04.656: [UiServer][1551239488] Sending message to PE. ctx= 0x2aaab002eec0
2010-08-13 10:44:04.656: [   CRSPE][1547036992] Processing PE command id=874. Description: [Stat Resource : 0x2aaab40093b0]
2010-08-13 10:44:04.657: [   CRSPE][1547036992] PE Command [ Stat Resource : 0x2aaab40093b0 ] has completed
2010-08-13 10:44:04.657: [   CRSPE][1547036992] UI Command [Stat Resource : 0x2aaab40093b0] is replying to sender.
2010-08-13 10:44:04.657: [UiServer][1551239488] Done for ctx=0x2aaab002eec0

OLAPIHISTORYRETENTION

caused by

 BUG 3386542 - OLAPI trggers that are installed with seed database, (OLAPISTARTUPTRIGGER and OLAPISHUTDOWNTRIGGER), does not handle absence of Oracle OLAP.

Can also occur when oracle standard edition is installed in which OLAP is missig.

solution is detailed on metalink note 266728.1

Disable OLAPISTARTUPTRIGGER and OLAPISHUTDOWNTRIGGER to avoid error from being generated.

ALTER TRIGGER SYS.OLAPISTARTUPTRIGGER DISABLE;
ALTER TRIGGER SYS.OLAPISHUTDOWNTRIGGER DISABLE;

aq_tm_processes Is Set To 0

Signs

After upgrading to 10.2.0.3 using DBUA the message "WARNING: AQ_TM_PROCESSES is set to 0" begins appearing in the alert log file.

DBUA has set the aq_tm_processes initialization parameter explicitly to zero.

Fix

In 10.2, it is recommended to leave the parameter aq_tm_processes unset and let the database autotune the parameter.

Setting aq_tm_processes parameter explicitly to zero which disables the time monitor process (qmn), can disrupt the operation of the database due to several system queue tables used when the standard database features are used.

You cannot determine if aq_tm_processes is set explicitly to zero just by querying v$parameter.

A check to see if the parameter is explicitly zero is:

connect / as sysdba

set serveroutput on

declare
mycheck number;
begin
select 1 into mycheck from v$parameter where name = 'aq_tm_processes' and value = '0'
and (ismodified <> 'FALSE' OR isdefault='FALSE');
if mycheck = 1 then
dbms_output.put_line('The parameter ''aq_tm_processes'' is explicitly set to 0!');
end if;
exception when no_data_found then
dbms_output.put_line('The parameter ''aq_tm_processes'' is not explicitly set to 0.');
end;
/

If it is set to zero, it is recommended to unset the parameter.

alter system reset aq_tm_processes scope=spfile sid='*';

However, this requires bouncing the database if unable to do so

alter system set aq_tm_processes = 1;

Internal Error Code Kkslgbv0

Found in

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3
in any platform.

Metalink note

Note:382567.1
Note:416001.1
Note:5155885.8

Signs

The alert log shows the error:
ORA-00600: internal error code, arguments: [kkslgbv0], [], [], [], [], [], [], []

Bug

5155885

Fixed in

10.2.0.4 (Server Patch Set)
11.1.0.6 (Base Release)

Apply Patch

Patch 5155885

Workaround

Use CURSOR_SHARING=EXACT or
set "_optim_peek_user_binds"=false so that bind values are not peeked.

OALL8 is in an inconsistent state With JDBC Thin Driver

Found in

JDBC - Version: 10.1.0.0 to 10.2.0.3
in any platform.

Metalink Notes

Note: 549409.1 OALL8 is in an inconsistent state" With JDBC Thin Driver and selecting non-ascii Characters

Note: 944692.1 Master Note: Understanding the "OALL8 is in an Inconsistent State" Exception

Signs

"OALL8 is in an inconsistent state" is thrown when using the 10.2.0.3 JDBC thin driver to select non ascii characters from the database.

Fixed in

11.1.0.6.0 version of Oracle JDBC driver.

Apply Patch

Patch 4390875

Internal error Code Kcbz_check_objd_typ_3

Found in

Oracle Server - Enterprise Edition - Version: 10.2.0.2 to 10.2.0.3
in any platform.
The cause of this problem has been identified and verified in an Unpublished Bug 4430244.

Metalink Note

Note:430223.1

Signs

Segment Advisor is being used.
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [4], [0], [15], [], [], [], []

Fixed in

10.2.0.4 (Server Patch Set)
11.1.0.6 (Base Release)

Apply patch

Patch 4430244

Shared server tied to session WAIT(RECEIVE)

Bug

Bug 5447395 - Shared server tied to session when BFILE used

Metalink Note

Note:5447395.8

Fixed in

10.2.0.4 (Server Patch Set)
11.1.0.6 (Base Release)

Description

If a shareed server session (MTS) ever opens a BFILE and also closes it then the shared server gets tied to that particular session and remains in receiving state "WAIT(RECEIVE)".

WARNING: inbound connection timed out (ORA-3136)

The "WARNING: inbound connection timed out (ORA-3136)" in the alert log indicates that the client was not able to complete it's authentication within the period of time specified by parameter SQLNET.INBOUND_CONNECT_TIMEOUT.

You may also witness ORA-12170 without timeout error on the database server sqlnet.log file.
This entry would also have the clinet address which failed to get authenticated. Some applications or JDBC thin driver applications may not have these details.

From 10.2 onwards the default value of this parameter is 60 seconds, hence if the client is not able authenticate within 60 secs , the warning would appear in the alert log and the client connection will be terminated.

This timeout restriction was introduced to combat Denial of Service (DoS) attack whereby malicious clients attempt to flood database servers with connect requests that consumes resources.

There can be three main reasons for this error

1. Server gets a connection request from a malicious client which is not supposed to connect to the database , in which case the error thrown is the correct behavior. You can get the client address for which the error was thrown via sqlnet log file.
2. The server receives a valid client connection request but the client takes a long time to authenticate more than the default 60 seconds.
3. The DB server is heavily loaded due to which it cannot finish the client logon within the timeout specified.

The default value of 60 seconds is good enough in most conditions for the database server to authenticate a client connection. If its taking longer period, then its worth checking all the below points before going for the workadound:

1. Check whether local connection on the database server is sucessful & quick.

2. If local connections are quick ,then check for underlying network delay with the help of your network administrator.

3. Check whether your Database performance has degraded by anyway.

4. Check alert log for any critical errors for eg, ORA-600 or ORA-7445 and get them resolved first.

These critical errors might have triggered the slowness of the database server.

As a workaround to avoid only this warning messages, you can set the parameters SQLNET.INBOUND_CONNECT_TIMEOUT and INBOUND_CONNECT_TIMEOUT_listenername
to the value more than 60.

In server side sqlnet.ora file add SQLNET.INBOUND_CONNECT_TIMEOUT

SQLNET.INBOUND_CONNECT_TIMEOUT = 120

In listener.ora file INBOUND_CONNECT_TIMEOUT_listenername

INBOUND_CONNECT_TIMEOUT_LISTENER = 110

From Oracle version 10.2.0.3 onwards the default value of INBOUND_CONNECT_TIMEOUT_ is 60 seconds. For previous releases it is zero by default.

More on meta link note 465043.1 and 345197.1

file var/log/nessages Flooded with "su(pam_unix)session opened/closed for user oracle

Metalink Doc ID : 415665.1

The problem is reported in Bug 5722352

Solution

Obtain patch for unpublished Bug 5679560 from MetaLink and apply it

Or:

1. take a backup copy of /etc/init.d/init.cssd

2. edit /etc/init.d/init.cssd

Replace code section:

$SU $ORACLE_USER -c "$ECHO \$TZ > /tmp/oratz.$$ " > /dev/null 2>&1
NEWTZ=`$SED 's/^[ \t]*//;s/[ \t]*$//' < /tmp/oratz.$$`
$RMF /tmp/oratz.$$
if [ ! -z "$NEWTZ" ]; then
TZ=$NEWTZ;
export TZ;
fi


with:

TZCHANGE=/tmp/TZCHANGE
if [ -f $TZCHANGE ]then
$SU $ORACLE_USER -c "$ECHO \$TZ > /tmp/oratz.$$ " > /dev/null 2>&1
NEWTZ=`$SED 's/^[ \t]*//;s/[ \t]*$//' < /tmp/oratz.$$`
$RMF /tmp/oratz.$$
if [ ! -z "$NEWTZ" ]; then
TZ=$NEWTZ;
export TZ;
fi
$RMF $TZCHANGE
fi

Recreating of the OCCI libraries (genoccish) fails

Recreating of the OCCI libraries (genoccish) fails with errors similar to:cp: cannot stat `/DISCARD/': No such file or directory
cp: cannot stat `/DISCARD/': No such file or directory
/usr/bin/ld: Warning: size of symbol `std::basic_string >::~basic_string()' changed from 168 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o) to 52 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o)
/usr/bin/ld: Warning: size of symbol `std::basic_string >::~basic_string()' changed from 52 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o) to 168 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o)
/usr/bin/ld: Warning: size of symbol `std::basic_string >::~basic_string()' changed from 168 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o) to 52 in $ORACLE_HOME/lib32/libocci10.a(occiConnectionImpl.o)
/usr/bin/ld: Warning: size of symbol `std::basic_string >::~basic_string


Workaround: Download and apply the patch for bug 5240469

But this may also not work some times. Most likely cause for this would be a missing RPM.

compat-gcc-32-c++ (x86_64)

Please make sure that ' /usr/bin/g++32' is a 64bit binary. The output should look similar to the following:
%file g++32g++32: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
If the version is not 64bit,it is required to install the 64bit version of the compat package that contains this file:
%usr/bin> rpm -qf g++32 compat-gcc-32-c++-3.2.3-47.3
To check if this is a 64-bit rpm :-
%/usr/bin> rpm -q --queryformat "%{NAME} %{ARCH} \n" compat-gcc-32-c++
compat-gcc-32-c++ x86_64


metalink notes regarding this problem.

432885.1
379409.1
417319.1
428563.1
429830.1
397344.1