「ADBはSQLを自動で最適化します！」という営業トークにワクワクした日
初めてADBの話を聞いたとき、営業の兄ちゃんがこう言った。
「SQLのチューニングはもう不要です！ADBが全部やります！」
俺の脳内は即、異世界モードに突入。
- 実行計画？勝手に良くなる
- インデックス？勝手に作ってくれる
- 統計情報？勝手に最新化
「俺、もう何もしなくても魔王軍並の戦力が手に入るじゃん...!」
まずは統計情報の自動化で"足元"から固める
オンプレ時代、統計情報の更新は俺の夜中の仕事だった・
更新忘れで性能劣化、取りすぎで処理延長...胃が痛くなる作業だ。
でもADBはーー
- データ変化を自動検知
- 必要なテーブルだけ効率的に更新
- 夜間やメンテ時間に自動実行
気づけば統計情報は常に最新。
「足元が固まってるって、こんなに安心なんだな」
SQL性能劣化の検知から修復まで、全自動だった
ADBの真価はここからだ。
SQLの性能劣化を検知し、修復する流れが全部自動化されている。
1️⃣ SQLの実行情報を高頻度で自動収集
常時監視モードで、実行時間・CPU・I/Oなどを収集。
「常に戦況ログを取ってる偵察部隊みたいなもの」
2️⃣ リソースを大量消費する上位SQLを自動検出
収集データから、CPU時間やI/O使用量が多いSQLをランク付け。
「あやしいやつは、すぐマークだ」
3️⃣ 代替プランを自動検索
過去の実行計画や統計情報をもとに、より効率的なプランを探索。
「勝てそうな戦術をデータベースが自分で考える」
4️⃣ 現行のベースラインと代替プランを比較し、良ければ自動登録
もし代替プランが明らかに速ければ、SQL Plan Baselineに自動追加。
「優秀な作戦は即採用、しかも司令官（DBA）の許可なしで」
5️⃣ ベースラインに存在する実行計画を優先利用
以後は安定した実行計画を使い続けるため、再び劣化する可能性が激減。
「勝てる戦術は、勝てるまで何度でも使う」
つまり、性能劣化を“未然に防ぐ”時代へ
この仕組みのおかげで、
- 本番環境の急な遅延を自動で抑止
- DBAの緊急対応ゼロ
- 常に安定したレスポンスを維持
「気づけば性能が戻ってた」
そんな未来が、ADBの世界にはある。
だが、まだ封印された力があった
「全部自動化されてるんだ！」と浮かれていた俺に、Oracleはこう言った。
「いや、まだ眠ってる力がある。ただしデフォルトではOFFだ」
その”封印された機能”とはーー
- 自動インデクス作成
- 自動パーティション
- 自動ゾーンマップ
- 自動Materialized Views
などなど
安全性と互換性のため、最初からは有効になっていない。
解き放つかどうかは、DBAの判断に委ねられている。
そう、真の力は封印されていた。解き放つかどうかは、俺達DBA次第だ。
次回予告
第7話｜クラウドでのセキュリティ、旧世界の知識は通じない！？
「ACL設定？パスワードポリシー？…ってそれ、IAMじゃないの？」
オンプレDBAの常識が通じない、クラウドセキュリティの新世界に俺は戸惑う。