1. 为什么需要开启达梦数据库的SQL日志记录在数据库的日常运维和开发工作中我们经常会遇到一些“灵异事件”某个查询昨天还跑得好好的今天突然就慢如蜗牛一个核心业务功能在测试环境一切正常上了生产却间歇性报错或者更头疼的是数据莫名其妙被修改了却找不到是谁、在什么时候、通过什么语句操作的。当这些问题发生时如果没有一份详尽的“操作录像”排查工作无异于大海捞针。而SQL日志就是数据库的“黑匣子”它忠实记录了所有进出数据库的SQL语句及其执行上下文。对于达梦数据库DM Database而言开启SQL日志记录通常指AUDIT_TRAIL或SVR_LOG相关功能不是一个可选项而是保障系统可观测性、安全审计和性能诊断的基石。尤其在企业级应用中它至少能满足三大核心需求安全审计满足等保、行业规范对数据操作留痕的强制要求问题排查快速定位慢查询、错误语句和异常连接的根源行为分析了解应用系统的真实SQL模式为优化和架构调整提供数据支撑。我见过太多团队在出事后才慌忙翻找日志配置结果发现根本没开或者只开了错误日志丢失了最关键的SQL文本追悔莫及。因此无论你是DBA、开发还是架构师把达梦的SQL日志配置明白应该是上线前 checklist 里的必选项。2. 达梦SQL日志记录的核心机制与配置选型达梦数据库提供了多种日志记录机制它们各有侧重不能混为一谈。新手最容易犯的错误就是以为开了“日志”就万事大吉实际上没选对类型记录的信息根本没用。我们需要根据目标选择正确的工具。2.1 语句级日志SVR_LOG与审计日志AUDIT的区分这是两个最常用但最易混淆的概念。你可以把它们理解为“行车记录仪”和“交警执法记录仪”的区别。SVR_LOG服务器日志 更像是系统的“诊断日志”。它主要记录达梦数据库服务器运行过程中的事件比如启动关闭、检查点、会话登录登出、SQL语句的执行情况成功与否、耗时以及错误信息。它的核心目的是运维监控和性能分析。通过分析SVR_LOG我们可以找出哪些SQL慢慢SQL日志是其子项系统在什么时间点负载高以及出现了哪些运行错误。AUDIT审计日志 这是专门为了安全与合规设计的。它记录的是对数据库对象如表、视图、过程或特定操作如INSERT, UPDATE, DELETE, SELECT的访问企图无论成功与否。审计可以非常精细例如可以只审计某个用户对某张表的DELETE操作。审计日志会详细记录操作者、操作时间、操作对象、使用的SQL语句、操作结果成功/失败以及客户端信息等。它主要用于事后追溯和满足安全法规要求。简单来说如果你想分析“为什么系统慢了”你应该关注SVR_LOG特别是其中的慢SQL日志。如果你想搞清楚“谁动了我的数据”那么你必须配置AUDIT。2.2 关键参数解析INI文件与动态视图达梦的配置主要存储在dm.ini参数文件和一些动态性能视图中。与SQL日志相关的关键参数如下1. SVR_LOG 相关参数 (在 dm.ini 中)SVR_LOG 总开关。0表示关闭1表示开启。这是所有语句日志记录的前提。SVR_LOG_FILE_SIZE 单个日志文件的大小限制单位MB。当日志写满这个大小后会滚动到下一个文件。需要根据日志量合理设置太小会导致文件频繁切换太大会导致单个文件过大难以分析。SVR_LOG_FILE_NUM 保留的日志文件数量。达到数量后最旧的文件会被覆盖。这决定了你能回溯多久的历史。SQL_TRACE_MASK这是一个极其重要的参数用于过滤记录哪些SQL语句。它是一个位掩码常用值包括1: 记录慢SQL执行时间超过SV_LOG_SLOW_MS定义的阈值。2: 记录执行失败的SQL。4: 记录执行成功的SQL。8: 记录绑定参数的值对分析问题至关重要。通常在生产环境为了平衡性能和记录需求可以设置为3(12即只记录慢SQL和错误SQL)。在问题诊断阶段可以临时调整为7(124) 甚至15来记录更多信息。SV_LOG_SLOW_MS 定义“慢SQL”的阈值单位毫秒。执行时间超过此值的SQL会被记录当SQL_TRACE_MASK包含1时。2. AUDIT 相关配置审计的开启和策略设置不主要通过dm.ini而是通过SQL命令来管理。核心的系统过程包括SP_SET_ENABLE_AUDIT(): 全局启用或禁用审计功能。SP_AUDIT_STMT(): 设置语句级审计策略。例如SP_AUDIT_STMT(ALL, USER1, ON)表示对用户USER1的所有SQL语句开启审计。SP_AUDIT_OBJECT(): 设置对象级审计策略。例如SP_AUDIT_OBJECT(DELETE, USER1, TABLE1, ON)表示审计用户USER1对表TABLE1的DELETE操作。审计记录默认存储在数据库的SYSAUDITOR模式下的相关表中也可以配置为写入操作系统文件。注意 开启审计尤其是全量审计会对数据库性能产生显著影响并快速产生大量日志。务必根据实际安全需求制定精细化的审计策略避免“一刀切”。3. 手把手配置从零开启并验证SQL日志理论讲完了我们进入实战环节。假设我们有一个新的达梦数据库实例目标是开启SVR_LOG用于性能监控并针对关键表设置审计。3.1 配置 SVR_LOG语句级日志步骤一检查当前状态首先连接到数据库查看当前的SVR_LOG配置。-- 查询动态视图确认SVR_LOG是否开启 SELECT * FROM V$PARAMETER WHERE NAME LIKE SVR_LOG%; -- 查询SQL_TRACE_MASK等参数 SELECT * FROM V$PARAMETER WHERE NAME IN (SQL_TRACE_MASK, SV_LOG_SLOW_MS);如果SVR_LOG的VALUE为0则表示未开启。步骤二修改参数文件dm.ini达梦的参数修改通常有两种方式直接修改dm.ini文件需重启生效或使用SP_SET_PARA_VALUE()过程动态修改部分参数立即生效或重启生效。对于生产环境建议先在测试环境修改dm.ini然后重启验证。找到数据库实例的dm.ini文件通常在/dmdata/DAMENG/目录下Windows则在安装目录的data/DAMENG/下。使用文本编辑器如vim, notepad打开找到相关参数行进行修改SVR_LOG 1 # 开启服务器日志 SVR_LOG_FILE_SIZE 1024 # 单个日志文件1024MB SVR_LOG_FILE_NUM 20 # 保留20个日志文件 SQL_TRACE_MASK 3 # 记录慢SQL和错误SQL SV_LOG_SLOW_MS 1000 # 定义慢SQL阈值为1000毫秒1秒保存文件并重启达梦数据库服务。# Linux 系统假设服务名为 DmServiceDMSERVER systemctl restart DmServiceDMSERVER # Windows 服务在服务管理器中重启步骤三动态修改可选用于临时诊断如果问题正在发生需要立即抓取日志可以动态开启并调整记录级别。注意SVR_LOG参数本身不能动态从0改为1但可以在已开启的基础上动态调整SQL_TRACE_MASK。-- 假设SVR_LOG已为1动态调整SQL_TRACE_MASK为7记录慢、错、成功SQL立即生效 SP_SET_PARA_VALUE(2, SQL_TRACE_MASK, 7); -- 动态调整慢SQL阈值立即生效 SP_SET_PARA_VALUE(2, SV_LOG_SLOW_MS, 500);这里的第一个参数2表示SESSION级别立即生效。1表示IN FILE级别需要重启。步骤四验证与查看日志配置生效后SVR_LOG会生成在dm.ini所在目录的../log/子目录下例如/dmdata/DAMENG/log/文件名通常为dm_DMSERVER_20241127.log这样的格式。 你可以使用tail命令实时查看或下载后用文本工具分析。tail -f /dmdata/DAMENG/log/dm_DMSERVER_20241127.log日志条目示例2024-11-27 10:23:45.123 (EP[0x7f8a1b7fc700] SESSION_ID: 1234 USER: SYSDBA APP: DIsql CLI_IP: 192.168.1.100) [慢SQL]执行耗时: 2345 ms, SQL语句: SELECT * FROM VERY_LARGE_TABLE WHERE ... 2024-11-27 10:24:01.456 (EP[0x7f8a1b7fc700] SESSION_ID: 1234 ...) [错误]语句执行失败错误码: -5004, SQL语句: UPDATE TABLE_X SET ID NULL WHERE ...3.2 配置 AUDIT审计日志步骤一启用审计功能首先需要以具有AUDIT DATABASE权限的用户如SYSAUDITOR或SYSDBA登录开启全局审计开关。-- 启用审计 SP_SET_ENABLE_AUDIT(1);步骤二配置审计策略我们针对一个重要的用户APP_USER对其拥有的核心表CORE_TABLE的所有DML操作进行审计。-- 审计 APP_USER 对 CORE_TABLE 的所有 INSERT, UPDATE, DELETE 操作 SP_AUDIT_OBJECT(INSERT, APP_USER, CORE_TABLE, ON); SP_AUDIT_OBJECT(UPDATE, APP_USER, CORE_TABLE, ON); SP_AUDIT_OBJECT(DELETE, APP_USER, CORE_TABLE, ON); -- 如果需要审计 SELECT 操作在高安全场景下 SP_AUDIT_OBJECT(SELECT, APP_USER, CORE_TABLE, ON);步骤三查看审计记录审计记录存储在系统表SYSAUDIT.AUDITRECORDS中默认配置下。我们可以查询该表来验证。-- 以 SYSAUDITOR 用户登录查询 SELECT OPERATION_TIME, USERNAME, SCHNAME, TVNAME, OPERATION, SQL_TEXT, SUCC_FLAG, IP_ADDR FROM SYSAUDIT.AUDITRECORDS WHERE TVNAME CORE_TABLE ORDER BY OPERATION_TIME DESC LIMIT 10;这条查询会返回最近10条对CORE_TABLE表的审计记录包括操作时间、用户、模式名、表名、操作类型、完整的SQL语句、是否成功以及客户端IP。4. 日志分析实战从海量记录中定位问题日志开起来了但面对动辄几个G的文本文件或成千上万的审计记录如何快速找到有价值的信息这才是真正的挑战。4.1 SVR_LOG 分析技巧抓取慢SQL 这是最常规的分析。使用grep或文本编辑器的搜索功能查找“[慢SQL]”关键词。grep \[慢SQL\] dm_DMSERVER_*.log | head -20找到慢SQL后记录下完整的SQL文本和执行时间。接下来需要结合执行计划EXPLAIN进行进一步分析。定位错误高峰 统计错误码出现的频率可以快速发现系统性问题。grep \[错误\] dm_DMSERVER_20241127.log | awk -F 错误码: {print $2} | awk {print $1} | sort | uniq -c | sort -nr这个命令会统计当天日志中各种错误码出现的次数并按降序排列。如果某个错误码如连接相关的-6001突然暴增那就指明了排查方向。关联会话与用户 一条慢SQL或错误SQL的日志行里包含了SESSION_ID和USER。你可以用SESSION_ID去关联V$SESSIONS等动态视图获取该会话的更多信息如当前状态、最后活跃时间、客户端程序等这对于定位由特定应用或用户引发的问题非常有用。4.2 AUDIT 日志分析与合规报告审计日志的分析更侧重于安全和行为分析。异常操作追溯 比如发现数据被异常篡改可以直接在AUDITRECORDS表中查询特定时间段内对目标表的所有UPDATE或DELETE操作结合IP_ADDR和USERNAME能迅速锁定可疑源头。SELECT * FROM SYSAUDIT.AUDITRECORDS WHERE TVNAME SALARY_TABLE AND OPERATION IN (UPDATE, DELETE) AND OPERATION_TIME BETWEEN 2024-11-26 18:00:00 AND 2024-11-27 09:00:00 AND SUCC_FLAG Y ORDER BY OPERATION_TIME;生成合规性报告 定期运行SQL查询统计关键操作的频率和分布形成报告。例如统计每月所有失败登录尝试SELECT DATE_TRUNC(MONTH, OPERATION_TIME) AS MONTH, USERNAME, IP_ADDR, COUNT(*) AS FAILED_ATTEMPTS FROM SYSAUDIT.AUDITRECORDS WHERE OPERATION LOGIN AND SUCC_FLAG N GROUP BY DATE_TRUNC(MONTH, OPERATION_TIME), USERNAME, IP_ADDR ORDER BY MONTH DESC, FAILED_ATTEMPTS DESC;4.3 使用第三方工具与脚本化对于长期运维建议将日志分析脚本化、自动化。日志收集 可以使用rsync或Logstash等工具将达梦服务器上的日志文件自动收集到中央日志服务器如ELK Stack进行集中存储和分析。监控告警 编写Shell或Python脚本定期如每分钟tail日志文件匹配“错误码: -6001”或“执行耗时: 10000 ms”等关键模式一旦发现就通过邮件、钉钉、企业微信等渠道发送告警。可视化分析 将SVR_LOG解析后导入到Grafana等可视化平台可以制作慢SQL趋势图、错误类型分布饼图等让问题一目了然。5. 性能影响、日志管理与常见避坑指南开启日志不是没有代价的。不当的配置会拖垮数据库性能或者让磁盘被日志塞满。5.1 性能影响与优化建议SVR_LOG 写入文件是I/O操作。当SQL_TRACE_MASK设置过高如记录所有成功SQL且并发量很大时I/O压力会剧增。建议生产环境默认只开慢SQL和错误SQL(SQL_TRACE_MASK3)。只有在诊断特定问题时才临时调高记录级别并尽快恢复。AUDIT 审计需要将记录写入数据库表会产生额外的磁盘写入和事务开销。建议务必实施精细化审计策略。不要动不动就SP_AUDIT_STMT(ALL, PUBLIC, ON)。只审计真正需要关注的核心资产和敏感操作。对于高频访问的表审计其所有SELECT操作可能带来不可接受的性能下降。通用建议 将日志文件无论是SVR_LOG文件还是审计表空间放在高性能的SSD磁盘上并且与数据文件、重做日志文件分盘存放减少I/O竞争。5.2 日志生命周期管理日志不管理磁盘两行泪。SVR_LOG文件滚动 依靠SVR_LOG_FILE_SIZE和SVR_LOG_FILE_NUM参数控制。假设每个文件1GB保留20个那么最多占用20GB磁盘空间。需要根据磁盘大小和保留时长需求来调整这两个参数。旧的日志文件会被自动覆盖。审计日志归档与清理AUDITRECORDS表会一直增长。达梦提供了系统过程来管理-- 将指定时间之前的审计记录归档到操作系统文件备份后可从表中删除 SP_AUDIT_EXPORT(‘2024-10-01 00:00:00’ ‘/opt/audit_backup/2024Q3.aud’); -- 删除指定时间之前的审计记录谨慎操作 SP_AUDIT_DELETE(‘2024-10-01 00:00:00’);务必制定定期的审计日志归档和清理计划例如每月初归档上个月的记录并删除半年或一年前的数据。归档文件要安全存储以备审计检查。5.3 常见问题与解决方案开启SVR_LOG后日志文件没有生成检查 确认dm.ini中的SVR_LOG1已生效重启后查看V$PARAMETER。确认数据库实例用户对日志目录有写权限。检查SQL_TRACE_MASK如果设置为0则即使开启SVR_LOG也不会记录任何SQL。审计策略不生效检查 首先确认SP_SET_ENABLE_AUDIT(1)已执行。其次确认执行审计策略配置的用户拥有足够的权限通常需要AUDIT ANY或AUDIT DATABASE。最后检查审计策略的语法对象名如表名、用户名是否大小写正确、是否存在。日志文件增长过快磁盘告警紧急处理 立即调整SQL_TRACE_MASK到一个更保守的值如从7调回3。清理旧的日志文件注意不要删除正在写入的当前日志文件。扩大SVR_LOG_FILE_NUM或减少SVR_LOG_FILE_SIZE以加速滚动覆盖。根治 分析日志内容是否因为误配置记录了过多不必要的SQL如大量简单查询。优化审计策略减少审计范围。如何分析加密的SQL语句在某些安全设置下SVR_LOG中的SQL语句可能被部分脱敏或加密。这时需要结合SQL_TRACE_MASK中包含8绑定参数的设置并可能需要联系达梦原厂支持获取更详细的解码方式。在测试环境尽量使用可解析的日志格式进行问题复现。配置和管理达梦数据库的SQL日志就像给数据库系统装上了全方位的监控探头。初期投入一些时间理解机制、制定策略在后续运维中带来的问题定位效率和安全性提升是巨大的。记住一个原则日志不是为了存而存是为了用而存。清晰的日志管理策略和高效的分析方法能让这些沉默的数据真正开口说话成为你保障系统稳定和数据安全的最得力助手。