簡介dgreadiness_v3.6.zip 面向在 Windows 10 上使用 VMware Workstation 運行 Ubuntu 等虛擬機(jī)的開發(fā)與運維人員針對關(guān)閉 Hyper-V 后仍提示 VMware 與 Device/Credential Guard 不兼容、虛擬機(jī)無法啟動的問題提供基于 Windows Defender Device Guard 與 Credential Guard 硬件就緒工具的禁用方案。壓縮包共 6 個文件約 32KB包含 PowerShell 工具腳本、p7b 策略文件、xml 配置模板和 txt 說明文檔分別用于執(zhí)行禁用配置、承載策略設(shè)置、提供審計/強(qiáng)制模式模板及使用說明體量輕便、結(jié)構(gòu)明確。已有 3189 人學(xué)習(xí)下載說明該問題在 Win10 虛擬機(jī)場景中較常見。讀者可借助其中的腳本與策略模板快速完成 Credential Guard 關(guān)閉減少手動修改組策略和注冊表的試錯成本也可據(jù)說明文檔理解各配置項作用為同類兼容性排錯提供參考。1. dgreadiness_v3.6.zip 不是安裝包是切換前的一張體檢單dgreadiness_v3.6.zip 這個名字本身就說明了它的形態(tài)一個壓縮包、帶版本號、沒有安裝向?qū)Ы忾_來是一堆 SQL 和 shell。它的作用不是部署容災(zāi)而是在你已經(jīng)有一套主備庫主庫 一個或多個備庫之后回答一個很具體的問題——現(xiàn)在這一刻我敢不敢做切換演練很多團(tuán)隊的做法是切之前拉個會幾個人分別敲幾條命令看看憑感覺拍板這個包要做的事是把這些零散判斷固化成一份可重復(fù)、可對比、可交給別人的報告。它適合兩類人一類是要定期做容災(zāi)演練的 DBA另一類是接手了一套沒人維護(hù)的備庫、想先摸清底細(xì)的運維。讀完你能自己解包、配連接、改檢查項、定閾值也知道哪些綠燈其實是假的。2. 就緒度先立標(biāo)準(zhǔn)六類檢查項和它們的權(quán)重怎么定打開一個 readiness 包最忌諱的動作是直接bash run.sh然后盯著輸出里紅色的那幾行看。紅色代表什么、多紅才算不能切、這次紅下次綠是環(huán)境變了還是腳本抽風(fēng)——這些問題在腳本里沒有答案得你自己先定。所以第一章不做操作先把“ready”這個詞拆成可判定的指標(biāo)。2.1 傳輸層、應(yīng)用層、結(jié)構(gòu)層就緒度的三個觀察面我把所有檢查項歸到三個觀察面這個分法決定了后面報告的排版也決定了排錯時的查找順序。傳輸層看的是日志能不能從主庫順利落到備庫歸檔目的地狀態(tài)是不是 VALID、有沒有 ERROR 文本、傳輸延遲多少、歸檔目的地所在文件系統(tǒng)的剩余空間、網(wǎng)絡(luò)往返時延和帶寬是否夠峰值 redo 量。這一層出問題表現(xiàn)是備庫長時間收不到新日志但主庫業(yè)務(wù)一切正常最容易被忽略。應(yīng)用層看的是日志到了之后有沒有被真正應(yīng)用MRP 進(jìn)程在不在、狀態(tài)是 APPLYING_LOG 還是 WAITING_FOR_LOG、應(yīng)用延遲多少、備庫已應(yīng)用的最大序列號和主庫當(dāng)前序列號差多少、有沒有歸檔缺口GAP。這一層最容易出“假綠燈”后面避坑那章會專門講。結(jié)構(gòu)層看的是兩邊長得像不像db_unique_name 和 log_archive_config 是否互認(rèn)、standby_file_management 是否 AUTO、保護(hù)模式和 redo 傳輸是 SYNC 還是 ASYNC、standby redo log 的組數(shù)和單組大小、臨時文件和數(shù)據(jù)文件路徑、密碼文件、以及多租戶下每個 PDB 的狀態(tài)。結(jié)構(gòu)層的問題平時完全不疼一切換就卡死是典型的“平時不查、演練翻車”。三個面里傳輸層和應(yīng)用層是動態(tài)指標(biāo)數(shù)值會隨業(yè)務(wù)波動結(jié)構(gòu)層是靜態(tài)指標(biāo)除非有人改配置否則長期不變。這個差異直接影響采集頻率動態(tài)指標(biāo)要頻繁采、看趨勢靜態(tài)指標(biāo)一次采完存成基線就行不必每次全量跑。提示如果包里的檢查項命名和上面不一樣不要急著改腳本先按這三個面把現(xiàn)有項歸類缺哪一類再補(bǔ)比重寫省事得多。2.2 權(quán)重怎么定按「切換后多久能對外服務(wù)」倒推權(quán)重不是技術(shù)參數(shù)是業(yè)務(wù)參數(shù)。我的做法是問一句話這一項不達(dá)標(biāo)切換后要多花多久才能對外服務(wù)答案越長權(quán)重越高。按這個口徑歸檔缺口和結(jié)構(gòu)層錯配是最貴的——缺口意味著要補(bǔ)日志甚至重建結(jié)構(gòu)錯配意味著切換根本起不來這兩類給高權(quán)重傳輸延遲和應(yīng)用延遲影響的是切換瞬間丟多少數(shù)據(jù)、追平要多久中等權(quán)重目的地狀態(tài)、SRL 配置這類屬于“不達(dá)標(biāo)立刻知道、修起來也快”的低權(quán)重。檢查項觀察面權(quán)重不達(dá)標(biāo)后果歸檔序列缺口應(yīng)用層25需補(bǔ)日志或重建備庫參數(shù)與結(jié)構(gòu)一致性結(jié)構(gòu)層20切換可能直接失敗應(yīng)用延遲應(yīng)用層20切換后追平日志耗時長傳輸延遲傳輸層15數(shù)據(jù)丟失窗口變大目的地狀態(tài)與錯誤文本傳輸層10日志傳輸中斷SRL 組數(shù)與大小結(jié)構(gòu)層10切換時日志寫不下這張表不需要照抄權(quán)重之和湊夠 100 就行關(guān)鍵是每一項的權(quán)重你能對著業(yè)務(wù)說清楚理由。說不清理由的項要么刪掉要么降權(quán)別放在那里制造噪音。2.3 判定口徑要先寫死否則報告沒法比較分?jǐn)?shù)之外還要有檔位否則你只知道“78 分”不知道“78 分能不能切”。我一般分三檔PASS、WARN、FAIL。PASS 拿滿分WARN 拿一半FAIL 拿零分。但光有分?jǐn)?shù)不夠——結(jié)構(gòu)層錯配這種項哪怕總分 95 也不能切所以還要引入“否決項”概念歸檔缺口、SRL 配置、參數(shù)一致性這三項只要有一個 FAIL無論總分多少都判定為 NOT READY。這樣做的好處是報告有兩層結(jié)論分?jǐn)?shù)用來橫向比較這次 92、上次 88是在變好還是變差否決項用來縱向決策能不能現(xiàn)在切。只給分?jǐn)?shù)人會拿分?jǐn)?shù)當(dāng)擋箭牌只給否決項又看不出趨勢。兩者都要。還有一條容易被忽略口徑要寫進(jìn)配置文件不要寫死在腳本里。閾值、權(quán)重、否決項名單都放conf/env.conf這樣半年后別人接手改一個數(shù)字就能適配另一套庫不用讀懂 SQL。3. 解包與首輪巡檢三條命令跑出第一份報告標(biāo)準(zhǔn)立完動手。這一章的目標(biāo)不是跑出完美報告是在 20 分鐘內(nèi)跑出第一份“能看”的報告哪怕里面一半是 FAIL——先有基線再談優(yōu)化。3.1 解包與目錄約定先固定路徑再談自動化不要在原目錄里直接解壓。壓縮包解開后通常有bin/、sql/、conf/、out/這幾類目錄如果每次巡檢都解到不同路徑報告會散落在各處后面想做趨勢對比就得靠人肉找文件。我固定用一個版本化路徑# 固定安裝路徑按版本號分目錄升級時并存而不是覆蓋 sudo mkdir -p /opt/dgcheck/3.6 sudo unzip -q dgreadiness_v3.6.zip -d /opt/dgcheck/3.6 # 看一眼結(jié)構(gòu)確認(rèn)入口腳本和 SQL 目錄在哪 find /opt/dgcheck/3.6 -maxdepth 2 -type d | sort ls -l /opt/dgcheck/3.6/bin/ 2/dev/null || ls -l /opt/dgcheck/3.6 # 腳本給執(zhí)行權(quán)限但不要給全局可寫 sudo chown -R dbcheck:dba /opt/dgcheck/3.6 sudo chmod -R 750 /opt/dgcheck/3.6 sudo chmod 640 /opt/dgcheck/3.6/conf/*.conf 2/dev/null這段的關(guān)鍵點在三處。-d指定目標(biāo)目錄避免解壓出來的文件平鋪在當(dāng)前目錄把家目錄搞亂。find -maxdepth 2是先摸清結(jié)構(gòu)再決定怎么調(diào)因為不同打包習(xí)慣里入口腳本可能在bin/也可能在根目錄ls一次就知道比自己猜快。chmod 640給配置文件是因為里面通常有連接串和口令權(quán)限放開等于把庫的鑰匙掛在墻上。專用運行賬號也是必要的一步。我一般建一個只讀賬號dbcheck跑巡檢讓它屬于dba組以便讀v$視圖但不給它sysdba。巡檢腳本只需要看狀態(tài)不需要改任何東西——一個能改東西的巡檢腳本某天就會改錯東西這是血淚經(jīng)驗。注意如果包里帶.sh之外的可執(zhí)行文件比如編譯好的采集二進(jìn)制先用file看一眼架構(gòu)和依賴別在 x86 機(jī)器上跑 arm 的產(chǎn)物報錯信息會誤導(dǎo)你以為連不上庫。3.2 連接配置與最小巡檢命令配置文件只放連接信息和閾值不放任何邏輯。常見做法是conf/env.conf這種以 shell 變量形式被source進(jìn)來的文件# conf/env.conf —— 只放連接與閾值邏輯一律進(jìn)腳本 PRIMARY_TNSdg_primary # 主庫連接串走 tnsnames 或等價命名 STANDBY_TNSdg_standby # 備庫連接串 RUN_USERdbcheck # 巡檢專用賬號非 sysdba THRESH_TRANSPORT_LAG60 # 傳輸延遲告警線單位秒 THRESH_APPLY_LAG120 # 應(yīng)用延遲告警線單位秒 THRESH_ARCHIVE_GAP0 # 允許的序列缺口通常為 0 THRESH_FRA_PCT85 # 歸檔區(qū)使用率告警線百分比 DENY_ITEMSarchive_gap,srl_config,param_diff # 否決項名單四個閾值里前三個是硬指標(biāo)最后一個歸檔區(qū)使用率是很多人不做但極容易翻車的項——歸檔區(qū)滿的那一刻主庫會掛起備庫也跟著停屬于“平時不查、爆起來要命”的類型。DENY_ITEMS是把第 2 章的口徑落地的字段后面折算報告時直接讀這個變量。配好之后首輪就跑最小集合一個主庫側(cè)、一個備庫側(cè)別一上來跑全套不然輸出里幾百行你不知道哪行是關(guān)鍵的。#!/usr/bin/env bash # bin/first_run.sh —— 首輪最小巡檢只采集傳輸與應(yīng)用兩個面 set -uo pipefail BASE/opt/dgcheck/3.6 source $BASE/conf/env.conf TS$(date %Y%m%d_%H%M%S) OUT$BASE/out/$TS mkdir -p $OUT # 主庫歸檔目的地狀態(tài) 當(dāng)前最大序列 sqlplus -S $RUN_USER$PRIMARY_TNS $BASE/sql/10_primary.sql \ $OUT/primary.txt 21 # 備庫應(yīng)用進(jìn)程狀態(tài) 已應(yīng)用序列 sqlplus -S $RUN_USER$STANDBY_TNS $BASE/sql/20_standby.sql \ $OUT/standby.txt 21 echo report dir: $OUT grep -iE error|ORA-|SP2- $OUT/*.txt echo 存在錯誤先看上面幾行 || echo 采集無報錯set -uo pipefail沒有加-e這是有意的首輪巡檢最怕的是某項失敗就整體退出導(dǎo)致你只看到第一個問題、看不到后面的問題。所以讓每個采集動作各自失敗、各自留痕最后統(tǒng)一 grep 一遍錯誤關(guān)鍵字。-S是靜默模式去掉客戶端橫幅和提示符輸出更干凈后面好解析。時間戳精確到秒是為了同一天多次演練時不覆蓋文件。grep -iE error|ORA-|SP2-這行是一個廉價但有效的兜底。數(shù)據(jù)庫客戶端的報錯文本格式很好認(rèn)寬泛匹配一下就能把“沒連上庫”和“連上了但查詢出錯”區(qū)分開——這兩種情況后面的處理完全不一樣。3.3 輸出目錄與失敗兜底o(hù)ut/目錄要有輪轉(zhuǎn)策略別等它撐滿。一次全量巡檢的輸出不大但每天跑、跑半年加上有人手動重跑很容易堆到幾百個目錄。我一般保留最近 30 次全量 所有“變更前后”的對比目錄其余刪除# 只保留最近 30 個時間戳目錄其余清理命名規(guī)則必須嚴(yán)格按時間戳 cd /opt/dgcheck/3.6/out || exit 0 ls -1d 2*/ | sort | head -n -30 | xargs -r rm -rf前提是目錄名嚴(yán)格是YYYYMMDD_HHMMSSsort的字典序才等于時間序。如果包自帶的輸出目錄用了別的命名比如帶主機(jī)名就先改命名規(guī)則再用這條命令否則head -n -30刪掉的可能是昨天剛跑的基線這種翻車比不清理更糟。失敗兜底還有一個細(xì)節(jié)退出碼。巡檢腳本的退出碼要能被上層調(diào)度感知——0 表示全 PASS1 表示有 WARN2 表示有 FAIL 或否決項。這樣掛到定時任務(wù)或流水線上不用解析文本就知道結(jié)果。很多包默認(rèn)只 echo 不 return接進(jìn)自動化就得自己補(bǔ)這幾行。4. 改 SQL 與定閾值把通用檢查項調(diào)成你庫的形狀一份通用腳本跑在你自己的庫上一定會有一半檢查項“看起來對但不準(zhǔn)”。這不是腳本的問題是每套庫的形態(tài)差異太大有的單實例、有的多租戶有的保護(hù)模式要求零丟失、有的能接受幾分鐘延遲有的 redo 峰值每秒幾十兆、有的幾百 K。所以第三章的核心動作是改改 SQL 的取數(shù)口徑、改閾值的紅線位置。4.1 三類必改的 SQL序列缺口、備庫日志、參數(shù)一致性序列缺口是最該改的一條。很多腳本只查應(yīng)用延遲但延遲是個瞬時值——剛剛應(yīng)用完一批日志延遲會顯示接近 0哪怕中間其實缺了一段日志沒傳過來。真正的缺口要看序列號連續(xù)性-- sql/30_gap.sql主庫側(cè)取每個線程的當(dāng)前序列 set lines 200 pages 100 feedback off heading on col thread# format 999 col cur_seq format 9999999 select thread#, max(sequence#) as cur_seq from v$thread group by thread# order by thread#;-- sql/31_applied.sql備庫側(cè)取每個線程已應(yīng)用的序列 col thread# format 999 col applied_seq format 9999999 select thread#, max(sequence#) as applied_seq from v$archived_log where applied YES group by thread# order by thread#;邏輯說明主庫的v$thread給出每個線程當(dāng)前寫到哪備庫的v$archived_log里appliedYES的最大值給出應(yīng)用到哪。兩者相減就是缺口。多線程RAC 形態(tài)下必須按 thread 分別算只取全局最大值會漏掉某個線程掉隊的場景——這種場景在小庫上不常見在大庫上就是演練失敗的常見原因。參數(shù)說明appliedYES這個過濾條件是關(guān)鍵去掉它拿到的是“收到了多少”而不是“應(yīng)用了多少”這兩者在備庫開啟實時應(yīng)用時差別很大。如果你的庫用的是備庫實時應(yīng)用還可以補(bǔ)一條查v$standby_apply_progress但對缺口判斷來說上面兩條已經(jīng)夠用。**備庫日志SRL**是最容易被跳過的一條因為它不影響日常運行只影響切換-- sql/40_srl.sql兩邊分別跑比對組數(shù)與單組大小 col group# format 999 col mb format 9999 select group#, thread#, bytes/1024/1024 as mb, status from v$standby_log order by thread#, group#; select group#, thread#, bytes/1024/1024 as mb from v$log order by thread#, group#;判據(jù)是經(jīng)驗值備庫 SRL 的組數(shù)不少于主庫在線 redo 組數(shù) 每線程 1 組單組大小與主庫一致不能小于。組數(shù)不夠切換瞬間會因為無處寫日志而卡住大小不一致切換后可能出現(xiàn)頻繁切換log switch拖慢性能。這兩條都屬于“不改也沒事、一切換就死”的類型。參數(shù)一致性要挑真正影響切換的那幾個別把全部參數(shù)拉出來比對噪音太大-- sql/50_param.sql只比對與容災(zāi)強(qiáng)相關(guān)的參數(shù) col name format a32 col value format a48 select name, value from v$parameter where name in ( db_unique_name,log_archive_config,log_archive_dest_state_2, standby_file_management,protection_mode,archive_log_format, db_recovery_file_dest_size,remote_login_passwordfile ) order by name;這十個參數(shù)里log_archive_config少寫一個備庫名、standby_file_management是 MANUAL、remote_login_passwordfile不是 EXCLUSIVE任意一條都能讓切換直接失敗。db_recovery_file_dest_size放在這里是很多人的疑問——它影響的是歸檔空間不在切換時立刻報錯但會在切換后補(bǔ)日志階段把空間撐爆屬于第二波翻車。提示參數(shù)比對一定要在主備兩邊都跑同一條 SQL 再 diff不要拿主庫的輸出去和心里記著的備庫配置比記憶比腳本更容易錯。4.2 閾值不是拍腦袋用歷史延遲分布定紅線THRESH_APPLY_LAG120這個數(shù)字從哪來很多人是從別人的腳本里抄的。抄來的數(shù)字有兩個問題一是和自己的業(yè)務(wù)量不匹配二是沒人知道為什么是 120。我的做法是先裸跑兩周只采集不判定把每次的傳輸延遲、應(yīng)用延遲記下來然后看分布分位傳輸延遲應(yīng)用延遲用途p502 秒15 秒常態(tài)參考不必告警p9540 秒90 秒WARN 線留出批量作業(yè)的余量p9975 秒150 秒FAIL 線超過說明真的出問題了規(guī)律很樸素WARN 線設(shè)在 p95 附近FAIL 線設(shè)在 p99 或 p95 的兩倍。這樣日常波動不會天天報警真出事的時候一定越線。設(shè)置完還要回頭看一次——如果一周內(nèi) WARN 觸發(fā)了十幾次說明線畫低了或者這條鏈路的容量本來就不夠該擴(kuò)容而不是調(diào)閾值。批量作業(yè)窗口要單獨對待。夜間跑大批量的時候apply lag 從 15 秒沖到 300 秒是正常的如果這時 FAIL 了你會收到一堆無效告警然后開始忽略告警——這是運維里最危險的狀態(tài)。解決辦法是給批量窗口單獨一組閾值按時間切換配置而不是把全局閾值放寬到 300 秒那樣等于白天也不告警了。4.3 把文本輸出收斂成一張就緒度表采集出來是一堆文本人看得懂、腳本看不懂。中間加一層折算把關(guān)鍵指標(biāo)壓成keyvalue再交給一個小腳本算分# 采集腳本末尾把關(guān)鍵指標(biāo)壓成一行一個鍵值供折算腳本消費 { echo archive_gap$ARCHIVE_GAP echo apply_lag$APPLY_LAG echo transport_lag$TRANSPORT_LAG echo dest_status$DEST_STATUS echo srl_ok$SRL_OK echo param_diff$PARAM_DIFF } $OUT/metrics.kv#!/usr/bin/env python3 # bin/score.py —— 把 metrics.kv 折算成就緒度分?jǐn)?shù)與結(jié)論 import sys, os WEIGHTS {archive_gap: 25, param_diff: 20, apply_lag: 20, transport_lag: 15, dest_status: 10, srl_ok: 10} DENY set(os.environ.get(DENY_ITEMS, ).split(,)) def load(path): kv {} with open(path, encodingutf-8) as f: for line in f: line line.strip() if not line or not in line: continue k, v line.split(, 1) kv[k.strip()] v.strip() return kv def judge(key, raw, kv): # 數(shù)值型指標(biāo)與閾值比較非數(shù)值型按 1/0 判定 if key archive_gap: return PASS if int(raw) 0 else (WARN if int(raw) 3 else FAIL) if key in (apply_lag, transport_lag): warn float(os.environ.get(THRESH_ key.upper(), 120)) v float(raw) return PASS if v warn else (WARN if v warn * 2 else FAIL) return PASS if raw in (1, VALID, TRUE) else FAIL def main(path): kv load(path) score, denies, rows 0.0, [], [] for key, w in WEIGHTS.items(): if key not in kv: rows.append((key, MISSING, 0)) continue res judge(key, kv[key], kv) got w if res PASS else (w * 0.5 if res WARN else 0) score got if res FAIL and key in DENY: denies.append(key) rows.append((key, res, got)) for k, r, g in rows: print(f{k:16s} {r:8s} {g:5.1f}) verdict NOT READY if denies else (READY if score 90 else RISKY) print(f\nscore{score:.1f} verdict{verdict} deny{,.join(denies) or -}) if __name__ __main__: main(sys.argv[1])邏輯上分三層。WEIGHTS是第 2 章那張表的代碼化judge是個小狀態(tài)機(jī)把原始數(shù)值翻譯成 PASS/WARN/FAIL注意 WARN 的判定用的是“閾值的兩倍”這樣只改一個配置就能同時控制兩檔最后主線按權(quán)重累加denies收集否決項。指標(biāo)缺失MISSING單獨記一檔而不是直接 FAIL因為缺失往往是采集失敗不是環(huán)境壞混在一起會誤導(dǎo)排查方向。參數(shù)說明DENY_ITEMS從環(huán)境變量讀是為了讓同一份腳本能跑“演練前嚴(yán)格模式”和“日常寬松模式”兩套口徑不用改代碼。閾值同樣從環(huán)境變量兜底o(hù)s.environ.get(..., 120)保證腳本單獨運行也不崩。跑起來驗證一下# 用一次真實采集結(jié)果折算先看分?jǐn)?shù)再看否決項 cd /opt/dgcheck/3.6 DENY_ITEMSarchive_gap,srl_ok,param_diff python3 bin/score.py out/20240101_020000/metrics.kv輸出如果verdictNOT READY但score92.0說明分?jǐn)?shù)被某一兩個高分項撐著否決項里有 FAIL——這正是第 2 章說的“分?jǐn)?shù)管趨勢、否決項管決策”別被 92 分騙了。5. 排查記錄五個讓報告「全綠」卻切不過去的坑5.1 延遲顯示 0 秒但備庫落后兩小時現(xiàn)象報告里 apply lag 一直是 0 到 2 秒看起來健康真做切換時發(fā)現(xiàn)丟了大量數(shù)據(jù)業(yè)務(wù)對賬對不上。原因apply lag 的語義是“最近一條已應(yīng)用日志的應(yīng)用時間與當(dāng)前時間之差”它衡量的是“追平速度”不是“落后多少”。如果日志根本沒傳到備庫備庫無日志可應(yīng)用這個值反而會很小甚至為 0——這是最典型的假綠燈。解決把歸檔缺口序列號差值作為主判據(jù)延遲只作為輔判據(jù)。缺口不為 0 時無論延遲多好看都判 FAIL。這條一定要進(jìn)否決項名單。5.2 SRL 組數(shù)和主庫一樣多切換仍然卡住現(xiàn)象比對下來 SRL 組數(shù)“看起來夠”切換演練時仍然在 redo 寫入階段卡了幾十秒。原因組數(shù)夠但單組大小小于主庫的在線 redo切換后日志切換頻率暴增或者組數(shù)是照“主庫組數(shù)”配的沒有算上每線程多一組的余量。多線程環(huán)境下每個線程都需要獨立的 SRL 組共用一個組池也會卡。解決按“每線程主庫在線組數(shù) 1”配單組大小嚴(yán)格等于主庫 redo 大小字節(jié)數(shù)一致而不是四舍五入后的兆數(shù)一致。改完重跑 4.1 里那條 SRL SQL 確認(rèn)。5.3 巡檢賬號權(quán)限過高審計上翻車現(xiàn)象腳本跑得好好的某次安全審計里被指出巡檢使用了高權(quán)限賬號且口令明文放在配置文件里。原因為了省事直接用了最高權(quán)限賬號順手把口令寫進(jìn)env.conf文件權(quán)限還是 644。解決換專用只讀賬號只授查詢v$視圖所需的最小權(quán)限配置文件權(quán)限收到 640 并限定屬組口令改走外部認(rèn)證或憑據(jù)文件不進(jìn)版本庫。這條不是技術(shù)問題但會真的讓項目停掉早改比晚改省事。5.4 輸出目錄把磁盤撐滿反過來拖垮歸檔現(xiàn)象某天主庫歸檔區(qū)寫滿業(yè)務(wù)掛起查下來是巡檢報告占了同一個文件系統(tǒng)。原因out/目錄沒做輪轉(zhuǎn)加上有人為了排查重復(fù)手動跑全量一年下來堆了上千個目錄。巡檢工具本身成了故障源這個坑我見過不止一次。解決輸出目錄和歸檔區(qū)物理隔離別放同一個掛載點加輪轉(zhuǎn)3.3 那條并給巡檢腳本本身加一個“單次輸出不超過 N 兆”的保護(hù)——如果超了說明采集范圍寫錯了應(yīng)該報錯而不是繼續(xù)寫。5.5 多租戶下 PDB 狀態(tài)沒納入檢查現(xiàn)象容器庫層面全綠切換后發(fā)現(xiàn)某個 PDB 處于 MOUNT 或者沒開讀寫。原因檢查項只查了容器級視圖沒有遍歷 PDB。多租戶環(huán)境里 PDB 的狀態(tài)是獨立管理的容器級看起來一切正常。解決在結(jié)構(gòu)層加一條遍歷 PDB 的查詢把每個 PDB 的打開模式和恢復(fù)狀態(tài)列出來任一 PDB 不是 READ WRITE 就判 WARN若你的業(yè)務(wù)依賴該 PDB 則升級為 FAIL。這條屬于“不查不知道、查了才發(fā)現(xiàn)”的類型建議第一次就補(bǔ)上。6. 把它釘進(jìn)演練流程基線對比與回歸的兩種做法跑通一次巡檢不算什么能讓它在半年后仍然是團(tuán)隊判斷切換時機(jī)的依據(jù)才算落地。我用兩種做法把它釘住定時留基線變更前后做 diff。定時巡檢我掛在業(yè)務(wù)低峰只跑全量并把結(jié)果目錄按“日期_類型”命名類型分daily和drill。daily每天一次用來攢趨勢數(shù)據(jù)drill只在演練和變更前跑用來做決策。兩者閾值可以不同daily用寬松口徑只看異常drill用嚴(yán)格口徑加全部否決項。這樣平時不會天天被報警吵真要切換的時候有一個不會說謊的口徑。# 低峰定時每日基線 目錄按類型分方便后面按類型做趨勢 30 2 * * * /opt/dgcheck/3.6/bin/run_all.sh -t daily \ /opt/dgcheck/3.6/out/cron.log 21 # 演練前手工嚴(yán)格口徑帶完整否決項 # /opt/dgcheck/3.6/bin/run_all.sh -t drill第二種做法更重要變更前后做 diff而不是看單次分?jǐn)?shù)。因為分?jǐn)?shù)會騙人——加了個索引、換了批處理時間分?jǐn)?shù)可能從 88 漲到 93但某項具體指標(biāo)其實是惡化的只是被其他項蓋過去了。所以我每次都把metrics.kv和上一次 drill 的做逐鍵對比# 變更前后逐鍵 diff只關(guān)心變化方向和幅度 diff (sort out/20240101_drill/metrics.kv) \ (sort out/20240201_drill/metrics.kv) | grep -E ^[]輸出里是變更后是變更前。如果archive_gap從 0 變成 1哪怕分?jǐn)?shù)還在 90 以上也要停下來查——缺口從 0 到 1 往往意味著某個歸檔目的地開始間歇性失敗這種早期信號只有 diff 抓得到。還有一個我踩過的細(xì)節(jié)基線要跟著版本走。升級到 3.6 之后新增了檢查項舊基線里沒有這些鍵diff 出來一堆看著像惡化其實是新增。所以升級后第一件事是重跑一次 drill 生成新基線并把舊基線的metrics.kv單獨歸檔不要混在同一個目錄里比。我自己的習(xí)慣是每次演練前打印一行結(jié)論貼在工單里score / verdict / deny 列表 / 與上次 drill 的差異項。四個字段誰看都清楚也逼著自己別只看總分。這套東西的價值不在腳本多聰明在于它把“我覺得可以切”變成“這份報告說可以切而且和上次比沒變差”——前者靠人后者能交接。希望幫到你。本文還有配套的精品資源點擊獲取