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の注文を個別のパーティションに格納し、前年までの注文を他のパーティションに格納します。
Oracleでは複数の異なるパーティション化方法を提供します。レンジ・パーティション化は、ILMのためによく使用されるパーティション化方法の1つです。時間隔パーティション化および参照パーティション化も、ILM環境での使用に特に適しています。
データのパーティション化には様々な利点があります。パーティション化により、データを使用方法に応じて適切なストレージ・デバイスに簡単に分散すると同時に、データをオンラインに保ち、最もコスト効果の高いデバイスに格納できるようになります。パーティション化はデータにアクセスするすべてのユーザーにとって透過的であるため、アプリケーションの変更が必要ありません。このため、いつでもパーティション化を実装できます。新しいパーティションが必要なときには、ADD PARTITION
句を使用して追加するだけです。また、時間隔パーティションを使用している場合には、パーティションが自動的に作成されます。
その他の利点として、各パーティションが独自のローカル索引を持つことが可能です。オプティマイザがパーティション・プルーニングを使用すると、問合せは、すべてのパーティションではなく関連するパーティションのみにアクセスするため、問合せのレスポンス時間が短縮されます。
5.1.2.1.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.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.2 ヒート・マップおよびADOを使用したILM戦略の実装
データベースでのデータ移動のために情報ライフサイクル管理(ILM)計画を実装するには、ヒート・マップおよび自動データ最適化(ADO)の機能を使用します。
ノート:
ヒート・マップおよびADOは、Oracle Database 12cリリース2のマルチテナント環境でサポートされています。
この項では、次の項目について説明します。
関連項目:
-
ヒート・マップおよびADOを使用するOracle Enterprise Manager Cloud Controlの使用の詳細は、「Oracle Enterprise ManagerでのILMヒート・マップおよびADOの管理」を参照してください
-
Database Vaultで保護されたオブジェクト上でのILM操作をADO管理ユーザーが実行できるようにする認可の付与など、Oracle Database Vaultレルムおよびコマンド・ルールによる情報ライフサイクル管理(ILM)の使用の詳細は、Oracle Database Vault管理者ガイドを参照してください。
5.2.1 ヒート・マップの使用
ILM戦略を実装するために、Oracle Databaseのヒート・マップを使用すればデータのアクセスと変更を追跡できます。
ヒート・マップは、セグメント・レベルのデータ・アクセス・トラッキングおよびセグメントおよび行レベルのデータ変更トラッキングを提供します。HEAT_MAP
初期化パラメータを使用して、この機能を有効にできます。
ヒート・マップ・データは、ADOポリシーを使用してインメモリー列ストア(IM列ストア)のコンテンツを管理するための、自動データ最適化(ADO)を支援します。列統計およびその他の関連統計が含まれるヒート・マップ・データを使用すると、IM列ストアがいつ満杯(メモリー不足)になるかを判断できます。ほぼ満杯と判断されたときに、アクセス頻度が高くIM列ストアに移入することで利点が得られるセグメントが存在する場合は、非アクティブなセグメントが削除されます。
この項では、次の項目について説明します。
関連項目:
-
インメモリー列ストアの有効化およびサイズ設定の詳細は、『Oracle Database In-Memoryガイド』を参照してください
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の場合、システム・レベルでヒート・マップを有効にする必要があります。
関連項目:
-
ADOの詳細は、「自動データ最適化の使用」を参照してください
-
HEAT_MAP
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください
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ポリシーには、P1
、P2
およびP
n
などのシステム生成名が付けられます。
セグメント・レベルのポリシーは1回のみ実行されます。ポリシーが正常に実行されると、そのポリシーは無効になり、再度評価されることはありません。ただし、ポリシーを明示的に再び有効化することはできます。行レベルのポリシーは継続的に実行され、正常な実行後も無効になることはありません。
ADOポリシーの有効範囲は、キーワードGROUP
、ROW
または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)では、INMEMORY
、INMEMORY
MEMCOMPRESS
、NO
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;
関連項目:
-
インメモリー列ストアおよびADOのサポートの詳細は、『Oracle Database In-Memoryガイド』を参照してください
-
SQLのCREATE TABLE文のILM句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
-
SQLのCREATE INDEX文のILM句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
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
表の圧縮およびストレージ層ポリシーを施行する方法を示し、次のビジネス要件を反映します。
-
バルク・ロード・データ
-
OLTPワークロードの実行
-
更新が6か月間なければ、ARCHIVE HIGHで圧縮
-
低コスト・ストレージへの移動
例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パラメータ
名前 | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TBS_PERCENT
*パラメータの値のために、ADOは最善を尽くしますが、保障はされません。表領域割当て率がTBS_PERCENT_USED
の値に到達すると、表領域割当ての空き領域比率がTBS_PERCENT_FREE
の値に近づくように、ADOはデータの移動を開始します。例として、TBS_PERCENT_USED
が85およびTBS_PERCENT_FREE
が25
に設定されると、表領域が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 ...
関連項目:
-
DBMS_ILM_ADMIN
PL/SQLパッケージのCUSTOMIZE_ILM
プロシージャでILM ADOパラメータを設定する方法を示す例は、例5-9を参照してください -
Oracle Enterprise Manager Cloud ControlによるILM ADOパラメータの設定の詳細は、「Oracle Enterprise ManagerでのILMヒート・マップおよびADOの管理」を参照してください
-
ILM ADOパラメータの完全なリストは、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
-
DBMS_ILM_ADMIN
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
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パッケージを使用して、ポリシーでオブジェクトを再作成することもできます。
関連項目:
-
ILM ADOパラメータの詳細は、「ILM ADOパラメータの管理」を参照してください
-
DBMS_ILM
、DBMS_ILM_ADMIN
およびDBMS_METADATA
パッケージの詳細は、『Oracle Database 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には、表および表パーティションの移動に関連する制限事項があります。
関連項目:
-
表の移動の制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
-
表パーティションの移動の制限事項の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
-
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
コマンドによって暗黙的にレポートされない非表示列です。 - この列は明示的に更新できます。
行アーカイブが有効になっている表への問合せ
行アーカイブが有効になっている表に対してINSERT
、UPDATE
およびCREATE AS SELECT
を使用した場合の動作に留意してください。
各行のORA_ARCHIVE_STATE
のデフォルト値は0です。これは、行はその列値をアーカイブ済に変更するまでアクティブ・データとみなされるということです。したがって、行アーカイブ表へのINSERTでは、必ず、新しい行がアクティブに設定されます。
UPDATE
更新では、どの行のORA_ARCHIVE_STATE
値も直接設定できます。規則ではactive
またはarchived
を示すために"0"または"1"を使用することになっていますが、ORA_ARCHIVE_STATE
を任意の有効なVARCHAR2(4000)値に更新できます。
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_STATE がSELECT リストに明示的に含まれている
|
不可 | 選択された行を、行の可視性に応じて、リクエストされた列にコピーします。各行の既存の行アーカイブ状態をソース表からターゲット表に伝播します。 |
可 | 可 | ORA_ARCHIVE_STATE がSELECT に明示的に含まれていない
|
不可 | 選択された行を、行の可視性に応じて、選択された列にコピーします。ターゲット表内のすべての新規行の新しい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
'で表されます。
DBMS_ILMでは、archive_state_active constant varchar2(1) := '0'; archive_state_archived constant varchar2(1) := '1';
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');
関連項目:
-
Oracle Temporalの詳細は、『Oracle Database開発ガイド』を参照してください
-
DBMS_FLASHBACK_ARCHIVE
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください -
CREATE
TABLE
またはALTER
TABLE
を使用した有効時間の一時モデリングの開始の詳細は、『Oracle Database SQL言語リファレンス』を参照してください -
表情報の監視に使用するビューの詳細は、『Oracle Databaseリファレンス』を参照してください
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.4 パーティション化を使用したILMシステムの手動実装
パーティション化を使用して、情報ライフサイクル管理(ILM)システムを手動で実装できます。
例5-12では、手動でストレージ層を作成し、それらのストレージ層に対して表をパーティション化し、そのデータベースに対して仮想プライベート・データベース(VPD)・ポリシーを設定して、オンライン・アーカイブ層のデータへのアクセスを制限する方法を示します。
関連項目:
-
CREATE
TABLE
SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください -
DBMS_RLS
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
例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では、ヒート・マップおよび自動データ最適化を管理できます。
この項では、次の項目について説明します。
関連項目:
-
ヒート・マップおよびADOポリシー詳細の表示に使用できるビューの詳細は、「ビューを使用したヒート・マップ・トラッキング・データの表示」および「ビューを使用したADOのポリシーの監視」を参照してください
-
Oracle Enterprise Manager Cloud Controlの管理の詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドを参照してください
5.5.1 データベース管理メニューへのアクセス
データベースの「管理」メニューにアクセスするには:
-
Oracle Enterprise Manager Cloud Controlにログインします。
-
「ターゲット」メニューから「データベース」を選択します。
-
リストでデータベース名をクリックします。
-
データベース・ホームページで「管理」メニューが表示されます。
5.5.2 表領域レベルの自動データ最適化アクティビティの表示
データベースのサイズ別に選択した上位100の表領域のアクティビティを監視するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページでは、最終アクセス時刻、最終書込み時刻、最終全体スキャン時刻および最終参照スキャン時刻に基づいて上位100の表領域アクティビティ・ヒート・マップを表示できます。
デフォルトでは、ヒート・マップ内の各ボックスのサイズはヒート・マップ内の表領域を表し、表領域のサイズによって決まります。情報ライフサイクル管理を使用すると、表領域からセグメント・レベルのヒート・マップにドリルダウンできます。
5.5.3 任意の表領域のセグメント・アクティビティ詳細の表示
任意の表領域のセグメント・アクティビティ詳細を表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「追加の表示」ボタンをクリックします。
Enterprise Managerにより、任意の表領域のセグメント・アクティビティ詳細を検索できるダイアログ・ボックスが表示されます。
-
ダイアログ・ボックスに表領域名を入力して、「検索」ボタンをクリックします。
Enterprise Managerにより、表領域のセグメント・アクティビティ詳細が表示されます。
-
「表領域ポリシーの編集」ボタンをクリックすると、「ADO」タブが選択された状態で、表領域の編集ページが表示されます。圧縮または移動を許可する表領域のポリシーを作成できます。
5.5.4 任意のオブジェクトのセグメント・アクティビティ詳細の表示
任意のオブジェクトのセグメント・アクティビティ詳細を表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
カーソルをデータベース・レベルのヒート・マップ内の任意のボックスに移動します(各ボックスは表領域を表します)。表示するオブジェクトが属する表領域をクリックします。
Enterprise Managerにより、表領域に属する上位100の最大オブジェクトの表領域レベルのヒート・マップが表示されます。「セグメント・アクティビティ」表には、上位100の最大オブジェクトのセグメント・アクティビティ詳細が表示されます。
-
情報ライフサイクル管理ページで、「追加の表示」ボタンをクリックします。
Enterprise Managerにより、表領域に属する任意のオブジェクトのセグメント・アクティビティ詳細を検索できるダイアログ・ボックスが表示されます。
-
ダイアログ・ボックスにスキーマ名とオブジェクト名を入力して、「検索」をクリックします。
Enterprise Managerにより、オブジェクトのセグメント・アクティビティ詳細が表示されます。
-
「オブジェクト・ポリシーの編集」ボタンをクリックすると、「ADO」タブが選択された状態で、オブジェクトの編集ページが表示されます。圧縮または移動を許可するオブジェクトのポリシーを作成できます。
5.5.5 任意のオブジェクトのセグメント・アクティビティ履歴の表示
任意のオブジェクトのセグメント・アクティビティ履歴を表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
カーソルをデータベース・レベルのヒート・マップ内の任意のボックスに移動します(各ボックスは表領域を表します)。表示するオブジェクトが属する表領域をクリックします。
Enterprise Managerにより、表領域に属する上位100の最大オブジェクトの表領域レベルのヒート・マップが表示されます。「セグメント・アクティビティ」表には、上位100の最大オブジェクトのセグメント・アクティビティ詳細が表示されます。
-
セグメント・アクティビティ詳細表でオブジェクトを選択し、「アクティビティ履歴」ボタンをクリックします。
Enterprise Managerにより、「ADO」タブが選択された状態で、オブジェクトの編集ページが表示されます。「ADO」タブには、ポリシーのリストとセグメント・アクセス履歴が表示されます。
-
セグメントを選択して、日付範囲が過去60日間になるよう変更し、「毎日」オプションを選択して、「リフレッシュ」ボタンをクリックすると、そのオブジェクトの過去60日間に渡るセグメント・アクセス履歴が表示されます。
5.5.6 自動データ最適化でのアクティビティ・セグメントの検索
様々な期間中に自動データ最適化でセグメント・アクティビティを検索するには、次のステップに従います:
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、ヒート・マップの内のボックスのいずれかをクリックします。データベース・レベルの初期表示から、ヒート・マップのボックスをクリックして、その表領域の上位100の最大オブジェクトを表示します。その後にヒート・マップのボックスをクリックして、そのオブジェクトの上位100の最大セグメントを表示できます。
-
最終アクセス時刻の1年前のタイムスタンプを入力し、「実行」をクリックします。昨年アクセスまたは変更されていないセグメントのリストが表示されます。セグメントはセグメント・サイズの降順にソートされます。
オブジェクト・レベルのヒート・マップでは、表領域、名前、パーティション、タイプ、最終アクセス時刻、最終書込み時刻、最終全体スキャン時刻および最終参照スキャン時刻に基づいて、特定のセグメントを検索できます。
行(セグメント)を選択してそのセグメントの行アクティビティを表示でき、「ポリシー」列をクリックするとセグメントに関連付けられているポリシーが表示されます。
5.5.7 セグメントのポリシーの表示
セグメントに関連付けられているポリシーを表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「実行」をクリックします。検索結果のセグメントに関連付けられたポリシーがある場合は、ゼロ以外の件数が「ポリシー」列に表示されます。件数の上にマウスを移動すると、継承されたポリシーを含む、セグメントに関連付けられているポリシーが表示されます。件数がゼロの場合は、ポリシーはセグメントに関連付けられていません。
データベース・レベルのヒート・マップから表領域レベルのヒート・マップにどりダウンします。表領域レベルのヒート・マップでは、Enterprise Managerに、表領域に属する上位100のオブジェクトが表示されます。Enterprise Managerで、各オブジェクトのポリシーの件数が列に表示されます。
表領域レベルのヒート・マップからオブジェクトを選択し、オブジェクト・レベルのヒート・マップにドリルダウンします。Enterprise Managerには、オブジェクトに属する上位100の最大セグメントが表示されます。Enterprise Managerで、各セグメントのポリシーの件数が「ポリシー」列に表示されます。
5.5.8 バックグラウンド・アクティビティの無効化
自動データの最適化のバックグラウンド評価およびスケジューラを無効にするには、次のステップに従います:
ILM ADO ENABLED
パラメータの詳細は、ILM ADOパラメータの管理を参照してください。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
ポリシー実行の設定セクションで、「構成」をクリックします。
ポリシー実行の設定ダイアログ・ボックスが表示されます。
-
「ステータス」ドロップダウンを「無効」に変更して、「OK」をクリックします。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。このページの「ポリシー実行設定」セクションにある「ポリシー」タブで、ステータスが「無効」と表示されます。
5.5.9 バックグラウンド自動データ最適化の実行頻度の変更
情報ライフサイクル管理のバックグランドの評価とスケジューラの実行頻度を変更するには、次のステップに従います。
ILM ADO EXECUTION
INTERVAL
パラメータの詳細は、ILM ADOパラメータの管理を参照してください。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
ポリシー実行の設定セクションで、「構成」をクリックします。
ポリシー実行の設定ダイアログ・ボックスが表示されます。
-
「実行間隔」の値を現在表示されている値より低いまたは高い数値に変更し、「OK」をクリックします。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。このページの「ポリシー実行設定」にある「ポリシー」タブで、実行間隔に新しい値が表示されます。
5.5.10 過去24時間のポリシー実行の表示
過去24時間で実行されたポリシーを表示し、ポリシーの実行で移動または圧縮されたオブジェクトを表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
「過去24時間のポリシー実行サマリー」行の完了したポリシー・リンクまたは失敗したポリシー・リンクをクリックします。クリックすると、いずれかの過去24時間の実行履歴が表示されます。
ポリシー実行の詳細ダイアログ・ボックスが表示され、過去24時間のポリシーの実行の詳細が表示されます。
5.5.11 過去24時間で移動したオブジェクトの表示
過去24時間に移動されたオブジェクトを表示し、これらのオブジェクトを移動したポリシー/ジョブを表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
「過去24時間のポリシー実行サマリー」行で、移動したオブジェクト・リンクをクリックします。
ポリシー実行履歴ダイアログ・ボックスが表示され、過去24時間で実行されたジョブとポリシー、および移動されたオブジェクトの実行履歴が表示されます。
5.5.12 ポリシー詳細の表示
特定のADOポリシーの詳細を表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
ポリシー詳細を表示するには、ポリシー表のポリシー名のリンクをクリックするか、ポリシー表の行を選択して「ポリシーの詳細を表示」ボタンをクリックします。
5.5.13 ポリシーに関連付けられているオブジェクトの表示
特定のポリシーに関連付けられているオブジェクトを表示するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
「オブジェクト」列の件数をクリックします。
ポリシーに関連付けられたオブジェクトが表示されます。
5.5.14 実行前のポリシーの評価
ポリシーを実行する前にポリシーを評価するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
「評価」リージョンで、「評価」をクリックします。
表示されるダイアログ・ボックスでは、データベース内のすべてのポリシーを評価するか、特定スキーマのオブジェクトに影響するすべてのポリシーを評価するかを選択できます。
-
スキーマ名を入力し、「OK」をクリックして評価を開始します。
「評価」ダイアログ・ボックスが閉じられ、評価が発行されます。ページをリフレッシュしたり、その他のEnterprise Managerタスクを実行して、後から「ポリシー」タブを再表示したりできます。実行すると、「評価」リージョンの「完了」の数が1つ増えます。
-
「評価」リージョンの「完了」の数のリンクをクリックすると、完了したすべての評価がリストされたダイアログ・ボックスが表示されます。
-
最新評価のタスクIDをクリックすると、評価タスクに現在含まれているすべてのオブジェクトがリストされた「評価詳細」ダイアログ・ボックスが表示されます(これらのオブジェクトは、評価が実行されると圧縮または移動されます)。
-
「OK」をクリックすると、実行にオブジェクトのリストが含まれます。「評価詳細」ダイアログ・ボックスが閉じられます。
-
最新の評価が含まれる「評価」表の行(一番上の行)を選択し、「実行」をクリックします。
実行中に影響を受けるオブジェクトがリストされた、評価の実行ダイアログ・ボックスが表示されます。
-
「OK」をクリックして実行します。
評価の実行ダイアログ・ボックスが閉じられます。実行結果は、「過去24時間のポリシー実行サマリー」の「ジョブ」または「ポリシー」リージョンにある「完了」か「失敗」のリンクをクリックすると参照できます。また、タスクの状態がINACTIVEからACTIVEやCOMPLETEDに変わると、「評価」の「完了」の数が1つ減ります。
5.5.15 単一のポリシーの実行
ポリシーに関連付けられているオブジェクトでポリシーをすぐに実行するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
ポリシーを選択し、「ポリシーの実行」をクリックします。
「ポリシーの実行」ダイアログ・ボックスが表示され、選択したポリシーによって評価されるすべてのオブジェクトがリストされます。また、ダイアログ・ボックスには、実行される
EXECUTE_ILM
コマンドを表示するための非表示/表示ボタンも含まれます。このポリシーが有効化されたオブジェクトのみが含まれます。
5.5.16 ポリシー実行の停止
ポリシーの実行を停止するには、次のステップに従います。
-
「管理」メニューから、「記憶域」、情報ライフサイクル管理の順に選択します。
Enterprise Managerでは、情報ライフサイクル管理ページが表示されます。
-
情報ライフサイクル管理ページで、「ポリシー」タブをクリックします。
-
「過去24時間のポリシー実行サマリー」の「ジョブ」リージョンで、「進行中」リンクをクリックします。このステップでは、進行中のタスク/ジョブが少なくとも1つあることを想定しています。
表示されるダイアログ・ボックスには、現在実行されているすべてのタスクがリストされています。
-
表にリストされているいずれかのタスクの「ジョブ」リンクをクリックします。
タスクの一部として実行されているジョブの詳細がリストされたダイアログ・ボックスが表示されます。
-
「OK」をクリックします。
「ジョブ詳細」ダイアログ・ボックスが閉じられます。
-
表で行を選択し、「実行停止」をクリックします。
実行プロセスの停止を確認するダイアログ・ボックスが表示されます。
-
「OK」をクリックします。
確認のダイアログ・ボックスが閉じられます。
5.6 自動ストレージ圧縮の使用
自動ストレージ圧縮を使用して、初期のダイレクト・ロードおよびDML、および最終データセットに対するスキャンを高速化します。
自動ストレージ圧縮でのソート動作
- クラスタリング・ディレクティブが
CREATE TABLE
またはALTER TABLE
のCLUSTERING
句からのものである場合:- 各ダイレクト・ロードで、文レベルでソートが実行されます。
- 自動ストレージ圧縮では、1 GBのチャンクの移動時にソート順序が保持されます。
DBMS_AUTO_CLUSTERING
PL/SQLパッケージを使用してクラスタリングが有効になっている場合:- ダイレクト・ロードではソートされません。
- 自動ストレージ圧縮では、1 GBの各チャンクの移動時に行がソートされます。
自動ストレージ圧縮の前提条件
- 表が、次のプロパティがある表領域に存在する必要があります:
SEGMENT SPACE MANAGEMENT AUTO
-
AUTOALLOCATE
- PDBで、
HEAT_MAP=ON
を設定します。 - 表がHCC表である必要があります。
自動ストレージ圧縮を有効にするには
- PDBレベルで
DBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZE
を実行します。 - 圧縮なしデータをHCC表にダイレクト・ロードします。
- すべての行が圧縮なしであることを確認し、セグメント・サイズを書き留めます。
- DMLアクティビティなしで、
AUTO_OPTIMIZE_INACTIVITY_THRESHOLD
によって分単位で指定された時間が経過すると、自動ストレージ圧縮により、バックグラウンドの自動タスクとして実行が開始されます。 - 行が増分的に圧縮されます。
増分での進行状況は、"
Auto compression data moved
"システム統計をチェックすることで監視できます。この統計は時間の経過とともに増加します。 - 最終的に、"
Auto compression data moved
"は、圧縮なしの最初のセグメント・サイズと一致します。これは、自動ストレージ圧縮が完了したことを示しています。セグメント・サイズを元のサイズと比べて、それが圧縮されたことを確認します。
ノート:
属性クラスタリングDDLを使用してクラスタリングが指定されている場合:- ソートはダイレクト・ロード中に実行されます。
- 自動ストレージ圧縮ではソート順序が保持されます。
DBMS_AUTO_CLUSTERING
を使用してクラスタリングが有効になっている場合:
- ソートはダイレクト・ロード中には実行されません。
- 自動ストレージ圧縮により、データ移動中にソートが実行されます。
関連項目:
- DMLとハイブリッド列圧縮については、『Oracle Database概要』ガイドを参照してください。
- ENABLE_AUTO_OPTIMIZEプロシージャについては、『Database PL/SQLパッケージおよびタイプ・リファレンス』で説明しています。
5.6.1 例: 自動ストレージ圧縮の使用
- 自動ストレージ圧縮を有効にします。PDBレベルで
DBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZE
を設定しますEXEC DBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZE;
- HCC圧縮を使用しない表を作成します。
この例では、圧縮を使用せずに作成された表
MYTAB
を使用します。 - 表が圧縮されていないことを確認します。
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定数に関する項を参照してください。 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;
ALTER TABLE
を実行してHCC圧縮を追加し、ダイレクト・パスによってデータをロードします。ここでは、HCC問合せLOW圧縮を表に追加し、/*+ append */を挿入してダイレクト・パス・ロードを実行します。この例では、自動圧縮が一時停止されている間、表の圧縮なしのサイズを確認します。SELECT BYTES/1024/1024 MB FROM DBA_SEGMENTS WHERE OWNER = 'SCOTT' AND SEGMENT_NAME = 'MYTAB'; MB ----- 5.625
問合せによって、圧縮されていない表サイズが返されます。
- 自動圧縮の増分での進行状況を
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
の値には、それらのすべての表によって移動されるデータが含まれます。また、切り上げのため、この値が長期間にわたって圧縮されていないデータの実際のサイズと正確には一致しない場合があります。 - 次に、
auto_optimize_inactivity_threshold
が満たされたときに開始するよう自動圧縮を再開します。EXEC DBMS_ILM_ADMIN.RESUME_AUTO_OPTIMIZE;
- 圧縮操作は監視できます。続行すると、
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
にはそれらの表のデータも含まれます。