In plain words: It reads database manuals to build a knowledge base, then uses a language model with a branching search to find a fault's root cause and fix. It beat hand-written rules and plain GPT-4 on real faults, answering in under 10 minutes instead of hours.
Abstract · D-Bot: Database Diagnosis System using Large Language Models
Database administrators (DBAs) play an important role in managing, maintaining and optimizing database systems. However, it is hard and tedious for DBAs to manage a large number of databases and give timely response (waiting for hours is intolerable in many online cases). In addition, existing empirical methods only support limited diagnosis scenarios, which are also labor-intensive to update the diagnosis rules for database version updates. Recently large language models (LLMs) have shown great potential in various fields. Thus, we propose D-Bot, an LLM-based database diagnosis system that can automatically acquire knowledge from diagnosis documents, and generate reasonable and well-founded diagnosis report (i.e., identifying the root causes and solutions) within acceptable time (e.g., under 10 minutes compared to hours by a DBA). The techniques in D-Bot include (i) offline knowledge extraction from documents, (ii) automatic prompt generation (e.g., knowledge matching, tool retrieval), (iii) root cause analysis using tree search algorithm, and (iv) collaborative mechanism for complex anomalies with multiple root causes. We verify D-Bot on real benchmarks (including 539 anomalies of six typical applications), and the results show that D-Bot can effectively analyze the root causes of unseen anomalies and significantly outperforms traditional methods and vanilla models like GPT-4.
Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, Guoyang Zeng
arXiv:2312.01454 · cs.DB, cs.AI, cs.CL, cs.LG · submitted Dec 3, 2023 · updated Dec 6, 2023
abstract · pdf · html
His "achievements" included dropping the production database by messing with the backup processes, insisting on very wide tables rather than smaller tables with joins since "they're easier to maintain", and giving out full admin rights to junior devs who subsequently went on to develop their own "black data mart" which was way way better than the production version.
Sigh, and to make things worse, this DBA guy managed to leverage his "experience" into a Principal Data Architect role at a major consulting company after the start-up predictably imploded.