Oracle Database 18cを使用した 自動データ最適化 Oracle ホワイト・ペーパー | 2018 年 2 月

Oracle Database 18c を使用した自動データ最適化

目次 免責事項 ........................................................................................................................................................... 1

はじめに ........................................................................................................................................................... 2

ストレージ階層化と圧縮階層化 ................................................................................................................. 3

ヒートマップ -- データ利用状況の詳細な追跡 ........................................................................................ 4

データの自動最適化 ...................................................................................................................................... 4

結論 ................................................................................................................................................................. 10

免責事項 下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供

を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルや

コード、機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材

料になさらないでください。オラクルの製品に関して記載されている機能の開発、リリース、

および時期については、弊社の裁量により決定されます。

2 | Oracle Database 18cを使用した自動データ最適化

はじめに 企業が保存し管理しているデータ量は急増しています。各種業界の概算によると、データ量は

2、3 年ごとに倍増しています。データの急増により、IT はコストとパフォーマンスの両面に

おいて困難な課題に直面しています。

ストレージのコストは下がり続けているにもかかわらず、データ量の急増により、ストレージは

大部分の IT 予算における最大のコスト要因の 1 つとなっています。さらに、データの増加が加速

しているため、予算内に収めながらパフォーマンス要件に応えることが難しくなっています。

情報ライフ・サイクル管理（ILM）は、企業の現在のビジネス要件およびパフォーマンス要件

に応じて、異なるストレージ層と圧縮層にデータを保存することで、これらの課題に対処しま

す。このアプローチにより、ストレージを最適化し、コスト削減および最大のパフォーマンス

実現を目指します。

ヒートマップおよび自動データ最適化は、Oracle Advanced Compression の機能です。ヒート

マップは、変更および問合せのタイムスタンプを行レベルおよびセグメント・レベルで自動的

に追跡します。そのため、データがどのようにアクセスされているかについて詳細に把握でき

ます。自動データ最適化（ADO）は、ヒートマップによって収集された情報に基づくユー

ザー定義ポリシーに従って、データの移動と圧縮を自動的に行います。

ヒートマップと ADO によって、Oracle Database の各種圧縮テクノロジーやパーティション

化テクノロジーにすでに存在する革新技術を容易に使用できるようになるため、大量のデータ

にかかる管理コストが削減され、アプリケーションとデータベースのパフォーマンスが向上し

ます。これらの機能を組み合わせて、Oracle Database の第一級の情報ライフ・サイクル管理

戦略の実施に役立てることができます。

3 | Oracle Database 18cを使用した自動データ最適化

ストレージ階層化と圧縮階層化 企業は（1 つのアプリケーションの場合も）、すべてのデータに均等にアクセスするわけではありません。もっとも重要なデータや、もっとも頻繁にアクセスされるデータには、最高のパフォーマンスと可用性が必要です。すべてのデータにこのような最適な状態のアクセスを提供するのは、コストがかかって非効率的であり、多くの場合、アーキテクチャ的に不可能です。代わりに、IT 組織はストレージ階層化を実装します。

ストレージ階層化を実装すると、企業は異なる層のストレージにデータをデプロイできるため、アクセス回数の少ない（"コールドな"）データを、高額で最速のストレージとは別の場所へ移動できます。コールドなデータは引き続き利用できますが、アクセス速度は低速になります。しかしながら、アクセスがまれであるため、アプリケーション・パフォーマンス全体への影響は最小限にとどまります。コールド・データは、ストレージにおいて（アクティブ・データよりも）高い圧縮度で圧縮される場合もあります。オラクルでは、情報ライフ・サイクル管理（ILM） 1という用語を、データの作成および取得からアーカイブまたは削除に至る管理を指すために使用します。

図 1 は、もっともアクティブなデータが高パフォーマンス層に、非アクティブ・データや履歴データが低コスト層にあることを示しています。このシナリオでは、ビジネスはパフォーマンス、信頼性およびセキュリティ上の要件をすべて満たしていますが、データのすべてが高パフォーマンス（層 1）ストレージに存在する構成よりも大幅にコストが下がっています。この図は、非アクティブなストレージ層と履歴ストレージ層に対してより圧縮度の高い圧縮を行うことで、非アクティブ・データをスキャンする問合せのパフォーマンスを向上させながら、コストの削減も促進できることを示しています。

図1：パーティション化、Advanced Compression、およびHybrid Columnar Compression

ストレージ階層化に加えて、異なるタイプの圧縮を使用して、異なるアクセス・パターンに合わせることもできます。たとえば、コールド・データは、アクセスを遅くする代わりに、より高い圧縮度で圧縮できます。Oracle Database では、アプリケーションのパフォーマンス要件と可用性の要件を満たしながら、ホット/アクティブ・データからウォーム/非アクティブ・データやコールド/履歴データに至るまでのライフ・サイクルを通じて、データ移動に活用できる数種類の圧縮を提供しています。オラクルでは、これを圧縮階層化と呼びます。

1 Gartner による ILM の定義などを参照してください。ストレージ階層化では、データを異なるレベルのストレージ・サービスに割り当てる方法を

実施しますが、これは ILM に使用されるツールの 1 つです。

データは、Advanced Compression および/または Hybrid Columnar Compression を使用して、ストレージ層全体で圧縮されます。通常の圧縮率は 3 倍から 15 倍です。

データは、コスト、パフォーマンス、可用性、およびセキュリティの要件に基づいて、それぞれ異なる層に割り当てられます。

4 | Oracle Database 18cを使用した自動データ最適化

たとえ適切なストレージ機能や圧縮機能を用いたとしても、どのデータをどこに保存すべきか、そしてある層から別の層へいつデータを移行すべきか、は相変わらず深刻な課題です。Oracle Database 18cでは、データ・アクセス・パターンを自動的に検出する機能であるヒートマップによってこの課題に対処し、ヒートマップの情報を使用することにより、データ組成を自動的に最適化します（自動データ最適化）。本書の後半では、ストレージ階層化および圧縮階層化を実現する Oracle Database のテクノロジーと、それらを使用して情報ライフ・サイクル管理をサポートする方法について説明します。

ヒートマップ -- データ利用状況の詳細な追跡 Oracle Advanced Compression の一機能であるヒートマップは、表やパーティションの利用状況を行レベルおよびセグメント・レベルで自動的に追跡します。2データ変更時刻は行レベルで追跡されてブロック・レベルへ集計され、変更時刻、全表スキャン時刻、および索引検索時刻は、セグメント・レベルで追跡されます。ヒートマップにより、データがどのようにアクセスされ、アクセス・パターンが時間が経つにつれてどのように変化しているか、詳細に表示されます。ヒートマップ・データへは、一連の PL/SQL 表関数、およびデータ・ディクショナリ・ビューを通じて、プログラムによってアクセスできます。

図 2 は、ヒートマップ・データを表現するための方法の 1 つを示したものです。ボックスはそれぞれ、表の 1 つのパーティションを表しています。ボックスのサイズはパーティションの相対的なサイズを表し、ボックスの色は、パーティション内の任意の行への直近のアクセスに基づいて、どれだけそのパーティションが"ホット"（アクセスが頻繁）であるかを表しています。

図2：パーティション化された表へのアクセス・パターンを表すヒートマップ・データ

データの自動最適化 自動データ最適化を使用すると、データ圧縮（スマート圧縮）およびデータ移動のためのポリシーを作成して、ストレージ階層化および圧縮階層化を実装できます。スマート圧縮とは、ヒートマップ情報を利用して、圧縮ポリシーおよび圧縮レベルを実際のデータ使用状況に関連付ける機能を指します。

Oracle Database は、ADO ポリシーを定期的に評価し、ヒートマップによって収集された情報を使用して、データを移動および/または圧縮する時期を決定します。ADO の操作はすべて、ユーザーの介入なくバックグラウンドで自動的に実行されます。

2 データベース行は、データベース・ブロック内に保存され、エクステントにグループ化されます。セグメントは、表やパーティションといった表

領域内の論理ストレージ構造のデータすべてを含む、一連のエクステントです。

5 | Oracle Database 18cを使用した自動データ最適化

ADO ポリシーは、表および/またはパーティションのセグメント・レベルまたは行レベルで指定できます。ポリシーは、メンテナンス時間枠内にバックグラウンドで自動的に評価および実行されます。ADO ポリシーは、DBA によって、手動またはスクリプト経由で評価および実行することもできます。

ADO ポリシーでは、ADO 操作が開始されるための（データ・アクセスの）条件（アクセスなし、変更なし、または作成時刻など）、およびポリシーが有効になる時期（n 日後、n か月後または n年後など）を指定できます。ADO の“条件”は組み合わせることができないので注意してください。たとえば、表やパーティションの最初の ADO 条件で“変更なし”を使用した場合、同じ表やパーティションで用いられるその他の条件にも、同じ種類の条件を使用する必要があります。

ADO ポリシーの条件は、ヒートマップ・データに限定されません。PL/SQL ファンクションを使用してカスタム条件を作成し、独自のデータおよびロジックを使用するように ADO の柔軟性を拡張して、データを移動または圧縮する時期を決定することもできます。

次の例では、Advanced Row Compression と Hybrid Columnar Compression の両方を採用した、“ベスト・プラクティス”の圧縮アプローチを使用しています。圧縮階層化のベスト・プラクティスではHCC を使用していますが、HCC にアクセスできない場合は、ADO ポリシーで Advanced Row Compression のみを使用します。

自動データ最適化の例

以下の例では、販売注文を含む orders 表があり、その表は注文日によってレンジ・パーティション化されていることを前提とします。

最初の例では、Advanced Row Compression を使用して、30 日間変更されていないパーティションを自動的に圧縮するためのセグメント・レベルの ADO ポリシーを作成しています。ここでは、古い販売データが使用するストレージが自動的に削減されると同時に、表の古いパーティション内の多数の行を通じてスキャンする問合せのパフォーマンスが向上します。

ALTER TABLE orders ILM ADD POLICY ROW STORE COMPRESS ADVANCED SEGMENT AFTER 30 DAYS OF NO MODIFICATION;

以下の例では、Hybrid Columnar Compression を使用して、90 日間変更されていないパーティションを自動的により高い圧縮度で圧縮するためのセグメント・レベルの ADO ポリシーを作成しています。これは、HCC が使用でき、データがこれ以上更新されなくても問合せが継続するときは合理的ですが、HCC に移動することにより、大量のストレージを節約できると同時に、問合せパフォーマンスが大幅に向上します。

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY HIGH SEGMENT AFTER 90 DAYS OF NO MODIFICATION;

場合によっては、できる限り高速にデータをロードする必要があり、その場合は圧縮を無効にしてパーティションを作成することが求められます。そうすることで、表でロード後のアクティビティが終了した後に、圧縮を実装できます。ロード時間に関する SLA を有する企業では、可能な限り迅速に表を作成し、表にデータを入力してから、圧縮を実装できます。

6 | Oracle Database 18cを使用した自動データ最適化

次の例では、企業は圧縮のメリットを享受したいと考えているものの、SLA 要件も満たす必要があります。この場合、パーティションのデータをより細かい粒度で（セグメント全体ではなく、ブロックごとに）圧縮すると良いでしょう。行レベルの ADO ポリシーを作成することで、ブロック内のどの行も3 日以上変更されていないパーティションのブロックを自動的に圧縮できます。行レベルのポリシーでは、ブロック内のすべての行がポリシー条件を満たしてから、ブロックを圧縮する必要があります。

以下は、行が圧縮されずに挿入され、その後ブロックごとに Advanced Row Compression（Hybrid Columnar Compression では行レベルのポリシーも指定可能）へ移動される ADO ポリシーの例です。このポリシーでは、SEGMENT キーワードではなく、ROW キーワードが使用されていることに注意してください。

ALTER TABLE orders ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW AFTER 3 DAYS OF NO MODIFICATION;

上記のポリシーが実装されると、Oracle Database はメンテナンス時間枠内にブロックを評価し、該当するすべてのブロックを圧縮します。そうすることで、領域が解放され、新たな行を挿入できるようになります。これにより、データ・ロードのパフォーマンスを最大限に向上させることができるだけでなく、パーティション全体に圧縮の準備ができるのを待つことなく、ストレージを節約でき、圧縮のパフォーマンスも向上します。

スマート圧縮に加え、ADO ポリシーのアクションには、低コストのストレージ層や Oracle のHybrid Columnar Compression（HCC）などの他の圧縮機能を使用するストレージ層など、別のストレージ層へのデータ移動もあります。3

ADO ベースのストレージ階層化（Tier To）は、圧縮階層化とは異なり、ADO 条件句（AFTER “X” DAYS OF NO MODIFICATION）には基づかず、代わりに表領域の圧縮に基づきます。ストレージ階層化を"領域の圧縮"に依存させることを正当とする理由は、まさにご想像のとおりです。企業は、できるだけ多くのデータを高パフォーマンスの（かつもっとも高額な）ストレージ層に保存し、絶対に必要な状況になるまで低パフォーマンスのストレージ層には移動しないことを望でいるのです。ストレージ圧縮要件の例外は、'READ ONLY'オプションのあるストレージ階層化ポリシーです。これらはヒートマップ・ベースの条件句によってトリガーされます。

ADO パラメータ、TBS_PERCENT_USED の値では、表領域がいっぱいと見なされる場合の表領域割当て制限のパーセンテージを指定します。TBS_PERCENT_FREE の値では、表領域における対象の空きパーセンテージを指定します。表領域割当て制限のパーセンテージが TBS_PERCENT_USED の値に到達すると、ADO は、表領域割当て制限の空きパーセンテージが TBS_PERCENT_FREE の値に近づくように、セグメントを移動し始めます。この ADO のアクションでは、最善が尽くされますが、結果は保証されません。

たとえば次のように、DBMS_ILM_ADMIN PL/SQL パッケージの CUSTOMIZE_ILM プロシージャを使用して、ILM の ADO パラメータを設定できます。

BEGIN DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED, 85): DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE, 25): END;

3 HCC を使用するには、Oracle Exadata、Oracle SuperCluster、Pillar Axiom、Sun ZFS Storage Appliance、または FS1 を使用する必要があります。

7 | Oracle Database 18cを使用した自動データ最適化

上記の例では、表領域が、ユーザーが定義した上限のしきい値（85%）に到達すると、データベースは表領域のもっともコールドな表やパーティションを、表領域割当て制限に少なくとも 25%の空きができるまで、対象の表領域に自動的に移動します。この処理は、"TIER TO"を使用した ADO ポリシーが定義されている表およびパーティションにのみ適用されます。これにより、パフォーマンスの恩恵を実際に受けるセグメントのために層 1 のストレージ領域が解放され、層 1 のパフォーマンスを必要としないコールドなセグメントが低コストの層 2 のストレージに移動されます。

以下の例では、現在の表領域で領域が不足している場合に、表領域レベルの ADO ポリシーによってパーティションが異なる表領域に自動的に移動されます。"tier to"キーワードは、現在の表領域がいっぱいになると、データが新しい表領域へ移動することを示します。"low_cost_store"表領域は、低コストのストレージ層に作成されました。

ALTER TABLE orders ILM ADD POLICY tier to low_cost_store;

ADO ストレージ階層化はセグメント・レベルで実行されるため、ADO ポリシーがストレージ階層化を実装している場合は、セグメント全体が移動されます。この移動は単方向です。つまり、ADOストレージ階層化は、コールドなセグメントを高パフォーマンスのストレージからより低パフォーマンスで低コストのストレージに移動するためのものです。ADO 圧縮ポリシーとストレージ階層化ポリシーの両方が該当する場合、データベースは、単一のセグメント再編成ステップで両ポリシーを実行します。

このストレージ階層化の動作はすべて、"TIER TO"を使用したポリシーのカスタム条件でオーバーライドできます。DBA は、PL/SQL を使用して独自の条件を記述して、エンコードしたい任意の条件に基づいたセグメントの移動を実装できます。

セグメントを別の表領域に移動する場合、オブジェクトの移動後にターゲットの表領域を READONLY に設定するオプションもあります。このオプションは、データベース・バックアップ中に履歴データに対して使用すると効果的です。その後の Oracle Recovery Manager（Oracle RMAN）データベースのフル・バックアップでは、READ ONLY の表領域はスキップされます。

OLTP 向けの自動データ最適化

前述の例では、圧縮階層化（スマート圧縮）またはストレージ階層化といった、1 つのアクションを実装する個々の ADO ポリシーについて説明しました。次の例では、OLTP アプリケーション向けの複数の ADO ポリシーを組み合わせる方法について説明します。

OLTP アプリケーションでは、もっともアクティブな表およびパーティションに対して、Advanced Row Compression を使用する必要があります。そうすることで、アクティブな表およびパーティションに対して DML 操作が実行される際に、新たに追加または更新されたデータが確実に圧縮されるようになります。

OLTP 表内のコールド・データまたは履歴データには、Hybrid Columnar Compression のウェアハウス圧縮またはアーカイブ圧縮のいずれかを使用します。これにより、更新される頻度が低い、あるいはまったく更新されないデータは最高レベルで圧縮されます。

Advanced Row Compression での圧縮率が通常 2 倍から 4 倍であるのに対し、Hybrid Columnar Compression での圧縮率は通常 6 倍から 15 倍です。

8 | Oracle Database 18cを使用した自動データ最適化

図 3 に例を示します。

図3：Advanced Row Compression、Hybrid Columnar Compression、階層化

ADOによってこのアプローチを実装するには、以下のポリシーを使用します。

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY HIGH SEGMENT AFTER 30 DAYS OF NO MODIFICATION;

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 90 DAYS OF NO MODIFICATION;

ALTER TABLE orders ILM ADD POLICY tier to low_cost_store;

このスマート圧縮およびストレージ階層化の例では、Advanced Row Compression を有効化してorders パーティションが定義されることを前提としているため、行は最初に挿入された時点のレベルで圧縮されます。

Oracle Database は、ADO ポリシーを自動的に評価して、パーティションがより高い圧縮レベルへ移動するのに適しているかどうか、より低コストのストレージ層へ移動するのに適しているかどうかを判断します。前述したように、ストレージ階層化はおもに現在の表領域がいっぱいになると開始されますが、ユーザー定義の条件に基づいて開始時期をカスタマイズすることができます。

Oracle Advanced Compression のヒートマップおよび ADO の機能により、DBA は OLTP アプリケーション向けの ILM を簡単に実装でき、OLTP データで HCC を使用できるようになります。HCC を使用すると、DBA はレポートおよび分析のパフォーマンスを向上させながら、コールドな OLTP データによって使用されるストレージ領域量を大幅に削減できます。

データウェアハウス向けの自動データ最適化

HCC をサポートする Exadata ストレージまたは Oracle ストレージ上のデータウェアハウス・アプリケーションでは、頻繁に問合せを受ける表およびパーティションに対して HCC ウェアハウス圧縮を使用する必要があります。データウェアハウス・アプリケーション内のコールド・データまたは履歴データに対しては、アーカイブ圧縮を使用することにより、アクセス頻度の低いデータが最高レベルで圧縮されます。アーカイブ圧縮での圧縮率は、通常 15 倍から 50 倍です。

9 | Oracle Database 18cを使用した自動データ最適化

図 4 に例を示します。

図4：パーティション化とHybrid Columnar Compression

ADO によってこのアプローチを実装するには、以下の文を使用します。

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 90 DAYS OF NO MODIFICATION; ALTER TABLE orders ILM ADD POLICY tier to lessactivetbs;

この例では、ウェアハウス圧縮を有効化して orders 表が定義されることを前提としているため、行は最初に挿入された時点のレベルで圧縮されます。

この例ではセグメント・レベルで HCC 圧縮を実装しましたが、自動データ最適化では、行レベルのポリシーに対する Hybrid Columnar Compression（HCC）もサポートされることに留意してください。コールド・ブロックの行は、表またはパーティションの他の部分で DML 挿入アクティビティが発生していても、HCC 圧縮を行うことができます。

表に配列を挿入している間は、Hybrid Columnar Compression（HCC）を使用できます。つまり、APPEND ヒントのない SQL INSERT 文では HCC を（圧縮レベルを下げることなく）使用でき、PL/SQL や Oracle Call Interface（OCI）といったプログラム・インタフェースから配列を挿入する場合は、HCC を使用できます。HCC に対する ADO ポリシーは、表またはパーティションの小規模なサブセットに頻繁に変更が加えられている場合でも、現在は有効です（更新は引き続き非圧縮で実行され、HCC 圧縮レベルに影響を及ぼす可能性があります）。

Oracle Database は、ADO ポリシーを自動的に評価して、パーティションがより高い圧縮レベルへ移動するのに適しているかどうか、別の表領域へ移動するのに適しているかどうかを判断します。前述の OLTP 向けのスマート圧縮の例のように、Oracle Database 18c の ADO の自動機能により、DBA はデータウェアハウス向けの ILM を簡潔かつ簡単に実装でき、DBA がストレージ使用およびストレージ・パフォーマンスの最適化に費やす必要のある時間と労力を大幅に削減できます。

10 | Oracle Database 18cを使用した自動データ最適化

結論 情報ライフ・サイクル管理により、組織は、データが時間の経過とともにアクセスされる様子を把握し、それに応じてデータを管理できるようになります。ただし、ほとんどの場合、データベース向けの ILM ソリューションには、2 つのおもな機能が欠けています。データの自動分類と、自動データ圧縮およびストレージ層間の移動です。

Oracle Advanced Compression のヒートマップおよび自動データ最適化機能は、パフォーマンスを最大化しながらコストを最小限に抑える、包括的で自動化された ILM ソリューションをサポートします。Oracle Database 18c の包括的な圧縮機能と組み合わせることにより、Oracle Database は ILMの実装に理想的なプラットフォームを提供します。

自 動 デ ー タ 最 適 化 に つ い て 詳 し く は 、 ス ト レ ー ジ 最 適 化 の ブ ロ グ（https://blogs.oracle.com/DBStorage/）を参照してください。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2018, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく

変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証

を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本

文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル

の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信する

ことはできません。

Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される SPARC International,

Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX

は、The Open Group の登録商標です。0218