共 3 篇相关文章
这篇讲的是《Oracle DBA手记II》中一个真实踩坑案例：一个看似无害的数据库参数 `Failed Login Count`，在高并发登录场景下，竟然导致了性能显著下降。 作者从一个生产环境性能突降的排查出发，锁定了异常的数据库等待事件。追踪发现，罪魁祸首是用于记录登录失败次数的统计功能。每当有用户（尤其是程序客户端）因密码错误等原因登录失败时，Oracle 会频繁更新这个统计信息，产生了大量行级锁竞争。在批量、并发的连接尝试下，这成了严重的性能瓶颈。 文章详细剖析了该问题的触发条件与根因，并给出了具体的解决方案——通过调整 `SEC_CASE_SENSITIVE_LOGON` 等参数或在特定时段调整统计策略，从而规避锁争用。这个案例生动地提醒 DBA 们，一些默认开启的、用于审计与监控的功能，在特定业务模式下可能悄然变为性能负担，需要结合实际负载仔细权衡其开关与粒度。
这篇讲的是如何用Oracle触发器实现对DELETE操作的轻量级审计。作者从实际的运维需求出发，帮朋友编写了一个简单但实用的解决方案。 核心实现思路很清晰：先创建一张审计表来存储删除记录的元数据，再编写一个行级触发器在DELETE操作发生时自动插入审计数据。触发器被设计为在每次删除操作触发一次（FOR EACH ROW），从而能逐条记录。记录的内容不仅包括了被删除数据的关键业务字段，还贴心地捕获了执行删除操作的数据库用户（USER）和精确到秒的系统时间（SYSDATE），为事后追溯提供了完整的信息链。 这个方案的巧妙之处在于其“四两拨千斤”的直接性——没有复杂的配置或依赖，仅用数据库原生的对象组合就实现了核心审计功能。它特别适合那些需要快速部署、对审计粒度要求明确（仅追踪删除操作），且追求维护简便性的场景。对于许多中小型项目或特定模块的数据保护来说，这种实现方式往往比启用全面审计或部署第三方工具来得更加轻便、高效。
这篇讲的是如何为MySQL配置审计日志，让每一次数据访问都“有迹可循”。作者从数据安全与合规的现实需求出发，指出仅仅依靠默认日志往往不够精细。文章核心介绍了MySQL官方审计插件的配置方法，比如如何按用户、按库、按操作类型来筛选和记录日志，并对比了通用查询日志、错误日志和慢查询日志在审计场景下的不同侧重。 特别值得关注的是，作者通过一个实际案例展示了审计日志的妙用：通过分析日志中的高频查询和特定时间窗口的异常连接，成功定位了一个因程序连接池配置不当导致的性能瓶颈。文章没有停留在配置命令的罗列，而是将日志数据与实际的运维排障场景结合起来，解释了这些记录到底“能用来干什么”。 最后，作者也坦诚地讨论了开启审计日志对性能的潜在影响，给出了在测试环境与生产环境进行差异化配置的实用建议。对于需要加强数据库管控或进行事后追溯的团队来说，这篇提供了清晰的配置路径和应用思路。
