積累了幾次Oracle客戶端連接故障，做下總結。

1、案例

案例1：客戶端連接報錯ORA-12514

項目場景
業務工程人員使用PLSQL工具，連接部署在Windows系統上的Oracle 11gR2單機數據庫，報錯ORA-12514。
分析排查
（1）錯誤代碼含義
ORA-12514 是指監聽程序無法識別連接描述符中請求的服務。
（2）錯誤可能性
監聽程序可能掛了，也可能是listener.ora文件中的配置有問題。
（3）錯誤排查

登錄數據庫服務器，cmd窗口執行 “lsnrctl status” 命令，發現監聽沒有啟動。于是執行 “lsnrctl start”命令啟動監聽，啟動后注意到 “UNKNOWN” 標識——靜態監聽，說明其依賴listener.ora文件配置。

繼續嘗試連接，依然報錯ORA-12514。

考慮到是靜態監聽模式，此時高度懷疑listener.ora文件配置有誤；檢查發現listener.ora文件中并沒有關于目標實例的配置信息，于是將目標實例信息補充到文件中。

調整完listener.ora文件，重啟監聽；再次嘗試連接，連接成功。
錯誤復盤
這個錯誤是比較基礎的：listener.ora文件配置缺少目標實例信息、監聽未啟動。和現場溝通后得知是業務工程人員自己部署用來測試的，所以并未注意這兩個細節。

案例2：客戶端連接報錯ORA-28547

項目場景
業務工程人員使用PLSQL工具，連接部署在Windows系統上的Oracle 11gR2單機數據庫，報錯ORA-28547。

分析排查
（1）錯誤代碼含義
ORA-28547 是指客戶端與服務器通信失敗。
（2）錯誤可能性
由于是第一次看到這個錯誤代碼，也已經排查過監聽配置文件、監聽程序無異常。所以網上查閱多篇資料，梳理總結如下：

1、配置文件中存在問題；
2、環境問題：未安裝Oracle客戶端、防火墻未放行1521端口；
3、數據庫連接工具的OCI版本與目標數據庫不匹配；

（3）錯誤排查

1、listener.ora文件、tnsnames.ora文件都已經排查過，未有寫錯的服務名和路徑。
2、防火墻關閉，且在同一網段，不會是網絡問題；客戶端也已安裝，且環境變量正確。
3、OCI版本也無誤

似乎無計可施了。終于在對比檢查了多次listener.ora文件后，發現某行多了個括號，格式發生錯誤。于是刪除多余括號，再次嘗試連接，連接成功。

錯誤復盤
這次的錯誤同樣基礎，但卻十分隱蔽：listener.ora文件格式錯誤，僅僅只是多了個括號。這是我自己在listener.ora文件中 手敲 監聽配置信息造成的錯誤，也再次提醒如果需要手工調整監聽配置文件，最好是從其他數據庫配置文件或者samples模版文件中拷貝修改，避免失誤。

案例3：客戶端連接報錯：Got minus one from a read call

項目場景
業務工程人員使用DBever工具連接 19C數據庫時，報錯：Got minus one from a read call，連接失敗。

分析排查
（1）錯誤含義
“Got minus one from a read call” ：讀取call的結果是-1。字面上看不出什么，所以查看告警日志和監聽日志；其中告警日志無異常，監聽日志中發現如下報錯：

（2）錯誤可能性
監聽日志中顯示TNS-12518, TNS-12547, TNS-12560, TNS-00517的組合報錯。嘗試將這個錯誤拋給deepseek，給出了如下原因：

1、內存資源不足
2、權限問題
3、操作系統bug
4、資源限制（/etc/security/limits.conf配置的資源限制參數過低）
5、網絡配置問題

不得不說，deepseek挺強大的，將所有的可能性都列舉了出來。但是它似乎只是聯網匯總分析了網上的文章，給出的每一種可能性權重都是一樣的，我抓不住它給出的重點，而且很多地方只是淺嘗輒止。
（3）錯誤排查

系統內存資源、Oracle相關目錄權限、資源限制參數都很快檢查完了；至于操作系統bug，我沒想著排查，因為太高級我不會…。并且嘗試使用sqlplus連接，也連接不上，所以也排除客戶端驅動問題。

最后我還是將目標瞄向監聽配置文件，但是服務名、路徑、主機名等每一個參數，都沒有問題；格式也沒問題。

于是我打開了另外一臺數據庫的監聽配置文件仔細對比，在對比了非常多次之后，發現在listener.ora文件中，ORACLE_HOME的路徑，末尾處有個 “/” 。我不知道是不是它的問題，但也將其刪除，重啟監聽，再次嘗試連接，連接成功。

錯誤復盤
數據庫使用的是靜態監聽，完全依賴監聽配置文件。部署這臺數據庫的DBA在手動配置監聽文件時，不知道在listener.ora文件中ORACLE_HOME路徑末尾不能有 “/”。這是個細節問題，很隱蔽，但卻很關鍵。

案例4：客戶端連接報錯：ORA-12518

項目場景
業務工程師反饋某備庫連接不上，批處理報錯。使用PLSQL登錄顯示ORA-12518。

分析排查
（1）錯誤含義
ORA-12518：監聽收到了客戶端的連接請求，但在將這個連接請求移交給數據庫服務進程的時候失敗了。
（2）錯誤可能性
這個錯誤的原因可能是操作系統內存資源告警、資源限制參數過低且已達到上限、數據庫的process/session達到上限；嚴重的話也有可能是實例出現問題，PGA中的會話全局區不能再分配連接。
（3）錯誤排查
我并沒有去檢查操作系統內存資源和資源限制參數。直接去檢查了process和session資源，發現資源已耗盡；調整完process后，問題解決。
錯誤復盤
此次連接錯誤，有兩個原因：一是process參數本身設置不合理，才500；二是業務某個批處理未設置連接池，導致連接數很快消耗完。這兩個錯誤都是可以提前預見和規避的。

案例5：客戶端連接報錯：ORA-28040

項目場景
低版本的JDBC驅動在連接Oracle 19C時，會遇到ORA-28040錯誤。
解決方案
1、可以選擇升級JDBC驅動。
2、臨時修改sqlnet.ora文件，向下兼容JDBC
將以下參數加入sqlnet.ora文件，如果沒有該文件，需要手動創建。

可以執行lsnrctl status命令查看監聽配置目錄。

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8  # 允許最低協議版本為 8（兼容 10g/11g）
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

在調整完sqlnet.ora文件后，需要重啟監聽，配置才可生效。

2、總結

通過以上案例，可以發現：大部分連接問題都是因為監聽配置文件有誤，此外常見的還有數據庫資源限制問題。當發生連接故障時，我們可能記不住那么多不同的錯誤代碼，但是可以優先從配置文件、數據庫資源方面著手排查；這也是提醒我們在手動操作配置文件時務必要細心。