データベース自律診断 - yuuk1's Digital Garden

# データベース自律診断 ## 定義データベース自律診断は、スロークエリ、リソース枯渇、ハング、クラッシュ、演算子起因の性能異常などを自動的に分析し、根本原因と解決策候補を特定する取り組みである。[[データベース O&M]] の子 concept として、診断・RCA の責務を担う。([[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]) ## 横断的知見 - **診断粒度は KPI → クエリ → 演算子へ細かくなっている**: OpDiag は演算子レベルの帰属を扱い、後続の修正作業量を減らす方向を示した。([[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]]) - **ドメイン知識の外在化が精度の律速である**: D-Bot は知識なしアブレーションで大幅に性能を落とし、DB 診断文書・ツール・LLM の組み合わせが必須であることを示した。([[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]) - **木探索は早期停止と幻覚を抑える**: D-Bot の UCT 型探索や DBAIOps のグラフ推論は、LLM の単発診断を構造化し、誤ったツール呼び出しや早期停止を抑える。 - **DB 診断は一般 RCA と手法的に同型だが、証拠が DB 内部に寄る**: SOP/RAG/マルチエージェントという構造は [[根本原因分析]] と共通するが、実行計画・wait event・redo log・query operator が主証拠になる。 ## 横断的知見(続き) - **産業実装での自律診断は RCA 提示止まりで承認付き実行とセットになっている**: Storax (Databricks) は根本原因・タイムライン・緩和策候補を出力するまでを自律で行い、実際の DB パラメータ変更には人間承認ゲートを設ける。D-Bot/DBAIOps が「診断知識をどう与えるか」を研究の主問題とするのに対し、産業実装は「診断後の実行を誰が承認するか」を設計の中心に置く。(Source: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]) - **FluxInfer は DB メトリクス間の有向因果推定を放棄し無向グラフ + PageRank で PC 系 8 手法を上回った**: FluxInfer（Liu+ IPCCC 2020）は DB 性能メトリクスの根本原因 KPI を、重み付き無向依存グラフ（WUDG: Pearson 相関 + 相関変化量）と重み付き PageRank で特定する。従来の PC ベース手法が辺方向推定に失敗して精度を落とす問題を「方向を推定しない」設計で迂回し、AC@3 で 2〜15 倍の改善を達成した。D-Bot/DBAIOps が LLM + 知識グラフで診断知識を供給する流れとは別路線で、メトリクス間の統計的依存のみから根本原因を絞り込む「知識レス」設計。OpDiag の演算子レベル帰属とは粒度が異なり（FluxInfer は KPI レベル）、両者の統合——FluxInfer で候補 KPI を絞り込み → OpDiag で演算子レベルに深掘り——が考えられる。(Source: [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]]) ## 横断的知見(続き) - **DBPA ベンチマークが示す「訓練データ規模の重要性」**: DBSherlock は同一データ 40 件でもモデル構築に 10,307 秒かかるのに対し XGBoost は 2 秒で済み、かつ精度は XGBoost・LightGBM が大幅に上回る。診断に機械学習を使うためのデータ収集コストを下げることが、診断アルゴリズム研究の前提条件であることを DBPA は明確にした。(Source: [[@2023__PACMMOD__DBPA - A Benchmark for Transactional Database Performance Anomalies]]) - **DBPA は「データ不足」を根本原因とし、LLM 系診断は「知識不足」を根本原因とする**: D-Bot・DBAIOps・Storax が LLM + 知識グラフで「どの知識を与えるか」を主問題とするのに対し、DBPA は「十分な訓練データが得られないこと」を主問題として再現ベンチマークで解決しようとする。両者は直交するアプローチであり、組み合わせが有望である。(Source: [[@2023__PACMMOD__DBPA - A Benchmark for Transactional Database Performance Anomalies]], [[D-Bot]], [[DBAIOps]]) - **Spark ジョブ診断は「クラウドデータ処理基盤」領域の DB 診断として、RDBMS 系診断と証拠源が大きく異なる**: AutoDebugger([[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]])は、SMS から収集した ShuffleTime・IOTime・CPUTime・QueueingTime・IdleTime などの Spark 実行メトリクスを因果グラフのノードとして用いる。D-Bot/DBAIOps が実行計画・wait event・redo log を主証拠とする RDBMS 系診断とは、証拠源の種類が根本的に異なる。これは「DB 診断」が「どのデータ処理エンジンか」でまったく別のドメイン知識を必要とすることを示す——同じ因果推論フレームワーク上でも、ノード定義とグラフ構造は対象エンジンに固有である。(Source: [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]]) ## 横断的知見(続き) - **本番忠実度環境での再評価は「診断できても直る保証」の脆さを定量化した**: 上記「木探索は早期停止と幻覚を抑える」という主張は D-Bot 原論文の自己申告ベンチマークに基づくが、DBA-Bench が稼働ワークロード付きの共有 PostgreSQL 環境・共通バックボーン(GPT-5.5)で D-Bot を再評価すると、Diagnosis Pass 18.9% に対し Outcome Pass 13.2%・Safe Pass はわずか 5.7% にとどまり、素の ReAct(44.3%/26.4%/17.9%)を全指標で下回った。全ベースライン横断でも Diagnosis Pass 32.7% に対し Outcome Pass 19.6%(diagnosis-passing runs の 62.1% が outcome に失敗)であり、「診断精度の向上=修復の成功」ではないことを大規模に実証した。木探索・知識グラフによる構造化は診断のノイズ耐性を上げても、証拠に基づく修復対象の選定・実行・検証という別のボトルネックには効かない。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **失敗モードはタスクドメインごとに定性的に異なる**: DBA-Bench の失敗モード分類(700 件の non-clean runs)では、misleading alerts はノイズ/デコイへの誤誘導が支配的(68.3%)、composite faults は因果連鎖の途中打ち切りが支配的(45.9%)、system failure・business change は誤った修復対象の選択が最頻(34.7%/30.0%)、periodic health check・resource governance は証拠の見落としが最頻(33.0%/28.0%)。これは「DB 診断の失敗要因」が単一のボトルネックでなく、シナリオの性質(欺瞞的症状か・複合障害か・単純な劣化か)に応じて異なる能力を要求することを示す。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) ## 横断的知見(続き) - **D-Bot 自身の手法分類は、DBA-Bench が再評価した「ツリーサーチ型」評価対象より広い**: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]] §3.3.3 は D-Bot を (1) RAG ベースの診断知識強化(階層文書構造 + ファインチューニング済み Sentence-BERT 検索)、(2) チーフエージェント調整下のツリーサーチ型マルチエージェント根本原因分析、(3) GPT-4 駆動の診断結果を Llama2-13B・CodeLlama-13B・Baichuan2-13B へマルチタスクファインチューニングで蒸留するローカライズド LLM、の3手法の複合として説明する。DBA-Bench が再評価したのはこのうち (2) の GPT-5.5 バックボーン版のみであり、コスト削減を狙う (3) の蒸留版がどう再評価されるかは示されていない。上記「本番忠実度環境での再評価は『診断できても直る保証』の脆さを定量化した」という既存知見のもとになった性能が、より小型のバックボーンでも維持されるかは未検証のまま残る。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]], [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **HTAP エンジン固有の診断も、RDBMS/Spark に続く「エンジン固有証拠源」の一例である**: ByteHTAP([[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]] §3.3.3 で言及)は HTAP システムのクエリ性能回帰を診断するため、過去クエリとその性能説明からなる知識ベースを構築し、拡張ツリー CNN 分類器でクエリプランペアを符号化・検索する。これは D-Bot/DBAIOps の実行計画・wait event・redo log や、AutoDebugger の Spark 実行メトリクス(ShuffleTime 等)と並ぶ第3のエンジン固有証拠源であり、上記「Spark ジョブ診断は…証拠源が大きく異なる」という既存知見(RDBMS 系と Spark 系の対比)を HTAP エンジンにも拡張する——DB 診断はエンジンごとに固有の証拠設計を要するという傾向が、少なくとも3系統のエンジン(RDBMS・Spark・HTAP)で確認できる。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]], [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]]) ## 未解決の問い - OpDiag の演算子レベル帰属を DBAIOps の ExperienceGraph に証拠として注入できるか。 - 複数 DBMS やクラウドマネージド DB に診断知識を移植するとき、どの知識が共通でどれが製品固有か。 - 診断後の解決策を自動実行する場合、DB 変更のリスクをどう評価・ロールバックするか。 - DBPA のような再現ベンチマークを LLM ベース診断(D-Bot 等)の評価基盤として使うとき、何を追加で設計する必要があるか(LLM の推論過程評価など)。 - DBA-Bench が示した「診断は正しいが修復が安全に完遂しない」ギャップを埋めるには、診断アルゴリズムの改良ではなく、修復契約(前提条件・スコープ・ロールバック条件・post-action 検証)を制御ループ全体で保持する別種の機構が要る可能性がある。この機構をどう設計・評価すべきか。 - D-Bot の蒸留済みローカライズド LLM 版(Llama2-13B・CodeLlama-13B・Baichuan2-13B)は、DBA-Bench のような本番忠実度ベンチマークで GPT-5.5 バックボーン版と比べてどの程度性能が劣化するか。 ## 関連 - 親: [[データベース O&M]] - 隣接 concept: [[データベースノブチューニング]] / [[根本原因分析]] / [[AIOps]] / [[障害緩和]] - ソース: [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]] / [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]] / [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]] / [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]] / [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]] ## 出典 - [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]] - [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]] - [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]] - [[A Survey of LLM × DATA]] - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]](§3.3.3 Anomaly Diagnosis — D-Bot の RAG/マルチエージェント/ファインチューニング3手法、DBG-PT、ByteHTAP、Panda) - [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]](産業実装での診断+承認付き実行パターン) - [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]](WUDG + PageRank による知識レス DB 根本原因 KPI 特定) - [[@2023__PACMMOD__DBPA - A Benchmark for Transactional Database Performance Anomalies]](OLTP 性能異常の決定論的再現ベンチマーク、9 種の異常タイプ、複合異常生成アルゴリズム) - [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]](本番忠実度ベンチマークによる D-Bot/DBAIOps 再評価、診断-修復ギャップの定量化、カテゴリ別失敗モード分類)