はじめに
本blogではコストについての記載なども含まれ、内容は執筆時のものとなります。最新の公式ドキュメントを確認の上、ご自身の責任のもとでご活用ください。（特にストレージのコストはバックアップなども別途かかる場合があるため、ご注意ください）
Autonomous AI Databaseの基礎的な点については知っていることが前提となります。また、基本的には トランザクション処理(旧ATP) ベースの記載となります。
Autonomous AI Database Serverless はCPUリソース、ストレージリソースともにオンラインで変更することが可能です。
ストレージの自動スケーリング の機能は、デフォルトでは無効ですが有効にすると予約ベースラインの３倍までストレージが利用可能となります。
- 「その他のアクション」
- 「リソース割当ての管理」
- 「ストレージの自動スケーリング」
- 「リソース割当ての管理」
後述するストレージ縮小機能は、この「ストレージの自動スケーリング」が前提となるため、本blogでは自動スケーリングが有効となっている前提の内容を記載します。
Autonomous AI Databaseのストレージ課金の考え方
Autonomous AI Databaseのストレージにおいて利用状況と課金の仕組みは次の分類を理解しておく必要があります。
- 使用済ストレージ
- データベースで実際に使用している領域
- 割当済ストレージ
- データベースに割当てられている領域
- 予約済ストレージ
- 設定値
- 最大ストレージ
- 設定値（予約済みストレージ）の3倍
容量の関係性としては次のようになり、予約済ストレージは利用においてはあまり意識する必要がありません。
- 使用済ストレージ ＜ 割当済ストレージ ＜ 最大ストレージ
一方で、課金の仕組みは次のようになります1。
- 割当済ストレージ ≦ 予約済ストレージ の場合 →予約済ストレージ
- 割当済ストレージ ≧ 予約済ストレージ の場合 →割当済ストレージ
割当済ストレージが予約済ストレージを超えるまでは設定値（予約済ストレージ）分の課金となりますが、割当が予約分を超えるとその割当分に対して課金が行われます。
ストレージ課金の例
次のグラフのような状況を例として考えてみます。
前提としてストレージの自動スケーリングは有効、100GBを予約している形です。
| 状況 | 使用済(GB) | 割当済(GB) | 予約済(GB) | 最大(GB) | 請求対象(GB) | |
|---|---|---|---|---|---|---|
| ① | 未使用 50GBが割当済 |
0 | 50 | 100 | 300 | 100 |
| ② | 100GBを使用 100GB(使用済＝割当済) |
100 | 100 | 100 | 300 | 100 |
| ③ | 200GBを使用 200GB(使用済＝割当済) |
200 | 200 | 100 | 300 | 200 |
| ④ | 150GB分削除 50GBが実際に使用 割当済ストレージは200GBで変わらない |
50 | 200 | 100 | 300 | 200 |
| ⑤ | 150GB分の割当済ストレージを解放 50GB(使用済＝割当済) |
50 | 50 | 100 | 300 | 100 |
※ 実際には使用済ストレージは 0 にはできませんし、使用済＝割当済と完全に一致することはありませんのでご注意ください
④ の状況について少し補足します。Oracle Databaseを利用している方は認識があると思いますが、データが削除されても領域が解放されるわけではありません。基本的には自動で解放もされないため「ストレージの縮小」を実行する必要があります。
ストレージの縮小
Autonomous AI Database でストレージの縮小を行う場合、次の条件が必要になります2。
- ストレージ自動スケーリングが有効であること
- 割当済ストレージ ＞ 予約済ストレージ
- 割当済ストレージ ー 使用済ストレージ ＞ 100GB
縮小操作においては以下の注意点が述べられています。
- 内部的に
alter table... move onlineが実行されるため、CPUに負荷がかかる - 次のオブジェクトが含まれていると縮小操作自体が実行できない
- ベクトルインデックス
- トランザクション・イベント・キュー
- MEMOPTIMIZE FOR WRITE表
- ROWIDデータ型の列値は変更される可能性がある
- 次のオブジェクトを含む表はオフラインになる
- ビットマップ結合索引を持つ表
- ネストされた表
- オブジェクトテーブル
- 不変表
- ブロックチェーン・テーブル
- ドメイン索引があるパーティション表
- 縮小操作をデータ削除操作の直後に実行する場合、失敗する可能性がある
縮小操作の例
最初の状態
adbtest1 というデータベースへテストデータを大量（200GB弱）に格納した状態にしました。予約済ストレージは100GBに、自動スケーリングを有効にしています。
（※）SQLで実行して取得したデータと画面から参照できるデータに若干ずれがありますが、SQLの四捨五入などの過程で出ていると想定しています
この状態で「縮小」を実施しようとすると、次のポップアップが出て縮小できません。
テストデータ削除
大量にデータが格納されたテーブルをTruncateし、状況を確認すると次のような状態になります。
Truncate直後はOCIコンソール上に使用済みストレージの減少は表示されませんが、少し経つと反映されます。
ストレージ縮小の実行
縮小を押下すると、以下のように解放される領域含めてメッセージが出ますので「続行」します。
今回は30分くらいかかりましたが、無事完了しました。
割当済ストレージも縮小されていることが確認できます。
縮小実施時のリソース使用状況ですが、AWRレポート上では縮小処理はほぼ単一のセッションで実施されており、CPU割当を増やすことで縮小処理の速度が向上するようには見受けられませんでした。
まとめ
Autonomous AI Databaseの自動スケーリング機能は基本的にオンラインでリソースを変更することが可能で、且つ従量制となるので利用しないと勿体ない機能の一つになるかとは考えてます。
割当済ストレージの縮小も、以前はOracleでも（いろんな意味で）高コストな処理の一つではありましたが、Autonomous AI Databaseではハードルは下がっていると思いますので、是非活用してみてもらえればと考えてます。