Middleware

最近在一个项目中碰到一个事情，缘由大概如下：
业务由中间价tomcat连接到oracle db，每连接一次呢要插入对应表中一条数据，结果出现了偶尔报错ora-01461的错误，估计是因为插入的数据表中对应字段使用varchar2类型数据，但是经过字符集转换后由于长短不一直造成自负超过4000字节，此时数据库会将数据类型转换成long字段类型数据插入，导致字段类型不一致，所以报错01046的错误。
像这类错误只会在业务前端展示，在数据库这层无法看到明确的报错，解决这类问题有2个思路：

一是更新jdbc的驱动；

二是找到对应的表更改字段的varchar2为long等长字段。

我遇到情况是上面的第一种，当时我采用oracle 10g最新的jdbc驱动更新中间件的tomcat（数据库版本为9206），但是很遗憾隔了没多久又出现同样的报错情况。最终我决定要找到对应的表，可是这时候应用开发也不知道是哪张表，无赖之下只能在oracle层面采取errorstack的方式跟踪，大概的原理如下：

errorstack事件：dump 错误栈信息，通常Oracle发生错误时前台进程将得到一条错误信息，但某些情况下得不到错误信息，可以采用这种方式得到Oracle错误。

使用语法：

alter session set events ’12899 trace name errorstack forever’; 不需要重启数据库，在session级别生效。
alter system set events ’12899 trace name errorstack forever’;-需要重启数据库，在全局系统生效

我这里以错误ORA-12899的方式为例，具体如下：

执行语句：

alter system set events ’12899 trace name errorstack forever’;

SQL> alter system set events '12899 trace name errorstack forever';

System altered.

SQL> desc t1
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NUMBER
NAME VARCHAR2(4)

SQL> insert into t1 values(250,'ludatou');
insert into t1 values(250,'ludatou')
*
ERROR at line 1:
ORA-12899: value too large for column "SYS"."T1"."NAME" (actual: 7, maximum: 4)

可以在user_dump下找到最新的dump，ls -lFrt，就为此次错误的跟踪trace,Trace的内容如下：

*** 2014-01-15 17:24:13.461
----- Error Stack Dump -----
ORA-12899: value too large for column "SYS"."T1"."NAME" (actual: 7, maximum: 4)
----- Current SQL Statement for this session (sql_id=8f4g5vujpymhg) -----
insert into t1 values(250,'ludatou')
↑↑↑↑↑
这个trace把语句也抓起来了。

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------

*** 2014-01-15 17:24:13.992
skdstdst()+38 call kgdsdst() BFD338FC ? 2 ?
ksedst1()+88 call skdstdst() BFD338FC ? 0 ? 1 ? AC9E128 ?
8551B9E ? AC9E128 ?
ksedst()+33 call ksedst1()+8 0 ? F9F580 ? 2050033 ? 0 ?
FF ? 2004 ?
dbkedDefDump()+1062 call ksedst() 0 ? 0 ? 0 ? 0 ? 0 ? 0 ?
ksedmp()+47 call dbkedDefDump() 1 ? 0 ?
dbkdaKsdActDriver() call 00000000 1 ? 1F060C ? 1D19EC ? 0 ?
+1481 FAA03A0 ? F9E3720 ?
dbgdaExecuteAction( call 00000000 F9F580 ? BFD35630 ?
)+595
dbgdaRunAction()+89 call dbgdaExecuteAction( F9F580 ? F21B294 ? 20C0002 ?
4 ) BFD35630 ? 1 ?
dbgdRunActions()+64 call dbgdaRunAction() F9F580 ? 71D0810 ?
dbgdProcessEventAct call dbgdRunActions() DC16520 ? DC16529 ?
ions()+604
dbgdChkEventKgErr() call dbgdProcessEventAct F9F580 ? FAA03A0 ? 71D093C ?
+1542 ions() 0 ? 1 ? EA055FB ?
dbkdChkEventRdbmsEr call dbgdChkEventKgErr() F9F580 ? 223BAD0 ? 3263 ?
r()+23
__PGOSF12_ksfpec()+ call dbkdChkEventRdbmsEr 3263 ? 8 ? EABE0A0 ?
139 r() EABE0A0 ? EAB6A38 ?
BFD35F24 ?
dbgePostErrorKGE()+ call 00000000 FAA03A0 ? 3263 ?
825