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

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 データ・クラスのパーティションへの割当て」の説明

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

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

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

5.1.2.1.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.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を使用して、監査をさらに拡張することができます。

5.1.2.4.5 有効期限

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

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