備庫報警郵件的分析案例(三)
前兩篇地址：
http://blog.itpub.net/23718752/viewspace-1827685/
http://blog.itpub.net/23718752/viewspace-1829630/
最後透過手工定位監控的方式終於把罪魁禍首揪了出來，為什麼在備庫使用ash無果，因為還是10g的庫，還沒有這個特性，在11g中才可以。這個也算是在10g中的一個監控盲點吧。
最後得到的語句是下面這樣的形式每天凌晨都會在備庫查詢一次，資源消耗極大，目前臨時表空間為98G都不能滿足需求。
select c.cn as
cn, c.uin as uin from (select cn from test_cn_bind where enabled='Y' group by cn
having count(cn)>1) t, test_cn_bind c where t.cn = c.cn and c.enabled='Y' order
by cn
所以這個問題和開發同事溝通了一下，才得知了緣由。原來test_cn_bind這個表有一個欄位cn,目前是nonunique的，業務上需要為unique的，但是線上修改目前還是沒有機會的，如果真是出現了這種情況，會在業務上有一些問題，但是機率很低，所以開發部門最後建議在備庫上執行這麼一個查詢。
這麼來看，原來在設計階段這個問題就沒有考慮完善，後續就會有各種的補救措施。
既然業務上確實需要，但是目前的改進空間還比較大，比如走個並行，比如更快的儲存介質上。
因為這是個一主兩備的環境，第二個備庫是最近申請的，裡面有SSD，所以在滿足同樣需求的情況下，可以考慮把語句挪到SSD所在的備庫上來。
那麼先來看看在SSD上執行的效果。結果執行竟然還報錯了。
SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1);
select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1) *
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1003 - see DBWR trace file
ORA-01110: data file 1003: '/U01/app/oracle/oradata/testmdb/temp03.dbf'
Elapsed: 00:00:07.81
根據提示說在/U01下沒有這個臨時資料檔案。在檔案系統中檢視，確實是不存在，但是在這個備庫有路徑對映，是/U01 對映 /U03,臨時資料檔案在/U03下面。臨時資料檔案確實在/U03下面。
使用dg broker把備庫置為online，然後開始嘗試offline drop.
SQL> alter database datafile '/U01/app/oracle/oradata/testmdb/temp01.dbf' offline drop;
alter database datafile '/U01/app/oracle/oradata/testmdb/temp01.dbf' offline drop
*
ERROR at line 1:
ORA-01516: nonexistent log file, datafile, or tempfile "/U01/app/oracle/oradata/testmdb/temp01.dbf"
看來只能做rename了。
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf';
alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf'
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is automatic.
修改失敗，發現備庫檔案管理有auto的影響，限制為manual修改。
SQL> show parameter standby
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL> alter system set standby_file_management=manual;
System altered.
再次修改就沒有問題了，三個臨時資料檔案都修改一下。
SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf';
Database altered.
SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp02.dbf' to '/U03/app/oracle/oradata/testmdb/temp02.dbf';
Database altered.
SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp03.dbf' to '/U03/app/oracle/oradata/testmdb/temp03.dbf';
Database altered.
修改完成之後再置為auto
SQL> alter system set standby_file_management=auto;
System altered.
當然這種變化，備庫中肯定會有影響。
DGMGRL> show configuration;
Configuration
Name: testmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
testmdb - Primary database
stestmdb2 - Physical standby database
stestmdb - Physical standby database
Current status for "testmdb":
Warning: ORA-16607: one or more databases have failed
$ dgmgrl /
Connected.
DGMGRL> show database verbose stestmdb2;
Database
Name: stestmdb2
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: ONLINE
Instance(s):
testmdb
Properties:
InitialConnectIdentifier = 'stestmdb2'
ObserverConnectIdentifier = ''
LogXptMode = 'ARCH'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '2'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '/U01/app/oracle/oradata/testmdb, /U03/app/oracle/oradata/testmdb'
LogFileNameConvert = '/U01/app/oracle/oradata/testmdb, /U02/app/oracle/oradata/testmdb'
FastStartFailoverTarget = ''
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'acc223.cyou.com'
SidName = 'testmdb'
LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=10.127.65.223)(PORT=1521))'
StandbyArchiveLocation = '/U01/app/oracle/admin/testmdb/arch'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
LatestLog = '(monitor)'
TopWaitEvents = '(monitor)'
Current status for "stestmdb2":
Error: ORA-16766: Redo Apply unexpectedly offline
需要手動開啟日誌應用。
DGMGRL> edit database stestmdb2 set state='READ-ONLY';
Succeeded.
然後再次嘗試就可以了，透過下面的top資訊可以看到在執行並行的大查詢過程中，io wait是相對很低的。
top - 19:29:59 up 310 days, 8:48, 2 users, load average: 1.04, 0.53, 0.20
Tasks: 488 total, 2 running, 486 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 0.4%sy, 0.0%ni, 96.7%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 132050764k total, 131731368k used, 319396k free, 789588k buffers
Swap: 16771776k total, 399208k used, 16372568k free, 125815688k cached
使用MegaCli來檢視一下SSD的配置資訊
/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aAll -NoLog |less
Raw Size: 745.211 GB [0x5d26ceb0 Sectors]
Non Coerced Size: 744.711 GB [0x5d16ceb0 Sectors]
Coerced Size: 744.625 GB [0x5d140000 Sectors]
Sector Size: 0
Firmware state: Online, Spun Up
Device Firmware Level: 0270
Shield Counter: 0
Successful diagnostics completion on : N/A
SAS Address(0): 0x4433221102000000
Connected Port Number: 2(path0)
Inquiry Data: BTTV428102EV800JGN INTEL SSDSC2BA800G3 5DV10270
FDE Capable: Not Capable
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: 6.0Gb/s
Link Speed: 6.0Gb/s
Media Type: Solid State Device
Drive: Not Certified
Drive Temperature :26C (78.80 F)
PI Eligibility: No
Drive is formatted for PI information: No
PI: No PI
Drive's NCQ setting : N/A
Port-0 :
Port status: Active
Port's Linkspeed: 6.0Gb/s
Drive has flagged a S.M.A.R.T alert : No
這樣問題就基本能夠定位了，在備庫2中執行，發現效率確實好了很多。所以就給開發同學提出了四點建議。
#1建議語句修改為
select c.cn as cn,c.uin from cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1;
#幫忙檢視一下呼叫邏輯是否有問題
同時之前的查詢會有多個會話（差不多8個這樣的會話）進行同樣的查詢，請幫忙看一下是否存在呼叫問題，
資料庫使用者 TEST_SHINK 客戶端使用者為：webadmin
#在備庫2（5.23）中進行同類查詢。
因為存在兩個備庫，在備庫2(5.23 使用SSD)上對比發現，同樣的語句在備庫2上效果要好很多，可以使用備庫2來做此類查詢
資料庫IP 為10.127.5.23:1523 資料庫為：testmdb 需要開通防火牆許可權，請備註。
#降低查詢頻率
檢視資料查詢的情況，時間可以從37分鐘改進到近12分鐘左右，可以看到目前為止不存在這類問題（查詢結果為0），是否可以考慮把執行頻率也降低，比如一週一次。
--SSD的備庫
SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1);
COUNT(*)
----------
0
Elapsed: 00:12:11.73
--普通盤的備庫
SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1);
COUNT(*)
----------
0
Elapsed: 00:37:08.85
所以這麼一個案例從頭到尾詳細分析了一遍，感覺還是牽扯到方方面面。對於抖動的情況，在業務需求之外的，還是需要引起重視。我喜歡跟開發的同事說，報錯不是關鍵，沒有報錯不一定沒問題。來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1835051/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 備庫報警郵件的分析案例（一)
- 備庫報警郵件的分析案例（二)
- 一封備庫報警郵件的分析
- 三封報警郵件的分析
- 由報警郵件分析發現的備庫oracle bugOracle
- 一條看似平常的報警郵件所做的分析
- zabbix郵件報警通知
- grafana的郵件報警AlertingGrafana
- prometheus配置MySQL郵件報警PrometheusMySql
- 一條關於swap爭用的報警郵件分析
- zabbix郵件報警功能的驗證
- 一條關於swap爭用的報警郵件分析(二）
- 一條關於swap爭用的報警郵件分析(一）
- zabbix 配置傳送郵件報警
- 使用Zabbix服務端本地郵箱賬號傳送報警郵件及指定報警郵件操作記錄服務端
- jenkins郵件報警機制配置Jenkins
- oracle資料庫自動發郵件實現報警功能Oracle資料庫
- SQLServer郵件預警SQLServer
- pinpoint-docker開啟郵件報警和整合釘釘報警推送Docker
- 細述zabbix郵件報警常見問題
- supervisor守護程式並配置郵件報警
- 一則備庫CPU報警的思考
- zabbix監控之同時向多人郵件報警
- Linux 下如何用 mutt 設定郵件報警Linux
- UNIX系統高負載郵件報警指令碼負載指令碼
- 醫療行業郵件營銷案例分析行業
- 表空間郵件預警(luckyfriends)
- 伺服器磁碟監控指令碼分享（含報警郵件）伺服器指令碼
- 基於Nginx+Keepalived的LB服務監控（郵件報警）Nginx
- 配置Jenkins構建失敗觸發郵件報警機制Jenkins
- X站釣魚郵件應急響應案例分析
- 技術分享| 如何使用Prometheus實現系統監控報警郵件通知Prometheus
- linux通過cacti監控apache通過飛信郵件進行報警LinuxApache
- AWR報告分析之三：cursor: pin S 的原理與案例分析
- Laravel 傳送郵件報錯Laravel
- AWR報告分析之三：cursor: pin S 的原理與案例分析-eygle
- 郵件傳送案例流的形式檔案不落盤
- 分散式監控系統Zabbix-3.0.3-完整安裝記錄（5）-郵件報警部署分散式