Home > Oracle, Performance > ORA-00600: internal error code, arguments: [ktprhtnew6]

ORA-00600: internal error code, arguments: [ktprhtnew6]


While recovering a database, stuck with ORA-00600 and database crashed.  We have an Oracle version 11.1 and were hitting a bug: 8310931 and fixed in 11.2.  The bug says, this problem will happen usually on high number of CPUs while doing transaction recovery.  We got 126 CPU in the DB server.


Errors in file /opt/oracle/diag/rdbms/xxxx/xxx/trace/xxx_smon_29786.trc (incident=120257):

ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/xxx/xxxx/incident/incdir_120257/xxxx_smon_29786_i120257.trc
Fri Feb 22 22:49:14 2013
Trace dumping is performing id=[cdmp_20130222224914]
Fatal internal error happened while SMON was doing active transaction recovery.
Errors in file /opt/oracle/diag/rdbms/xxxxx/xxxxx/trace/xxxx_smon_29786.trc:
ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], [], [], [], [], []
SMON (ospid: 29786): terminating the instance due to error 474

The only information we could see the trace file was, it was doing transaction recovery while crashing with 256 servers.


*** 2013-02-22 22:49:06.125
Dead transaction 0x00df.019.0002e351 recovered by 256 server(s)
Incident 120257 created, dump file: /opt/oracle/diag/rdbms/xxx/xxx/incident/incdir_120257/xxxx_smon_29786_i120257.trc
ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], [], [], [], [], []

Parallel Transaction recovery caught exception 600
Parallel Transaction recovery caught error 600
Fatal internal error happened while SMON was doing active transaction recovery.
error 474 detected in background process
ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], [], [], [], [], []

*** 2013-02-22 22:49:14.570
SMON (ospid: 29786): terminating the instance due to error 474
ksuitm: waiting up to [5] seconds before killing DIAG

stuck with the issue – we thought to hide the high number of  CPUs from Oracle.  Set the CPU_COUNT to  64 and started the database.  That resolved the issue and database came up cleanly.

Note: I felt reducing parallel servers for rollback (by adjusting the parameter fast_start_parallel_rollback) were also could have been resolved the issue with the CPU_COUNT 126.  In our case it was ‘HIGH’.  Basically Oracle should not use 256 servers for recovery to hit this bug.  Will test that case when I get an opportunity, hurry to release the system now!

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: