1. 达梦数据库审计功能的整体设计思路
1.1 审计解决的是“事后追责”和“事前威慑”
数据库审计这三个字，很多 DBA 一听就觉得是“合规要求、安全部门来检查时用的”。说实话，它确实承载着合规功能，但实际用起来价值远不止那一份检查报告。我之前排障时遇到过一种情况：业务方坚称没有人改过数据，结果某张表的金额字段在深夜被批量更新了。在没有审计的情况下，你只能翻应用日志、问开发、查会话，费时费力。而达梦数据库自带的审计功能，可以帮你把“谁、在什么时间、从哪个客户端IP、执行了什么 SQL、操作了哪个对象”这类信息完整记录下来，相当于给数据库装了一台行车记录仪。
审计功能的核心价值可以拆成三层：
- 安全合规层：满足等保、行业监管和内部制度对数据库操作的审计要求。
- 安全问题定位层：当出现数据篡改、越权查询、误删除时，有据可查。
- 行为威慑层：使用者知道每一步操作都可能被记录，会下意识减少高风险操作。
对于正在做国产数据库迁移的团队来说，达梦的审计功能尤其值得提前熟悉。毕竟业务迁移到新库之后，原有数据库里“开箱即用”的审计习惯突然没了，心里会很没底。达梦在这个功能上做得比较完整，同时也保留了自己的设计逻辑，搞清楚它的运行机制，才能在生产环境里用得顺手。
1.2 达梦审计机制的运行模式
达梦数据库的审计流程可以从一条链路来理解：审计开关是整个机制的“总闸门”，开关不开，后面配什么规则都不生效；开关打开后，数据库会按用户配置的审计规则，把符合条件的操作封装成审计记录，先写入内存中的审计队列，再异步刷入审计文件；同时系统提供了一系列审计视图，可以从中查询已生成的审计记录。
这里要特别注意一个概念：达梦的审计行为和普通业务日志不一样，它不是把每条 SQL 都拿来做字符串匹配，而是由内核在 SQL 执行的关键路径上主动输出审计事件。因此它对规则的定义维度和匹配逻辑有严格要求。达梦通常把审计按三个维度组合：审计级别、审计对象、审计操作。级别决定审计的“颗粒度”，对象决定“盯着谁看”，操作决定“看什么动作”。三者组合不到位，要么记录的没用，要么有用的没记录，这也是很多新手配置审计后“查不到东西”的根本原因。
达梦审计功能还遵循了“职责分离”的思路，它不是由系统管理员一手包办，而是区分了三类管理角色：系统管理员负责数据库日常运行，审计员负责审计功能的开启、规则配置和记录查询，安全员负责安全策略和口令管理。三者权限相互独立，数据库管理员不能随意关闭审计或删改审计记录。这种设计能避免“既当运动员又当裁判员”的问题，在等保测评里是加分项，在实际运维中也确实能减少内部操作风险。
1.3 审计级别和对象的关键差异
在真正上手配置之前，得先把达梦审计规则里的几个关键维度搞清楚。
审计级别方面，达梦一般按用户和操作范围划分，实际使用中最常见的是“对所有用户审计”和“对指定用户审计”。比如你只想盯一个应用账号，那就没必要审计所有人，减少日志量同时也能降低对性能的影响。级别定义得越粗，记录量越大，排查时信噪比越低；定义得太细，又可能出现该记录的没记录。
审计对象方面，达梦覆盖了表、视图、存储过程、触发器这类常见数据库对象，也覆盖了登录、DDL、DML 等操作层面。使用时要理解一个关键差异：表级审计关注的是“这张表被谁操作了”，操作级审计关注的是“某类操作是否发生，触发者是谁”。实际场景往往需要两者配合。例如只配了操作级审计，没配表级审计，遇到“某张核心表被 DELETE”这种需求，就很难快速定位。
不同版本的达梦在审计功能细节上会有些差异，比如部分系统过程的参数名称、审计视图的字段命名，但整体框架是一致的。在动手配置前，建议先用你环境对应版本的手册核对一遍，后面看到的 SQL 示例都是以常见版本为基础的实践写法。
2. 开启审计前需要想清楚的配置项
2.1 用审计员账号而不是系统管理员账号
达梦的审计操作有严格的权限控制。配置审计功能时，需要先使用审计员账号登录，而不是系统管理员账号。这是很多初次接触达梦审计功能的人容易忽略的一点：拿着最高权限的管理员账号去执行开启审计的存储过程，结果报错“权限不足”，还以为是版本问题。
审计员账号在达梦中通常是初始化实例时创建的系统账号，也可以在后期由具有相应权限的账号创建。建议的项目实践是：审计员账号和系统管理员账号分开保管，分给不同的人负责。如果团队规模小，实在分不开，至少要保证账密不能明文贴在运维文档里，并且通过口令策略定期修改。
登录后可以先确认当前连接的账号是不是审计员角色，避免后续配置白忙一场。在测试环境里，我一般会把每个账号的角色权限打印出来核对一遍，这个习惯放到审计功能上同样适用。
提示：审计员账号的权限管理属于数据库安全体系的一部分，不要因为图省事就把审计员账号给应用 DBA 日常使用。一旦出问题，审计记录本身的公信力会大打折扣。
2.2 审计文件目录与空间规划
达梦开启审计后，审计记录会被写入审计文件。默认情况下这些文件放在数据库实例的数据目录附近，但生产环境强烈建议独立规划磁盘路径。原因有两个：第一，审计文件增长可能非常快，如果和数据库数据文件放在同一块盘，审计日志撑满磁盘会拖垮整个实例；第二，审计文件本身是敏感数据，需要独立的目录权限管控，避免普通用户直接访问。
配置审计文件路径的常见写法是通过系统过程设置，同时需要确保目标目录已经创建好，并且数据库进程对该目录有读写权限。设置完成后，最好检查一下参数是否生效，如果没有生效，可能需要重启实例或者按版本要求重新加载配置文件。
空间规划方面，我提供一个操作思路：先统计当前审计记录的平均大小，再估算业务高峰期每分钟会产生多少条审计记录。举个例子，如果一条审计记录平均约 500 字节，高峰期每秒产生 20 条记录，那么一天光是高峰期就可能产生约 800 多 MB 的数据，一周就是 5 到 6 个 GB。根据这个量级去规划磁盘空间和保留周期，比“先开了再说”稳妥得多。
另外还要关注单个审计文件的大小限制。达梦会把审计记录切分成多个文件，每个文件达到设定大小后自动切换到下一个。生产环境建议把单个文件设置得适中，太大不方便归档和排查，太小会产生大量碎片文件，管理起来也麻烦。
2.3 审计开关和审计记录保留策略
审计开关这一步操作很简单，本质上是执行开启审计的系统过程。但开完之后不要急着配一堆规则，先想清楚保留策略。
审计记录不能只记不清，会带来两个问题：一是磁盘空间被历史文件占满，二是排查问题时旧记录缺失。针对第一个问题，建议在规划阶段就定好“保留多少天、超过怎么处理”。很多单位会把审计文件定期转储到独立的审计服务器或对象存储，数据库本地只保留近期文件，这样既满足追溯需求，又避免磁盘压力。针对第二个问题，要明确审计文件的转储频率。最怕的情况是：真出事的时候想查三个月前的记录，结果本地文件早就满了没转储。
达梦提供了审计视图供查询，但视图中的数据来源同样受审计文件保留周期影响。日常监控时可以直接查视图，但要做长期归档，就不能只依赖视图，还要对审计文件本身做备份。把审计目录纳入备份任务里，定期把历史文件拷贝归档，是成本最低、效果最稳的做法。
3. 核心实操：按典型场景配置审计规则
3.1 一个具体的审计需求场景
为了把配置过程讲清楚，我拿一个模拟场景来走一遍全流程：
某业务系统的核心订单表存在被批量修改的风险，需要在数据库中记录所有对该表的数据变更；同时，应用账号的登录行为需要留痕，方便排查密码泄露或异常登录；另外，开发人员手动执行的 DDL 操作（比如 ALTER TABLE）也要记录，防止表结构被偷偷改动导致线上故障。
这个场景在国产数据库迁移项目里非常典型：核心业务表 + 登录行为 + 结构性变更。三个需求分别对应达梦审计中的表对象审计、操作审计和 DDL 审计。按这个思路去配置，不会出现规则相互覆盖或者漏配的问题。
3.2 对象级审计规则的配置与验证
第一步是给订单表配置增删改审计。达梦中常用的配置方式是调用审计对象操作的系统过程，这个过程会定义一个规则：哪些用户对哪个对象的哪种操作需要记录。
基于常见实践的示例写法如下：
-- 审计指定模式下订单表的插入、更新、删除操作，并记录执行失败的操作 SP_AUDIT_OBJECT('TABLE', 'APP_SCHEMA', 'CORE_ORDER', 'INSERT', 'ALL', 'FALSE'); SP_AUDIT_OBJECT('TABLE', 'APP_SCHEMA', 'CORE_ORDER', 'UPDATE', 'ALL', 'FALSE'); SP_AUDIT_OBJECT('TABLE', 'APP_SCHEMA', 'CORE_ORDER', 'DELETE', 'ALL', 'FALSE');这里最后一个参数表示“是否只审计成功操作”，实际使用中建议把成功和失败都记录下来。失败的操作往往比成功操作更有排查价值，比如有人反复尝试删表失败，这可能比一次成功删除更值得警惕。
规则配置好之后，用应用账号执行几条 INSERT、UPDATE、DELETE，再通过审计视图查询，能看到对应记录。如果查询结果为空，优先检查规则是不是真的生效，以及当前账号的操作是否被规则覆盖。
3.3 操作级和登录审计的配置技巧
接下来配置登录审计和 DDL 审计。登录审计通过操作级审计来实现，DDL 审计可以针对指定用户操作来配置。
基于常见实践的写法：
-- 审计所有用户的登录操作，成功失败都记录 SP_AUDIT_OPERATION('LOGIN', 'ALL', 'FALSE'); -- 审计指定账号的 DDL 操作，这里以 ALTER TABLE 为例 SP_AUDIT_OPERATION('ALTER TABLE', 'APP_DEV', 'FALSE');这里有个容易被忽视的技巧：操作级审计如果不指定用户，会对所有用户生效，日志量会明显上涨。实际场景中，如果只有少数开发人员有 DDL 权限，建议把审计对象限制到这几个账号，规则更精准，排查也更高效。
登录审计的返回信息里会包含客户端 IP、登录时间、登录账号、成功与否等关键字段。如果应用通过中间件访问数据库，大量请求会共用一个数据库账号，这时候登录审计只能看到同一个账号的频繁登录，定位具体业务用户还得靠应用侧日志配合。理解了这层限制，就不会对着审计记录里的同一账号大量登录记录发愁了。
规则都配好之后，我建议梳理一张规则清单，内容包括：规则类型、对象、操作类型、针对用户、生效时间、配置人。这张清单在后续排查“为什么这个操作没被审计到”时，能帮你快速排除规则覆盖问题。
4. 审计记录的查询排障与日常运维
4.1 快速查询审计记录的关键视图
达梦提供了一组以 DM_AUDIT 开头的审计视图，通过 SQL 就能查询审计记录。使用审计员账号登录后，可以直接查询。常见的视图包括审计记录总览视图、对象级审计记录视图和操作级审计记录视图。
一个基础的查询示例：
-- 查询最近的审计记录 SELECT USERNAME, IP, OPERATION, OBJ_NAME, SQL_TEXT, AUDIT_TIME, SUCCESS FROM DM_AUDIT_RECORD ORDER BY AUDIT_TIME DESC FETCH FIRST 100 ROWS ONLY;查询时需要注意几点：一是审计视图的字段在不同版本中可能存在差异，比如字段名大小写或者是否带 OBJ_NAME，需要结合环境实际调整；二是过滤条件要优先使用审计时间字段，避免全表扫描式查询把数据库会话拖慢；三是不要频繁对审计视图做大范围查询，审计数据量大时，建议先归档到单独的统计表或分析平台，再去做关联分析。
实际排查中，最常写的查询条件是“某个时间窗口内、某个账号、对某张表的某种操作”。把这三个条件组合好，基本能满足绝大多数溯源场景。
4.2 审计文件的管理与归档
审计记录落盘到审计文件后，文件本身的管理往往被人忽略。审计文件是二进制格式，直接用文本编辑器打开是一堆乱码，但这不代表不需要维护。文件管理的核心动作包括：
- 定期检查审计文件目录的磁盘使用率。
- 将超过保留周期的文件复制到归档存储。
- 归档完成后，再按策略清理本地过期文件。
归档操作建议用脚本或定时任务完成，不要手动去删除文件。尤其要注意：当前正在写入的审计文件不要强行删除或移动，否则可能导致审计功能异常，甚至影响实例运行。
这里分享一个实践细节：将审计文件目录设置为独立挂载点后，可以对该目录做快照或增量备份，方便追溯历史记录。如果审计要求特别严格，还可以考虑对归档文件做哈希校验，防止归档过程中文件损坏或被篡改。
4.3 审计功能对性能的影响
不少人在开启审计前最担心的就是性能问题。审计确实会有开销，因为每条被审计的操作都要额外生成审计记录，增加一次写入动作。但开销的大小和审计范围强相关，全库全量审计和只审计核心对象，差距可能在一个数量级以上。
建议的做法是分阶段实施：先在测试环境开启审计，压测对比开启前后的 TPS 和响应时间；再到生产环境先对少量核心对象开启，观察一段时间；最后再根据业务需求逐步扩大范围。我曾经见过一个系统，开启对所有表的 UPDATE 审计后，高峰期磁盘 IO 上升明显，后来改成只审计核心业务表，性能影响基本可以忽略，排查效果也没打折。
如果业务对性能要求极其苛刻，还可以考虑把审计文件放在独立的磁盘或存储上，避免和业务日志、数据文件抢 IO。
5. 踩坑实录：常见问题与排查思路
5.1 审计规则配置了却看不到记录
这是出现频率最高的问题。我总结下来主要有三类原因：
第一，总开关没开。审计开关没打开时，配置再多的规则也不会产生审计记录，先查一下审计开关状态。第二，规则覆盖范围不对。比如规则定义的是对 A 用户的审计，结果实际操作用的是 B 用户，自然没有记录。第三，规则被重复定义或者被禁用。有些版本中，如果同一规则已经存在，再次配置可能会报错或覆盖原有规则，需要先查一下现有规则清单。
排查这类问题时，我一般按这个顺序来：先确认开关状态，再确认规则清单，最后手动模拟触发一次操作并立刻查询审计记录。通过排除法很快就能定位问题。
5.2 审计文件快速增长与空间打满
审计日志增长过快，在生产环境是一个不可忽视的风险。常见原因包括：审计范围过宽、日志级别设置过度、系统存在自动化任务频繁执行被审计的操作等。比如某个定时任务每小时批量 update 一次表，如果审计规则覆盖了这张表的全部 update，一天下来审计量就可能远超预期。
解决办法分两步：先优化规则缩小审计范围；再制定空间监控和清理机制。磁盘使用率达到一定阈值时自动告警，运维人员及时归档并清理过期文件，避免审计功能反过来拖垮数据库。
5.3 审计时间不准与记录可信度问题
审计记录的可信度依赖数据库服务器时间。如果服务器时间漂移，审计记录里的时间就不可靠，追责时会出现“记录显示半夜操作，但业务方坚称当时没人值班”的争议。这个问题在跨节点、跨机房的架构里更容易出现。
建议部署统一的时间同步服务，确保数据库服务器的系统时间准确。同时，在归档审计记录时保留服务器时区信息，避免后续分析时因为时区换算产生偏差。这个细节在等保和内部审计中会被重点关注。
5.4 审计相关常见问题速查表
| 现象 | 可能原因 | 处理思路 |
|---|---|---|
| 开启审计时报权限不足 | 当前账号不是审计员角色 | 切换审计员账号登录 |
| 审计规则执行报错 | 规则已存在或参数格式不对 | 查询现有规则，调整参数后重试 |
| 配置后查不到审计记录 | 审计总开关未开启 | 先确认开关状态并开启 |
| 审计记录只有一部分操作 | 规则覆盖范围过窄 | 补充对象级或操作级规则 |
| 审计文件占用空间暴涨 | 规则范围过宽、自动化任务触发 | 缩小审计对象，清理过期文件 |
| 审计记录时间与实际不符 | 服务器时间漂移 | 统一时间同步服务，检查时区设置 |
| 审计文件被外部程序占用 | 文件正在写入中 | 避免手工删除写入中的文件 |
| 视图查询很慢 | 审计记录量大、全表过滤 | 用时间条件过滤，定期归档数据 |
数据库审计功能在实际项目中发挥的作用，往往比预期大得多。我第一次在生产环境完整体验这套流程时，感触最深的是：审计不是一个“开了就完事”的功能，它需要围绕业务场景持续调整规则、管理文件、验证效果。建议刚接触达梦的朋友，先在测试环境里把“配置规则、触发操作、查询记录、清理文件”这条完整链路跑一遍，不需要追求复杂的全量审计，只要把核心对象的操作留痕做好，遇到问题的时候就知道这套行车记录仪有多重要了。
