另辟蹊徑解決數(shù)據(jù)庫運維技術難題

1、另辟蹊徑解決數(shù)據(jù)庫運維技術難題技術創(chuàng)新，變革未來數(shù)據(jù)庫服務是做什么的？數(shù)據(jù)庫服務駐場工程師故障處理數(shù)據(jù)庫服務駐場工程師重癥監(jiān)護室的故事一個醫(yī)院，在重癥監(jiān)護室， 死亡率從某個時候起突然 高起來，而經過醫(yī)生的分 析，每天早上8點的死亡 率，比其他時間段高很多案例1：系統(tǒng)突然卡頓客戶系統(tǒng)某天告警，15:10-15:25 系統(tǒng)卡頓RAC環(huán)境的GC等待GC等待，本質上就是節(jié)點間的交互gc buffer busy *gc current block *gc cr *- 并發(fā)訪問- 獲取當前塊- 獲取一致性塊gc current與gc cr語句都是最簡單的insert相關：insert into xxx v

2、alues(,)current請求就是訪問數(shù)據(jù)塊本身, 發(fā)生于DMLcr請求就是根據(jù)不同情況訪問數(shù)據(jù)塊本身或者前鏡像(undo),主要發(fā)生于select解決GC等待的常見方法最常見：應用分區(qū)，避免訪問同樣數(shù)據(jù)其次：優(yōu)化內聯(lián)網(wǎng)- 萬兆網(wǎng)卡- IB網(wǎng)卡其他：bug進程繁忙采取第一步措施客戶已經做了嚴格的應用分區(qū)其中一個節(jié)點（節(jié)點2）完全不跑應用內聯(lián)網(wǎng)為萬兆RAC相關進程CPU正常采取第一步措施檢查x$bh/v$bh, 發(fā)現(xiàn)部分塊在節(jié)點2也存在，懷疑是統(tǒng) 計信息收集select count(*),ownerfrom x$bh h ,dba_objects o where o.data_object_

3、id = h.obj措施：強制統(tǒng)計信息收集在節(jié)點1上運行強行flush 節(jié)點2的buffer cachealter system flush buffer cache;問題未能解決第二天接近的時間點，問題再次發(fā)生第三天接近的時間點，問題再再次發(fā)生罪魁禍首一個醫(yī)院，在重癥監(jiān)護室，死亡 率從某個時候起突然高起來，而 經過醫(yī)生的分析，每天早上8點的 死亡率，比其他時間段高很多罪魁禍首一個醫(yī)院，在重癥監(jiān)護室，死亡 率從某個時候起突然高起來，而 經過醫(yī)生的分析，每天早上8點的 死亡率，比其他時間段高很多原來，每天8點清潔阿姨拔掉呼吸機的電源，開始 打掃衛(wèi)生是否存在同樣的規(guī)律？由于主機間的塊傳輸由lms進

4、程負責，檢查故障期間的Lms進程日志，發(fā)現(xiàn)如下日 志：2020-09-26 15:31:30.766 = Two consecutive receive calls took in 5945 ms = 2020-09-26 15:31:30.767 = Two consecutive receive calls took in 7274 ms = 2020-09-26 15:31:30.807 = Two consecutive receive calls took in 8494 ms = 2020-09-26 15:31:30.835 = Two consecutive receive c

5、alls took in 6355 ms =是否存在同樣的規(guī)律？awk /Two consecutive receive calls took/ t=substr($2,1,5);wait=$(NF-2)/1000;if( wait=3;cnt3t+); if( wait=2;cnt2t+); if( wait=1;cnt1t+); ENDfor (i in cnt1)print i,cnt1i,cnt2i,cnt3i *lms*.trc是否存在同樣的規(guī)律？每六小時出 現(xiàn)一次哪個阿姨每六個小時打掃一次衛(wèi)生？與客戶配合，發(fā)動所有力量主機工程師網(wǎng)絡工程師監(jiān)控負責人存儲工程師應用開發(fā)人員排除了在操作

6、系統(tǒng)、網(wǎng)絡、監(jiān)控中6個小時為周期的工作。而數(shù)據(jù)庫和應 用本身也不存在6個小時為周期的任務。CRS？回到crs,檢查集 群日志oswps.datOracle自治數(shù)據(jù)庫尋根問底What is OraJavaAgentDriver?搜索Oracle官網(wǎng)，發(fā)現(xiàn)OraJavaAgentDriver對應的是Oracle的cvu組件，全稱是Cluster Verification Utility,是Oracle CRS健康檢查的一個工具，在CRS作為資源存在，名字是ora.cvu。ora.cvu是6個小時打掃一次衛(wèi)生的阿姨嗎?crsctl stat res ora.cvu -p21600=3600*6解決問

7、題由于Oracle CVU主要是初始安裝時用來檢查系統(tǒng)狀況是否符合安裝標準，如果后續(xù)整個集群沒有硬件和操作系統(tǒng)變更，理論上來說，不會有變化，因此，該組件可以禁用。禁用方法如下： crsctl stop ora.cvu crsctl disable ora.cvu數(shù)據(jù)庫問題不僅僅是數(shù)據(jù)庫本身頭痛醫(yī)頭？腦部問題？ 運動過量？心臟供血不足？ 氧氣含量低?吸入有毒氣體？ 發(fā)燒？。案例：數(shù)據(jù)庫hung節(jié)點2在10月1日12點36分時候突然拋出無法在操作系統(tǒng)上創(chuàng)建生成任 務進程的異常：Thu Oct 01 12:35:30 GMT+08:00 2020ARC1: Standby redo logfile

8、selected for thread 2 sequence 109637 for destination LOG_ARCHIVE_DEST_2Thu Oct 01 12:36:24 GMT+08:00 2020kkjcre1p: unable to spawn jobq slave process Thu Oct 01 12:36:24 GMT+08:00 2020Errors in file /oracle/admin/epmdb/bdump/epmdb2_cjq0_5243470.trc:Thu Oct 01 12:41:29 GMT+08:00 2020ksvcreate: Proce

9、ss(m000) creation failedThu Oct 01 12:46:35 GMT+08:00 2020kkjcre1p: unable to spawn jobq slave process Thu Oct 01 12:46:35 GMT+08:00 2020Errors in file /oracle/admin/epmdb/bdump/epmdb2_cjq0_5243470.trc:主機資源占用正常CPU占用正常 內存用量正常procstack和ps elf hung* SESSION ID:(3904.1) 2020-10-01 12:32:20.508Waited for

10、 process J003 to initialize for 60 seconds* 2020-10-01 12:32:20.514swap info: free_mem = 136988.31M rsv = 612.00M alloc = 651.48M avail = 156672.00M swap_free = 156020.52Mskgpgcmdout: read() for cmd /bin/sh -c /usr/bin/procstack 13697324 2&1 timed out after 18.798 secondsskgpgcmdout: read() for cmd /bin/ps -elf | /bin/egrep PID | 18022634 | /bin/grep -v grep timed out after 15.000 seconds主機工程師介入，發(fā)現(xiàn)是操作系統(tǒng)