|
|
2014年3月28日
這個(gè)問題很多小伙伴都遇到了，網(wǎng)上搜羅了半天也沒找到太好、太完美的解決辦法，有人說是因?yàn)榘惭bIE11時(shí)聯(lián)網(wǎng)了，導(dǎo)致自動(dòng)打了補(bǔ)丁，這個(gè)補(bǔ)丁可以自動(dòng)檢查IE主頁是否損壞，可以通過卸載相應(yīng)的補(bǔ)丁解決，我同時(shí)又找到了另外一個(gè)通過修改hosts文件的方法，貌似目前解決了我的問題，修改方法如下：
使用記事本打開 C:\Windows\System32\drivers\etc\hosts 文件，在最下面追加一行：
127.0.0.1 ieonline.microsoft.com
將JDK中BIN文件夾下的 msvcr71.dll 這個(gè)文件復(fù)制到 TOMCAT 中的 BIN 下
有段日子沒做記錄了，這段日子一直在排雷（前人埋下的隱患代碼，或者直接說bug），今天這個(gè)雷讓我排了將近大半天，因?yàn)槭钦缴暇€的系統(tǒng)，只能看后臺(tái)日志，不能調(diào)試，打印出的異常信息不完整，種種的條件不充分，導(dǎo)致問題很難定位。標(biāo)題上的兩個(gè)異常，第一個(gè)一看就明白是插入的數(shù)值大于數(shù)據(jù)庫字段長度，第二個(gè)多是因?yàn)镹umber類型的字段導(dǎo)致，比如精度不足。我們的這次問題原因是程序員在做除法運(yùn)算時(shí)沒有對(duì)除數(shù)進(jìn)行非零判斷，導(dǎo)致計(jì)算出來的數(shù)值非法，插入數(shù)據(jù)庫失敗，請看代碼：
  public static void main(String[] args)  {
 double a = 10;
double b = 0;
double c = 0;
double m = a/c;
double n = b/c;
System.out.println(m);
System.out.println(n);
 }
經(jīng)過計(jì)算后，m和n的值分別是多少？沒在實(shí)際開發(fā)中遇到的可能不知道，或者你有個(gè)好習(xí)慣不會(huì)出現(xiàn)這樣的bug，請看結(jié)果：
 Infinity
NaN
被除數(shù)非零，除數(shù)為零做除法的結(jié)果是字符串“Infinity”，翻譯成中文就是“無限”，你的中學(xué)數(shù)學(xué)老師可能說過；
被除數(shù)為零，除數(shù)為零做觸發(fā)的結(jié)果是字符串“NaN”，即不是有效的數(shù)字。
就是這個(gè)“Infinity”花費(fèi)了我一小天的時(shí)間才定位。下面詳述問題定位的方法。
異常1：ORA-01438: value larger than specified precision allowed for this column
了解點(diǎn)數(shù)據(jù)庫的打眼一看就知道插入的數(shù)值超過了表字段長度，但你知道是哪個(gè)表哪個(gè)字段嗎？我不知道，于是網(wǎng)上查閱了下，Oracle數(shù)據(jù)庫服務(wù)器在Linux上。
命令行登陸到數(shù)據(jù)庫所在服務(wù)器，進(jìn)入Oracle的安裝目錄，假設(shè)是/opt/oracle/
進(jìn)入到如下目錄：/opt/oracle/admin/實(shí)例名/udump
中間的數(shù)據(jù)庫實(shí)例名根據(jù)實(shí)際情況修改，udump目錄下會(huì)有一堆的.trc文件，這些文件記錄了所有操作當(dāng)前數(shù)據(jù)庫出現(xiàn)異常的堆棧信息。為了定位問題，我將該目錄下的所有.trc文件都刪除了（當(dāng)然，刪除之前把udump目錄整個(gè)備份了），再進(jìn)行一次系統(tǒng)的業(yè)務(wù)操作，查看一下udump目錄，發(fā)現(xiàn)立刻生成一個(gè)新 的.trc文件，打開查看（內(nèi)容片段）：
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2/db_1
System name: AIX
Node name: gsdj1
Release: 1
Version: 6
Machine: 00CFD4644C00
Instance name: bjwd1
Redo thread mounted by this instance: 1
Oracle process number: 132
Unix process pid: 48300280, image: oracle@gsdj1
*** SERVICE NAME:(bjwd) 2014-03-28 16:48:05.683
*** SESSION ID:(2969.43961) 2014-03-28 16:48:05.683
*** 2014-03-28 16:48:05.683
ksedmp: internal or fatal error
ORA-01438: value larger than specified precision allowed for this column
Current SQL statement for this session:
insert into CP_TEMP_STOCKTRAN (APPLY_ID, ALIEN, CER_TYPE, CER_NO, TRANS_AM, TRANS_AM_PR, TRANS_TYPE, TRANS_DATE, ENDORSOR, BLIC_TYPE, ALIEN_ID, ENDORSOR_ID, STOCKTRAN_ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13)
黃色背景紅色字體的SQL就是罪魁禍?zhǔn)祝@僅僅能定位發(fā)生問題的數(shù)據(jù)庫表，字段還得自己排查。異常1讓我定位到了這里，這時(shí)想起了異常2。
異常2： Could not synchronize database state with session
之前也搜索過這個(gè)異常，多數(shù)是由于Number類型的字段導(dǎo)致。冷靜的思考一下，平常我們在做表設(shè)計(jì)時(shí)，會(huì)把文字類型的字段設(shè)置大一些，Number類型的精度也會(huì)根據(jù)實(shí)際業(yè)務(wù)進(jìn)行設(shè)計(jì)，但往往Number類型的字段最容易出問題：
1、如果將非Number值插入該字段，比如字符串
2、如果插入的數(shù)值精度過多，如字段設(shè)計(jì)Number(10,2)，也就是最大支持8為整數(shù)和兩位小數(shù)，要插入34.121313就會(huì)失敗
根據(jù)表名定位到hibernate的映射文件以及實(shí)體類，再從業(yè)務(wù)功能入口（一個(gè)action方法）搜索，終于定位到一個(gè)業(yè)務(wù)接口做了該實(shí)體類的保存代碼，定位到了那個(gè)字段，定位到了做除法沒有判斷除數(shù)是否為0。
|