「その機能、止まるよ」～OCIとADBと自動インデックスと～

本記事は基盤デザインウィーク最終日の記事です。
🌈 9日目 ▶▶ 本記事 💻

その機能、止まるよ

「貴方、うちの会社で数少ないOCI上のシステム担当なんだからOCI関連でブログ書くよろし」

ということでOCIについて書きます。どうも、私です、長廻です。

改めまして、みなさま、OCI（Oracle Cloud Infrastructure）ってご存じでしょうか。
そうです、Oracle社の提供しているパブリッククラウドサービスです。
NRIネットコムではAWS上にシステムを構築することが多いのですが、OCIも利用しています。

本記事ではOCIの中でも、特徴的なサービスの一つであるADB（Autonomous Database）というサービスについてご紹介します。
なお、Autonomous Databaseには後述するような様々な自動化された機能が存在しますが、本記事ではその一部の機能（自動インデックス）のみのご紹介です。
また、自動インデックス機能について、運用中に発生した問題点についても言及しています。

Autonomous Databaseとはなんぞや
自動インデックスとはなんぞや
その機能、止まるよ
- 事象
- 原因と対策
最後に

Autonomous Databaseとはなんぞや

Autonomous DatabaseはOCI上のフルマネージドなOracleデータベースサービスです。
Autonomousという名の通り、とっても自律した生活を送っています、そう、私なんかよりね。

Autonomousということで、以下のような様々な処理が自動化されています。

自動スケーリング（CPU及びストレージ）
自動バックアップ
自動フェールオーバー
自動パッチ適用
自動オプティマイザ統計収集
自動インデックス
自動SQL計画管理
・・・etc

特に後半3つのようなチューニング関連の自動化処理はAutonomous Databaseならではですね。※利用者側で有効 / 無効の設定は可能
本来であれば、インデックスを手動で作成するのは当然のこととして、それに加えてインデックスのREBUILD等のメンテナンスジョブやテーブルのオプティマイザ統計を収集するジョブを構築し、何らかのジョブ管理ツールで定期実行するといった運用が必要となります。
Autonomous Databaseではそれらを全てOracle任せにできます。
構築工数や運用負荷はかなり軽減されますね。

また、自動インデックスをはじめとするチューニング周りの自動化については、熟練のOracleエンジニアがチューニングを施すことに匹敵するようです（Oracle社談）。
チューニング関連はハマるときはハマるというか、時間と労力のかかる作業ですよね。
それを自動で実施してくれるという点もAutonomous Databaseの大きなメリットであると言えます。

それでは、冒頭に記載した通り、本記事では自動インデックスにフォーカスしてご紹介します。

自動インデックスとはなんぞや

なんぞや！

その名の通り、わざわざ手動でインデックスを作成せずとも、ADBで自動的にインデックスを作成してくれる機能です。
過去に実行されたワークロード（SQLクエリ）の情報を元にAI及び機械学習を用いて、性能向上する可能性のあるSQLクエリを特定し、インデックスを作成します。

自動インデックスの処理概要

ADBで内部的に以下の1～6の処理を自動でぐるぐる回し、絶え間なくインデックスのチューニングを行います。

インデックスの作成対象となるSQLクエリの取得
- ワークロードからSQLクエリを定期的に取得する（SQL、実行計画、バインド変数、実行統計等）
候補となるインデックスの特定
- 性能向上する可能性のあるインデックス候補を特定し、UNUSABLEかつINVISIBLEの状態で作成する
インデックスの評価
- 2で作成したインデックス候補について、実際にSQLを実行し、評価する。
  インデックスの評価はアプリケーションの外側で実施され、システムに影響は与えない。
インデックスの決定
- 3で有効と判断されたインデックスをREBUILD後、VISIBLEにして利用可能状態にする。
オンライン検証
- オンラインでインデックスの有効性を検証する
監視
- インデックスの利用状況を継続的に監視し、長期間利用されていないインデックスは削除する

VISIBLE、INVISIBLE、UNUSABLEって？

VISIBILITYとSTATUS

Oracleでは、インデックスの設定項目として「VISIBILITY」と「STATUS」という項目があり、インデックスごとにそれぞれ値を持ちます。
なお、ALL_INDEXESテーブル等で各インデックスの設定値を確認できます。

「STATUS」はインデックスの状態を表し、「VALID」あるいは「UNUSABLE」の値を持ちます。
「VALID」の場合、当該インデックスは利用可能な状態で、「UNUSABLE」の場合は利用禁止の状態です。

「VISIBILITY」はオプティマイザ（※）からの可視性を表し、「INVISIBLE」あるいは「VISIBLE」の値を持ちます。
「VISIBLE」の場合、オプティマイザから当該インデックスが見えている状態であり、SQLクエリ実行時に利用されます。
「INVISIBLE」の場合、オプティマイザから当該インデックスが見えていない状態であり、 SQLクエリ実行時には利用されません。
※オプティマイザ： SQLクエリの最適な処理方法を決定し、最良のパフォーマンスを提供する機能

自動インデックスの処理概要と照らし合わせて考えてみる

自動インデックス機能で各インデックスの「VISIBILITY」及び「STATUS」が適宜変更されますが、なぜそのような処理が実施されているのか考えてみます。

インデックスを「INVISIBLE」の状態にしておくと、上記の通り、SQLクエリ実行時にそのインデックスは利用されなくなるため、システムに影響を与えずにインデックスの評価ができるというわけです。
ただし、「INVISIBLE」にするとそのインデックスは利用されなくなりますが、DML（Update、Insert、Delete）実行時に更新はされます。つまり、システムでは利用しないインデックスのせいでDBに負荷がかかることになるわけですね。
そこで、「UNUSABLE」の出番です。「UNUSABLE」にしておけばDML実行時にインデックスは更新されません。
そのため、上記”2”の処理では、「UNUSABLE」かつ「INVISIBLE」の状態で評価対象のインデックスを作成するというわけですね。
ただし、「UNUSABLE」になっている場合、利用可能な状態にするには「REBUILD」の実行が必要です。
”4”の処理で「REBUILD」を実行しているのはこのためです。
「REBUILD」実行後、「VALID」の状態になり、システムで利用可能になります。
よくできてるなーと思いました。

文章だけだとイメージが掴みにくいため、「VISIBILITY」と「STATUS」のそれぞれの設定値におけるインデックスの状態を整理してみました。

その機能、止まるよ

その自動インデックスですが、運用フェーズに入って発生した問題があります。

そうです、止まっていたのです。
※厳密には「機能していない状態になった」です（後述）。

当初、Oracleのバグかと想定していたのですが、違いました。

事象

前述した処理概要 1～6 の一覧の処理サイクルを自動インデックスタスクと呼びますが、自動インデックスタスクには最大実行時間というものが設定（デフォルトでは1時間）されています。
最大実行時間を超過するとそのタスクは打ち切られ、再度タスクが実行されますが、3回連続で最大実行時間を超過すると自動インデックスタスクは24時間一時停止します。
24時間後、自動インデックスタスクは再開しますが、再び最大実行時間を超過するとまた24時間一時停止します。

最大実行時間の超過と24時間の一時停止を繰り返し、自動インデックスが機能していない状態になっていました。
Oracleサポートに確認したところ、仕様通りの動作ということでしたが、2024年1月現在、この仕様についてOCIの公式ドキュメント上に記載はないので、今後の利用者の方々のためにぜひ記載してもらえるとありがたいです。

最大実行時間を超過したのであれば、次回の実行では処理量を減らすなどして調整してくれればよいのですが、そのようなことはしてくれません。となると、一度最大実行時間を超過したら、24時間の一時停止後に再開したとて結局超過するのでは。。