パッチを当てるのは、俺の役目だったはずだ
オンプレ時代、パッチ適用はDBAの戦場だった。
事前に影響調査
動作確認用のテスト環境構築
本番適用の手順書（20ページ）
リカバリプランも用意
深夜の作業、成功しても拍手はされない
それでも、自分の手でDBを守ってきたという実感があった。
そんな俺に、OCIの通知が飛んできた。
「Autonomous Databaseのパッチ適用が完了しました」
え？
…やった記憶がないんだが。
勝手にパッチ！？そんなのアリかよ…
調べてみると、ADBは定期的に自動パッチが適用される設計だった。
運用停止の必要なし
ユーザー操作も不要
基本的には「気づいたら終わってる」
まさに「魔法のようなメンテナンス」。
でも、逆に不安になった。
「本当に落ちたりしないのか？」
「動作保証はどうなってる？」
「パッチの詳細は見られるのか？」
パッチの適用はコントロールできるのか？
ADBでは、 事前に定義されたメンテナンス・ウィンドウ の中でOracleは勝手にパッチを適用する
「次回のメンテナンスは ◯月◯日 XX:00 〜 XX:00」
それは、運営（Oracle）が決めた"世界の運行スケジュール"
DBAが日付を動かすことは出来ない。避けられぬ運命(スケジュール) なのだ。
Oracle Cloud Supportでサービス・リクエストを提出することで、割り当てられたメンテナンス・ウィンドウを、別の2時間のウィンドウに変更することは可能。
ユーザ自身でのスケジュール変更は出来ない。
しかし！選べる"2つの時の流れ"があった。
Oracleは我々に 「早期(Early)」と「定期(Regular)」 という２つのときの流れを用意してくれている。
| モード | 適用時期 | 特徴 |
|---|---|---|
| 早期(Early) | 定期パッチより1週間早い | 新しいパッチを即体験できる |
| 定期(Regular) | 早期パッチの1週間後 | より安定した運用向け |
もし本番環境を 定期(Regular) にしておき、
検証環境を 早期(Early) にしておけばーー
「1週間前に新パッチが検証環境に降ってくる」
-> 本番適用前に事前テストができる！
これはまさに 時空魔法。
本番の未来を、検証環境で先取りできるのだ。
「未来を知る者は、災いを避けられる」
それが、クラウドDBAの新しい戦いなのか。
バックアップも自動。でも、本当に使えるのか？
ADBは1日1回、自動でバックアップを取ってくれる。
しかも、以下のような恩恵付き：
最大60日間保持
ポイントインタイム・リカバリ（PITR）可能
OCIコンソールから“ポチッ”で復元できる
だけど最初は不安だった。
「ログアーカイブが壊れてたら？」
「RMANの検証は？チェックサムは？」
「“戻したつもりが戻ってない”とかないの？」
試してみた：PITR（ポイント・イン・タイム・リカバリ）
意を決して、開発環境でPITRを実行してみた。
結果：
任意の日時を指定して復元
数分〜十数分で別インスタンスが生成
そのまま検証・切り戻し可能
「……これは、めちゃくちゃラクだ」
オンプレでは丸一日かかっていた作業が、数クリックで終わる。
だがラクだからこそ、理解しておかないと事故る。
DBAの役割が変わる瞬間だった
「パッチもバックアップも、やらなくていい」
それは“仕事が減る”ではなく、“責任の持ち方が変わる”ということ。
手作業がなくなっても
監視すべき指標はあるし
復旧の手順も知っておく必要がある
自動化された世界でも、DBAは消えない。
ただ、信じて任せる力が試される。
次回予告
第6話｜SQLの性能劣化、気づいたら治ってた件〜そしてまだ封印された力もあった〜
あの面倒なSQL性能劣化対応が"ゼロ運用に"ーー
オンプレDBA必見、監視・原因特定・計画修復まで全自動の仕組みを暴く！