数据库管理员理应获得更好的解决方案：超越脚本和仪表板

现在是凌晨两点。一个关键的生产系统开始放缓。警报响起，仪表板变成红色，但没有明显原因。数据库管理员 (DBA) 连接、检查日志，发现存在影响性能的重大数据库死锁。他们争分夺秒地诊断问题，运行多个脚本，检查命令行输出，解读原始数据并拼凑零散的信息。几个小时过去了，问题才得到完全理解和解决。

如果你从事过企业数据工作，你可能经历过这样的时刻。

最近一项针对 30 多位经验丰富的数据库管理员的非正式调研*显示：

• 62% 的人表示他们每天使用 3-4 种不同的工具来管理环境
• 64% 的人认为他们的脚本编写方法是非集中式、次优或混乱的
• 绝大多数受访者认为性能故障排除是最耗时的环节——不是调整或维护，而是实时诊断和解决问题

在大多数数据库管理员的工作环境中，可观测性、自动化、脚本编写和文档编写都位于完全独立的系统中。工具之间互不沟通。警报、日志和查询之间失去了联系。结果如何？即使是简单的问题也需要人工关联和深厚的历史知识才能解决。

这种工具碎片化不仅效率低下，而且风险很大。环境越复杂，设置就越脆弱。小问题会像滚雪球一样越滚越大。新 DBA 的入职流程既缓慢又容易出错。资深 DBA 把时间都花在了救火上，而不是提高性能或推动战略。

“不仅仅是解决问题所需的时间。还需要时间来弄清楚首先应该关注什么。”一位资深 DBA 调查受访者说道。

虽然碎片化并非新鲜事，但如今的现实情况使这个问题变得迫在眉睫。数据库环境（例如 IBM Db2）不再局限于集中式的本地部署服务器。云架构和混合架构增加了复杂性。与此同时，工作量的扩大也增加了出现性能瓶颈和异常情况的可能性。安全性、合规性和正常运行时间的要求日益严格，留给被动管理的空间就更少了。

从根本上说，DBA 的角色在不断发展。团队需要以更少的资源取得更多的成果，并将其工作重心从战术行动转向战略性监督。

生成式 AI 为一种新型工具打开了大门——但要明确一点：拥有大语言模型并不足以使其发挥作用。当 AI 深深植根于上下文时，它在数据库管理方面就可以发挥重要作用：Db2 内部逻辑、历史使用模式、实时指标以及 DBA 日常工作流的实际情况。如果没有这些信息，LLM 只会沦为另一种干扰，提供含糊不清的建议、错误的答案，或者更糟糕的是有风险的建议。

这些限制意味着面向 DBA 的 AI 工具必须不仅仅是通用的聊天机器人。对 Db2 和 DBA 工作流都有深入了解的专家必须精心设计和微调 AI 工具，才能使其有效发挥作用。

在最近的一项调查¹中，30 多位 Db2 高级管理员强调了他们在人工智能辅助方面的首要任务。他们的回答清晰而一致：

• 可直接提升工作量性能的查询优化建议
• 通过根本原因分析缩短从检测问题到解决问题的时间
• 异常检测和配置建议，以主动发现风险和优化方案

数据库管理员并不要求采用通用 AI，他们要求工具能够帮助他们更快、更有信心地完成其已经在做的事情。

如果运用得当，AI 并不会取代 DBA 的判断，而是会扩展这种判断，从而节省时间并提高准确性。反之，只会增加调试工作量。

试想以不同的方式管理数据库环境。 与其在凌晨 2 点进行混乱的故障排除，不如设想一个综合的解决方案，在您需要时主动提供所需的信息。DBA 可以立即查看相关日志、查询和可操作的建议，无需再花费数小时在分散的文档或消息应用程序对话中查找信息。

常规但重要的任务，例如执行备份、架构更新和修补，可以可靠地自动运行。数据库调整可以变得主动、智能，在用户注意到问题之前就提供查询优化、索引改进和资源平衡方面的建议。

如果您的数据库能够全天候自我监控，在出现异常情况并导致中断之前提醒您，会怎么样？

在这一愿景中，得益于利用嵌入式专家知识的工具的支持，新 DBA 的入职培训只需数周，而非数年。您会拥有一个集成的操作层，作为管理 Db2 的统一工作空间，而不是使用数十个互不关联的工具。

这一愿景不是某种假设的未来状态，而是数据库管理应该如何运作的问题。

如果您对这些问题感同身受，请联系我们。或者预订会议，以便更好地进行数据库管理。