Oracle Identity Governanceのパフォーマンス・チューニング

13 Oracle Identity Governanceのパフォーマンス・チューニング

ノート:

エンタープライズ・クラスのどのようなビジネス・アプリケーションにおいても、すべてのシステムに通用するような単純なチューニング方法はありません。この章のチューニングに関する項では、構成のサンプルを(場合によっては)示し、Oracle Identity Governanceのチューニングの原則の概要について説明します。各自のユースケース・シナリオを検討し、適切な設定を判断してください。

この章では、Oracle Identity Governance (OIG)に固有のチューニングおよびサイズ設定のガイドラインを示します。この項の内容は、次のとおりです。

親トピック: Oracle Identity and Access Management

Oracle Identity Governanceについて

Oracle Identity Governance (OIG)を使用すると、エンタープライズおよびエクストラネット・アプリケーションにわたり、アイデンティティおよびユーザー・プロビジョニング・イベントが集中管理され、完全に自動化されるため、運用効率およびビジネス効率が向上します。

Oracle Identity Governanceの使用の詳細は、『Oracle Identity Governanceの管理』を参照してください。

親トピック: Oracle Identity Governanceのパフォーマンス・チューニング

Oracle Identity Governanceのパフォーマンスの監視

Oracle Identity Governanceのリアルタイム・パフォーマンス・メトリックを監視すると、パフォーマンス・ボトルネックを特定できます。Oracle Fusion Middlewareコンポーネントの監視方法の詳細は、「モニタリング」を参照してください。

Oracle Identity Governanceでは、次の作業を定期的に行うことをお薦めします。

Oracle Database 11gのOracle Enterprise Managerコンソールや自動ワークロード・リポジトリ(AWR)などのパフォーマンス・モニタリング・ツールを使用して、リアルタイムのパフォーマンスを監視します。
ノート:

Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、Oracle Identity Governanceを監視できます。これを行うには:
1. Identity Managementで、Oracle Identity Governanceを選択して「ホーム」ページに進みます。「ホーム」ページで、Oracle Identity Governanceを監視できます。
2. Oracle Identity Governanceメニューから「パフォーマンス」を選択して、パフォーマンス・メトリックを表示します。
Oracle Database Enterprise Manager (EM)を使用してルーチン統計とレポートを収集します。これはOracle Database (標準機能)で使用可能です。
- ルーチン統計の収集
  
  ルーチン統計の収集は、自動メンテナンス・タスクによって行われます。これはOracle Databaseの次のナビゲーション・パスで使用できます。
  
  Oracle EM→「サーバー」タブ→「問合せオプティマイザ」→オプティマイザ統計の管理→自動メンテナンス・タスク・リンク
- Oracle Database 11g EMによる統計のレポート要件
  
  現在収集されている統計の状態をレポートするために、EMには次のナビゲーション・パスにレポート・インタフェースが用意されています。
  
  Oracle EM→「サーバー」タブ→「問合せオプティマイザ」→オプティマイザ統計の管理→「オブジェクト統計」リンク
  
  このインタフェースを使用して、失効、欠落またはロック状態のオブジェクトやすでに分析済のオブジェクトまで、すべてのオブジェクトをレポートできます(スキーマのオブジェクトや選択肢のオブジェクトも含みます)。
完全なスキーマ統計をOracle Identity Governance実装で収集します。

OIGスキーマおよび依存スキーマ(*_MDS, *_SOAINFRA, *_OPSS and *_ORASDPM)を更新します。ユーザーやアカウントの一括ロード、新規コネクタのインポート、新規ターゲットからの大規模なリコンシリエーションの実行、アーカイブ・リコンシリエーションやアーカイブ・ユーティリティの使用などの大量なデータ変更イベントでは、完全なスキーマまたは表統計を考慮してください。OIGおよびOIG依存スキーマ(*_MDS, *_SOAINFRA, *_OPSS and *_ORASDPM)の統計を定期的に収集する必要があります。

これによりCBOは、データの現行の状態に基づく効果的な問合せ実行計画を決定できます。次に、定期的にデータベース統計を収集するSQLコマンドのサンプルを示します。

関連項目:

ルーチン統計の収集とレポートは、Oracle Database 11gで使用可能な自動メンテナンス・タスクによって実行できます。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド 11g リリース1 (11.1)』を参照してください。
```
DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> schema_owner,
Exec dbms_stats.gather_schema_stats(OWNNAME=> 'OIG_OIG',ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,degree =>DBMS_STATS.DEFAULT_DEGREE,options=>'GATHER AUTO', no_invalidate =>FALSE,cascade=>TRUE); 
```
「自動データベース診断モニター(ADDM)」や「自動ワークロード・リポジトリ」レポートのアドバイザ・セクションにある関連推奨事項を参照し、推奨された設定に従ってインスタンス構成パラメータを調整します。これは特に、新しいコネクタをインポートして、新しいターゲット・システムからの一連のリコンシリエーションを完了した後で、一致ルールに応じた新しい索引の必要性を識別するために必要になります。

親トピック: Oracle Identity Governanceのパフォーマンス・チューニング

チューニングに関する基本的な考慮事項

Oracle Identity Governanceの使用状況およびパフォーマンスの問題に応じて、次の基本的なパラメータのチューニングを検討してください。チューニングに関するその他の考慮事項については、「主なパフォーマンス分野」を参照してください。

親トピック: Oracle Identity Governanceのパフォーマンス・チューニング

アプリケーション・キャッシュのチューニングと管理

Oracle Identity Governanceではメタデータのキャッシングが可能で、これによってDBアクティビティを減らすことができます。結果としてネットワーク負荷が軽減され、パフォーマンスが向上します。

開発環境でアプリケーション・サーバーを再起動しなくても構成の変更がすぐに反映されるように、デフォルトでは大多数の構成のキャッシングは無効です(falseに設定されています)。

次の各項では、Oracle Identity Governanceをチューニングするための推奨キャッシュ値をいくつか示します。

親トピック: チューニングに関する基本的な考慮事項

Oracle Identity Governanceのキャッシュのチューニング

キャッシュは、Oracle Identity Governanceが構成を格納するMDSにある/db/oim-config.xml構成ファイルで構成されます。Oracle Enterprise Manager (EM)を使用してキャッシュを有効にしたり、oim-config.xmlをエクスポートして変更を行ってからインポートして戻してキャッシュを有効にできます。

本番環境でより高い最適なパフォーマンスが得られるように、次の設定をお薦めします。EMを使用して、システムMBean→「アプリケーション定義のMBeans」→oracle.iam→server:OIM_server1→Application: OIM→XMLConfig→Config→XMLConfig.CacheConfig→「キャッシュ」→XMLConfig.CacheConfig.CacheCategoryConfigに移動して、次の操作を実行します。

次の2つのセクションを除くすべてのコンポーネントのキャッシングをtrueに設定します。
```
threadLocalCacheEnabled="false"
```
クラスタ化されていないインストールでは、clustered="false"を設定します。クラスタ化されているインストールでは、clustered="true"を設定します。

ノート:

変更したこの値は、Oracle Identity Governanceサーバーによって使用されるMDSデータベース・スキーマに保存されます。したがって、マルチノード・インストールまたはクラスタ化されたインストールでは、1回のみ変更してください。

キャッシュ・カテゴリUser_Org_Membership_And_ChainおよびObjectDefinitionの有効化

Oracle Identity Governanceバージョンに基づいて、表13-1の説明に従ってキャッシュ・カテゴリを有効化することをお薦めします。Oracle Identity Governanceバージョンが次の表の「適用可能なリリース」列で指定されたバージョンと同じでない場合、これらを有効にする必要はないので注意してください。

表13-1 キャッシュ・カテゴリを有効化する手順

キャッシュ・カテゴリ名適用可能なリリース手順

キャッシュ・カテゴリ名	適用可能なリリース	手順
User_Org_Membership_And_Chain	Oracle Identity Governance 12cリリース(12.2.1.4.0)	Oracle Enterprise Manager (EM)を使用するか、`oim-config.xml`構成ファイルを編集して、このキャッシュ・カテゴリを有効化できます。これを行うには、次のステップを実行します: EMの使用 EMにログインします。 oracle.iamの下にあるmbean XMLConfig.CacheConfigに移動し、`true`に設定されていない場合は属性`Enabled`の値を`true`に設定します。Mbeanのオブジェクト名は"oracle.iam:name=Cache,type=XMLConfig.CacheConfig,XMLConfig=Config,Application=OIM,ApplicationVersion=12.2.1.4.0"です。次のパラメータとともにmbeanのcreateCacheCategoryConfig操作を使用して、新しいキャッシュ・カテゴリを作成します。 `enabled=true` `expirationTime=3600` `name=User_Org_Membership_And_Chain` oim-config.xmlファイルの使用 `$OIM_HOME/bin`に移動します。環境変数`OIM_ORACLE_HOME`を適宜設定します。 `weblogic.properties`ファイルを開き、メタデータ・ファイルをエクスポートするために次のプロパティを設定します。 wls_servername=`OIM_server1` application_name=OIMAppMetadata metadata_to_loc=`<TMP_DIRECTORY>` metadata_files=/db/oim-config.xml 次のコマンド・スクリプトを実行して、`/db/oim-config.xml`メタデータ・ファイルをエクスポートします。 `./weblogicExportMetadata.sh` 入力を要求されたら、WebLogic資格証明およびJNDI URLを入力します。 `$TMP_DIRECTORY/db/oim-config.xml`ファイルを開き、`cacheCategoriesConfig`タグに次の内容を追加します。 <cacheCategoryConfig enabled="true" expirationTime="14400" name="User_Org_Membership_And_Chain"/> `weblogic.properties`ファイルを開き、変更されたメタデータ・ファイルをインポートするために次のプロパティを設定します。 wls_servername=`OIM_server1` application_name=OIMAppMetadata metadata_from_loc=`<TMP_DIRECTORY>` 次のコマンドを実行して、変更された`/db/oim-config.xml`メタデータ・ファイルをMDSにインポートします。 `./weblogicImportMetadata.sh` 入力を要求されたら、WebLogic資格証明およびJNDI URLを入力します。
ObjectDefinition	Oracle Identity Governance 12c (12.2.1.4.0)	Oracle Enterprise Manager (EM)を使用して、このキャッシュ・カテゴリを有効化できます。これを行うには、次のステップを完了します。 EMにログインします。 oracle.iamの下にあるmbean XMLConfig.CacheConfigに移動し、キャッシュ・カテゴリObjectDefinitionの属性`Enabled`の値を`true`に設定します。

User_Org_Membership_And_Chain

Oracle Identity Governance 12cリリース(12.2.1.4.0)

Oracle Enterprise Manager (EM)を使用するか、oim-config.xml構成ファイルを編集して、このキャッシュ・カテゴリを有効化できます。これを行うには、次のステップを実行します:

EMの使用

EMにログインします。
oracle.iamの下にあるmbean XMLConfig.CacheConfigに移動し、trueに設定されていない場合は属性Enabledの値をtrueに設定します。Mbeanのオブジェクト名は"oracle.iam:name=Cache,type=XMLConfig.CacheConfig,XMLConfig=Config,Application=OIM,ApplicationVersion=12.2.1.4.0"です。
次のパラメータとともにmbeanのcreateCacheCategoryConfig操作を使用して、新しいキャッシュ・カテゴリを作成します。

enabled=true

expirationTime=3600

name=User_Org_Membership_And_Chain

oim-config.xmlファイルの使用

$OIM_HOME/binに移動します。
環境変数OIM_ORACLE_HOMEを適宜設定します。
weblogic.propertiesファイルを開き、メタデータ・ファイルをエクスポートするために次のプロパティを設定します。
```
wls_servername=OIM_server1
application_name=OIMAppMetadata
metadata_to_loc=<TMP_DIRECTORY>
metadata_files=/db/oim-config.xml
```
次のコマンド・スクリプトを実行して、/db/oim-config.xmlメタデータ・ファイルをエクスポートします。

./weblogicExportMetadata.sh

入力を要求されたら、WebLogic資格証明およびJNDI URLを入力します。
$TMP_DIRECTORY/db/oim-config.xmlファイルを開き、cacheCategoriesConfigタグに次の内容を追加します。
```
<cacheCategoryConfig enabled="true" expirationTime="14400"
name="User_Org_Membership_And_Chain"/>
```
weblogic.propertiesファイルを開き、変更されたメタデータ・ファイルをインポートするために次のプロパティを設定します。
```
wls_servername=OIM_server1
application_name=OIMAppMetadata
metadata_from_loc=<TMP_DIRECTORY>
```
次のコマンドを実行して、変更された/db/oim-config.xmlメタデータ・ファイルをMDSにインポートします。

./weblogicImportMetadata.sh

入力を要求されたら、WebLogic資格証明およびJNDI URLを入力します。

ObjectDefinition

Oracle Identity Governance 12c (12.2.1.4.0)

Oracle Enterprise Manager (EM)を使用して、このキャッシュ・カテゴリを有効化できます。これを行うには、次のステップを完了します。

EMにログインします。
oracle.iamの下にあるmbean XMLConfig.CacheConfigに移動し、キャッシュ・カテゴリObjectDefinitionの属性Enabledの値をtrueに設定します。

ノート:

Enterprise Managerを使用した構成変更の詳細は、『Oracle Identity Governanceの管理』のEnterprise Managerを使用したOracle Identity Governanceの構成の管理に関する項を参照してください。

親トピック: アプリケーション・キャッシュのチューニングと管理

キャッシュのパージ

キャッシュをパージするには、OIM_HOME/server/bin/ディレクトリでPurgeCacheユーティリティを使用します。このユーティリティはキャッシュ内のすべての要素をパージします。

ノート:

キャッシュのパージは、キャッシングが有効でシステム構成を変更した場合に行う必要があります。キャッシングが無効な場合には不要です。
PurgeCacheユーティリティを実行する前に、OIM_HOME/server/bin/ディレクトリに移動します。

PurgeCacheユーティリティを実行する前に、DOMAIN_HOME/bin/setDomainEnv.shスクリプトを実行する必要があります。

PurgeCacheユーティリティを使用するには、Microsoft WindowsではPurgeCache.bat CATEGORY_NAME、UNIXではPurgeCache.sh CATEGORY_NAMEを実行します。CATEGORY_NAME引数は、パージする必要のあるカテゴリの名前を表します。たとえば、次のコマンドはすべてのFormDefinitionエントリをシステムとそのクラスタからパージします。

PurgeCache.bat FormDefinition
PurgeCache.sh FormDefinition

すべてのOracle Identity Governanceカテゴリをパージするには、PurgeCacheユーティリティにAllの値を渡します。カテゴリはすべてクリアすることをお薦めします。

親トピック: アプリケーション・キャッシュのチューニングと管理

Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

この項では、Oracle Identity Governance用にOracle WebLogic Serverをチューニングしてパフォーマンスを向上させる方法を説明します。Oracle WebLogic Serverのパフォーマンス・チューニングの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。

ノート:

この項では、すべてのチューニング・パラメータの推奨および値を参考のみの目的で示しています。必要性、アプリケーションの使用パターン、負荷およびハードウェア仕様に基づいて、値を変更してください。
いずれかの設定を変更した場合、サーバーを再起動する必要があります。

親トピック: チューニングに関する基本的な考慮事項

Oracle Identity Governanceに対するJVMメモリー設定のチューニング

「Java仮想マシン(JVM)のチューニング」で説明した設定に加えて、これらの設定を使用してください。

表13-2のように、本番環境のヒープ・メモリーとpermgenメモリーを増やして、メモリーの使用パターンを監視することをお薦めします。使用状況に基づいて、これらのメモリー設定は増減できます。

表13-2 JVMメモリー設定をチューニングするために設定するJVMパラメータ

JVMパラメータ	HotSpot JVM
`Min. Heap Size (Xms)`	4GB
`Max Heap Size (Xmx)`	8GB
`MetaspaceSize (-XX:MetaspaceSize)`	500m
`MaxMetaspaceSize (-XX:MaxMetaspaceSize)`	1GB

JVMメモリー設定を変更するには:

DOMAIN_HOME/bin/setStartupEnv.sh (Unix)を使用するか、OIMDomainEnv.cmd (Windows)を設定します。そうでない場合は、DOMAIN_HOME/bin/setStartupEnv.sh (Unix)またはsetStartupEnv.cmd (Windows)を引き続き使用して、ヒープ・サイズ設定を変更します。
DOMAIN_HOME/bin/setStartupEnv.sh (Unix)またはsetStartupEnv.cmd (Windows)で、OIM-MGD_SVRSのメモリー引数SERVER_MEM_ARGS_xxHotSpotの値を変更します。
すべてのサーバーを再起動します。

コンソールを使用してすべてのサーバーを再起動する場合は、ノード・マネージャも再起動する必要があります。

ノート:

クラスタ化されたインストールまたはマルチノード・インストールでは、前述のステップをすべてのインストール場所に対して繰り返してください。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

Oracle Identity Governanceに対するJDBC接続プールのチューニング

Oracle Identity Governanceは、Oracle Web Logic ServerにデプロイされているApplicationDBDS、oimOperationsDBおよびoimJMSStoreDSのデータ・ソースを使用します。必要に応じ、各データ・ソースの接続プールの数を大きくします。

JDBC接続プールの容量を増やすには:

WebLogic Server管理コンソールを起動します。
「サービス」→「JDBC」→「データ・ソース」→「データ・ソース名」の順にクリックし、「接続プール」タブをクリックします。
必要に応じて、初期容量と最大容量を調整します。
「非アクティブ接続タイムアウト」パラメータを300に設定します。
「アイドル・プール接続を信頼する秒数」を30に設定します。
変更を保存してアクティブ化します。

ノート:

アプリケーション・サーバーの接続プールでの接続数の増加は、データベース構成の変更による補正が必要です。Oracle DatabaseのMAX SESSIONS設定を増やす必要がある場合があります。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

OIG固有のワーク・マネージャ・プロパティのチューニング

この項では、OIG固有のワーク・マネージャのいくつかのチューニング・オプションについて説明します。デフォルトでは、ワーク・マネージャは本番データベースのために最適化されていません。これらをチューニングすると、プロセスを優先順位別に使用目的により合致するように構成して、パフォーマンスを向上できます。

表13-3で説明するMaxThreadsConstraint値の使用をお薦めしますが、使用するシステムに最適化された値を表13-3で示す計算方法で決定することもできます。

使用するインストールのワーク・マネージャ別に最適なMaximum Threads Constraintを計算するには、DBAに相談して、次の値を確認します。

OIGデータベースで使用可能なデータベースCPUの数
OIGクラスタ内のノードの数
OIGアクセス・ポリシー・スケジュール済タスク「ユーザー・ポリシーの評価」で使用されるスレッドの数。

これらの値を確認してから、次の値を計算します。

OIGデータベースで使用可能なデータベースCPUの数に8をかけます。結果の数値は、データベース接続の総計です。
データベース接続の数値を、OIGクラスタ内のノードの数で割ります。
表13-3に示す式を使用して、計算した値を次の変数に置き換えます。
- d = データベース接続の総数
- n = OIGクラスタ内のノードの数
- t = OIGアクセス・ポリシー・スケジュール済タスク「ユーザー・ポリシーの評価」で使用されるスレッドの数

表13-3 推奨されるOIGワーク・マネージャの最大スレッド制約

ワーク・マネージャ	ロール	最大スレッド制約の推奨値
`OIMMDBWorkManager`	このワーク・マネージャは、ほとんどのOIG Message Driven Beans (MDB)に適用され、監査以外のすべてのオフライン・アクティビティのJMSメッセージをMDB処理する並行スレッドの数を制限します。	Round(1/3[([d-t]/n)-10])
`OIMAuditWorkManager`	このワーク・マネージャは、監査MDBに適用されます。これは、監査に関連したJMSメッセージをMDB処理する並行スレッドの数を制限します。	5
`OIMWorkManager`	このワーク・マネージャは、すべてのOIG Enterprise JavaBeans (EJB)に適用されます。これは基礎となるAPIを実装します。これは、着信APIコールを処理する並行スレッドの数も制限します。	Round(2/3[([d-t]/n)-10])
`OIMUIWorkManager`	このワーク・マネージャは、ユーザー・インタフェースとやりとりされるリクエストを処理するスレッドの数を制限します。	10 (UI同時実効性にもとづく)
`OIMAccessPolicyWorkManager`	N/A	6
`OIMRoleGrantRevokeWorkManager`	N/A	6

次の手順に従って、MaxThreadsConstraint値を変更します。

WebLogic管理コンソールにログインします。
「環境」→「ワーク・マネージャ」の順に進みます。
ワーク・マネージャを選択し、最大スレッド数制約を特定します。
必要に応じて、カウントを変更します。

ワーク・マネージャのチューニング方法の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の「ワーク・マネージャを使用したスケジューリング済作業の最適化」を参照してください。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

アダプタおよびプラグイン構成のリロードの無効化

デフォルトでは、アダプタとログイン構成の再ロードは、開発を容易にするために有効化されています。これらは本番環境では無効化する必要があります。これを行うには:

『Oracle Identity Governanceの管理』の構成ファイルのエクスポートおよびインポートに関する項の説明に従って、MDSから/db/oim-config.xmlファイルをエクスポートします。

oim-config.xmlファイルで、次のコードを置換します:

<ADPClassLoaderConfig adapterReloadingEnabled="true" loadingStyle="ParentFirst" reloadInterval="15" reloadingEnabled="true">

置換後:

<ADPClassLoaderConfig adapterReloadingEnabled="false" loadingStyle="ParentFirst" reloadInterval="15" reloadingEnabled="false">

次を置換します:

<storeConfig reloadingEnabled="true" reloadingInterval="20"/>

置換後:

<storeConfig reloadingEnabled="false" reloadingInterval="20"/>

oim-config.xmlファイルを保存して、MDSにインポートして戻します。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

UNIX用のオープン・ファイル記述子数の変更(オプション)

WebLogicでは、WEBLOGIC_HOME/common/bin/commEnv.shスクリプトでオープン・ファイル記述子の数が1024に制限されています。WebLogicでは同時ユーザー数が多い場合、「TOO MANY OPEN FILES」例外がスローされることがあります。このエラーが発生した場合、スクリプト内の制限値を1024よりも大きい値にすることを検討します。オペレーティング・システムが増加したオープン・ファイル数を処理できることを確認してください。オープン・ファイル・ディスクリプタの数を設定するには、システム要件と仕様のUNIXシステムでのオープン・ファイル制限とプロセス数の設定に関する項を参照してください。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

Solaris Sparc T3またはT4に対するJVMガベージ・コレクションのチューニング

Solaris Sparc T3またはT4でJVMガベージ・コレクションをチューニングするには:

テキスト・エディタで、DOMAIN_HOME/bin/ディレクトリにあるsetSOADomainEnv.shまたはsetSOADomainEnv.cmdファイルを開きます。
USER_MEM_ARGSの値を次のように設定します。
ノート:

USER_MEM_ARGSの値は例として示しています。この値は必要に応じて変更できます。
```
USER_MEM_ARGS="-Xms3048m -Xmx3048m -Xmn1648m -Xss256k -XX:PermSize=384m -XX:MaxPermSize=384m"
```

JAVA_OPTIONSの値を次のように設定します。

ノート:

JAVA_OPTIONSの値は例として示しています。この値は必要に応じて変更できます。

JAVA_OPTIONS="-Xnoclassgc -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90
 -XX:PermSize=350m -XX:MaxPermSize=350m -XX:+AggressiveOpts
 -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:+PrintGCDetails
 -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps  -XX:ReservedCodeCacheSize=64m
 -XX:CICompilerCount=8 -XX:+AlwaysPreTouch -XX:+PrintReferenceGC
 -XX:+ParallelRefProcEnabled -XX:-UseAdaptiveSizePolicy
 -XX:+PrintAdaptiveSizePolicy -XX:+DisableExplicitGC"

ファイルを保存して閉じます。

親トピック: Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング

Oracle Identity Governanceに対するデータベース・パラメータのチューニング

この項では、構成のサンプルを1つ示し、Oracle Identity Governanceに対する Oracle Databaseのチューニングに関する原則の概要を説明します。データベースのチューニングに関する一般的な情報については、「データベース・パラメータのチューニング」を参照してください。

Oracle Identity Governanceには、多数の構成オプションがあります。ボトルネックを特定し、パフォーマンスを最適化する最善の方法は、本番環境のキーとなるデータベース・パフォーマンスを監視し、必要に応じて構成を調整していくことです。「Oracle Identity Governanceのパフォーマンスの監視」で説明した監視タスクを確認した後、この項のガイドラインを使用して、初期のベースライン・データベース構成を選択できます。

ノート:

Oracle Identity Governanceを使用する場合、ベースライン・データベース・チューニング・パラメータを維持することは重要です。Oracle Databaseインスタンス・パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド11gリリース1 (11.1)』を参照してください。

インスタンス構成パラメータのサンプル
物理データの配置
enq: HW - contentionの解決
競合するプロセスが同じ表への挿入を行い、表の最高水位標を同時に増加させようとすると、最高水位エンキュー競合(enq:HW - contention)イベントが発生します。

親トピック: チューニングに関する基本的な考慮事項

インスタンス構成パラメータのサンプル

表13-4に、パフォーマンスに関連するいくつかの重要なデータベース初期化パラメータに関する情報を示します。

SGA、PGAサイズは、一部のプラットフォームでは、基礎となるオペレーティング・システムの使用可能な最大メモリーの制限によって制限されます。サポート・ノート: Oracle Databaseサーバーとオペレーティング・システムのメモリー制限[ID 269495.1]を参照してください。

ノート:

表13-4に示すデータベース・インスタンス・パラメータに対しては、Oracle Databaseのリリースに基づいて、メモリー管理アプローチを使用してください。

Oracle Database 10g以降で使用できる自動共有メモリー管理(ASMM)を使用し、SGA_TARGETおよびSGA_MAX_SIZEパラメータを指定してSGAコンポーネントを管理できます。PGAは、PGA_AGGREGATE_TARGETを通じて個別に管理されます。

次の接続プール要件および外部プログラムに対する追加接続に対応するように、プロセス・パラメータを設定する必要があります。

アプリケーション・サーバーで構成されたXAデータ・ソースの接続プール・サイズ
アプリケーション・サーバーで構成された非XAデータ・ソースの接続プール・サイズ
xlconfig.xmlで構成されたダイレクト・データベース接続プール・サイズ

表13-4 構成パラメータのサンプル

パラメータ	Oracle Databaseの推奨初期設定
`db_keep_cache_size`	800M
`cursor_sharing`	FORCE
`open_cursors`	800
`session_cached_cursors`	800
`query_rewrite_integrity`	TRUSTED
`query_rewrite_enabled`	TRUE
`processes`	接続プール設定に基づく
`MAX_DISPATCHERS`	0
`MAX_SHARED_SERVERS`	0
`distributed_lock_timeout`	1400
`filesystemio_options`	SETALL
`sga_target`	6GB
`pga_aggregate_target`	2GB

親トピック: Oracle Identity Governanceに対するデータベース・パラメータのチューニング

物理データの配置

Oracle Identity Governanceの基本インストールでは、OIGデータベース・オブジェクトを格納するために次の3つの物理表領域を使用します。

データ表領域: 表のデータ、索引およびその他のオブジェクトを格納します。
LOB表領域: OIGオーケストレーションのLOBデータを格納します。
アーカイブ表領域: リアルタイム・パージ機能に対応するOIGエンティティのOOTBアーカイブ表を格納します。

ヒント:

使用ディスク領域を最小限にするために、次のようにすることをお薦めします。

デプロイメントの最初の起動フェーズでは、Oracle Identity Governanceの表領域は、Oracle Identity Governanceにリコンサイルされる10万ユーザーごとに20Gの割合で増加すると予測されます。同じユーザーに対して、LOB表領域はOracle Identity Governanceの主要な表領域のサイズの約30%増加します。Oracle Identity Governanceでの編成の使用はLOB表領域の増加に影響するため、広範囲に編成が使用されるというシナリオでは、これに応じて、LOB表領域は主要な表領域の60% - 100%の割合で増加する可能性があります。

ディスク領域を効率的に管理するために、データベース管理者は、実際のシステムで正確な増加率をモニタリングする必要があります。

パフォーマンスを向上させるため、ローカルで管理する複数の表領域を作成し、各カテゴリのデータベース・オブジェクトを専用の表領域に格納してください。ストレージを最適化することは、効率的なデータ・アクセスに役立ちます。次の項では、頻繁にアクセスが行われ増大する可能性がある表について説明します。これらの表を独自の専用表領域に配置することをお薦めします。

一般的なOracle Identity Governanceデプロイメントでは、通常、次の項で説明されている表は増大し、頻繁にアクセスが行われます。また、パフォーマンス・メトリックを使用して、頻繁にアクセスする表(ホット表)を特定できます。I/O競合を削減するため、ホット表を専用の表領域に移動します。

ノート:

Oracle Identity Governanceは、リアルタイム・オンライン・モードとコマンド行モードの両方でアーカイブおよびパージ・ソリューションを提供し、増加するデータをこれらの表の大部分に格納します。詳細は、「アーカイブおよびパージ・ユーティリティを使用したデータ増加の制御」のアーカイブ・ユーティリティの使用に関する説明を参照してください。

親トピック: Oracle Identity Governanceに対するデータベース・パラメータのチューニング

タスクの表

Oracle Identity Governanceでは、プロビジョニングおよび承認タスクの詳細が次の表に格納されます。これらは、時間の経過とともに増大する可能性が高い表です。これらを1つ以上の専用表領域にグループ化することをお薦めします。

親トピック: 物理データの配置

リコンシリエーション表

Oracle Identity Governanceのリコンシリエーション・スキーマには、静的表と動的表の両方があります。静的表のリストを次に示します。動的表は、RECON_TABLES表のRECON_TABLE_NAME列を問い合せることで識別できます。

RECON_ACCOUNT_OLDSTATE
RECON_BATCHES
RECON_CHILD_MATCH
RECON_EVENTS
RECON_EVENT_ASSIGNMENT
RECON_EXCEPTIONS
RECON_HISTORY
RECON_JOBS
RECON_TABLES
RECON_UGP_OLDSTATE
RECON_USER_OLDSTATE
RECON_ACCOUNT_MATCH
RECON_ORG_MATCH
RECON_ROLE_HIERARCHY_MATCH
RECON_ROLE_MATCH
RECON_ROLE_MEMBER_MATCH
RECON_USER_MATCH
RA_LDAPUSER
RA_MLS_LDAPUSER
RA_LDAPROLE
RA_MLS_LDAPROLE
RA_LDAPROLEMEMBERSHIP
RA_LDAPROLEHIERARCHY

使用する環境で大量のリコンシリエーション・データが生成される場合は、これらの表を1つ以上の専用表領域に移動してください。

親トピック: 物理データの配置

OIG編成LOB表

アーカイブおよびパージ・ユーティリティを使用すると、編成表のデータの増加を制御できます。詳細は、『Oracle Identity Governanceの管理』のアーカイブおよびパージ・ユーティリティを使用したデータ増加の制御に関する項を参照してください。

親トピック: 物理データの配置

監査表

Oracle Identity Governanceでは、監査レベル設定に基づいてトランザクションが監査されます。ほとんどの監査レベルで、データが大幅に増大する可能性があります。監査表を独自の表領域に格納することをお薦めします。Oracle Identity Governanceの監査表には、2つのカテゴリがあります。XML形式で監査データを格納する表を次に示します。このリストで、特にUPA表が増大することが予想されるため、これを専用の表領域に配置することが重要です。

ユーザー・プロファイル監査データは、次のフラット構造の表に格納されます。これらの表は、コンプライアンス・レポート作成のために、Oracle Identity Governance履歴レポートで使用されます。これらの表およびその索引を、専用の表領域に格納することをお薦めします。

UPA_FIELDS
UPA_GRP_MEMBERSHIP
UPA_RESOURCE
UPA_USR
UPA_UD_FORMS
UPA_UD_FORMFIELDS

アーカイブおよびパージ・ユーティリティを使用すると、監査(UPA)表のデータの増加を制御できます。詳細は、Oracle Fusion Middleware Oracle Identity Governanceシステム管理者ガイドのアーカイブおよびパージ・ユーティリティを使用したデータ増加の制御に関する項を参照してください。

親トピック: 物理データの配置

REDOログ・ファイル

Oracle Identity Governanceで構成されたリコンシリエーション・プロセスによっては、リコンシリエーション中のデータベース・トランザクションおよびコミットの量が多くなる場合があります。複数のREDOログ・ファイルを使用することをお薦めします。REDOログ・ファイルに割り当てる総領域は、1 - 2GBにする必要があります。

推奨事項:

REDOログ・メンバーを持つ3つ以上のREDOログ・グループを使用します。
各REDOログ・メンバーの初期サイズ1GBで開始し、競合や頻繁なログ切替えが行われていないか、REDOログを継続的にモニターします。
メンバーの多重化と正確な数および各メンバーのディスク領域は、障害に対する計画に従って検討できます。
結果に基づいて、サイズを調整するか、REDOログ・ファイルをさらに追加します。

親トピック: 物理データの配置

プールの変更の保存

Oracle Identity Governanceのデフォルトでは、頻繁に参照される小さい表は、プール保存バッファを使用してデータベースにキャッシュされるように割り当てられます。表13-4のdb_keep_cache_sizeを参照してください。使用するインストールのユーザーが50,000より多い場合、プール保存バッファではなく、USRおよびPCQ表にデフォルトのバッファを使用することをお薦めします。次のコマンドを使用して、デフォルトのバッファ・プールにこれらの表を格納できます。

ALTER TABLE USR STORAGE(buffer_pool default);
ALTER TABLE PCQ STORAGE(buffer_pool default);

親トピック: 物理データの配置

enq: HW - contentionの解決

競合するプロセスが同じ表への挿入を行い、表の最高水位標を同時に増加させようとすると、最高水位エンキュー競合(enq:HW - contention)イベントが発生します。

OIGデータベースでは、この問題は、ラージ・オブジェクト(LOB)列がある表で発生します。負荷が高くなると、これらの表のLOBセグメントでは競合が発生し、AWRレポートで待機イベントのenq: HW - contentionとして表示されます。

OracleデータベースにおけるLOBのデフォルト記憶域はBasicFileです。頻繁にエクステントを割り当てたりチャンクを再利用すると、LOBセグメントの最高水位標で競合が発生する場合があります。また、ASSMが管理するLOBセグメントでこの競合が発生する場合があります。領域割当てでは一度に1つのブロックのみ取得するからです。

LOB記憶域をBasicFileからSecureFileに切り替えることで、この競合を解消できます。SecureFileは、従来のBasicFileに比べてパフォーマンス上の利点があるLOB記憶域アーキテクチャです。これらの2つのアーキテクチャの詳細は、『データベースSecureFilesおよびラージ・オブジェクト開発者ガイド』のLOB記憶域に関する項を参照してください。

OIGデータベースでenq: HW – contentionイベントが発生した場合は、次のデータベース・イベントを設定して、LOB記憶域をSecureFileに移行することで解決できます。

ALTER SYSTEM SET EVENT='44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024' scope=spfile;

ノート:

この修正は、証明時にSOA関連SQLに対するenq: HW – contentionイベントが表示される場合にのみ適用してください。これは、競合問題の解決の詳細が示されている「BasicFileからSecureFileへの移行(enq:HW - contention)」に似ています。

親トピック: Oracle Identity Governanceに対するデータベース・パラメータのチューニング

Oracle Internet Directoryのチューニング

Oracle Identity Governanceが最適なレベルで実行されるようにするには、「Oracle Internet Directoryのパフォーマンス・チューニング」の説明に従って、Oracle Internet Directoryをチューニングすることが重要です。

親トピック: チューニングに関する基本的な考慮事項

ユーザー・インタフェースに対するアプリケーション・モジュール(AM)のチューニング

AMプールのチューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「アプリケーション・モジュール・プーリング」を参照してください。

ノート:

推奨設定では、ノードごとの同時ユーザー数100を想定しています。同時ユーザーの数が異なる場合、次の式を使用して、Djbo.ampool.maxavailablesizeを変更します。

Djbo.ampool.maxavailablesize = # of concurrent users + 20%

親トピック: チューニングに関する基本的な考慮事項

JMSのチューニング

「メッセージ・バッファ・サイズ」および「最大メッセージ」プロパティのデフォルト値(-1)を変更することをお薦めします。「メッセージ・バッファ・サイズ」を1 GB (1073741824バイト)、「最大メッセージ」を1000000にそれぞれ設定します。

これらのプロパティは、WebLogic Server管理コンソールに移動して変更します。

メッセージ・バッファ・サイズ:
「サービス」→「メッセージング」→「JMSサーバー」→「JRFWSAsyncJmsServer_auto_*」。
最大メッセージ数:
「サービス」→「メッセージング」→「JMSサーバー」→「JRFWSAsyncJmsServer_auto_*」→「しきい値と割当」。

親トピック: チューニングに関する基本的な考慮事項

チューニングに関する高度な考慮事項

この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってOracle Identity Governanceのパフォーマンスが向上するかどうかを判断してください。

親トピック: Oracle Identity Governanceのパフォーマンス・チューニング

リコンシリエーション・チューニング

3つの個別のプロセス・ステージまたは機能モジュールがエンドツーエンドのリコンシリエーション・フローの実行中に適用されます。個別に最適化して相互に関連してパフォーマンスの最適化を実現できる必要がある3つの機能モジュールまたはステージは次のとおりです。

ターゲット・システムおよびコネクタ

コネクタは、ターゲット・システムからデータをフェッチし、リコンシリエーションのイベント作成APIを起動してOIGデータベース・スキーマのリコンシリエーション・ステージング表のイベントおよびイベント・データを作成します。
OIGリコンシリエーション・エンジン

OIGリコンシリエーション・エンジンは、ステージング表からデータを抽出し、OIGにリコンサイルします。プロセスには、ルールに基づく検証、データの照合およびアクションの実行が含まれます。エンジンは、データベースのバルク収集メカニズムを使用して、前述のすべての処理を一括で実行します。
リコンシリエーションのOracle Identity Governanceの後処理

リコンシリエーション・エンジンがターゲットからの受信データの処理を完了した後に後処理ステージが開始されます。このステージの実行中に、OIGカーネル編成がトリガーされ、ポリシー、ロールの割当て、リソース・プロビジョニング、監査処理などに従ってデフォルトのパスワード生成のような機能を実行するためにイベント・ハンドラが実行されます。

この項には次のトピックが含まれます:

親トピック: チューニングに関する高度な考慮事項

ターゲット・システムおよびコネクタ・チューニング

この項では、ターゲット・システムおよびOracle Identity Governanceコネクタに適用する必要があるチューニングについて説明します。

Oracle Internet Directory

リコンシリエーションの実行中に、ターゲット・システム・レコードのすべての変更内容がOracle Identity Governanceにリコンサイルされます。リコンサイルされるレコード数によっては、このプロセスに長い時間がかかる場合があります。また、リコンシリエーション中に接続が中断すると、プロセスの完了にはさらに時間がかかります。パフォーマンスを最適化するために「ページングされたリコンシリエーション」を構成することをお薦めします。

ページングされたリコンシリエーションを構成するには、ユーザー・リコンシリエーションのスケジュール済タスクのPageSize属性に値を指定する必要があります。PageSizeのデフォルト値100は、ほとんどのシナリオに適しています。

ノート:

OID LDAPサーバー(この場合はターゲット・システム) v10.1.4以上のバージョンは、ページングされたリコンシリエーション関連のLDAP操作をサポートします。

SAP

リコンシリエーション・バッチ・サイズ100を使用することをお薦めします。

Active Directory (11.1.1.5.0および11.1.1.6.0コネクタ)

パフォーマンス向上パッチ
- Active Directory 11.1.1.5.0を使用している場合、パッチ# 15916848が適用されていることを確認してください。パッチはMy Oracle Supportからダウンロードできます。パッチ適用手順は、パッチに付属しているReadmeを参照してください。
- Active Directory 11.1.1.6.0を使用している場合、My Oracle Supportからパッチ# 15916848をダウンロードしてください。デプロイメント・マネージャを使用して、パッチの一部として用意されているReconAttributeMap.xmlのみインポートします。11.1.1.6.0バージョン自体で更新されるため、パッチで用意されているActiveDirectory.Connector.dllを無視できます。パッチ適用手順は、パッチに付属しているReadmeを参照してください。
イベントの無視APIをスキップするリコンシリエーション・エンジンの構成

デフォルト動作は、コネクタによって戻されるユーザー・レコードごとにリコンシリエーション・イベントを作成するか無視するかを最初に確認します。このプロセスには、OIGデータベースに格納されている値に対してコネクタから受信するユーザーのすべての属性の値を比較することが含まれています。これを無視するには、参照定義Lookup.Configuration.ActiveDirectoryを開き、次のエントリを追加します。
- コード・キー:Ignore Event Disabled
- デコード: true
ノート:

前述の変更を行う前にイベントの無視APIコールを無効にする長所と短所を評価する必要があります。
バッチ処理

バッチ処理がADコネクタで使用される場合、結果セットをソートする必要があります。したがって、リコンサイルされるレコード数を10000未満にする場合にバッチ処理を使用できます。推奨バッチ・サイズは500です。
ページング
- リコンサイルされるレコードの数が10000を超える場合、Lookup.Configuration.ActiveDirectoryおよびLookup.Configuration.ActiveDirectory.Trustedに存在するPage Size Configurationプロパティを使用します。
- ページングを使用するよう構成する場合、スケジュール済タスク・パラメータBatch Size、Batch Start、Number of Batches、Sort ByおよびSort Directionに値が指定されていないことを確認する必要があります。
- ページングによって、問合せの結果セット全体が小さなサブセット(ページ)に分割されます。通常、単純な検索ではこの値を最大ページ・サイズに設定することをお薦めします。ページ・サイズを最大値に設定することで、各ページを取得するためにネットワーク上で往復する回数を最小限に抑えることができます。これによって、単純な検索の場合に操作のコストが高くなる傾向があります。PageSizeをターゲット・システムのMaxPageSizeよりも大きな値に指定する場合、Active Directoryサーバーによって無視され、かわりにMaxPageSizeが使用されます。この場合、例外は生成されません。場合によっては、タイムアウトやサーバーの過負荷を回避するために小さいページ・サイズを指定する必要があります。問合せによってはコストが非常に高くなります。したがって、1ページの結果数を制限してこれを避けることができます。Active Directoryコネクタの場合、最適なパフォーマンスにはデフォルト値1000を使用します。
フィルタ

特定のセットのレコードがターゲットから取得される場合、Filtersを使用してSearch Baseの値を指定することをお薦めします。スケジュール済タスクで指定されたフィルタは、LDAP問合せに変換されます。フィルタにより、検索を絞り込み、データの検索および処理をより迅速に実行できます。フィルタの詳細は、Active Directoryコネクタ・ドキュメントを参照してください。
フォレスト・トポロジのリコンシリエーションの場合、完全なフォレストからデータをリコンサイルするためにコネクタを使用できます(グローバル・カタログ・サーバー経由)。または、特定のドメインまたはドメイン・コントローラからデータをリコンサイルするためにコネクタを使用できます。検索ベースとともに最初のオプションを使用するかわりに特定のデータ・センターからデータをリコンサイルするたびに2番目のアプローチを使用することをお薦めします。

たとえば:

DC1、DC2、...DC10といったActive Directoryフォレストの10個のデータ・センターがあると想定します。DC2に存在する組織(tempOrg)からデータをリコンサイルするには、次のアプローチのいずれかを使用します。
1. グローバル・カタログを使用して、検索ベースに組織のDNを指定します。
2. DC2を使用して、検索ベースに組織のDNを指定します。
パフォーマンスを向上するために2番目のアプローチを使用することをお薦めします。

親トピック: リコンシリエーション・チューニング

リコンシリエーション一致ルールのデータベース索引

リコンシリエーションでは、照合アルゴリズムを使用して、変更がリクエストされたユーザー、アカウント、ロールまたは組織がOIGにすでに存在するかどうかが検索されます。照合アルゴリズムでは、OIGの一連の列のデータとターゲット・ステージング表の列のデータが比較されます。一致ルールを含む列がリコンシリエーション・プロファイルに定義され、実行時に定義されます。照合操作のパフォーマンスを改善するためには、照合ルールの列に正しい索引が作成されている必要があります。

適切な索引を識別する推奨方法を示すために、メタデータ・ストア(MDS)リポジトリに存在するサンプルActive Directory (AD)ユーザー・プロファイルを例として取り上げます。この例では、次について説明します。

ノート:

OIG 11gリリース2 (11.1.2.1.0)以上では、可能な場合に索引が自動的に作成されます。次の手順に従ってリコンシリエーション一致ルールに必要なすべての索引を導入することをお薦めします。

信頼できるソース・リコンシリエーションに対する索引の選択

信頼できるソース・リコンシリエーションの一致ルール基準に基づいて索引を選択するには、次のステップを実行する必要があります。

テキスト・エディタでActive Directoryユーザー・プロファイル・ファイルを開きます。診断ダッシュボードに存在するValidate Recon Profileテストを使用するか、EMに存在するValidate Recon Profile MBeanを使用して、Active Directoryユーザー・プロファイルを開くことができます。
ownerMatchingRuleWhereClauseを検索するか、すべてのエンティティのmatchingRuleを検索します。

ownerMatchingRuleWhereClause = (((UPPER(USR.USR_LOGIN)=UPPER(RA_ADUSER7.RECON_USERID5A729570)) OR (UPPER(USR.USR_UDF_OBGUID)=UPPER(RA_ADUSER7.RECON_OBJECTGUID))))

プロファイルの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。

たとえば、前述の例の照合ルールには、次の索引が必要です。

表13-5 索引付けする表の名前および列

表名	索引付けする列
`USR`	`UPPER(USR_LOGIN)`
`USR`	`UPPER(USR.USR_UDF_OBGUID)`
`RA_ADUSER7`	`UPPER(RECON_USERID5A729570)`
`RA_ADUSER7`	`UPPER(RA_ADUSER7.RECON_OBJECTGUID)`

ノート:

照合ルールのUPPERやSUBSTRなどの関数とともに索引を作成することが重要です。表13-5のUPPERはすべての列で使用される関数です。
一部の列および関数がすでに索引付けされている可能性があります。表13-5のUSR表にUPPER(USR_LOGIN)の関数ベースの索引がすでに使用されています。

ターゲット・ソースのリコンシリエーションに対する索引の選択

ターゲット・リソースのリコンシリエーションで照合ルール基準に基づいて索引を選択するには、次のステップを実行する必要があります。

テキスト・エディタでActive Directoryユーザー・プロファイル・ファイルを開きます。診断ダッシュボードに存在するValidate Recon Profileテストを使用するか、EMに存在するValidate Recon profile MBeanを使用して、Active Directoryユーザー・プロファイルを開くことができます。
アカウント検索タグ<matchingruleWhereClause>を検索します。

<matchingruleWhereClause>((UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSER7.RECON_OBJECTGUID))</matchingruleWhereClause>

プロファイルの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。

たとえば、前述の例の照合ルールには、次の索引が必要です。

表13-6 索引付けする表の名前および列

表名	索引付けする列
`UD_ADUSER`	`UD_ADUSER_OBJECTGUID`
`RA_ADUSER7`	`RECON_OBJECTGUID`

ノート:

照合ルールのUPPERやSUBSTRなどの関数とともに索引を作成することが重要です。
一部の列および関数がすでに索引付けされている可能性があります。

複数値データがあるターゲット・ソースのリコンシリエーションに対する索引の選択

複数値データがあるターゲット・リソースのリコンシリエーションで、照合ルール基準に基づいて索引を選択するには、次のステップを実行する必要があります。

テキスト・エディタでActive Directoryユーザー・プロファイル・ファイルを開きます。診断ダッシュボードに存在するValidate Recon Profileテストを使用するか、EMに存在するValidate Recon profile MBeanを使用して、Active Directoryユーザー・プロファイルを開くことができます。
権限について、<childreconeventdata>の下にある<matchingruleWhereClause>タグを検索します。

<matchingruleWhereClause>((UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_UD_ADUSRC.RECON_MEMBEROF))</matchingruleWhereClause>

プロファイルの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。たとえば、前述の例の照合ルールには、次の索引が必要です。

表13-7 索引付けする表の名前および列

表名	索引付けする列
`UD_ADUSRC`	`UD_ADUSRC_GROUPNAME`
`RA_UD_ADUSRC`	`RECON_MEMBEROF`

ノート:

照合ルールのUPPERやSUBSTRなどの関数とともに索引を作成することが重要です。
一部の列および関数がすでに索引付けされている可能性があります。

親トピック: リコンシリエーション・チューニング

リコンシリエーションのOracle Identity Governanceの後処理

表13-8は、リコンシリエーションの後処理中に呼び出される一部の重要な初期状態のイベント・ハンドラを示しています。

表13-8 イベント・ハンドラおよび説明

イベント・ハンドラ	説明
`AccountReconAuditHandler`	アカウント/ターゲット・リコンシリエーションの変更を監査します
`ReconScheduledTaskAccountHandler`	アカウント/ターゲット・リコンシリエーションに関連付けられているワークフローをトリガーします
`ReconScheduledTaskUserHandler`	信頼されたリコンシリエーションに関連付けられているワークフローをトリガーします
`ReconUserDisplayNameHandler`	信頼されたリコンシリエーションのカスタム表示名を生成します
`ReconUserLoginHandler`	リコンシリエーション中にカスタム・ログインを生成します
`ReconUserPasswordHandler`	信頼されたリコンシリエーションのカスタム・パスワードを生成します
`UserCreateLdapPostProcessHandler`	LDAP同期が有効である場合にLDAPのユーザーを作成します
`UserUpdateLdapPostProcessHandler`	LDAP同期が有効である場合にLDAPのユーザーを更新します

WebLogicアプリケーション・サーバーのDMSメトリック・ページの残りの初期状態およびカスタムのイベント・ハンドラを確認できます。次のURLを使用して、DMSメトリック・ページに移動します。

http://<servername>:<port>/dms

このURLでは、portはWebLogic管理サーバー・ポートを示します。ログインするには、WebLogic管理資格証明を使用する必要があります。

DMSメトリック・ページにログインした後、OIG_EventHandlerをクリックして、イベント・ハンドラおよびその処理時間メトリックのリストを表示します。これらのメトリックを使用して、最適化する必要がある可能性があるイベント・ハンドラを識別できます。

親トピック: リコンシリエーション・チューニング

LDAP同期のチューニング

Oracle Identity Governanceのパフォーマンス・チューニングには、次の手順があります。

Oracle Identity Governanceに対する最大接続プールの増加

親トピック: チューニングに関する高度な考慮事項

Oracle Identity Governanceに対する最大接続プールの増加

Oracle Identity Governanceに対する最大接続プールを増やすには:

Oracle Identity System Administrationにログインします。
左ペインで、「構成」の「ITリソース」をクリックします。「ITリソースの管理」ページが新しいウィンドウに表示されます。
「ITリソース・タイプ」リストから「ディレクトリ・サーバー」を選択し、「検索」をクリックします。
ディレクトリ・サーバーITリソースについては、「編集」をクリックします。「ITリソースの詳細およびパラメータの編集」ページが表示されます。
次の構成パラメータの値を500に変更します。
- 初期プール・サイズ: 500
- 最小プール・サイズ: 500
- 最大プール・サイズ: 500
「更新」をクリックします。

親トピック: LDAP同期のチューニング

LDAP同期のバッチ・サイズの増加

LDAP同期のバッチ・サイズを増やすには、LDAP同期のリコンシリエーションに関する、次のスケジュール済ジョブのバッチ・サイズを1000に設定します。

LDAPユーザー作成および更新のリコンシリエーション
LDAPロール作成および更新のリコンシリエーション
LDAPロール階層のリコンシリエーション
LDAPロール・メンバーシップのリコンシリエーション

親トピック: Oracle Identity Governanceに対する最大接続プールの増加

OVDの構成パラメータの設定

Oracle Identity Governanceで、OID用に構成されたOVDとのLDAP同期を有効にする場合、表13-9に示すOVDの構成パラメータを設定する必要があります。

表13-9 OVDの構成パラメータ

名前	パラメータ	値
OVD全般	`リスナー - LDAPエンドポイント`	50
-	`リスナー - LDAP SSLエンドポイント`	50
ユーザー・アダプタ	`最大プール・サイズ`	500
-	`操作タイムアウト`	1500000
-	`最大プール待機`	1000
変更ログ・アダプタ	`最大プール・サイズ`	500
-	操作タイムアウト	1500000

親トピック: Oracle Identity Governanceに対する最大接続プールの増加

OIDの構成パラメータの設定

Oracle Identity Governanceで、OVDやOIDとのLDAP同期を有効にする場合、表13-10に示すOIDの構成パラメータを設定する必要があります。

表13-10 OIDの構成パラメータ

名前	パラメータ	値
DBの最大接続数	`orclmaxcc`	10
プロセス数	`orclserverprocs`	2 - 4
参照プロセスをスキップ	`orclskiprefinsql`	1
LDAP接続タイムアウト	`orclldapconntimeout`	60
MatchDN処理の有効化	`orclmatchdnenabled`	0
エントリ・キャッシュの有効化	`orclcacheenabled`	0

表13-10の属性を変更するには、次の構文を使用します。

ldapmodify -h HOST_NAME -p PORT_NUMBER -D cn=orcladmin -w PASSWORD -v <<EOF
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry

親トピック: Oracle Identity Governanceに対する最大接続プールの増加

Identity Virtualization Library (libOVD)の構成パラメータの設定

Oracle Identity Governanceで、OID用に構成されたIdentity Virtualization Library (libOVD)とのLDAP同期を有効にする場合、表13-11に示すIdentity Virtualization Library (libOVD)の構成パラメータを設定する必要があります。

ノート:

Identity Virtualization Library (libOVD)チューニング・パラメータの構成は、WLSTコマンドを使用して管理できます。

表13-11 Identity Virtualization Library (libOVD)の構成パラメータ

名前	パラメータ	値
ユーザー・アダプタ	`最大プール・サイズ`	500
ユーザー・アダプタ	`操作タイムアウト`	1500000
ユーザー・アダプタ	`最大プール待機`	1000
変更ログ・アダプタ	`最大プール・サイズ`	500
変更ログ・アダプタ	`操作タイムアウト`	1500000

WebLogic ServerおよびJDBCの構成パラメータの設定

Oracle WebLogic ServerおよびJDBCの構成パラメータの設定については、「Oracle Identity Governanceに対するアプリケーション・サーバーのチューニング」を参照してください。

親トピック: Oracle Identity Governanceに対する最大接続プールの増加

低速のSQLをなくすための順序監査メッセージのチューニング

負荷が非常に高い状態で実行されていて、行われる変更より、監査ジョブの処理速度の方が遅いと、処理が蓄積していきます。処理速度を向上させて、監査メッセージの発行タスクの実行中に低速のSQLをなくすには、順序監査メッセージを「いいえ」に設定します。

Sysadmin→「スケジューラ」→監査メッセージの発行→順序監査メッセージ=「いいえ」

ノート:

デフォルト値は常に「True」に設定することをお薦めします。ただし、負荷が大きい間は、蓄積が大量に生じる可能性があります。そのような場合は、順序付けの句をオフにすることが可能です。順序付けの句がオフになっていると、正しくない順序で処理が行われて障害が発生し、aud_jms表の一部の監査エントリが未処理のままになる可能性があります。失敗したエントリは、aud_jmsの失敗したすべての行の、失敗した列を1に更新するジョブで再度処理できます。

親トピック: チューニングに関する高度な考慮事項