Oracle Autonomous Database（以降、「ADB」と表記）は、運用コストを大幅に削減可能な世界初の自律型データベースとして2017年にリリースされました。
企業が抱えるデータ量の増大やDBMSの多機能化・複雑化等によって、データベースの運用コストは増加傾向にあるため、運用コストを大幅に削減できる可能性があるADBのリリースは非常に注目を集めました。以来、ADBは、データベースの移行先として検討対象に上がることが多いサービスだと思います。
しかし、「運用コストの削減」と「使い勝手の良さ」は必ずしも両立できるものではありません。ADBはフルマネージド・サービスであるため、オンプレのOracle Databaseでは設定変更可能だったが、ADBでは設定変更不可である、ということがあります。
ADBへの移行を決定したものの、既存運用に当てはめることができなかった、逆に不便な運用となってしまった、といった事態は避けたいものです。
本稿では、Oracle Autonomous Database Sharedの構築経験から、移行を決定する前に知っておきたい、ADB Sharedの注意点をご紹介します。
大部分の初期化パラメータは変更できない
ADBは自律型データベースであり、細かいことを気にする必要はない、というコンセプトであるため大部分の初期化パラメータが変更できません。
例えば、DBAならば気にしない人はいないパラメータ「SGA_TARGET」や「PGA_AGGREGATE_TARGET」、「SESSIONS」は、ADBに割り当てたCPU数に比例して自動で増加します。
変更可能なパラメータはマニュアルに記載がありますので、以下URLをご参照ください。
共有Exadataインフラストラクチャ上のOracle Autonomous Databaseの使用 ｜ Oracleヘルプセンター
自動バックアップの稼動時間は変更できない
ADBでのデータベースのバックアップ取得方法は自動、手動の2種類あり、手動は任意のタイミングで実行可能、自動は週次でフルバックアップ、日次で増分バックアップが稼動します。
この自動バックアップに関して、稼働時間を指定、変更することができず、自動バックアップを取らない設定にすることもできないので、いつバックアップが稼動するかわかりません。
とは言っても、1TBあるデータベースのバックアップがわずか数分で完了しますので、CPU等のリソースがシビアな状況でなければそこまで気にする必要もないかもしれません。
自動メンテナンスタスクの稼働時間が変更できない
自動統計情報取得、SQLチューニングアドバイザなどの自動メンテナンスタスクの稼働時間はデフォルトだと平日は22時-翌2時(計4時間)、土曜、日曜は午前6時-22時(計16時間)の設定になっていますが、上記稼働時間を変更することができません。
特に、統計情報の取得タイミングは重要ですので、必要に応じて統計情報取得コマンドを定期実行する仕組みを作る等、手当が必要になるかもしれません。
なお、データベースのタイムゾーンはデフォルトだとUTCであり、これを日本時間(JST)に変更しないと平日は朝7時-11時、土曜、日曜は15時-翌7時に稼働することになってしまいますので、こちらも非常に重要な注意点です。
sysdate、systimestamp関数の結果がUTC表示となる
ATPが稼動しているサーバのOSのタイムゾーン設定がUTCであり、
sysdate関数、systimestamp関数はOSのタイムゾーンを基準に時刻を返しますので
当関数を使用すると結果がUTCで返されることになります。
例えば、日本時間(JST)で16時にsysdate関数を実行すると、-9時間となる7時で時間が表示されます。
上記関数を使用している場合はそれぞれ以下表の通りに置き換える必要があります。
| 置き換え前 | 置き換え後 | |
| sysdate関数 | sysdate | current_date |
| systimestamp関数 | systimestamp | current_timestamp |
表領域の自動拡張設定がインスタンス再起動によって自動的に自動拡張有に変更される
表領域の自動拡張設定は「自動拡張しない」設定とすることが可能ですが、
ADBのインスタンスを再起動すると、デフォルトである「自動拡張する」設定へと自動で変更されてしまいます。
ADBの利用料を極力抑えるためにADBを定期的に停止する運用を検討されることもあるかと思いますので、表領域の自動拡張設定は変更しない方が望ましいです。
自動タスクの稼働により想定外にCPU使用量が増える
ADBは自立型データベースですので、業務以外にも様々な自動タスクが稼動しています。
特に、以下のタスクは有効となっている場合にCPUの使用量が多くなりがちです。
| No. |
タスク |
概要 |
デフォルト |
備考 |
| 1 |
自動索引機能 |
アプリケーション・ワークロードを監視して、自動的に索引作成や削除等の管理を行う |
無効 |
- |
| 2 |
高頻度自動オプティマイザ統計収集 |
全データの10%以上が更新された表について、自動でオプティマイザ統計を取得する |
有効 |
無効化が可能。また、タスクの実行間隔や実行時間を制御可能 |
| 3 |
リアルタイム統計収集 |
DML操作(insert,update,delete)実行時に統計を収集する |
有効 |
無効化するにはヒント句NO_GATHER_OPTIMIZER_STATISTICSを使用する |
例えば、ADBに単純移行する等の理由からCPUを現行と同等の性能となる想定で割り当てを行うと、自動タスクが稼動している分だけCPUの使用量が増え、当初の見積よりもCPUを増やすことになったり、業務を圧迫したりする可能性がありますので、要注意です。
おわりに
以上、ADB移行検討時の注意点についてご紹介しました。
ADBでは、運用コストを低下させるために様々な制約がありますので、これは想定外だった！という状況を避けるために事前に多くの情報を仕入れておくことが重要だと考えています。
本稿が皆様のADB検討の一助になれば幸いです。
