简介这是一份面向数据库管理员与运维工程师的Oracle 11.2.0.1补丁安装操作文档集中解决企业级数据库环境中补丁包下载、验证、安装与核对的全流程问题适合中高级运维人员作为日常维护操作参考。文档覆盖补丁安装各关键环节安装前需检查实例状态并完全关闭数据库完成数据文件、控制文件等完整备份后再下载与解压补丁包安装时需将OPatch解压到安装目录设置ORACLE_HOME环境变量进入OPATCH目录执行opatch apply并提醒数字补丁包须由小到大逐个安装看到succeed方为完成。文档还给出了异常情况下的常用排错命令包括opatch lsinventory查看已装补丁、opatch rollback回滚指定补丁、opatch prereq检查前置条件等同时强调补丁完成后重启服务器并验证Oracle服务自动启动压缩包保留备用、临时目录可清理。资源包为单个doc文档大小942KB文字说明与命令行示例配合清晰目前已有130人浏览学习适合需要规范掌握Oracle打补丁流程或进行维护复盘的人员。1. 跑了十一年没动过的 11.2.0.1安全扫描一来就得打补丁一套跑了十一年没动过的 Oracle 11.2.0.1 生产库平时没人敢碰等保扫描报告一出安全那边把 CVE 清单往你桌上一拍打补丁就从“有空再说”变成了“本周必须做完”。Oracle 11.2.0.1 数据库打补丁不是下载一个安装包双击执行就完事它是一条从补丁选型、OPatch 升级、二进制替换、数据字典脚本到验证回滚的完整链路任何一步跳过轻则补丁没生效重则监听起不来、存储过程成片失效。这份技术笔记适合要接手 11.2.0.1 存量库的人也适合被安全整改追着跑、需要给老库做季度补丁的一线 DBA照着下面的顺序做能少走一半弯路。2. 打补丁前的三件套补丁选型、OPatch 升级与一致性备份2.1 先分清 PSU、SPU、OJVM 和常规 Patch选型错了后面全白忙11.2.0.1 是 11gR2 最早发布的版本Oracle 对它的补丁策略和后期 11.2.0.4 不一样。在 2015 年前后11.2.0.1 的 PSUPatch Set Update基本冻结之后再出的季度安全补丁多以 SPU 形式发布。也就是说你手里如果还压着几年前的 PSU 包别直接拿去打先去确认这个补丁是否适用于当前时间点的库否则打了等于没打。很多老 DBA 一听到“打补丁”就条件反射找 PSU这是 11.2.0.1 场景下最常见的选型误区。选型前先看补丁类型。PSU 是季度累积补丁既修安全漏洞也带一批高危稳定性修复改动面大SPU 是 Security Patch Update只针对安全漏洞对业务影响面相对小OJVM 补丁专门修 Oracle JVM 组件的问题和 Java 存储过程强相关one-off patch 则是针对某一个具体 Bug 的临时补丁。我一般这样选如果安全整改有时间窗口优先打 SPU 加对应的 OJVM 补丁如果库里刚好踩中某个已知 Bug再考虑叠加 one-off。不要一上来拉一个最新最大的补丁包堆叠越多冲突检查和回滚成本越高。补丁类型包含内容典型适用场景是否要执行 SQL 脚本PSU安全修复 高影响稳定性修复距离上次补丁时间较长的老库是catbundle.sqlSPU仅安全修复等保整改、安全扫描驱动是catcpu.sqlOJVM PSUJava 组件安全与稳定性修复存在大量 Java 存储过程视 README 而定one-off单个 Bug 修复命中某个具体 Bug通常是二进制替换另一种常见想法是既然 11.2.0.1 这么老不如直接下载一个新版 11g 重装。干过数据库迁移的人都知道生产库的 schema、权限、同义词、存储过程、统计信息和应用兼容性不是你一个周末能搬完的“重装绕开打补丁”在大多数企业内部根本不可行所以补丁这条路必须走通。补丁从哪里找、选哪个编号以 MOS 补丁中心里按产品名 Oracle Database、Release 11.2.0.1.0 过滤出来的结果为准常用引用文档 161818.1 里维护着 11.2.0.1 的季度补丁对照表下载前先把平台、位数、PSU/SPU 类型核对三遍。2.2 OPatch 为什么要单独升级11.2.0.1 自带的版本多数不满足要求11.2.0.1 自带的 OPatch 工具版本通常很旧很多直接停在 11.1.0.6 附近而新发布的补丁包对 OPatch 有最低版本要求。OPatch 是打补丁用的手术刀不是补丁本身它版本不够你下载的补丁再全也跑不起来。常见的报错是 opatch apply 一执行就提示“OPatch version must be greater than xx”然后中止。所以正规操作顺序里第一步永远是先看当前 OPatch 版本再对照补丁 README 里注明的最低版本要求。OPatch 工具包的下载名一般是 p6880880_112000_对应平台和架构的 zip 包这是 Oracle 官方工具包不是某个业务补丁。下载后解压覆盖到 ORACLE_HOME 下的 OPatch 目录但覆盖前必须把原来的 OPatch 完整备份。还有一个非常容易翻车的点新版 OPatch 运行时需要 JRE 1.6 以上而 11.2.0.1 的 ORACLE_HOME 自带 JDK 基本是 1.5直接拿来跑会报 Java 版本错误。我一般不会去动 ORACLE_HOME 自带的 jdk 目录而是把新版 OPatch 解压完成后用软链接把 ORACLE_HOME/jdk 指向系统里已装好的新 JDK然后在 opatch 脚本头部确认 JAVA_LOCATION 是否正确。# 1. 先确认当前 OPatch 与 JDK 版本 $ORACLE_HOME/opatch/opatch version $ORACLE_HOME/jdk/bin/java -version # 2. 备份旧 OPatch 与 JDK 软链 mv $ORACLE_HOME/opatch $ORACLE_HOME/opatch.bak.$(date %Y%m%d) mv $ORACLE_HOME/jdk $ORACLE_HOME/jdk.bak.$(date %Y%m%d) # 3. 解压新 OPatch 工具包并替换 JDK 软链 unzip -q p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME ln -s /usr/java/jdk1.7.0_80 $ORACLE_HOME/jdk # 4. 验证升级结果 $ORACLE_HOME/opatch/opatch version $ORACLE_HOME/jdk/bin/java -version第一段命令先跑 opatch version是为了在动手术刀之前把基线记录下来。第二步的备份用日期后缀方便出问题后快速回退到出厂状态。第三步把 OPatch 解压进 ORACLE_HOME再改 JDK 软链注意这里不是复制 JDK 进去而是软链这样系统 JDK 升级不用再动 Oracle 目录。最后一步验证必须看到 opatch version 的输出变成新版本号同时 java -version 显示 1.6 以上两个条件同时满足才算 OPatch 升级成功。如果只换了 OPatch 没换 JDK会出现 opatch 脚本能运行但内部报 Java 版本过低只换 JDK 不换 OPatch则补丁前置检查照样不通过。2.3 备份与基线检查动 home 之前先留好后路打补丁的本质是替换 ORACLE_HOME 下的二进制文件、共享库再执行脚本改写数据字典。二进制替换后想回退靠的是补丁自带的 rollback 机制数据字典改写后想回退靠的只有备份。所以我的备份顺序是先 RMAN 全备再备份 spfile再打包 ORACLE_HOME最后记录打补丁前的 inventory 状态。RMAN 备份要在数据库 open 状态下完成必须包含归档日志否则后面做时间点恢复时缺日志会卡住。# 数据库全备包含数据文件、控制文件、spfile、归档日志 rman target / EOF backup database plus archivelog; backup current controlfile; backup spfile; EOF # 打包 ORACLE_HOME排除数据文件目录与归档目录 tar -czf /u02/backup/ora_home_before_patch_$(date %Y%m%d).tar.gz \ --exclude/u01/app/oracle/oradata \ --exclude/u01/app/oracle/flash_recovery_area \ /u01/app/oracle/product/11.2.0/dbhome_1 # 记录打补丁前的补丁清单 $ORACLE_HOME/opatch/opatch lsinventory -all /u02/backup/before_patch_lsinventory_$(date %Y%m%d).log备份对象操作验证方式数据库RMAN 全备 归档list backup; 确认完成时间spfileRMAN backup spfile备份片存在且大小合理ORACLE_HOMEtar 打包gzip -t 校验包完整性inventory 基线opatch lsinventory -all 落盘日志文件能打开且内容完整这一步常常被赶进度的人跳过尤其是 tar ORACLE_HOME觉得补丁自带回滚就够了。但补丁回滚只覆盖它动过的文件inventory 被写坏、某个 lib 文件权限被改、依赖文件被补丁意外覆盖这些情况全靠 home 备份兜底。备份完成后再做一次 opatch lsinventory把输出存到安全位置这个文件就是打补丁前后对比的参照物。如果库里还有 Oracle 自带组件之外的自定义库建议连同对应的 SQL 脚本一起备份后面存储过程失效排查时能用上。3. 应用数据库补丁opatch apply 与 SQL 脚本的完整执行顺序3.1 环境确认与环境变量设置避免返回码 73OPatch 执行过程中有一个高频返回码 73普遍原因是环境变量不干净、inventory 找不到或补丁目录权限不对。解决这个问题的第一步是把 ORACLE_HOME、PATH、ORACLE_SID 一次性导出并且让 sqlplus 和 opatch 指向同一个 HOME。常见翻车原因是机器上装了两套 Oracle 客户端或开发库PATH 里先出现的那个 sqlplus 覆盖了你要打补丁的库opatch 读取的环境变量和实际要操作的 HOME 对不上前置检查必然失败。# 统一环境变量这是整个打补丁过程的基础 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$ORACLE_HOME/opatch:$PATH export ORACLE_SIDPROD # 确认当前用户与 inventory 归属 id oracle ls -ld $ORACLE_HOME/inventory ls -ld /opt/oracle/oraInventory # 查看监听当前状态打补丁期间建议关闭 lsnrctl status第二段命令先执行 id oracle确认当前确实是 Oracle 软件属主用户在 Linux 环境里如果图省事用 root 跑 opatch会在权限检查上卡住。ls 检查 inventory 目录的属主和权限如果属主不是 oracle后续 opatch apply 写 inventory 时会直接报错。监听状态这一步容易被忽略但实际上打补丁过程中会替换 libclntsh.so 等共享库监听进程如果在运行文件被替换后监听可能出现句柄异常所以我会在 apply 之前显式记录监听状态并在补丁执行窗口内关掉监听。这里还有一个实操细节如果这台机器上同时存在 11.2.0.1 和 12c 两套环境请反复确认当前 shell 里的 ORACLE_HOME 到底指向哪一套最好执行 which opatch 和 echo $ORACLE_HOME 各看一眼再继续。3.2 冲突检查与 opatch apply先跑 prereq 再动手拿到补丁包后不要急先在补丁目录里找到 README确认补丁编号和适用于 11.2.0.1 的平台。然后做冲突检查我习惯用 CheckConflictAgainstOHWithDetail 这个前置检查项它专门用来发现补丁和当前 ORACLE_HOME 里已装补丁之间的冲突。如果直接 apply冲突补丁会互相覆盖最后数据库启动时出现怪异行为日志里又看不出来。# 补丁目录解压后进入补丁号对应包名中的 P 字段 $ORACLE_HOME/opatch/opatch prereq CheckConflictAgainstOHWithDetail -ph /u02/patch/Pxxxxxxx # 确认无冲突后正式执行 apply-oh 显式指定 ORACLE_HOME $ORACLE_HOME/opatch/opatch apply -oh $ORACLE_HOME -ph /u02/patch/Pxxxxxxx-prereq 后面的 CheckConflictAgainstOHWithDetail 是一个内部检查项作用是把待打补丁与现有补丁清单做交叉比对oll 输出里如果有 warning 说明有冲突风险需要停下来评估不能带着 warning 硬上。-ph 指定补丁包所在目录目录名不要带中文和空格。apply 命令里的 -oh 参数显式指定 ORACLE_HOME防止 PATH 里混入其他版本导致打错目录。apply 执行过程中输出会滚动很多行核心只看两个位置阶段末尾的 Apply complete 字样以及日志文件里有没有 fail 或 ERROR 关键字。日志一般在 ORACLE_HOME/cfgtoollogs/opatch/ 目录下按日期命名。RAC 环境下还要额外注意每个节点的 ORACLE_HOME 都要各自执行一次 opatch不能只在其中一个节点打。规范做法是先打非当前实例所在节点让数据库服务优先跑在未打补丁的节点上等第一个节点打完并验证通过后再切到另一个节点重复相同操作。执行顺序千万别反否则会出现两个节点二进制版本不一致客户端连接报 ORA-00600 或监听无法正常注册。单实例环境相对简单但也需要确认 opatch apply 期间没有其他进程在调用 ORACLE_HOME 下的文件比如定时备份脚本。3.3 SQL 脚本catbundle.sql 怎么落到数据字典opatch apply 完成只意味着二进制文件替换完毕数据库的数据字典里记录的补丁状态还是旧的。这也是很多初次打补丁的人最容易卡住的地方明明 opatch lsinventory 能看到补丁但数据库查询 v$version 没变化业务告警依旧存在。原因就是数据库库侧脚本没执行。11.2.0.1 的 PSU 补丁落地脚本通常是 catbundle.sqlSPU 年代则可能是 catcpu.sql具体以补丁 README 为准不要在脚本名上自己猜。sqlplus / as sysdba SQL select * from dba_registry_history; SQL startup; SQL ?/rdbms/admin/catbundle.sql psu apply SQL shutdown immediate; SQL startup;第一句 dba_registry_history 是打补丁前的历史记录留着做前后对照。startup 把实例正常打开脚本执行不需要数据库处于 upgrade 模式。第三句里的问号会被 sqlplus 自动替换成 ORACLE_HOME 路径psu 参数表示应用 PSU 补丁主体apply 是动作。脚本执行时间跟数据库组件数量、dictionary 大小强相关有可能跑十几分钟到一两个小时期间不要开新会话去动业务表也不要中断当前会话。脚本执行到末尾会自动调用 utlrp 重编译失效对象能看到 invalid 对象数量的统计输出最后出现类似 Dictionary update complete 的行就说明成功。脚本跑完后 shutdown immediate 再 startup让改动正式生效。如果是 SPU 补丁脚本名可能就是 catcpu.sql参数结构类似。还有一点容易被忽略有些补丁包同时包含数据库补丁和客户端补丁数据库侧只执行数据库对应的那部分 SQL 脚本客户端不需要执行。脚本执行过程中如果看到 ORA-04063 报错先不用慌通常是同批次对象正在被重编译等脚本结束再查一遍状态。4. OJVM 补丁与失效对象存储过程和 Java 包最容易现形4.1 OJVM 为什么单独成包Java 存储过程在 11.2.0.1 里的特殊性Oracle 11.2.0.1 的数据库内核里集成了一套 JVM用来跑 Java 存储过程。很多业务系统把复杂报表逻辑、加密算法、文件解析逻辑写成了 Java source 或存储过程这套东西一旦失效业务调用直接报错而且不会告诉你“JVM 坏了”只会在 alert 日志里出现 ORA-00600 或 ORA-04063。OJVM 补丁在 Oracle 的补丁体系里经常单列因为 JVM 组件和数据库字典耦合度高单独出包可以把对业务 SQL 的冲击降到最小。如果安全扫描报告单独点了 Java 组件的 CVE我会优先只打 OJVM PSU而不是顺手拉一个完整 PSU。原因很简单OJVM 补丁的变更范围集中在 JVM 和与其绑定的 Java 类上对普通 SQL 执行计划影响小回滚也干净。如果手头既有 DB PSU 又有 OJVM PSU规范顺序是先打 DB 补丁并执行完对应 SQL 脚本再打 OJVM 补丁。反过来的话两个补丁都要改的公共文件可能互相覆盖opatch 冲突检查阶段就会报警。打 OJVM 补丁的命令套路和普通补丁一致同样走 opatch apply但 OJVM 补丁经常在 apply 完成后没有对应的 SQL 脚本或者仅要求执行 utlrp.sql。关键点在 README里面会明确写“是否需要执行 SQL 脚本”以及具体的脚本名。我见过有人打完 OJVM 补丁后没看 README直接跳过脚本执行结果 Java 存储过程全部失效应用半夜告警。另一个经验是业务里有大量 create or replace java source、loadjava 或者依赖 Java 的存储过程时OJVM 补丁是所有补丁类型里对业务影响最直接的一个验证阶段必须把这类对象列进回归范围。4.2 utlrp.sql 批量重编译怎么跑、跑完看什么数据库补丁和 OJVM 补丁都会造成一批对象失效这是正常现象因为二进制版本变化后数据字典里记录的依赖状态需要刷新。处理失效对象的官方工具就是 utlrp.sql它已经在 ORACLE_HOME/rdbms/admin 目录下自带。执行之前先记录当前失效对象数量跑完再对比避免把补丁前就存在的失效对象误判成补丁引起的。sqlplus / as sysdba SQL select count(*) from dba_objects where statusINVALID; SQL ?/rdbms/admin/utlrp.sql SQL select count(*) from dba_objects where statusINVALID; SQL select owner, object_type, count(*) 2 from dba_objects 3 where statusINVALID 4 group by owner, object_type;第一句查出来的数字就是基准值。utlrp.sql 会尝试并发编译所有失效对象输出里会有 “Recompilation completed” 或类似提示。跑完后再查一次 count正常情况下应该趋近于零或者回到补丁前的基线水平。第三句按 owner 和 object_type 分组如果还有残留失效对象能清楚看到是存储过程、函数、包还是 Java class。残留对象如果是自定义用户下的比如 APP 用户下的某一个包查看它依赖的对象是否也处于 invalid 状态常见原因是依赖的其他对象还没编译成功。udtlrp.sql 这个脚本不要连续反复执行跑两三次后如果失效对象数量不降反增说明不是简单的编译问题而是对象本身的源码引用了不存在的对象或者某个基础表结构被改掉了。这时候需要单独查看具体对象的 dba_dependencies定位到依赖链的断点。还有一类情况Java 存储过程在 OJVM 补丁后持续 invalid可能是 oracle 用户下缺少某些 Java 类权限补丁后权限被收紧这种情况光跑 utlrp 没用需要按 README 重新授权。5. 打补丁常见问题排查五个以现象开头的真实踩坑记录5.1 现象opatch apply 前置检查直接失败返回码 73打补丁时执行 opatch apply跑到前置检查阶段就停住日志里出现返回码 73整包补丁没有真正开始应用。第一次遇到时容易以为是补丁包损坏忙着重下载其实是环境问题。73 这个返回码在 OPatch 里普遍对应前置检查不通过最常见的三个原因ORACLE_HOME 环境变量没导出或指向了别的库inventory 目录权限不对oracle 用户无法写入补丁包解压后属主不是 oracle导致读取不到补丁文件。解决思路很直接先执行 echo $ORACLE_HOME 和 which opatch 确认当前环境再把 inventory 目录和补丁目录统一 chown 给 oracle 用户。我这里专门记录一个血泪经验用 root 命令下载和解压了补丁包后面全程用 oracle 用户操作结果 apply 时一直报权限相关错误查了半小时才发现补丁目录属主是 root。改成 chown -R oracle:oinstall 补丁目录后apply 一次通过。5.2 现象catbundle.sql 跑到一半不动会话卡在某个 DDL 上数据库补丁的 SQL 脚本执行过程中发现长时间没有输出查看 v$session 发现会话卡在一个 DDL 语句上后面的对象重编译全部排队。这个现象在补丁窗口内非常吓人尤其是在有业务会话没清干净的情况下。原因通常是 processes 参数到了上限或者有应用会话死死握着某个对象的锁脚本的 DDL 拿不到锁一直在等待。排查命令看 v$lock 和 v$session_wait找到阻塞脚本会话的源头。如果是会话锁确认是测试联调会话的话直接 kill如果是 processes 不够在另一个会话里临时调大 processes 参数再等脚本继续。需要特别强调的是不要因为看着不动就直接 CtrlC 杀掉 SQL*Plus 会话catbundle 中断后数据字典处于半更新状态后续再执行会出现“已应用一半”的脏状态恢复起来比等待更痛苦。我一般会先观察会话等待事件等十分钟确认是死锁还是单纯慢再决定处理动作。5.3 现象补丁打完后 oracle 监听服务无法启动opatch apply 和 SQL 脚本都执行成功数据库能正常启动但 lsnrctl start 报错监听进程起不来客户端全部连不上。遇到这个现象时先别怀疑监听配置因为打补丁过程替换了 ORACLE_HOME/bin 下的多个可执行文件如果之前用 root 执行过解压或移动文件属主会变成 rootoracle 用户启动监听时没有执行权限。处理方式是把 ORACLE_HOME/bin 下所有文件属主统一改回 oracle用 chown -R oracle:oinstall 处理然后再 lsnrctl start。另一个隐蔽原因是环境变量里 ORACLE_HOME 指向了打补丁前备份的目录监听启动时找到的 listener.ora 还是旧路径检查 listener.ora 里的 Oracle 相关路径确保和当前 HOME 一致。清理完属主问题后监听日志也是排查重点日志路径在 $ORACLE_HOME/network/log/listener.log看最后几行就能确认是权限拒绝还是端口占用。5.4 现象想回滚却发现 SQL 脚本没有后悔药补丁打完第二天某个业务模块出现兼容性问题决定回滚。执行 opatch rollback -id 补丁号二进制确实回退了但数据库字典里补丁信息还在业务问题依旧。原因在于 OPatch 回滚只负责文件层面恢复catbundle.sql 对数据字典的修改不会自动撤销11.2.0.1 的补丁回滚机制在 SQL 阶段没有完整的自动反向脚本。所以在回滚操作之前必须先评估如果 SQL 脚本已经执行过最可靠的后悔药是闪回数据库或从 RMAN 备份恢复而不是 opatch rollback。如果 SQL 脚本还没执行opatch rollback 可以干净地回退。这个判断必须在打补丁前就想清楚并把全库备份放在安全位置。等着遇到问题再翻备份往往发现备份时间点不对或者没有归档整个回滚就变成了灾难演练。5.5 现象补丁后业务存储过程报 ORA-04063但库内对象状态正常打补丁完成后存储过程所在包被调用时直接报 ORA-04063 existing state of package has been invalidated查询 dba_objects 却发现对象状态是 VALID。这类现象特别迷惑人因为它不是对象本身失效而是会话里持有的包状态失效。原因在补丁替换二进制后数据库重启导致 session 级别的包状态被作废而应用侧连接池里的旧会话没有重建。解决方法是让应用侧做连接池重建或重启一次应用不需要再动数据库。如果问题集中在少数几个长连接上确认连接池配置里没有启用 session state 复用相关的选项。还有一种做法是在维护窗口执行 alter system flush shared_pool把缓存中的旧状态强制清掉但这个操作影响所有会话不能在业务高峰做。6. 补丁打完后如何验证三条命令与一个巡检习惯6.1 用三条命令确认补丁真实生效打补丁是不是成功不能用“感觉业务没报错”来判断要落到具体命令输出上。我每次收尾必跑三条检查第一条看 OPatch 清单第二条查数据字典补丁记录第三条执行一个核心只读存储过程确认运行链路正常。# 1. 确认二进制层面的补丁记录 $ORACLE_HOME/opatch/opatch lsinventory -detail | grep -B2 -A2 Patch description # 2. 确认数据字典层面的补丁记录 sqlplus -S / as sysdba EOF select patch_id, action, status, description from dba_registry_sqlpatch where statusAPPLY order by action_time desc; EOF # 3. 验证核心业务存储过程可执行选择只读场景 sqlplus app_user/app_passwordPROD EOF begin pkg_rpt_daily.get_snapshot(1); end; / EOF第一条命令的 grep 上下文里能看到补丁全名、patch id 和描述确认和下载的补丁包一致。第二条命令查 dba_registry_sqlpatch能列出补丁在数据字典里的应用状态和执行时间如果查出来是空或者状态不是 APPLY说明 SQL 脚本没执行成功。第三条命令挑了应用侧最常调用的只读存储过程能通就说明从数据库引擎到 JVM 到应用对象的整条链没有断裂。三条命令全部通过后再把数据库 alert 日志里补丁时间点附近的 ORA- 报错扫一遍。6.2 把补丁台账写进日常巡检的一个习惯验证通过不算完补丁的长期价值体现在下次排查问题时能快速定位版本。我做了一个非常简单的补丁台账表每次维护操作后手动更新一行工作量和价值回报比极高。字段内容示例打补丁日期2026-03-14补丁编号Patch 编号与描述补丁类型SPU / OJVM / one-offOPatch 版本打补丁前的升级目标版本脚本执行日志catbundle 输出日志路径验证结论三条命令全部通过存储过程验证通过这个台账不需要什么平台和数据库工具一个 Excel 或者 Markdown 表格就够。它的价值在半年后体现当某个存储过程行为异常时翻台账能立刻看到“那次补丁改了什么”。我一开始也不做台账后来碰到一个库莫名其妙出现数据写入延迟排查了两天才想起来是两个月前一个 SPU 引入的统计信息变更从那以后每次打完补丁顺手存一条记录成了固定习惯。希望帮到你。本文还有配套的精品资源点击获取
