一條細小的報警簡訊的處理

最近偶爾會收到一封報警簡訊，提示內容大體如下，
xxxx,trc_directory (TNS-1190),log_directory(TNS-1190)，Please check log for details
對於這個問題，看似是監聽出了問題，但是根據同事的反饋說監聽一切正常，而且從業務部門也從來沒有得到任何反饋說系統的任何問題，所以問題就擱置了下來，但是昨天再次收到這個問題，
感覺還是需要來看一下，畢竟收到報警簡訊了，應該是什麼地方達到了閥值，還是需要關注的。
於是登入到伺服器上去看，伺服器上是11g的庫，用到了asm,所以是grid和oracle獨立的兩個使用者。
檢視tns的情況，
$ ps -ef|grep tns
root        85     2  0  2014 ?        00:00:00 [netns]
grid      3431     1  0  2014 ?        01:40:55 /home/U01/app/grid/11.2.3/bin/tnslsnr LISTENER -inherit
grid     15587     1  0  2014 ?        00:32:19 /home/U01/app/grid/11.2.3/bin/tnslsnr LISTENER_1526 -inherit
oracle   30419 30323  0 22:42 pts/0    00:00:00 grep tns  

檢視grid中的日誌顯示內容為，可以看到有警告，但是不確定是否有這個問題導致。                                                                                        
WARNING: Subscription for node down event still pending                                                                                                                                                                             
21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0    
21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=services)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * services * 0
WARNING: Subscription for node down event still pending                                                                                                                                                                             
21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0    
因為報錯資訊知道了TNS錯誤上所以自己的注意力就集中在了那上面，除此之外也沒有發現有任何的警告。
這個時候求助於metalink，發現竟然有一篇很詳細的文章介紹。
 How To Disable Oracle Database Listener Alerts TNS-01190 In Enterprise Manager Cloud Control 12c to avoid the error "trc_directory (TNS-1190), log_directory (TNS-1190),. Please check log for details." (Doc ID 1399060.1)
那麼這個時候來看這個問題似乎就是水到渠成了。
根據這個帖子的說法，還是因為agent在oracle使用者下，而監聽在grid下，所以agent需要週期性的去查詢一下監聽的資訊的時候，因為沒有許可權，所以會有一些問題。
對於這個問題，如果通過EM來修正，就可以找到對應的監聽

然後在 監聽器->監視->度量和收集設定裡面可以看到其實1190就是最高的閥值了。

這個時候一種解決辦法就是把1190從這個閥值中去掉。
當然去掉之後，偶爾的報警簡訊一直到今天再也沒有出現過。
不過這樣處理問題還是治標不治本，知道還是因為一些設定的不規範，單純修改閥值，去除閥值雖然可行，但是還是不夠徹底。
所以繼續開始琢磨改怎麼處理。繼續檢視，發現了兩篇相關的文章。
EM 11g: How To Prevent the Generation of The Listener Error TNS-1190 From the Enterprise Manager 11.1.0.1 Grid Control Console (文件 ID 1595086.1)
'WARNING: Subscription for node down event still pending' in Listener Log (Doc ID 372959.1)
第一篇雖然是11g中的解決方法，但是我覺得更加全面，因為裡面提到了4中方法，第一種就是解決這個警告，因為這個也是間接反映了這個問題，第二種就是通過EM修改閥值，去掉1190的閥值
第三種是新增監聽密碼，但是這種似乎還是不太適用，第四種是直接忽略，好像也有道理，但是我不願意這麼做。
好了，這麼看來，第二種已經做完了，那麼目前的效果是怎麼樣的呢？
檢視監聽日誌的情況
$ tail -f *.log
Thu Oct 22 22:53:44 2015
22-OCT-2015 22:53:44 * ping * 0
WARNING: Subscription for node down event still pending
22-OCT-2015 22:53:44 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0
可以看到監聽的警告依然存在，那麼就開始在listener.ora裡面新增一個引數
SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER_1526=OFF
這個其實也是把一個類似的觸發器關掉，可見oracle在這方面真實技高一籌。
修改完成之後，還是需要reload的。
$ lsnrctl reload listener_1526
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))
The command completed successfully
然後再次檢視日誌，發現就有了明顯的變化。
Thu Oct 22 22:57:34 2015
22-OCT-2015 22:57:34 * ping * 0
WARNING: Subscription for node down event still pending
22-OCT-2015 22:57:34 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0
System parameter file is /home/U01/app/grid/11.2.3/network/admin/listener.ora
Trace information written to /home/U01/app/grid/diag/tnslsnr/rolequery/listener_1526/trace/ora_15587_139826913183488.trc
Trace level is currently 0
Log messages written to /home/U01/app/grid/diag/tnslsnr/rolequery/listener_1526/alert/log.xml
22-OCT-2015 22:57:37 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=grid))(COMMAND=reload)(ARGUMENTS=64)(SERVICE=listener_1526)(VERSION=186647296)) * reload * 0
然後日誌中的警告就徹底消失了。
Thu Oct 22 22:58:44 2015
22-OCT-2015 22:58:44 * ping * 0
22-OCT-2015 22:58:44 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0
按照這種情況，這個錯誤算是徹底解決了，修不修改閥值已經沒那麼重要了。
從這個簡單的案例可以看出這個細小的報警簡訊還是能夠折射出一些小的問題來，比如grid和oracle的分離，agent安裝基於oracle使用者，但是監聽在grid,還是需要考慮一些相關的設定。
如果出現了問題，單純修改閥值或者遮蔽監控，只是把問題給藏起來了，還是沒有得到解決，所以問題處理也要做到表裡如一。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1815764/，如需轉載，請註明出處，否則將追究法律責任。