5 時間ベース情報の管理およびメンテナンス

Oracle Databaseには、時間に基づいてデータを管理およびメンテナンスするための計画が用意されています。

この章では、時間に基づくデータの管理およびメンテナンスの戦略を作成できるOracle Databaseのコンポーネントについて説明します。

ほとんどの組織で、保管データは最も貴重な企業資産の1つであると考えられてきましたが、データの管理方法やメンテナンス方法は企業によって大きく異なります。本来、データの使用目的は、経営目標の達成を支援し、事業を経営し、また将来の方向性を特定し、企業を成功に導くことにありました。

ただし、新しい政府規制とガイドラインが、データ保持の方法や理由において大きな促進力となっています。規制のために、組織は非常に長い期間にわたって情報を保持して管理する必要が生じています。その結果、今日では、情報技術(IT)マネージャは、その他の次のような目標を達成しようとしています。

  • 可能なかぎり低いコストで大量のデータを格納すること

  • データの保持および保護のための新しい法的要件を満たすこと

  • データ量の増加に基づく、より詳しい分析により、ビジネス機会を改善すること

この章の構成は、次のとおりです。

5.1 ILMを使用したOracle Databaseのデータの管理

情報ライフサイクル管理(ILM)では、Oracle Database内のデータを、そのデータに適用されるルールおよび規則を使用して管理できます。

現在、情報の形式は、電子メール・メッセージから、写真、オンライン・トランザクション処理(OLTP)システムの注文まで多岐にわたります。データの種類と使用方法がわかれば、データの発展方法や最終的な状態を理解したことになります。

各組織が直面する1つの目標は、データに適用されるようになった規則や規制を守る一方で、自らのデータがどのように発展および増大するかを理解し、使用方法が時間につれて変化する様子を監視し、保管すべき期間を決定することです。情報ライフサイクル管理(ILM)は、プロセス、ポリシー、ソフトウェアおよびハードウェアを組み合せて、これらの課題に取り組み、データのライフサイクルの各ステージで適切な技術を使用できるようにします。

この項では、次の項目について説明します。

5.1.1 ILMのOracle Databaseについて

Oracle Databaseは、ILMソリューションの実装に理想的なプラットフォームを提供します。

Oracle Databaseプラットフォームは、次を提供します。

  • アプリケーションの透過性

    アプリケーションの透過性はILMでは大変重要です。アプリケーションをカスタマイズする必要がないことを意味し、様々な変更をデータに加えてもデータを使用するアプリケーションに影響を及ぼさないためです。データをライフサイクルの別のステージに簡単に移動することができ、データベースでのデータ・アクセスを最適化することができます。もう1つの大きな利点は、アプリケーションの透過性により、新たな規制要件に迅速に対応するために必要な柔軟性が得られることです。この場合も、既存のアプリケーションが影響を受けません。

  • ファイングレイン・データ

    Oracleでは、データを非常に細かいレベルや関連グループごとに表示することができます。これに対して、ストレージ・デバイスではバイトやブロックが表示されるだけです。

  • 低コスト・ストレージ

    保管するデータが非常に多い場合、低コスト・ストレージの使用が、ILMを実装する際の重要な要素になります。Oracleは多様なストレージ・デバイスを利用できるため、最小限のコストで最大限の容量のデータを保持できます。

  • 強制可能なコンプライアンス・ポリシー

    コンプライアンスの理由で情報を保存する場合は、規則に従ってデータを保管および管理していることを取締機関に示すことが不可欠です。Oracle Databaseでは、セキュリティ・ポリシーと監査ポリシーを定義し、データのすべてのアクセスに対して施行して、アクセスを記録することができます。

この項では、次の項目について説明します。

5.1.1.1 Oracle Databaseでのデータ型の管理

I情報ライフサイクル管理は、組織のすべてのデータに関連します。

このデータには、OLTPシステムでの注文やデータ・ウェアハウスでの売上履歴など、構造化されたデータの他に、電子メール、ドキュメント、イメージなど、構造化されていないデータも含まれます。Oracle Databaseでは、BLOBおよびOracle SecureFilesによって非構造化データの格納がサポートされ、優れたドキュメント管理システムをOracle Textで使用できます。

組織のすべての情報がOracle Databaseに含まれる場合は、データベースで提供される機能を利用して、存続期間の経過に伴う展開に応じてデータを管理および移動できます。複数の種類のデータ・ストアを管理する必要はありません。

5.1.1.2 規制の要件

現在、多くの組織は、特定のデータを特定の期間にわたって保管する必要があります。このような規制に従わない組織は、非常に重い罰金を支払うことになります。

世界中の様々な規制要件(米国のSarbanes-Oxley、HIPAA、DOD5015.2-STD、欧州連合の欧州データ保護指令(European Data Privacy Directive)など)により、組織のデータ管理方法が変化しています。このような規制によって、保管する必要があるデータ、データを変更できるかどうか、保管する必要がある期間(30年以上に及ぶ可能性もある)が定められます。

これらの規制によって頻繁に要求されるのは、未許可のアクセスや変更から電子データを保護することと、データに対する変更や変更者の監査証跡を保持することです。Oracle Databaseでは、アプリケーションのパフォーマンスに影響せずに大容量のデータを保存できます。また、アクセスの制限や未許可のデータ変更の防止に必要な機能も含み、Oracle Audit Vault and Database Firewallを使用して拡張することができます。Oracle Databaseでは暗号化機能も提供され、これにより、高度な権限を持つユーザーが意図的にデータを変更したのではないことを示すことができます。フラッシュバック・データ・テクノロジを使用すると、改ざん防止履歴アーカイブの存続期間における行のすべてのバージョンを格納できます。

5.1.1.3 オンライン・アーカイブの利点

オンライン・アーカイブには複数の利点があります。

データのライフサイクルのある時点になると、データは定期的にアクセスされなくなり、アーカイブの対象とみなされます。従来、データはデータベースから削除されて大容量の情報を非常に低いコストで格納できるテープに格納されました。現在、データをテープにアーカイブする必要はありません。データベースに残しておくか、集中オンライン・アーカイブ・データベースに移すことができます。このようなすべての情報を、1GB当たりのコストがテープとほとんど変わらない低コスト・ストレージを使用して格納できます。

アーカイブ目的ですべてのデータをOracle Databaseに置いておくと多数の利点が得られます。最も重要な利点は、いつでもすぐにデータを利用できるということです。このため、データがアーカイブされたテープを探したり、テープが読取り可能かどうか、またデータベースにロードできる形式になっているかどうかを判断したりして、時間を無駄にせずにすみます。

データが長い間アーカイブされていた場合は、テープ・アーカイブからデータベースにデータをリロードするためのプログラムを作成する開発時間も必要になります。これにはコストや時間がかかることがわかっており、データが古い場合は特に顕著です。データベースに保存したデータは、オンライン状態で最新のデータベース・フォーマットになっているためこの問題はありません。

現在、データベースに履歴データを保持しても、データベースのバックアップに必要な時間やバックアップのサイズに影響することはありません。RMANを使用してデータベースをバックアップすると、変更されたデータのみがバックアップに取得されます。履歴データが変更される可能性は少ないため、一度データがバックアップされると、その後のバックアップはありません。

検討する必要があるもう1つの重要な要素は、データベースからデータを物理的に除去する方法です(特に本番システムから集中アーカイブに移す場合)。Oracleではトランスポータブル表領域またはパーティションを使用して、データベース間でこのデータを短時間で移動する機能が提供されます。これにより、データがひとまとまりの単位で移動されます。

データベースからデータを削除するにあたり、最も速い方法はデータのセットを削除することです。これは、データがパーティションに保持された状態で実現できます。パーティションの削除は非常に高速で処理できます。ただし、データの関係を維持する必要があるためにこの方法が不可能な場合は、従来のSQL delete文を発行する必要があります。delete文の発行に必要な時間を少なく見積らないようにしてください。

データをデータベースから削除する必要があり、将来、データベースにデータを戻す必要が生じる可能性がある場合は、トランスポータブル表領域などのデータベース・フォーマットのままデータを移動するか、Oracle DatabaseのXML機能を使用してオープン・フォーマットで情報を抽出することを検討してください。

Oracle Databaseでのデータのオンライン・アーカイブを検討する理由は次のとおりです。

  • ディスクのコストはテープのコストに近づいているため、データが入っているテープを探す時間やデータをリストアするためのコストをなくすことができます。

  • 必要時にデータがオンラインになっており、高速アクセスを提供し、業務要件を満たします。

  • データがオンラインになっているためすぐにアクセスできます。このため、データを提供できないことで規制機関から罰金を課せられる可能性が少なくなります。

  • 現在のアプリケーションを使用してデータにアクセスできるため、新しいアプリケーションを構築するためにリソースを無駄にする必要がありません。

5.1.2 Oracle Databaseを使用したILMの実装

Oracle Databaseを使用した情報ライフサイクル管理ソリューションの作成は非常に簡単です。

ILMソリューションは、次の4つの簡単なステップによって完了できますが、ILMがコンプライアンス目的で実装されていない場合、ステップ4はオプションです。

5.1.2.1 ステップ1: データ・クラスの定義

情報ライフサイクル管理を有効に利用するには、まず最初に、組織のすべてのデータを確認してから情報ライフサイクル管理ソリューションを実装します。

データの確認後、次を決定します。

  • 重要なデータは何か、どこに格納されているか、保管する必要があるデータは何か

  • そのデータの組織でのフロー

  • 時間経過につれてそのデータがどのように扱われるか、そのデータはまだ必要か

  • データ可用性の程度と必要な保護

  • 法的および業務上の要件に対応するデータ保存

データの使用方法を理解すれば、それに基づいてデータを分類できます。最も一般的なタイプの分類は、経過時間つまり日付によるものですが、製品やプライバシなどその他のタイプの分類も可能です。プライバシと経過時間など、混合型の分類も使用できます。

データ・クラスの処理方法を変えるには、データを物理的に分ける必要があります。情報が作成されると最初のうちはよくアクセスされますが、時間が経過するとほとんど参照されなくなることがあります。たとえば、顧客が注文を行うと、ステータスや注文品が発送されたかどうかを確認するために定期的に注文を表示します。注文品が届いた後は、おそらくその注文を参照することはありません。この注文も、注文されている品物を確認するために実行する定期レポートに含まれます。ただし、時間がたつとどのレポートにも含まれなくなり、将来的に参照されるのは、そのデータに関連する詳しい分析が行われる場合のみになります。たとえば、注文を財務四半期Q1、Q2、Q3およびQ4に分け、さらに履歴注文として分類することができます。

この方法を使用する利点は、データがクラス(この例では注文日付)ごとに行レベルでグループ化されることです。Q2の注文は別のクラスに存在するため、Q1のすべての注文を自己完結した単位として管理できます。これはパーティション化の使用によって実現できます。パーティションはアプリケーションに対して透過的であるため、データを物理的に分離しても、アプリケーションはすべての注文を見つけることができます。

5.1.2.1.1 ILMでのパーティション化

パーティション化では、データ値に基づいてデータを物理的に配置します。日付によってデータをパーティション化する方法がよく使用されます。

図5-1に示すシナリオでは、Q1、Q2、Q3およびQ4の注文を個別のパーティションに格納し、前年までの注文を他のパーティションに格納します。

図5-1 データ・クラスのパーティションへの割当て

図5-1の説明が続きます
「図5-1 データ・クラスのパーティションへの割当て」の説明

Oracleでは複数の異なるパーティション化方法を提供します。レンジ・パーティション化は、ILMのためによく使用されるパーティション化方法の1つです。時間隔パーティション化および参照パーティション化も、ILM環境での使用に特に適しています。

データのパーティション化には様々な利点があります。パーティション化により、データを使用方法に応じて適切なストレージ・デバイスに簡単に分散すると同時に、データをオンラインに保ち、最もコスト効果の高いデバイスに格納できるようになります。パーティション化はデータにアクセスするすべてのユーザーにとって透過的であるため、アプリケーションの変更が必要ありません。このため、いつでもパーティション化を実装できます。新しいパーティションが必要なときには、ADD PARTITION句を使用して追加するだけです。また、時間隔パーティションを使用している場合には、パーティションが自動的に作成されます。

その他の利点として、各パーティションが独自のローカル索引を持つことが可能です。オプティマイザがパーティション・プルーニングを使用すると、問合せは、すべてのパーティションではなく関連するパーティションのみにアクセスするため、問合せのレスポンス時間が短縮されます。

5.1.2.1.2 データのライフサイクル

データを分析すると、多くの場合、当初はアクセスや更新が非常に頻繁に行われることがわかります。データが古くなるにつれて、アクセス頻度は減少し、あるとしてもごく少数になります。

図5-2に示すように、ほとんどの組織では、多くのユーザーが現行データにアクセスするが、それよりも古いデータにアクセスするユーザーはほとんどいないという状況が見られます。データは、アクティブ、非アクティブ、履歴、アーカイブ可能のいずれかとみなすことができます。

非常に多くのデータを保持するときは、その存続期間において物理的に場所を移す必要があります。データがライフサイクルのどの時点にあるかによって異なりますが、最も適切なストレージ・デバイスに格納する必要があります。

図5-2 時間経過に伴うデータ使用状況

図5-2の説明が続きます
「図5-2 時間経過に伴うデータ使用状況」の説明
5.1.2.2 ステップ2: データ・クラスに対応したストレージ層の作成

Oracle Databaseでは、多様なストレージ・オプションを利用できるため、情報ライフサイクル管理ソリューションの実装における2番目のステップは、必要なストレージ層の設定です。

必要に応じていくつでもストレージ層を作成できますが、最初は次のストレージ層をお薦めします。

  • 高パフォーマンス

    高パフォーマンス・ストレージ層には、Q1の注文を保持するパーティションなど、重要で頻繁にアクセスされるデータがすべて格納されます。この層には、高パフォーマンスのストレージ・デバイスの小型で高速なディスクが使用されます。

  • 低コスト

    低コスト・ストレージ層には、Q2、Q3、Q4の注文を保持するパーティションなど、それほど頻繁にアクセスされないデータが格納されます。この層は、モジュール式ストレージ・アレイや低コストATAディスクなど、低コストで最大限の記憶域を提供する大容量ディスクを使用して構築されます。

  • オンライン・アーカイブ

    オンライン・アーカイブ・ストレージ層には、ほとんどアクセスまたは変更されないすべてのデータが格納されます。このストレージ層は、非常に大きくなり、最大のデータ容量を格納する可能性があります。様々な方法を使用してデータを圧縮できます。ATAドライブのような低コスト・ストレージ・デバイスに格納しても、データをオンラインで利用できます。コストは情報をテープに格納するよりわずかに高いだけで、テープにアーカイブした場合の不便さもありません。オンライン・アーカイブ・ストレージ層を読取り専用に指定すると、データを変更できなくなります。最初にデータベース・バックアップを取得すると、それ以降バックアップする必要はありません。

  • オフライン・アーカイブ(オプション)

    オフライン・アーカイブ・ストレージ層はオプションです。データベースからデータを削除する必要がある場合のみ使用され、データはXMLなど別の形式でテープに格納されます。

図5-2は、一定の期間でデータがどのように使用されるかを示しています。この図から、すべての情報を保管するには、すべてのデータを保存する複数のストレージ層が必要となり、さらに、それによってストレージの合計コストが大幅に節減されるというメリットがもたらされることがわかります。

ストレージ層を作成すると、「ステップ1: データ・クラスの定義」で指定したデータ・クラスが、パーティションを使用してデータベース内に物理的に実装されます。この方法により、データを使用方法に応じて適切なストレージ・デバイスに簡単に分散し、一方で、データをオンラインに保っていつでも利用できるようにし、最もコスト効果の高いデバイスに格納することができるようになります。

Oracle Automatic Storage Management(Oracle ASM)を使用して、ストレージ層間のデータを管理することもできます。Oracle ASMは、Oracle Databaseファイル用の高パフォーマンスで管理が容易なストレージ・ソリューションです。Oracle ASMはボリューム・マネージャであり、データベースでのみ使用できるよう設計されたファイル・システムが備えられています。Oracle ASMを使用するには、ストライプ化およびミラー化のプリファレンスを使用して、Oracle Databaseのパーティション化したディスクを割り当てます。Oracle ASMによってディスク領域が管理され、使用可能なすべてのリソースにI/O負荷が配分されるため、I/Oを手動でチューニングしなくてもパフォーマンスが最適化されます。たとえば、データベースを停止しなくても、データベースのディスクのサイズを増加し、データベースの一部を新しいデバイスに移動できます。

5.1.2.2.1 ストレージ層へのクラスの割当て

ストレージ層を定義すると、ステップ1で指定したデータ・クラス(パーティション)を適切なストレージ層に割り当てることができます。

この割当てにより、データを使用方法に応じて適切なストレージ・デバイスに簡単に分散し、一方で、データをオンラインに保っていつでも利用できるようにし、最もコスト効果の高いデバイスに格納することができます。図5-3で、アクティブ、非アクティブ、履歴またはアーカイブ可能として識別されるデータは、高パフォーマンス層、低コスト・ストレージ層、オンライン・アーカイブ・ストレージ層およびオフライン・アーカイブにそれぞれ割り当てられます。この方法を使用すると、アプリケーションによってデータが引き続き認識されるのでアプリケーションを変更する必要はありません。

図5-3 データのライフサイクル

図5-3の説明が続きます
「図5-3 データのライフサイクル」の説明
5.1.2.2.2 階層ストレージの使用によるコスト節減

ILM戦略を実装する利点の1つは、複数階層ストレージの使用によりコストを節減できることです。

格納するデータが3TBあり、内訳は高パフォーマンス200GB、低コスト800GB、オンライン・アーカイブ2TBであるとします。また、1GB当たりのコストは、高パフォーマンス層では72ドル、低コスト層では14ドル、オンライン・アーカイブ層では7ドルと仮定します。

表5-1に、すべてのデータを1クラスのストレージに格納するかわりに階層ストレージを使用することで実現できるコスト節減を示します。ここでわかるように、非常に大きなコスト節減が可能です。データがOLTPおよびHCCデータベース圧縮に適している場合は、さらにコスト節減を行うことができます。

表5-1 階層ストレージ使用によるコスト節減

ストレージ層 単一層(高パフォーマンス・ディスク使用) 複数ストレージ層 複数層(データベース圧縮)

高パフォーマンス(200 GB)

$14,400

$14,400

$14,400

低コスト(800 GB)

$57,600

$11,200

$11,200

オンライン・アーカイブ(2 TB)

$144,000

$14,000

$5,600

各列の合計

$216,000

$39,600

$31,200

5.1.2.3 ステップ3: データのアクセス・ポリシーおよび移行ポリシーの作成

情報ライフサイクル管理ソリューションの実装における3番目のステップは、許可されたユーザーのみがデータにアクセスできるようにすること、およびデータの存続期間中のデータの移動方法を指定することです。

データが古くなったときにストレージ層の間でデータを移行する方法がいくつかあります。

5.1.2.3.1 データへのアクセス制御

データのアクセス権を存続期間中に変更できるため、データのセキュリティは情報ライフサイクル管理のもう1つの重要な側面です。

さらに、データのアクセス方法について厳密に要求する規制要件が存在する場合があります。

Oracle Database内のデータは、次のようなデータベース機能を使用して保護されます。

  • データベース・セキュリティ

  • ビュー

  • 仮想プライベート・データベース

仮想プライベート・データベース(VPD)では、データベースに対して非常に細かいレベルのアクセスを定義できます。セキュリティ・ポリシーによって、表示できる行と列が決まります。複数のポリシーを定義することで、様々なユーザーやアプリケーションが同じデータの異なるビューを表示できます。たとえば、Q1、Q2、Q3およびQ4の情報は大半のユーザーが見られるようにして、履歴データは許可されたユーザーのみが見られるようにできます。

セキュリティ・ポリシーはデータベース・レベルで定義され、すべてのデータベース・ユーザーに透過的に適用されます。この方法の利点は、データにアクセスするための安全で管理された環境が提供されることです。この環境を変更することはできず、実装するためにアプリケーションを変更する必要もありません。また、データが変更されないことを保証する読取り専用表領域を定義できます。

5.1.2.3.2 パーティション化を使用したデータの移動

存続期間中、データを移動する必要があり、使用できる技法はパーティション化です。

データの移動は次の理由で発生する可能性があります。

  • パフォーマンスを維持するため、高パフォーマンス・ディスクに保持できる注文数には制限があります。

  • データが頻繁にアクセスされなくなっても、高価な高パフォーマンス・ストレージを使用している場合には、低コスト・ストレージ・デバイスに移動する必要があります。

  • 法的要件により、情報は指定の期間にわたって利用可能であることが必要です。最低限のコストで安全に保存する必要があります。

様々なストレージ層を活用するようにOracle Database内でデータを物理的に移動する方法は多数あります。たとえば、データがパーティション化されている場合、Q2の注文を含むパーティションを、高パフォーマンス・ストレージ層から低コスト・ストレージ層にオンラインのまま移動することができます。データはデータベース内で移動されるため、物理的に移動しても、データを必要とするアプリケーションに影響したり、通常のユーザーの作業を中断したりすることはありません。

場合によっては、データのグループではなく、個々のデータ項目を移動する必要があります。たとえば、プライバシとレポートのレベルに従ってデータが分類されており、以前は機密扱いだったデータが、現在は公開できるようになったとします。データがプライバシの分類に基づいてパーティション化されているときに、分類が機密から公開に変更されると、データ行は公開データを含むパーティションに自動的に移動されます。

データを元の場所から移動するときは、選択したプロセスがすべての規制要件に準拠するように常に確認することがきわめて重要です。たとえば、データを変更できない、未許可のアクセスから保護する、容易に参照できる、承認された場所に格納するといった要件があります。

5.1.2.4 ステップ4: コンプライアンス・ポリシーの定義と施行

情報ライフサイクル管理ソリューションの4番目のステップは、コンプライアンスのためのポリシーの作成です。

データが集中管理されず断片化している場合は、すべての場所でコンプライアンス・ポリシーを定義して施行する必要がありますが、コンプライアンス・ポリシーが見逃されやすくなります。ただし、Oracle Databaseを使用して、データを集中的に格納できる場所を提供すると、すべてのコンプライアンス・ポリシーを1箇所で管理および施行でき、コンプライアンス・ポリシーの施行が非常に容易になります。

コンプライアンス・ポリシーを定義するときは、次の点を考慮してください。

  • データの保存

  • 不変性

  • プライバシ

  • 監査

  • 有効期限

5.1.2.4.1 データの保存

保存ポリシーでは、データの保存方法、保存が必要な期間、最終的な処理方法が指定されます。

例としては、レコードを元の形式で格納する必要があり、変更は許可されず、7年間保存する必要があるが、その後は削除できるというような保存ポリシーがあります。Oracle Databaseセキュリティを使用すると、データを変更せずに保持し、許可されたプロセスのみが適切なときにデータを削除することを保証できます。保存ポリシーは、ILMアシスタントのライフサイクル定義を使用して定義することもできます。

5.1.2.4.2 不変性

不変性は、データが完全であり変更されていないことを外部機関に証明することに関連します。

データが変更されていないことを示すために、暗号署名すなわちデジタル署名をOracle Databaseによって生成して、データベースの内外に保存できます。

5.1.2.4.3 プライバシ

Oracle Databaseではデータ・プライバシを保証するためにいくつかの方法が提供されます。

データへのアクセスは、仮想プライベート・データベース(VPD)を使用して定義したセキュリティ・ポリシーにより厳しく制御できます。また、生データを見るユーザーがデータの内容を把握できないように、個々の列を暗号化することができます。

5.1.2.4.4 監査

Oracle Databaseは、データに対するすべてのアクセスと変更を追跡できます。

これらの監査機能は表レベルで定義することも、ファイングレイン監査を使用して定義することもできます。ファイングレイン監査では、監査レコードをいつ生成するかという基準を指定します。Oracle Audit Vault and Database Firewallを使用して、監査をさらに拡張することができます。

関連項目:

Oracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。

5.1.2.4.5 有効期限

最終的には、業務または規制に関する理由からデータの有効期間が終わり、データベースから削除する必要が生じます。

Oracle Databaseでは、削除対象として指定された情報を含むパーティションを削除することにより、データをすばやく効率よく削除できます。

5.2 ヒート・マップおよびADOを使用したILM戦略の実装

データベースでのデータ移動のために情報ライフサイクル管理(ILM)計画を実装するには、ヒート・マップおよび自動データ最適化(ADO)の機能を使用します。

ノート:

ヒート・マップおよびADOは、Oracle Database 12cリリース2のマルチテナント環境でサポートされています。

この項では、次の項目について説明します。

関連項目:

5.2.1 ヒート・マップの使用

ILM戦略を実装するために、Oracle Databaseのヒート・マップを使用すればデータのアクセスと変更を追跡できます。

ヒート・マップは、セグメント・レベルのデータ・アクセス・トラッキングおよびセグメントおよび行レベルのデータ変更トラッキングを提供します。HEAT_MAP初期化パラメータを使用して、この機能を有効にできます。

ヒート・マップ・データは、ADOポリシーを使用してインメモリー列ストア(IM列ストア)のコンテンツを管理するための、自動データ最適化(ADO)を支援します。列統計およびその他の関連統計が含まれるヒート・マップ・データを使用すると、IM列ストアがいつ満杯(メモリー不足)になるかを判断できます。ほぼ満杯と判断されたときに、アクセス頻度が高くIM列ストアに移入することで利点が得られるセグメントが存在する場合は、非アクティブなセグメントが削除されます。

この項では、次の項目について説明します。

関連項目:

5.2.1.1 ヒート・マップの有効化および無効化

HEAT_MAP句を含むALTER SYSTEMまたはALTER SESSION文を使用して、システムまたはセッション・レベルでヒート・マップ・トラッキングを有効化および無効化できます。

たとえば、次のSQL文は、データベース・インスタンスのヒート・マップ・トラッキングを有効化します。

ALTER SYSTEM SET HEAT_MAP = ON;

ヒート・マップを有効にすると、すべてのアクセスがインメモリー・アクティビティ・トラッキング・モジュールによって追跡されます。SYSTEMおよびSYSAUX表領域のオブジェクトは追跡されません。

次のSQL文は、ヒート・マップ・トラッキングを無効化します。

ALTER SYSTEM SET HEAT_MAP = OFF;

ヒート・マップを無効にすると、アクセスがインメモリー・アクティビティ・トラッキング・モジュールによって追跡されません。HEAT_MAP初期化パラメータのデフォルト値はOFFです。

HEAT_MAP初期化パラメータでも自動データ最適化(ADO)を有効化および無効化できます。ADOの場合、システム・レベルでヒート・マップを有効にする必要があります。

関連項目:

5.2.1.2 ビューを使用したヒート・マップ・トラッキング・データの表示

ヒート・マップ・トラッキング・データは、V$*ALL*DBA*およびUSER*ヒート・マップ・ビューで表示されます。

例5-1に、ヒート・マップ・ビューで提供される情報の例を示します。V$HEAT_MAP_SEGMENTビューは、リアルタイム・セグメント・アクセス情報を表示します。ALL_DBA_およびUSER_HEAT_MAP_SEGMENTビューは、ユーザーに表示されるすべてのセグメントの最新のセグメント・アクセス時間を表示します。ALL_DBA_およびUSER_HEAT_MAP_SEG_HISTOGRAMビューは、ユーザーに表示されるすべてのセグメントのセグメント・アクセス情報を表示します。DBA_HEATMAP_TOP_OBJECTSビューは、最もアクティブなオブジェクトのヒート・マップ情報を表示します。DBA_HEATMAP_TOP_TABLESPACESビューは、最もアクティブな表領域のヒート・マップ情報を表示します。

関連項目:

ヒート・マップ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください

例5-1 ヒート・マップ・ビュー

/* enable heat map tracking if necessary*/

SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE,
  FULL_SCAN, LOOKUP_SCAN FROM V$HEAT_MAP_SEGMENT;

SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM TRACK_TIM SEG FUL LOO
-------------------- -------------------- --------- --- --- ---
SALES                SALES_Q1_1998        01-NOV-12 NO  NO  NO
SALES                SALES_Q3_1998        01-NOV-12 NO  NO  NO
SALES                SALES_Q2_2000        01-NOV-12 NO  NO  NO
SALES                SALES_Q3_1999        01-NOV-12 NO  NO  NO
SALES                SALES_Q2_1998        01-NOV-12 NO  NO  NO
SALES                SALES_Q2_1999        01-NOV-12 NO  NO  NO
SALES                SALES_Q4_2001        01-NOV-12 NO  NO  NO
SALES                SALES_Q1_1999        01-NOV-12 NO  NO  NO
SALES                SALES_Q4_1998        01-NOV-12 NO  NO  NO
SALES                SALES_Q1_2000        01-NOV-12 NO  NO  NO
SALES                SALES_Q1_2001        01-NOV-12 NO  NO  NO
SALES                SALES_Q2_2001        01-NOV-12 NO  NO  NO
SALES                SALES_Q3_2000        01-NOV-12 NO  NO  NO
SALES                SALES_Q4_2000        01-NOV-12 NO  NO  NO
EMPLOYEES                                 01-NOV-12 NO  NO  NO
...

SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), SEGMENT_WRITE_TIME,
  SEGMENT_READ_TIME, FULL_SCAN, LOOKUP_SCAN FROM USER_HEAT_MAP_SEGMENT;

SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM SEGMENT_W SEGMENT_R FULL_SCAN LOOKUP_SC
-------------------- -------------------- --------- --------- --------- ---------
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
SALES                SALES_Q1_1998                            30-OCT-12 01-NOV-12
...

SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE, FULL_SCAN,
  LOOKUP_SCAN FROM USER_HEAT_MAP_SEG_HISTOGRAM;

SUBSTR(OBJECT_NAME,1 SUBSTR(SUBOBJECT_NAM TRACK_TIM SEG FUL LOO
-------------------- -------------------- --------- --- --- ---
SALES                SALES_Q1_1998        31-OCT-12 NO  NO  YES
SALES                SALES_Q1_1998        01-NOV-12 NO  NO  YES
SALES                SALES_Q1_1998        30-OCT-12 NO  YES YES
SALES                SALES_Q2_1998        01-NOV-12 NO  NO  YES
SALES                SALES_Q2_1998        31-OCT-12 NO  NO  YES
SALES                SALES_Q2_1998        30-OCT-12 NO  YES YES
SALES                SALES_Q3_1998        01-NOV-12 NO  NO  YES
SALES                SALES_Q3_1998        30-OCT-12 NO  YES YES
SALES                SALES_Q3_1998        31-OCT-12 NO  NO  YES
SALES                SALES_Q4_1998        01-NOV-12 NO  NO  YES
SALES                SALES_Q4_1998        31-OCT-12 NO  NO  YES
SALES                SALES_Q4_1998        30-OCT-12 NO  YES YES
SALES                SALES_Q1_1999        01-NOV-12 NO  NO  YES
SALES                SALES_Q1_1999        31-OCT-12 NO  NO  YES
...

SELECT SUBSTR(OWNER,1,20), SUBSTR(OBJECT_NAME,1,20), OBJECT_TYPE, SUBSTR(TABLESPACE_NAME,1,20),
    SEGMENT_COUNT FROM DBA_HEATMAP_TOP_OBJECTS ORDER BY SEGMENT_COUNT DESC;

SUBSTR(OWNER,1,20)   SUBSTR(OBJECT_NAME,1 OBJECT_TYPE        SUBSTR(TABLESPACE_NA SEGMENT_COUNT
-------------------- -------------------- ------------------ -------------------- -------------
SH                   SALES                TABLE              EXAMPLE                         96
SH                   COSTS                TABLE              EXAMPLE                         48
PM                   ONLINE_MEDIA         TABLE              EXAMPLE                         22
OE                   PURCHASEORDER        TABLE              EXAMPLE                         18
PM                   PRINT_MEDIA          TABLE              EXAMPLE                         15
OE                   CUSTOMERS            TABLE              EXAMPLE                         10
OE                   WAREHOUSES           TABLE              EXAMPLE                          9
HR                   EMPLOYEES            TABLE              EXAMPLE                          7
OE                   LINEITEM_TABLE       TABLE              EXAMPLE                          6
IX                   STREAMS_QUEUE_TABLE  TABLE              EXAMPLE                          6
SH                   FWEEK_PSCAT_SALES_MV TABLE              EXAMPLE                          5
SH                   CUSTOMERS            TABLE              EXAMPLE                          5
HR                   LOCATIONS            TABLE              EXAMPLE                          5
HR                   JOB_HISTORY          TABLE              EXAMPLE                          5
SH                   PRODUCTS             TABLE              EXAMPLE                          5
...

SELECT SUBSTR(TABLESPACE_NAME,1,20), SEGMENT_COUNT 
    FROM DBA_HEATMAP_TOP_TABLESPACES ORDER BY SEGMENT_COUNT DESC;

SUBSTR(TABLESPACE_NA SEGMENT_COUNT
-------------------- -------------
EXAMPLE                        351
USERS                           11

SELECT COUNT(*) FROM DBA_HEATMAP_TOP_OBJECTS;

  COUNT(*)
----------
        64

SELECT COUNT(*) FROM DBA_HEATMAP_TOP_TABLESPACES;

  COUNT(*)
----------
         2
5.2.1.3 DBMS_HEAT_MAPサブプログラムを使用したヒート・マップ・データの管理

DBMS_HEAT_MAPパッケージは、DBMS_HEAT_MAPサブプログラムを使用したヒート・マップ・データの表示にさらに柔軟性を提供します。

DBMS_HEAT_MAPには、ブロック、エクステント、セグメント、オブジェクト、表領域などの様々なレベルの記憶域でヒート・マップを外部化する1番目のAPIのセットおよび上位の表領域のバックグラウンド・プロセスでマテリアライズド化されたヒート・マップを外部化する2番目のAPIのセットが含まれます。

例5-2に、DBMS_HEAT_MAPパッケージのサブプログラムの使用の例を示します。

関連項目:

DBMS_HEAT_MAPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

例5-2 DBMS_HEAT_MAPパッケージのサブプログラムの使用

SELECT SUBSTR(segment_name,1,10) Segment, min_writetime, min_ftstime 
  FROM TABLE(DBMS_HEAT_MAP.OBJECT_HEAT_MAP('SH','SALES'));

SELECT SUBSTR(tablespace_name,1,16) Tblspace, min_writetime, min_ftstime 
  FROM  TABLE(DBMS_HEAT_MAP.TABLESPACE_HEAT_MAP('EXAMPLE'));

SELECT relative_fno, block_id, blocks, TO_CHAR(min_writetime, 'mm-dd-yy hh-mi-ss') Mintime,
   TO_CHAR(max_writetime, 'mm-dd-yy hh-mi-ss') Maxtime, 
   TO_CHAR(avg_writetime, 'mm-dd-yy hh-mi-ss') Avgtime 
   FROM TABLE(DBMS_HEAT_MAP.EXTENT_HEAT_MAP('SH','SALES')) WHERE ROWNUM < 10;

SELECT SUBSTR(owner,1,10) Owner, SUBSTR(segment_name,1,10) Segment, 
  SUBSTR(partition_name,1,16) Partition, SUBSTR(tablespace_name,1,16) Tblspace, 
  segment_type, segment_size FROM TABLE(DBMS_HEAT_MAP.OBJECT_HEAT_MAP('SH','SALES'));

OWNER      SEGMENT    PARTITION        TBLSPACE         SEGMENT_TYPE         SEGMENT_SIZE
---------- ---------- ---------------- ---------------- -------------------- ------------
SH         SALES      SALES_Q1_1998    EXAMPLE          TABLE PARTITION           8388608
SH         SALES      SALES_Q2_1998    EXAMPLE          TABLE PARTITION           8388608
SH         SALES      SALES_Q3_1998    EXAMPLE          TABLE PARTITION           8388608
SH         SALES      SALES_Q4_1998    EXAMPLE          TABLE PARTITION           8388608
SH         SALES      SALES_Q1_1999    EXAMPLE          TABLE PARTITION           8388608
...

5.2.2 自動データ最適化の使用

ILM戦略を実装するには、自動データ最適化(ADO)を使用して、データベース内の異なる層のストレージ間のデータの圧縮および移動を自動化できます。

この機能には、各層の異なる圧縮レベルを指定するポリシーを作成する機能およびデータの移動が発生する時間を制御する機能が含まれます。

この項では、次の項目について説明します。

自動データ最適化を使用するには、システム・レベルでヒート・マップを有効にする必要があります。HEAT_MAP初期化パラメータを使用して、この機能を有効にします。HEAT_MAP初期化パラメータの設定の詳細は、ヒート・マップの有効化および無効化を参照してください。

5.2.2.1 自動データ最適化のポリシーの管理

SQL文を使用して表を作成および変更する場合、行、セグメントおよび表領域の粒度レベルでADOのポリシーを指定できます。また、ADOポリシーにより、索引に対してアクションを実行できます。

ADOのポリシーを指定すると、データベース内の異なる層のストレージ間のデータの移動を自動化できます。これらのポリシーにより、各層に異なる圧縮レベルを指定することや、データの移動が発生する時間を制御することや、索引を最適化することもできます。

表のADOポリシー

SQL CREATEおよびALTER TABLE文のILM句により、ADOのポリシーを作成、削除、有効化または無効化できます。ILMポリシー句は、圧縮およびストレージ層ポリシーを決定します。また、ポリシー・アクションを起こす条件を指定するAFTER句やON句など、その他の句を含みます。表を作成する場合、ADOの新しいポリシーを追加できます。表を変更してポリシーを追加したり、既存のポリシーを有効化、無効化または削除できます。ポリシーは、表全体または表のパーティションに追加できます。ADOポリシーを表、または表のパーティションに追加する場合、AFTER句には1つの条件タイプのみを指定できます。ILM ADOポリシーには、P1P2およびPnなどのシステム生成名が付けられます。

セグメント・レベルのポリシーは1回のみ実行されます。ポリシーが正常に実行されると、そのポリシーは無効になり、再度評価されることはありません。ただし、ポリシーを明示的に再び有効化することはできます。行レベルのポリシーは継続的に実行され、正常な実行後も無効になることはありません。

ADOポリシーの有効範囲は、キーワードGROUPROWまたはSEGMENTを使用して、関連オブジェクトのグループに対して、またはセグメントや行のレベルで指定できます。

ポリシーのグループ化に適用できる圧縮のデフォルト・マッピングは次のとおりです。

  • ヒープ表のCOMPRESS ADVANCEDは、索引に対して標準の圧縮およびLOBセグメントに対してLOWにマップされます。

  • ヒープ表のCOMPRESS FOR QUERY LOW/QUERY HIGHは、索引に対して標準の圧縮およびLOBセグメントに対してMEDIUMにマップされます。

  • ヒープ表のCOMPRESS FOR ARCHIVE LOW/ARCHIVE HIGHは、索引に対して標準の圧縮およびLOBセグメントに対してHIGHにマップされます。

圧縮マッピングは変更できません。GROUPは、セグメント・レベルのポリシーにのみ適用できます。ストレージ層ポリシーはセグメント・レベルでのみ適用可能で、行レベルで指定できません。

索引のADOポリシー

索引のADOポリシーでは、既存の自動データ最適化(ADO)フレームワークを使用して索引を圧縮および最適化できます。

ADO索引ポリシーは、ALTER INDEXまたはCREATE INDEX SQL文のILM句を使用して追加できます。ADO索引ポリシーには、P1、P2、... Pnnというように、システムで生成された名前が付けられます。

たとえば、索引の作成時にADOポリシーを追加できます。

CREATE TABLE product_sales 
   (PRODUCT_ID NUMBER NOT NULL,
    CUSTOMER_ID NUMBER NOT NULL, 
    TIME_ID DATE NOT NULL, 
    CHANNEL_ID NUMBER NOT NULL,
    PROMO_ID NUMBER,
    QUANTITY_SOLD NUMBER(10,2) NOT NULL);

CREATE INDEX prod_id_idx ON product_sales(product_id) ILM ADD POLICY OPTIMIZE AFTER 7 DAYS OF NO MODIFICATION;

SELECT POLICY_NAME, POLICY_TYPE, ENABLED FROM USER_ILMPOLICIES;
POLICY_NAME             POLICY_TYPE    ENA
---------------------   -------------  ---
P21                     DATA MOVEMENT  YES

既存の索引にADOポリシーを追加できます。

ALTER INDEX hr.emp_id_idx ILM ADD POLICY SEGMENT TIER TO LOW_COST_TBS;

ALTER INDEX hr.emp_id_idx ILM ADD POLICY OPTIMIZE AFTER 3 DAYS OF NO ACCESS;

OPTIMIZE句を使用すると、ADOで、ポリシーの条件が満たされるたびに索引を最適化できます。最適化プロセスには、索引の圧縮、縮小または再構築などの処理が含まれます。

  • 圧縮: 索引セグメント内のキー値の部分を圧縮します

  • 縮小: 可能であれば索引ブロックの内容をマージし、ブロックを解放して再利用できるようにします

  • 再構築: 索引を再構築して、領域使用量およびアクセス速度を改善させます

OPTIMIZE句を指定すると、索引に最適なアクションが自動的に判別され、最適化プロセスの一部としてそのアクションが実装されます。実行するアクションを指定する必要はありません。

索引のADOポリシーを管理する際に手動でポリシーを無効にすることはできません。索引のADOポリシーは、1回のみ実行されます。ポリシーは、正常に実行された後は無効になり、再度評価されることはありません。

ALTER INDEX SQL文のILM句を使用して、一度に1つのポリシーを削除できます。たとえば:

ALTER INDEX prod_id_idx ILM DELETE POLICY p21;

索引パーティション・レベルでのILM ADOポリシーの変更はサポートされていません。索引レベルで変更されたADOポリシーは、すべてのパーティションにカスケードされます。

インメモリー列ストアのADOポリシー

自動データ最適化(ADO)では、INMEMORYINMEMORY MEMCOMPRESSNO INMEMORYポリシー・タイプを使用してインメモリー列ストア(IM列ストア)がサポートされています。

  • オブジェクトをインメモリー列ストアに移入できるようにするには、ADD POLICY句にINMEMORYを含めます。

  • IM列ストア内のオブジェクトに対する圧縮レベルを上げるには、ADD POLICY句にINMEMORY MEMCOMPRESSを含めます。

  • 利点が最も少ないオブジェクトをIM列ストアから明示的に削除するには、ADD POLICY句にNO INMEMORYを含めます。たとえば:

NO INMEMORY句を使用してIM列ストアからオブジェクトを削除する例を次に示します。

ALTER TABLE sales_2015 ILM ADD POLICY NO INMEMORY 
      AFTER 7 DAYS OF NO ACCESS;

インメモリー列ストア句を使用するADOポリシーは、セグメント・レベルのポリシーのみとなります。USER/DBA_ILMDATAMOVEMENTPOLICIESビューおよびV$HEAT_MAP_SEGMENTビューには、インメモリー列ストアについてADOポリシーの情報が含まれています。

ADOポリシーのカスタマイズ

ポリシーを実行する時間を決定する機能を提供するON PL/SQL_functionオプションを使用して、ポリシーをカスタマイズできます。ON PL/SQL_functionオプションは、セグメント・レベルのポリシーでのみ使用できます。たとえば:

CREATE OR REPLACE FUNCTION my_custom_ado_rules (objn IN NUMBER) RETURN BOOLEAN;

ALTER TABLE sales_custom ILM ADD POLICY COMPRESS ADVANCED SEGMENT
      ON my_custom_ado_rules;

関連項目:

5.2.2.2 ILM ADOポリシーを含む表の作成

ILM ADOポリシーを含む表を作成するには、CREATE TABLE文でILM ADD POLICY句を使用します。

例5-3のSQL文は、表を作成し、ILMポリシーを追加します。

例5-3 ILM ADOポリシーを含む表の作成

/* Create an example table with an ILM ADO policy */
CREATE TABLE sales_ado 
 (PROD_ID NUMBER NOT NULL,
  CUST_ID NUMBER NOT NULL, 
  TIME_ID DATE NOT NULL, 
  CHANNEL_ID NUMBER NOT NULL,
  PROMO_ID NUMBER NOT NULL,
  QUANTITY_SOLD NUMBER(10,2) NOT NULL,
  AMOUNT_SOLD NUMBER(10,2) NOT NULL )
 PARTITION BY RANGE (time_id)
 ( PARTITION sales_q1_2012 VALUES LESS THAN (TO_DATE('01-APR-2012','dd-MON-yyyy')),
   PARTITION sales_q2_2012 VALUES LESS THAN (TO_DATE('01-JUL-2012','dd-MON-yyyy')),
   PARTITION sales_q3_2012 VALUES LESS THAN (TO_DATE('01-OCT-2012','dd-MON-yyyy')),
   PARTITION sales_q4_2012 VALUES LESS THAN (TO_DATE('01-JAN-2013','dd-MON-yyyy')) )
  ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT 
      AFTER 12 MONTHS OF NO ACCESS;

/* View the existing ILM ADO polices */
SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled 
       FROM USER_ILMPOLICIES;

POLICY_NAME              POLICY_TYPE   ENABLE
------------------------ ------------- ------
P1                       DATA MOVEMENT YES
5.2.2.3 ILM ADOポリシーの追加

ILM ADOポリシーを表に追加するには、ALTER TABLE文でILM ADD POLICY句を使用します。

例5-4のSQL文では、sales表のパーティションへのILMポリシーの追加の例を示します。

例5-4 ILM ADOポリシーの追加

/* Add a row-level compression policy after 30 days of no modifications */
ALTER TABLE sales MODIFY PARTITION sales_q1_2002 
  ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW 
  AFTER 30 DAYS OF NO MODIFICATION;

/* Add a segment level compression policy for data after 6 months of no modifications */
ALTER TABLE sales MODIFY PARTITION sales_q1_2001 
  ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT 
  AFTER 6 MONTHS OF NO MODIFICATION;

/* Add a segment level compression policy for data after 12 months of no access */
ALTER TABLE sales MODIFY PARTITION sales_q1_2000 
      ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT 
      AFTER 12 MONTHS OF NO ACCESS;

/* Add storage tier policy to move old data to a different tablespace */
/* that is on low cost storage media */
ALTER TABLE sales MODIFY PARTITION sales_q1_1999 
  ILM ADD POLICY
  TIER TO my_low_cost_sales_tablespace;

/* View the existing polices */
SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled 
   FROM USER_ILMPOLICIES;

POLICY_NAME              POLICY_TYPE   ENABLE
------------------------ ------------- ------
P1                       DATA MOVEMENT YES
P2                       DATA MOVEMENT YES
P3                       DATA MOVEMENT YES
P4                       DATA MOVEMENT YES
P5                       DATA MOVEMENT YES
ノート: 複数の行レベル・ポリシーの追加はサポートされていません。(追加ポリシーが基準を満たしている場合でも)データベースは最後に追加されたポリシーのみを実行します。セグメント・レベルおよび表パーティションでは、複数のポリシーがサポートされています。可能であれば、これらのレベルのいずれかで追加のポリシーを実装することを検討してください。
5.2.2.4 ILM ADOポリシーの無効化と削除

ILM ADOポリシーを無効化または削除するには、ALTER TABLE文でILM DISABLE POLICYまたはILM DELETE POLICY句を使用します。

例5-5のSQL文に示すように、ADOのILMポリシーを無効化または削除できます。既存のILMポリシーが追加する新しいポリシーと競合する場合、既存のポリシーの削除が必要になることがあります。

例5-5 ILM ADOポリシーの無効化と削除

/* You can disable or delete an ADO policy in a table with the following */
ALTER TABLE sales_ado ILM DISABLE POLICY P1;
ALTER TABLE sales_ado ILM DELETE POLICY P1;

/* You can disable or delete all ADO policies in a table with the following */
ALTER TABLE sales_ado ILM DISABLE_ALL;
ALTER TABLE sales_ado ILM DELETE_ALL;

/* You can disable or delete an ADO policy in a partition with the following */
ALTER TABLE sales MODIFY PARTITION sales_q1_2002 ILM DISABLE POLICY P2;
ALTER TABLE sales MODIFY PARTITION sales_q1_2002 ILM DELETE POLICY P2;

/* You can disable or delete all ADO policies in a partition with the following */
ALTER TABLE sales MODIFY PARTITION sales_q1_2000 ILM DISABLE_all;
ALTER TABLE sales MODIFY PARTITION sales_q1_2000 ILM DELETE_ALL;
5.2.2.5 ADOを使用したセグメント・レベルの圧縮層およびストレージ層の指定

セグメント・レベルの圧縮層ポリシーを使用して、表内のセグメント・レベルで圧縮を指定できます。

行レベルの圧縮層ポリシーと組み合せて、データベースのデータの格納および管理方法を非常に細かく制御します。

例5-6に、ADOのポリシーを作成してsales_ado表の圧縮およびストレージ層ポリシーを施行する方法を示し、次のビジネス要件を反映します。

  1. バルク・ロード・データ

  2. OLTPワークロードの実行

  3. 更新が6か月間なければ、ARCHIVE HIGHで圧縮

  4. 低コスト・ストレージへの移動

例5-6 セグメント・レベルの圧縮層およびストレージ層の使用

/* Add a segment level compression policy after 6 months of no changes */
ALTER TABLE sales_ado ILM ADD POLICY
  COMPRESS FOR ARCHIVE HIGH SEGMENT 
  AFTER 6 MONTHS OF NO MODIFICATION;

Table altered.

/* Add storage tier policy */
ALTER TABLE sales_ado ILM ADD POLICY
  TIER TO my_low_cost_tablespace;

SELECT SUBSTR(policy_name,1,24) POLICY_NAME, policy_type, enabled 
  FROM USER_ILMPOLICIES;

POLICY_NAME              POLICY_TYPE   ENABLED
------------------------ ------------- -------
...
P6                       DATA MOVEMENT  YES
P7                       DATA MOVEMENT  YES
5.2.2.6 ADOを使用した行レベルの圧縮層の指定

自動データ最適化(ADO)のポリシーでは、基本および拡張圧縮に加えて、ハイブリッド列圧縮(HCC)がサポートされています。

HCC行レベル・ポリシーは、表の圧縮タイプに関係なく、任意の表で定義できます。セグメントの他の部分にDMLアクティビティがある場合は、コールド・ブロックの行をHCCで圧縮できます。

ノート:

HCC行レベル・ポリシーは、ASSM (自動セグメント領域管理)表領域でのみサポートされます。

非HCC表のHCCポリシーでは、行がHCC圧縮単位(CU)にある場合は、更新中に行が移動される可能性があります。また、行移動のその他の使用事例と同様に、移動された行を参照している索引エントリを更新するには、索引メンテナンスが必要となります。

行レベル・ポリシーは、Oracle Database 12cリリース1 (12.1)でサポートされています。ただし、HCC行レベル圧縮ポリシーを使用するには、データベースが12.2互換であるか、それ以上である必要があります。

関連項目:

表の圧縮の詳細は、『Oracle Database管理者ガイド』を参照してください

例5-7 行レベルのハイブリッド列圧縮の使用によるADOポリシーの作成

例5-7のSQL文では、HCCを使用して表employees_ilmの行でポリシーが作成されます。

ALTER TABLE employees_ilm 
   ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY ROW 
   AFTER 30 DAYS OF NO MODIFICATION;

例5-8 行レベルの拡張圧縮の使用によるADOポリシーの作成

例5-8のSQL文では、拡張圧縮を使用して表sales_adoの行でポリシーが作成されます。

ALTER TABLE sales_ado 
  ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW 
  AFTER 60 DAYS OF NO MODIFICATION;

SELECT policy_name, policy_type, enabled 
   FROM USER_ILMPOLICIES;
 
POLICY_NAME              POLICY_TYPE   ENABLE
------------------------ ------------- -------
...
P8                       DATA MOVEMENT YES
5.2.2.7 ILM ADOパラメータの管理

DBMS_ILM_ADMIN PL/SQLパッケージでCUSTOMIZE_ILMプロシージャを使用して設定する、ILM ADOパラメータを使用して、ADO環境をカスタマイズできます。

様々なILM ADOパラメータを表5-2に示します。

表5-2 ILM ADOパラメータ

名前 説明

ABSOLUTEJOB LIMIT

ABSOLUTEJOB LIMITの値は、同時に存在するADOジョブの絶対数を制限します。

DEGREEOF PARALLELISM

DEGREEOF PARALLELISMの値は、ADOポリシーのジョブが実行される並列度を決定します。

ENABLED

ENABLEDパラメータは、ADOバックグラウンド評価および実行を制御します。デフォルトでは有効化されています(TRUEまたは1)。

ENABLEDおよびHEAT_MAP初期化パラメータの設定は、次のように相互作用します。

  • HEAT_MAP初期化パラメータがONに設定され、ENABLEDパラメータがFALSEに設定されている場合(0)、ヒート・マップ統計は収集されますが、ADOは統計に対して自動的には機能しません。

  • HEAT_MAP初期化パラメータがOFFに設定され、ENABLEDパラメータがTRUEに設定されている場合(1)、ヒート・マップ統計は収集されず、ADOはヒート・マップ統計を信頼できないため、ADOは何も動作しません。ADOは、ENABLEDFALSEに設定されているかのように動作します。

EXECUTION MODE

EXECUTION MODEの値は、ADOがオンライン・モードまたはオフライン・モードのどちらで実行されるかを制御します。デフォルトはオンライン(2)です。

EXECUTION INTERVAL

EXECUTION INTERVALのタイプは、ADOがバックグラウンド評価を開始する頻度を決定します。デフォルトは15分です。

JOB LIMIT

JOB LIMITの値は、任意の時点でのADOジョブの最大数を制御します。同時ADOジョブの最大数は、(JOB LIMIT)*(インスタンス数)*(インスタンスごとのCPU数)として計算されます。デフォルト値は2です。

POLICY TIME

POLICY TIMEの値は、ADOポリシーが秒単位または日単位で指定されるかどうかを決定します。値は、秒の場合は1、または日(デフォルト)の場合は0となります。

RETENTION TIME

RETENTION TIMEの値は、そのデータがパージされるまで、完了したADOタスクが保持される時間の長さを指定します。デフォルトは30日です。

TBS PERCENT USED

TBS_PERCENT_USEDパラメータの値は、表領域が一杯と見なされる場合の表領域割当て率を指定します。デフォルトは85パーセントです。

TBS PERCENT FREE

TBS_PERCENT_FREEパラメータの値は、表領域のターゲット空き領域比率を示します。デフォルトは25パーセントです。

TBS_PERCENT*パラメータの値のために、ADOは最善を尽くしますが、保障はされません。表領域割当て率がTBS_PERCENT_USEDの値に到達すると、表領域割当ての空き領域比率がTBS_PERCENT_FREEの値に近づくように、ADOはデータの移動を開始します。例として、TBS_PERCENT_USEDが85およびTBS_PERCENT_FREE25に設定されると、表領域が90パーセント・フルになると想定します。すると、ADOは表領域割当ての少なくとも25パーセントが空き領域になるように(75パーセント未満が表領域割当てに使用されるようにとも言えます)、データを移動する操作を開始します。

DBA_ILMPARAMETERSビューではパラメータを表示できます。たとえば、次の問合せでは、ADO関連パラメータの値を表示します。

SQL> SELECT NAME, VALUE FROM DBA_ILMPARAMETERS;

---------------------------------------------------------------- ----------
ENABLED                                                                   1
RETENTION TIME                                                           30
JOB LIMIT                                                                 2
EXECUTION MODE                                                            2
EXECUTION INTERVAL                                                       15
TBS PERCENT USED                                                         85
TBS PERCENT FREE                                                         25
POLICY TIME                                                               0
ABSOLUTE JOB LIMIT                                                       10
DEGREE OF PARALLELISM                                                     4
...

関連項目:

5.2.2.8 ポリシー管理のPL/SQL関数の使用

より複雑なADOシナリオを実装してポリシーがデータをアクティブに移動および圧縮する時間を制御する高度なポリシー管理およびカスタマイズには、PL/SQL DBMS_ILMおよびDBMS_ILM_ADMINパッケージを使用できます。

PL/SQL DBMS_ILMおよびDBMS_ILM_ADMINパッケージを使用すると、重要な本番ワークロードに悪影響を与えないように、ADOのILMアクティビティを管理できます。これらのパッケージを使用するには、データベース互換性を最低でも12.0に設定する必要があります。

DBMS_ILMパッケージのEXECUTE_ILMプロシージャは、ジョブを作成およびスケジュールして、ADOのポリシーを施行します。以前にスケジュールされたILMジョブに関係なく、EXECUTE_ILM()プロシージャはこの機能を提供します。すべてのジョブはすぐに実行するように作成およびスケジュールされますが、すぐに実行されるかどうかはスケジューラでキューに入れられているジョブの数に依存します。

ILMジョブの実行時間をさらに制御し、次のメンテナンス・ウィンドウまで待てない場合、EXECUTE_ILMプロシージャを使用できます。

DBMS_ILMパッケージのSTOP_ILMプロシージャは、すべてのジョブ、すべての実行中ジョブ、タスクIDに基づくジョブ、または特定のジョブを停止します。

例5-9で示すように、DBMS_ILM_ADMIN PL/SQLパッケージのCUSTOMIZE_ILMプロシージャを使用して、ADOの設定をカスタマイズできます。

たとえば、TBS_PERCENT_USEDおよびTBS_PERCENT_FREE ILMパラメータの値を設定するか、ABS_JOBLIMIT ILMパラメータを設定することができます。TBS_PERCENT_USEDおよびTBS_PERCENT_FREEは、表領域の割当てに基づいてデータを移動する時期を決定し、ABS_JOBLIMITは、同時に存在するADOジョブの絶対数を設定します。

DBMS_METADATA PL/SQLパッケージを使用して、ポリシーでオブジェクトを再作成することもできます。

関連項目:

例5-9 CUSTOMIZE_ILMを使用したADO設定のカスタマイズ

SQL> BEGIN
  2  DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED, 85);
  3  DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE, 25);
  4  END;
  5  /

SQL> BEGIN
  2  DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.ABS_JOBLIMIT, 10);
  3  END;
  4  /
5.2.2.9 ビューを使用したADOのポリシーの監視

DBA_ILM*およびUSER_ILM*ビューを使用してデータベース・オブジェクトに関連付けられているADOのポリシーを表示および監視し、必要に応じてポリシーを容易に変更できます。

  • DBA/USER_ILMDATAMOVEMENTPOLICIESビューは、ADOのILMポリシーのデータ移動の関連属性に固有の情報を表示します。

  • DBA/USER_ILMTASKSビューは、プロシージャEXECUTE_ILMのタスクIDを表示します。ユーザーがプロシージャEXECUTE_ILMを呼び出すたびに、この特定の呼出しを追跡するためにタスクIDが戻されます。データベースによる期間の内部ILMタスクを追跡するため、タスクIDも生成されます。このビューは、ADOのすべてのILMタスクの情報を含みます。

  • DBA/USER_ILMEVALUATIONDETAILSビューは、特定のタスクに考慮されるポリシーの詳細を表示します。ポリシーが評価用に選択された場合、ポリシーを実行するジョブの名前も表示されます。ポリシーが実行されなかった場合、このビューは理由も提供します。

  • DBA/USER_ILMOBJECTSビューは、データベースのADOのすべてのオブジェクトおよびポリシーを表示します。特定の表領域で作成されたため、多くのオブジェクトは親オブジェクトを介してポリシーを継承します。このビューは、ポリシーとオブジェクト間のマッピングを提供します。継承されたポリシーの場合、このビューはポリシーが継承されるレベルも示します。

  • DBA/USER_ILMPOLICIESビューは、データベースのADOのすべてのポリシーの詳細を表示します。

  • DBA/USER_ILMRESULTSビューは、データベースのADOのデータ移動関連ILMジョブの情報を表示します。

  • DBA_ILMPARAMETERSビューは、ADO関連パラメータの情報を表示します。

関連項目:

ILMビューの詳細は、『Oracle Databaseリファレンス』を参照してください

5.2.3 ADOおよびヒート・マップの制限事項

このトピックでは、ADOおよびヒート・マップに関連する制限事項について説明します。

ADOおよびヒート・マップに関連付けられている制限事項を次に示します。

  • パーティション・レベルのADOおよび圧縮は、有効期間が経過した行を圧縮する行レベルADOポリシーを除き、時間的な有効性に対してサポートされます(アクセスまたは変更)。

  • パーティション・レベルのADOおよび圧縮は、ORA_ARCHIVE_STATE列でパーティション化される場合に、インデータベース・アーカイブに対してサポートされます。

  • ADOのカスタム・ポリシー(ユーザー定義関数)は、ポリシーが表領域レベルでデフォルトの場合にサポートされません。

  • ADO行レベルのポリシーでは、OF NO MODIFICATION条件タイプのみがサポートされています。
  • ストレージ層を使用する場合、ADOはターゲット表領域の記憶領域のチェックを実行しません。

  • ADOは、オブジェクト型を使用した表またはマテリアライズド・ビューでサポートされません。

  • ADOは、索引構成表またはクラスタではサポートされません。

  • ADO同時実行性(ADOの同時ポリシー・ジョブの数)は、Oracleスケジューラの同時実行性に依存します。ADOのポリシー・ジョブが2回以上失敗した場合、ジョブが無効とマークされ、後でジョブを手動で有効にする必要があります。

  • 複数の行レベル・ポリシーの追加はサポートされていません。セグメント・レベルおよび表パーティションでは、複数のポリシーがサポートされています。可能であれば、これらのレベルのいずれかで追加のポリシーを実装することを検討してください。

  • ADOには、表および表パーティションの移動に関連する制限事項があります。

    関連項目:

5.3 Oracle Databaseのデータの有効性および表示の制御

インデータベース・アーカイブおよび時間的な有効性を使用して、Oracle Databaseのデータの有効性および表示を制御できます。

この項では、次の項目について説明します。

5.3.1 インデータベース・アーカイブの使用

インデータベース・アーカイブでは、表内の行をアクティブまたはアーカイブ済としてマークできます。

インデータベース・アーカイブはどのようにデータベース操作とアプリケーション操作に役立つか

インデータベース・アーカイブの利点を次に示します。

  • インデータベース・アーカイブを使用すると、アプリケーションのパフォーマンスが低下することなく、大量のアーカイブ・データをデータベースに格納できます。
  • アーカイブ済データを圧縮するとバックアップ・パフォーマンスが向上します。
  • データ検索のパフォーマンス・アクセラレータとして使用できます。

    これにより、検索の範囲が、現在関連性のあるものに絞り込まれます(ターゲット表内のデータ量が少数の可能性がある)。

  • データ変更を伴うアプリケーション・アップグレードによる停止時間を短縮できます。

    アクティブ・データとアーカイブ済データを別々に処理するようにアップグレード・スクリプトを記述できます。たとえば、アーカイブ済データはユーザーには不可視であるため、アップグレードしアクティブ・データにデータ修正が適用された直後に再度アプリケーションが使用可能になるようにすることができます。アーカイブ済データに対する変更は後に延期できます。

アクティブ・データとアーカイブ・データ

インデータベース・アーカイブの目的のために、表内の行は、次の2つのうちどちらかの状態になっています:

  • アクティブ - 頻繁な問合せの対象となる行は、通常はアクティブとみなされます。たとえば、ビジネス環境においては、現四半期と前四半期の売上データがアクティブとみなされる可能性があります。

  • アーカイブ - 進行中のアクティビティに必要でなくなったデータを含む行は、暗黙的にアーカイブとみなされる可能性があります。たとえば、それらには、記録保存やコンプライアンスの目的でのみ格納されている数か月前または数年前に完了したトランザクションからのデータが含まれている可能性があります。このようなデータが読み取られることや変更されることはめったにありません。たとえば、過去5年の事業年度の売上データをアーカイブ・データとみなすことができます。

多くの場合、データベース内のデータの大部分は、非アクティブであるため、アーカイブとなります。問合せでこのデータを自動的にフィルタ処理すると、問合せのパフォーマンスが大幅に向上します。同様に、バルク更新(アプリケーションのアップグレード中など)でも、無関係なデータが除外されて停止時間が短くなることでメリットがあります。このデータ・フィルタ処理を設定するには、表に対して行アーカイブ格納を有効にします。これにより、列ORA_ARCHIVE_STATEがその表に追加されます。アーカイブ済の行は通常は問合せでは参照不可であるため、これらの行は処理されず、問合せ結果から除外されます。

ORA_ARCHIVE_STATEとは

ORA_ARCHIVE_STATEは、指定された行をactiveまたはarchivedとして指定する役目を果たすシステム列です。これは、ディクショナリ内にユーザー列番号(usrcol#)がない非表示列です。これは、表のDESCRIBEを実行したときや表に対してSELECT *問合せを発行したときには参照不可です。ただし、この列は、SELECT問合せの選択リスト、UPDATE問合せの変更リスト、および問合せとDMLの述語で、明示的に指定できます。

ノート:

ご自分で、およびご自分の組織のILM慣例で、行アーカイブ表内のどの行をアーカイブする必要があるかを決める必要があります。インデータベース・アーカイブでは、このような分析は実行されません。デフォルトでは、行アーカイブ表内の各行がアクティブとなります。

新しい表または既存の表での行アーカイブの有効化

CREATE TABLE文にROW ARCHIVAL句を含めるか、ALTER TABLEを使用して既存の表にROW ARCHIVALを設定します。たとえば:

CREATE TABLE scott.emp (EMPNO NOT NULL NUMBER(7), FULLNAME VARCHAR2(100), JOB VARCHAR2(9), MGR NUMBER(7)) ROW ARCHIVAL;
ALTER TABLE scott.emp ROW ARCHIVAL;

表からROW ARCHIVALプロパティを削除することもできます。これにより、表からORA_ARCHIVE_STATE列が削除されます。

ALTER TABLE scott.emp NO ROW ARCHIVAL;

ノート:

オンライン再定義の間に表の行アーカイブ属性を削除することはできません。

ORA_ARCHIVE_STATE列の特性の一部を次に示します:

  • これは、SELECT *問合せおよびDESCRIBEコマンドによって暗黙的にレポートされない非表示列です。
  • この列は明示的に更新できます。

行アーカイブが有効になっている表への問合せ

行アーカイブが有効になっている表に対してINSERTUPDATEおよびCREATE AS SELECTを使用した場合の動作に留意してください。

INSERT

各行のORA_ARCHIVE_STATEのデフォルト値は0です。これは、行はその列値をアーカイブ済に変更するまでアクティブ・データとみなされるということです。したがって、行アーカイブ表へのINSERTでは、必ず、新しい行がアクティブに設定されます。

UPDATE

更新では、どの行のORA_ARCHIVE_STATE値も直接設定できます。規則ではactiveまたはarchivedを示すために"0"または"1"を使用することになっていますが、ORA_ARCHIVE_STATEを任意の有効なVARCHAR2(4000)値に更新できます。

CREATE TABLE AS SELECT

CREATE TABLE AS SELECTの動作は、選択範囲内の各表が行アーカイブに対応しているかどうかと、SELECTリスト内の列の構造によって異なります。(次の表を参照)

"ORA_ARCHIVE_STATE"はOracle予約語ではないため各表で行アーカイブがまだ有効になっていない場合はユーザー列の名前として使用できることに注意してください。

INSERT INTO SELECT

ソース表とターゲット表が行アーカイブに対応しているINSERT INTO SELECTでは、ソース表とターゲット表の列リストで明示的にマップされていないかぎり、ターゲット表のORA_ARCHIVE_STATE列にソース表の対応する列の値が移入されることはありません。かわりに、デフォルトのアクティブの行アーカイブ状態が設定されます。

ALTER TABLE MOVE

ALTER TABLE MOVEを使用して表を移動した場合、表の行アーカイブ状態列は保持されます。

CREATE TABLE AS SELECTでの2つの表の間のデータ転送の動作の違い(両方の表が行アーカイブ対応の場合とそうでない場合)

次の表では、様々なシナリオでのCREATE TABLE AS SELECTの動作を示します。

表5-3 ORA_ARCHIVE_STATEの属性

ソース表が行アーカイブ対応かどうか ターゲット表が行アーカイブ対応かどうか 選択リストの構造 ORA_ARCHIVE_STATEはソース表のユーザー列である 動作
不可 不可 SELECT *であるか、ORA_ARCHIVE_STATEを含めることがSELECTリストで明示的に指定されている ORA_ARCHIVE_STATEをユーザー列として含め、すべての行をターゲット表のリクエストされた列にコピーします。
不可 SELECT * 不可 選択された行を、行の可視性に応じて、ORA_ARCHIVE_STATE列を除くすべての列にコピーします。
不可 ORA_ARCHIVE_STATEがSELECTリストに明示的に含まれている ORA_ARCHIVE_STATEをユーザー列として含め、選択された行を、行の可視性に応じて、リクエストされた列にコピーします。
SELECT * 不可 すべての行を、ターゲット表のリクエストされた列にコピーします。ターゲット表内のすべての新規行のORA_ARCHIVE_STATE列に'0'を割り当てます。
ORA_ARCHIVE_STATESELECTリストに明示的に含まれている 不可 選択された行を、行の可視性に応じて、リクエストされた列にコピーします。各行の既存の行アーカイブ状態をソース表からターゲット表に伝播します。
ORA_ARCHIVE_STATESELECTに明示的に含まれていない 不可 選択された行を、行の可視性に応じて、選択された列にコピーします。ターゲット表内のすべての新規行の新しいORA_ARCHIVE_STATE列に'0'を割り当てます。
不可 SELECT *であるか、ORA_ARCHIVE_STATEがSELECTリストに明示的に含まれている 重要: 戻り値

セッション・レベルの可視性制御のためのROW ARCHIVAL VISIBILITYの設定

デフォルトでは、行アーカイブが有効になっている表においては、アクティブ・データのみをユーザーおよびアプリケーションが参照可能です。ただし、これをセッションごとに変更することや、アーカイブ済の行を現在のセッション内で参照可能にする(または参照不可に戻す)ことができます。

次の文では、アクティブの行に対してのみ、セッション・レベルでの可視性が有効になります。このセッション内では、行アーカイブが有効になっている表に対するユーザー問合せはすべて、システムによるアクティブ・データのフィルタ処理の対象となります。
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;
次の文では、すべての行に対して、セッション・レベルでの行アーカイブ可視性が有効になります。このセッション内では、行アーカイブが有効になっている表に対するユーザー問合せはすべて、行アーカイブ列の値に影響を受けます。
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;

関連項目:

  • 『PL/SQLパッケージおよびタイプ・リファレンス』では、DBMS_ILMパッケージに、ORA_ARCHIVE_STATE列のためのアクティブおよびアーカイブ済状態定数が含まれています。これらは、それぞれ'0'と'1'で表されます。
    archive_state_active constant varchar2(1) := '0'; 
    archive_state_archived constant varchar2(1) := '1'; 
    DBMS_ILMでは、ORA_ARCHIVE_STATEの現在の値を返すための関数ARCHIVESTATENAMEも提供されています。
    function archiveStateName(value in varchar2) return varchar2;
    
    入力パラメータ 説明
    value アーカイブ状態名を返す必要がある文字列値。
    return

    "0"の場合は"archive_state_active"

    その他の場合は"archive_state_archived"

  • 『SQL言語リファレンス』では、ALTER TABLE文とCREATE TABLE文でのROW_ARCHIVAL句の使用について説明しています。
    • ALTER TABLE [schema.]table [alter_table_properties | … ] [row_archival_clause]
    • CREATE TABLE [schema.]table [(relational properties)] [table properties] table_properties::= [column_properties ] [ table_partitioning_clauses ] … [row_archival_clause] row_archival_clause ::= [NO] ROW ARCHIVAL

例5-10 インデータベース・アーカイブの使用

/* Set visibility to ACTIVE to display only active rows of a table.*/
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;

CREATE TABLE employees_indbarch 
 (employee_id NUMBER(6) NOT NULL, 
  first_name VARCHAR2(20), last_name VARCHAR2(25) NOT NULL, 
  email VARCHAR2(25) NOT NULL, phone_number VARCHAR2(20), 
  hire_date DATE NOT NULL, job_id VARCHAR2(10) NOT NULL, salary  NUMBER(8,2),
  commission_pct NUMBER(2,2), manager_id NUMBER(6), department_id NUMBER(4)) ROW ARCHIVAL;

/* Show all the columns in the table, including hidden columns */
SELECT SUBSTR(COLUMN_NAME,1,22) NAME, SUBSTR(DATA_TYPE,1,20) DATA_TYPE, COLUMN_ID AS COL_ID,
  SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN, CHAR_LENGTH 
  FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_INDBARCH';

NAME                   DATA_TYPE                COL_ID SEG_COL_ID INT_COL_ID HID CHAR_LENGTH
---------------------- -------------------- ---------- ---------- ---------- --- -----------
ORA_ARCHIVE_STATE      VARCHAR2                                 1          1 YES        4000
EMPLOYEE_ID            NUMBER                        1          2          2 NO            0
FIRST_NAME             VARCHAR2                      2          3          3 NO           20
LAST_NAME              VARCHAR2                      3          4          4 NO           25
EMAIL                  VARCHAR2                      4          5          5 NO           25
PHONE_NUMBER           VARCHAR2                      5          6          6 NO           20
HIRE_DATE              DATE                          6          7          7 NO            0
JOB_ID                 VARCHAR2                      7          8          8 NO           10
SALARY                 NUMBER                        8          9          9 NO            0
COMMISSION_PCT         NUMBER                        9         10         10 NO            0
MANAGER_ID             NUMBER                       10         11         11 NO            0
DEPARTMENT_ID          NUMBER                       11         12         12 NO            0

/* Insert some data into the table */
INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
  hire_date, job_id, salary, manager_id, department_id) 
  VALUES (251, 'Scott', 'Tiger', 'scott.tiger@example.com', '21-MAY-2009',
 'IT_PROG', 50000, 103, 60);

INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
  hire_date, job_id, salary, manager_id, department_id) 
  VALUES (252, 'Jane', 'Lion', 'jane.lion@example.com', '11-JUN-2009', 
  'IT_PROG', 50000, 103, 60);

/* Decrease the ORA_ARCHIVE_STATE column size to improve formatting in queries */
COLUMN ORA_ARCHIVE_STATE FORMAT a18;

/* The default value for ORA_ARCHIVE_STATE is '0', which means active */
SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
 
EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
        251 0
        252 0

/* Insert a value into ORA_ARCHIVE_STATE to set the record to inactive status*/
UPDATE employees_indbarch SET ORA_ARCHIVE_STATE = '1' WHERE employee_id = 252;

/* Only active records are in the following query */
SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;

EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
        251 0

/* Set visibility to ALL to display all records */
ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;

SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;

EMPLOYEE_ID ORA_ARCHIVE_STATE
----------- ------------------
        251 0
        252 1

5.3.2 時間的な有効性の使用

時間的な有効性は、実際の有効性の期間を追跡できます。有効時間はデータのユーザーおよびアプリケーションによって設定でき、指定された有効時間または有効な時間範囲でデータを選択できます。

多くの場合、アプリケーションは、ビジネスの管理に関連する日付またはタイムスタンプでデータベースに記録されるファクトの有効性を示します。たとえば、保険業の補償の有効日を決定する人事管理(HR)アプリケーションの従業員の雇用日は有効な日付です。この日付は、従業員レコードがデータベースに入力された日付または時間とは異なります。前者の一時属性(雇用日)は有効時間(VT)と呼ばれ、後者(データベースに入力された日付)はトランザクション時間(TT)と呼ばれます。有効時間は通常ユーザーによって制御されますが、トランザクション時間はシステムが管理します。

ILMでは、有効時間属性は、ファクトが実業界で有効な時間および無効な時間を示すことができます。有効時間属性を使用すると、問合せは現在有効な行のみを表示できますが、閉じた注文や将来の雇用などの現在有効でないファクトを含む行は表示できません。

有効時間時制モデリングに不可欠な概念は次のとおりです。

  • 有効時間

    これは時間のユーザー定義表現です。有効時間の例には、プロジェクトの開始日および終了日、従業員の雇用日および退職日が含まれます。

  • 有効時間セマンティックを使用した表

    これらの表にはユーザー定義時間の1つ以上のディメンションがあり、それぞれ開始と終了があります。

  • 有効時間フラッシュバック問合せ

    これは、有効時間ディメンションを使用して、ある時点および複数バージョンの問合せを実行する機能です。

有効期間は、表定義で指定された2つの日時列で構成されます。列を明示的に追加して有効期間を追加したり、列を自動的に作成できます。表の作成または表の変更プロセス中に有効期間を追加できます。

一時的な表問合せのセッション・レベルの表示制御をサポートするため、DBMS_FLASHBACK_ARCHIVE PL/SQLパッケージはENABLE_AT_VALID_TIMEプロシージャを提供します。プロシージャを実行するには、必要なシステムおよびオブジェクト権限が必要です。

次のPL/SQLプロシージャは、指定された時点で有効時間の表示を設定します。

SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time 
          ('ASOF', '31-DEC-12 12.00.01 PM');

次のPL/SQLプロシージャは、セッション・レベルで有効期間内の現在有効なデータに一時的なデータの表示を設定します。

SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('CURRENT');

次のプロシージャは、デフォルトの一時的な表の表示である全表の一時的なデータの表示を設定します。

SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('ALL');

関連項目:

5.3.3 時間的な有効性による表の作成

このトピックの例は、時間的な有効性による表の作成方法を示します。

例5-11に、時間的な有効性の使用を示します。

Live SQL:

関連する例をOracle Live SQLのOracle Live SQL: 時間的な有効性による表の作成で参照して実行してください。

例5-11 時間的な有効性による表の作成

/* Create a time with an employee tracking timestamp */
/* using the specified columns*/
CREATE TABLE employees_temp (
       employee_id NUMBER(6) NOT NULL, first_name VARCHAR2(20), last_name VARCHAR2(25) NOT NULL,
       email VARCHAR2(25) NOT NULL, phone_number VARCHAR2(20), hire_date DATE NOT NULL, 
       job_id VARCHAR2(10) NOT NULL, salary  NUMBER(8,2), commission_pct NUMBER(2,2), 
       manager_id NUMBER(6), department_id NUMBER(4),
       PERIOD FOR emp_track_time);

DESCRIBE employees_temp

 Name                                                    Null?    Type
 ------------------------------------------------------- -------- ---------------
 EMPLOYEE_ID                                             NOT NULL NUMBER(6)
 FIRST_NAME                                                       VARCHAR2(20)
 LAST_NAME                                               NOT NULL VARCHAR2(25)
 EMAIL                                                   NOT NULL VARCHAR2(25)
 PHONE_NUMBER                                                     VARCHAR2(20)
 HIRE_DATE                                               NOT NULL DATE
 JOB_ID                                                  NOT NULL VARCHAR2(10)
 SALARY                                                           NUMBER(8,2)
 COMMISSION_PCT                                                   NUMBER(2,2)
 MANAGER_ID                                                       NUMBER(6)
 DEPARTMENT_ID                                                    NUMBER(4)

SQL> SELECT SUBSTR(COLUMN_NAME,1,22) NAME, SUBSTR(DATA_TYPE,1,28) DATA_TYPE, COLUMN_ID AS COL_ID,
     SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN 
     FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_TEMP';

NAME                   DATA_TYPE                    COL_ID SEG_COL_ID INT_COL_ID HID
---------------------- ---------------------------- ------ ---------- ---------- ---
EMP_TRACK_TIME_START   TIMESTAMP(6) WITH TIME ZONE                  1          1 YES
EMP_TRACK_TIME_END     TIMESTAMP(6) WITH TIME ZONE                  2          2 YES
EMP_TRACK_TIME         NUMBER                                                  3 YES
EMPLOYEE_ID            NUMBER                            1          3          4 NO
FIRST_NAME             VARCHAR2                          2          4          5 NO
LAST_NAME              VARCHAR2                          3          5          6 NO
EMAIL                  VARCHAR2                          4          6          7 NO
PHONE_NUMBER           VARCHAR2                          5          7          8 NO
HIRE_DATE              DATE                              6          8          9 NO
JOB_ID                 VARCHAR2                          7          9         10 NO
SALARY                 NUMBER                            8         10         11 NO
COMMISSION_PCT         NUMBER                            9         11         12 NO
MANAGER_ID             NUMBER                           10         12         13 NO
DEPARTMENT_ID          NUMBER                           11         13         14 NO

/* Insert/update/delete with specified values for time columns */
INSERT INTO employees_temp(emp_track_time_start, emp_track_time_end, employee_id, first_name,
   last_name, email, hire_date, job_id, salary, manager_id, department_id) 
   VALUES (TIMESTAMP '2009-06-01 12:00:01 Europe/Paris', 
           TIMESTAMP '2012-11-30 12:00:01 Europe/Paris', 251, 'Scott', 'Tiger',
          'scott.tiger@example.com', DATE '2009-05-21', 'IT_PROG', 50000, 103, 60);

INSERT INTO employees_temp(emp_track_time_start, emp_track_time_end, employee_id, first_name,
     last_name, email, hire_date, job_id, salary, manager_id, department_id)  
     VALUES (TIMESTAMP '2009-06-01 12:00:01 Europe/Paris', 
             TIMESTAMP '2012-12-31 12:00:01 Europe/Paris', 252, 'Jane', 'Lion',
             'jane.lion@example.com', DATE '2009-06-11', 'IT_PROG', 50000, 103, 60);  

UPDATE employees_temp set salary = salary + salary * .05  
       WHERE emp_track_time_start <= TIMESTAMP '2009-06-01 12:00:01 Europe/Paris';

SELECT employee_id, SALARY FROM employees_temp;

EMPLOYEE_ID     SALARY
----------- ----------
        251      52500
        252      52500

/* No rows are deleted for the following statement because no records */
/* are in the specified track time. */
DELETE employees_temp WHERE emp_track_time_end < TIMESTAMP '2001-12-31 12:00:01 Europe/Paris';

0 rows deleted.

/* Show rows that are in a specified time period */
SELECT employee_id FROM employees_temp 
       WHERE emp_track_time_start > TIMESTAMP '2009-05-31 12:00:01 Europe/Paris' AND 
             emp_track_time_end < TIMESTAMP '2012-12-01 12:00:01 Europe/Paris';

EMPLOYEE_ID
-----------
        251

/* Show rows that are in a specified time period */
SELECT employee_id FROM employees_temp AS OF PERIOD FOR 
       emp_track_time TIMESTAMP '2012-12-01 12:00:01 Europe/Paris'; 

EMPLOYEE_ID
-----------
        252

5.3.4 インデータベース・アーカイブおよび時間的な有効性の制限事項

このトピックでは、インデータベース・アーカイブおよび時間的な有効性に関連付けられている制限事項を示します。

次のような制限があります。

  • ILMは、時間的な有効性のOLTP表圧縮でサポートされていません。セグメント・レベルのILMおよび圧縮は、終了時間列でパーティション化される場合にサポートされます。

  • ILMは、インデータベース・アーカイブのOLTP表圧縮でサポートされていません。セグメント・レベルのILMおよび圧縮は、ORA_ARCHIVE_STATE列でパーティション化される場合にサポートされます。

5.4 パーティション化を使用したILMシステムの手動実装

パーティション化を使用して、情報ライフサイクル管理(ILM)システムを手動で実装できます。

例5-12では、手動でストレージ層を作成し、それらのストレージ層に対して表をパーティション化し、そのデータベースに対して仮想プライベート・データベース(VPD)・ポリシーを設定して、オンライン・アーカイブ層のデータへのアクセスを制限する方法を示します。

関連項目:

例5-12 ILMシステムの手動実装

REM Setup the tablespaces for the data 

REM These tablespaces would be placed on a High Performance Tier 
CREATE SMALLFILE TABLESPACE q1_orders DATAFILE 'q1_orders'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE q2_orders DATAFILE 'q2_orders'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE q3_orders DATAFILE 'q3_orders'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE q4_orders DATAFILE 'q4_orders'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM These tablespaces would be placed on a Low Cost Tier 
CREATE SMALLFILE TABLESPACE "2006_ORDERS" DATAFILE '2006_orders'
  SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE "2005_ORDERS"  DATAFILE '2005_orders'
  SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM These tablespaces would be placed on the Online Archive Tier 
CREATE SMALLFILE TABLESPACE "2004_ORDERS" DATAFILE '2004_orders'
  SIZE 5M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE old_orders DATAFILE 'old_orders'
  SIZE 15M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM Now create the Partitioned Table 
CREATE TABLE allorders (
    prod_id       NUMBER       NOT NULL,
    cust_id       NUMBER       NOT NULL,
    time_id       DATE         NOT NULL,
    channel_id    NUMBER       NOT NULL,
    promo_id      NUMBER       NOT NULL,
    quantity_sold NUMBER(10,2) NOT NULL,
    amount_sold   NUMBER(10,2) NOT NULL)
 --
 -- table wide physical specs
 --
  PCTFREE 5 NOLOGGING   
 --
 -- partitions
 --  
 PARTITION BY RANGE (time_id)
  ( partition allorders_pre_2004 VALUES LESS THAN 
     (TO_DATE('2004-01-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE old_orders,
    partition allorders_2004 VALUES LESS THAN 
     (TO_DATE('2005-01-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE "2004_ORDERS",
    partition allorders_2005 VALUES LESS THAN 
     (TO_DATE('2006-01-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE "2005_ORDERS",
    partition allorders_2006 VALUES LESS THAN 
     (TO_DATE('2007-01-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE "2006_ORDERS",
    partition allorders_q1_2007 VALUES LESS THAN 
     (TO_DATE('2007-04-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE q1_orders,
    partition allorders_q2_2007 VALUES LESS THAN 
     (TO_DATE('2007-07-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE q2_orders,
    partition allorders_q3_2007 VALUES LESS THAN 
     (TO_DATE('2007-10-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE q3_orders,
    partition allorders_q4_2007 VALUES LESS THAN 
     (TO_DATE('2008-01-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE q4_orders);

ALTER TABLE allorders ENABLE ROW MOVEMENT;

REM Here is another example using INTERVAL partitioning 

REM These tablespaces would be placed on a High Performance Tier 
CREATE SMALLFILE TABLESPACE cc_this_month DATAFILE 'cc_this_month'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

CREATE SMALLFILE TABLESPACE cc_prev_month DATAFILE 'cc_prev_month'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM These tablespaces would be placed on a Low Cost Tier 
CREATE SMALLFILE TABLESPACE cc_prev_12mth DATAFILE 'cc_prev_12'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM These tablespaces would be placed on the Online Archive Tier
CREATE SMALLFILE TABLESPACE cc_old_tran DATAFILE 'cc_old_tran'
  SIZE 2M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED LOGGING 
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;

REM Credit Card Transactions where new partitions 
REM are automatically placed on the high performance tier 
CREATE TABLE cc_tran (
    cc_no       VARCHAR2(16) NOT NULL,
    tran_dt     DATE         NOT NULL,
    entry_dt    DATE         NOT NULL,
    ref_no      NUMBER       NOT NULL,
    description VARCHAR2(30) NOT NULL,
    tran_amt    NUMBER(10,2) NOT NULL)
 --
 -- table wide physical specs
 --
 PCTFREE 5 NOLOGGING   
 --
 -- partitions
 --  
 PARTITION BY RANGE (tran_dt)
 INTERVAL (NUMTOYMINTERVAL(1,'month') ) STORE IN (cc_this_month )
  ( partition very_old_cc_trans VALUES LESS THAN
     (TO_DATE('1999-07-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE cc_old_tran ,
    partition old_cc_trans VALUES LESS THAN
     (TO_DATE('2006-07-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE cc_old_tran ,
    partition last_12_mths VALUES LESS THAN
     (TO_DATE('2007-06-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE cc_prev_12mth,
    partition recent_cc_trans VALUES LESS THAN
    (TO_DATE('2007-07-01 00:00:00'
            ,'SYYYY-MM-DD HH24:MI:SS'
            ,'NLS_CALENDAR=GREGORIAN'
            )) TABLESPACE cc_prev_month,
    partition new_cc_tran VALUES LESS THAN
     (TO_DATE('2007-08-01 00:00:00'
             ,'SYYYY-MM-DD HH24:MI:SS'
             ,'NLS_CALENDAR=GREGORIAN'
             )) TABLESPACE cc_this_month);

REM Create a Security Policy to allow user SH to see all credit card data,
REM PM only sees this years data,
REM and all other uses cannot see the credit card data 

CREATE OR REPLACE FUNCTION ilm_seehist
  (oowner IN VARCHAR2, ojname IN VARCHAR2)
   RETURN VARCHAR2 AS con VARCHAR2 (200);
BEGIN
  IF SYS_CONTEXT('USERENV','CLIENT_INFO') = 'SH'
  THEN -- sees all data
    con:= '1=1';
  ELSIF SYS_CONTEXT('USERENV','CLIENT_INFO') = 'PM'
  THEN -- sees only data for 2007
    con := 'time_id > ''31-Dec-2006'''; 
  ELSE
    -- others nothing
    con:= '1=2';
  END IF;
  RETURN (con);
END ilm_seehist;
/

5.5 Oracle Enterprise ManagerでのILMヒート・マップおよびADOの管理

Oracle Enterprise Manager Cloud Controlでは、ヒート・マップおよび自動データ最適化を管理できます。

この項では、次の項目について説明します。

関連項目:

5.5.1 データベース管理メニューへのアクセス

データベースの「管理」メニューにアクセスするには:

  1. Oracle Enterprise Manager Cloud Controlにログインします。

  2. 「ターゲット」メニューから「データベース」を選択します。

  3. リストでデータベース名をクリックします。

  4. データベース・ホームページで「管理」メニューが表示されます。

5.5.2 表領域レベルの自動データ最適化アクティビティの表示

データベースのサイズ別に選択した上位100の表領域のアクティビティを監視するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページでは、最終アクセス時刻、最終書込み時刻、最終全体スキャン時刻および最終参照スキャン時刻に基づいて上位100の表領域アクティビティ・ヒート・マップを表示できます。

    デフォルトでは、ヒート・マップ内の各ボックスのサイズはヒート・マップ内の表領域を表し、表領域のサイズによって決まります。情報ライフサイクル管理を使用すると、表領域からセグメント・レベルのヒート・マップにドリルダウンできます。

5.5.3 任意の表領域のセグメント・アクティビティ詳細の表示

任意の表領域のセグメント・アクティビティ詳細を表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「追加の表示」ボタンをクリックします。

    Enterprise Managerにより、任意の表領域のセグメント・アクティビティ詳細を検索できるダイアログ・ボックスが表示されます。

  3. ダイアログ・ボックスに表領域名を入力して、「検索」ボタンをクリックします。

    Enterprise Managerにより、表領域のセグメント・アクティビティ詳細が表示されます。

  4. 「表領域ポリシーの編集」ボタンをクリックすると、「ADO」タブが選択された状態で、表領域の編集ページが表示されます。圧縮または移動を許可する表領域のポリシーを作成できます。

5.5.4 任意のオブジェクトのセグメント・アクティビティ詳細の表示

任意のオブジェクトのセグメント・アクティビティ詳細を表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. カーソルをデータベース・レベルのヒート・マップ内の任意のボックスに移動します(各ボックスは表領域を表します)。表示するオブジェクトが属する表領域をクリックします。

    Enterprise Managerにより、表領域に属する上位100の最大オブジェクトの表領域レベルのヒート・マップが表示されます。「セグメント・アクティビティ」表には、上位100の最大オブジェクトのセグメント・アクティビティ詳細が表示されます。

  3. 情報ライフサイクル管理ページで、「追加の表示」ボタンをクリックします。

    Enterprise Managerにより、表領域に属する任意のオブジェクトのセグメント・アクティビティ詳細を検索できるダイアログ・ボックスが表示されます。

  4. ダイアログ・ボックスにスキーマ名オブジェクト名を入力して、「検索」をクリックします。

    Enterprise Managerにより、オブジェクトのセグメント・アクティビティ詳細が表示されます。

  5. 「オブジェクト・ポリシーの編集」ボタンをクリックすると、「ADO」タブが選択された状態で、オブジェクトの編集ページが表示されます。圧縮または移動を許可するオブジェクトのポリシーを作成できます。

5.5.5 任意のオブジェクトのセグメント・アクティビティ履歴の表示

任意のオブジェクトのセグメント・アクティビティ履歴を表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. カーソルをデータベース・レベルのヒート・マップ内の任意のボックスに移動します(各ボックスは表領域を表します)。表示するオブジェクトが属する表領域をクリックします。

    Enterprise Managerにより、表領域に属する上位100の最大オブジェクトの表領域レベルのヒート・マップが表示されます。「セグメント・アクティビティ」表には、上位100の最大オブジェクトのセグメント・アクティビティ詳細が表示されます。

  3. セグメント・アクティビティ詳細表でオブジェクトを選択し、「アクティビティ履歴」ボタンをクリックします。

    Enterprise Managerにより、「ADO」タブが選択された状態で、オブジェクトの編集ページが表示されます。「ADO」タブには、ポリシーのリストとセグメント・アクセス履歴が表示されます。

  4. セグメントを選択して、日付範囲が過去60日間になるよう変更し、「毎日」オプションを選択して、「リフレッシュ」ボタンをクリックすると、そのオブジェクトの過去60日間に渡るセグメント・アクセス履歴が表示されます。

5.5.6 自動データ最適化でのアクティビティ・セグメントの検索

様々な期間中に自動データ最適化でセグメント・アクティビティを検索するには、次のステップに従います:

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、ヒート・マップの内のボックスのいずれかをクリックします。データベース・レベルの初期表示から、ヒート・マップのボックスをクリックして、その表領域の上位100の最大オブジェクトを表示します。その後にヒート・マップのボックスをクリックして、そのオブジェクトの上位100の最大セグメントを表示できます。

  3. 最終アクセス時刻の1年前のタイムスタンプを入力し、「実行」をクリックします。昨年アクセスまたは変更されていないセグメントのリストが表示されます。セグメントはセグメント・サイズの降順にソートされます。

    オブジェクト・レベルのヒート・マップでは、表領域、名前、パーティション、タイプ、最終アクセス時刻、最終書込み時刻、最終全体スキャン時刻および最終参照スキャン時刻に基づいて、特定のセグメントを検索できます。

    行(セグメント)を選択してそのセグメントの行アクティビティを表示でき、「ポリシー」列をクリックするとセグメントに関連付けられているポリシーが表示されます。

5.5.7 セグメントのポリシーの表示

セグメントに関連付けられているポリシーを表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「実行」をクリックします。検索結果のセグメントに関連付けられたポリシーがある場合は、ゼロ以外の件数が「ポリシー」列に表示されます。件数の上にマウスを移動すると、継承されたポリシーを含む、セグメントに関連付けられているポリシーが表示されます。件数がゼロの場合は、ポリシーはセグメントに関連付けられていません。

    データベース・レベルのヒート・マップから表領域レベルのヒート・マップにどりダウンします。表領域レベルのヒート・マップでは、Enterprise Managerに、表領域に属する上位100のオブジェクトが表示されます。Enterprise Managerで、各オブジェクトのポリシーの件数が列に表示されます。

    表領域レベルのヒート・マップからオブジェクトを選択し、オブジェクト・レベルのヒート・マップにドリルダウンします。Enterprise Managerには、オブジェクトに属する上位100の最大セグメントが表示されます。Enterprise Managerで、各セグメントのポリシーの件数が「ポリシー」列に表示されます。

5.5.8 バックグラウンド・アクティビティの無効化

自動データの最適化のバックグラウンド評価およびスケジューラを無効にするには、次のステップに従います:

ILM ADO ENABLEDパラメータの詳細は、ILM ADOパラメータの管理を参照してください。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. ポリシー実行の設定セクションで、「構成」をクリックします。

    ポリシー実行の設定ダイアログ・ボックスが表示されます。

  4. 「ステータス」ドロップダウンを「無効」に変更して、「OK」をクリックします。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。このページの「ポリシー実行設定」セクションにある「ポリシー」タブで、ステータスが「無効」と表示されます。

5.5.9 バックグラウンド自動データ最適化の実行頻度の変更

情報ライフサイクル管理のバックグランドの評価とスケジューラの実行頻度を変更するには、次のステップに従います。

ILM ADO EXECUTION INTERVALパラメータの詳細は、ILM ADOパラメータの管理を参照してください。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. ポリシー実行の設定セクションで、「構成」をクリックします。

    ポリシー実行の設定ダイアログ・ボックスが表示されます。

  4. 「実行間隔」の値を現在表示されている値より低いまたは高い数値に変更し、「OK」をクリックします。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。このページの「ポリシー実行設定」にある「ポリシー」タブで、実行間隔に新しい値が表示されます。

5.5.10 過去24時間のポリシー実行の表示

過去24時間で実行されたポリシーを表示し、ポリシーの実行で移動または圧縮されたオブジェクトを表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. 「過去24時間のポリシー実行サマリー」行の完了したポリシー・リンクまたは失敗したポリシー・リンクをクリックします。クリックすると、いずれかの過去24時間の実行履歴が表示されます。

    ポリシー実行の詳細ダイアログ・ボックスが表示され、過去24時間のポリシーの実行の詳細が表示されます。

5.5.11 過去24時間で移動したオブジェクトの表示

過去24時間に移動されたオブジェクトを表示し、これらのオブジェクトを移動したポリシー/ジョブを表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. 「過去24時間のポリシー実行サマリー」行で、移動したオブジェクト・リンクをクリックします。

    ポリシー実行履歴ダイアログ・ボックスが表示され、過去24時間で実行されたジョブとポリシー、および移動されたオブジェクトの実行履歴が表示されます。

5.5.12 ポリシー詳細の表示

特定のADOポリシーの詳細を表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. ポリシー詳細を表示するには、ポリシー表のポリシー名のリンクをクリックするか、ポリシー表の行を選択して「ポリシーの詳細を表示」ボタンをクリックします。

5.5.13 ポリシーに関連付けられているオブジェクトの表示

特定のポリシーに関連付けられているオブジェクトを表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. 「オブジェクト」列の件数をクリックします。

    ポリシーに関連付けられたオブジェクトが表示されます。

5.5.14 実行前のポリシーの評価

ポリシーを実行する前にポリシーを評価するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. 「評価」リージョンで、「評価」をクリックします。

    表示されるダイアログ・ボックスでは、データベース内のすべてのポリシーを評価するか、特定スキーマのオブジェクトに影響するすべてのポリシーを評価するかを選択できます。

  4. スキーマ名を入力し、「OK」をクリックして評価を開始します。

    「評価」ダイアログ・ボックスが閉じられ、評価が発行されます。ページをリフレッシュしたり、その他のEnterprise Managerタスクを実行して、後から「ポリシー」タブを再表示したりできます。実行すると、「評価」リージョンの「完了」の数が1つ増えます。

  5. 「評価」リージョンの「完了」の数のリンクをクリックすると、完了したすべての評価がリストされたダイアログ・ボックスが表示されます。

  6. 最新評価のタスクIDをクリックすると、評価タスクに現在含まれているすべてのオブジェクトがリストされた「評価詳細」ダイアログ・ボックスが表示されます(これらのオブジェクトは、評価が実行されると圧縮または移動されます)。

  7. 「OK」をクリックすると、実行にオブジェクトのリストが含まれます。「評価詳細」ダイアログ・ボックスが閉じられます。

  8. 最新の評価が含まれる「評価」表の行(一番上の行)を選択し、「実行」をクリックします。

    実行中に影響を受けるオブジェクトがリストされた、評価の実行ダイアログ・ボックスが表示されます。

  9. 「OK」をクリックして実行します。

    評価の実行ダイアログ・ボックスが閉じられます。実行結果は、「過去24時間のポリシー実行サマリー」の「ジョブ」または「ポリシー」リージョンにある「完了」「失敗」のリンクをクリックすると参照できます。また、タスクの状態がINACTIVEからACTIVECOMPLETEDに変わると、「評価」の「完了」の数が1つ減ります。

5.5.15 単一のポリシーの実行

ポリシーに関連付けられているオブジェクトでポリシーをすぐに実行するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. ポリシーを選択し、「ポリシーの実行」をクリックします。

    「ポリシーの実行」ダイアログ・ボックスが表示され、選択したポリシーによって評価されるすべてのオブジェクトがリストされます。また、ダイアログ・ボックスには、実行されるEXECUTE_ILMコマンドを表示するための非表示/表示ボタンも含まれます。このポリシーが有効化されたオブジェクトのみが含まれます。

5.5.16 ポリシー実行の停止

ポリシーの実行を停止するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. 「過去24時間のポリシー実行サマリー」の「ジョブ」リージョンで、「進行中」リンクをクリックします。このステップでは、進行中のタスク/ジョブが少なくとも1つあることを想定しています。

    表示されるダイアログ・ボックスには、現在実行されているすべてのタスクがリストされています。

  4. 表にリストされているいずれかのタスクの「ジョブ」リンクをクリックします。

    タスクの一部として実行されているジョブの詳細がリストされたダイアログ・ボックスが表示されます。

  5. 「OK」をクリックします。

    「ジョブ詳細」ダイアログ・ボックスが閉じられます。

  6. 表で行を選択し、「実行停止」をクリックします。

    実行プロセスの停止を確認するダイアログ・ボックスが表示されます。

  7. 「OK」をクリックします。

    確認のダイアログ・ボックスが閉じられます。

5.5.17 ポリシー実行履歴の表示

特定のポリシーの実行履歴を表示するには、次のステップに従います。

  1. 「管理」メニューから、「記憶域」情報ライフサイクル管理の順に選択します。

    Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。

  2. 情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。

  3. ポリシーを選択し、「実行履歴」をクリックします。

    ポリシー実行履歴ダイアログ・ボックスが表示され、選択したポリシーの実行履歴が表示されます。詳細には、ジョブ情報および移動または圧縮されたオブジェクトが含まれます。

5.6 自動ストレージ圧縮の使用

自動ストレージ圧縮を使用して、初期のダイレクト・ロードおよびDML、および最終データセットに対するスキャンを高速化します。

自動ストレージ圧縮では、ロード、およびロード後のDMLを、圧縮なし形式で処理できます。DMLアクティビティが落ち着くと、圧縮がバックグラウンドの自動タスクで段階的に実行されます。圧縮された最終的なデータは、DMLによる断片化はなく、スキャンに最適です。

自動ストレージ圧縮でのソート動作

  • クラスタリング・ディレクティブがCREATE TABLEまたはALTER TABLECLUSTERING句からのものである場合:
    • 各ダイレクト・ロードで、文レベルでソートが実行されます。
    • 自動ストレージ圧縮では、1 GBのチャンクの移動時にソート順序が保持されます。
  • DBMS_AUTO_CLUSTERING PL/SQLパッケージを使用してクラスタリングが有効になっている場合:
    • ダイレクト・ロードではソートされません。
    • 自動ストレージ圧縮では、1 GBの各チャンクの移動時に行がソートされます。

自動ストレージ圧縮の前提条件

  • 表が、次のプロパティがある表領域に存在する必要があります:
    • SEGMENT SPACE MANAGEMENT AUTO
    • AUTOALLOCATE
  • PDBで、HEAT_MAP=ONを設定します。
  • 表がHCC表である必要があります。

自動ストレージ圧縮を有効にするには

  1. PDBレベルでDBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZEを実行します。
  2. 圧縮なしデータをHCC表にダイレクト・ロードします。
  3. すべての行が圧縮なしであることを確認し、セグメント・サイズを書き留めます。
  4. DMLアクティビティなしで、AUTO_OPTIMIZE_INACTIVITY_THRESHOLDによって分単位で指定された時間が経過すると、自動ストレージ圧縮により、バックグラウンドの自動タスクとして実行が開始されます。
  5. 行が増分的に圧縮されます。

    増分での進行状況は、"Auto compression data moved"システム統計をチェックすることで監視できます。この統計は時間の経過とともに増加します。

  6. 最終的に、"Auto compression data moved"は、圧縮なしの最初のセグメント・サイズと一致します。これは、自動ストレージ圧縮が完了したことを示しています。セグメント・サイズを元のサイズと比べて、それが圧縮されたことを確認します。

ノート:

属性クラスタリングDDLを使用してクラスタリングが指定されている場合:
  • ソートはダイレクト・ロード中に実行されます。
  • 自動ストレージ圧縮ではソート順序が保持されます。
DBMS_AUTO_CLUSTERINGを使用してクラスタリングが有効になっている場合:
  • ソートはダイレクト・ロード中には実行されません。
  • 自動ストレージ圧縮により、データ移動中にソートが実行されます。

関連項目:

  • DMLとハイブリッド列圧縮については、『Oracle Database概要』ガイドを参照してください。
  • ENABLE_AUTO_OPTIMIZEプロシージャについては、『Database PL/SQLパッケージおよびタイプ・リファレンス』で説明しています。

5.6.1 例: 自動ストレージ圧縮の使用

  1. 自動ストレージ圧縮を有効にします。PDBレベルでDBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZEを設定します
    EXEC DBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZE;
  2. HCC圧縮を使用しない表を作成します。

    この例では、圧縮を使用せずに作成された表MYTABを使用します。

  3. 表が圧縮されていないことを確認します。
    SELECT UNIQUE DBMS_COMPRESSION.GET_COMPRESSION_TYPE('SCOTT', 'MYTAB', <ROWID>) FROM SCOTT.MYTAB;
    
    DBMS_COMPRESSION.GET_COMPRESSION_TYPE('SCOTT', 'MYTAB', <ROWID>)
    –--------------------------------------------------------------------
                                                                        1                   

    ノート:

    DBMS_COMPRESSION.GET_COMPRESSION_TYPEは、圧縮タイプを決定できる定数を使用します。値「1」は、表が圧縮されていないことを示します。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』DBMS_COMPRESSION定数に関する項を参照してください。
  4. AUTO_OPTIMIZE_INACTIVITY_THRESHOLDを設定します。

    AUTO_OPTIMIZE_INACTIVITY_THRESHOLDは、自動圧縮を開始するまでDMLアクティビティなしで待機する時間を指定します。待機時間は、DBMS_ILM_ADMIN.CUSTOMIZE_ILMによって設定されます。デフォルトは1440分(1日)です。この値は変更できます:

    EXEC DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.AUTO_OPTIMIZE_INACTIVITY_THRESHOLD, <NEW_VALUE_IN_MINUTES>);

    定義された待機時間が経過すると、自動ストレージ圧縮はバックグラウンドの自動タスクとして起動され、行が増分的に移動および圧縮されます。自動圧縮は一時停止および再起動できます。たとえば、圧縮前に表のサイズを決定するために一時停止する場合は、DBMS_ILM_ADMIN.PAUSE_AUTO_OPTIMIZEを使用します。

    EXEC DBMS_ILM_ADMIN.PAUSE_AUTO_OPTIMIZE;
  5. ALTER TABLEを実行してHCC圧縮を追加し、ダイレクト・パスによってデータをロードします。ここでは、HCC問合せLOW圧縮を表に追加し、/*+ append */を挿入してダイレクト・パス・ロードを実行します。この例では、自動圧縮が一時停止されている間、表の圧縮なしのサイズを確認します。
     SELECT BYTES/1024/1024 MB FROM DBA_SEGMENTS WHERE OWNER = 'SCOTT' AND 
     SEGMENT_NAME = 'MYTAB';
    
    MB                                                                      
    -----                                                                  
    5.625  
    

    問合せによって、圧縮されていない表サイズが返されます。

  6. 自動圧縮の増分での進行状況をAuto compression data movedシステム統計をチェックして監視します。この統計は、データの移動および圧縮によって時間とともに増加します。以前に圧縮を一時停止したため、Auto compression data movedの値は0です。自動圧縮は開始していません。
    SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE 'AUTO COMPRESSION DATA%';
    
    NAME					     VALUE
    ------------------------------------------- --------
    Auto compression data movement success      0
    Auto compression data movement failure      0
    Auto compression data moved                 0
    

    V$SYSSTATは、自動圧縮を使用しているすべての表の値の合計を示します。複数の表を圧縮する場合、Auto compression data moved の値には、それらのすべての表によって移動されるデータが含まれます。また、切り上げのため、この値が長期間にわたって圧縮されていないデータの実際のサイズと正確には一致しない場合があります。

  7. 次に、auto_optimize_inactivity_thresholdが満たされたときに開始するよう自動圧縮を再開します。
    EXEC DBMS_ILM_ADMIN.RESUME_AUTO_OPTIMIZE;
  8. 圧縮操作は監視できます。続行すると、Auto compression data movedの値が増加します。
    SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE 'AUTO COMPRESSION DATA%';
    
    NAME					     VALUE
    ------------------------------------------- --------
    Auto compression data movement success      1
    Auto compression data movement failure      0
    Auto compression data moved                 6
    

    「Auto compression data moved」の値は、圧縮されていない約6 MBのデータが圧縮に移動されたことを示します。自動圧縮が開始された時点で圧縮されていないデータのサイズは5.625 MBでした。

    この例では、圧縮前のセグメント・サイズと圧縮中に移動されるデータの量が完全には一致しない場合があることを示しています。V$SYSSTATは、自動圧縮を使用したすべての表の値の合計を示します。前述のように、複数の表をロードする場合、Auto compression data movedにはそれらの表のデータも含まれます。