移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.3

前回はOracle Database 12c（以下、12c）の目玉機能であるOracle Multitenantのリソース管理や旧バージョンからの移行方法について解説しました。今回は12cで強化されたILM（情報ライフサイクル管理）関連の機能について取り上げます。

Oracle Databaseには初期リリースであるV2から12cまで35年を超える歴史がありますが、RDBMSとしての基本的な機能は8iや9iの時点でほぼ実装を終えています。10g以降のリリースでは、運用管理コストを削減したり、作業の効率性を高めるといった顧客の課題解決を第一に考えた新機能が目立つようになってきました。

その中でも、Oracle Databaseならではの強みと言えるのが「自動化」に関する機能です。手動でコマンドを発行したり、スクリプトやプログラムとして作り込みが必要だった部分を自動化することで、運用フェーズのコストを大きく削減することができます。Oracle Database 11gR2（以下、11gR2）までに実装されている代表的な自動化の機能は以下のとおりです。

ここでは代表的な機能だけを取り上げましたが、「自動」と名のつくものだけでも相当な数があります。パフォーマンスの改善や問題解決に直結するような機能がほとんどで、もはやOracle Databaseを運用する上で欠かせない存在になっています。他のRDBMSと比べてOracle Databaseが優れている点の1つと言えるでしょう。

このように、今や当たり前となっている自動化の機能ですが、必ずしもリリース直後から積極的に採用されてきたわけではありません。例えば10gで自動共有メモリー管理が実装された当初は、「悪い方向に自動調整されないか心配」「新機能で実績が少ない」といった理由で敬遠されることもありました。運用実績が増えてからはこうしたネガティブな意見はあまり聞かなくなりましたが、手動でのメモリー管理をそのまま使い続けているというケースも存在します。

また、仕様がどの程度明らかにされているかも重要で、あまりにもブラック・ボックスの部分が多すぎると安心して利用することができません。最近ではマニュアルやナレッジ・ベースの情報が充実していますが、性能など実際に検証してみないと分からない部分もあります。自動化が便利な機能であることは間違いありませんが、いわゆる「枯れた」機能になるためには実績とナレッジの充実が不可欠であると言えます。そこで今回は、12cの新機能であるILM（情報ライフサイクル管理）の自動化について、実際の検証結果を交えながら内部動作を詳しく紹介していきます。

ILMとは、アクセス頻度や利用目的に応じてデータを最適に配置することで、ストレージへの投資を効率化したり、法令に則ったデータの保管や活用を支援するという考え方です。データベースには多種多様なデータが格納されますが、「頻繁に更新されるもの」「更新はされないが参照はされるもの」「更新も参照もほとんどされないもの」など、様々な特性があります。多くのケースでは、以下のようにデータが発生してから時間が経過するにつれてアクセス頻度が低くなり、稀に参照されるだけの状態になります。このようなデータを更新に強い高性能なストレージに配置しておく必要はないため、安価で大容量のストレージに配置し直そうというのがILMの基本概念となります。

Oracle DatabaseでILMを実現するための機能には、パーティショニングや圧縮があります。例えば時系列でパーティションを分けるレンジ・パーティションやインターバル・パーティションを使用すれば、最新のデータと過去のデータを物理的に分けることができます。また、圧縮を組み合わせることで容量を抑え、データ量の増加にも対応できます。

機能としては非常に便利なパーティショニングと圧縮ですが、その一方で課題もあります。パーティションを別のストレージに移動したり、データを圧縮するタイミングを管理者が判断しながら運用しなければなりません。例えば「作成から一定の日数が経過した」「1ヵ月以上アクセスがなかった」「表領域の空きが80%を下回った」など様々なタイミングでの実施を考慮しなければなりません。そのため、ILMの機能はあってもなかなか実装まで至らないという状況が多く見られました。

こうした背景があり、12cではILMを自動化する「Automatic Data Optimization（ADO） 」という新機能が実装されました。ADOを使用すると、管理者が定義したポリシーをもとに自動でデータの移動や圧縮が行われるため、管理の負荷を軽減することができます。ADOで設定できるポリシーは以下のとおりです。

ここで注目すべきなのは、条件の中に「更新がなかった場合」「アクセスがなかった場合」という項目があることです。11gR2までのバージョンには、いつそのデータにアクセスしたかという情報をデータベース側に記録する仕組みはありませんでしたが、12cでは「Heat Map」という機能でアクセス頻度を記録することができるようになりました。

Heat MapというとWebページのどこがクリックされているのかを可視化できるツールとして有名ですが、12cではその考え方をデータベースに応用しています。Heat MapとADOを組み合わせることによって、長期間アクセスされていないデータを識別して自動的に移動または圧縮することができます。なお、ADOはOracle Advanced Compressionオプションの新機能として提供されています。

データを自動的に移動／圧縮するためには、まずデフォルトで無効になっているHeat Mapを有効にする必要があります。手順は簡単で、初期化パラメータのheat_mapをONにするだけでHeat Mapが有効になります。heat_mapパラメータはSYSTEMレベルとSESSIONレベルのどちらでもONにできますが、SYSTEMレベルでないとADOが利用できません。また、アクセス頻度の記録はSYSTEMとSYSAUX表領域以外が対象となるので注意が必要です。

Heat Mapが有効になると、SGA上に情報が蓄積されていき、V$HEAT_MAP_SEGMENTビューでその情報を確認できるようになります。SGA上の情報は1時間ごとにディスクにフラッシュされ、SYSAUX表領域にあるHEAT_MAP_STATS$表に格納されます。収集した情報はセグメント、エクステント、ブロックのレベルでそれぞれディクショナリ・ビューから問い合わせることができます。以下の例では、SCOTTユーザのセグメントについて最後に更新／参照された日付を表示しています。もし日付が古いようであれば、その表には普段ほとんどアクセスがないということが分かります。

Heat Mapによる記録が開始されたら、続いてADOのポリシーを定義します。以下の例ではEMP表に対して30日間更新がなかったら自動的に行レベル（ブロック単位）の圧縮を行うというポリシーを定義しています。圧縮の他にも、表領域が一杯になったらセグメントを移動させるなどの様々なポリシーを定義することができます。

ポリシーを定義すれば、ILMを自動化するための設定は完了です。あとは自動的にポリシーが評価され、データの移動や圧縮が行われるようになります。ポリシーの評価は行レベルであればMMONが15分間隔で行い、それ以外のセグメントや表領域レベルの場合は日次のメンテナンス・ウィンドウで行われます。今回の例では30日後に自動圧縮されますが、試しに今すぐ自動実行させたいという場合はちょっとした裏技があります。詳しくは「Oracle Database 12c Learning Library」にある「Setting Up Compression Tiering for Automatic Data Optimization 」をご参照ください。（検証目的の手法なので、本番環境では使用しないでください。）

ADOによるILMの自動化にはHeat Mapでの情報収集が不可欠ですが、気になるのはデータベースに対する負荷です。ADOを使用するにはheat_mapパラメータをSYSTEMレベルで有効化する必要があるため、記録される情報は膨大な量になるはずです。そこでまずは、heat_mapパラメータをONにした場合とOFFにした場合で、性能にどの程度影響が出るかを比較してみます。

＜検証方法＞
・32個のセグメントを用意 （合計サイズ：20GB）
・OLTP処理を複数セッションから同時実行
・heat_map=ON/OFFの両パターンでTPSとレスポンス・タイムを比較

今回はHeat Mapによる情報収集が絶え間なく行われるように、あえてOLTP系の処理を大量に実行しています。結果を見てみると、TPSとレスポンス・タイムともに10%程度の差が出ており、セッション数が多くなるほど差が開いていることが分かります。また、以下のような待機イベントが発生していることから、Heat Mapの情報を書き出す処理やREDOの生成に起因する差であることも分かります。

・Heatmap BlkLevel Flushed
・Heatmap SegLevel Segments flush
・redo entries
・redo writes

少し極端な結果かもしれませんが、heat_mapパラメータをSYSTEMレベルで有効にするということは、アクセスがあった分だけ記録を残すという動作になるので性能面での考慮は必要です。セグメント数やセッション数などに応じて結果が変わってくるため、しっかりとした性能検証が必要な機能と言えるでしょう。

もうひとつ気をつけたいのは、ADOによって自動的に圧縮／移動されるデータの量です。あまりにも大容量のデータが対象になる場合、実行完了まで時間がかかってしまいます。ADOの処理は日次のメンテナンス・ウィンドウで実行されますが、圧縮／移動にはそれなりのI/Oが伴うため、オンライン系の処理や夜間バッチとバッティングしないよう注意が必要です。もし重複してしまった場合、どのような影響が出るのかを検証したのが以下のグラフです。

＜検証方法＞
・3つのセグメントを用意 （合計サイズ：30GB）
・OLTP処理を複数セッションから同時実行
・実行中にADOのポリシーでセグメントを別の表領域に移動
・移動中とそうでない場合でTPSとレスポンス・タイムを比較

TPS、レスポンス・タイムともに多少の影響が出ていることが分かります。今回は3つのセグメントを自動移動させていますが、ADOでは移動／圧縮対象が複数存在した場合にそれらをまとめて並列実行するため、30GB分のI/Oが一度に行われます。そのため瞬間的にI/O負荷が高まりやすく、他の処理とバッティングしないよう注意が必要です。

これらの検証結果から、ADOとHeat Mapは設定による影響や仕様をある程度理解した上で使うべき機能と言えます。これまでの自動化機能にも言えることですが、便利だからといって安易に利用するのではなく、どういうシーンで効果を発揮できるものかを明らかにし、賢く付き合っていくことが重要です。

次回は12cのReal Application Clusters（RAC）について検証結果を紹介します。

・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.6
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.7

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。