Ora 00600 [ktrexc_1]

When using merger to update data today, the error message "ora600" is reported. A solution was found online, with the ora bug.

 

Http://sns.linuxpk.com/blog-52196-16983.html

 

YesterdayDatabaseA 600 error occurred while performing merge operations. The reason was not found for a long time from the Internet,ItpubA netizen gave a solution, which turned out to be a bug in Oracle.

The error message is as follows:

ORA-00600: Internal error code, arguments: [ktrexc_1], [], [], [], [], [], [], [], []

Solution:

Set the hidden parameter "_ row_cr" to false as a workaround for the bug as follow:

SQL> alter system set "_ row_cr" = false scope = both;

The parameter can be enabled/disabled dynamically.

-This is a Boolean parameter that defaults to false. When set to true it will enable row level consistent read (row Cr) If either of the following are true:

You are running under a RAC Environment
Event 10313 is enabled

Applies:
Oracle Server-Enterprise Edition-version: 9.0.1.4 to 10.2.0.3-release: 9.0.1 to 10.2
Information in this document applies to any platform.
Symptoms
The following errors reported in the Alert Log causing failure of the associated SQL statement
ORA-00600: Internal error code, arguments: [ktrgcm_3]

Changes
Setting the following Parameter
_ Row_cr = true

Cause
The problem happens when reclaiming space from a txn Free List when migrating BLOB data from inline to out-of-line.

This is cause by the setting _ row_cr = true

Solution
Set "_ row_cr" = false

"_ Row_cr" is a hidden parameter used to control Cr requests and buffer waits on remote undo segment headers which is a common problem on RAC instances

In particle with Oracle Applications, global cache request waits and buffer waits for segment headers of rollback segments owned by remote instances, can become a significant part of the overall wait time. consult the view v $ cr_block_server (refer to part
II, Chapter 3.4 V $ cr_block_server) for confirmation.

A Cr request and buffer wait here can occur in the following situation:

1. Several instances modify a block.
2. instance B queries the block.

This causes a request to generate a cr version of the current block, which can either be in the local cache or a remote cache, e.g. instance.
If remote, the LMS on instance a will try to generate the Cr block; when local, the foreground process executing the query on instance B will perform the Cr block generation.
In any case, either instance needs to read the transaction table and undo blocks from the rollback segment that are referenced in the active Itls of the block.
This cleanout/rollback process may cause several lookups of local and remote undo headers and undo blocks.
The remote undo header and undo block lookups will result in a global Cr request. Since undo headers are frequently accessed, a buffer wait may also occur.

The wait event will be GC buffer busy, and the use of automatic undo segments can exacerbate the performance problem because for each transaction we will use a different undo segment.
The views v $ session_wait or V $ session_wait_history assist in identifying the rollback segment, simply by looking at the columns P1 and P2, which denote the file ID and block ID.

Rowcr is now enabled and supported with 10.2. rowcr can partially reduce the overhead of the global block cleanout/rollback problem by simply attempting to generate a cr version for the requested row.

Please note that rowcr (_ row_cr = true) is not supported in Oracle versions prior to 10g Release

 

 

In Oracle9i Release 2, the row Cr feature can be partially alleviate the overhead of the global block cleanout/rollback problem. the row Cr feature will reduce the number of Cr rollbacks and avoid a costly block cleanout/rollback in a RAC environment. instead
Of every Ming a block cleanout, row Cr will only attempt to generate a cr version for the specified row. currently, row Cr works for update statements that have a unique index scan or fetch by row ID in the row source. whenever there is a fetch by unique
Index row source in the execution plan, that causes Cr cleanout/rollback, row Cr will kick in. the statistic row Cr attempts essential measures the number of updates that have this property that cause Cr cleanout or rollbacks to happen. the statistic row
Cr hits measures the success ratio of row Cr among the attempts made. Oracle10g and beyond this feature shocould extend for index range scans, as well as further optimize cleanout processing.

To extend row Cr functionality, the hidden parameter _ row_cr needs to be set to true (default is false ). row Cr will be tried before invoking Cr rollback. the parameter can be changed dynamically, by using alter system. currently, row Cr is turned on only
For updates whose plan is unique scans or fetch by row ID. no other operation gets row Cr. when setting the _ row_cr parameter to true, row Cr will be attempted for all SQL (this will include updates, selects, deletes and joins) that have a fetch by unique
Index or a fetch by row ID row source in the row source tree.

This parameter has benefited several bugs, however this is unsupported functionality. Consider setting _ row_cr = true if majority are immediate Cr cleanouts