# データベース O&M ## 定義 データベース O&M(Database Operation and Maintenance)は、データベースシステムの異常検知・診断・根本原因分析・復旧・性能最適化を扱う運用保守領域である。一般 AIOps と同じ検知→診断→緩和の構造を持つが、DB 内部機構、実行計画、メトリクス階層、ノブ設定、ログ/redo/ロック/バッファ管理などの専門知識が律速になる。([[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]) 本ページは親ページとし、異常診断は [[データベース自律診断]]、性能設定最適化は [[データベースノブチューニング]] に分ける。 ## 横断的知見 - **DB O&M は RCA と最適化の 2 軸で構成される**: D-Bot/DBAIOps/OpDiag は異常の根本原因を診断し、AgentTune はノブ空間を探索して性能を最適化する。両者は対象が違うが、DBA の専門知識を LLM/グラフ/木探索で外在化する点で共通する。 - **知識の構造化が LLM の性能を決める**: DBAIOps は ExperienceGraph とグラフ進化で、一般 RAG が壊しがちな診断パスの関係性を保つ。([[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]) - **DB 固有の信号は一般 AIOps の telemetry と粒度が違う**: wait event、redo log、実行計画、クエリ演算子、ノブ設定など、DB 内部構造を知らないと根本原因と緩和策を結びつけられない。 - **未知異常への適応は O&M の中心課題である**: ルールベースや通常の ML は既知パターンに強いが、DBAIOps はグラフ進化で新規 DB/新規異常へ対応する方向を示した。 - **DB O&M は AI 診断以前に、サービス運用化と標準化で難度を下げる領域でもある**: Bigtable はユーザー運用モデルから Bigtable SRE チームによる全社サービス運用へ移行し、固定タブレットサーバ形状、メタデータ専用パーティション、ブラックボックスプローバ、既定バックアップ、オートサイジングを導入した。D-Bot/DBAIOps/AgentTune が「既存 DB 運用の診断・最適化を自動化する」方向であるのに対し、Bigtable の経験は「運用対象の形を標準化して O&M 問題そのものを狭める」方向を示す。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]], [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]], [[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]]) - **性能最適化は O&M の事前介入として DB 内部へ入り込む**: AgentTune は公開ノブの値を調整し、EcoTune は LSM ツリー内部のコンパクション方針を平均クエリスループットへ最適化する。どちらも障害後の RCA ではなく、DBA/O&M が通常行う性能維持作業を自動化する方向だが、EcoTune は実行計画やノブではなくストレージエンジンのバックグラウンド作業スケジューリングを直接対象にする。(Source: [[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]], [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]]) - **テキストからの知識抽出がノブ探索の障壁を取り除く最初の実証**: DB-BERT(SIGMOD 2022)は DBMS マニュアル・ブログ・フォーラムの自然言語テキストを BERT で解析し、チューニングヒントを抽出・優先付け・翻訳・集約して、全実験(TPC-H/TPC-C × Postgres/MySQL)で人手によるパラメータ選定や値域指定を必要とする強化学習手法(DDPG++)と教師あり NLP 手法(Prior-Main)の両方を上回った。ノブチューニングの「人間の専門知識に依存する入力準備」という課題に対し、テキスト解析による自動化の可能性を示した。(Source: [[@2022__SIGMOD__DB-BERT - a Database Tuning Tool that Reads the Manual]]) - **産業規模の DB O&M では AI 導入前に情報とツールの集中化が先決になる**: Databricks の [[Storax]] 事例(MySQL/TiDB を数千インスタンス・70以上のリージョン・3クラウドで運用)では、AI エージェントを入れる前にバラバラなツールとコンテキストを集中化した。最初の数イテレーションはほぼ AI を使わなかったが、この集中化なしに後続エージェント統合は採用されなかった。D-Bot/DBAIOps が「LLM に何を与えるか(知識・ツール・証拠)」を主問題としてきた方向と、現場が「情報がどこにあるかを全員が知れる状態を先に作る」ことを先決とする観察は整合する。(Source: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]], [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]) - **AI DB O&M の安全な書き込みには外付けワークフローエンジンと多者承認が必要になる**: Storax は Temporal ワークフローでリスクの高い DB 操作に2人目承認ゲートを設ける。「診断後の解決策を自動実行する場合の承認境界」という研究系の未解決問に対し、産業実装はワークフローエンジン+多者承認という具体的な解を示した。(Source: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]) - **診断-修復ギャップは業界横断で観測される現実の課題である**: DBA-Bench は 848 自動実行のうち Diagnosis Pass 277 件(32.7%)に対し Outcome Pass はその 62.1% が失敗する(19.6%)ことを実測し、「診断できても安全な修復を完遂できない」という O&M の核心的困難を定量化した。Storax の「診断は自律、実行は人間承認」という産業実装の設計判断(上記)は、この診断-修復ギャップに対する運用上の回避策として整合的に読める——研究系ベンチマークが定量化した困難を、産業実装は承認ゲートで吸収している。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]], [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]) - **D-Bot・DBAIOps は自己申告のベンチマークでは高精度だが、共有の本番忠実度環境で再評価すると性能が大きく後退する**: D-Bot は原論文で 539 件の異常ベンチマークにおいて DNN/DecisionTree 比 8〜54% の精度向上・HumanDBA と競争力のある性能を主張したが、DBA-Bench が GPT-5.5 固定バックボーンで統一ツール・知識・シナリオを用いて再評価すると Safe Pass はわずか 5.7%(common-ReAct の 17.9% を下回る)にとどまった。DBAIOps も同様に、自身のベンチマークでは高い成功を報告する一方、DBA-Bench では Safe Pass 14.2%(GPT-5.5 ReAct の 17.9% を下回る)。これは本ページ冒頭の「タスク範囲・testbed・評価指標の違いが比較を妨げる」という DBAIOps 自身の課題認識を裏付ける実証例であり、共有の再現可能な評価環境が O&M エージェント研究に不可欠であることを示す。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **アーキテクチャの精緻化(木探索・知識グラフ)は動作点を変えるが失敗モードを除去しない**: DBA-Bench の固定バックボーン比較(GPT-5.5)では、D-Bot の tree-search も DBAIOps の knowledge-graph-guided reasoning も、素の ReActループに対して Safe Pass を改善しない(むしろ低下)。コスト面ではトレードオフが生まれる(DBAIOps は ReAct 比コスト 69.1% 減で Safe Pass -3.7 ポイント)ものの、診断-修復-安全性の根本的なギャップ自体は構造変更では解決しない。(Source: [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) - **2017年の DBRE(人間中心のセルフサービス化)は、2020年代の AI 駆動 DB O&M(D-Bot・DBAIOps 等)が自動化しようとする対象そのものを先取りして定義している**: Laine Campbell と Charity Majors が2017年に提唱した DBRE(『SREの探求』16章)は、優秀な DBRE が希少であるという制約に対し、標準化されたセルフサービス型プラットフォーム(メトリクス収集プラグイン・バックアップ/リカバリユーティリティ・リファレンスアーキテクチャ・安全なデプロイ手法)を人間の DBRE が構築することで、DBRE 自身がボトルネックにならないようにする、という人間中心の解法を示した。これに対し、本ページが扱う D-Bot・DBAIOps・AgentTune 等は、同じ「優秀な DBA/DBRE の希少性」という制約に対し、LLM/知識グラフ/木探索によって診断・チューニングそのものを自動化するという異なる解法を提示する。両者を並べると、DBRE のセルフサービス化(2017年)は「人間の専門知識をプラットフォーム/標準として外在化する」ことで希少性を緩和したのに対し、AI 駆動 O&M(2020年代)は「専門知識そのものを LLM に外在化する」ことで同じ制約に取り組んでおり、外在化の対象が「手順・標準」から「判断・診断」へと深化した系譜として読める。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 16 データベースリライアビリティエンジニアリング]] §16.1.2, [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]) - **DBRE の「番人からの脱却」という組織的処方は、DBA-Bench が定量化した「診断-修復ギャップ」に対する2017年時点の先行的な回避策として読める**: DBA-Bench(既出)は、AI エージェントが診断に成功しても安全な修復を完遂できないケースが多い(Outcome Pass の失敗率62.1%)ことを実測した。『SREの探求』16章は、AI 以前の2017年時点で同種の「危険な変更を安全に完遂させる」という課題に対し、影響分析による関門判定(共有オブジェクトのロック・データ完全性の問題等が検出されたら人間の DBRE を巻き込む)、マイグレーションパターンのリポジトリ化、ロールバックスクリプトの必須チェックイン、という段階的セーフガードで対処していた。AI 駆動 O&M が Storax のような外部ワークフローエンジン+多者承認で診断-修復ギャップを吸収する(既出)のは、DBRE が2017年に確立した「危険な操作は自動化ではなく人間の関与を要求するゲートを残す」という設計原則の、LLM エージェント文脈での再実装と位置づけられる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 16 データベースリライアビリティエンジニアリング]] §16.6.2, §16.6.3, [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]]) ## 未解決の問い - **承認境界の設計については Storax が一つの解を示した**(Temporal + 2人目承認)が、「どの粒度の操作から多者承認が必要か」「ロールバック不能な操作をエージェントに許可すべきか」は引き続き未解決である。 - 診断結果からノブ変更・インデックス追加・クエリ修正を自動実行する場合、安全な承認境界をどう定義するか。 - DBMS 間の共通知識と固有知識をどう分ければ、Oracle/MySQL/PostgreSQL/分散 DB に横展開できるか。 - ExperienceGraph の継続更新は、誤った診断経験を取り込んだときにどう修正されるべきか。 - DB をサービス運用化して形状・バックアップ・監視を標準化した場合、LLM/エージェント型 O&M はどの作業を残余タスクとして担うべきか。 - コンパクションのような内部バックグラウンド作業を自動最適化する場合、DBA が承認・監査すべき境界は公開ノブ変更より狭いのか、それとも同等に扱うべきか。 - DBA-Bench が明らかにした「診断は正しいが修復が安全に完遂しない(62.1%)」という失敗モードに対し、Storax 型の外部承認ゲート以外にエージェント内部の設計(修復契約の全ループ保持など)でどこまで対処できるか。DBA-Bench 自身はこれを設計上の教訓として提示するが、実装・検証は今後の課題として残る。 ## 関連 - 子 concept: [[データベース自律診断]] / [[データベースノブチューニング]] - 隣接 concept: [[根本原因分析]] / [[AIOps]] / [[異常検知]] / [[障害緩和]] / [[本番接地型ベンチマーク]] / [[データベースリライアビリティエンジニアリング]] - ソース: [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]] / [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]] / [[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]] / [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] / [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]] / [[@2022__SIGMOD__DB-BERT - a Database Tuning Tool that Reads the Manual]] / [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]] / [[@2021__OReillyJapan__SREの探求 - Chapter 16 データベースリライアビリティエンジニアリング]] ## 出典 - [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]] - [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]] - [[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] - [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]] - [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]](産業規模 O&M、Storax、ツール集中化先行、Temporal承認ゲート) - [[@2022__SIGMOD__DB-BERT - a Database Tuning Tool that Reads the Manual]](テキストからのチューニングヒント抽出・NLP 強化型ノブチューニング) - [[@2026__arXiv__DBA-Bench - A Production-Fidelity Benchmark for LLM-Based Database Operations Agents]](本番忠実度 DB エージェントベンチマーク、106シナリオ、diagnosis-outcome-safety 分離評価、D-Bot/DBAIOps 再評価) - [[@2021__OReillyJapan__SREの探求 - Chapter 16 データベースリライアビリティエンジニアリング]](2017年の DBRE、セルフサービス化による専門知識の外在化、番人モデルからの脱却と影響分析による関門判定)