修改glogin.sql引發的生產系統監控的虛假報警

問題提出：
生產系統，收到報警郵件說open_cursors過多，馬上登入到伺服器上檢查，發現open cursor最多的一個session才開啟100多個cursor，應該沒什麼問題。但是一個小時後，又收到報警郵件，重新登入伺服器，還是沒什麼異常。而且之後每個小時（這個規律是後來才發現的）都會收到報警郵件，每次都沒有任何異常，這下找不到頭緒了。[@more@]晚上回家，又收到這樣的郵件，於是把所有這類郵件從第一封開始到最後一封看了一遍，又看了一遍發信的時間，才注意到每個小時都會發一封報警郵件。登入生產，檢查監控的指令碼（指令碼為另一個同事寫的，而且已經半年多沒收到這樣的報警了），指令碼中定義的也是一個小時檢查一次，也就是說每次監控指令碼執行，都會發郵件出來，肯定是監控不對了。
生產系統是兩臺機器的RAC系統，從郵件標題看，信是從DB1發出的，檢查DB1的指令碼，沒有任何異常。後來發現DB2從來沒有發郵件出來，那麼DB2的指令碼應該是完全正確的，於是拿DB2的指令碼去跟DB1的核對，看是否是DB1的指令碼出現錯誤了。結果發現DB2監控指令碼里面的提示全部是DB1的提示，於是把裡面的提示全部改成DB2，然後執行一遍，馬上收到了報警郵件，這說明問題是處在DB2上的。而由於當初上RAC的時候，這個監控指令碼沒有修改，導致DB2的郵件報警出現的卻是DB1的提示，所以到DB1上死活也找不出問題所在。
檢視監控指令碼，是使用一個查詢，如果查詢返回的結果是3行，則說明沒有異常，因為3行正好是sql提示和返回no rows的提示資訊，如果返回大於3行，則發報警郵件，檢視返回結果，發現每次執行返回結果都正好四行，而但sql的返回結果都是空。仔細檢視，發現最後面有一行提示資訊Executed in 0.807 seconds，到此問題已經完全暴露了出來了。
因為我習慣在glogin.sql中加上set timing on設定，這樣每個sql執行完就會知道執行了多少分鐘。那天因為頻繁在DB2上操作，每次都設定set timing on太麻煩，於是就把它加到了glogin.sql中去了，這樣就導致了監控指令碼的返回會比原先多一行，而正好我只設定了DB2，沒有設定DB1，而DB2報警郵件的提示卻是DB1，誤導了視線。一連串的正好導致了問題的發生。
總結：任何返回錯誤、報警、提示資訊的地方，返回的結果一定要正確，這個在編寫任何程式的時候，尤其大量使用CRTL+C和CTRL+V的時候尤其要注意。