A problem has recently been addressed because of a hit ORA-600 [kole_t2u], [description], bugs causing a large number of udump files to be dumped in the Cdmp directory,
These cdmp then burst the local disk space, triggering ORA-7445 [_MemMove () +64] When Oracle discovers that there is no space available to write some logs
The underlying cause of triggering ORA-600 [kole_t2u], [34], is the illegal operation of a business program in which some of the existing Oracle character sets (ZH16GBK) cannot be processed in a table in db that contains a CLOB field
The fault simulation is as follows:
Sql> select * from V$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0-64bit Production
PL/SQL Release 11.2.0.2.0-production
CORE 11.2.0.2.0 Production
TNS for Linux:version 11.2.0.2.0-production
Nlsrtl Version 11.2.0.2.0-production
sql> CREATE TABLE t3 (a clob);
Table created.
sql> INSERT into T3 values (utl_raw.cast_to_varchar2 (' EC '));
INSERT into T3 values (utl_raw.cast_to_varchar2 (' EC '))
*
ERROR at line 1:
Ora-00600:internal error code, arguments: [kole_t2u], [34], [], [], [], [],[], [], [], [], [], []
Sql> SELECT * from Nls_database_parameters
PARAMETER VALUE
------------------------------ --------------------------------------------------------------------------------
Nls_language AMERICAN
Nls_territory AMERICA
Nls_currency $
Nls_iso_currency AMERICA
Nls_numeric_characters.,
Nls_characterset ZHS16GBK
Nls_calendar Gregorian
Nls_date_format DD-MON-RR
Nls_date_language AMERICAN
Nls_sort BINARY
Nls_time_format HH.MI. Ssxff AM
PARAMETER VALUE
------------------------------ --------------------------------------------------------------------------------
Nls_timestamp_format DD-MON-RR HH.MI. Ssxff AM
Nls_time_tz_format HH.MI. Ssxff AM TZR
Nls_timestamp_tz_format DD-MON-RR HH.MI. Ssxff AM TZR
Nls_dual_currency $
Nls_comp BINARY
Nls_length_semantics BYTE
NLS_NCHAR_CONV_EXCP FALSE
Nls_nchar_characterset AL16UTF16
Nls_rdbms_version 11.2.0.2.0
Rows selected.
ORA-600 [kole_t2u], [34] affected version range:
Oracle database-enterprise edition-version 9.2.0.1 to 11.2.0.4 [Release 9.2 to 11.2]
Information in this document applies to any platform.
Oracle Server Enterprise edition-version:9.2.0.1 to 11.1.0.6
Checked for relevance on 20-jan-2014***
ORA-600 [kole_t2u], [34] Trigger scenario:
As stated, this error can come to multibyte environments. Secondly it is clear that whenever this error comes up, there must are at least 1 incomplete codepoint used in the data.
In general we can split these occurrences in 3 categories:
Invalid multibyte data is being inserted-a application into a CLOB
Invalid multibyte data have been inserted in a VARCHAR2 (without initially being detected), and the stored data are moved to A CLOB at a later stage (either through application code, or by a Oracle process like Auditing).
Existing correctly stored CLOB data is incorrectly "split" into chunks. This could leave a codepoint "split" in the middle of the byte stream, leaving a incorrect number of bytes for the last Co Depoint before the split. This could either happen in application code, or could is due to bug in the database.
We'll look at all these 3 categories in depth in the following paragraphs.
The final processing method:
1. Request the application to review the business process according to the error record
2. In order to avoid cdmp explosion local space, set max_dump_file_size
max_dump_file_size
| Property
Description |
Parameter type |
String |
Syntax |
MAX_DUMP_FILE_SIZE = { integer [K | M] | UNLIMITED } |
Default value |
UNLIMITED |
Modifiable |
ALTER SESSION ,ALTER SYSTEM |
Range of values |
0 to Unlimited, orUNLIMITED |
Basic |
No |
MAX_DUMP_FILE_SIZE
Specifies the maximum size of trace files (excluding the alert file). The change of this limit if you is concerned that trace files could use too much space.
A Numerical value for MAX_DUMP_FILE_SIZE
specifies the maximum size in operating system blocks.
A number followed by a K
or M
suffix specifies the file size in kilobytes or megabytes.
The special value string UNLIMITED
means that there is no upper limit on trace file size. Thus, dump files can be as large as the operating system permits.
ODM fund:
ORA-600 [kole_t2u], [under]-description, Bugs, and Reasons (document ID 734474.1)
ORA-600 [kole_t2u] with multibyte Character sets while appending to LOB in a Loop (document ID 739282.1)
Al32utf8/utf8 (Unicode) Database Character Set Implications (document ID 788156.1) |
Character set conversion when using Utl_file (document ID 227531.1)
Getting ORA-7445 [_MemMove () +64] and Instance Crashed (document ID 1294148.1) go to bottom go to bottom
In this Document
Symptoms
Cause
Solution
This document was being delivered to your via Oracle support ' s Rapid Visibility (RaV) process and therefore have not been sub Ject to an independent technical review.
Applies To:
Oracle database-enterprise edition-version 10.2.0.4 to 11.2.0.2 [Release 10.2 to 11.2]
Information in this document applies to any platform.
Symptoms
In the alert log file There is reported errors like:
Ora-07445:exception Encountered:core Dump [_MemMove () +64] [Sigbus]
[Invalid address Alignment] [0x0. ...] [] []
and instance crashed.
The trace files generated by these errors is truncated (not relevant) or has no information (0 bytes).
Cause
The issue is caused by a resource problem outside Oracle.
By checking the OS system log, you can see that the Oracle mount point have ran out of space just before the errors and UNT Il the instance crash.
For example on an HP-UX system, the messages can be as the following:
vmunix:vxfs:NOTICE:msgcnt 1 MESG 001:v-2-1: vx_nospace-/dev/vg01/lvora file System Full (1 block extent)
Solution
Monitor your system in order to avoid running out of space in Oracle mount points.