テックノート

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

  • DB(Oracle Database)
2014.02.27

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

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

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


Vol.3 ILMの自動化で運用は楽になるのか

自動化はOracle Databaseならではの強み


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

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

機能名 概要
自動メモリー管理 システム・グローバル領域(SGA)とプログラム・グローバル領域(PGA)をまとめて自動的に調整する機能。
自動共有メモリー管理 システム・グローバル領域(SGA)とプログラム・グローバル領域(PGA)をそれぞれ自動的に調整する機能。Linux環境でHugePagesを使用している場合、自動メモリー管理ではなく必ずこちらを使用する。
自動化メンテナンス・タスク 一定の間隔でデータベースのメンテナンス操作を自動的に実行する機能。自動オプティマイザ統計収集などが含まれる。
自動ストレージ管理(ASM) データのストライピング、ミラーリング、リバランシングを自動的に行うボリューム・マネージャ。Real Application Clusters(RAC)環境を中心に多く採用されている。
自動ワークロード・リポジトリ(AWR) データベースのパフォーマンス統計やセッション・アクティビティの履歴などを自動的に収集/保存する機能。トラブル・シューティングにおいて効果を発揮し、Enterprise Managerを使用してWebブラウザからも情報を参照できる。
自動データベース診断モニター(ADDM) AWRで収集した情報をもとに、パフォーマンス問題の分析と推奨事項の提示を自動的に行う機能。潜在的な問題を早期に検出できる。
自動SQLチューニング AWRで収集した情報をもとに、CPU時間やI/O回数の値が大きいSQLを自動的にチューニングする機能。Oracle Database 11.2.0.2以降ではチューニングのレポートも作成できる。

11gR2までに実装されている代表的な自動化の機能

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

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

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

Automatic Data Optimization(ADO)とHeat Map


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

データのアクセス特性とストレージ要件

データのアクセス特性とストレージ要件

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

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

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

ADOで設定できるポリシー

ADOで設定できるポリシー

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

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

Heat Mapによる可視化のイメージ

Heat Mapによる可視化のイメージ

データが自動的に移動/圧縮されるまでの流れ


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

Heat Mapの有効化


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

セグメントレベルで最後にアクセスされた日付を確認

Heat Mapの動作イメージ

Heat Mapの動作イメージ

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

ADOポリシーの定義

ADOポリシーの定義

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

ADOとHeat Mapによる性能への影響


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

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

検証結果:TPSとレスポンス・タイムの比較

検証結果: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とレスポンス・タイムの比較

検証結果: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


執筆者のご紹介

アシスト関 俊洋

関 俊洋
ビジネスインフラ技術本部

2006年入社。データベース・システムの構築や運用トラブルの解決といった業務を経験し、その後新製品の検証やソリューションの立ち上げを経てエバンジェリストへ。2016年にクラウド事業を立ち上げ、現在はクラウドとデータベースの二足の草鞋を履いている。

本記事をご覧いただいている方へのご案内

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


関連している記事

  • DB(Oracle Database)
2020.01.28

Oracle OpenWorld 2019 視察記

2019年9月16~19日に開催された世界最大規模のITイベントOracle OpenWorld 2019の様子を紹介します。

  • DB(Oracle Database)
2019.09.18

超入門「PL/SQL」

Oracle Database向けにデータベース言語 SQLを拡張したプログラミング言語であるPL/SQLを理解し、活用していくための実践講座です。

  • DB(Oracle Database)
2019.01.29

Oracleサポート出張所

Oracle Databaseで発生するトラブルを「どんな方法で」「どのように」解決していくか。データベースの運用管理において、より円滑に業務を進めるために必要なノウハウを紹介していきます。

ページの先頭へ戻る