前戲：
為響應某公司安全部門要求，針對該公司使用了weblogic中間件的系統進行2019年10月釋出的最新PSU更新檔進行更打，以修複對應的安全漏洞。
而本文要講的故障案例，就是由本次更新檔更打而引發的，而通過這個案例，我們能得到了哪些啟發？且看下文道來。
故障概述 2019/11/19某公司營業系統訂單相關業務辦理時，相同的業務請求間歇性的出現“ORA-01461: 僅能綁定要插入 LONG 列的 LONG 值”報錯。故障處理過程：1、系統維護人員發現報錯“ORA-01461: 僅能綁定要插入 LONG 列的 LONG 值”，第一反應是程式有問題，向ORACLE資料庫中插入或更新資料時插入的字元串長度越界？但是相同的請求資料時而成功，時而報錯。核實發現代碼近期沒做過變更上線，相關業務也早就存在，代碼問題的可能性較小。
2、資料庫側核實，對應的一體機Oracle19C庫沒有異常，且近期沒更新。
3、中間件側運維人員核實昨晚針對故障系統抽取了部分主機進行了weblogic更新檔更打！“部分主機”與報錯現象對上了，懷疑故障可能與更新檔更新相關。
4、搜集了相關故障資訊後，針對weblogic更新進行了復原，應用重新開機後，問題得到解決。
故障原因分析：後續針對故障時刻搜集的相關資訊進行排查，未發現任何異常資訊，僅有的資訊隻有業務日志“ORA-01461”報錯。我們在測試環境進行了weblogic更新檔更新準備複現問題，然而問題并未複現。
接着，我們針對能夠引發“ORA-01461”報錯的可能原因，做了深一步的梳理：1）插入到字元串長度大于4000位元組；
2）插入到表中的記錄的某個字段資料的實際長度大于2000個位元組（如果是UTF-8，則是1333個位元組）；或者是插入的記錄中有兩個或兩個以上長度大于2000位元組的字元串。
3）資料庫與用戶端的JDBC驅動不比對。對于UTF-8或歐洲的某些字元集，oracle在存儲時，對于一個字元需要2個或3個位元組的存儲空間，雖然表定義中為varchar2(4000)，但是其實該字段的data_length為其2倍或3倍長。這種情況下oracle會把data_length長度超過4000的當做LONG型處理。
程式未做變更、資料庫未做變更，相關業務sql肯定沒問題，我們首先排除了1、2兩點的可能。針對第三點，我們優先進行了進一步排查。
曆史日志記錄應用啟動加載的JDBC驅動版本為12.1.0.2.0：
當晚更新檔更新後，應用啟動日志記錄使用的JDBC驅動驅動版本為11.2.0.3.0 ：
繼續核實發現測試環境更新檔更新後應用啟動加載的JDBC驅動為12.1.0.2.0：
為何同樣是更新檔更新，卻出現了不一樣的結果？
我們對當晚更新檔更新操作過程進行了複核，發現當晚操作人員更新檔更新是采用拷貝安裝的形式，直接從其他完成weblogic更新檔更打的主機直接拷貝了一份安裝到目标系統主機上。
恰巧，故障系統在項目初期，針對weblogic下jdbc驅動包ojdbc6.jar做了定制修改，修改後驅動為12.1.0.2.0版本：
而當晚的拷貝安裝相當于将修改後的ojdbc6.jar驅動包還原了，是以驅動版本變成了11.2.0.3.0。
後續我們在測試環境驗證，将weblogic産品下驅動包替換後，果然問題複現。引發故障的原因也就此解開。
五、剖析總結綜上分析過程，我們很容易看出存在以下幾點問題的：1） 更新當晚缺少業務驗證，或者說業務驗證不充分 ；2） 更新檔更新拷貝安裝的方式欠妥，未按照規範敲指令更新；3） 廠商在項目上線初期，針對weblogic基礎軟體的JDBC驅動包做了調整。第一點非本次故障本質原因，在此不做闡述。
第二點，需要我們再次強調運維操作的規範性，以及不折不扣的執行的重要性，否則你不踩坑誰踩坑！
但是單就weblogic更新檔更新這件事來說，運維人員也确有他的難處。
運維人員經常面臨的是一晚上幾十台、幾百台，一輪更新檔更新涉及伺服器甚至上千計數，而一台伺服器按照規範更新，解除安裝更新檔、更打更新檔最快可能也要40分鐘左右，按照規範更新顯然很難完成更新任務。
而針對weblogic在同作業系統，版本差異不大的情況下，拷貝安裝是常被采納的方案，這就是為何操作人員使用拷貝安裝的原因。
冤不冤？不冤，你沒按規範來啊。冤不冤？冤！鬼知道開發廠商在系統上線初期針對weblogic的JDBC驅動包做了改造啊，完全不知情，甚至是項目開發人員都不知曉或遺忘。
這就要引申出我們的第三點。
第三點，抛開這次問題不講，以後的weblogic更新檔如果針對JDBC驅動做了更新，運維人員按照規範更新，同樣會掉坑裡！廠商對weblogic預設JDBC驅動做了改造，還有什麼地方被改了沒人知曉。
牽扯到後續，如果系統遷移呢？咱們可以拷貝安裝遷移啊，但是目标主機作業系統都換了呢，顯然拷貝安裝是不成立的。
這等于埋了一個大坑在這，誰踩誰軟。該故障的本質是缺少了對基礎軟體安裝管理規範，以及運維交接規範，進一步思考是缺少依托平台軟體流轉内部入網上線标準化規範化執行落地意識。畢竟，人是最可靠，但也是最不可靠的。