导读

在数据库的日常运维工作中，技术决策无处不在。每一次选择和判断，都会直接影响系统的稳定性与安全性。特别是在安全生产的背景下，正确的技术决策不仅能有效规避故障与风险，更是保障业务连续性的核心所在。

云和恩墨联合创始人、技术二线负责人杨廷琨在最近的一场直播中，结合实际案例为大家带来一场关于“日常运维中的技术决策”的深入思考与探讨。以下为直播分享实录。（点击这里观看直播回放）

关于技术决策这个话题，我想探讨更高层次的问题——面对技术选择时，我们该如何思考并做出稳妥、可持续的决策？这不仅涉及操作正确性，更关系到整体架构和方向的把控。为便于讨论，我准备了三个真实案例，期待与大家深入交流。

案例一：DDL删除字段导致核心系统全挂起

在数据库的日常运维中，大部分DDL（数据定义语言）操作由于只涉及数据字典的修改，常常被认为是“轻量级”的，尤其是添加字段这种表结构的变更。然而如果是删除字段，则结果会大相径庭，错误时机和操作方式可能引发系统级灾难。

这是我们团队亲历的一个客户故障案例，也成为我们后续在数据库平台设计和产品培训中反复引用的警示故事。

1

 

起因：一个删除字段的操作

某制造业客户的数据库中有一张大表，表内存储着多年积累的业务数据。客户计划清理掉一个“已经不用的字段”，但由于对技术方案评估不足，没有安排停机时间窗口，在白天业务高峰期就直接执行了相关DDL语句。没想到，这条操作像是按下了“灾难按钮”——执行删除字段之后，系统逐渐表现出严重性能异常，最终所有业务请求被锁死，数据库不可用。客户紧急报警，我们的团队介入分析。

案例背景

1

某客户7*24系统出现业务挂起

2

检查发现运行了DDL语句删除字段

3

由于操作表很大，怕UNDO空间不足，使用了CHECKPOINT语句

4

DDL导致表上的DML挂起，长时间影响业务，维护人员选择中止DDL

5

使用CHECKPOINT语句的DROP COLUMN是不可撤销操作，后续只能继续删除或删表

6

更严重的是目前表处于不一致状态，对表的查询都会被挂起

2

 

故障分析

1、删除字段在大表上是高风险操作

绝大多数 DDL（如添加字段、修改字段名）只是修改数据字典，通常秒级完成。但删除字段属于特殊 DDL，会触发对表中每一个数据块的访问与清理操作，本质上类似一次全表级 DML，极其耗时。

这个操作没有预判到其真正影响，直接在生产高峰期执行，无异于自断经脉。

2、并发业务加剧锁竞争

在没有停机窗口的情况下执行这个操作，业务仍在高并发访问这张大表。而删除字段操作加了表级锁，长时间未释放，导致后续所有访问该表的业务全部被阻塞，排队等待锁。

数据库系统负载飙升，用户请求超时堆积，业务系统进入“假死”状态。

3、checkpoint 导致无法回滚

客户意识到问题后，尝试用Ctrl+C中断操作，本以为可以通过事务回滚挽救。但是由于这条删除字段的DDL带了checkpoint语句，这意味着部分变更已经被写入数据文件，无法撤销。

图1: checkpoint含义

以上的这些操作导致数据库陷入了“半完成状态”：删字段操作回不了头，也做不完，无奈只能求助我方通过非常规手段完成后续善后处理。

3

 

案例启发

这次事件给我们带来了深刻启发，也总结出如下三点教训：

1. DDL操作要评估表规模与运行状态，不要仅凭“经验”判断DDL是否安全，尤其在面对大表和复杂结构变更时，务必事先评估数据量与执行代价。

2. 生产环境慎做结构变更，特别是大表，建议安排专门的停机窗口或使用Online DDL工具，避免在业务高峰执行高风险DDL。

3. 谨慎使用checkpoint语句，如无特殊情况，不要在删除字段的时候使用，否则可能陷入进退两难的境地。

删除字段最佳实践

1

DDL是有风险的操作，大部分DDL要在闲时或可维护窗口进行

2

ALTER TABLE DROP COLUMN是高风险操作，执行时间和持有锁的时间取决于表的大小，需要在明确的可维护窗口内进行

3

ALTER TABLE DROP COLUMN CHECKPOINT N是导致业务不可用的罪魁祸首，一旦发起操作没有反悔的机会，几乎所有情况都不应该考虑该语句

4

对于临时删除列，使用SET UNUSED COLUMN语句

5

彻底删除列推荐使用在线重定义，需要关注在线重定义的限制条件

案例二：修改字段精度引发的数据处理难题

在实际客户场景中，遇到了一个表字段精度修改的问题。客户想将一个number类型字段的小数精度从(10, 2)提升到(10, 3)，即由原来支持2位小数，提升为3位小数。但在执行时数据库却报错：这是很多人在数据库操作中容易踩到的坑——不能直接修改有数据的字段精度。

图2: 案例二背景

1

 

现场应对方案

技术一线的同事在第一时间提出的解决思路是：“既然不能直接改，那我就加一个新列，把老列的值复制进去，再删掉老列。”尽管并行加速能解决部分性能问题，但是这种方式其实不是更优方案，并没有解决所有的问题。

方案	描述	执行时间	行迁移
方案一	直接更新新增列数据	207	44%
方案二	并行度4直接更新	77	44%
方案三	同时更新新增列和原始列	148	0
方案四	并行度4同时更新	40	0

表1: 前期四种方案对比

后来，我们对这个问题进行了深入分析，逐步还原了背后的技术根因，发现主要问题在于以下几点：

• 新增字段并灌入数据，会导致每行记录的长度增加；
• 原表数据已经接近满页，此时一旦数据变长，原有位置放不下，就会引发行迁移（row migration）；
• 行迁移会带来显著的性能问题，特别是后续的查询、更新操作可能明显变慢；

此外，删除列的操作本身也潜藏高风险，比如可能涉及元数据修改、对象锁定等，稍有不慎就会影响线上业务。

2

 

二线优化建议

针对这个场景，如果采用技术一线的增加字段并UPDATE的操作，可以进一步优化，采用原字段和新字段互换更新，这样可以有效地降低行迁移。此外，通过在线重定义的方式也是一个降低在线操作影响业务处理的方法。

图3: 优化方案-在线重定义

但是针对这个案例而言，其实导致问题的真正原因还是对于报错的理解不透彻，如果将NUMBER(10, 2)调整为NUMBER(11, 3)，就可以完美解决这个问题了。

图4: 优化方案-在线修改

总结来说，我们其实只需要理解报错的含义，并调整字段的精度，就可以用最小的代价解决问题。我建议DBA碰到问题的时候要多思考，务必找到问题根因，而不是一条路走到黑。

案例三：数据坏块问题及金融客户的多方案修复实践

在数据库运维中，坏块（block corruption）是一个不可忽视的问题，尤其在金融行业的7×24小时系统中，大面积坏块可能导致业务中断和数据一致性风险。

本案例客户来自金融行业，数据库系统长期在线运行。通过查询V$datebase_block_corruption视图，检测到约600条坏块记录，涉及很多非连续数据块，分布在多个数据文件中。尽管当前业务尚无明显异常，但若坏块增多或被频繁访问，可能严重影响系统稳定性和数据写入，需及时修复。

图5: 案例三背景

1

 

修复方案比较

2

 

客户方案

综合评估业务影响、恢复复杂度与可控性后，最终为客户选择了Block Recover。这一方案在不中断系统运行的前提下，快速精准地修复了损坏的数据块，避免了业务停机、恢复复杂和不可控风险。

3

 

案例总结

当面临数据库坏块时，切勿一刀切地选择全库恢复或盲目切主备。应结合以下几个维度做出判断：

• 坏块数量与分布
• 业务影响程度
• 系统架构（是否有备库）
• 运维窗口的可接受时长

经验总结

1

技术方案决策错误的代价比操作错误更大

2

技术方案的确定需要专家评估可行性、风险和代价

3

发生预期外的事故时，及时技术升级避免错过最佳时间窗口

4

深入理解技术原理才能找到最佳解决方案

5

多思考多复盘，有助于技术能力的快速提升

技术决策看似日常，却关乎系统的生命线。只有不断积累经验、沉淀方法，才能在关键时刻快速响应、精准判断，确保业务安全稳定运行。