Oracle Data Guard 切换前就绪度检查与基线对比-北京尧图网络

简介dgreadiness_v3.6.zip 面向在 Windows 10 上使用 VMware Workstation 运行 Ubuntu 等虚拟机的开发与运维人员针对关闭 Hyper-V 后仍提示 VMware 与 Device/Credential Guard 不兼容、虚拟机无法启动的问题提供基于 Windows Defender Device Guard 与 Credential Guard 硬件就绪工具的禁用方案。压缩包共 6 个文件约 32KB包含 PowerShell 工具脚本、p7b 策略文件、xml 配置模板和 txt 说明文档分别用于执行禁用配置、承载策略设置、提供审计/强制模式模板及使用说明体量轻便、结构明确。已有 3189 人学习下载说明该问题在 Win10 虚拟机场景中较常见。读者可借助其中的脚本与策略模板快速完成 Credential Guard 关闭减少手动修改组策略和注册表的试错成本也可据说明文档理解各配置项作用为同类兼容性排错提供参考。1. dgreadiness_v3.6.zip 不是安装包是切换前的一张体检单dgreadiness_v3.6.zip 这个名字本身就说明了它的形态一个压缩包、带版本号、没有安装向导解开来是一堆 SQL 和 shell。它的作用不是部署容灾而是在你已经有一套主备库主库一个或多个备库之后回答一个很具体的问题——现在这一刻我敢不敢做切换演练很多团队的做法是切之前拉个会几个人分别敲几条命令看看凭感觉拍板这个包要做的事是把这些零散判断固化成一份可重复、可对比、可交给别人的报告。它适合两类人一类是要定期做容灾演练的 DBA另一类是接手了一套没人维护的备库、想先摸清底细的运维。读完你能自己解包、配连接、改检查项、定阈值也知道哪些绿灯其实是假的。2. 就绪度先立标准六类检查项和它们的权重怎么定打开一个 readiness 包最忌讳的动作是直接bash run.sh然后盯着输出里红色的那几行看。红色代表什么、多红才算不能切、这次红下次绿是环境变了还是脚本抽风——这些问题在脚本里没有答案得你自己先定。所以第一章不做操作先把“ready”这个词拆成可判定的指标。2.1 传输层、应用层、结构层就绪度的三个观察面我把所有检查项归到三个观察面这个分法决定了后面报告的排版也决定了排错时的查找顺序。传输层看的是日志能不能从主库顺利落到备库归档目的地状态是不是 VALID、有没有 ERROR 文本、传输延迟多少、归档目的地所在文件系统的剩余空间、网络往返时延和带宽是否够峰值 redo 量。这一层出问题表现是备库长时间收不到新日志但主库业务一切正常最容易被忽略。应用层看的是日志到了之后有没有被真正应用MRP 进程在不在、状态是 APPLYING_LOG 还是 WAITING_FOR_LOG、应用延迟多少、备库已应用的最大序列号和主库当前序列号差多少、有没有归档缺口GAP。这一层最容易出“假绿灯”后面避坑那章会专门讲。结构层看的是两边长得像不像db_unique_name 和 log_archive_config 是否互认、standby_file_management 是否 AUTO、保护模式和 redo 传输是 SYNC 还是 ASYNC、standby redo log 的组数和单组大小、临时文件和数据文件路径、密码文件、以及多租户下每个 PDB 的状态。结构层的问题平时完全不疼一切换就卡死是典型的“平时不查、演练翻车”。三个面里传输层和应用层是动态指标数值会随业务波动结构层是静态指标除非有人改配置否则长期不变。这个差异直接影响采集频率动态指标要频繁采、看趋势静态指标一次采完存成基线就行不必每次全量跑。提示如果包里的检查项命名和上面不一样不要急着改脚本先按这三个面把现有项归类缺哪一类再补比重写省事得多。2.2 权重怎么定按「切换后多久能对外服务」倒推权重不是技术参数是业务参数。我的做法是问一句话这一项不达标切换后要多花多久才能对外服务答案越长权重越高。按这个口径归档缺口和结构层错配是最贵的——缺口意味着要补日志甚至重建结构错配意味着切换根本起不来这两类给高权重传输延迟和应用延迟影响的是切换瞬间丢多少数据、追平要多久中等权重目的地状态、SRL 配置这类属于“不达标立刻知道、修起来也快”的低权重。检查项观察面权重不达标后果归档序列缺口应用层25需补日志或重建备库参数与结构一致性结构层20切换可能直接失败应用延迟应用层20切换后追平日志耗时长传输延迟传输层15数据丢失窗口变大目的地状态与错误文本传输层10日志传输中断SRL 组数与大小结构层10切换时日志写不下这张表不需要照抄权重之和凑够 100 就行关键是每一项的权重你能对着业务说清楚理由。说不清理由的项要么删掉要么降权别放在那里制造噪音。2.3 判定口径要先写死否则报告没法比较分数之外还要有档位否则你只知道“78 分”不知道“78 分能不能切”。我一般分三档PASS、WARN、FAIL。PASS 拿满分WARN 拿一半FAIL 拿零分。但光有分数不够——结构层错配这种项哪怕总分 95 也不能切所以还要引入“否决项”概念归档缺口、SRL 配置、参数一致性这三项只要有一个 FAIL无论总分多少都判定为 NOT READY。这样做的好处是报告有两层结论分数用来横向比较这次 92、上次 88是在变好还是变差否决项用来纵向决策能不能现在切。只给分数人会拿分数当挡箭牌只给否决项又看不出趋势。两者都要。还有一条容易被忽略口径要写进配置文件不要写死在脚本里。阈值、权重、否决项名单都放conf/env.conf这样半年后别人接手改一个数字就能适配另一套库不用读懂 SQL。3. 解包与首轮巡检三条命令跑出第一份报告标准立完动手。这一章的目标不是跑出完美报告是在 20 分钟内跑出第一份“能看”的报告哪怕里面一半是 FAIL——先有基线再谈优化。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 # 看一眼结构确认入口脚本和 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 # 脚本给执行权限但不要给全局可写 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这段的关键点在三处。-d指定目标目录避免解压出来的文件平铺在当前目录把家目录搞乱。find -maxdepth 2是先摸清结构再决定怎么调因为不同打包习惯里入口脚本可能在bin/也可能在根目录ls一次就知道比自己猜快。chmod 640给配置文件是因为里面通常有连接串和口令权限放开等于把库的钥匙挂在墙上。专用运行账号也是必要的一步。我一般建一个只读账号dbcheck跑巡检让它属于dba组以便读v$视图但不给它sysdba。巡检脚本只需要看状态不需要改任何东西——一个能改东西的巡检脚本某天就会改错东西这是血泪经验。注意如果包里带.sh之外的可执行文件比如编译好的采集二进制先用file看一眼架构和依赖别在 x86 机器上跑 arm 的产物报错信息会误导你以为连不上库。3.2 连接配置与最小巡检命令配置文件只放连接信息和阈值不放任何逻辑。常见做法是conf/env.conf这种以 shell 变量形式被source进来的文件# conf/env.conf —— 只放连接与阈值逻辑一律进脚本 PRIMARY_TNSdg_primary # 主库连接串走 tnsnames 或等价命名 STANDBY_TNSdg_standby # 备库连接串 RUN_USERdbcheck # 巡检专用账号非 sysdba THRESH_TRANSPORT_LAG60 # 传输延迟告警线单位秒 THRESH_APPLY_LAG120 # 应用延迟告警线单位秒 THRESH_ARCHIVE_GAP0 # 允许的序列缺口通常为 0 THRESH_FRA_PCT85 # 归档区使用率告警线百分比 DENY_ITEMSarchive_gap,srl_config,param_diff # 否决项名单四个阈值里前三个是硬指标最后一个归档区使用率是很多人不做但极容易翻车的项——归档区满的那一刻主库会挂起备库也跟着停属于“平时不查、爆起来要命”的类型。DENY_ITEMS是把第 2 章的口径落地的字段后面折算报告时直接读这个变量。配好之后首轮就跑最小集合一个主库侧、一个备库侧别一上来跑全套不然输出里几百行你不知道哪行是关键的。#!/usr/bin/env bash # bin/first_run.sh —— 首轮最小巡检只采集传输与应用两个面 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 # 主库归档目的地状态当前最大序列 sqlplus -S $RUN_USER$PRIMARY_TNS $BASE/sql/10_primary.sql \ $OUT/primary.txt 21 # 备库应用进程状态已应用序列 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这是有意的首轮巡检最怕的是某项失败就整体退出导致你只看到第一个问题、看不到后面的问题。所以让每个采集动作各自失败、各自留痕最后统一 grep 一遍错误关键字。-S是静默模式去掉客户端横幅和提示符输出更干净后面好解析。时间戳精确到秒是为了同一天多次演练时不覆盖文件。grep -iE error|ORA-|SP2-这行是一个廉价但有效的兜底。数据库客户端的报错文本格式很好认宽泛匹配一下就能把“没连上库”和“连上了但查询出错”区分开——这两种情况后面的处理完全不一样。3.3 输出目录与失败兜底out/目录要有轮转策略别等它撑满。一次全量巡检的输出不大但每天跑、跑半年加上有人手动重跑很容易堆到几百个目录。我一般保留最近 30 次全量所有“变更前后”的对比目录其余删除# 只保留最近 30 个时间戳目录其余清理命名规则必须严格按时间戳 cd /opt/dgcheck/3.6/out || exit 0 ls -1d 2*/ | sort | head -n -30 | xargs -r rm -rf前提是目录名严格是YYYYMMDD_HHMMSSsort的字典序才等于时间序。如果包自带的输出目录用了别的命名比如带主机名就先改命名规则再用这条命令否则head -n -30删掉的可能是昨天刚跑的基线这种翻车比不清理更糟。失败兜底还有一个细节退出码。巡检脚本的退出码要能被上层调度感知——0 表示全 PASS1 表示有 WARN2 表示有 FAIL 或否决项。这样挂到定时任务或流水线上不用解析文本就知道结果。很多包默认只 echo 不 return接进自动化就得自己补这几行。4. 改 SQL 与定阈值把通用检查项调成你库的形状一份通用脚本跑在你自己的库上一定会有一半检查项“看起来对但不准”。这不是脚本的问题是每套库的形态差异太大有的单实例、有的多租户有的保护模式要求零丢失、有的能接受几分钟延迟有的 redo 峰值每秒几十兆、有的几百 K。所以第三章的核心动作是改改 SQL 的取数口径、改阈值的红线位置。4.1 三类必改的 SQL序列缺口、备库日志、参数一致性序列缺口是最该改的一条。很多脚本只查应用延迟但延迟是个瞬时值——刚刚应用完一批日志延迟会显示接近 0哪怕中间其实缺了一段日志没传过来。真正的缺口要看序列号连续性-- sql/30_gap.sql主库侧取每个线程的当前序列 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备库侧取每个线程已应用的序列 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给出每个线程当前写到哪备库的v$archived_log里appliedYES的最大值给出应用到哪。两者相减就是缺口。多线程RAC 形态下必须按 thread 分别算只取全局最大值会漏掉某个线程掉队的场景——这种场景在小库上不常见在大库上就是演练失败的常见原因。参数说明appliedYES这个过滤条件是关键去掉它拿到的是“收到了多少”而不是“应用了多少”这两者在备库开启实时应用时差别很大。如果你的库用的是备库实时应用还可以补一条查v$standby_apply_progress但对缺口判断来说上面两条已经够用。**备库日志SRL**是最容易被跳过的一条因为它不影响日常运行只影响切换-- sql/40_srl.sql两边分别跑比对组数与单组大小 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#;判据是经验值备库 SRL 的组数不少于主库在线 redo 组数每线程 1 组单组大小与主库一致不能小于。组数不够切换瞬间会因为无处写日志而卡住大小不一致切换后可能出现频繁切换log switch拖慢性能。这两条都属于“不改也没事、一切换就死”的类型。参数一致性要挑真正影响切换的那几个别把全部参数拉出来比对噪音太大-- sql/50_param.sql只比对与容灾强相关的参数 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;这十个参数里log_archive_config少写一个备库名、standby_file_management是 MANUAL、remote_login_passwordfile不是 EXCLUSIVE任意一条都能让切换直接失败。db_recovery_file_dest_size放在这里是很多人的疑问——它影响的是归档空间不在切换时立刻报错但会在切换后补日志阶段把空间撑爆属于第二波翻车。提示参数比对一定要在主备两边都跑同一条 SQL 再 diff不要拿主库的输出去和心里记着的备库配置比记忆比脚本更容易错。4.2 阈值不是拍脑袋用历史延迟分布定红线THRESH_APPLY_LAG120这个数字从哪来很多人是从别人的脚本里抄的。抄来的数字有两个问题一是和自己的业务量不匹配二是没人知道为什么是 120。我的做法是先裸跑两周只采集不判定把每次的传输延迟、应用延迟记下来然后看分布分位传输延迟应用延迟用途p502 秒15 秒常态参考不必告警p9540 秒90 秒WARN 线留出批量作业的余量p9975 秒150 秒FAIL 线超过说明真的出问题了规律很朴素WARN 线设在 p95 附近FAIL 线设在 p99 或 p95 的两倍。这样日常波动不会天天报警真出事的时候一定越线。设置完还要回头看一次——如果一周内 WARN 触发了十几次说明线画低了或者这条链路的容量本来就不够该扩容而不是调阈值。批量作业窗口要单独对待。夜间跑大批量的时候apply lag 从 15 秒冲到 300 秒是正常的如果这时 FAIL 了你会收到一堆无效告警然后开始忽略告警——这是运维里最危险的状态。解决办法是给批量窗口单独一组阈值按时间切换配置而不是把全局阈值放宽到 300 秒那样等于白天也不告警了。4.3 把文本输出收敛成一张就绪度表采集出来是一堆文本人看得懂、脚本看不懂。中间加一层折算把关键指标压成keyvalue再交给一个小脚本算分# 采集脚本末尾把关键指标压成一行一个键值供折算脚本消费 { 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 折算成就绪度分数与结论 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): # 数值型指标与阈值比较非数值型按 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是个小状态机把原始数值翻译成 PASS/WARN/FAIL注意 WARN 的判定用的是“阈值的两倍”这样只改一个配置就能同时控制两档最后主线按权重累加denies收集否决项。指标缺失MISSING单独记一档而不是直接 FAIL因为缺失往往是采集失败不是环境坏混在一起会误导排查方向。参数说明DENY_ITEMS从环境变量读是为了让同一份脚本能跑“演练前严格模式”和“日常宽松模式”两套口径不用改代码。阈值同样从环境变量兜底os.environ.get(..., 120)保证脚本单独运行也不崩。跑起来验证一下# 用一次真实采集结果折算先看分数再看否决项 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说明分数被某一两个高分项撑着否决项里有 FAIL——这正是第 2 章说的“分数管趋势、否决项管决策”别被 92 分骗了。5. 排查记录五个让报告「全绿」却切不过去的坑5.1 延迟显示 0 秒但备库落后两小时现象报告里 apply lag 一直是 0 到 2 秒看起来健康真做切换时发现丢了大量数据业务对账对不上。原因apply lag 的语义是“最近一条已应用日志的应用时间与当前时间之差”它衡量的是“追平速度”不是“落后多少”。如果日志根本没传到备库备库无日志可应用这个值反而会很小甚至为 0——这是最典型的假绿灯。解决把归档缺口序列号差值作为主判据延迟只作为辅判据。缺口不为 0 时无论延迟多好看都判 FAIL。这条一定要进否决项名单。5.2 SRL 组数和主库一样多切换仍然卡住现象比对下来 SRL 组数“看起来够”切换演练时仍然在 redo 写入阶段卡了几十秒。原因组数够但单组大小小于主库的在线 redo切换后日志切换频率暴增或者组数是照“主库组数”配的没有算上每线程多一组的余量。多线程环境下每个线程都需要独立的 SRL 组共用一个组池也会卡。解决按“每线程主库在线组数 1”配单组大小严格等于主库 redo 大小字节数一致而不是四舍五入后的兆数一致。改完重跑 4.1 里那条 SRL SQL 确认。5.3 巡检账号权限过高审计上翻车现象脚本跑得好好的某次安全审计里被指出巡检使用了高权限账号且口令明文放在配置文件里。原因为了省事直接用了最高权限账号顺手把口令写进env.conf文件权限还是 644。解决换专用只读账号只授查询v$视图所需的最小权限配置文件权限收到 640 并限定属组口令改走外部认证或凭据文件不进版本库。这条不是技术问题但会真的让项目停掉早改比晚改省事。5.4 输出目录把磁盘撑满反过来拖垮归档现象某天主库归档区写满业务挂起查下来是巡检报告占了同一个文件系统。原因out/目录没做轮转加上有人为了排查重复手动跑全量一年下来堆了上千个目录。巡检工具本身成了故障源这个坑我见过不止一次。解决输出目录和归档区物理隔离别放同一个挂载点加轮转3.3 那条并给巡检脚本本身加一个“单次输出不超过 N 兆”的保护——如果超了说明采集范围写错了应该报错而不是继续写。5.5 多租户下 PDB 状态没纳入检查现象容器库层面全绿切换后发现某个 PDB 处于 MOUNT 或者没开读写。原因检查项只查了容器级视图没有遍历 PDB。多租户环境里 PDB 的状态是独立管理的容器级看起来一切正常。解决在结构层加一条遍历 PDB 的查询把每个 PDB 的打开模式和恢复状态列出来任一 PDB 不是 READ WRITE 就判 WARN若你的业务依赖该 PDB 则升级为 FAIL。这条属于“不查不知道、查了才发现”的类型建议第一次就补上。6. 把它钉进演练流程基线对比与回归的两种做法跑通一次巡检不算什么能让它在半年后仍然是团队判断切换时机的依据才算落地。我用两种做法把它钉住定时留基线变更前后做 diff。定时巡检我挂在业务低峰只跑全量并把结果目录按“日期_类型”命名类型分daily和drill。daily每天一次用来攒趋势数据drill只在演练和变更前跑用来做决策。两者阈值可以不同daily用宽松口径只看异常drill用严格口径加全部否决项。这样平时不会天天被报警吵真要切换的时候有一个不会说谎的口径。# 低峰定时每日基线目录按类型分方便后面按类型做趋势 30 2 * * * /opt/dgcheck/3.6/bin/run_all.sh -t daily \ /opt/dgcheck/3.6/out/cron.log 21 # 演练前手工严格口径带完整否决项 # /opt/dgcheck/3.6/bin/run_all.sh -t drill第二种做法更重要变更前后做 diff而不是看单次分数。因为分数会骗人——加了个索引、换了批处理时间分数可能从 88 涨到 93但某项具体指标其实是恶化的只是被其他项盖过去了。所以我每次都把metrics.kv和上一次 drill 的做逐键对比# 变更前后逐键 diff只关心变化方向和幅度 diff (sort out/20240101_drill/metrics.kv) \ (sort out/20240201_drill/metrics.kv) | grep -E ^[]输出里是变更后是变更前。如果archive_gap从 0 变成 1哪怕分数还在 90 以上也要停下来查——缺口从 0 到 1 往往意味着某个归档目的地开始间歇性失败这种早期信号只有 diff 抓得到。还有一个我踩过的细节基线要跟着版本走。升级到 3.6 之后新增了检查项旧基线里没有这些键diff 出来一堆看着像恶化其实是新增。所以升级后第一件事是重跑一次 drill 生成新基线并把旧基线的metrics.kv单独归档不要混在同一个目录里比。我自己的习惯是每次演练前打印一行结论贴在工单里score / verdict / deny 列表 / 与上次 drill 的差异项。四个字段谁看都清楚也逼着自己别只看总分。这套东西的价值不在脚本多聪明在于它把“我觉得可以切”变成“这份报告说可以切而且和上次比没变差”——前者靠人后者能交接。希望帮到你。本文还有配套的精品资源点击获取

Oracle Data Guard 切换前就绪度检查与基线对比

相关推荐

云ERP WebAPI接口对接：鉴权、单据保存与查询字段映射

国产x86集显Win10驱动：INF安装、pnputil回滚与验收

C#电子秤数据接口中间件：多型号SDK兼容与串口粘包解析

更多资讯

DSP2812读写EEPROM驱动详解：基于AT24C的I2C实现与掉电保存

Indy 10.6.3.3：Delphi 12 网络组件安装与 HTTPS 避坑

Java面向对象实验代码全解析：从类到异常处理

VS2010 下 CefSharp WinForms 嵌入与 JS 互调

C语言迷宫游戏：数据结构综合实践与DFS/BFS算法手写实现

Python面试八股文高频考点与答题模板：生成器、GIL、深浅拷贝全解析

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？