| Oracle® Fusion Middleware Oracle Identity Manager管理者ガイド 11g リリース1(11.1.1) B62264-03 |
|
 前 |
 次 |
この章では各種アーカイブ・ユーティリティの使用方法について説明します。次の項で構成されています。
この項では、リコンシリエーション・アーカイブ・ユーティリティの使用方法について説明します。内容は次のとおりです。
Oracle Identity Managerは、ターゲット・システムのリコンシリエーション・データを、アクティブ・リコンシリエーション表と呼ばれるOracle Identity Manager表に格納します。
リコンシリエーション・プロセス中、リコンシリエーション・マネージャはアクティブ・リコンシリエーション表のデータをOracle Identity Managerのコア表とリコンサイルします。リコンシリエーション・マネージャはリコンサイルされたデータをアクティブ・リコンシリエーション表から削除しないため、これらの表は最終的に非常に大きくなり、リコンシリエーション・プロセス中のパフォーマンスが低下することがあります。リコンシリエーション・アーカイブ・ユーティリティを使用すると、Oracle Identity Managerとリコンサイルされたデータをアーカイブできます。リコンシリエーション・アーカイブ・ユーティリティは、アーカイブされたデータを、アクティブ・リコンシリエーション表と同じ構造のアーカイブ・リコンシリエーション表に格納します。
表23-1に、アクティブ・リコンシリエーション表と、アクティブ・リコンシリエーション表のデータがアーカイブされる対応するアーカイブ・リコンシリエーション表を示します。
表23-1 アクティブ・リコンシリエーション表とアーカイブ・リコンシリエーション表
| アクティブ・リコンシリエーション表(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_EXCEPTIONS |
ARCH_RECON_EXCEPTIONS |
|
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 |
|
すべての水平リコンシリエーション表 |
"ARCH_" + substr(HTnames,1,25) |
リコンシリエーション・アーカイブ・ユーティリティを使用して、次のタスクを実行できます。
アクティブ・リコンシリエーション表のすべてまたは特定のデータをアーカイブ・リコンシリエーション表にアーカイブ
アクティブ・リコンシリエーション表のすべてのデータの削除
アクティブ・リコンシリエーション表からアーカイブ・リコンシリエーション表にデータを移動してアーカイブする場合は、YYYYMMDD形式の日付(たとえば、この日付以前のすべてのレコードをアーカイブするなど)とリコンシリエーション・イベント・ステータスのパラメータ値(アーカイブするデータを定義)を指定する必要があります。これらのアーカイブ基準の詳細は、「アーカイブ基準」を参照してください。
選択したデータをアーカイブする場合は、指定した日付とイベント・ステータス以前に作成された選択したイベント・ステータスに基づいて、リコンシリエーション・データがユーティリティによってアーカイブされます。
アクティブ・リコンシリエーション表のすべてのデータをアーカイブ・リコンシリエーション表にアーカイブする場合、リコンシリエーション・アーカイブ・ユーティリティによって、指定した日付以前に作成されたリコンシリエーション・データがすべてアーカイブされます。
Oracle Database版のリコンシリエーション・アーカイブ・ユーティリティを構成するファイルは、次のディレクトリにあります。
OIM_HOME/db/oim/oracle/Utilities/Recon11gArchival
リコンシリエーション・アーカイブ・ユーティリティを実行する前に、データベースにOIM_RECON_ARCH表領域を作成する必要があります。これを行うには、次のサンプル・コマンドを実行します。
CREATE TABLESPACE OIM_RECON_ARCH
LOGGING DATAFILE 'OIM_RECON_ARCH'
SIZE 500M REUSE AUTOEXTEND ON NEXT 10M;
|
注意:
|
アーカイブするリコンシリエーション・データの選択には、次の基準が設けられています。値が一致するデータがアーカイブされます。
データはYYYYMMDDの形式にする必要があります。指定されたリコンシリエーション・イベント・パラメータ値と一致する、この日付以前のすべてのレコードがアーカイブされます。
リコンシリエーション・イベント・パラメータで、クローズ済、リンク済、クローズ済またはリンク済または「すべて」を選択します。
クローズ済は、リコンシリエーション・マネージャで手動で閉じられたイベントを表します。
リンク済は、Oracle Identity Managerにリコンサイルされたイベントを表し、次の状態を含みます。
作成に成功しました
更新に成功しました
削除に成功しました
作成に失敗しました
更新に失敗しました
削除に失敗しました
クローズ済またはリンク済
「すべて」は、ステータスに関係なくすべてのイベントをアーカイブします。
リコンシリエーション・アーカイブ・ユーティリティを実行するには:
Oracle Identity Managerデータベースが使用可能で、リコンシリエーション・プロセスが実行されていないことを確認します。また、Oracle Identity Managerデータベースが他のセッションのトランザクションに対してオープンされていないことを確認します。
|
注意: リコンシリエーション・アーカイブ・ユーティリティはオフピーク時間帯に実行することをお薦めします。 |
「サーバーの起動と停止」の章の説明に従って、Oracle Identity Managerを停止します。
Microsoft Windowsプラットフォームでは、短い日付書式をM/d/yyyyとして指定する必要があります。また、時間書式をH:mm:ssとして指定する必要があります。日付書式および時間書式をカスタマイズするには、「コントロール パネル」で「地域と言語のオプション」コマンドを使用します。
|
注意:
|
LinuxまたはUNIXプラットフォームでは、次のコマンドを実行してoim_recon_archival.shファイルの実行権限を設定し、このファイルが有効なLinuxまたはUNIXテキスト・ファイルであることを確認します。
chmod 755 path/oim_recon_archival.sh dos2unix path/oim_recon_archival.sh
LinuxまたはUNIXプラットフォームでは、path/oim_recon_archival.shファイルを実行してユーティリティを実行します。
Microsoft Windowsプラットフォームでは、path\oim_recon_archival.batファイルを実行してユーティリティを実行します。
Oracle Databaseインストール環境で、求められた場合には次のパラメータの値を入力します。
Oracleホーム・ディレクトリ
リモート・データベースのOracle Database名の場合は、入力として接続文字列が求められ、これは、//HOST_NAME:PORT/SERVICE_NAMEの形式で入力します。
Oracle Identity Managerデータベースのユーザー名とパスワード
リコンシリエーション作成日をYYYYMMDD書式で入力します。この日付以前の必要なステータス値を持つすべてのレコードがアーカイブされます。
求められた場合には、アーカイブするデータのリコンシリエーション・イベント・ステータスを選択します。
クローズ済の場合は1を入力
リンク済の場合は2を入力
クローズ済またはリンク済の場合は3を入力
「すべて」の場合には4を入力
「終了」の場合には5を入力
処理するバッチ・サイズを入力します。
デフォルトのバッチ・サイズは5000です。
|
注意: バッチ・サイズは、アーカイブ/パージの単一のイテレーションで、データベース・レベルでの内部コミットとして処理されるレコード数の値です。実行時にアーカイブ・ユーティリティの操作を開始するときに、バッチ・サイズを入力パラメータ値として指定する必要があります。 このバッチ・サイズはデフォルトで5000です。数十万を超えるrecon_eventsをパージする場合は、より大きいバッチ・サイズを選択できます。その場合、RDBMSでより多くのリソースが必要となることがあります(たとえば、TEMP表領域やUNDO表領域でより多くの領域が必要)。 |
ユーティリティはリコンシリエーション・データをアーカイブし、ログ・ファイルに実行サマリーを記録します。
Microsoft Windowsプラットフォームでは、ユーティリティの実行後に、短い日付書式を地域またはロケールの日付書式に再設定します。「コントロール パネル」の「地域と言語のオプション」コマンドを使用して日付書式を再設定します。
アクティブ・リコンシリエーション表からデータが削除されるため、DBAは統計を更新するためにアクティブ・リコンシリエーション表およびその索引を分析する必要があります。Oracle Identity ManagerのデータベースとしてOracle Databaseを使用している場合のみ、この手順を実行してください。
この項では、タスク・アーカイブ・ユーティリティの使用方法について説明します。内容は次のとおりです。
Oracle Identity Managerでは、タスクはリソースのプロビジョニングを処理するプロセスを構成する1つ以上のアクティビティを意味します。たとえば、リソースへのアクセスを要求するプロセスには、複数のプロビジョニング・タスクが含まれます。Oracle Identity Managerでは、アクティブ・タスク表と呼ばれる次の表にタスク・データを格納します。
OSI
OSH
SCH
Oracle Identity Managerのデフォルトでは、完了したタスクはアクティブ・タスク表から削除されません。アクティブ・タスク表のサイズが増加するにつれて、特にプロビジョニング・タスクの管理時に、パフォーマンスが低下する可能性があります。タスクが正常に実行されたら、タスク・アーカイブ・ユーティリティを使用してタスク・データをアーカイブし、それをアクティブ・タスク表から削除できます。タスク・アーカイブ・ユーティリティでタスク・データをアーカイブすると、パフォーマンスが改善され、データを安全に格納できます。
タスク・アーカイブ・ユーティリティは、アーカイブされたタスク・データを次のアーカイブ・タスク表に格納します。これらの表の構造は、アクティブ・タスク表と同じです。
ARCH_OSI
ARCH_OSH
ARCH_SCH
タスク・アーカイブ・ユーティリティを使用して、次のタイプのタスクをアーカイブできます。
無効化または削除されたユーザーの失効されたリソース・インスタンスに対するプロビジョニング・タスク
失効されたリソース・インスタンスに対するプロビジョニング・タスク
タスク・アーカイブ・ユーティリティを使用してタスクをアーカイブする場合、アーカイブ前に、アーカイブ操作のタイプ、ユーザー・ステータス、タスク実行日および索引を削除するレコード数を指定できます。アーカイブ操作はアーカイブするタスク・データのタイプを示し、ユーザー・ステータスは削除、無効化またはその両方を行ったユーザーに関するデータをアーカイブするかどうかを決定します。タスク実行日はタスクを実行する日を示し、YYYYMMDD書式である必要があります。
指定したタスク実行日まで、実行されるすべてのタスクがアーカイブされます。アーカイブ・プロセスにかかる時間を短縮するために、アーカイブされるレコード数が200000を超えると、ユーティリティによりすべてのアクティブ・タスク表の索引が削除されます。アーカイブ・データがアクティブ・タスク表から削除された後に、索引は再作成されます。200000という値は必要な値に変更できます。OIM_TasksArch.batファイルまたはOIM_TasksArch.shファイルのコードの次の行で値を変更できます。
.batファイルの場合、set INDXRESP=200000
.shファイルの場合、indxopt=200000
Oracle Database版のタスク・アーカイブ・ユーティリティを構成するファイルは、次のディレクトリにあります。
OIM_HOME/db/oim/oracle/Utilities/TaskArchival
|
注意: アクティブ・タスク表からアーカイブ・タスク表にアーカイブされたデータは、Oracle Identity Managerから使用できなくなります。このデータにアクセスするには、Oracle Identity Managerデータベースのアーカイブ・タスク表を問い合せる必要があります。 |
タスク・アーカイブ・ユーティリティをOracle Databaseとともに使用するには、次の手順を実行する必要があります。
SQL*Plusを起動し、Oracle DatabaseにSYSユーザーとして接続します。
次のコマンドを入力して、アーカイブ・タスク表用に別の表領域を作成します。DATA_DIRを、データ・ファイルを格納するディレクトリで置き換え、必要に応じてサイズなどのパラメータを環境に合せて調整します。
CREATE TABLESPACE TasksArch
DATAFILE 'DATA_DIR\tasksarch_01.dbf' SIZE 1000M REUSE
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
|
注意: 大量のデータをアーカイブする際は、大きなサイズのUNDO表領域を割り当てることをお薦めします。また、初期化パラメータparallel_max_serversおよびparallel_min_serversを構成して、パラレル実行を有効にしてください。パラレル実行は、アーカイブ・プロセスのパフォーマンスの向上に役立ちます。 |
Oracle Identity Managerデータベース・ユーザーとしてOracle Databaseに接続します。
次のコマンドを入力してcr_taskarchival_ddl_table.sqlスクリプトを実行し、OIM_TASK_ARCH_DDLという表を作成します。この表は、タスク・アーカイブ・ユーティリティで使用されます。
@ path/cr_taskarchival_ddl_table.sql
次のコマンドを入力してCreate_TasksArch_Tables.sqlスクリプトを実行し、アーカイブ・タスク表を作成します。
@ path/Create_TasksArch_Tables.sql
次のコマンドを入力してOIM_SP_TASKS_ARCHIVAL.sqlスクリプトを実行し、タスク・アーカイブ・ユーティリティでタスク・データをアーカイブおよび削除するために使用するストアド・プロシージャを作成します。
@ path/OIM_SP_TASKS_ARCHIVAL.sql
|
注意: Oracle Identity Managerユーティリティを実行する環境で、LD_LIBRARY_PATHをSQL*PlusなどのOracleユーティリティを開始するように設定する必要があります。 |
次の手順を実行して、タスク・アーカイブ・ユーティリティを実行します。
Oracle Identity Managerデータベースが使用可能になっており、他のOracle Identity Managerトランザクションに対してはオープンになっていないことを確認します。
|
注意: タスク・アーカイブ・ユーティリティは、オフピーク時間帯に実行することをお薦めします。 |
OSI、SCHおよびOSH表のバックアップを作成したことを確認します。
使用しているアプリケーション・サーバーに対応したOracle Identity Managerのインストレーション・ガイドの手順に従って、Oracle Identity Managerを停止します。
Microsoft Windowsプラットフォームでは、短い日付書式をdddd M/d/yyyyとして指定する必要があります。また、時間書式をH:mm:ssとして指定する必要があります。日付書式および時間書式をカスタマイズするには、「コントロール パネル」で「地域と言語のオプション」コマンドを選択します。
|
注意:
|
LinuxおよびUNIXプラットフォームでは、path/OIM_TasksArch.shファイルを実行します。Microsoft Windowsプラットフォームでは、path\OIM_TasksArch.batファイルを実行します。
Oracle Databaseインストール環境で、求められた場合には次のパラメータの値を入力します。
Oracleホーム・ディレクトリ
Oracle Identity Managerデータベース名またはOracle Identity Managerデータベースがリモート・コンピュータで稼働している場合はTNS文字列
リモート・データベースの場合は、入力として接続文字列が求められます。これは、//HOST_NAME:PORT/SERVICE_NAMEの形式で入力します。
Oracle Identity Managerデータベースのユーザー名とパスワード
求められた場合には、次のオプションのいずれかを選択します。
無効化または削除されたユーザーの失効されたリソース・インスタンスに対するプロビジョニング・タスクをすべてアーカイブします。
?失効されたリソース・インスタンスに対するプロビジョニング・タスクをすべてアーカイブします。
終了します。
無効化または削除されたユーザーの失効されたリソース・インスタンスに対するプロビジョニング・タスクをすべてアーカイブする場合、次のいずれかのオプションを選択します。
ステータスが「削除」であるユーザー
ステータスが「無効」であるユーザー
ステータスが「削除」および「無効」であるユーザー
メイン・メニューに戻る
入力を求められたら、YYYYMMDDという書式でタスク実行日を入力します。指定したタスク実行日まで、実行されるすべてのタスクがアーカイブされます。現在の日付以前に実行されたすべてのタスクをアーカイブするには、日付を入力せずに[Enter]キーを押します。
ユーティリティがアーカイブ・プロセスを開始する前に、サマリー情報が表示されます。サマリー情報によって、アーカイブされるタスクの合計数がわかります。サマリー情報を注意深く確認し、サマリーに表示されている削除量をデータベースでサポートできることを確認します。
タスクをアーカイブするには、入力を求められたときにyまたはYの値を入力します。あるいは、nまたはNを入力して、ユーティリティを終了します。
|
注意: 入力を求められたときに、YまたはNの値を入力する必要があります。値を選択しないで[Enter]キーを押すと、ユーティリティでは再度アーカイブされるタスク数が計算され、アーカイブを開始せずに確認が求められます。 |
Microsoft Windowsプラットフォームでは、タスク・アーカイブ・ユーティリティの実行完了後に、短い日付書式を地域またはロケールの日付書式に再設定します。「コントロール パネル」で「地域と言語のオプション」コマンドを使用して日付書式を再設定します。
|
注意: アクティブ・タスク表からデータが削除されるため、更新される統計用にアクティブ・タスク表およびその索引を分析する必要があります。Oracle Identity ManagerのデータベースとしてOracle Databaseを使用している場合のみ、この手順を実行してください。 |
表23-2に、タスク・アーカイブ・ユーティリティによって生成される出力ファイルを示します。
表23-2 タスク・アーカイブ・ユーティリティによって生成される出力ファイル
| ファイル | 説明 |
|---|---|
|
|
ユーティリティが指定された資格証明を使用してデータベースに接続できなかった場合に生成されます。 |
|
|
アーカイブ・プロセスまたは削除プロセスが失敗した場合に生成されます。 |
|
|
アーカイブ・プロセスまたは削除プロセスが成功した場合に生成されます。 |
|
注意: ユーティリティを再度実行するときに、これらのエラー・ログ・ファイルは削除されます。 |
この項では、リックエスト・アーカイブ・ユーティリティの使用方法について説明します。内容は次のとおりです。
デフォルトで、Oracle Identity Managerはクローズまたは取り消されたリクエストをアクティブ・リクエスト表から削除しません。これらのリクエストをアーカイブしてディスク領域を解放し、データベースのパフォーマンスを向上させるには、リクエスト・アーカイブ・ユーティリティを使用します。リクエスト・データは、リクエスト作成日とリクエスト・ステータスに基づいてアーカイブできます。リクエスト・ステータスに基づいてリクエストをアーカイブするかどうかは任意です。リクエスト・ステータスを使用すると、次の内容をアーカイブできます。
リクエスト・ステータスが取消し済、「クローズ済」または「完了」である完了したリクエスト。これは、オプション完了の場合は1を選択して指定されます。
リクエスト・ステータスが取消し済、「クローズ済」、「完了」または「失敗」、一部失敗である完了または失敗したリクエスト。これは、オプション完了および失敗の場合は2を選択して指定されます。
リクエスト作成日に基づくすべてのリクエスト。これは、オプションすべての場合は3を選択して指定されます。
表23-3に、アーカイブされる表の名前と、対応するアーカイブ表の名前を示します。
表23-3 アーカイブ表
| メイン表 | アーカイブ表 |
|---|---|
|
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/db/oim/oracle/Utilities/RequestArchival
リクエスト・アーカイブ・ユーティリティは、Oracle Identity Managerを停止してオフライン・モードで実行することも、Oracle Identity Managerを実行してオンライン・モードで実行することもできます。
ユーティリティをオフライン・モードで実行する前に、Oracle Identity Managerを停止する必要があります。
リクエスト・アーカイブ・ユーティリティを実行する前に、次のことを行います。
|
注意: Oracle Identity Managerユーティリティを実行する環境で、LD_LIBRARY_PATHをSQL*PlusなどのOracleユーティリティを開始するように設定する必要があります。 |
OIM_REQUEST_ARCH表領域を作成します。リクエスト・アーカイブ・ユーティリティを初めて実行する場合は、アーカイブされるすべての表に対して、対応するアーカイブ表が作成されます。アーカイブ表は、OIM_REQUEST_ARCHと呼ばれる個別の表領域に作成されます。ユーティリティを実行する前に、この表領域を作成しておく必要があります。
oim_create_request_arch_tables.sqlスクリプトを実行して、リクエスト表に対して必要なアーカイブ表を作成します。これは、アーカイブされるすべての表に対応するアーカイブ表を作成するPL/SQLスクリプトです。
ユーティリティをオフライン・モードで実行する場合は、ユーティリティを実行する前にOracle Identity Managerを停止する必要があります。
表23-4に、リクエスト・アーカイブ・ユーティリティによって使用される入力パラメータのリストを示します。
表23-4 入力パラメータ
| パラメータ | 説明 |
|---|---|
|
Oracleホーム |
システムのORACLE_HOME環境変数の値。 |
|
Oracle SID |
Oracle Identity ManagerデータベースのSID。リモート・データベースの場合は、//HOST_NAME:PORT/SERVICE_NAMEの形式で接続文字列を入力する必要があります。 ここで、HOST_NAMEはデータベースがデプロイされているコンピュータのホスト名、PORTはホストのポート番号、SERVICE_NAMEはデータベース・インスタンスの名前です。 |
|
OIM DBユーザー |
Oracle Identity Managerデータベース・ユーザーのデータベース・ログインIDです。 |
|
OIM DBパスワード |
Oracle Identity Managerデータベース・ユーザーのパスワード。 |
|
リクエスト・ステータス |
ユーザー入力値1、2または3に基づいたリクエスト・ステータス。 |
|
リクエスト作成日 |
ユーティリティは、このリクエスト基準日またはそれ以前に作成された、必要なリクエスト・ステータスのすべてのリクエストをアーカイブします。 |
|
バッチ・サイズ |
ユーティリティは、レコードのグループまたはバッチを単一トランザクションとして処理します。バッチ・サイズは、ユーティリティのパフォーマンスに影響する可能性があります。 「バッチ・サイズ」のデフォルト値は |
|
ユーティリティ実行モード |
ユーティリティを実行するモード(オンラインまたはオフライン)。オンライン・モードの場合は1を、オフライン・モードの場合は2を入力する必要があります。 ユーティリティは、オンライン・モードよりもオフライン・モードのほうが高速で実行されます。ただし、ユーティリティをオフライン・モードで実行するには、ダウンタイムが必要です。オフライン・モードで実行することによってアーカイブ操作を高速化できますが、ユーティリティがアーカイブ操作を完了するまでOracle Identity Managerを使用できません。このため、このオプションを選択する前に、Oracle Identity Managerが実行されていないことを確認してください。 |
Oracle Identity Managerデータベースが使用可能であることを確認します。
|
注意: リクエスト・アーカイブ・ユーティリティは、オフピーク時間帯に実行することをお薦めします。 |
ユーティリティをオフライン・モードで実行する場合は、「サーバーの起動と停止」の章の説明に従って、Oracle Identity Managerを停止します。
ユーティリティをオンライン・モードで実行する場合は、この手順を無視してステップ3に進みます。
Microsoft Windowsプラットフォームでは、短い日付書式をdddd M/d/yyyy.として指定する必要があります。また、時間書式を H:mm:ssとして指定する必要があります。日付書式および時間書式をカスタマイズするには、「コントロール パネル」で「地域と言語のオプション」コマンドを使用します。
|
注意:
|
UNIXプラットフォームでは、次のコマンドを実行してOIM_request_archival.sh ファイルの実行権限を設定し、このファイルが有効なUNIXテキスト・ファイルであることを確認します。
chmod 755 path/OIM_request_archival.sh dos2unix path/OIM_request_archival.sh
UNIXプラットフォームでは、path/OIM_request_archival.shファイルを実行します。Microsoft Windowsプラットフォームでは、path\OIM_request_archival.batファイルを実行します。
oim_request_archivalスクリプトではデータベース入力が検証され、データベースとの接続が確立されます。次にoim_request_archival.sqlスクリプトが呼び出され、このスクリプトはユーティリティに関連するPL/SQLプロシージャをコンパイルするために使用されます。
Oracle Databaseインストール環境で、求められた場合には次のパラメータの値を入力します。
Oracleホーム・ディレクトリ
Oracle Identity Managerデータベース名またはOracle Identity Managerデータベースがリモート・コンピュータで稼働している場合はTNS文字列。そうでない場合は、ORALE SIDを入力します。
リモート・データベースの場合は、入力として接続文字列が求められます。これは、//HOST_NAME:PORT/SERVICE_NAMEの形式で入力します。
Oracle Identity Managerデータベースのユーザー名とパスワード
求められた場合には、次のオプションのいずれかを入力します。
ステータスが「リクエストが取り消されました」、「リクエストがクローズされました」、「リクエストが完了しました」で、作成日がユーザーによってYYYYMMDD書式で指定されたリクエスト作成日またはそれ以前であるリクエストをアーカイブするには、1を入力します。
ステータスが「リクエストが取り消されました」、「リクエストがクローズされました」、「リクエストが完了しました」またはリクエストの一部が失敗しましたで、作成日がユーザーによってYYYYMMDD書式で指定されたリクエスト作成日またはそれ以前であるリクエストをアーカイブするには、2を入力します。
リクエスト作成日が、ユーザーによってYYYYMMDD書式で指定されたリクエスト作成日またはそれ以前であるすべてのリクエストをアーカイブするには、3を入力します。
ユーティリティを実行するモードを指定するように求められた場合、ユーティリティをオンライン・モードで実行する場合は1を入力します。それ以外の場合は、2を入力してユーティリティをオフライン・モードで実行します。
求められた場合には、バッチ・サイズを指定します。
|
注意: バッチ・サイズは、アーカイブ/パージの単一のイテレーションで、データベース・レベルでの内部コミットとして処理されるレコード数の値です。実行時にアーカイブ・ユーティリティの操作を開始するときに、バッチ・サイズを入力パラメータ値として指定する必要があります。 このバッチ・サイズはデフォルトで2000です。より大きいバッチ・サイズを選択できますが、その場合、データベースでより多くのリソースが必要となることがあります(たとえば、TEMP表領域やUNDO表領域でより多くの領域が必要)。 |
ユーティリティはリクエスト・データをアーカイブし、ログ・ファイルに実行サマリーを記録します。
Microsoft Windowsプラットフォームでは、ユーティリティの実行後に、短い日付書式を地域またはロケールの日付書式に再設定します。「コントロール パネル」の「地域と言語のオプション」コマンドを使用して日付書式を再設定します。
アクティブ・リクエスト表からデータが削除されるため、DBAは統計を更新するためにアクティブ・リクエスト表およびその索引を分析する必要があります。Oracle Identity ManagerのデータベースとしてOracle Databaseを使用している場合のみ、この手順を実行してください。
すべてのログは、現在のフォルダに作成されているlogs/ディレクトリに書き込まれます。表23-5にユーティリティにより生成されるログ・ファイルのリストを示します。
表23-5 DBアーカイブ・ユーティリティにより生成されるログ
| ログ・ファイル | 説明 |
|---|---|
|
oim_create_request_arch_tables.log |
ユーティリティがアーカイブ表の作成に失敗したときに作成されます。 |
|
oim_request_archival.log |
ユーティリティがアーカイブに必要なプロシージャの作成に失敗したときに作成されます。 |
|
validate_date.log |
入力値REQUEST_CREATION_DATEが無効な場合に作成されます。 |
|
oim_request_archival_summary_TIMESTAMP.log |
実行のサマリーが含まれます。 |
|
Err_DB_Conn_TIMESTAMP_ATTEMPTNUMBER.log |
ユーティリティが提供される資格証明を使用してデータベースに接続できない場合に作成されます。 |
この項では、監査アーカイブおよびパージ・ユーティリティの使用方法について説明します。内容は次のとおりです。
Oracle Identity Managerデータベース・スキーマで継続的にデータが生成され、監査データが増加することにより、データベース・サーバーによる記憶域の消費量が徐々に増大します。監査データはUPA表に移入されます。UPA表のデータの増加により、ディスク領域とメンテナンスの問題が発生する場合があります。したがって、UPA表内の古い監査データを消去またはアーカイブする必要があります。
ディスク領域の消費量を制御するために、監査アーカイブおよびパージ・ユーティリティを使用できます。このユーティリティは、論理的かつ一貫した方法でデータをパージすることにより、監査データの増加を制御します。
|
注意:
|
パーティションをアーカイブまたは削除できる、暦年に基づいた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表を準備するには、次の手順を実行します。
Oracle Identity Managerが実行されておらず、オフライン・ユーティリティで使用できないことを確認します。
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;
これは、最小の年から始まる各暦年のパーティションを決定する際に役立ちます。
新規パーティション表を作成します。
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_part 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コマンドを使用して新規パーティションを追加できます。
UPA表のパーティションをアーカイブまたはパージするには、次の手順を実行します。
Oracle Identity Managerのアテステーション機能を使用する場合は、アーカイブまたはパージするパーティションにアクティブなアテステーション・レコードがないことを確認します。これを確認するには、次のSQLを使用します。
SQL> SELECT COUNT(1) FROM UPA PARTITION(<PARTITION_TO_BE_DROPPED>) WHERE UPA_KEY IN (select distinct (upa_key) from apt apt, atr atr, atd atd where apt.atr_key=atr.atr_key and atr.atr_completion_time is NULL and apt.apt_key = atd.apt_key);
この問合せは、アクティブなアテステーション・レコードがないことを意味するゼロ・レコードを返す必要があります。ゼロ以外の値が返される場合は、削除対象のパーティションを指すアクティブなアテステーションがまだ存在していることを意味します。このことは一般的ではありませんが、過去の年のパーティションを削除する前に、アクティブなアテステーション・レコードがないことを確認する必要があります。
削除対象のパーティションのデータを必要とするカスタム・レポートまたは問合せがないことを確認します。
削除対象のパーティションをテープまたは他のメディアにアーカイブします。パーティションをアーカイブするには多くの方法があります。方法の1つは、データ・ポンプまたはエクスポート・ユーティリティを使用して、削除対象のパーティションをアーカイブすることです。使用中の環境で最も効果的な方法を選択します。
パーティションをパージします。これを行うには、次のようにします。
SQL> Alter table UPA drop partition PARTITION_NAME UPDATE GLOBAL INDEXES; SQL>Drop tablespace TBS_NAME including contents and datafiles;
ここで、TBS_NAMEは削除対象のパーティションに関連付けられている表領域で、ここに他のデータが含まれていてはいけません。
|
注意:
|
