Oracle ORA-00600: internal error code; cursor sharing

• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
We are getting errors in the pc_server logs since we applied SP1002 on our production server.

I was looking for something to address slow response time reports since the update. Here is an example of the errors:

Oracle error: io_z37_start4b z37
ORA-00600: internal error code, arguments: [kkslgbv0], [], [], [], [],

08:43:57 Error (get_buf_z37_by_time_range) : Failed to start z37 table (START-4-B).
===


Our DBAs also noticed the file system was filling up due to lot of trace file generation and saw this sort of error in the trace files:
####
ORA-00600: internal error code, arguments: [kkslgbv0], [], [], [], [], [], [], []
Current SQL statement for this session:
select sum(to_number(z31_sum)) from umn50.z31 where z31_rec_key like :v1 and z31_status = :"SYS_B_0" and z31_credit_debit = :"SYS_B_1"

####
Our DBAs looked at Metalink and found that it is due to the "cursor sharing" parameter. In alephp, this parameter is set as -- cursor sharing = similar (they noted that this is ExLibris recommendation and thye are not sure not clear why they recommended it). The DBAs changed it to -- cursor sharing = exact as recommended by Oracle and this stopped the trace file generation. Metalink says that this is a bug and it will be fixed in the 11.1 release. (11.1 is not yet available).

After this change the slow response time issues disappeared.

This is not happening on our test server which is on Oracle 10 with the cursor sharing = similar setting, but it has very few transactions.

Here is the main quesion - Is it "safe" to leave the "cursor sharing = exact" on saturn?
(We will change loon to be the same)

Resolution:
Absolutely YES. ExLibris recommends to set the cursor sharing to "exact".
The initial setup of Oracle, when installed, should be "cursor sharing = exact" by default.