Multitenantのリソース管理や旧バージョンからの移行方法について解説しました。今回は12cで強化されたILM(情報ライフサイクル管理)関連の機能について取り上げます。Databaseには初期リリースであるV2から12cまで35年を超える歴史がありますが、RDBMSとしての基本的な機能は8iや9iの時点でほぼ実装を終えています。10g以降のリリースでは、運用管理コストを削減したり、作業の効率性を高めるといった顧客の課題解決を第一に考えた新機能が目立つようになってきました。Databaseならではの強みと言えるのが「自動化」に関する機能です。手動でコマンドを発行したり、スクリプトやプログラムとして作り込みが必要だった部分を自動化することで、運用フェーズのコストを大きく削減することができます。システム・グローバル領域(SGA)とプログラム・グローバル領域(PGA)をまとめて自動的に調整する機能。システム・グローバル領域(SGA)とプログラム・グローバル領域(PGA)をそれぞれ自動的に調整する機能。Linux環境でHugePagesを使用している場合、自動メモリー管理ではなく必ずこちらを使用する。一定の間隔でデータベースのメンテナンス操作を自動的に実行する機能。自動オプティマイザ統計収集などが含まれる。データのストライピング、ミラーリング、リバランシングを自動的に行うボリューム・マネージャ。Clusters(RAC)環境を中心に多く採用されている。データベースのパフォーマンス統計やセッション・アクティビティの履歴などを自動的に収集/保存する機能。Managerを使用してWebブラウザからも情報を参照できる。AWRで収集した情報をもとに、パフォーマンス問題の分析と推奨事項の提示を自動的に行う機能。潜在的な問題を早期に検出できる。AWRで収集した情報をもとに、CPU時間やI/O回数の値が大きいSQLを自動的にチューニングする機能。11.2.0.2以降ではチューニングのレポートも作成できる。11gR2までに実装されている代表的な自動化の機能ここでは代表的な機能だけを取り上げましたが、「自動」と名のつくものだけでも相当な数があります。Databaseを運用する上で欠かせない存在になっています。Databaseが優れている点の1つと言えるでしょう。このように、今や当たり前となっている自動化の機能ですが、必ずしもリリース直後から積極的に採用されてきたわけではありません。10gで自動共有メモリー管理が実装された当初は、「悪い方向に自動調整されないか心配」「新機能で実績が少ない」といった理由で敬遠されることもありました。運用実績が増えてからはこうしたネガティブな意見はあまり聞かなくなりましたが、手動でのメモリー管理をそのまま使い続けているというケースも存在します。仕様がどの程度明らかにされているかも重要で、あまりにもブラック・ボックスの部分が多すぎると安心して利用することができません。最近ではマニュアルやナレッジ・ベースの情報が充実していますが、性能など実際に検証してみないと分からない部分もあります。自動化が便利な機能であることは間違いありませんが、いわゆる「枯れた」機能になるためには実績とナレッジの充実が不可欠であると言えます。そこで今回は、12cの新機能であるILM(情報ライフサイクル管理)の自動化について、実際の検証結果を交えながら内部動作を詳しく紹介していきます。MapILMとは、アクセス頻度や利用目的に応じてデータを最適に配置することで、ストレージへの投資を効率化したり、法令に則ったデータの保管や活用を支援するという考え方です。データベースには多種多様なデータが格納されますが、「頻繁に更新されるもの」「更新はされないが参照はされるもの」「更新も参照もほとんどされないもの」など、様々な特性があります。多くのケースでは、以下のようにデータが発生してから時間が経過するにつれてアクセス頻度が低くなり、稀に参照されるだけの状態になります。このようなデータを更新に強い高性能なストレージに配置しておく必要はないため、安価で大容量のストレージに配置し直そうというのがILMの基本概念となります。DatabaseでILMを実現するための機能には、パーティショニングや圧縮があります。時系列でパーティションを分けるレンジ・パーティションやインターバル・パーティションを使用すれば、最新のデータと過去のデータを物理的に分けることができます。圧縮を組み合わせることで容量を抑え、データ量の増加にも対応できます。機能としては非常に便利なパーティショニングと圧縮ですが、その一方で課題もあります。パーティションを別のストレージに移動したり、データを圧縮するタイミングを管理者が判断しながら運用しなければなりません。「作成から一定の日数が経過した」「1ヵ月以上アクセスがなかった」「表領域の空きが80%を下回った」など様々なタイミングでの実施を考慮しなければなりません。そのため、ILMの機能はあってもなかなか実装まで至らないという状況が多く見られました。」という新機能が実装されました。ADOを使用すると、管理者が定義したポリシーをもとに自動でデータの移動や圧縮が行われるため、管理の負荷を軽減することができます。ADOで設定できるポリシーは以下のとおりです。ADOで設定できるポリシーここで注目すべきなのは、条件の中に「更新がなかった場合」「アクセスがなかった場合」という項目があることです。Map」という機能でアクセス頻度を記録することができるようになりました。MapというとWebページのどこがクリックされているのかを可視化できるツールとして有名ですが、12cではその考え方をデータベースに応用しています。MapとADOを組み合わせることによって、長期間アクセスされていないデータを識別して自動的に移動または圧縮することができます。Compressionオプションの新機能として提供されています。Mapを有効にする必要があります。Mapが有効になります。heat_mapパラメータはSYSTEMレベルとSESSIONレベルのどちらでもONにできますが、SYSTEMレベルでないとADOが利用できません。アクセス頻度の記録はSYSTEMとSYSAUX表領域以外が対象となるので注意が必要です。Mapが有効になると、SGA上に情報が蓄積されていき、V$HEAT_MAP_SEGMENTビューでその情報を確認できるようになります。SGA上の情報は1時間ごとにディスクにフラッシュされ、SYSAUX表領域にあるHEAT_MAP_STATS$表に格納されます。収集した情報はセグメント、エクステント、ブロックのレベルでそれぞれディクショナリ・ビューから問い合わせることができます。以下の例では、SCOTTユーザのセグメントについて最後に更新/参照された日付を表示しています。日付が古いようであれば、その表には普段ほとんどアクセスがないということが分かります。Mapによる記録が開始されたら、続いてADOのポリシーを定義します。以下の例ではEMP表に対して30日間更新がなかったら自動的に行レベル(ブロック単位)の圧縮を行うというポリシーを定義しています。圧縮の他にも、表領域が一杯になったらセグメントを移動させるなどの様々なポリシーを定義することができます。ADOポリシーの定義ポリシーを定義すれば、ILMを自動化するための設定は完了です。あとは自動的にポリシーが評価され、データの移動や圧縮が行われるようになります。ポリシーの評価は行レベルであればMMONが15分間隔で行い、それ以外のセグメントや表領域レベルの場合は日次のメンテナンス・ウィンドウで行われます。今回の例では30日後に自動圧縮されますが、試しに今すぐ自動実行させたいという場合はちょっとした裏技があります。(検証目的の手法なので、本番環境では使用しないでください。Mapでの情報収集が不可欠ですが、気になるのはデータベースに対する負荷です。ADOを使用するにはheat_mapパラメータをSYSTEMレベルで有効化する必要があるため、記録される情報は膨大な量になるはずです。そこでまずは、heat_mapパラメータをONにした場合とOFFにした場合で、性能にどの程度影響が出るかを比較してみます。Mapによる情報収集が絶え間なく行われるように、あえてOLTP系の処理を大量に実行しています。結果を見てみると、TPSとレスポンス・タイムともに10%程度の差が出ており、セッション数が多くなるほど差が開いていることが分かります。Mapの情報を書き出す処理やREDOの生成に起因する差であることも分かります。writes少し極端な結果かもしれませんが、heat_mapパラメータをSYSTEMレベルで有効にするということは、アクセスがあった分だけ記録を残すという動作になるので性能面での考慮は必要です。セグメント数やセッション数などに応じて結果が変わってくるため、しっかりとした性能検証が必要な機能と言えるでしょう。ひとつ気をつけたいのは、ADOによって自動的に圧縮/移動されるデータの量です。あまりにも大容量のデータが対象になる場合、実行完了まで時間がかかってしまいます。ADOの処理は日次のメンテナンス・ウィンドウで実行されますが、圧縮/移動にはそれなりのI/Oが伴うため、オンライン系の処理や夜間バッチとバッティングしないよう注意が必要です。重複してしまった場合、どのような影響が出るのかを検証したのが以下のグラフです。検証結果:TPSとレスポンス・タイムの比較TPS、レスポンス・タイムともに多少の影響が出ていることが分かります。今回は3つのセグメントを自動移動させていますが、ADOでは移動/圧縮対象が複数存在した場合にそれらをまとめて並列実行するため、30GB分のI/Oが一度に行われます。そのため瞬間的にI/O負荷が高まりやすく、他の処理とバッティングしないよう注意が必要です。Mapは設定による影響や仕様をある程度理解した上で使うべき機能と言えます。これまでの自動化機能にも言えることですが、便利だからといって安易に利用するのではなく、どういうシーンで効果を発揮できるものかを明らかにし、賢く付き合っていくことが重要です。Clusters(RAC)について検証結果を紹介します。俊洋ビジネスインフラ技術本部2006年入社。データベース・システムの構築や運用トラブルの解決といった業務を経験し、その後新製品の検証やソリューションの立ち上げを経てエバンジェリストへ。2016年にクラウド事業を立ち上げ、現在はクラウドとデータベースの二足の草鞋を履いている。最後までご覧いただきありがとうございました。本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。2019の様子を紹介します。SQLを拡張したプログラミング言語であるPL/SQLを理解し、活用していくための実践講座です。Databaseで発生するトラブルを「どんな方法で」「どのように」解決していくか。データベースの運用管理において、より円滑に業務を進めるために必要なノウハウを紹介していきます。