不能直接用存储过程“自动”巡检，因其无调度、告警、日志归档和跨库联动能力；需将其作为校验引擎，集成到dbms_scheduler或外部调度器中实现真正自动化。
不能直接用存储过程“自动”巡检——它没有调度能力，也不自带告警、日志归档或跨库联动能力。真正能落地的方案，是把存储过程作为校验引擎，套在 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 HAVING 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;
注意点：
- 用子查询 +
HAVING，别用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 和业务方都愿意去看、能快速定位、知道谁来跟进——这需要日志结构清晰、失败信息带上下文、且和现有运维通道（如企业微信机器人）打通。存储过程只管“查得对不对”，剩下的，得靠设计。
