最近也在處理一些遺留的問題，所以對於使用orabbix的報警還是心懷敬畏之心，一方面是我們讓它能夠做全方位的監控，另一方面也讓我發現我們還是存在不少的小問題，小問題雖小，但是放大了，就是大麻煩，甚至資料庫事故。
自從上次在社群分享了DB time的抖動案例之後，有不少的朋友似乎對這個工具很感興趣，我做這個分享的一個主要原因就是希望大家在有些細節中發現問題，至於我分享的問題原因，都是各種各樣的小問題，有些朋友也納悶這種錯誤似乎還是比較低階的，透過一般的監控都應該解決，但是確實存在，發現瞭解決了，就是我們的最終目的。
前幾天又收到一條報警簡訊，提示某個備庫報了ora錯誤，但是簡訊中也沒有提到更多的ora資訊，首先連線到主庫看看是否dg出了問題，使用dgmgrl進行驗證，沒有發現任何問題。
然後登入到備庫，檢視ora日誌，發現了這麼一段錯誤內容。
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1873]: Assigned to RFS process 3095
RFS[1873]: Identified database type as 'physical standby'
RFS[1873]: Archived Log: '/opt/app/oracle/fra/SEXTDB3/archivelog/2015_09_22/o1_mf_1_2997_c016jv19_.arc'
Tue Sep 22 08:00:31 2015
Media Recovery Log /opt/app/oracle/fra/SEXTDB3/archivelog/2015_09_22/o1_mf_1_2997_c016jv19_.arc
Media Recovery Waiting for thread 1 sequence 2998
Tue Sep 22 09:18:01 2015
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Tue Sep 22 09:18:06 2015
MRP0: Background Media Recovery cancelled with status 16037
Tue Sep 22 09:18:06 2015
Errors in file /opt/app/oracle/admin/extradb/bdump/extdb_mrp0_3067.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Tue Sep 22 09:18:08 2015
Errors in file /opt/app/oracle/admin/extradb/bdump/extdb_mrp0_3067.trc:
ORA-16037: user requested cancel of managed recovery operation
Tue Sep 22 09:18:08 2015
MRP0: Background Media Recovery process shutdown (extdb)
Tue Sep 22 09:18:09 2015
Managed Standby Recovery Canceled (extdb)
Tue Sep 22 09:18:09 2015
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Tue Sep 22 09:18:11 2015
ALTER DATABASE OPEN READ ONLY
Tue Sep 22 09:18:11 2015

從錯誤資訊來看，似乎是日誌應用的mrp終止了，但是檢視後面的日誌發現最新的日誌已經成功應用了，如果沒有其他人的操作，那麼這個操作就是自動觸發的了。
首先可以排除人為的操作。
我透過下面的指令碼從alert日誌中抓取最近幾天的ORA錯誤情況，發現每天早晨的8點，9點左右，資料庫都會啟動到read only狀態，然後稍過幾分鐘，又會切換回日誌應用狀態。
tail -10000 alert_extradb.log| grep -A1 -B1 "READ ONLY"
--
Sun Sep 20 09:18:05 2015
ALTER DATABASE OPEN READ ONLY
Sun Sep 20 09:18:05 2015
--
Physical standby database opened for read only access.
Completed: ALTER DATABASE OPEN READ ONLY
Sun Sep 20 09:18:05 2015
--
Sun Sep 20 16:00:05 2015
ALTER DATABASE OPEN READ ONLY
Sun Sep 20 16:00:05 2015
--
Physical standby database opened for read only access.
Completed: ALTER DATABASE OPEN READ ONLY
Sun Sep 20 16:00:05 2015
--
Mon Sep 21 08:00:10 2015
ALTER DATABASE OPEN READ ONLY
Mon Sep 21 08:00:10 2015
--
Physical standby database opened for read only access.
Completed: ALTER DATABASE OPEN READ ONLY
Mon Sep 21 08:00:11 2015
--
Mon Sep 21 09:18:10 2015
ALTER DATABASE OPEN READ ONLY
Mon Sep 21 09:18:10 2015
--
Physical standby database opened for read only access.
Completed: ALTER DATABASE OPEN READ ONLY
Mon Sep 21 09:18:10 2015

好了，基本可以定位問題不是人為觸發。應該是crontab或者scheduler來觸發的了。
檢視crontab，檢視時間點相近的配置，就發現了兩條相關的記錄，時間戳和ORA的時間戳是一致的。

0 8,16 * * * (/bin/bash /home/oracle/dbadmin/scripts/query/query_for_xxxxx.sh 2>&1 > /dev/null)
18 9 * * * . $HOME/.extradbprofile;$HOME/dbadmin/scripts/query_data/query_mail.sh 6563
本來問題到此就基本明白了，是因為crontab觸發的查詢報出的ora錯誤，那麼為什麼查詢還會需要一次又一次的read only呢，還是因為這是一個10gR2的庫。
有時候應用部門有這種查詢的需求，但是又不能人工每天去查，就讓系統每天定時觸發，然後傳送郵件即可。
那麼我們就預設保持現狀吧，檢視了一下這幾個指令碼
dgmgrl / "edit database sextdb3 set state='READ-ONLY'"
查詢部分
傳送郵件
dgmgrl / "edit database sextdb3 set state='online'"
檢視這幾個指令碼已經有好些年頭了。是否業務部門還需要這樣的查詢，本來想聯絡一下他們，順著指令碼中的郵箱去檢視，但是發現這幾個人已經不在通訊錄中了，那麼這就意味著這種查詢可能不再需要了。
簡單的討論和核查後，確認這兩個job已經不再需要了，這樣這個問題就基本解決了，早上再也沒有這兩個ORA報警了，想想心裡又會少咯噔幾下。

一個備庫中ORA錯誤資訊的分析

相關文章