# データベース 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/新規異常へ対応する方向を示した。 ## 未解決の問い - 診断結果からノブ変更・インデックス追加・クエリ修正を自動実行する場合、安全な承認境界をどう定義するか。 - DBMS 間の共通知識と固有知識をどう分ければ、Oracle/MySQL/PostgreSQL/分散 DB に横展開できるか。 - ExperienceGraph の継続更新は、誤った診断経験を取り込んだときにどう修正されるべきか。 ## 関連 - 子 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]] ## 出典 - [[@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]]