KES 定时任务与作业调度sys_cron扩展、作业配置与自动化运维前言定时任务是数据库运维里省人力的关键手段很多DBA头疼的就是那些重复性的日常操作日志清理、统计信息更新、历史数据归档全靠人肉执行的话既容易忘也占时间。去年完成的一个自动化改造项目让我对KingbaseES的定时任务能力有了更全面的认识。整个改造过程中通过部署sys_cron扩展、梳理日常作业清单DBA每周节省了大约6小时的手工操作时间漏执行的事故降到了零。作业创建、调度配置、执行监控这些环节KES都有完整的方案。这篇文章我想把自己在作业调度方面使用KES的经验分享给大家重点讲解作业怎么创建、怎么管理、失败了怎么排查。希望能给还在手工跑脚本的朋友一些参考。一、sys_cron扩展安装定时任务在KES里靠sys_cron扩展实现先把扩展装好后面的作业都基于它。安装与启用扩展装在每个库上装一次就能用。-- 先确认扩展可用默认随数据库一起发布SELECT*FROMsys_available_extensionsWHEREnameLIKE%cron%;-- 在目标数据库里创建扩展CREATEEXTENSION sys_cron;-- 验证装好了SELECTextname,extversionFROMsys_extensionWHEREextnamesys_cron;装完扩展后作业元数据存在sys_cron模式下的几张表里。有个细节要注意作业默认以创建者的权限执行建作业用什么账号作业就有什么权限。生产环境我习惯专门建一个cron_user账号只授需要的权限别图省事用超级用户。调度语法sys_cron用的是标准cron表达式五段式第一次接触的话对着表写就行。-- 典型的调度时间对着改就行-- 每天凌晨2点 0 2 * * *-- 每小时第30分钟 30 * * * *-- 每周一早上6点 0 6 * * 1-- 每月1号零点 0 0 1 * *-- 每5分钟一次 */5 * * * *-- 简写语法也支持不想记cron符号的用这个-- 每分钟 1 minute-- 每小时 1 hour-- 每天一次 1 day-- 每周一次 1 week二、作业创建装好扩展接下来把日常操作一条条建成作业。基础作业数据清理类任务最适合先上手。之前接手过一个库日志表三年没人清理膨胀到900多GB磁盘三天两头报警。建了清理作业之后磁盘占用稳定在60GB左右再没报警过。-- 每天凌晨2点清理30天前的日志SELECTcron.schedule(job_clean_logs,-- 作业名0 2 * * *,-- 调度时间$$DELETEFROMoperation_logWHERElog_timeCURRENT_TIMESTAMP-INTERVAL30 days$$);-- 查看已创建的作业SELECTjobid,schedule,command,database,username,activeFROMcron.job;作业创建函数返回一个jobid后面管理作业全靠它。创建时建议都起个一眼能看懂的名字后面排查问题的时候job_clean_logs比job_15友好太多。多类型作业运维里的高频操作基本都能建成作业。-- 每天凌晨3点更新统计信息慢查询的常见原因就是统计信息过期SELECTcron.schedule(job_analyze,0 3 * * *,$$ANALYZE$$);-- 每周日凌晨做历史数据归档SELECTcron.schedule(job_archive_orders,0 4 * * 0,$$INSERTINTOorders_historySELECT*FROMordersWHEREorder_dateCURRENT_DATE-INTERVAL90 days$$);-- 每天导出前一天的汇总数据给业务方SELECTcron.schedule(job_daily_report,30 6 * * *,$$COPY(SELECT*FROMdaily_summaryWHEREstat_dateCURRENT_DATE-1)TO/data/report/daily_report.csvWITH(FORMAT csv)$$);-- 归档完顺手把主表里的旧数据删掉每周日凌晨业务最低峰SELECTcron.schedule(job_purge_orders,30 4 * * 0,$$DELETEFROMordersWHEREorder_dateCURRENT_DATE-INTERVAL90 days$$);三、作业管理作业建好不是就完事了日常的查看、调整、停用都少不了。查看与调整作业信息集中在cron.job表里改调度时间直接UPDATE。-- 看全部作业和状态SELECTjobid,jobname,schedule,active,database,usernameFROMcron.jobORDERBYjobid;-- 调整调度时间比如清理任务从凌晨2点改到1点UPDATEcron.jobSETschedule0 1 * * *WHEREjobnamejob_clean_logs;-- 临时停用保留配置先不跑UPDATEcron.jobSETactivefalseWHEREjobnamejob_daily_report;-- 重新启用UPDATEcron.jobSETactivetrueWHEREjobnamejob_daily_report;-- 彻底删除作业SELECTcron.unschedule(job_clean_logs);停用和删除的区别要记牢active设成false只是暂停作业配置还在随时能启回来unschedule是真删了想恢复只能重建。版本发布窗口我一般把作业批量停用窗口结束再统一启用。执行记录每次作业跑完都有记录排查失败全靠它。-- 最近的执行记录重点看status和return_messageSELECTjobid,status,return_message,start_time,end_timeFROMcron.job_run_detailsORDERBYstart_timeDESCLIMIT20;-- 只看失败的SELECTjobid,status,return_message,start_timeFROMcron.job_run_detailsWHEREstatussucceededORDERBYstart_timeDESCLIMIT10;-- 结果示例-- jobid | status | return_message | start_time-- 5 | failed | division by zero | 2026-09-28 02:00:03-- 5 | succeeded | 1 row deleted | 2026-09-27 02:00:01-- 3 | succeeded | UPDATE 1000000 | 2026-09-28 03:00:05return_message这一列特别有用作业里的SQL报了什么错原文都在里面多数问题看一眼就知道原因。比如上面jobid为5的作业division by zero说明SQL里有除零问题直接定位到代码。四、失败处理与监控作业没人盯着跑失败通知机制必须建起来。失败原因排查常见的失败就那么几类各有各的解法。-- 情况1作业依赖的表被改名/删除作业里SQL失效-- 排查看return_message里的报错对象名SELECTreturn_message,start_timeFROMcron.job_run_detailsWHEREjobid5ANDstatusfailedORDERBYstart_timeDESCLIMIT3;-- 情况2作业执行账号权限被回收-- 排查手工切到该账号执行同样的SQL试试SETROLE cron_user;SELECTCOUNT(*)FROMoperation_log;-- 情况3作业和备份窗口撞车锁等待超时-- 处理错开调度时间避开备份和批处理高峰UPDATEcron.jobSETschedule0 5 * * *WHEREjobnamejob_analyze;踩过一次印象很深的坑客户反馈统计作业一直没生效报表还是慢。查了半天发现作业时区配置不对设置的凌晨3点实际跑在了中午业务高峰——作业本身成功了但ANALYZE在高峰期跑反而添乱还被DBA当成异常连接杀掉过。时区这事装完扩展第一件事就该确认。失败告警作业失败的记录配合监控查询就能做主动通知。-- 供监控平台采集的失败作业统计SELECTjobid,COUNT(*)ASfail_count,MAX(start_time)ASlast_fail_timeFROMcron.job_run_detailsWHEREstatusfailedANDstart_timeCURRENT_TIMESTAMP-INTERVAL1 dayGROUPBYjobidHAVINGCOUNT(*)0;-- 连续失败的作业更要重视偶发失败和持续失败是两码事WITHrecent_runsAS(SELECTjobid,status,ROW_NUMBER()OVER(PARTITIONBYjobidORDERBYstart_timeDESC)ASrnFROMcron.job_run_details)SELECTjobid,statusFROMrecent_runsWHERErn3ANDstatusfailedGROUPBYjobid,statusHAVINGCOUNT(*)3;监控平台轮询第一条查询捞到数据就触发告警。第二条更狠一点连续三次失败才报过滤掉偶发抖动我们生产上用的是这个策略告警量少了但每条都值得看。五、实战案例去年完成的一个自动化改造项目很好地验证了KES定时任务能力的价值。项目背景一个保险公司的业务系统数据量8000万。运维团队只有两个DBA日常的日志清理、归档、统计信息更新全靠手工脚本每周花在重复操作上的时间超过10小时还出过两次漏执行导致的故障。改造过程通过梳理运维现状发现当时的问题集中在三类日志清理、统计信息更新靠人工提醒忘过好几次历史数据归档每月手工执行占用周末时间作业失败没人知道都是业务受影响后才发现针对这些问题我们做了改造部署sys_cron扩展建专用执行账号清理、归档、ANALYZE等6项操作全部建成作业接入监控告警失败主动通知值班人改造效果改造后运维效率明显改善DBA每周节省手工操作时间约6小时漏执行事故全年为零作业失败响应时间从天级降到分钟级# 改造项目数据# 数据量8000万# 作业数量6个# 改造时间3天# DBA每周节省6小时# 漏执行事故0# 磁盘占用从920GB降到60GB日志清理作业客户反馈最直观的变化是磁盘报警消失了DBA终于能把时间花在性能优化这些有价值的事情上而不是每天惦记着跑脚本。总结与展望通过实际项目的应用KES在定时任务与作业调度方面确实有自己的优势。sys_cron扩展安装简单作业管理方便执行记录完整。特别是对于人手紧张的运维团队把重复操作作业化是最划算的投入。对于还在手工跑脚本的朋友来说建议从日志清理这类最简单的作业入手跑稳了再逐步把归档、统计信息更新这些迁过来。作业化的节奏可以慢但方向值得坚持。当然每个系统的运维习惯不一样作业清单也要结合自己的实际来定。但从经验来看失败告警这一环千万别省作业跑失败了没人知道等于没做。如果你也在做运维自动化欢迎交流讨论分享经验。