导读
在日常运维工作中，技术决策无处不在。每一次选择和判断，都会直接影响系统的稳定性与安全性。特别是在安全生产的背景下，正确的技术决策不仅能有效规避故障与风险，更是保障业务连续性的核心所在。
本期分享，墨天轮技术研究院院长、二线负责人杨廷琨将结合实际案例，为大家带来一场关于“日常运维中的技术决策”的深入思考与探讨，助力大家在复杂场景中做出更加稳妥、可持续的技术选择。
本文整理自直播分享，部分语句在不改变原意的基础上做了更改。
演讲资料：https://www.modb.pro/doc/145110
视频回放：https://www.modb.pro/video/10397
杨廷琨
墨天轮技术研究院院长，二线负责人
ACOUG核心专家，，高级咨询顾问，称"杨长老"；数年如一日坚持进行Oracle技术研究与写作，号称"Oracle的百科全书"，在自己的博客上累计发表了超过3000篇文章。
关于技术决策这个话题，前几周安全系列分享中，已有同事从操作层面介绍了如何避免误删表、防止连接错误数据库、规避不当操作等实用内容，为日常工作提供了指导。
今天，我想探讨更高层次的问题 —— 面对技术选择时，我们该如何思考和作出稳妥、可持续的决策。这不仅涉及操作正确性，更关系到整体架构和方向的把控。为便于讨论，我准备了三个真实案例，期待与大家深入交流。
案例一：DDL删除字段导致核心系统全挂起
在数据库的日常运维中，DDL（数据定义语言）操作常常被认为是“轻量级”的，尤其是像添加或删除字段这样的结构变更。然而，真实的生产环境却给我们上了深刻的一课 —— 删字段并不简单，错误时机和操作方式，可能引发系统级灾难。
这是我们团队亲历的一个客户故障案例，也成为我们后续在数据库平台设计和产品培训中反复引用的警示故事。
起因：一个删除字段的操作
某金融客户的数据库中有一张大表，表内存储着多年积累的业务数据。业务上线多年，表结构存在一定冗余，数据库团队计划清理掉一个“已经不用的字段”。考虑到只是“删字段”，也没安排停机时间窗口，就在白天业务高峰期直接执行了这条 DDL 语句。没想到，这条操作像是按下了“灾难按钮”。执行删除字段之后，系统逐渐表现出严重性能异常，最终所有业务请求被锁死，数据库不可用。客户紧急报警，我们团队介入分析。
图1:案例一背景
故障分析一：删除字段在大表上是高风险操作
绝大多数 DDL（如添加字段、修改字段名）只是修改数据字典，通常秒级完成。但删除字段属于特殊 DDL，会触发对表中每一个数据块的访问与清理操作，本质上类似一次全表级 DML，极其耗时。
这个操作没有预判到其真正影响，直接在生产高峰期执行，无异于自断经脉。
故障分析二：并发业务加剧锁竞争
在没有停机窗口的情况下执行这个操作，业务仍在高并发访问这张大表。而删除字段操作加了表级锁，长时间未释放，导致后续所有访问该表的业务全部被阻塞，排队等待锁。
数据库系统负载飙升，用户请求超时堆积，业务系统进入“假死”状态。
故障分析三：checkpoint 导致无法回滚
客户意识到问题后，尝试用 Ctrl+C 中断操作，本以为可以通过事务回滚挽救。没想到，执行 DDL 后不久，有人手动触发了 checkpoint —— 这意味着部分变更已经被写入数据文件，无法撤销。
图2:checkpoint含义
以上的这些操作导致数据库陷入了“半完成状态”：删字段操作回不了头，也做不完，只能咬牙完成。故障持续了近1小时，客户技术团队最终紧急切换至备用数据库，由我们团队完成后续善后处理。
案例启发
这次事件给我们带来了深刻启发，也总结出如下三点教训：
-
DDL 操作要评估表规模与运行状态
不要仅凭“经验”判断 DDL 是否安全，尤其在面对大表和复杂结构变更时，务必事先评估数据量与执行代价。 -
生产环境慎做结构变更，特别是大表
建议安排专门的停机窗口或使用 Online DDL 工具，避免在业务高峰执行高风险 DDL。 -
谨慎使用 checkpoint 和低层语句
不恰当的 checkpoint 操作可能直接破坏回滚机制，让系统陷入不可控状态。
图3:删除字段最佳实践
案例二：修改字段精度引发的数据处理难题
在实际客户场景中，遇到了一个表字段精度修改的问题。客户想将一个 number 类型字段的小数精度从 12 提升到 13（即由原来支持 2 位小数，提升为 3 位小数），但在执行时数据库却报错：
这是很多人在数据库操作中容易踩到的坑 —— 不能直接修改有数据的字段精度。
图4:案例二背景
现场应对方案
一线同事第一时间提出的解决思路是：“既然不能直接改，那我就加一个新列，把老列的值复制进去，再删掉老列。尽管并行加速能解决部分性能问题，但是：运行这种方式其实不是较优方案，并没有解决所有的问题。”
图5:前期四种方案对比
后来，我们对这个问题进行了深入分析，逐步还原了背后的技术根因，发现主要问题在于以下几点：
- 新增字段并灌入数据，会导致每行记录的长度增加；
- 原表数据已经接近满页，此时一旦数据变长，原有位置放不下，就会引发 行迁移（row migration）；
- 行迁移会带来显著的性能问题，特别是后续的查询、更新操作可能明显变慢；
此外，删除列的操作本身也潜藏高风险，比如可能涉及元数据修改、对象锁定等，稍有不慎就会影响线上业务。
二线优化建议
针对这个场景，二线提出了几条实用的优化建议，希望为大家后续处理类似问题提供参考：
- 优先评估是否可以采用在线重定义（Online Redefinition）或其他更平滑的方式替代直接操作原表，从而降低对生产系统的冲击；
- 尽量避免大范围的
UPDATE操作，可以考虑分批、按条件进行更新，降低资源消耗； - 如果确实需要新增列并更新数据，应事先评估表空间使用情况，防止触发大规模行迁移；
- 在删除列之前，务必要做好备份和演练，确保不会对元数据造成不可逆的破坏。
图6:优化方案：在线重定义
图7:优化方案：在线修改
案例三：数据坏块问题及金融客户的多方案修复实践
在数据库运维中，坏块（block corruption）是一个不可忽视的问题，尤其在金融行业的 7×24 小时系统中，大面积坏块可能导致业务中断和数据一致性风险。
本案例客户来自金融行业，数据库系统长期在线运行。通过 ACO 的 date block corruption 视图，检测到约 600 条坏块记录，实际涉及更多非连续数据块，分布在多个数据文件中。尽管当前业务尚无明显异常，但若坏块增多或被频繁访问，可能严重影响系统稳定性和数据写入，需及时修复。
图8:案例三背景
修复方案比较
| 修复方式 | 适用场景 | 系统影响 | 停机时间 | 优点 | 缺点或风险 |
|---|---|---|---|---|---|
| 全库恢复（整体恢复） | 坏块数量多，影响频繁，前台频繁报错，需确保数据一致性 | 全库业务不可用 | 长，可能数小时 | 保证数据一致性，适用于严重损坏场景 | 停机时间长，业务全面中断 |
| 数据文件级恢复 | 坏块集中在部分数据文件，影响范围可控，业务影响有限 | 局部业务可能受影响 | 中等，依恢复数量而定 | 操作灵活，可分文件分批恢复 | 每次操作范围小但整体耗时长，影响业务不可控，容易引发连锁访问错误 |
| 主备切换（DG切换） | 有可用的同步备库，主库出现坏块但备库无报错，适用于7×24高可用场景 | 取决于备库承载能力与切换流程 | 短，一般10分钟~30分钟 | 避免主库直接受影响，便于主库修复 | 切换存在风险，需改IP、调整中间件配置，可能引发其他系统联动问题 |
| 数据块级恢复（Block Recover） | 坏块数量少且分散，对业务影响不明显，有备份或ADG支持 | 几乎无业务影响 | 极短或无停机时间 | 修复精确、无感知 | 需具备完整备份或ADG支持，某些版本才支持自动修复 |
客户方案
综合评估业务影响、恢复复杂度与可控性后，最终为客户选择了Block Recover。这一方案在不中断系统运行的前提下，快速精准地修复了损坏的数据块，避免了业务停机、恢复复杂和不可控风险。
案例总结
当面临数据库坏块时，切勿一刀切地选择全库恢复或盲目切主备。应结合以下几个维度做出判断：
- 坏块数量与分布
- 业务影响程度
- 系统架构（是否有备库）
- 运维窗口的可接受时长
图9:案例总结
技术决策看似日常，却关乎系统的生命线。只有不断积累经验、沉淀方法，才能在关键时刻快速响应、精准判断，确保业务安全稳定运行。
以上就是我今天分享的所有内容，谢谢大家！
