咱们做数据库运维的最怕的不是硬件故障而是那种“看起来一切正常突然某天夜里批量任务炸了”的隐形雷。尤其是分区表场景我见过太多系统平时数据写入顺风顺水一到月初或者月初批量就冒出“分区不存在导致插入失败”紧接着磁盘空间告急、表空间无法扩展一条链路崩到底。这篇文章就把我这几年来在分区表维护和磁盘空间治理上踩过的坑、沉淀下来的“护流程”和“应急预案”完整拆开讲。内容包括分区缺失问题是怎么发生的、怎么用自动化手段从源头堵住、空间耗尽前的监控阈值和清理扩展方案、以及事故真正发生时怎么快速止血恢复。适合正在维护较大规模数据库实例的DBA、运维工程师和架构师参考新手也能对照着抄作业。1. 分区缺失导致数据插入失败问题往往比想象中更严重1.1 一次典型的生产事故复盘先说一个我实际经历过的问题场景。某业务系统的核心流水表按天做RANGE分区每天凌晨有个定时任务负责创建次日分区。运行了快半年都没出过事。结果某个月底因为某台调度机负载过高定时任务被系统杀掉第二天早上业务方反馈大批量数据插入报错错误信息非常明确——对应分区不存在。当时看到具体报错的时候我第一反应不是去手动补分区而是先确认影响的业务面。因为这张流水表承载的不只是联机交易还连着下游的报表、对账、清算分区缺失意味着所有路由到对应分区的写入全部失败。幸运的是应用有重试机制没有造成数据永久丢失但重试风暴直接把数据库连接池打满周边系统跟着雪崩最后处理了接近两个小时业务才恢复。复盘之后我总结出一个判断分区缺失不是“补一个分区”那么简单而是“护流程”缺失导致的系统性风险。补分区只是治标真正要解决的是谁能保证定时任务每次都成功失败了怎么第一时间发现极端情况下有没有兜底方案1.2 为什么分区维护会“断档”很多团队对分区维护的理解就是“写个脚本、挂个crontab、每天跑一次”这个思路没错但有几个隐患经常被忽略一是定时任务本身可能不执行。调度机宕机、负载过高被杀进程、脚本因为语法变更报错都会导致任务静默失败。而大多数公司对定时任务的成功率监控是不完整的脚本跑失败了没有告警分区缺失要到业务写入失败那一刻才能暴露。二是DDL操作的权限和资源问题。创建分区虽然是轻量DDL但如果在业务高峰期执行可能触发库内的字典锁竞争慢下来后超时超时之后脚本如果没做重试和幂等处理任务就算执行了实际上也没建成分区。三是人为操作导致的分区误删除。分区清理脚本写错边界条件、误删了未来的分区、手工归档时删错对象这些我都见过。尤其是那种“清理三个月前分区”的脚本如果日期计算逻辑在跨年时算错了后果就是要把明年甚至后年的分区全删掉。还有一个大家容易忽略的场景分区表结构变更后没有同步维护计划。业务加了一个新维度表从哈希分区改成复合分区老的创建分区脚本可能完全失效但没人知道。分区维护看起来是个粗活实际上任何一个环节的假设失效都会直接把数据写入打穿。1.3 分区缺失造成的连锁反应分区缺失的直接表现是插入失败但连锁反应往往更可怕。首先是应用重试风暴。绝大多数业务代码不会为“分区不存在”专门做异常处理框架层面的重试机制会反复触发同一个失败SQL短时间内撑爆数据库的并发连接。我见过因为单条插入失败重试把连接池从50打满到2000的。其次是数据延迟和积压。联机写入失败后消息队列里的数据不会消失但消费端一直在报错消息越积越多。等分区修复之后积压数据瞬间灌入数据库又可能触发新的性能瓶颈。再往下就是空间问题被掩盖。一个分区缺失没被发现意味着对应的数据文件可能已经很久没有新增而其他分区还在持续增长。有时候DBA只看到“总空间剩余很多”其实某个表空间的数据文件已经逼近上限一旦那个分区后续被创建写入量一上来立刻就会触发“无法扩展表空间”的故障。这也是为什么我坚持把分区维护和空间治理放在同一个流程里来设计而不是分开各自为战。2. 护流程核心把“人工定时维护”升级为“自动巡检预创建双保险”2.1 巡检脚本每天盯着分区元数据解决分区缺失的第一步是让“有没有分区”这件事变得随时可查、异常可感知。不要等到写入失败才被动发现而要主动巡检。我这里的做法是写一个巡检脚本每天定时跑检查所有关键分区表的未来分区覆盖情况。核心思路是针对每张分区表统计它当前的最大分区边界然后计算从当前日期到“需要提前覆盖的日期”之间是否存在缺失的分区区间。伪逻辑大概是这样-- 以Oracle为例查到每张表的最后一个分区的上边界 SELECT table_owner, table_name, partition_name, high_value FROM dba_tab_partitions WHERE table_name T_LOG ORDER BY partition_position DESC; -- 在程序里解析high_value和当前日期对比 -- 如果 max_partition_date 目标日期当前日期N天说明有缺口脚本不需要很复杂关键是明确每个表需要提前多久建分区。有的表每天写入量很大我建议提前创建未来7天到30天的分区有的表一个月才产生一个分区提前一个周期就行。巡检脚本发现的缺口直接进入告警通道同时调用建分区脚本尝试补齐。提示巡检不是一次性建完就拉倒。它存在的意义是把“静默失败”变成“显式告警”。定时任务跑挂了巡检脚本也挂了至少你还有最后一道人工查漏补缺的机会。2.2 预创建机制提前把未来N个月的分区建好巡检是发现问题预创建是从源头减少问题发生的概率。我更倾向于把建分区动作提前一个窗口期批量做掉而不是卡在每天凌晨才创建。举个例子某流水表日增数据约2GB按天分区。每个月月底我直接预创建下个月的31个分区每周再补一次确保未来7天总有分区可用。这样即使某天定时任务挂了、调度机宕了未来一周内的写入都不会受影响有充足的修复时间。批量预创建的好处有几个一是DDL可以安排在业务低峰期集中执行避免每天跟业务争抢资源二是即使某个分区创建失败剩下的分区不受影响风险被隔离三是巡检的“缺口”目标变成“未来7天必须有分区”而不是“明天必须有分区”缓冲期从小时级变成天级。预创建脚本的幂等性必须做好。因为批量脚本一旦重复执行或者多个调度节点同时触发就会出现“分区已存在”的冲突。所以在建分区之前一定要先查一次元数据有就跳过没有才建。另外脚本最好支持指定日期区间方便手工补建时使用。Oracle的间隔分区Interval Partitioning其实是自动建分区的内置方案如果版本支持、分区键类型简单可以优先考虑但要注意间隔分区在部分版本上对默认表空间、子分区模板有限制还是需要人工巡检兜底。MySQL 8.0的分区表达式不支持动态建分区通常还是靠外部调度实现。2.3 防呆双保险默认分区兜底 应用端校验自动巡检和预创建能把风险降到极低但还不够。我坚持一个原则能防呆的地方绝对不依赖人的自觉。所以还需要两道保险。第一道是默认分区兜底。在主键和查询逻辑允许的前提下给分区表设置一个MAXVALUE分区Oracle或者默认分区MySQL所有没有落在明确分区范围的数据全部写入默认分区。这样即使创建分区的流程完全失效插入不会失败数据不会丢只是默认分区越来越大需要额外监控。当然默认分区不能一劳永逸。业务数据如果大量落在默认分区就失去了分区裁剪的意义查询性能会变差。所以默认分区只能作为“故障期间保证可用性”的保险丝平时还是要把主分区建好并且监控默认分区的数据量。一旦发现默认分区有大量数据进入就要告警说明分区维护链路出问题了。第二道是应用端校验。这个对大多数团队来说改动成本稍高但对核心链路很值得。做法是在应用的DAO层或者数据访问中间件里维护一张“分区配置表”的缓存写入前判断目标分区是否存在不存在时要么走降级路由要么直接触发一个“补充分区”的接口调用。简单说就是让写入方自己关心分区存不存在而不是把压力全压在数据库这一侧。配合默认分区兜底双保险基本能挡住大多数场景。如果业务不愿意做应用端改动至少要把默认分区和巡检这两件事做扎实。3. 空间清理与扩展预案磁盘耗尽之前必须有标准动作3.1 容量监控哪些指标要看阈值怎么定分区维护和空间管理是绑在一起的两件事。分区缺的是“结构”空间缺的是“容量”但它们的故障表现都是写入失败。所以要制定一套容量监控指标不能等“磁盘满了”才知道。我日常会盯几个核心指标一是文件系统使用率。这是最直接、最容易告警的。对于存放数据文件的文件系统使用率超过85%就要关注超过90%就必须处理。不要把阈值定到95%以上因为数据库写入有瞬时波动文件系统一旦写满整个实例可能直接hang住而不是优雅报错。二是表空间剩余空间和数据文件最大可扩展值。有些表空间配了自动扩展但设置了MAXSIZE当逼近MAXSIZE时会报“无法扩展表空间”此时文件系统可能还有剩余。所以不能只看文件系统使用率要看数据库内部的剩余空间和扩展极限。三是增长趋势。粗略估算日均增长量结合剩余可用空间计算出“还能撑几天”。比如某表空间每天增长20GB剩余空间还有1TB表面看很充裕但扣掉日常维护窗口和可能的批量增长高峰实际安全时间窗口可能只有三四周要提前规划扩容。我习惯用一张表格汇总这些关键参数每周审视一次监控项预警阈值严重阈值处理动作文件系统使用率85%92%清理临时文件、归档日志、扩容表空间剩余空间剩余可撑10天剩余可撑3天增加数据文件、调整保留策略分区表最大分区边界距离预创建目标不足3天不足1天立即补齐预创建任务默认分区数据量超过单个分区均值1.5倍超过均值3倍排查维护链路、拆分数据注意容量监控必须落在数据库层而不是只看操作系统层。数据文件的自动扩展上限、表空间的碎片空间、未提交事务占用的undo空间这些只有从数据库内部才能看到全貌。3.2 空间清理执行顺序从最划算的开始磁盘空间告警后很多人的第一反应是删表、删日志实际上应该按照“影响最小、回报最大”的顺序来执行。我自己总结的清理顺序是这样的清理数据库归档日志和监听日志。归档日志是空间大户尤其是开启了归档模式但备份策略不完善的库。先确认归档可以删除的时间点比如备份已经完成且保留天数满足要求然后手动清理或调整备份策略。注意删除归档时要用数据库或备份工具不要直接用rm删物理文件否则控制文件里的记录会不一致。清理临时表空间和排序段。临时表空间在大量排序、哈希连接后可能膨胀虽然正常情况下会释放但如果有长事务或者异常会话临时文件可能一直占着空间。可以查当前使用率确认为空后收缩临时文件。清理无效的中间表和废弃历史表。很多业务会周期性创建中间表跑完就不再使用还有一些历史表已经归档到数仓但源库没有及时下线。逐个确认后truncate或drop空间回收立竿见影。清理分区表的历史分区。对于保留策略明确的分区表直接drop或truncate超过保留期的分区。这个操作比delete数据高效得多因为不产生大量undo和redo还能让对应的数据文件释放空间。前提是确认历史分区已经被备份或归档。最后才考虑压缩或移动数据文件。表压缩如Oracle的OLTP压缩或行压缩能节省大量空间但压缩过程本身消耗CPU需要评估窗口移动数据文件则涉及停机或在线操作风险较高只在前面手段都不够时才用。这里特别提醒一个容易踩的坑删数据后空间未释放。如果表空间设置了自动扩展删除大量数据后数据文件不会自动缩小文件系统使用率可能依然很高。需要用ALTER DATABASE DATAFILE RESIZE或者收缩表空间的操作来手动回收。很多人删了几个小时的数据回头一看磁盘还是满的就是没做这一步。3.3 表空间扩展方案何时手动加数据文件何时启用自动扩展清理和扩展是一体两面。有些场景清理只是拖延时间根本解法是扩容。关于表空间扩展我见过两种极端配置一种完全不开启自动扩展空间耗尽直接报错另一种把每个数据文件的MAXSIZE设为无限大听之任之。前者容易出事故后者容易把磁盘塞爆连累整个实例。正确做法是设置合理的自动扩展上限同时保留手动扩容能力。我的配置原则普通业务表空间数据文件自动扩展每次扩展固定大小比如32GB或64GB并设置一个合理的最大上限避免无限膨胀。核心大表空间关闭自动扩展或者扩展上限设得很高但通过容量监控提前预警在达到阈值前手动增加数据文件。手动操作的好处是可以把新数据文件放到不同的挂载路径分散IO压力。临时表空间和UNDO表空间单独管理临时表空间大小根据排序等需求设置合理初始值UNDO表空间的保留时间根据业务需求配置不要过短也不要过长。手动扩展时有两个细节容易被忽略。一个是表空间内数据文件数量限制每个表空间能容纳的数据文件数量有限Oracle有MAXDATAFILES限制如果频繁扩展导致数据文件数量接近上限后续扩容会报错需要提前规划。另一个是不同数据文件之间的空间使用不均衡Oracle表空间是均分写入但如果数据文件大小不一致可能出现大文件空闲、小文件写满的情况尽量保持数据文件大小一致或者定期做空间均衡。提示扩展表空间不是“公司有钱就能随便扩”。先确认文件系统剩余容量、按路径规划扩展顺序、评估IO能力再执行ALTER TABLESPACE ADD DATAFILE。没有空间规划地盲目扩张只会让下一个故障提前到来。4. 真正发生故障时如何快速响应并恢复业务4.1 最优先的止血操作应急预案再完善事故真正发生时第一步永远是止血不是排查根因。如果当前故障是“分区缺失导致插入失败”最优先的操作是立刻补齐缺失分区并且让写入恢复。不要在这个时刻纠结为什么定时任务挂了可以先把分区补上。如果故障是“磁盘空间耗尽或表空间无法扩展”当务之急是让数据库能够继续写入。我一般按这个优先级处理清理归档日志。优先采用可靠方式快速清理可删除的归档解除文件系统满的燃眉之急。清理临时表空间。如果实例还活着可以尝试收缩临时文件或重启实例让临时文件重建。truncate无用的中间表。这个动作要慎重需要业务确认但在紧急时刻相比整个实例不可用truncate一张确认无用的临时表通常是值得的。扩展表空间或增加数据文件。如果文件系统还有空间直接增加数据文件是最快的恢复路径如果文件系统已经满了必须先清理文件系统空间再做扩展。止血过程中不要做复杂操作。比如不要在磁盘满的情况下执行大型表的DELETE和收缩因为DELETE会产生大量redo和undo空间需求反而更大。紧急时刻就用最简单、最直接的手段腾出空间。4.2 故障排查与定位思路恢复写入之后才进入真正的排查环节。排查思路要清晰分两条线并行。一条是分区维护链路。查定时任务最近几次的执行状态、日志输出、是否有报错查巡检脚本的告警为什么没触发查最近有没有人手工执行过DDL或删分区操作。如果脚本没有日志那说明连基本的可观测性都没做这次事故之后必须补上。另一条是空间链条。查磁盘使用率的增长曲线确认是业务自然增长还是异常膨胀查表空间里哪些对象占的空间最大查归档日志量是否异常查是否有会话一直占用UNDO或临时空间。这里分享一个快速定位空间占用大户的常用SQL思路查dba_segments按段大小排序或者查v$sort_usage、v$temp_space_header看临时段占用情况。如果是Oracle还可以查v$flash_recovery_area_usage看快速恢复区占用。定位到具体对象后再结合业务决定如何处理。排查过程中要注意记录时间线哪一刻出现告警、哪一刻业务开始报错、哪一刻做了止血操作、哪一刻确认恢复。时间线越清晰复盘时越容易还原因果链条。4.3 恢复后的复盘清单恢复不等于结束。每次空间或分区故障之后我强烈建议做一次完整复盘至少要覆盖下面几项故障根因是什么是程序缺陷、流程缺陷还是资源不足现有监控和告警为什么没有提前发现是阈值设置不合理还是监控覆盖缺失故障期间的操作步骤是否有效有没有因为慌乱做了多余操作应急预案和实际操作之间的差距在哪里预案是否需要更新短期内需要立哪些快速改进项比如补脚本、调阈值、加告警还是立刻扩容长期如何从架构上解决比如分区表改成分区自动管理、数据保留策略调整、归档方式优化。复盘不是追责而是把每一次故障的教训固化成流程和工具。我见过很多团队同一个“空间爆满”事故一年内反复出现三次原因就是每次只做了临时扩容没把清理和监控机制建起来也没有完善预案。这样下去DBA始终在救火系统始终不稳定。5. 常见问题速查与实操心得5.1 高频问题排查速查表现象可能原因处理动作插入报错“分区不存在”定时任务未执行、脚本失败、分区被误删手工补分区检查调度日志修复脚本磁盘使用率曲线异常陡增归档日志暴涨、临时文件膨胀、异常会话定位会话清理归档收缩临时文件表空间无法扩展数据文件达到MAXSIZE、文件系统已满增加数据文件或清理空间检查自动扩展上限删了大量数据但空间没释放数据文件未收缩、采用高水位标记RESIZE数据文件或收缩表空间默认分区数据量异常分区维护链路断了数据落入兜底分区修复自动化流程拆分默认分区数据巡检脚本无告警脚本自身挂了、告警通道失效优先解决脚本可观测性补充第二告警通道这个表格我建议直接打印出来贴在工位上遇到对应现象先按表格动作处理再深挖根因。紧急时刻人的判断力会下降有一张明确的操作清单能帮助稳定节奏。5.2 脚本和流程设计中的避坑经验写分区维护脚本和空间清理脚本我有几个经验可以分享第一脚本必须记录日志。这一点怎么强调都不过分。没有日志的脚本等于没有监控。所有自动任务的执行结果要落到独立的日志文件并且日志要有级别、时间戳、执行sql、返回码。之后做故障还原时日志是唯一的客观依据。第二任务调度要支持重试和幂等。脚本内部先检查元数据再执行DDL所有反向操作要考虑清楚。定时任务如果失败要有自动重试机制但重试之前要判断是不是已经有其他节点执行成功了避免重复执行产生冲突。第三告警永远要有两级。一级是预警比如“未来3天没有分区”“文件系统使用率超过85%”留给团队处理时间二级是严重告警比如“分区缺失已经导致写入失败”“空间使用率超过92%”必须立即响应。两级阈值不要都设得太近否则预警相当于没有。第四应急预案要定期演练。分区的应急预案不能只停留在文档层面至少每季度要做一次模拟演练人为把某个分区表的最大分区删掉然后按预案恢复计时看多久能恢复写入人为把文件系统写满看告警能否触发、清理流程能否执行。演练没过关的预案就不算预案。5.3 我的一些额外建议最后聊点个人心得。第一点是把空间和分区放在一个责任域里管理。很多团队把“磁盘空间”归系统管理员管“分区表维护”归DBA管出了事两边互相推。实际上两者是同一个故障链的两端最好由同一个人或同一个小团队统一负责运维DBA不要只盯着SQL和索引还要管好数据生命周期里的容量规划。第二点是在容量规划里留出缓冲。不要按“当前日增长 × 365”算一年的总空间然后只买这么多。业务增长是非线性的、批量任务有波峰、数据归档可能延迟。我给业务方报空间容量时通常按照预计增长的1.5倍到2倍去规划宁可多预留一些也不要在关键促销或结算日被磁盘卡住。第三点是自动化是主线但人要留一手。就算巡检、预创建、告警、扩容全部自动化了也一定要有一个懂的人知道每一步的原理知道这些脚本万一全挂了该怎么办。运维工作不是把一切交给工具就完了工具只是人的延伸。打个比方分区维护和空间预案就像是给数据库买了一份“保险”。买保险不是为了出险而是为了出险时不至于裸奔。你家里装了防盗门出门还是会反锁数据库有了预案日常还是要盯监控。真正的稳定从来不是靠某一次完美操作而是靠一整套能在故障发生前就提前预判、在故障发生时快速兜底的机制。下次再遇到分区缺失或者磁盘写满的问题别急着在群里问“怎么办”先把这套护流程跑一遍你会发现大部分坑早就被填平了。
咱们做数据库运维的最怕的不是硬件故障而是那种“看起来一切正常突然某天夜里批量任务炸了”的隐形雷。尤其是分区表场景我见过太多系统平时数据写入顺风顺水一到月初或者月初批量就冒出“分区不存在导致插入失败”紧接着磁盘空间告急、表空间无法扩展一条链路崩到底。这篇文章就把我这几年来在分区表维护和磁盘空间治理上踩过的坑、沉淀下来的“护流程”和“应急预案”完整拆开讲。内容包括分区缺失问题是怎么发生的、怎么用自动化手段从源头堵住、空间耗尽前的监控阈值和清理扩展方案、以及事故真正发生时怎么快速止血恢复。适合正在维护较大规模数据库实例的DBA、运维工程师和架构师参考新手也能对照着抄作业。1. 分区缺失导致数据插入失败问题往往比想象中更严重1.1 一次典型的生产事故复盘先说一个我实际经历过的问题场景。某业务系统的核心流水表按天做RANGE分区每天凌晨有个定时任务负责创建次日分区。运行了快半年都没出过事。结果某个月底因为某台调度机负载过高定时任务被系统杀掉第二天早上业务方反馈大批量数据插入报错错误信息非常明确——对应分区不存在。当时看到具体报错的时候我第一反应不是去手动补分区而是先确认影响的业务面。因为这张流水表承载的不只是联机交易还连着下游的报表、对账、清算分区缺失意味着所有路由到对应分区的写入全部失败。幸运的是应用有重试机制没有造成数据永久丢失但重试风暴直接把数据库连接池打满周边系统跟着雪崩最后处理了接近两个小时业务才恢复。复盘之后我总结出一个判断分区缺失不是“补一个分区”那么简单而是“护流程”缺失导致的系统性风险。补分区只是治标真正要解决的是谁能保证定时任务每次都成功失败了怎么第一时间发现极端情况下有没有兜底方案1.2 为什么分区维护会“断档”很多团队对分区维护的理解就是“写个脚本、挂个crontab、每天跑一次”这个思路没错但有几个隐患经常被忽略一是定时任务本身可能不执行。调度机宕机、负载过高被杀进程、脚本因为语法变更报错都会导致任务静默失败。而大多数公司对定时任务的成功率监控是不完整的脚本跑失败了没有告警分区缺失要到业务写入失败那一刻才能暴露。二是DDL操作的权限和资源问题。创建分区虽然是轻量DDL但如果在业务高峰期执行可能触发库内的字典锁竞争慢下来后超时超时之后脚本如果没做重试和幂等处理任务就算执行了实际上也没建成分区。三是人为操作导致的分区误删除。分区清理脚本写错边界条件、误删了未来的分区、手工归档时删错对象这些我都见过。尤其是那种“清理三个月前分区”的脚本如果日期计算逻辑在跨年时算错了后果就是要把明年甚至后年的分区全删掉。还有一个大家容易忽略的场景分区表结构变更后没有同步维护计划。业务加了一个新维度表从哈希分区改成复合分区老的创建分区脚本可能完全失效但没人知道。分区维护看起来是个粗活实际上任何一个环节的假设失效都会直接把数据写入打穿。1.3 分区缺失造成的连锁反应分区缺失的直接表现是插入失败但连锁反应往往更可怕。首先是应用重试风暴。绝大多数业务代码不会为“分区不存在”专门做异常处理框架层面的重试机制会反复触发同一个失败SQL短时间内撑爆数据库的并发连接。我见过因为单条插入失败重试把连接池从50打满到2000的。其次是数据延迟和积压。联机写入失败后消息队列里的数据不会消失但消费端一直在报错消息越积越多。等分区修复之后积压数据瞬间灌入数据库又可能触发新的性能瓶颈。再往下就是空间问题被掩盖。一个分区缺失没被发现意味着对应的数据文件可能已经很久没有新增而其他分区还在持续增长。有时候DBA只看到“总空间剩余很多”其实某个表空间的数据文件已经逼近上限一旦那个分区后续被创建写入量一上来立刻就会触发“无法扩展表空间”的故障。这也是为什么我坚持把分区维护和空间治理放在同一个流程里来设计而不是分开各自为战。2. 护流程核心把“人工定时维护”升级为“自动巡检预创建双保险”2.1 巡检脚本每天盯着分区元数据解决分区缺失的第一步是让“有没有分区”这件事变得随时可查、异常可感知。不要等到写入失败才被动发现而要主动巡检。我这里的做法是写一个巡检脚本每天定时跑检查所有关键分区表的未来分区覆盖情况。核心思路是针对每张分区表统计它当前的最大分区边界然后计算从当前日期到“需要提前覆盖的日期”之间是否存在缺失的分区区间。伪逻辑大概是这样-- 以Oracle为例查到每张表的最后一个分区的上边界 SELECT table_owner, table_name, partition_name, high_value FROM dba_tab_partitions WHERE table_name T_LOG ORDER BY partition_position DESC; -- 在程序里解析high_value和当前日期对比 -- 如果 max_partition_date 目标日期当前日期N天说明有缺口脚本不需要很复杂关键是明确每个表需要提前多久建分区。有的表每天写入量很大我建议提前创建未来7天到30天的分区有的表一个月才产生一个分区提前一个周期就行。巡检脚本发现的缺口直接进入告警通道同时调用建分区脚本尝试补齐。提示巡检不是一次性建完就拉倒。它存在的意义是把“静默失败”变成“显式告警”。定时任务跑挂了巡检脚本也挂了至少你还有最后一道人工查漏补缺的机会。2.2 预创建机制提前把未来N个月的分区建好巡检是发现问题预创建是从源头减少问题发生的概率。我更倾向于把建分区动作提前一个窗口期批量做掉而不是卡在每天凌晨才创建。举个例子某流水表日增数据约2GB按天分区。每个月月底我直接预创建下个月的31个分区每周再补一次确保未来7天总有分区可用。这样即使某天定时任务挂了、调度机宕了未来一周内的写入都不会受影响有充足的修复时间。批量预创建的好处有几个一是DDL可以安排在业务低峰期集中执行避免每天跟业务争抢资源二是即使某个分区创建失败剩下的分区不受影响风险被隔离三是巡检的“缺口”目标变成“未来7天必须有分区”而不是“明天必须有分区”缓冲期从小时级变成天级。预创建脚本的幂等性必须做好。因为批量脚本一旦重复执行或者多个调度节点同时触发就会出现“分区已存在”的冲突。所以在建分区之前一定要先查一次元数据有就跳过没有才建。另外脚本最好支持指定日期区间方便手工补建时使用。Oracle的间隔分区Interval Partitioning其实是自动建分区的内置方案如果版本支持、分区键类型简单可以优先考虑但要注意间隔分区在部分版本上对默认表空间、子分区模板有限制还是需要人工巡检兜底。MySQL 8.0的分区表达式不支持动态建分区通常还是靠外部调度实现。2.3 防呆双保险默认分区兜底 应用端校验自动巡检和预创建能把风险降到极低但还不够。我坚持一个原则能防呆的地方绝对不依赖人的自觉。所以还需要两道保险。第一道是默认分区兜底。在主键和查询逻辑允许的前提下给分区表设置一个MAXVALUE分区Oracle或者默认分区MySQL所有没有落在明确分区范围的数据全部写入默认分区。这样即使创建分区的流程完全失效插入不会失败数据不会丢只是默认分区越来越大需要额外监控。当然默认分区不能一劳永逸。业务数据如果大量落在默认分区就失去了分区裁剪的意义查询性能会变差。所以默认分区只能作为“故障期间保证可用性”的保险丝平时还是要把主分区建好并且监控默认分区的数据量。一旦发现默认分区有大量数据进入就要告警说明分区维护链路出问题了。第二道是应用端校验。这个对大多数团队来说改动成本稍高但对核心链路很值得。做法是在应用的DAO层或者数据访问中间件里维护一张“分区配置表”的缓存写入前判断目标分区是否存在不存在时要么走降级路由要么直接触发一个“补充分区”的接口调用。简单说就是让写入方自己关心分区存不存在而不是把压力全压在数据库这一侧。配合默认分区兜底双保险基本能挡住大多数场景。如果业务不愿意做应用端改动至少要把默认分区和巡检这两件事做扎实。3. 空间清理与扩展预案磁盘耗尽之前必须有标准动作3.1 容量监控哪些指标要看阈值怎么定分区维护和空间管理是绑在一起的两件事。分区缺的是“结构”空间缺的是“容量”但它们的故障表现都是写入失败。所以要制定一套容量监控指标不能等“磁盘满了”才知道。我日常会盯几个核心指标一是文件系统使用率。这是最直接、最容易告警的。对于存放数据文件的文件系统使用率超过85%就要关注超过90%就必须处理。不要把阈值定到95%以上因为数据库写入有瞬时波动文件系统一旦写满整个实例可能直接hang住而不是优雅报错。二是表空间剩余空间和数据文件最大可扩展值。有些表空间配了自动扩展但设置了MAXSIZE当逼近MAXSIZE时会报“无法扩展表空间”此时文件系统可能还有剩余。所以不能只看文件系统使用率要看数据库内部的剩余空间和扩展极限。三是增长趋势。粗略估算日均增长量结合剩余可用空间计算出“还能撑几天”。比如某表空间每天增长20GB剩余空间还有1TB表面看很充裕但扣掉日常维护窗口和可能的批量增长高峰实际安全时间窗口可能只有三四周要提前规划扩容。我习惯用一张表格汇总这些关键参数每周审视一次监控项预警阈值严重阈值处理动作文件系统使用率85%92%清理临时文件、归档日志、扩容表空间剩余空间剩余可撑10天剩余可撑3天增加数据文件、调整保留策略分区表最大分区边界距离预创建目标不足3天不足1天立即补齐预创建任务默认分区数据量超过单个分区均值1.5倍超过均值3倍排查维护链路、拆分数据注意容量监控必须落在数据库层而不是只看操作系统层。数据文件的自动扩展上限、表空间的碎片空间、未提交事务占用的undo空间这些只有从数据库内部才能看到全貌。3.2 空间清理执行顺序从最划算的开始磁盘空间告警后很多人的第一反应是删表、删日志实际上应该按照“影响最小、回报最大”的顺序来执行。我自己总结的清理顺序是这样的清理数据库归档日志和监听日志。归档日志是空间大户尤其是开启了归档模式但备份策略不完善的库。先确认归档可以删除的时间点比如备份已经完成且保留天数满足要求然后手动清理或调整备份策略。注意删除归档时要用数据库或备份工具不要直接用rm删物理文件否则控制文件里的记录会不一致。清理临时表空间和排序段。临时表空间在大量排序、哈希连接后可能膨胀虽然正常情况下会释放但如果有长事务或者异常会话临时文件可能一直占着空间。可以查当前使用率确认为空后收缩临时文件。清理无效的中间表和废弃历史表。很多业务会周期性创建中间表跑完就不再使用还有一些历史表已经归档到数仓但源库没有及时下线。逐个确认后truncate或drop空间回收立竿见影。清理分区表的历史分区。对于保留策略明确的分区表直接drop或truncate超过保留期的分区。这个操作比delete数据高效得多因为不产生大量undo和redo还能让对应的数据文件释放空间。前提是确认历史分区已经被备份或归档。最后才考虑压缩或移动数据文件。表压缩如Oracle的OLTP压缩或行压缩能节省大量空间但压缩过程本身消耗CPU需要评估窗口移动数据文件则涉及停机或在线操作风险较高只在前面手段都不够时才用。这里特别提醒一个容易踩的坑删数据后空间未释放。如果表空间设置了自动扩展删除大量数据后数据文件不会自动缩小文件系统使用率可能依然很高。需要用ALTER DATABASE DATAFILE RESIZE或者收缩表空间的操作来手动回收。很多人删了几个小时的数据回头一看磁盘还是满的就是没做这一步。3.3 表空间扩展方案何时手动加数据文件何时启用自动扩展清理和扩展是一体两面。有些场景清理只是拖延时间根本解法是扩容。关于表空间扩展我见过两种极端配置一种完全不开启自动扩展空间耗尽直接报错另一种把每个数据文件的MAXSIZE设为无限大听之任之。前者容易出事故后者容易把磁盘塞爆连累整个实例。正确做法是设置合理的自动扩展上限同时保留手动扩容能力。我的配置原则普通业务表空间数据文件自动扩展每次扩展固定大小比如32GB或64GB并设置一个合理的最大上限避免无限膨胀。核心大表空间关闭自动扩展或者扩展上限设得很高但通过容量监控提前预警在达到阈值前手动增加数据文件。手动操作的好处是可以把新数据文件放到不同的挂载路径分散IO压力。临时表空间和UNDO表空间单独管理临时表空间大小根据排序等需求设置合理初始值UNDO表空间的保留时间根据业务需求配置不要过短也不要过长。手动扩展时有两个细节容易被忽略。一个是表空间内数据文件数量限制每个表空间能容纳的数据文件数量有限Oracle有MAXDATAFILES限制如果频繁扩展导致数据文件数量接近上限后续扩容会报错需要提前规划。另一个是不同数据文件之间的空间使用不均衡Oracle表空间是均分写入但如果数据文件大小不一致可能出现大文件空闲、小文件写满的情况尽量保持数据文件大小一致或者定期做空间均衡。提示扩展表空间不是“公司有钱就能随便扩”。先确认文件系统剩余容量、按路径规划扩展顺序、评估IO能力再执行ALTER TABLESPACE ADD DATAFILE。没有空间规划地盲目扩张只会让下一个故障提前到来。4. 真正发生故障时如何快速响应并恢复业务4.1 最优先的止血操作应急预案再完善事故真正发生时第一步永远是止血不是排查根因。如果当前故障是“分区缺失导致插入失败”最优先的操作是立刻补齐缺失分区并且让写入恢复。不要在这个时刻纠结为什么定时任务挂了可以先把分区补上。如果故障是“磁盘空间耗尽或表空间无法扩展”当务之急是让数据库能够继续写入。我一般按这个优先级处理清理归档日志。优先采用可靠方式快速清理可删除的归档解除文件系统满的燃眉之急。清理临时表空间。如果实例还活着可以尝试收缩临时文件或重启实例让临时文件重建。truncate无用的中间表。这个动作要慎重需要业务确认但在紧急时刻相比整个实例不可用truncate一张确认无用的临时表通常是值得的。扩展表空间或增加数据文件。如果文件系统还有空间直接增加数据文件是最快的恢复路径如果文件系统已经满了必须先清理文件系统空间再做扩展。止血过程中不要做复杂操作。比如不要在磁盘满的情况下执行大型表的DELETE和收缩因为DELETE会产生大量redo和undo空间需求反而更大。紧急时刻就用最简单、最直接的手段腾出空间。4.2 故障排查与定位思路恢复写入之后才进入真正的排查环节。排查思路要清晰分两条线并行。一条是分区维护链路。查定时任务最近几次的执行状态、日志输出、是否有报错查巡检脚本的告警为什么没触发查最近有没有人手工执行过DDL或删分区操作。如果脚本没有日志那说明连基本的可观测性都没做这次事故之后必须补上。另一条是空间链条。查磁盘使用率的增长曲线确认是业务自然增长还是异常膨胀查表空间里哪些对象占的空间最大查归档日志量是否异常查是否有会话一直占用UNDO或临时空间。这里分享一个快速定位空间占用大户的常用SQL思路查dba_segments按段大小排序或者查v$sort_usage、v$temp_space_header看临时段占用情况。如果是Oracle还可以查v$flash_recovery_area_usage看快速恢复区占用。定位到具体对象后再结合业务决定如何处理。排查过程中要注意记录时间线哪一刻出现告警、哪一刻业务开始报错、哪一刻做了止血操作、哪一刻确认恢复。时间线越清晰复盘时越容易还原因果链条。4.3 恢复后的复盘清单恢复不等于结束。每次空间或分区故障之后我强烈建议做一次完整复盘至少要覆盖下面几项故障根因是什么是程序缺陷、流程缺陷还是资源不足现有监控和告警为什么没有提前发现是阈值设置不合理还是监控覆盖缺失故障期间的操作步骤是否有效有没有因为慌乱做了多余操作应急预案和实际操作之间的差距在哪里预案是否需要更新短期内需要立哪些快速改进项比如补脚本、调阈值、加告警还是立刻扩容长期如何从架构上解决比如分区表改成分区自动管理、数据保留策略调整、归档方式优化。复盘不是追责而是把每一次故障的教训固化成流程和工具。我见过很多团队同一个“空间爆满”事故一年内反复出现三次原因就是每次只做了临时扩容没把清理和监控机制建起来也没有完善预案。这样下去DBA始终在救火系统始终不稳定。5. 常见问题速查与实操心得5.1 高频问题排查速查表现象可能原因处理动作插入报错“分区不存在”定时任务未执行、脚本失败、分区被误删手工补分区检查调度日志修复脚本磁盘使用率曲线异常陡增归档日志暴涨、临时文件膨胀、异常会话定位会话清理归档收缩临时文件表空间无法扩展数据文件达到MAXSIZE、文件系统已满增加数据文件或清理空间检查自动扩展上限删了大量数据但空间没释放数据文件未收缩、采用高水位标记RESIZE数据文件或收缩表空间默认分区数据量异常分区维护链路断了数据落入兜底分区修复自动化流程拆分默认分区数据巡检脚本无告警脚本自身挂了、告警通道失效优先解决脚本可观测性补充第二告警通道这个表格我建议直接打印出来贴在工位上遇到对应现象先按表格动作处理再深挖根因。紧急时刻人的判断力会下降有一张明确的操作清单能帮助稳定节奏。5.2 脚本和流程设计中的避坑经验写分区维护脚本和空间清理脚本我有几个经验可以分享第一脚本必须记录日志。这一点怎么强调都不过分。没有日志的脚本等于没有监控。所有自动任务的执行结果要落到独立的日志文件并且日志要有级别、时间戳、执行sql、返回码。之后做故障还原时日志是唯一的客观依据。第二任务调度要支持重试和幂等。脚本内部先检查元数据再执行DDL所有反向操作要考虑清楚。定时任务如果失败要有自动重试机制但重试之前要判断是不是已经有其他节点执行成功了避免重复执行产生冲突。第三告警永远要有两级。一级是预警比如“未来3天没有分区”“文件系统使用率超过85%”留给团队处理时间二级是严重告警比如“分区缺失已经导致写入失败”“空间使用率超过92%”必须立即响应。两级阈值不要都设得太近否则预警相当于没有。第四应急预案要定期演练。分区的应急预案不能只停留在文档层面至少每季度要做一次模拟演练人为把某个分区表的最大分区删掉然后按预案恢复计时看多久能恢复写入人为把文件系统写满看告警能否触发、清理流程能否执行。演练没过关的预案就不算预案。5.3 我的一些额外建议最后聊点个人心得。第一点是把空间和分区放在一个责任域里管理。很多团队把“磁盘空间”归系统管理员管“分区表维护”归DBA管出了事两边互相推。实际上两者是同一个故障链的两端最好由同一个人或同一个小团队统一负责运维DBA不要只盯着SQL和索引还要管好数据生命周期里的容量规划。第二点是在容量规划里留出缓冲。不要按“当前日增长 × 365”算一年的总空间然后只买这么多。业务增长是非线性的、批量任务有波峰、数据归档可能延迟。我给业务方报空间容量时通常按照预计增长的1.5倍到2倍去规划宁可多预留一些也不要在关键促销或结算日被磁盘卡住。第三点是自动化是主线但人要留一手。就算巡检、预创建、告警、扩容全部自动化了也一定要有一个懂的人知道每一步的原理知道这些脚本万一全挂了该怎么办。运维工作不是把一切交给工具就完了工具只是人的延伸。打个比方分区维护和空间预案就像是给数据库买了一份“保险”。买保险不是为了出险而是为了出险时不至于裸奔。你家里装了防盗门出门还是会反锁数据库有了预案日常还是要盯监控。真正的稳定从来不是靠某一次完美操作而是靠一整套能在故障发生前就提前预判、在故障发生时快速兜底的机制。下次再遇到分区缺失或者磁盘写满的问题别急着在群里问“怎么办”先把这套护流程跑一遍你会发现大部分坑早就被填平了。
