一條細小的報警簡訊的處理
最近偶爾會收到一封報警簡訊，提示內容大體如下，
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,還是需要考慮一些相關的設定。
如果出現了問題，單純修改閥值或者遮蔽監控，只是把問題給藏起來了，還是沒有得到解決，所以問題處理也要做到表裡如一。
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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Kafka是如何處理Netflix每天2萬億條訊息的？Kafka
- 必備丨iOS12的新功能讓手機一鍵發簡訊報警iOS
- 簡單的字串處理字串
- 多對一處理 和一對多處理的處理
- 簡單的全域性異常統一處理
- 通訊訊號處理的一些基本常識
- 印表機列印出現橫條紋怎麼處理 印表機出現一條一條的橫紋
- 道路千萬條，安全第一條——一次伺服器被入侵的處理經過伺服器
- MySQL：簡單記錄訊號處理MySql
- 處理python中的訊號Python
- Hadoop小檔案的處理方式Hadoop
- 僅一條簡訊就可以劫持你的手機 ！
- MATLAB音訊訊號處理（一）：函式簡易用法（audioread，sound函式）Matlab音訊函式
- rails gem報錯的處理AI
- 詳述一條SQL引發的高CPU故障處理過程SQL
- DBeaver同時執行多條insert into報錯處理
- pythonPIL影像處理庫簡介(一)Python
- Python語音訊號處理的一些kitPython音訊
- 一個簡單的 PHP 時間處理擴充套件PHP套件
- 刪除前一天的備份的一個簡單批處理
- 04 Windows批處理中的條件執行Windows
- TensorFlow進行簡單的影像處理
- Java的簡單理解(22)---處理流Java
- android簡單的圖形特效處理Android特效
- 基於Opencv的簡單影像處理OpenCV
- [譯] 最詳細的 CSS 字元轉義處理CSS字元
- Java 異常處理中的種種細節！Java
- 音訊處理開源庫webrtc(1)簡介音訊Web
- 一個簡單易用的資料庫壞塊處理方案資料庫
- AD模數轉換（ADC）在音訊處理中的詳細深度講解音訊
- 介面自動化的前置條件怎麼處理
- 只需傳送一條簡訊 黑客就能成功入侵你的iPhone黑客iPhone
- eKuiper 原始碼解讀：從一條 SQL 到流處理任務的旅程UI原始碼SQL
- 小程式處理大量資料列表的方法
- 網站註冊簡訊介面遭到簡訊轟炸機轟炸處理方案網站
- 我的 iOS 音訊處理總結iOS音訊
- CSAPP =2= 資訊的表示和處理APP
- linux中的訊號處理與SROPLinux
- 多功能的音訊處理軟體音訊