本地 oracle 安裝目錄滿觸發 ORA-7445 [_memmove()+64] 導致Instance Crashed 的事故

標籤：des   style   color   os   io   strong   檔案   for   

      最近處理了一個問題，原因是由於命中ORA-600 [kole_t2u], [34] - description, bugs 導致 在udump 目錄下大量轉儲 出cdmp 檔案，

然後這些 cdmp 撐爆本地磁碟空間， 在oracle 發現本地無空間可寫一些日誌時，又觸發ORA-7445 [_memmove()+64]

而觸發ORA-600 [kole_t2u], [34] 的 根本原因是因為業務程式的非法操作，在db 中某張含有 clob 欄位的表中插入了一些oracle現有字元集（zh16gbk）無法處理的字元

 

 

故障類比如下：

 

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

20 rows selected.

 

 ORA-600 [kole_t2u], [34] 影響的版本範圍：

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] 觸發的情景：

As stated, this error can come up in multibyte environments. Secondly it is clear that whenever this error comes up, there must be 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 by an application into a CLOB
Invalid multibyte data has been inserted in a VARCHAR2 (without initially being detected), and the stored data is 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 codepoint before the split. This could either happen in application code, or could be due to bug in the database.
We will look at all these 3 categories in depth in the following paragraphs.

 

 

最後的處理方法：

1. 要求應用根據報錯記錄去審查業務程式

2. 為了避免 cdmp 過大撐爆本地空間， 設定 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, or UNLIMITED
Basic	No

MAX_DUMP_FILE_SIZE specifies the maximum size of trace files (excluding the alert file). Change this limit if you are concerned that trace files may 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], [34] - description, bugs, and reasons (文檔 ID 734474.1)

ORA-600 [kole_t2u] With Multibyte Character Sets While Appending To LOB In a Loop (文檔 ID 739282.1)

AL32UTF8 / UTF8 (Unicode) Database Character Set Implications (文檔 ID 788156.1)

 

Character set conversion when using UTL_FILE (文檔 ID 227531.1)

 

 

Getting ORA-7445 [_memmove()+64] and Instance Crashed (文檔 ID 1294148.1) 轉到底部轉到底部 

In this Document
Symptoms
Cause
Solution
This document is being delivered to you via Oracle Support‘s Rapid Visibility (RaV) process and therefore has not been subject 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 are 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 are truncated (not relevant) or have no information (0 bytes).

CAUSE

In this case the issue is caused by a resource problem outside Oracle.
By checking the OS system log, you can see that the Oracle mount point has ran out of space just before the errors and until the instance crash.

For example in 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.