存储过程直接拿来当自动巡检工具？不行。它没有自带的调度能力，也不管告警、日志归档或者跨库联动。真正能落地的方式，是把存储过程当作校验引擎，然后套在 DBMS_SCHEDULER 或者外部调度器（比如 cron + Python）里跑起来。
为什么不能只靠存储过程做“自动化”
存储过程说穿了就是个封装SQL逻辑的容器，跑完就退出，不持久、不记录、也不主动通知。你写一个 check_data_integrity 过程，手动调一次没问题；但要每天8点自动跑、失败了往钉钉发消息、结果存到表里、历史记录随时能翻——这些全得靠外部机制来补。
常见的误操作有哪些？
- 把所有逻辑一股脑塞进一个大存储过程，结果没法分段调试，出错了也难定位
- 用
DBMS_OUTPUT.PUT_LINE打结果，但没人盯着输出窗口，等于没报 - 忽略异常处理，某张表不存在导致整个巡检中断，后面的检查全被跳过
必须搭配 DBMS_SCHEDULER 才算真自动化
DBMS_SCHEDULER 是 Oracle 的原生调度器，比老旧的 DBMS_JOB 靠谱得多，自带日志、依赖、失败重试和状态查询。关键不是“能不能跑”，而是“跑完了有没有反馈”。
实操要点：
- 先建日志表：
CREATE TABLE dq_check_log (id NUMBER GENERATED BY DEFAULT AS IDENTITY, check_name VARCHAR2(100), status VARCHAR2(10), msg CLOB, run_time DATE) - 巡检过程末尾必须插入日志，哪怕只是
INSERT INTO dq_check_log VALUES ('not_null_check', 'OK', NULL, SYSDATE) - 调度作业要设
LOGGING_LEVEL => DBMS_SCHEDULER.LOGGING_FULL，否则失败堆栈都查不到 - 别用
START_DATE => SYSTIMESTAMP写死时间，改用REPEAT_INTERVAL => 'FREQ=DAILY; BYHOUR=8; BYMINUTE=0'
数据质量校验逻辑怎么写才不翻车
别一上来就“查所有空值”，先盯住高频风险点：主键重复、必填字段为空、外键悬空、数值越界、日期逻辑矛盾。每类单独封装成小过程，方便随时启用/禁用。
看个例子：检查订单表 order_id 是否存在重复
CREATE OR REPLACE PROCEDURE check_order_id_uniqueness AS v_cnt NUMBER;BEGIN SELECT COUNT(*) INTO v_cnt FROM ( SELECT order_id FROM orders GROUP BY order_id HA VING COUNT(*) > 1 ); IF v_cnt > 0 THEN INSERT INTO dq_check_log VALUES ('order_id_uniqueness', 'FAIL', 'Found ' || v_cnt || ' duplicate order_id', SYSDATE); ELSE INSERT INTO dq_check_log VALUES ('order_id_uniqueness', 'OK', NULL, SYSDATE); END IF;EXCEPTION WHEN OTHERS THEN INSERT INTO dq_check_log VALUES ('order_id_uniqueness', 'ERROR', SQLERRM, SYSDATE);END;
几个小细节：
- 用子查询 +
HA VING，别用COUNT(*) OVER(PARTITION BY ...)—— 大表上会扫全表两遍 - 所有
INSERT INTO dq_check_log必须在同一个事务里提交，否则日志可能丢了 - 别在过程里 COMMIT；由调度作业控制事务边界，否则整个巡检批次没法回滚
容易被忽略的收尾动作
巡检不是跑完就完事。真正卡住运维效率的，往往是结果没人看、问题不闭环。
必须做的三件事：
- 定期清理
dq_check_log表（比如保留90天），否则几年后这张表自己就成了性能瓶颈 - 给关键失败项加索引：
CREATE INDEX idx_dq_log_fail ON dq_check_log(check_name) WHERE status = 'FAIL' - 暴露视图供 BI 工具拉取：
CREATE VIEW dq_summary AS SELECT check_name, MAX(run_time) last_run, COUNT(*) fail_count FROM dq_check_log WHERE status = 'FAIL' GROUP BY check_name
说到底，最麻烦的从来不是写校验逻辑，而是让 DBA 和业务方都愿意去看、能快速定位、知道谁来跟进——这需要日志结构清晰、失败信息带上下文、而且和现有运维通道（比如企业微信机器人）打通。存储过程只管“查得对不对”，剩下的，得靠设计。
