この章の構成は、次のとおりです。
注意:
コマンド行ユーティリティではなく、リアルタイムのパージおよびアーカイブ・オプションを使用することをお薦めします。
アーカイブおよびパージ・ユーティリティ(スケジュール済タスクベースおよびコマンドライン)は、Oracle Identity Managerの基礎となる表からデータをパージするだけで、領域の解放は行いません。領域の解放の詳細は、次のURLにあるMy Oracle Support Webサイトの「OIMデータベースのLOB列の大きくなりすぎたフットプリント(サイズが大きいフットプリント)の領域を解放する方法(Doc ID 2017034.1)」を参照してください。
https://support.oracle.com
Oracle Identity Managerには、エンティティとその依存データのためのアーカイブおよびパージ・ソリューションが用意されています。
Oracle Identity Managerのアプリケーション機能は、大量のデータを生成します。パフォーマンスとスケーラビリティの標準を満たすために、Oracle Identity Managerエンティティのライフ・サイクル管理用に生成されるデータを維持することが課題になります。この課題に対処するために、Oracle Identity Managerでは、オフラインのデータ・パージおよびアーカイブ・ソリューションに加え、オンラインの継続的なソリューションも提供しています。
表23-1に、Oracle Identity Managerが提供するエンティティとその依存データのためのアーカイブおよびパージ・ソリューションのリストを示します。
表23-1 アーカイブおよびパージのソリューション
エンティティのアーカイブおよびパージ | リアルタイム・オンライン・モード | コマンド行からの操作 | その他のモードからの使用 |
---|---|---|---|
リコンシリエーション |
はい |
はい |
|
プロビジョニング・タスク |
はい |
はい |
|
リクエスト |
はい |
はい |
|
編成 |
はい |
いいえ |
|
証明 |
はい |
いいえ |
|
レガシー監査 |
はい |
いいえ |
パーティションベースのアプローチの詳細は、「レガシー監査フレームワークでの監査データ増加の管理対策について」を参照してください。 |
軽量監査 |
はい |
いいえ |
パーティションベースのアプローチの詳細は、「軽量監査フレームワークでの監査データ増加の管理対策について」を参照してください。 |
アーカイブとパージの概念としては、パージ専用ソリューションまたはアーカイブ・ソリューション、データのアーカイブとパージ、保存期間、アーカイブ・パージ操作のモードがあります。
この項では、次の項目について説明します。
パージのみのソリューションと、パージにアーカイブを加えたソリューションは、リアルタイム・パージおよびアーカイブ機能に適用できます。
Oracle Identity Managerエンティティは、そのエンティティに関連するデータをパージおよびアーカイブする方法に基づいて、リアルタイム・パージ・アーカイブ機能の観点から次のように分類されます。
パージのみ: データが直接パージされ、アーカイブされないエンティティ。これに該当するエンティティは、リコンシリエーション、プロビジョニング・タスク、編成およびレガシー監査(UPA)です。
パージおよびアーカイブ: データがパージされ、アーカイブもされるエンティティ。これは、リクエスト・エンティティと証明書エンティティに適用されます。
注意:
リアルタイム・パージおよびアーカイブ・ソリューションは、継続的なデータ・パージ機能を提供します。また、コマンド行のアーカイブ・ユーティリティを使用して、定期的にデータをアーカイブすることもできます(必要な場合)。コマンド行版のアーカイブ・パージ・ユーティリティには、このようなエンティティの分類はありません。これらでは、基本的にパージの前にアーカイブを実行します。コマンド行のアーカイブ・ユーティリティの詳細は、「Oracle Identity Governanceのアーカイブ・パージ・ユーティリティのコマンド行オプションの使用」を参照してください。
パージ前のアーカイブは、アクティブ機能表またはエンティティ表からデータを削除する、Oracle Identity Managerコマンド行ユーティリティが従う標準メカニズムです。
データのアーカイブは、シャドウ・コピーまたは元の表のレプリカにデータをコピーすることで実行されます(通常は、ARCH_TABLE_NAMEの接尾辞が付きます)。パージおよびアーカイブのカテゴリに含まれるエンティティのデータ・パージ・ソリューションでは、パージの前にアーカイブ操作が実行されます。
データのパージとは、アーカイブ操作を先に実行することなく、アクティブ機能表またはエンティティ表からデータを削除またはパージするメカニズムです。
パージされたデータは、Oracle Identity Managerではリカバリできません。
リアルタイム・パージとは、Oracle Identity Managerの稼働中にデータを削除またはパージすることを意味し、機能呼出しや同時実行性、ワークロードに関係なく使用できます。
ただし、リアルタイムという文字どおりの意味とは異なり、システムで作成されたエンティティ・データが即座に削除されることはありません。
保存期間は、実用とコンプライアンスを目的として、Oracle Identity Managerにデータを保存しておく必要のある期間を定義します。
データは、該当するエンティティ・データの保存期間の値で定義された期限に基づいて削除されます。「保存期間」属性は、リアルタイム・パージ機能のために、OIMデータ・パージ・スケジュール済ジョブのユーザー・インタフェースから定義する必要があります。
アーカイブ・パージ操作はオンライン・モードでもオフライン・モードでも実行できます。
アーカイブ・パージ操作は、次のモードで実行できます。
オフライン・モード: このモードでは、データのアーカイブとパージの実行中に、Oracle Identity Managerが使用できなくなります。全体の操作がデータベース集中型になるため、最初に制約/索引が無効にされ、エンティティ表のデータがコピーおよび削除されてから、削除後の処理が再有効化されます。これにより、削除処理のパフォーマンスを最大化して、表レベルの制約が無効になっている期間に入力されたデータが機能的に矛盾する可能性を排除しています。そのため、Oracle Identity Managerを使用したトランザクション・レベルの変更は非推奨になります。その結果として、システムは使用の観点からオフラインになります。
オンライン・モード:: このモードでは、データベース・レベル全体の索引/制約が通常どおり有効の状態で、データのアーカイブとパージが実行されます。そのため、操作の観点からは、オンライン・モードで継続的にOracle Identity Managerを使用できます。
注意:
リアルタイム・パージは、オンライン・モードのみをサポートします。コマンド行のアーカイブ・パージ・ユーティリティは、ユーザーの入力に応じてオンラインとオフラインの両方のモードをサポートします。
Oracle Identity Managerでは、リアルタイムの継続的なデータ・パージ・ソリューションが提供され、パフォーマンスとスケーラビリティの標準を満たすために、様々なエンティティのライフ・サイクル管理用に生成されるデータを保持します。
リアルタイムの継続的なデータ・パージ・ソリューションの使用方法について次の各項で説明します。
Oracle Identity Managerでは、リアルタイム・パージおよびアーカイブ機能がデフォルトで使用できます。これにより、エンティティ・データは、オプションに基づいて継続的にパージできます。
このパージ・ソリューションは、1回構成すると、管理者の介入なしに自動的に機能します。
リアルタイム・パージおよびアーカイブの機能は、次のとおりです。
管理者は、Oracle Identity System Administrationの「スケジュール済タスク」セクションを使用して、エンティティに対するいくつかの重要なパラメータ(保存期間、実行期間、パージ基準など)に値を指定します。
各パージの実行に関する診断情報は、ログとして取得されます。
パージ・タスクは、定期的に実行されます。
エンティティのモジュール(リクエスト、リコンシリエーション、タスク、編成、レガシー監査など)は、割り当てられた時間間隔に従ってパージされます。
パージ・ソリューションは、フェイルセーフです。これは、システムがCPUサイクルを無制限に消費する状況が発生しないことを意味します。フェイルセーフ設計により、他のモジュールに与える影響は最小限に抑えられます。フェイルセーフ機能は、次のようにして実現されます。
各エンティティに対するパージ実行の自動カットオフまでの最大実行時間: 各パージ・ユーティリティの実行は、最大パージ実行時間パラメータの値(分単位)で制御されます。この最大パージ実行継続時間を超えると、パージは自動的に停止されます。これは、各エンティティ・レベルで指定されるため、パージの時間間隔の割当てを機能レベルで制御できます。
削除用に選別される各バッチは、時間係数を認識します。時間係数を超過すると、後続のバッチがスキップされ、ユーティリティの制御フローが完了します。
エンティティごとの最大パージ実行時間(分単位)は、スケジュール済タスクのUIで指定できます。
シングル・スレッドのバッチ処理: パージ操作では、コミットが発行される前に、削除する行数が最大になるバッチ・サイズを受け入れます。これにより、多数の行にパージが適用されたときに、REDOログのセグメントが過剰に増加することを防止します。バッチ・サイズは、パージ実行操作用のスケジュール済タスクのインタフェースから受け入れられます。
データの増加と、それに続くフットプリントは、継続的に制御されます。
これは、オンラインで操作され、サービスが停止することはありません。
自動化されたスケジュール済タスクによるパージ操作は、事前に定義した周期で暗黙的に非対話型で実行されます。パージ操作に関連する各種のメトリック(エンティティのモジュール名、成功または失敗のステータス、削除対象の行数など)はログに記録されます。これらのログは、パージ操作の実行ごとの診断指針になります。
リアルタイム・パージ・ユーティリティ・フレームワークを介してパージされるデータの量は、時間ウィンドウ、選択したエンティティ、既存のワークロードなどいくつかの入力と相関します。このパージ機能によるOracle Identity Managerでのデータのアウトフローがインフローより少ない場合は、システムである程度のデータ量が蓄積されたことを意味します。これは、コマンド行のアーカイブ/パージ・ユーティリティを使用して、適切な時点でパージできます。
エンティティ・データは、オプションまたはユーティリティの実行を構成するときに行った選択内容に基づいて、パージ・ソリューションにより継続的にパージされます。これらのオプションは、データ保存のポリシーとメンテナンスの要件に応じて変更できます。
リアルタイム・パージおよびアーカイブを構成するには:
この項で説明したスケジュール・タスクUIに対する構成入力の手順以外には、アーカイブ表領域の作成などの手動による実行が必要になる手順はありません。これ以降の各項に記載された手順は、すべて、コマンド行バージョンのユーティリティを実行するためのものです。
注意:
スケジュール・タスクのインタフェースからリアルタイム・アーカイブ・パージ操作を行う場合は、保存期間をゼロに設定してはいけません。保存期間をゼロに設定すると、パージ操作で不整合が発生する可能性があります。
複数のOIMデータ・パージ・ジョブ・スケジュール済ジョブの同時実行は、スケジュール・タスク機能のインスタンス化ではサポートされません。
Oracle Identity Managerの両方のモード(スケジュール・タスク・モードとコマンド行モード)から、エンティティに対するアーカイブ/パージ・ユーティリティを重複して実行しないでください。
パージの内部詳細(リクエスト、リコンシリエーションおよびプロビジョニング・タスクのパージ対象になる表など)は、コマンド行ユーティリティに関する後続の項を参照してください。リアルタイムのスケジュール済ジョブ・ベースのパージとコマンド行アーカイブ・ユーティリティのパージは、どちらもエンティティの同じ表のセットからデータをパージします。
スケジュール済ジョブの実行中にデータベースが再起動された場合、ジョブは実行中ステータスのままスタックします。スケジューラ・サービスを再起動して、実行中ステータスのままスタックしているすべてのジョブを停止する必要があります。
スケジュール済ジョブの停止方法の詳細は、「スケジューラの起動と停止」を参照してください。
編成データパージは、アクティブな編成表から統合されたOIMデータ・パージ・ジョブ・スケジュール済ジョブのインタフェースを使用して実施します。
編成データ・パージは次の基準に基づきます。
注意:
編成パージは、オンライン・モードでのみスケジュール済ジョブのインタフェースから利用できます。
編成プロセスのステータス(完了済、失敗、補正済、取消済、補正による取消済など)。
時間ベースの基準。この基準は、スケジュール済ジョブのインタフェースから日数で指定した保存期間の値で指定されます。
編成パージ機能によるパージの対象になるアクティブな編成表は、次のとおりです。
ORCHPROCESS
CALLBACK_INVOCATION_RESULT
アーカイブおよびパージ操作に関連する様々なメトリックや診断データを取得して対話することができます。
自動化されたスケジュール済タスクによるリアルタイム・パージおよびアーカイブ操作は、事前に定義した周期で暗黙的に非対話型で実行されます。ただし、パージ操作に関連するさまざまなメトリックを取得して対話することは可能です。
ピックされたエンティティ・モジュールの名前
成功/失敗ステータス
実行中に遭遇した例外
削除用にターゲットされた行の数
実際にパージされた行の数
最低でも、これらのメトリックが実行ごとにログに記録されます。直近500回分の実行データは常にアクセス可能です。
次の診断ロギング表は、リアルタイム・パージおよびアーカイブ操作の一部であり、エンティティ・パージ実行の診断情報を格納します。
OIM_DATAPURGE_TASK_LOG: エンティティ・データ削除のためのスケジュール済タスクによって制御されたパージ実行に関連する重要な情報を格納します。
表23-3は、OIM_DATAPURGE_TASK_LOG表示に含まれる列の一覧です。
表23-3 OIM_DATAPURGE_TASK_LOG表の列
列 | 説明 |
---|---|
OIM_DATAPRGTASK_KEY |
タスクを一意に識別するためのキーを格納します |
OIM_DATAPRG_ID |
一意のパージ名を格納します |
SCH_JOB_ID |
スケジューラによって割り当てられたスケジュール済タスクのジョブIDを格納します |
EXECUTION_MODE |
パージの実行モード(スケジュール済タスク・モードはSCH) |
PURGERUN_START_TIME |
パージ実行全体の開始時間を格納します |
PURGERUN_END_TIME |
パージ実行全体の終了時間を格納します |
PURGERUN_STATUS |
パージ実行の全体的なステータスを格納します(実行中は次のいずれかのステータスになります):
|
PURGE_RUN_NOTE |
パージ実行時のタスクレベル例外の詳細を格納します |
OIM_DATAPRG_TASKS_LOGDTLS: スケジュール済タスクによって制御された、モジュールまたはエンティティレベルのパージ実行に関連する重要な情報を格納します。
表23-4は、OIM_DATAPRG_TASKS_LOGDTLS表示に含まれる列の一覧です。
表23-4 OIM_DATAPRG_TASKS_LOGDTLS表の列
列 | 説明 |
---|---|
OIM_DATPRGLOGDET_KEY |
タスク内のモジュールを一意に識別するためのキーを格納します |
OIM_DATAPRGTASK_KEY |
OIM_ENTITYPURGE_TASK_LOG表の論理外部キーを格納します |
MOD_NAME |
次に示すようなモジュール名を格納します
|
EST_ALLOCT_TIME |
モジュール・パージ実行に割り当てられた時間を格納します |
MOD_STATUS |
モジュールのステータスを格納します(実行中は次のいずれかのステータスになります):
|
MODPURGERUN_START_TIME |
モジュール・パージ実行の開始時間を格納します |
MODPURGERUN_END_TIME |
モジュール・パージ実行の終了時間を格納します |
EST_PURGE_ROW_CNT |
モジュール・パージ実行のドライビング表のターゲット行数を格納します |
ACTUAL_PURGE_ROW_CNT |
パージ実行時に実際に削除されたドライビング表の行数を格納します |
MOD_PURGE_RUN_NOTE |
モジュール・レベルで遭遇したその他の例外や情報を格納します |
OIM_DATAPRG_FAILED_KEYS: スケジュール済パージの実行時に失敗した各モジュールまたはエンティティのエンティティ・キーを格納します。
表23-5は、OIM_DATAPRG_FAILED_KEYS表示に含まれる列の一覧です。
表23-5 OIM_DATAPRG_FAILED_KEYS表の列
列 | 説明 |
---|---|
OIM_DATAPRGFAILED_KEY |
失敗したタスクを一意に識別するためのキーを格納します |
OIM_DATAPRGTASK_KEY |
OIM_ENTITYPURGE_TASK_LOG表の論理外部キーを格納します |
MOD_NAME |
パージ実行が失敗するモジュール名を格納します |
MOD_ENTITY_KEY |
各モジュールのドライビング表キーを格納します |
ERROR_NOTE |
例外スタック・トレースを格納します |
OIM_DATAPURGE_TASK_LOG表とOIM_DATAPRG_TASKS_LOGDTLS表には、直近500回分のパージ実行のデータが格納されます。OIM_DATAPRG_FAILED_KEYS表には、最後の実行についてのみ、失敗したキー・データが格納されます。
注意:
OIMデータ・パージ・スケジュール済タスクの実行時のPL/SQLレイヤーでの問題のトラブルシューティングの詳細は、「PL/SQL統合診断ログおよびデバッグ・フレームワークの使用」を参照してください。アーカイブ・パージ・ユーティリティのコマンドライン・オプションには、リコンシリエーション・アーカイブ・ユーティリティ、タスク・アーカイブ・ユーティリティおよびリクエスト・アーカイブ・ユーティリティがあります。
この項では、コマンド行アーカイブ・パージ・ユーティリティの使用方法について説明します。次の項目が含まれます。
注意:
リコンシリエーション・アーカイブ・ユーティリティ、タスク・アーカイブ・ユーティリティおよびリクエスト・アーカイブ・ユーティリティをオフライン・モードとオンライン・モードの両方で使用できます。
Oracle Identity Managerは、3つのエンティティ(リコンシリエーション、プロビジョニング・タスクおよびリクエスト)に対して、コマンド行ユーティリティ・オプションによるエンティティ・データのアーカイブおよびパージを提供しています。
すべてのコマンド行ユーティリティは、Oracle Identity Managerのインストールに含まれており、エンティティ・データをアーカイブおよびパージするためのユーザー指定のパラメータを対話的に取得します。これらのユーティリティは、LinuxとMicrosoft Windowsの両方のオペレーティング・システム環境で使用できます。
リコンシリエーション・アーカイブ・ユーティリティを使用すると、Oracle Identity Managerとリコンサイルされたデータをアーカイブできます。これには、前提条件の準備、リコンシリエーション・データのアーカイブ条件の理解、ユーティリティの実行、生成されるログの理解、および問題のトラブルシューティングが含まれます。
この項では、リコンシリエーション・アーカイブ・ユーティリティの使用方法について説明します。次の項目が含まれます。
Oracle Identity Managerは、ターゲット・システムのリコンシリエーション・データを、アクティブ・リコンシリエーション表と呼ばれるOracle Identity Manager表に格納します。
リコンシリエーション・プロセス中、リコンシリエーション・マネージャはアクティブ・リコンシリエーション表のデータをOracle Identity Managerのコア表とリコンサイルします。リコンシリエーション・マネージャはリコンサイルされたデータをアクティブ・リコンシリエーション表から削除しないため、これらの表は最終的に非常に大きくなり、リコンシリエーション・プロセス中のパフォーマンスが低下することがあります。リコンシリエーション・アーカイブ・ユーティリティを使用すると、Oracle Identity Managerとリコンサイルされたデータをアーカイブできます。リコンシリエーション・アーカイブ・ユーティリティは、アーカイブされたデータを、アクティブ・リコンシリエーション表と同じ構造のアーカイブ・リコンシリエーション表に格納します。
表23-6に、アクティブ・リコンシリエーション表と、それに対応するアーカイブ・リコンシリエーション表(アクティブ・リコンシリエーション表のデータがアーカイブされる表)を示します。
表23-6 アクティブ・リコンシリエーション表とアーカイブ・リコンシリエーション表
アクティブ・リコンシリエーション表(Oracle Identity Manager表) | アーカイブ・リコンシリエーション表 |
---|---|
RECON_EVENTS |
ARCH_RECON_EVENTS |
RECON_JOBS |
ARCH_RECON_JOBS |
RECON_BATCHES |
ARCH_RECON_BATCHES |
RECON_EVENT_ASSIGNMENT |
ARCH_RECON_EVENT_ASSIGNMENT |
RECON_HISTORY |
ARCH_RECON_HISTORY |
RECON_USER_MATCH |
ARCH_RECON_USER_MATCH |
RECON_ACCOUNT_MATCH |
ARCH_RECON_ACCOUNT_MATCH |
RECON_CHILD_MATCH |
ARCH_RECON_CHILD_MATCH |
RECON_ORG_MATCH |
ARCH_RECON_ORG_MATCH |
RECON_ROLE_MATCH |
ARCH_RECON_ROLE_MATCH |
RECON_ROLE_HIERARCHY_MATCH |
ARCH_RECON_ROLE_HIER_MATCH |
RECON_ROLE_MEMBER_MATCH |
ARCH_RECON_ROLE_MEMBER_MATCH |
RA_LDAPUSER |
ARCH_RA_LDAPUSER |
RA_MLS_LDAPUSER |
ARCH_RA_MLS_LDAPUSER |
RA_LDAPROLE |
ARCH_RA_LDAPROLE |
RA_MLS_LDAPROLE |
ARCH_RA_MLS_LDAPROLE |
RA_LDAPROLEMEMBERSHIP |
ARCH_RA_LDAPROLEMEMBERSHIP |
RA_LDAPROLEHIERARCHY |
ARCH_RA_LDAPROLEHIERARCHY |
RECON_TABLESの下で説明されているすべての水平表 |
「ARCH_」に水平表(RA_*の表)の先頭25文字を追加 |
注意:
RECON_EXCEPTION表のデータはアーカイブまたはパージされません。これは、Oracle Identity Managerに事前に定義されたBIPレポートの依存性が原因です。
リコンシリエーション・アーカイブ・ユーティリティは、次のタスクを実行します。
アクティブ・リコンシリエーション表のすべてのデータまたは特定のデータをアーカイブ・リコンシリエーション表にアーカイブする
アクティブ・リコンシリエーション表のすべてのデータを削除する
リコンシリエーション・アーカイブ・ユーティリティは、ユーザー入力ごとに次の2要素の基準に基づいて、アクティブ・リコンシリエーション表からアーカイブ・リコンシリエーション表にデータを移動することで、データをアーカイブします。
日付ベースの基準。これは、リコンシリエーション・イベントの作成日です。YYYYMMDDの書式で指定する必要があります。この日付以前のレコードがアーカイブされます。
機能リコンシリエーション・イベントの状態ベース基準。これは、リコンシリエーション・イベントのステータスです。ユーティリティの実行時に示されるステータス・オプションから選択する必要があります。
アーカイブ基準の詳細は、「リコンシリエーション・データのアーカイブ基準」を参照してください。
選択したデータをアーカイブする場合は、指定した日付とイベント・ステータス以前に作成された選択したイベント・ステータスに基づいて、リコンシリエーション・データがユーティリティによってアーカイブされます。
アクティブ・リコンシリエーション表のすべてのデータをアーカイブ・リコンシリエーション表にアーカイブする場合、リコンシリエーション・アーカイブ・ユーティリティによって、指定した日付以前に作成されたリコンシリエーション・データがすべてアーカイブされます。
Oracle Database版のリコンシリエーション・アーカイブ・ユーティリティを構成するファイルは、次のディレクトリにあります。
OIM_HOME/server/db/oim/oracle/Utilities/Recon11gArchival
リコンシリエーション・アーカイブ・ユーティリティは、Oracle Identity Managerを停止してオフライン・モードで実行することも、Oracle Identity Managerを実行してオンライン・モードで実行することもできます。
ユーティリティをオフライン・モードで実行する前に、Oracle Identity Managerを停止する必要があります。
リコンシリエーション・アーカイブ・ユーティリティを実行する前に、データベースにOIM_RECON_ARCH表領域を作成する必要があります。そのためには、SYSやSYSTEMなどのDBA特権ユーザーとして次のサンプル・コマンドを実行できます。
CREATE TABLESPACE OIM_RECON_ARCH
LOGGING DATAFILE 'ORADATA/OIM_RECON_ARCH.dbf'
SIZE 500M REUSE AUTOEXTEND ON NEXT 10M;
注意:
前述のサンプル・コマンドでORADATAをORADATAディレクトリへのフルパスに置換する必要があります。
Oracle Identity Managerユーティリティを実行する環境で、LD_LIBRARY_PATHをSQL*PlusなどのOracleユーティリティを開始するように設定する必要があります。
アクティブ・リコンシリエーション表からアーカイブ・リコンシリエーション表にアーカイブされたデータは、Oracle Identity Managerから使用できなくなります。このデータにアクセスするには、Oracle Identity Managerデータベースのアーカイブ・リコンシリエーション表を問い合せる必要があります。
ASM、Exadata (ASM)またはOracle Managed Files (OMF)を使用する場合、ここに記載されている指示に従ってください。
ASMを使用する場合、DATA 1
などのディスクグループ名を使用して、次のように表領域をデータベースで作成できます。
CREATE TABLESPACE OIM_RECON_ARCH LOGGING DATAFILE '+DATA1' SIZE 500M AUTOEXTEND ON NEXT 10M;
Oracle Managed Filesを使用する場合、データファイルを省略して、コマンドを次のように実行できます。
CREATE TABLESPACE OIM_RECON_ARCH LOGGING DATAFILE SIZE 500M AUTOEXTEND ON NEXT 10M;
ユーティリティをオフライン・モードで実行する場合は、ユーティリティを実行する前にOracle Identity Managerを停止する必要があります。
アーカイブするリコンシリエーション・データの選択には、次の基準が設けられています。一致する値があり、RECON_EXCEPTION表内で参照されていないデータは、アーカイブおよびパージされます。
日付はYYYYMMDDの形式にする必要があります。指定されたリコンシリエーション・イベント・パラメータ値と一致する、この日付以前のすべてのレコードがアーカイブされます。
クローズは、リコンシリエーション・マネージャで手動でクローズされたイベント、つまり、ステータスが「イベントがクローズされました」であるリコンシリエーション・イベントを表します。
リンク済は、Oracle Identity Managerでリコンサイルされたイベントで、「作成に成功しました」、「更新に成功しました」および「削除に成功しました」の状態が含まれます。
クローズ済またはリンク済。
アーカイブされるリコンシリエーション・イベントのステータスを選択します。ステータスに応じてクローズ済は1、リンク済は2、クローズ済とリンク済は3、終了は4を入力します。
リコンシリエーション・アーカイブ・ユーティリティの実行後に次のエラーが発生した場合:
「ORA-01034 ORACLEは使用できません。」または「ORA-27101: 共有メモリー・レルムは存在しません」
ターゲット・インスタンスが起動されて実行しているかどうかを調べ、実行していない場合は、DBAに連絡してインスタンスを起動します。SQLPLUSコマンドを使用してOIM DBユーザー資格証明を使用してターゲット・インスタンスにアクセスできることを確認します。
リコンシリエーション・アーカイブ・ユーティリティの実行中、次のエラーが発生したら、
ORA-01034: ORACLE not available, ORA-27101: shared memory realm does not exist
ターゲット・インスタンスが稼働しているかどうかを確認します。稼働していない場合は、データベース管理者に連絡し、インスタンスを起動します。SQLPLUS
コマンドを使用してOracle Identity Managerデータベース・ユーザー資格証明を使用してターゲット・インスタンスにアクセスできることを確認します。
タスク・アーカイブ・ユーティリティを使用してタスク・データをアーカイブし、それをアクティブ・タスク表から削除できます。これには、データベースの準備、ユーティリティの実行および生成される出力ファイルの確認が含まれます。
この項では、タスク・アーカイブ・ユーティリティの使用方法について説明します。次の項目が含まれます。
Oracle Identity Managerでは、タスクはリソースのプロビジョニングを処理するプロセスを構成する1つ以上のアクティビティを意味します。たとえば、リソースへのアクセスを要求するプロセスには、複数のプロビジョニング・タスクが含まれます。Oracle Identity Managerは、アクティブ・タスク表にタスク・データを格納します。
Oracle Identity Managerのデフォルトでは、完了したタスクはアクティブ・タスク表から削除されません。アクティブ・タスク表のサイズが増加するにつれて、特にプロビジョニング・タスクの管理時に、パフォーマンスが低下する可能性があります。タスクが正常に実行されたら、タスク・アーカイブ・ユーティリティを使用してタスク・データをアーカイブし、それをアクティブ・タスク表から削除できます。タスク・アーカイブ・ユーティリティでタスク・データをアーカイブすると、パフォーマンスが改善され、データを安全に格納できます。
タスク・アーカイブ・ユーティリティは、アーカイブしたタスク・データをアーカイブ・タスク表に格納します。これらの表の構造は、アクティブ・タスク表と同じです。
表23-7に、アクティブ・タスク表と、それに対応するアーカイブ・タスク表(アクティブ・タスク表のデータがアーカイブされる表)を示します。
表23-7 アクティブ・タスク表とアーカイブ・タスク表
アクティブ・タスク表 | アーカイブ・タスク表 |
---|---|
OSI |
ARCH_OSI |
OSH |
ARCH_OSH |
SCH |
ARCH_SCH |
タスク・アーカイブ・ユーティリティを使用して、次のタイプのタスクをアーカイブできます。
完了済のプロビジョニング・タスク
完了済および取消済のプロビジョニング・タスク
タスク・アーカイブ・ユーティリティは、アクティブ・タスク表からアーカイブ・タスク表にタスクを移動することで、プロビジョニング・タスクをアーカイブします。これは、ユーザー入力ごとに指定される、次の2要素の基準に基づきます。
日付ベースの基準。これは、プロビジョニング・タスクの作成日です。YYYYMMDDの書式で指定する必要があります。この日付以前のレコードがアーカイブされます。
機能基準のタスク・ステータス。これは、プロビジョニング・タスクのステータスです(たとえば、完了済ステータスや完了済および取消済ステータスのプロビジョニング・タスク)。ユーティリティの実行時に示されるステータス・オプションから選択する必要があります。
アーカイブ操作はアーカイブするタスク・データのタイプを示し、ユーザー・ステータスは削除、無効化またはその両方を行ったユーザーに関するデータをアーカイブするかどうかを決定します。タスク実行日はタスクを実行する日を示し、YYYYMMDD書式である必要があります。
指定したタスク実行日まで、実行されるすべてのタスクがアーカイブされます。アーカイブ・プロセスにかかる時間を短縮するために、アーカイブされるレコード数が200000を超えると、ユーティリティによりすべてのアクティブ・タスク表の索引が削除されます。アーカイブ・データがアクティブ・タスク表から削除された後に、索引は再作成されます。200000という値は必要な値に変更できます。OIM_TasksArch.batファイルまたはOIM_TasksArch.shファイルのコードの次の行で値を変更できます。
.batファイルの場合、set INDXRESP=200000
.shファイルの場合、indxopt=200000
Oracle Database版のタスク・アーカイブ・ユーティリティを構成するファイルは、次のディレクトリにあります。
OIM_HOME/server/db/oim/oracle/Utilities/TaskArchival
注意:
アクティブ・タスク表からアーカイブ・タスク表にアーカイブされたデータは、Oracle Identity Managerから使用できなくなります。このデータにアクセスするには、Oracle Identity Managerデータベースのアーカイブ・タスク表を問い合せる必要があります。
タスク・アーカイブ・ユーティリティは、Oracle Identity Managerを停止してオフライン・モードで実行することも、Oracle Identity Managerを実行してオンライン・モードで実行することもできます。
ユーティリティをオフライン・モードで実行する前に、Oracle Identity Managerを停止する必要があります。
タスク・アーカイブ・ユーティリティをOracle Databaseとともに使用するには、次の手順を実行する必要があります。
注意:
Oracle Identity Managerユーティリティを実行する環境で、LD_LIBRARY_PATHをSQL*PlusなどのOracleユーティリティを開始するように設定する必要があります。
表23-8に、タスク・アーカイブ・ユーティリティによって生成される出力ファイルを示します。
表23-8 タスク・アーカイブ・ユーティリティによって生成される出力ファイル
ファイル | 説明 |
---|---|
|
ユーティリティが指定された資格証明を使用してデータベースに接続できなかった場合に生成されます。 |
|
アーカイブ・プロセスまたは削除プロセスが失敗した場合に生成されます。 |
|
アーカイブ・プロセスまたは削除プロセスが成功した場合に生成されます。 |
注意:
ユーティリティを再度実行するときに、これらのエラー・ログ・ファイルは削除されます。
リクエスト・アーカイブ・ユーティリティを使用して、クローズされたリクエストまたは取り下げられたリクエストをアーカイブします。これには、前提条件の準備、入力パラメータの理解、ユーティリティの実行、および生成されるログの理解が含まれます。
この項では、リクエスト・アーカイブ・ユーティリティの使用方法について説明します。次の項目が含まれます。
デフォルトで、Oracle Identity Managerはクローズまたは取り消されたリクエストをアクティブ・リクエスト表から削除しません。これらのリクエストをアーカイブしてディスク領域を解放し、データベースのパフォーマンスを向上させるには、リクエスト・アーカイブ・ユーティリティを使用します。リクエスト・データは、リクエスト作成日とリクエスト・ステータスに基づいてアーカイブできます。リクエスト・ステータスに基づいてリクエストをアーカイブするかどうかは任意です。リクエスト・ステータスを使用すると、次の内容をアーカイブできます。
リクエスト・ステータスが「取消し済」、「クローズ済」または「完了」である完了したリクエスト。これは、オプション完了の場合は1を選択して指定されます。
リクエスト・ステータスが「失敗」および「部分的に失敗」である失敗したリクエスト。これは、オプション「失敗の場合は2」を選択して指定されます。
リクエスト・ステータスが「取下げ済」、「クローズ済」、「完了」または「失敗」、「部分的に失敗」である完了または失敗したリクエスト。これは、オプション「完了および失敗の場合は3」を選択して指定されます。
表23-9に、アーカイブされる表の名前と、対応するアーカイブ表の名前を示します。
表23-9 アーカイブ表
メイン表 | アーカイブ表 |
---|---|
REQUEST |
ARCH_REQUEST |
REQUEST_HISTORY |
ARCH_REQUEST_HISTORY |
REQUEST_APPROVALS |
ARCH_REQUEST_APPROVALS |
REQUEST_ENTITIES |
ARCH_REQUEST_ENTITIES |
REQUEST_ENTITY_DATA |
ARCH_REQUEST_ENTITY_DATA |
REQUEST_BENEFICIARY |
ARCH_REQUEST_BENEFICIARY |
REQUEST_BENEFICIARY_ENTITIES |
ARCH_REQUEST_BE |
REQUEST_BENEFICIARY_ENTITYDATA |
ARCH_REQUEST_BED |
REQUEST_TEMPLATE_ATTRIBUTES |
ARCH_REQUEST_TA |
WF_INSTANCE |
ARCH_WF_INSTANCE |
REQUEST_COMMENTS |
ARCH_REQUEST_COMMENTS |
Oracle Database版のリクエスト・アーカイブ・ユーティリティを構成するファイルは、次のディレクトリにあります。
OIM_HOME/server/db/oim/oracle/Utilities/RequestArchival
リクエスト・アーカイブ・ユーティリティは、Oracle Identity Managerを停止してオフライン・モードで実行することも、Oracle Identity Managerを実行してオンライン・モードで実行することもできます。
ユーティリティをオフライン・モードで実行する前に、Oracle Identity Managerを停止する必要があります。
ユーティリティをオフライン・モードで実行する場合は、ユーティリティを実行する前にOracle Identity Managerを停止する必要があります。
注意:
Oracle Identity Managerユーティリティを実行する環境で、LD_LIBRARY_PATHをSQL*PlusなどのOracleユーティリティを開始するように設定する必要があります。
表23-10に、リクエスト・アーカイブ・ユーティリティによって使用される入力パラメータのリストを示します。
表23-10 入力パラメータ
パラメータ | 説明 |
---|---|
Oracleホーム |
システムのORACLE_HOME環境変数の値。 |
Oracle SID |
Oracle Identity ManagerデータベースのSID (TNSの名前かTNS別名)。 |
OIM DBユーザー |
Oracle Identity Managerデータベース・ユーザーのデータベース・ログインIDです。 |
OIM DBパスワード |
Oracle Identity Managerデータベース・ユーザーのパスワード。 |
リクエスト・ステータス |
ユーザー入力値1、2または3に基づいたリクエスト・ステータス。 |
リクエスト作成日 |
ユーティリティは、このリクエスト基準日またはそれ以前に作成された、必要なリクエスト・ステータスのすべてのリクエストをアーカイブします。 |
バッチ・サイズ |
ユーティリティは、レコードのグループまたはバッチを単一トランザクションとして処理します。バッチ・サイズは、ユーティリティのパフォーマンスに影響する可能性があります。 「バッチ・サイズ」のデフォルト値は |
ユーティリティ実行モード |
ユーティリティを実行するモード(オンラインまたはオフライン)。オンライン・モードの場合は1を、オフライン・モードの場合は2を入力する必要があります。 ユーティリティは、オンライン・モードよりもオフライン・モードのほうが高速で実行されます。ただし、ユーティリティをオフライン・モードで実行するには、ダウンタイムが必要です。オフライン・モードで実行することによってアーカイブ操作を高速化できますが、ユーティリティがアーカイブ操作を完了するまでOracle Identity Managerを使用できません。このため、このオプションを選択する前に、Oracle Identity Managerが実行されていないことを確認してください。 |
すべてのログは、現在のフォルダに作成されているlogs/ディレクトリに書き込まれます。表23-11にユーティリティにより生成されるログ・ファイルのリストを示します。
表23-11 DBアーカイブ・ユーティリティにより生成されるログ
ログ・ファイル | 説明 |
---|---|
validate_date.log |
入力値REQUEST_CREATION_DATEが無効な場合に作成されます。 |
oim_request_archival_summary_TIMESTAMP.log |
実行のサマリーが含まれます。 |
Err_DB_Conn_TIMESTAMP_ATTEMPTNUMBER.log |
ユーティリティが提供される資格証明を使用してデータベースに接続できない場合に作成されます。 |
監査データの増加を制御する手段は、軽量監査フレームワークにも従来の監査フレームワークにも用意されています。
ここでは、軽量監査フレームワークおよびレガシー監査フレームワークでデータ増加を管理するために使用できるツールおよび方法について説明します。
監査アーカイブおよびパージ・ユーティリティは、論理的かつ一貫した方法でデータをパージすることにより、監査データの増加を制御します。
Oracle Identity Managerデータベースで一連の業務を処理すると、監査データが増加し、データベース・サーバーの記憶域使用量も徐々に増加します。プロビジョニング機能に関連するOracle Identity Managerの監査データは、UPAと呼ばれるレガシー監査表に保存され、その他のデータは、軽量監査フレームワークを使用して監査され、AUDIT_EVENT表に保存されます。
ディスク領域の消費量を制御するために、監査アーカイブおよびパージ・ユーティリティを使用できます。このユーティリティは、論理的かつ一貫した方法でデータをパージすることにより、監査データの増加を制御します。
監査データの増加を制御するには、AUDIT_EVENTS表をパーティション化し、AUDIT_EVENTS表をアーカイブまたはパージし、進行中のパーティションのメンテナンスを行います。
ここでは、パーティション・ベースのアプローチを使用して軽量監査フレームワークの監査データの増加を管理する方法について説明します。次の項目が含まれます。
軽量監査フレーム(つまり、AUDIT_EVENT表)の監査データの増加を管理するには、使用可能な2つのソリューションがあります。
スケジュールされたジョブ、Remove Audit Log Events
の実行。
このスケジュールされたジョブを実行すると、古い監査ログ・イベントの削除(日数)フィールドに設定された保存期間よりも古いすべての監査レコードのパージが自動的に開始されます。デフォルトは180日間です。このスケジュールされたジョブはデフォルトで有効になっており、パージ・オプションのみを持ちます。
スケジュールされたジョブの詳細は、「スケジュール済タスク」を参照してください。
AUDIT_EVENT表のパーティション化。
ヒント:
これはドキュメントされたアプローチであり、監査データ・コンプライアンスまたはライフサイクル管理の要件に基づいてこのソリューションを使用する必要があります。このソリューションは、スケジュールされたジョブのパージを補完します。
このソリューションにより、次のことを達成できます。
データのアーカイブ(スケジュール・ジョブでは監査データのパージのみが可能)。
要件に基づいてディスク・サイズを管理する柔軟性。たとえば、データを長期間保存する必要がある場合、または高い監査成長が予想される場合など。
図23-1は、デプロイメントでの監査データの増加を管理する適切なオプションの選択に役立ちます。
パーティション・ベースのアプローチをスケジュールされたジョブと組み合せて使用すると、デプロイメントに適した次のソリューションを実現できます。
監査データを長期間(数年)、アーカイブまたは保持する必要がある場合:
パーティション・ベースのアプローチを実装して監査データの増加を管理します。これにより、データのアーカイブまたはデータ増加の管理(あるいはその両方)が可能になります。
後で保存期間が間近に迫ってきたとき、スケジュール・ジョブが視野に入ります。
監査データを短期間(数か月)保持する必要がある場合は、スケジュール・ジョブによってデータの増加を管理できます。監査データを短期間(数か月)保持する必要があるが、業務処理が多いために監査データの増加率が高い場合:
パーティション・ベースのアプローチを実装して監査データの増加を管理します。
スケジュール・ジョブを実行してデータをパージします。
パーティション・ベースのアプローチを使用する場合、またはその前に、次の前提条件が満たされている必要があります。
Oracleデータベースのパーティション機能を使用するには、データベース・パーティショニングのためのライセンスが必要です。
このソリューションを本番データベースに実装する前に、開発またはステージング環境で試用することをお薦めします。
AUDIT_EVENT表の最新のバックアップが使用可能であることを確認します。AUDIT_EVENT表のバックアップの作成は、このソリューションを適用するための必須の前提条件です。
Oracleデータベースのリリースが11gである場合は、時間隔パーティションの使用をお薦めします。11gより前のOracleデータベースの場合は、レンジ・パーティションを使用します。パーティション化は、EVENT_DATE列を使用して月ベースで実行する必要があります。
このソリューションを実装する前に、何か月分の監査データをオンラインにしておく必要があるかを決定します。たとえば、監査データの保存期間が6か月である場合は、月パーティション・ベースでAUDIT_EVENT表を6か月でパーティション化する必要があります。
Oracle Identity Managerが実行中でなく、オフライン・ユーティリティで使用できないことを確認してください。現在の月のパーティションの作成に成功した後にOracle Identity Managerを起動し、Oracle Identity Managerの実行中に残りの監査データをパーティション化できます。
アーカイブおよびパージ・ソリューションのためのAUDIT_EVENT表を準備するには、次の手順を実行します。
AUDIT_EVENTS表に対する問合せを実行して、監査データの最小および最大の暦月を取得します。
最小および最大の月を取得するには次の問合せが役立ちます。最大の月は現在の暦月である必要があります。
SELECT MIN (event_date) min_month, MAX (event_date) running_month FROM AUDIT_EVENT
前の手順に基づいて、表23-12に示されている3つの可能なシナリオと時相をパーティショニングのために考慮できます。
表23-12 パーティショニングが考慮される可能性があるシナリオ
シナリオ | 時相 |
---|---|
シナリオ1 |
最小値と暦月が同一である場合は、現在の月のパーティションを作成できます。時間間隔パーティションを使用する場合、残りの月のパーティションは、将来作成されます。レンジ・パーティションを使用する場合は、将来のパーティションを手動で作成する必要があります。 |
シナリオ2 |
最小値と暦月が保存期間(6か月など)の範囲内にある場合。たとえば、最小月がOCT-2015で暦月がDEC-2015である場合。この場合は、OCT-2015からDEC-2015までのパーティションを作成します。将来のパーティションは自動的に作成されます。 |
シナリオ3 |
最小値と暦月が保存期間の範囲外(6か月を超えるなど)である場合。たとえば、最小月がMAY-2015で暦月がDEC-2015である場合。この場合は、JUL-2015からDEC-2015までのパーティションを作成します。選択した期間の範囲外にある月(5月、6月)のデータをどうするか決定する必要があります。 |
AUDIT_EVENT表のパーティションの手順またはコマンドは、Oracle RDBMSのパーティションのドキュメントを参照してください。
監査データのアーカイブまたはパージは、パーティションの移動または削除によって実行できます。Oracle Identify Managerは、現在の月以外のパーティションを使用しません。現在の月のパーティションは、移動または削除できません。アーカイブまたはパージするパーティションは、監査データのコンプライアンスまたはライフ・サイクルの要件に依存します。
たとえば、コンプライアンスのために監査データを1年間保存する必要がある場合は、次の手順を実行します。
Remove Audit Log Events
の監査の保存期間をデフォルトの6か月(180日)から1年に変更します。Remove Audit Log Events
に設定された保存期間から外れたとき、スケジュールされたジョブRemove Audit Log Events
によってそのデータがパージされます。AUDIT_EVENTS表のパーティションでは、進行中に次のメンテナンス・アクティビティが必要です。
スケジュールされたジョブRemove Audit Log Events
は、保存期間が過ぎた監査データが含まれているパーティションからデータをパージします。これにより、AUDIT_EVENT表に空のパーティションが作成されます。これらの空のパーティションを定期的にチェックし、それらを削除することをお薦めします。
次のようなSQLを使用して、メンテナンス・ウィンドウでこれらの空のパーティションを削除します。
Alter table AUDIT_EVENT drop partition PARTITION_NAME UPDATE GLOBAL INDEXES;
監査アーカイブおよびパージ・ユーティリティを使用して、レガシー監査データの増加を管理するには、ユーティリティを実行するための前提条件に対応し、アーカイブとパージのためのUPA表を準備し、UPA表のアーカイブとパージを実行します。
この項の内容は次のとおりです。
注意:
Oracle Database Enterprise Editionのパーティション化機能は、監査アーカイブおよびパージの実装に必要です。
レガシー監査エンジン、つまり、UPA表での増加を管理するには、監査アーカイブおよびパージ・ユーティリティを使用できます。このユーティリティは、論理的かつ一貫した方法でデータをパージすることにより、監査データの増加を制御します。
注意:
監査アーカイブおよびパージ・ソリューションは、UPA表にのみ適用できます。UPA_ prefixを含む表である監査レポート表には適用できません。
このユーティリティは、Oracle Identity Managerリリース9.1.0以降と互換性があります。
Oracle Identity Managerを停止して最新データをフェッチする必要があります。これは、NULLレコードとしてEFF_TO_DATEを取得するためです。新規にパーティション化されたUPAでOracle Identity Managerを実行する際、残りのレコードを後で取得できます。
パーティションをアーカイブまたは削除できる、暦年に基づいたUPA表のパーティション化をお薦めします。パーティション化の利点は、Oracle Identity Managerでは古いパーティションにある古い監査データが使用されないため、古いパーティションをアーカイブまたはパージできることです。Oracle Identity Managerでは、最新の監査データおよび現在の暦年データが使用されます。したがって、UPA表は、EFF_TO_DATE列を使用して、日付範囲に基づいたパーティション化方法で暦年ごとにパーティション化されます。パーティション化後、EFF_TO_DATEがNULLである最新の監査データが1つのパーティションにグループ化され、暦年ごとに1つのパーティションが作成されます。Oracle Identity Managerは、現在の最新年のパーティション以外のパーティションに対する読取りや書込みは行いません。
たとえば、2005年からOracle Identity Managerの監査機能を使用していて、暦年2011年に監査アーカイブおよびパージ・ソリューションを実装する場合、暦年ごとにパーティションを作成すると仮定すると、これを実施した後に7つのパーティションが作成されることになります。これらの7つのパーティションで、Oracle Identity Managerは次のパーティションに対してのみ読取りまたは書込みを行います。
最新のパーティション
現在の年のパーティション(たとえば、2011年)
それ以前の年のパーティションはすべてアーカイブ後にパージされます。アーカイブしない場合は、それらの古いパーティションをパージできます。古いパーティションをアーカイブおよびパージすることにより、領域を再利用することができます。現在の最新年のパーティションは、Oracle Identity Managerが引き続き使用するためそのままにしておく必要があります。
監査アーカイブおよびパージ・ユーティリティを使用するには、次の前提条件を満たす必要があります。
データベースのパーティション化はOracle DatabaseのEnterprise Editionでのみサポートされています。したがって、監査アーカイブおよびパージ・ソリューションを実装するには、Oracle DatabaseのEnterprise Editionを実行する必要があります。
UPA表はレンジ・パーティション化する必要があります。間隔はデータ分散単位の値にできます。パーティション方法のそれ以外のモードはサポートされていません。
UPA表の最新のバックアップが使用可能であることを確認します。UPA表のバックアップの作成は、このソリューションを適用するための必須の前提条件です。このソリューションを本番データベースに実装する前に、開発またはステージング環境で試用することをお薦めします。
このソリューションを実装する前に、過去何年分の監査データをオンラインにしておく必要があるかを決定します。これは、事前にパーティションを作成する場合に役立ちます。
各パーティションは独自の表領域に置く必要があります。異なる年のパーティションや他のデータ間で表領域を共有しないでください。
パーティション化中、各暦年の監査データは最終的な宛先に移動される前に表にコピーされます。コピーされたデータを保持するディスク領域をプロビジョニングしておく必要があります。
アーカイブおよびパージ・ソリューションのためのUPA表を準備するには、次の手順を実行します。
UPA表がパーティション化されるまで、Oracle Identity Managerデータベースに対するトランザクションが存在しないようにします。
UPA表に対する問合せを実行して、監査データの最小および最大の暦年を取得します。最小および最大の年を取得するには次の問合せが役立ちます。最大の年は現在の暦年である必要があります。
SELECT EXTRACT (YEAR FROM MIN (eff_to_date)) min_year,EXTRACT (YEAR FROM MAX (eff_to_date)) running_year FROM upa;
これは、最小の年から始まる各暦年のパーティションを決定する際に役立ちます。
Oracle Identity Managerが実行されておらず、オフライン・ユーティリティで使用できないことを確認します。
新規パーティション表を作成します。
2005年を最小の年、2011年を実行または現在の暦年とした場合、新規パーティション表を作成する前に次のことを決定しておく必要があります。
何年分の古い監査データを保持しますか。3年分の監査データのみを保持することが重要な場合は、2008年からの新規にパーティション化された表を作成する必要があります。2008年より古いデータは、元のUPA表が削除されるときにクリーンアップされます。
何年分の古いデータを保持するかを決定した後、古いデータをどのようにしてどこに保持しますか。古いデータ・パーティションをすべてアーカイブUPA表に保持しますか、または古いパーティションのバックアップを作成し、古いパーティションを削除しますか。古いパーティションをテープに移し、UPA表からパージすることをお薦めします。前述のように、最新の実行中の暦年パーティションはそのままにしておく必要があります。
次のサンプルは、3年分の監査データをUPA表に保持し、現在の暦年は2011であることを想定しています。
SQL> SELECT 'Create Table UPA_PART ( UPA_KEY NUMBER (19) Not Null, USR_KEY NUMBER (19) Not Null, EFF_FROM_DATE TIMESTAMP (6) Not Null, EFF_TO_DATE TIMESTAMP (6), SRC VARCHAR2 (4000), SNAPSHOT CLOB, DELTAS CLOB, SIGNATURE CLOB ) PARTITION BY RANGE (EFF_TO_DATE) (PARTITION UPA_2008 VALUES LESS THAN (TO_DATE(''01/01/2009'', ''DD/MM/YYYY'')) Tablespace upa_2008, PARTITION UPA_2009 VALUES LESS THAN (TO_DATE(''01/01/2010'', ''DD/MM/YYYY'')) Tablespace upa_2009, PARTITION UPA_2010 VALUES LESS THAN (TO_DATE(''01/01/2011'', ''DD/MM/YYYY'')) Tablespace upa_2010, PARTITION UPA_2011_PART1 VALUES LESS THAN (TO_DATE('''||TO_CHAR(SYSDATE,'DD/MM/YYYY HH24:MI:SS')||''',''DD/MM/YYYY HH24:MI:SS'')) TABLESPACE UPA_2011_PART1, PARTITION UPA_2011_PART2 VALUES LESS THAN (TO_DATE(''01/01/2012'',''DD/MM/YYYY'')) TABLESPACE UPA_2011_PART2, PARTITION UPA_LATEST VALUES LESS THAN (MAXVALUE) TABLESPACE UPA_MAX ) ENABLE ROW MOVEMENT;' FROM DUAL;
次の文を実行して、UPA表と同様の構造を持つパーティション化されていない別の表を作成します。
SQL> Create table upa_non_part Tablespace TBS_NAME as select * from upa where 1=2;
ここで、TBS_NAMEは、交換されるパーティションと同じ表領域の名前です。
この表は本来一時的なものです。この表の目的は、新規にパーティション化されたUPA表への監査データのロードを容易にすることです。
注意:
UPA_NON_PARTまたはパーティション化されていない一時表は、交換するパーティションと同じ表領域に作成する必要があります。
次に示すように、最新の監査データをパーティション化されていないUPA表にロードします。
SQL> Insert /*+ parallel */ into upa_non_part select /*+ parallel */ * from upa where eff_to_date is null; SQL> COMMIT;
注意:
INSERT文でのヒント/*+parallel*/の使用は任意であり、使用可能なリソースに応じて他のヒントを使用してパフォーマンスを改善することもできます。
次に示すように、ALTER TABLEコマンドを使用してデータをパーティション化された表に入れ替えます。
SQL> ALTER TABLE upa_part EXCHANGE PARTITION UPA_LATEST WITH TABLE UPA_NON_PART WITH VALIDATION UPDATE GLOBAL INDEXES;
次に示すように、upa_non_part表を削除します。
SQL> DROP TABLE upa_non_part;
パーティションを交換する際は、データが物理的に書き込まれるのではなく、データ・ディクショナリが更新されます。したがって、交換するパーティションに関連する同じ表領域内のパーティション化されていない一時UPA_NON_PART表を削除し、再作成する必要があります。
次に示すように、パーティション化されていない元のUPA表の名前をUPA_OLDに変更します。
SQL> ALTER TABLE upa rename TO upa_old;
新規にパーティション化されたUPA_PART表の名前をUPAに変更します。
SQL> RENAME UPA_PART to UPA;
新規UPA表の制約を管理します。これを行うには、次のようにします。
次に示すように、制約を古いUPA表から他の名前に変更します。
ALTER TABLE UPA_old RENAME CONSTRAINT PK_UPA TO PK_UPA_old; ALTER INDEX IDX_UPA_EFF_FROM_DT RENAME TO IDX_UPA_EFF_FROM_DT_old; ALTER INDEX IDX_UPA_EFF_TO_DT RENAME TO IDX_UPA_EFF_TO_DT_old; ALTER INDEX IDX_UPA_USR_KEY RENAME TO IDX_UPA_USR_KEY_old; ALTER INDEX PK_UPA RENAME TO PK_UPA_OLD;
必要な索引および主キー制約を、新規にパーティション化されたUPA表に作成します。表領域やサイズなどの記憶域特性を必ず追加してください。これを行うには、次のSQL問合せを実行します。
SQL>create index IDX_UPA_EFF_FROM_DT on UPA (EFF_FROM_DATE) Local; SQL>create index IDX_UPA_EFF_TO_DT on UPA (EFF_TO_DATE) Local; SQL>create index IDX_UPA_USR_KEY on UPA (USR_KEY) Local; SQL>ALTER TABLE UPA add constraint PK_UPA primary key (UPA_KEY) using index;
注意:
主キーをサポートするために、パーティション化されていないグローバル索引が作成されます。グローバル索引はパーティションに変更が加えられるたびに使用できなくなります。必要に応じて、索引を再構築する必要があります。
次に示すように、UPA表の統計収集を実行します。
SQL>Exec dbms_stats.gather_table_stats(ownname => 'SCHEMA_NAME',tabname => 'UPA',cascade => TRUE,granularity => 'GLOBAL and PARTITION');
注意:
デフォルトでグローバル統計が収集されます。Oracle 11gにはパーティション化されたオブジェクトの統計収集に対する改善が組み込まれているため、変更されていないパーティションは再スキャンされません。これにより、一部のパーティションに静的データが含まれる大きな表で統計収集の速度が大幅に速くなります。表に新しいパーティションが追加された場合は、新しいパーティションの統計のみを収集する必要があります。グローバル統計は、既存のパーティション一覧を使用して新しいパーティション一覧を集計することにより、自動的に更新されます。
Oracle Identity Managerを起動します。データベースをトランザクションに対してオープンにすることができます。テストを行って、アプリケーションが期待どおりに実行されることを確認します。
現在の年のデータをUPA_2011_PART1に追加してすべてのデータが含まれるようにし、現在の年の一貫性を維持します。これを行うには、次のSQL問合せを順番に実行します。
SQL> CREATE TABLE upa_non_part Tablespace TBS_NAME AS SELECT * FROM upa WHERE 1=2;
ここで、TBS_NAMEは、交換されるパーティションと同じ表領域名です。
SQL> Alter Table UPA_NON_PART add constraint PK_UPA_NON_PART primary key (UPA_KEY) using index; ............. ............. SQL> Insert into upa_non_part select * from upa_old where eff_to_date >= to_date('01/01/2011', 'mm/dd/yyyy'); ............. ............. SQL> COMMIT; ............. ............. SQL> ALTER TABLE upa exchange partition UPA_2011_PART1 WITH table upa_non_part WITH VALIDATION UPDATE GLOBAL INDEXES; ............. ............. SQL> Drop table upa_non_part;
必要に応じて、前年のデータを新規にパーティション化されたUPA表に追加します。これを行うには、次のようにします。
次のSQL問合せを順番に実行します。
SQL> CREATE TABLE upa_non_part Tablespace TBS_NAME AS SELECT * FROM upa WHERE 1=2;
ここで、TBS_NAMEは、交換されるパーティションと同じ表領域です。
............. ............. SQL> Alter Table UPA_NON_PART add constraint PK_UPA_NON_PART primary key (UPA_KEY) using index; ............. ............. SQL> Insert into upa_non_part select * from upa_old where eff_to_date >= to_date('01/01/YEAR', 'mm/dd/yyyy') and eff_to_date < to_date('01/01/<YEAR+1>', 'mm/dd/yyyy');
ここで、YEARは、新規にパーティション化されたUPA表にデータを追加する年です。
............. ............. SQL>COMMIT; ............. ............. SQL> Alter table upa exchange partition UPA_<year> with table upa_non_part with validation Update global indexes;
索引が使用できない場合は、再構築します。次のSQL問合せにより、使用できない索引が表示されます。
SQL> Select index_name, partition_name, tablespace_name, status from user_ind_partitions;
次に示すように、upa_non_part表を削除します。
SQL> Drop table upa_non_part;
注意:
過去の各年に対してステップ15を繰り返します。
UPA表に対するすべてのパーティション操作が完了し、データがすべて追加されました。次に示すように、UPA表の統計収集を実行します。
SQL>Exec dbms_stats.gather_table_stats(ownname => '<Schem_name>',tabname => 'UPA',cascade => TRUE,granularity => 'GLOBAL and PARTITION');
UPA_OLD表が不要な場合は、削除します。削除する前に、この表のバックアップを作成できます。
次の項では、UPA表のアーカイブおよびパージについて説明します。
Oracle Identity Managerには、常に現在の最新暦年の監査データが必要です。次に、最新暦年のパーティションの名前を示します。
UPA_LATEST: 最新のパーティション
UPA_2011_PART1およびUPA_2011_PART2: 現在の年のパーティション(現在の年が2011の場合)
これらの2つのパーティションは、Oracle Identity Managerが引き続き使用するためそのままにしておく必要があります。これらの2つのパーティションはアーカイブまたはパージしないでください。
新しい暦年になる前にUPA表に新規パーティションを追加する必要があります。これを行うには、次のSQLテンプレートを使用します。
SQL> Alter table UPA split partition UPA_LATEST at (TO_DATE('01/01/YEAR+1','DD/MM/YYYY')) into (partition UPA_YEAR tablespace UPA_YEAR,partition UPA_LATEST tablespace UPA_MAX) update global indexes;
ここで、TO_DATE関数のYEARは、新しい暦年プラス1を表します。パーティション名および表領域名のYEARは、次の新しい暦年を示します。
新しい暦年2012年の新規パーティションを追加するSQL文の例は、次のとおりです。
SQL> Alter table UPA split partition UPA_LATEST at (TO_DATE('01/01/2013','DD/MM/YYYY')) into (partition UPA_2012 tablespace UPA_2012,partition UPA_LATEST tablespace UPA_MAX) update global indexes;
新しい暦年になる前に所定のSQLテンプレートを使用して新規パーティションを追加することをお薦めします。ただし、次の暦年になる前に新規パーティションを追加しない場合、次の年の開始後に同じSQLコマンドを使用して新規パーティションを追加できます。
Oracle Identity Managerでリアルタイム証明書パージを使用するには、リアルタイム証明書パージ・ジョブ・ユーティリティを理解して構成します。
次の各項では、Oracle Identity Managerのリアルタイム証明書パージ・ソリューションに関連する概念について説明します。
Oracle Identity Managerでは、リアルタイム証明書パージ・ジョブ機能がデフォルトで使用できます。証明書データは、オプション、または構成中に行った選択に基づいて、この機能を使用して継続的にパージできます。このパージ・ソリューションは、1回構成すると、管理者の介入なしに自動的に機能します。
リアルタイム証明書パージ・ジョブには、次のような機能があります。
管理者は、Oracle Identity System Administrationの「スケジュール済タスク」セクションを使用することで、いくつかの重要なパラメータに対して値を指定します。
各パージの実行に関する診断情報は、ログとして取得されます。
パージ・タスクは、割り当てられた時間に従って、定期的に実行されます。
データの増加と、それに続くフットプリントは、継続的に制御されます。
これは、オンラインで操作され、サービスが停止することはありません。
自動化されたスケジュール済タスクによるパージ操作は、事前に定義した周期で暗黙的に非対話型で実行されます。
パージ操作に関連する各種のメトリック(エンティティのモジュール名、成功または失敗のステータス、削除対象の行数など)はログに記録されます。
これらのログは、パージ操作の実行ごとの診断指針になります。
Certification Purgeタスクでは、既存のパージ診断ロギング・フレームワークが使用されます。フレームワークの詳細は、オンライン・アーカイブおよびパージ操作の診断データの収集の項を参照してください。
Oracle Identity Managerでは、アクティブ証明書表と呼ばれるOracle Identity Manager表に証明書データが格納されます。
Oracle Identity Managerでデータベースにアクティブ証明書データを格納する際に使用される命名規則には、表23-13に示すように、頭字語があります。
表23-13 アーカイブ証明書表で使用される頭字語
表の頭字語 | 説明 |
---|---|
CERT_* |
表には証明書が格納されます。CERT_IDは、これらの各表のキーです。 |
CERTD_* |
表には証明書の決定データが格納されます。 |
CERTDS_* |
表には証明書の決定データおよびスナップショット・データが格納されます。 |
CERTS_* |
表には証明書のスナップショット・データが格納されます。 |
証明書パージ・ジョブを使用して、アーカイブ証明書表にデータをアーカイブできます。この表の構造は、アクティブ証明書表と同じです。
表23-14に、アクティブ証明書表と、それに対応するアーカイブ証明書表(アクティブ証明書表のデータがアーカイブされる表)を示します。
表23-14 アクティブ証明書表とアーカイブ証明書表
アクティブ証明書表(Oracle Identity Manager表) | アーカイブ証明書表 |
---|---|
CERT_CERTS |
ARCH_CERT_CERTS |
CERT_CONFIG |
ARCH_CERT_CONFIG |
CERT_LAST_DECISION |
ARCH_CERT_LAST_DECISION |
CERT_TASK_INFO |
ARCH_CERT_TASK_INFO |
CERT_TASK_ACTION |
ARCH_CERT_TASK_ACTION |
CERT_ACTION_HISTORY_SCOPE |
ARCH_CERT_ACTION_HISTORY_SCOPE |
CERT_ACTION_HISTORY |
ARCH_CERT_ACTION_HISTORY |
CERTD_USER |
ARCH_CERTD_USER |
CERTD_USER_ACCT |
ARCH_CERTD_USER_ACCT |
CERTD_ROLE |
ARCH_CERTD_ROLE |
CERTD_APP_INST |
ARCH_CERTD_APP_INST |
CERTD_ENT_DEFN |
ARCH_CERTD_ENT_DEFN |
CERTD_ACCT_ENT_ASGN |
ARCH_CERTD_ACCT_ENT_ASGN |
CERTD_ROLE_POLICY |
ARCH_CERTD_ROLE_POLICY |
CERTD_POL_ENT_DEFN |
ARCH_CERTD_POL_ENT_DEFN |
CERTDS_USER_ROLE_ASGN |
ARCH_CERTDS_USER_ROLE_ASGN |
CERTDS_ENT_ASGN |
ARCH_CERTDS_ENT_ASGN |
CERTS_USER |
ARCH_CERTS_USER |
CERTS_USR_UDF |
ARCH_CERTS_USR_UDF |
CERTS_ROLE |
ARCH_CERTS_ROLE |
CERTS_APP_INST |
ARCH_CERTS_APP_INST |
CERTS_ENT_DEFN |
ARCH_CERTS_ENT_DEFN |
CERTS_ACCOUNT |
ARCH_CERTS_ACCOUNT |
CERTS_ACCT_ENT_ASGN |
ARCH_CERTS_ACCT_ENT_ASGN |
CERTS_POLICY |
ARCH_CERTS_POLICY |
CERTS_POL_ENT_DEFN |
ARCH_CERTS_POL_ENT_DEFN |
CERTS_CATALOG_UDF |
ARCH_CERTS_CATALOG_UDF |
注意:
証明書パージは、オンライン・モードでのみスケジュール済ジョブのインタフェースから利用できます。CERTD_STATS、CERT_DEFN、CERT_EVT_LSNRおよびCERT_EVT_TRIG表のデータはアーカイブまたはパージされません。
リアルタイム証明書パージ・ジョブの診断データの収集の詳細は、オンライン・アーカイブおよびパージ操作の診断データの収集を参照してください。