凌晨兩點(diǎn)被監(jiān)控電話叫醒RAC某個(gè)節(jié)點(diǎn)被集群驅(qū)逐業(yè)務(wù)側(cè)報(bào)錯(cuò)蜂擁而至登錄服務(wù)器看到CRS資源一片紅。干過Oracle RAC運(yùn)維的人基本都經(jīng)歷過這種場面。真正拉開差距的不是你會(huì)不會(huì)重啟而是你能不能在三五分鐘內(nèi)判斷該看哪一本日志日志里的哪幾行字符才是關(guān)鍵證據(jù)。RAC架構(gòu)下的故障調(diào)查和日志路徑定位就是這樣一件“看著不起眼、做起來要命”的事。這篇文章把我這些年摸出來的RAC日志地圖和排查習(xí)慣整理出來適合正在帶RAC項(xiàng)目的DBA也適合剛接觸集群、對(duì)一堆日志目錄還沒建立起整體感覺的新手。目標(biāo)是讓你下次接到故障電話時(shí)第一反應(yīng)不是亂翻目錄而是按層、按節(jié)點(diǎn)、按時(shí)間線有序排查。1. 為什么要先建立RAC日志地圖1.1 單實(shí)例日志思維為什么不夠用單實(shí)例Oracle出問題Alert Log加Trace文件基本就是全部答案最多再看一眼監(jiān)聽日志和操作系統(tǒng)日志半小時(shí)內(nèi)能把來龍去脈理清楚。但RAC完全不是這套玩法。RAC多了一層集群件GIGrid Infrastructure還多了節(jié)點(diǎn)間的心跳網(wǎng)絡(luò)、共享存儲(chǔ)、ASM實(shí)例、SCAN監(jiān)聽任何一個(gè)環(huán)節(jié)出問題都會(huì)同時(shí)在不同日志里留下片段。你可能會(huì)遇到這種情況ocssd.log里記著節(jié)點(diǎn)被驅(qū)逐crsd.log里記著資源被關(guān)閉實(shí)例alert里只留下IPC通信報(bào)錯(cuò)監(jiān)聽日志里全是連接失敗OS messages里還能看到網(wǎng)卡丟包記錄——每本日志都有內(nèi)容但沒有一本能獨(dú)立講完整個(gè)故事。所以RAC排障的第一原則是先分層再分節(jié)點(diǎn)。你腦子里必須有一張日志地圖知道故障發(fā)生時(shí)應(yīng)該撲向哪一層、哪一個(gè)文件。1.2 RAC日志分層的整體框架我習(xí)慣把RAC的日志體系分成五層排障時(shí)按這個(gè)順序逐層推進(jìn)層次主要路徑/文件核心內(nèi)容典型場景集群件層GI$GRID_HOME/log/節(jié)點(diǎn)名/CRS、CSS、EVM、GIPC、mDNS等組件日志節(jié)點(diǎn)驅(qū)逐、資源切換、集群無法啟動(dòng)數(shù)據(jù)庫實(shí)例層$ORACLE_BASE/diag/rdbms/db_unique_name/實(shí)例名/trace/實(shí)例alert、前臺(tái)/后臺(tái)traceORA錯(cuò)誤、性能問題、壞塊ASM層$ORACLE_BASE/diag/asm/asm/asm實(shí)例名/trace/磁盤組掛載、ASM實(shí)例狀態(tài)、I/O錯(cuò)誤ASM磁盤組dismount、存儲(chǔ)鏈路異常監(jiān)聽層$ORACLE_BASE/diag/tnslsnr/節(jié)點(diǎn)名/連接建立、拒絕、超時(shí)業(yè)務(wù)連不上、SCAN VIP異常操作系統(tǒng)層/var/log/messages、dmesg、journalctl內(nèi)存、網(wǎng)絡(luò)、存儲(chǔ)、NTP、OOM私網(wǎng)丟包、內(nèi)存耗盡、時(shí)鐘跳變這張地圖不需要死記硬背但至少要形成條件反射看到“節(jié)點(diǎn)驅(qū)逐”先想到ocssd和GI alert看到“資源offline”先想到crsd看到“連接失敗”先想到監(jiān)聽日志和網(wǎng)絡(luò)層。2. 集群件GI層日志路徑詳解2.1 GI日志的根目錄$GRID_HOME/logGI日志不放在ADR里它獨(dú)立放在GI安裝目錄下結(jié)構(gòu)是$GRID_HOME/log/節(jié)點(diǎn)名/GRID_HOME在不同版本里位置不一樣常見的有/u01/app/11.2.0/grid、/u01/app/19.0.0/grid、/u01/app/grid等。你需要先用grid用戶確認(rèn)環(huán)境變量echo $GRID_HOME echo $ORACLE_HOME注意在grid用戶下ORACLE_HOME通常就是GRID_HOME。好多人排障時(shí)用oracle用戶登錄環(huán)境變量指向數(shù)據(jù)庫軟件的ORACLE_HOME結(jié)果一個(gè)勁兒在數(shù)據(jù)庫軟件目錄里找集群日志自然找不到。這是第一個(gè)容易踩的坑。進(jìn)入$GRID_HOME/log/節(jié)點(diǎn)名/你會(huì)看到以下核心文件文件/目錄進(jìn)程對(duì)應(yīng)關(guān)注點(diǎn)alert.log集群級(jí)告警所有重大事件的匯總?cè)肟赾rsd/crsd.logCluster Ready Services資源狀態(tài)變遷、OCR訪問cssd/ocssd.logCluster Synchronization Services節(jié)點(diǎn)成員關(guān)系、心跳、驅(qū)逐evmd/evmd.logEvent Manager事件發(fā)布、FAN通知gipcd/gipcd.logGrid IPC私網(wǎng)通信、網(wǎng)絡(luò)心跳mdnsd/mdnsd.logmDNS集群名稱解析、GNS相關(guān)ohasd/ohasd.logOracle High Availability Services集群啟動(dòng)第一階段agent/crsd/各類資源Agentora.*資源啟動(dòng)/停止/故障轉(zhuǎn)移2.2 排障首選的集群alert與組件日志集群alert.log是第一個(gè)要打開的文件。它不像數(shù)據(jù)庫alert那樣記錄SQL和內(nèi)部錯(cuò)誤而是記錄集群層面的關(guān)鍵事件節(jié)點(diǎn)加入/離開、資源狀態(tài)變化、OCR切換、ASM磁盤組掛載失敗等。節(jié)點(diǎn)驅(qū)逐發(fā)生之前這里通常已經(jīng)寫了原因相關(guān)的提示。ocssd.log是節(jié)點(diǎn)驅(qū)逐調(diào)查的重頭。CSS進(jìn)程負(fù)責(zé)維護(hù)節(jié)點(diǎn)成員關(guān)系私網(wǎng)心跳斷了、磁盤心跳異常、misscount超時(shí)都可能導(dǎo)致一個(gè)節(jié)點(diǎn)被另一個(gè)節(jié)點(diǎn)強(qiáng)制驅(qū)逐。在這個(gè)文件里搜這些關(guān)鍵詞grep -iE evict|reboot|not reachable|misscount|timeout \ $GRID_HOME/log/$(hostname -s)/cssd/ocssd.log如果看到clssnmPollingThread這類條目基本可以確定是心跳層面的問題接下來去查私網(wǎng)、防火墻、網(wǎng)卡驅(qū)動(dòng)。crsd.log記錄資源層的動(dòng)作。比如某個(gè)節(jié)點(diǎn)的ora.db1.db資源突然offline或者VIP failover到另一節(jié)點(diǎn)都能在這里找到來龍去脈。常見錯(cuò)誤如File not found、OCR initialization failed等會(huì)直接指向OCR或文件權(quán)限問題。gipcd.log和mdnsd.log是網(wǎng)絡(luò)排查的關(guān)鍵配角。私網(wǎng)通信異常時(shí)gipcd.log里會(huì)出現(xiàn)GIPC_retry、connection timed out之類信息mDNS解析出問題則可能表現(xiàn)為節(jié)點(diǎn)無法加入集群、SCAN VIP解析異常。很多RAC隱患其實(shí)早就在這兩個(gè)日志里有了苗頭只是平時(shí)沒人看。2.3 動(dòng)態(tài)獲取GI日志位置與配套命令路徑記不準(zhǔn)時(shí)用命令動(dòng)態(tài)獲取狀態(tài)信息比死記硬背可靠# 查看集群資源整體狀態(tài) crsctl stat res -t # 查看OCR備份情況 ocrconfig -showbackup # 檢查OCR完整性 ocrcheck # 查看votedisk位置 crsctl query css votedisk另外如果是安裝或升級(jí)后集群起不來還要看配置日志目錄$GRID_HOME/cfgtoollogs/比如crsinstall子目錄下的crsinstall_crs_節(jié)點(diǎn)名.log記錄了root.sh執(zhí)行過程中每個(gè)步驟的結(jié)果。19c安裝腳本卡住時(shí)這個(gè)文件往往比任何排障日志都直接。3. 數(shù)據(jù)庫實(shí)例與ASM層日志路徑3.1 實(shí)例ADR結(jié)構(gòu)與alert日志數(shù)據(jù)庫實(shí)例的日志由ADRAutomatic Diagnostic Repository管理核心路徑是$ORACLE_BASE/diag/rdbms/db_unique_name/實(shí)例名/trace/alert_實(shí)例名.log以O(shè)RACLE_BASE/u01/app/oracle、庫名orcl、實(shí)例orcl1為例完整路徑是tail -f /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/alert_orcl1.log注意db_unique_name和實(shí)例名不一定相同RAC里實(shí)例名一般是orcl1、orcl2這種帶節(jié)點(diǎn)編號(hào)的而db_unique_name就是數(shù)據(jù)庫本身的名字。別拿實(shí)例名去匹配目錄名要用adrci確認(rèn)。最快的確認(rèn)方式是用SQL直接查SELECT name, value FROM v$diag_info;ADR Base那一行就是$ORACLE_BASEDiag Trace那一行就是trace目錄。也可以命令行下用adrciadrci adrci show homes adrci set home diag/rdbms/orcl/orcl1 adrci show alert -tail 50老系統(tǒng)10g、11.1沒有完整ADR實(shí)例日志在background_dump_dest和user_dump_dest指向的目錄一般可以在$ORACLE_HOME/rdbms/log附近找到。如果你接手的是老版本RAC先show parameter dump_dest確認(rèn)一下別再按11.2以后的路徑找。3.2 ASM實(shí)例與監(jiān)聽日志ASM實(shí)例的日志也在ADR下結(jié)構(gòu)類似$ORACLE_BASE/diag/asm/asm/asm1/trace/alert_asm1.log注意ASM實(shí)例名一般叫ASM1、ASM2目錄名里帶加號(hào)。ASM disk group dismount、ASM實(shí)例異常重啟、I/O錯(cuò)誤都從這本alert看起。比如ORA-15063表示ASM無法定位磁盤ORA-15032表示磁盤組操作失敗這些錯(cuò)誤會(huì)同時(shí)出現(xiàn)在ASM alert和OCR/集群日志里需要交叉印證。這里有個(gè)隱藏坑ASM和數(shù)據(jù)庫的ORACLE_BASE可能不是同一個(gè)。如果grid軟件和oracle軟件分開安裝ASM的$ORACLE_BASE通常是grid的路徑比如/u01/app/grid而數(shù)據(jù)庫實(shí)例的$ORACLE_BASE才是/u01/app/oracle。用oracle用戶登錄后直接按/u01/app/oracle找ASM日志必然撲空。建議在grid用戶下執(zhí)行echo $ORACLE_BASE再看。監(jiān)聽日志也在ADR體系里但是獨(dú)立的一類$ORACLE_BASE/diag/tnslsnr/節(jié)點(diǎn)名/listener/trace/listener.logRAC還有SCAN監(jiān)聽對(duì)應(yīng)目錄$ORACLE_BASE/diag/tnslsnr/節(jié)點(diǎn)名/listener_scan1/trace/listener_scan1.log如果是老版本監(jiān)聽日志可能在$ORACLE_HOME/network/log/。快速確認(rèn)方法lsnrctl show log_directory3.3 從alert到trace的推導(dǎo)線索實(shí)例alert.log里記錄ORA錯(cuò)誤只是一個(gè)起點(diǎn)真正的細(xì)節(jié)都在對(duì)應(yīng)的trace文件里?？吹絆RA-600、ORA-3137這類錯(cuò)誤時(shí)alert里通常會(huì)標(biāo)注類似Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_12345.trc的路徑直接打開這個(gè)trace文件。排查SQL性能或存儲(chǔ)過程問題時(shí)也可以主動(dòng)制造trace。比如ALTER SESSION SET EVENTS 10046 trace name context forever, level 12; -- 執(zhí)行目標(biāo)SQL ALTER SESSION SET EVENTS 10046 trace name context off;生成的trace文件會(huì)帶著會(huì)話ID出現(xiàn)在實(shí)例trace目錄里。RAC節(jié)點(diǎn)間負(fù)載均衡時(shí)要先確認(rèn)會(huì)話落在了哪個(gè)實(shí)例再去對(duì)應(yīng)節(jié)點(diǎn)的trace目錄找文件。4. 操作系統(tǒng)層日志與跨節(jié)點(diǎn)排查思路4.1 系統(tǒng)日志里藏著RAC的“前傳”很多RAC故障的根因并不在Oracle層而在操作系統(tǒng)。最常見的就是私網(wǎng)網(wǎng)卡問題、內(nèi)存不足觸發(fā)OOM killer、存儲(chǔ)鏈路超時(shí)、NTP時(shí)鐘跳變。這些都在系統(tǒng)日志里有記錄。Linux環(huán)境優(yōu)先級(jí)最高的是/var/log/messages排障時(shí)重點(diǎn)搜以下關(guān)鍵詞grep -iE out of memory|oom-killer|network|link down|NIC|ntp|time step /var/log/messages尤其要注意的是RAC節(jié)點(diǎn)被驅(qū)逐很多時(shí)候是“果”不是“因”。比如某節(jié)點(diǎn)內(nèi)存耗盡觸發(fā)OOM導(dǎo)致CSS進(jìn)程被殺繼而整個(gè)節(jié)點(diǎn)被集群驅(qū)逐。這種場景下如果只盯著ocssd.log看你會(huì)一直糾結(jié)“為什么心跳會(huì)斷”而實(shí)際上OS日志早就告訴你原因了。另外dmesg -T也是快速排查內(nèi)核級(jí)問題的工具特別是存儲(chǔ)多路徑和網(wǎng)卡收包異常dmesg -T | grep -iE error|fail|timeout|scsi|eth4.2 RAC對(duì)時(shí)鐘同步的敏感與日志佐證RAC對(duì)節(jié)點(diǎn)間時(shí)鐘偏差非常敏感。集群內(nèi)時(shí)間不同步輕則日志時(shí)間線混亂重則影響事務(wù)一致性判斷甚至誘發(fā)節(jié)點(diǎn)驅(qū)逐。19c環(huán)境檢查NTP/chrony狀態(tài)timedatectl chronyc sources -v如果OS日志里能看到類似時(shí)鐘跳變、time step的信息就要高度懷疑集群故障與時(shí)鐘漂移有關(guān)。而且時(shí)鐘不一致會(huì)直接影響你跨節(jié)點(diǎn)排查時(shí)的判斷——同一個(gè)事件在兩個(gè)節(jié)點(diǎn)日志里的時(shí)間戳不一樣會(huì)讓人誤以為事件順序有問題。所以跨節(jié)點(diǎn)排查前第一件事就是對(duì)兩邊的date輸出。4.3 跨節(jié)點(diǎn)時(shí)間線對(duì)照排查法RAC排障不能只看單個(gè)節(jié)點(diǎn)尤其節(jié)點(diǎn)驅(qū)逐類問題必須同時(shí)拉出兩個(gè)甚至所有節(jié)點(diǎn)的關(guān)鍵日志按時(shí)間排列。我常用的做法是把每個(gè)節(jié)點(diǎn)的關(guān)鍵事件抓出來統(tǒng)一放到一個(gè)文件里排序for node in node1 node2; do ssh $node grep -iE evict|reboot|error|alert \ $GRID_HOME/log/$node/alert.log | sed s/^/[$node] / done | sort這樣能快速看出節(jié)點(diǎn)A在幾點(diǎn)幾分開始心跳異常節(jié)點(diǎn)B在幾點(diǎn)幾分發(fā)起驅(qū)逐節(jié)點(diǎn)A在幾點(diǎn)幾分才寫實(shí)例alert。時(shí)間線一對(duì)齊因果鏈就出來了。這一步看起來簡單但很多人排障時(shí)容易忽略導(dǎo)致在單個(gè)節(jié)點(diǎn)的日志里反復(fù)打轉(zhuǎn)。5. 典型故障場景的日志速查與排查路線5.1 節(jié)點(diǎn)驅(qū)逐先看ocssd還是先看GI alert節(jié)點(diǎn)驅(qū)逐是RAC最典型、也最讓人頭疼的故障。我的排查順序是打開GI alert.log看驅(qū)逐前后的集群事件描述通常能拿到最粗的定位方向。打開ocssd.log搜evict、not reachable、misscount等關(guān)鍵詞確認(rèn)是私網(wǎng)心跳問題還是磁盤心跳問題。打開OS messages確認(rèn)網(wǎng)絡(luò)、內(nèi)存、存儲(chǔ)有沒有異常記錄。回到數(shù)據(jù)庫alert看實(shí)例退出的最后動(dòng)作。這里有個(gè)常見誤區(qū)一上來就翻數(shù)據(jù)庫alert。數(shù)據(jù)庫實(shí)例只是集群的“被管理者”它往往是被動(dòng)退出日志里沒有根因。根因大概率在集群層或OS層。5.2 CRS資源異常與OCR故障如果crsctl stat res -t看到資源反復(fù)offline、啟動(dòng)失敗或處于UNKNOWN狀態(tài)處理路徑是打開crsd.logtail -200 $GRID_HOME/log/$(hostname -s)/crsd/crsd.log搜索關(guān)鍵詞error、failed、ocr、permission、cannot。OCR相關(guān)故障比較隱蔽。OCR文件損壞或無法同步時(shí)crsd.log里會(huì)出現(xiàn)OCR讀取失敗的信息。先用ocrcheck確認(rèn)OCR完整性再用ocrconfig -showbackup看自動(dòng)備份。OCR自動(dòng)備份默認(rèn)放在$GRID_HOME/cdata/節(jié)點(diǎn)名/下比如ls -l $GRID_HOME/cdata/$(hostname -s)/如果OCR真的出了問題可以用最近的備份恢復(fù)。需要提醒的是OCR備份文件屬于集群元數(shù)據(jù)日常巡檢時(shí)最好納入備份監(jiān)控不要等故障了才發(fā)現(xiàn)備份都過期了。5.3 監(jiān)聽異常業(yè)務(wù)連不上的第一現(xiàn)場RAC環(huán)境業(yè)務(wù)連接失敗時(shí)很多人第一反應(yīng)是查應(yīng)用、查防火墻其實(shí)應(yīng)該先看監(jiān)聽日志。連接失敗、超時(shí)、拒絕都會(huì)在listener.log里留下明確記錄。tail -200 $ORACLE_BASE/diag/tnslsnr/$(hostname -s)/listener/trace/listener.log常見錯(cuò)誤TNS-12537 TNS-12560監(jiān)聽器自身異常或網(wǎng)絡(luò)斷開。TNS-12514服務(wù)名沒有注冊(cè)可能要看實(shí)例是否注冊(cè)到監(jiān)聽。Connection timeout可能涉及防火墻或私網(wǎng)質(zhì)量。如果是SCAN連接失敗除了看SCAN監(jiān)聽日志還要檢查DNS解析是否正常。SCAN VIP對(duì)應(yīng)的域名解析結(jié)果必須包含所有節(jié)點(diǎn)DNS只返回一個(gè)IP往往會(huì)導(dǎo)致單點(diǎn)故障。5.4 ASM磁盤組與實(shí)例故障ASM磁盤組dismount、ASM實(shí)例異常、存儲(chǔ)鏈路故障這三者經(jīng)常串在一起。排查順序是ASM alert日志比如alert_asm1.log搜ORA-15063、dismount、I/O error。ASM實(shí)例trace目錄確認(rèn)具體是哪塊磁盤、哪個(gè)ASM盤失敗。操作系統(tǒng)存儲(chǔ)層日志dmesg和/var/log/messages里搜multipath、io error、timeout判斷是HBA卡、光纖線還是存儲(chǔ)設(shè)備問題。實(shí)例啟動(dòng)失敗時(shí)數(shù)據(jù)庫alert里通常能看到ORA-29701cluster無法識(shí)別實(shí)例、ORA-29740實(shí)例心跳失敗之類錯(cuò)誤這些錯(cuò)誤要和集群日志配合著看單看任何一本都不完整。5.5 常見故障日志速查表故障現(xiàn)象優(yōu)先查看日志關(guān)鍵搜索詞輔助日志節(jié)點(diǎn)驅(qū)逐GI alert ocssd.logevict, not reachable, misscountOS messages, gipcd.logCRS資源offlinecrsd.logerror, failed, OCRagent/crsd下日志OCR損壞ocrcheck crsd.logOCR, checksum, format$GRID_HOME/cdata備份監(jiān)聽連接失敗listener.log / scan監(jiān)聽日志TNS-12537, TNS-12514, timeout實(shí)例注冊(cè)狀態(tài)ASM磁盤組dismountASM alertORA-15063, dismount, I/O errordmesg, multipath日志實(shí)例啟動(dòng)失敗實(shí)例alert traceORA-29701, ORA-29740crsd.log, OS messages6. 我在實(shí)際排障中用到的幾個(gè)實(shí)用技巧6.1 日志膨脹與磁盤空間檢查要養(yǎng)成肌肉記憶排障過程中最容易忽略的其實(shí)是磁盤空間。$GRID_HOME/log、$ORACLE_BASE/diag都是日志增長大戶。crsd.log長時(shí)間不清理漲到幾個(gè)GB很常見實(shí)例alert和trace文件在故障發(fā)生后會(huì)瞬間暴漲。如果/u01被日志塞滿輕則Oracle進(jìn)程報(bào)錯(cuò)重則整個(gè)集群異常雪上加霜。我的習(xí)慣是任何RAC排查開始前先執(zhí)行一條df -h確認(rèn)關(guān)鍵分區(qū)剩余空間。這浪費(fèi)不了半分鐘但能避免后期無法生成trace文件、無法寫dump文件的窘境。日常管理中ADR部分可以利用adrci設(shè)置保留策略adrci set home diag/rdbms/orcl/orcl1 adrci purge -age 43200 -type trace43200是分鐘數(shù)相當(dāng)于30天。GI日志不在ADR管理范圍內(nèi)需要靠腳本定期歸檔清理。注意不要直接rm正在被進(jìn)程寫入的日志文件容易造成文件句柄懸空、空間無法釋放。正確做法是先把日志mv走再配合進(jìn)程或維護(hù)窗口處理。6.2 調(diào)整組件日志級(jí)別的正確姿勢一般不需要?jiǎng)尤罩炯?jí)別默認(rèn)級(jí)別足夠日常排查。但如果某些問題復(fù)現(xiàn)頻率低、線索模糊可以針對(duì)組件臨時(shí)調(diào)高日志級(jí)別crsctl set log level 3 cssd調(diào)高后會(huì)記錄更細(xì)的CSS交互過程對(duì)定位心跳類問題有幫助。但注意日志級(jí)別調(diào)高意味著IO開銷增大、日志量暴增高峰期慎用。排查結(jié)束后記得調(diào)回原級(jí)別否則日志可能以極快速度膨脹。6.3 疑難問題記得收集診斷包遇到自己搞不定、需要求助的場景別手動(dòng)打包一堆日志直接用官方工具11.2及以后版本可以用diagcollection.sh$GRID_HOME/bin/diagcollection.sh --collect12.2以后更推薦TFA$GRID_HOME/bin/tfactl diagcollect -type daily -srdcTFA會(huì)把GI日志、數(shù)據(jù)庫日志、OS日志、網(wǎng)絡(luò)配置等匯總成一個(gè)壓縮包并自動(dòng)帶上時(shí)間戳。給原廠support提SR時(shí)這個(gè)包比你自己零散截取的日志有價(jià)值得多。排障經(jīng)驗(yàn)豐富的人未必每類問題都能獨(dú)立解決但懂得在合適的時(shí)機(jī)收集完整證據(jù)鏈?zhǔn)菍I(yè)DBA的重要素質(zhì)。6.4 我個(gè)人的排查習(xí)慣最后分享一個(gè)自己的習(xí)慣不一定適合所有人但實(shí)測多次都很穩(wěn)接到RAC故障報(bào)告后不急著看alert也不急著重啟先花兩分鐘做三件事——df -h看磁盤、date確認(rèn)本機(jī)時(shí)間、crsctl stat res -t看資源全景。然后才打開GI alert順著時(shí)間線往下翻。這三件事解決的是“方向”問題。方向?qū)α撕罄m(xù)看ocssd、crsd、實(shí)例日志時(shí)內(nèi)心已經(jīng)有一個(gè)基本判斷。方向錯(cuò)了可能在某個(gè)組件的trace文件里翻一晚上最后一查是磁盤滿了或時(shí)間漂移。RAC排障不是拼手速是拼誰的地圖更清晰、誰更早鎖定層次。日志路徑從來不是背出來的而是在一次次故障現(xiàn)場練出來的。