昨天在做MERGE的时候出现了一个600的错误，从网上找了很长时间都没有找到原因，的一个网友给出了解决方法，原来是ORACLE的一个BUG。
错误提示如下：
ORA-00600: internal error code, arguments: [ktrexc_1], [], [], [], [], [], [], []
解决方法：
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 enabledApplies to:
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 statementORA-00600: internal error code, arguments: [ktrgcm_3]Changes setting the following parameter _row_cr = TRUECause 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 particular 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 A.
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 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 performing a block cleanout, Row CR will only attempt to generate a CR version for the particular 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 essentially 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 should 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