DBA-Bench：面向基于LLM的数据库操作代理的生产保真度基准

# 面向基于大语言模型的数据库运维代理的生产保真度基准  
来源：https://arxiv.org/html/2607.22165  

陈俊明，蒋俊阳  
电子科技大学，中国成都  
[email protected]  
陈旭  
电子科技大学，中国成都  
[email protected]  
梁子博  
电子科技大学，中国成都  
[email protected]  
郑凯  
电子科技大学，中国成都  
[email protected]  

###### 摘要。基于大语言模型（LLM）的数据库代理展现出前景，但不同的任务范围、测试平台和评价指标阻碍了比较。我们识别出评估与生产运维之间的四个差距：*在线环境保真度*（与运行中数据库进行多轮读写交互）；*观测空间规模与复杂度*（在数千条时间序列、业务日志和并发活动中进行因果诊断）；*解决方案空间开放性*（多种修复方案，具有不同运维权衡）；以及*场景复杂度与覆盖度*（故障在内部机制和运维域之间级联）。我们提出了 DBA-Bench，这是一个通过*生产保真度*、*结果优先评估*和*受控场景可复现性*来弥合这些差距的基准。它采用带有主动工作负载、持久状态和多源观测的仪表化 PostgreSQL 环境；通过可衡量的恢复或在安全约束下的故障消除来定义成功；并在每次运行前恢复带有场景特定检查的快照。该基准包含 106 个场景，涵盖七个任务域，并基于参考路径诊断深度和环境复杂度提供两个公开的难度标签。我们评估了九个基线组，包括六个基础模型系统、两个由 GPT-5.5 支持的数据库代理以及一个人类 DBA 参考。在 848 次自动化运行中，诊断通过率、结果通过率和安全通过率分别为 32.7%、19.6% 和 12.4%；最佳自动化基线达到 17.9% 的安全通过率，而人类 DBA 参考为 93.4%。自动化安全通过率从简单场景的 19.6% 下降到困难场景的 7.6%，突显了安全端到端修复的难度。  
数据库运维，LLM 代理，基准，故障诊断  
††版权：无  
††CCS：信息系统 数据库管理系统引擎  
††CCS：计算方法学 智能代理  

## 1. 引言  
数据库运维涵盖查询调优、故障恢复、模式更改等任务。它们在存在并发工作负载的在线数据库上展开，干预措施会改变环境，而针对症状的修复可能无法触及根本原因；例如，在过时统计信息和锁争用事件中，终止可见的阻塞者只能暂时清除等待。此类工作知识密集、持续且高风险，但经验丰富的数据库管理员（DBA）稀缺；因此，基于 LLM 的自主代理被探索为一种力量倍增器（Lao 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib7)；Singh 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib4)）。越来越多的基于 LLM 的数据库代理涌现以满足这一需求——D-Bot（Zhou 等人，2024b (https://arxiv.org/html/2607.22165#bib.bib1)）、DBAIOps（Zhou 等人，2026 (https://arxiv.org/html/2607.22165#bib.bib3)）、DBAgent（Chen 等人，2026a (https://arxiv.org/html/2607.22165#bib.bib2)）以及报告式顾问如 Panda（Singh 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib4)）和 GaussMaster（Zhou 等人，2025 (https://arxiv.org/html/2607.22165#bib.bib8)）——各自在其评估设置上报告了令人鼓舞的结果。这些系统追求不同的运维目标，因此其评估使用不同的任务范围、测试平台、度量和故障场景。据我们所知，目前没有共享的、可复现的评估环境，能够在受控故障条件下比较不同的数据库代理。因此，报告中数字难以直接比较，限制了衡量走向生产就绪进展的领域级测量。因此，问题不仅仅是没有共同的排行榜。一个有意义的基准必须保留与代理如何观察、行动和验证恢复相关的运维条件，并且必须根据代理操作所产生的数据库状态来评判代理。现有评估在四个维度上偏离这些要求。  

**差距 1：在线环境保真度。** 数据库运维是与运行中、可写系统进行的有状态交互，而非静态的输入-输出任务。在代理诊断故障时，工作负载继续进行，每个探测或修复——从终止会话到更改配置或运行维护——都可能改变锁、优化器状态、可用性以及下一轮中可见的证据。许多数据库代理评估强调诊断或推荐质量：环境可能被表示为任务状态，而提议的修复被估计、报告或路由到人工审批，而不是在环境中执行和验证（Zhou 等人，2024b (https://arxiv.org/html/2607.22165#bib.bib1)，2026 (https://arxiv.org/html/2607.22165#bib.bib3)；Chen 等人，2026a (https://arxiv.org/html/2607.22165#bib.bib2)；Singh 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib4)）。此类设置不能同时衡量代理能否安全更改在线数据库状态、适应其操作后果并验证恢复。  

**差距 2：观测空间规模与复杂度。** 生产事件并非与系统其他部分隔离。DBA 必须在数千条度量时间序列、密集的业务日志、查询计划、锁与会话活动、后台任务以及并发工作负载产生的信号中定位因果证据。通用代理基准通常实例化全新的、干净的数据库或紧凑的任务环境，其中很大程度上缺少无关活动和可能的竞争信号。此类环境可以测试任务在隔离中的执行，但消除了构成生产诊断难度的环境复杂度。在低噪声条件下评估的代理不需要区分因果故障与相关的工作负载活动或显著但误导的症状。  

**差距 3：开放解决方案空间。** 现实世界的修复很少有单一的正确答案；竞争性的修复方案差异不在于正确性，而在于运维权衡。考虑为繁忙表添加缺失索引：DBA 可以在维护窗口期间使用 CREATE INDEX，这完成得更快但会阻塞写入；或者使用 CREATE INDEX CONCURRENTLY，这保持写入可用但需要更长时间，若中断可能留下无效索引。两者都创建所需的访问路径；哪一个“合适”取决于可用性和维护约束。一些数据库代理评估止步于推荐答案，而不是执行候选修复并检查产生的系统状态（Zhou 等人，2024b (https://arxiv.org/html/2607.22165#bib.bib1)，2026 (https://arxiv.org/html/2607.22165#bib.bib3)；Singh 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib4)）。针对预设答案或操作进行评分无法识别其他有效路径或比较其运维风险。  

**差距 4：场景复杂度与覆盖度。** 生产数据库故障既多样化又复合。一个现实的升级链——过时统计信息导致次优查询计划，进而加剧锁争用，最终耗尽连接池——要求代理在追踪因果关系时穿越数据库内部的多个层次，直至找到真正的根本原因。处理表面症状（连接耗尽）而忽略上游触发因素（过时统计信息）是失败的诊断，无论即时症状是否暂时缓解。AIOpsLab（Chen 等人，2025c (https://arxiv.org/html/2607.22165#bib.bib25)）通过评估交互式微服务环境中的检测、定位、根因分析和缓解，提供了一个紧密相关的先例。数据库运维引入了一个补充性的评估范围，需要推理查询计划、锁、统计信息、存储和配置。此类环境的基准还必须跨越查询调优、系统故障恢复、常规健康维护、业务驱动的模式更改、资源治理、复合故障和误导性警报。  

综合来看，这些差距需要一个具有在线读写交互、大规模且嘈杂的运维环境、结果导向的支持开放解决方案以及多样化因果结构的基准。公平比较还要求每个代理遇到等效的因果故障和运维上下文，同时保留在线系统的运行时变化。  

我们提出了 DBA-Bench，一个基于三个设计原则构建的基准框架，共同弥合这些差距。  
**生产保真度**意味着 DBA-Bench 提供接近生产级故障环境，涵盖一组丰富的、复杂的数据库场景。它在完全仪表化的 PostgreSQL 环境中实例化这些场景，同时 OLTP、OLAP 或混合业务工作负载在诊断和验证期间保持活跃。这些环境保留数据库内部状态（数据分布、统计信息、WAL 位置和死元组），并暴露广泛的多源观测表面，包括度量、系统和业务日志、查询记录和计划——直接解决差距 1、2 和 4。  
**结果优先评估**将成功定义为在场景运维安全约束下可衡量的性能恢复或故障消除。它认可满足场景特定成功契约的修复路径，并单独惩罚不受支持、未限定范围或破坏性操作——直接解决差距 3。  
**受控场景可复现性**在每次运行后恢复完整的脏环境，并且仅当场景特定的谓词验证了预期的因果状态和可见症状后才允许下一次运行。这种工程控制给予代理等效的故障条件，同时保留在线数据库的运行时变化。  

基于这些原则，DBA-Bench 实例化了 106 个场景，涵盖 7 个运维任务域和两个公开的难度标签。这些标签来源于两个独立标注的属性：参考路径诊断深度，它计算 DBA 验证的参考诊断路径中基于证据的因果跳数；以及环境复杂度，它量化该路径所需工具内的噪声。代理通过统一的工具接口与在线数据库环境交互，进行度量查询、SQL 执行和实例管理，镜像人类 DBA 使用监控仪表盘、SQL 终端和数据库管理控制台的工作流程。每次基准运行形成一个封闭的运维循环：代理在故障在线环境中定位证据，应用修复，并在工作负载保持活跃时验证结果。  

我们评估了六个基础模型下的通用 ReAct 工作流、两个由 GPT-5.5 支持的数据库代理以及一个人类 DBA 参考。在 848 次自动化运行中，诊断通过率、结果通过率和安全通过率分别为 32.7%、19.6% 和 12.4%。最佳自动化安全通过率为 17.9%，而人类 DBA 参考为 93.4%，差距达 75.5 个百分点。自动化安全通过率从简单场景的 19.6% 下降到困难场景的 7.6%。  

总之，本文做出以下贡献：  
- • **DBA-Bench 框架。** 我们设计并实现了一个针对数据库运维代理的基准，结合了在线仪表化的数据库环境与受控场景重现。该框架涵盖 7 个运维任务域的 106 个 PostgreSQL 场景，以及基于独立诊断深度和环境复杂度标注的两个难度标签。它结合了主动业务工作负载、统一的工具接口和声明式场景编排。  
- • **结果优先评估协议。** 我们提出了一种结果优先的评估方法论，其中成功需要在不违反运维安全约束的情况下实现可衡量的系统恢复。场景特定的结果验证器评估运行后状态和结构化提交，而单独的跟踪规则评估运维安全性。这种分离允许不同的修复路径在满足相同场景特定成功契约时获得认可，而不混淆恢复与执行安全性。  
- • **系统性的实证研究。** 我们报告了在保留这些运维属性的受控 PostgreSQL 环境中，对六个基础模型系统、两个数据库代理系统以及一个人工 DBA 参考的比较评估。结果揭示了诊断、实现结果和安全修复之间的差距，以及不同场景属性上的能力差异。  

## 2. 相关工作  
数据库自动化长期以来将专门诊断与策略特定控制相结合。早期的数据库诊断和自治数据库系统建立了用于性能谓词、在线异常诊断、根因 SQL 定位、工作负载感知因果分析、遥测驱动的慢查询诊断、多模态根因排序以及策略特定调优的方法（Yoon 等人，2016 (https://arxiv.org/html/2607.22165#bib.bib14)；Liu 等人，2020 (https://arxiv.org/html/2607.22165#bib.bib15)，2022 (https://arxiv.org/html/2607.22165#bib.bib16)；Lu 等人，2022 (https://arxiv.org/html/2607.22165#bib.bib17)；Ma 等人，2020 (https://arxiv.org/html/2607.22165#bib.bib26)；Ouyang 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib27)；Zhou 等人，2021 (https://arxiv.org/html/2607.22165#bib.bib28)；Van Aken 等人，2017 (https://arxiv.org/html/2607.22165#bib.bib29)）。这些系统提供了重要的诊断和控制构建模块，但每个都专注于一个受限的诊断或优化目标（Chen 等人，2025b (https://arxiv.org/html/2607.22165#bib.bib9)，2023a (https://arxiv.org/html/2607.22165#bib.bib10)，2023b (https://arxiv.org/html/2607.22165#bib.bib11)；Liang 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib12)；Chen 等人，2026b (https://arxiv.org/html/2607.22165#bib.bib13)）。  

大语言模型将这一工作线扩展为更灵活的运维推理。基于 LLM 的数据库运维系统现在涵盖交互式代理、单次传递顾问以及调优或副驾系统（Zhou 等人，2024b (https://arxiv.org/html/2607.22165#bib.bib1)；Chen 等人，2026a (https://arxiv.org/html/2607.22165#bib.bib2)；Zhou 等人，2026 (https://arxiv.org/html/2607.22165#bib.bib3)；Singh 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib4)；Chen 等人，2025a (https://arxiv.org/html/2607.22165#bib.bib5)，2024 (https://arxiv.org/html/2607.22165#bib.bib6)；Lao 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib7)；Zhou 等人，2025 (https://arxiv.org/html/2607.22165#bib.bib8)）。相邻的基于 LLM 的事件管理系统推荐根因和缓解（Ahmed 等人，2023 (https://arxiv.org/html/2607.22165#bib.bib30)），协助云服务监控（Yu 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib32)），推荐事件查询（Jiang 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib33)），或执行工具增强的自主根因分析（Wang 等人，2024 (https://arxiv.org/html/2607.22165#bib.bib31)）。