TNS12519、ORA12519錯誤處理及引數processes的設定

 

TNS12519、ORA12519錯誤處理及引數processes的設定

1、現象

客戶方應用程式連線oracle rac資料庫指定的節點，報錯：

TNS-12519: TNS:no appropriate service handler found

ORA-12519

檢查資料庫，發現叢集正常，監聽服務等也正常，但監聽日誌有報錯：

TNS-12519: TNS:no appropriate service handler found

沒多久告警日誌出現報錯：

Process  q0002 died，see its trace file

Ksvcreate：process（q002） creation failed

2、分析

TNS12519和ORA12519：

Oracle官方提示

ORA-12519: TNS:no appropriate service handler found
Cause: The listener could not find any available service handlers that are appropriate for the client connection.
Action: Run "lsnrctl services" to ensure that the instance(s) have registered with the listener, and are accepting connections.

憑經驗可以判斷告警日誌出現的報錯，是當前程式數已經達到引數processes設定的上限，不能建立新的程式了。

檢視一下，驗證：

select count(*) from v$process;

返回結果是799，當前資料庫的processes引數設定值為800，看來不夠用，需要調大。

進一步檢查，發現資料庫有很多是LOCAL=NO這樣的程式，而且90%以上都是前幾天的，當天的程式數很少（另外一個節點的情況相反，這是怎麼回事呢？是中介軟體等應用程式無限建立連線而不釋放？）；網上有資料說可以使用如下命令來殺掉這樣的程式，但是沒敢嘗試（通常不會有問題，Local＝No只是遠端連線的server process，但是如果遠端的連線在做一些大量的磁碟操作，是不是直接殺了以後不會導致磁碟的問題就不是那麼肯定了）：

ps -ef|grep -v grep|grep LOCAL=NO|awk '{print $2}'|xargs kill -9

還有發現有一個使用者擁有600多個非活動的會話（應該是異常情況）：

select username,count(*) from v$session group by username;

3、處理

當時和客戶商量，認為重啟資料庫動作較大，先試試殺掉之前查詢到的那個使用者所有的非活動會話，或者重啟節點監聽。嘗試後，觀察一段時間，沒什麼效果，程式數還是一直大。

後來，決定使用殺手鐧，下班時間操作，調大引數processes為1000，暫停應用，重啟資料庫生效:

SQL> alter system set processes=1000 scope=spfile sid=’*’;

crs_stop -all

crs_start -all

4、建議

rac資料庫負載均衡，客戶應用程式連線資料庫時目前使用的方式是直接指定虛ip和例項名，雖然資料庫有好些應用，但是手工指定，目前的情況是兩個節點負載情況嚴重不平衡，節點1的程式數不到100，節點2卻達到了上限800。

5、結果

調大引數後，暫停應用，重啟資料庫，開啟應用，測試，沒有問題，搞定收工。

附： 網路搜到的一些參考資料

oracle連線常見的有帶LOCAL=NO引數或帶LOCAL=YES的程式。

LOCAL=NO：非本地連線，即網路連線。它是透過Listener 連線到伺服器的。客戶端的應用透過客戶端的監聽向伺服器的監聽傳送請求，伺服器的監聽接收後，在與資料庫連線，執行相關操作，在把結果返回給客戶端。這是透過監聽的流程。 所以在客戶端需要配置監聽，即配置tnsnames.ora。

LOCAL=YES：本地連線。 本地連線不走監聽，所以在服務監聽沒有啟動的情況下，透過本地的sqlplus 還是可以連上資料庫的。

只要是透過SQL*Net網路遠端連入的客戶端程式都顯示為LOCAL=NO

LOCAL=NO 這個表示，業務賬戶透過走監聽連線到資料庫，這個的多少要看資料庫的設定PROCESSES上限是多少，再有的是，平時LOCAL=NO |wc -l 有多少，覺得不正常又是多少，可以設定一個基準線，比方說，session=500是正常的，如果session=600就不正常。目前應用都是透過weblogic或websphere來連線資料庫的，就拿weblogic來說，在獨佔模式下，一般來講，連線資料庫的session有多少，在weblogic 連線池裡都設定好了，比方，設定50個，那麼就有50個session來連線資料，不管有沒有ACTIVE SESSION,反正就佔著位置，所有說，weblogic這樣的應用伺服器與資料庫是密切相關的。一般有這樣的故障，資料庫session很高，但是基本上不活動，也就是說session僵死了，原因不在資料庫，而至weblogic這一端，為什麼了，因為weblgic應用伺服器網路中斷，或者weblogic伺服器意外重啟，導致資料庫session死掉了，但是session卻還佔用processes數量，導致資料庫session數量其高不下。這個時候要找應用的人來問了，問清楚了，就手動kill掉死掉的session，釋放掉session資源，資料庫短時間內是不會跟你清理的。
還有一種情況，在rac環境，應用連錯節點導致session資料其高也是常有的事，這個時候，dba就需要介入了，告訴應用人員，你的應用時連節點1，而不是連節點2的。