エンタープライズ・クラスのどのようなビジネス・アプリケーションにおいても、すべてのシステムに通用するような単純なチューニング方法はありません。この項では、構成のサンプルを1つ示し、Oracle Databaseのチューニングに関する原則の概要を説明します。
Oracle Identity Managerには、多数の構成オプションがあります。ボトルネックを特定し、パフォーマンスを最適化する最善の方法は、本番環境のキーとなるデータベース・パフォーマンスを監視し、必要に応じて構成を調整していくことです。この章では、データベース構成の初期ベースラインを選択する際に役に立つガイドラインを示します。
この章では、次の内容について説明します。
次の構成パラメータ設定のサンプルは、4つのCPU(64ビット)と8または16GBのRAMを備えたサーバーに基づいています。
注意: この表は、次のように使用します。ASMMは、Oracle Database 10gの自動共有メモリー管理機能を意味しています。これにより、様々なサブコンポーネントのメモリーが自動的に分散され、メモリー使用率を最も効果的に高めることができます。 次の接続プール要件および外部プログラムに対する追加接続に対応するように、プロセス・パラメータを設定する必要があります。
|
表2-1 構成パラメータのサンプル
パラメータ | Oracle9i Databaseの推奨初期設定 | Oracle Database 10gの推奨初期設定 |
---|---|---|
|
8192 |
8192 |
|
4GB(ASMMを有効化) |
10GB(ASMMを有効化) |
|
4GB |
10GB |
|
1.2GB |
1.2GB |
|
800M |
800M |
|
15MB |
15MB |
optimizer_mode |
CHOOSE |
CHOOSE |
|
0〜20の間 |
0〜20の間 |
|
FORCE |
FORCE |
|
600 |
800 |
|
600 |
800 |
|
False |
False |
|
TRUE |
TRUE |
|
TRUSTED |
TRUSTED |
|
16 |
16 |
|
2 |
2 |
|
接続プール設定に基づく。 |
接続プール設定に基づく。 |
Oracle Identity Managerの基本インストールでは、データベース・オブジェクトの格納に使用する物理表領域は1つのみです。Oracle Identity Managerのデータベース・オブジェクトは、次のカテゴリのいずれかに属します。
物理表
索引
ラージ・オブジェクト(LOBまたはCLOB)
パフォーマンスを向上させるため、ローカルで管理する複数の表領域を作成し、各カテゴリのデータベース・オブジェクトを専用の表領域に格納してください。これによりストレージが最適化され、データ・アクセスが効率的になります。次のユーザー・プロファイル監査(UPA
)コンポーネント表と索引を、個別の表領域に配置することをお薦めします。
UPA
UPA_FIELDS
UPA_GRP_MEMBERSHIP
UPA_RESOURCE
UPA_USR
これらの表には大量の履歴データを格納でき、履歴レポートで使用できます。
データベース・スキーマには、リコンシリエーション・データのための次の表が含まれます。
RCA
RCB
RCD
RCE
RCH
RCM
RCP
RCU
RPC
使用する環境で大量のリコンシリエーション・データが生成される場合は、これらの表を新たな表領域に移動してください。自動エクステント割当てにはローカル管理の表領域を使用します。
パフォーマンス・メトリックを使用して、頻繁にアクセスする表(ホット表)を特定できます。I/O競合を削減するため、ホット表を専用の表領域に移動します。パフォーマンス・メトリックの詳細は、「データベース・パフォーマンスの監視」を参照してください。
REDOログ・ファイル
Oracle Identity Managerで構成されたリコンシリエーション・プロセスによっては、リコンシリエーション中のデータベース・トランザクションおよびコミットの量が多くなる場合があります。複数REDOログ・ファイルを使用することをお薦めします。REOログ・ファイルに割り当てる総領域は、1〜2GBです。
プールの変更の保存
Oracle Identity Managerでは、USRおよびPCQ表はプール保存バッファを使用してデータベースにキャッシュされるようにデフォルトで割り当てられます(表2-1のdb_keep_cache_sizeを参照)。使用するインストールのユーザーが50,000より多い場合、プール保存バッファではなく、USRおよびPCQ表にデフォルトのバッファを使用することをお薦めします。使用できるコマンドは次のとおりです。
ALTER TABLE USR STORAGE(buffer_pool default);
ALTER TABLE PCQ STORAGE(buffer_pool default);
Oracle Identity Managerでは、シーケンス・オブジェクトを使用して、一意のレコード識別子を生成します。また、ストアド・プロシージャを使用して、特定のデータベース操作を行います。本番のパフォーマンスを最適化するために、シーケンス・オブジェクトおよびストアド・プロシージャをSGAに固定してください。Oracle Identity Managerインストールには、このためにcreate_db_trigger.sql
という名前のスクリプトが付属しています。create_db_trigger.sql
スクリプトは、Oracle Identity Managerデータベース・アカウントSYSADM
用に作成されています。これは、サンプルのOracleログイン・アカウントです。
このスクリプトは、次のインストール・ディレクトリに置かれます。
/installServer/Xellerate/db/oracle
シーケンス・オブジェクトおよびストアド・プロシージャを固定する手順:
SYS
でログインします。
SQL*Plus(Oracleクライアント・ツール)をコマンド・プロンプトで起動し、次のコマンドを入力します。
sqlplus /nolog
Oracleインスタンスに、SYSDBA
ロールを持つSYS
ユーザーとして接続します。
たとえば、次のコマンドを入力します。
CONNECT SYS/sys_password@db_instance AS SYSDBA
このコマンドでは、sys_password
はSYS
ユーザー・アカウントのパスワードであり、db_instance
はデータベース・インスタンスに接続するNet 8サービス名です。
次に例を示します。
CONNECT SYS/sys@xeltest AS SYSDBAConnected.
create_db_trigger.sql
スクリプトをテキスト・エディタで編集し、使用するOracle Identity Managerのデータベース・アカウント名を指定します。
create_db_trigger.sql
で、sysadmへのすべての参照が、使用されるアカウント名に置き換えられます。
たとえば、Oracle Identity Managerデータベース・アカウント名がmyschema
の場合、スクリプトを次のように編集します。
create or replace trigger cache_seq after startup on database beginmyschema.pin_obj; -- pin all sysadm's sequences in shared_poolmyschema.pin_sp; -- pin all commonly executed XELL stored procedures or functionsend;/
create_db_trigger.sql
スクリプトを実行します。
このスクリプトにより、データベースが起動する度に起動されるデータベース・トリガーが作成されます。その後でデータベースのバウンスが行われると、シーケンスおよびストアド・プロシージャは自動的にSGAに固定されます。
OracleインスタンスにSYS
ユーザーで接続した状態で、次のコマンドを入力します。
EXEC database_user
.PIN_OBJ;EXEC database_user.PIN_SP;
このコマンドでは、database_user
はデータベース・アカウントです。
これらのコマンドは、初期スキーマ作成時に1回のみ実行してください。Oracleサーバーのバウンスは必要ありません。
Oracle Identity Managerデータベースのリアルタイム・パフォーマンス・メトリックを監視すると、パフォーマンス・ボトルネックを特定できます。
次のことを定期的に実行してください。
Oracle Database 10gのOracle Enterprise Managerコンソールや自動ワークロード・リポジトリ(AWR)などのパフォーマンス・モニタリング・ツールを使用して、リアルタイムのパフォーマンスを監視します。
完全なスキーマ統計をOracle Identity Manager実装で収集します。
スキーマ統計を定期的に更新すると、コストベース・オプティマイザ(CBO)で最新の統計にアクセスできます。新規ターゲットからの大規模なリコンシリエーションの実行、アーカイブ・リコンシリエーションやアーカイブ・タスクなどの大量なデータ変更イベントで、完全なスキーマまたは表統計を実行することを考慮してください。
これによりCBOは、データの現行の状態に基づく効果的な問合せ実行計画を決定できます。次に、定期的にデータベース統計を収集するSQLコマンドのサンプルを示します。
DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> schema_owner, ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE, DEGREE=>8, OPTIONS=>'GATHER AUTO', NO_INVALIDATE=>FALSE);
Automatic Database Diagnostic Monitor(ADDM)やAutomatic Workload Repository(AWR)レポートのアドバイザ・セクションにある関連推奨事項を参照し、推奨された設定に従ってインスタンス構成パラメータを調整します。