某系統測試環境多個功能突然出現異常，排查後發現都是SQL無法正常運作，且錯誤都是“ORA-01722: 無效數字”，經過一次次排查，一次次确認，DS_STATE就是數字類型，為什麼寫查詢SQL為DS_STATE字段賦數字類型報錯，賦字元串類型卻能正常執行。下文介紹了整個發現問題，分析問題到最後解決問題的過程。
在報錯的所有語句中任意找了一條進行了排查，報錯結果如下圖：
确認DS_STATE到底是什麼類型：
經過檢視，DS_STATE就是數字類型。接着檢視了視圖YN_DAIRYSTATION_V 的内容，
從上圖中看到 DS_STATE 與其他表字段在試圖中做了關系，難不成問題在這兒，
接着檢視了：bd_statu 表的ydb_pvalue 字段類型
\(^o^)/~，好像發現問題了，數字類型和字元串類型做了關聯并且沒有進行資料類型轉換，但是，Oracle會進行自動隐式轉換，應該不是這個問題，接着檢視了正式環境資料庫、開發環境資料庫此語句都可以正常執行 ，是以确定不是類型轉化的問題。
從SQL語句文法上分析沒找到問題，後分析可能是資料庫底層是不是做了什麼設定導緻SQL語句無法正常運作，有個這個想法請教了楊華峰老師，經過楊老師的分析後定位到
Oracle 初始化參數之cursor_sharing 惹的禍，目前系統設定cursor_sharing=FORCE，更改為為預設設定cursor_sharing= EXACT 後，所有報錯的SQL都可以正常執行了。
總結經驗，出現這個問題有兩個解決辦法：
第一種：在寫多表關聯的SQL語句時，where條件中的關聯字段要做資料類型的顯式轉化，
改寫前：
改寫後：
或
第二種：調整 Oracle 初始化參數之cursor_sharing=EXACT
由于我運維的系統不是單個SQL有這個問題，是多個SQL都要同樣的問題，是以我采用了第二種解決方法，以上就是我解決此問題的過程和方法，分享給大家，後續有同樣的問題可以參考解決。