23 Oracle Databaseのチューニング

エンタープライズ・クラスのどのようなビジネス・アプリケーションにおいても、すべてのシステムに通用するような単純なチューニング方法はありません。この項では、構成のサンプルを1つ示し、Oracle Databaseのチューニングに関する原則の概要を説明します。

Oracle Identity Managerには、多数の構成オプションがあります。ボトルネックを特定し、パフォーマンスを最適化する最善の方法は、本番環境のキーとなるデータベース・パフォーマンスを監視し、必要に応じて構成を調整していくことです。この章では、データベース構成の初期ベースラインを選択する際に役に立つガイドラインを示します。

この章の内容は、次のとおりです。

• Oracle Identity Managerデータベースに対するデータベース・ロール/権限の使用

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

• 物理データの配置

• データベース・パフォーマンスの監視

23.1 Oracle Identity Managerデータベースに対するデータベース・ロール/権限の使用

データベース管理者は、ロールを作成して、データベース・アプリケーションの実行に必要なすべての権限を保護アプリケーション・ロールに付与します。それから保護アプリケーション・ロールを他のロールやユーザーに付与できます。アプリケーションは複数の異なるロールを持つことができ、それぞれに異なる権限セットを付与して、ユーザーに応じてアプリケーションの使用時にアクセスできるデータを制限できます。たとえば、パスワード付きのロールを作成し、ロールに付与された権限が不正に使用されるのを防止できます。アプリケーションは起動時に適切なロールが使用可能になるように設計されます。そのため、アプリケーション・ユーザーはアプリケーション・ロールのパスワードを知る必要はありません。

次に示すように、付与または取消しされるものに応じて、付与または取消しが有効になるタイミングは異なります。

• ユーザー、ロールおよびPUBLIC権限へのシステムおよびオブジェクト権限の付与および取消しはすべて、即座に有効になります。

• ユーザー、その他のロールおよびPUBLICへのロールの付与および取消しはすべて、現在のユーザー・セッションが、付与および取消し後にロールを再度有効にするためにSET ROLE文を発行した場合のみ有効になります。

SESSION_ROLESデータ・ディクショナリ・ビューを調べると、どのロールが現在有効であるかを確認できます。

Oracle Identity Managerでは、Oracle Identity Managerスキーマに前提条件となる権限が付与されており、Oracle Identity Managerをインストールする前に必要なオブジェクトを作成できるようにしています。これらの権限の一部は、Oracle Identity Managerのインストール後に取り消して、アプリケーションの要件に応じて後で特定のユーザーに付与できます。

表23-1に、データベース・アプリケーションに必要な権限を示します。

表23-1 データベース・アプリケーションに対するロール付与

ロール名	説明	Oracle Identity Managerに固有の使用方法	取り消された場合
CREATE TABLE	自分のスキーマ内での表の作成、変更および削除を可能にします。	これはリソースの権限付与の一部ですが、リソースの権限付与ではプロシージャを使用して表を作成できないため、これが明示的に必要になります。	ユーザーはプログラムで新しい表を作成できません。 この権限は、Oracle Identity Managerデプロイメントが安定したとき、つまりすべてのコンポーネントおよびコネクタがインポートされ、期待どおりに動作するようになったときに取り消すことができます。これは各コネクタでその独自のスキーマ・オブジェクトが作成されるためです。アーカイブ・ユーティリティはプログラムで表を作成するため、アーカイブ・ユーティリティの初期実行にこの権限が必要になります。
CONNECT	セッションの作成権限を付与します。	ユーザーに対するセッションの作成	これはインストール後にCREATE SESSIONと置換できます。Oracle Identity Managerデプロイメントが安定したとき、つまりすべてのコンポーネントおよびコネクタがインポートされ、期待どおりに動作するようになったときに置換できます。これは、各コネクタでその独自のスキーマ・オブジェクトが作成されるためです。
RESOURCE	そのユーザーに関連付けられたスキーマで特定タイプのスキーマ・オブジェクトの作成、変更および削除を可能にします。このロールは開発者やスキーマ・オブジェクトの作成が必要なその他のユーザーにのみ付与されます。このロールにより、オブジェクト・システムの作成権限のサブセットが付与されます。たとえば、CREATE TABLEシステム権限は付与されますが、CREATE VIEWシステム権限は付与されません。これにより次の権限が付与されます。 CREATE CLUSTER CREATE INDEXTYPE CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE TABLE CREATE TRIGGER CREATE TYPE さらに、このロールによりUNLIMITED TABLESPACEシステム権限が付与され、ユーザーがスキーマ・オブジェクトを作成するすべての表領域でUNLIMITEDの領域使用量割当てが効果的に割り当てられます。	シーケンス、インデックス、プロシージャ、トリガーおよびパッケージの作成	ユーザーはデータベース・オブジェクトを作成できません。SYSユーザーのみこれを行うことができます。Oracle Identity Managerデプロイメントが安定したとき、つまりすべてのコンポーネントおよびコネクタがインポートされ、期待どおりに動作するようになったときにこの権限を取り消すことができます。これは、各コネクタでその独自のスキーマ・オブジェクトが作成されるためです。表領域割当てを正しく指定してください。
CREATE VIEW	ユーザーのスキーマでのビューの作成、変更および削除を可能にします。	Oracle Identity ManagerでのSDP_VISIBLE_V、SDP_REQUIRED_V、SDP_LOOKUPCODE_VおよびSDP_RECURSIVE_Vビューの作成	ユーザーはビューを作成できません。SYSユーザーのみ、これを行うことができます。
DBMS_SHARED_POOL	データベース・オブジェクトを共有プール・メモリーに合わせます。	Oracle Identity Managerで使用されるすべてのプロシージャと機能を共有メモリーで固定するために使用	これはインストール後に取り消せますが、プロシージャや機能によっては明示的に固定されない場合があるため、パフォーマンスに影響を与えることがあります。pin_objプロシージャはOracle Identity Managerに対してのみ作成されます。これはデータベース・オブジェクトを共有メモリーに明示的に固定するために使用されます。このロールを取り消す前に、データベースレベルのトリガーcache_seqが削除されている(作成済みの場合)ことを確認してください。
SYS.DBMS_SYSTEM	XAリソース・マネージャを有効にして権限を設定し、XAリソース・マネージャがOracle databaseとアプリケーション間の相互作用を管理できるようにします。 注意: 各データベース接続は、トランザクション・リソースとしてトランザクション・マネージャとともに追加されます。トランザクション・マネージャは、グローバル・トランザクションに属する各接続に対してXAリソースを取得します。トランザクション・マネージャは開始メソッドを使用してグローバル・トランザクションとリソースを関連付け、終了メソッドを使用してトランザクションとリソースの関連付けを解除します。リソース・マネージャは、開始メソッドの起動と終了メソッドの起動との間に、グローバル・トランザクションをそのデータで実行されるすべての作業に関連付けます。	XAリソースおよびデータベース・トランザクション用	Oracle Databaseバージョン10.2.0.4以降では、これは安全に削除できます。DIST_TXN_SYNCプロシージャを、一般に公開されているDBMS_XAと呼ばれる新しいパッケージに移動することで、これのかわりとなります。そのため、新しいバージョンのOracleではXAクライアントはDBMS_SYSTEMで権限を実行する必要はありません。
SYS.DBMS_FLASHBACK	セルフサービス・リペアを有効にします。表から行を間違って削除した場合、削除された行を元に戻すことができます。	リコンシリエーション中の失敗に対して、これを使用して変更をロール・バックできます。	これは、Oracle Identity Manager 11g リリース 1 (11.1.1)の新しいリコンシリエーション・エンジンでのエラー処理に必要です。
CREATE_MATERIALIZED_VIEW	権限受領者のスキーマでマテリアライズド・ビューを作成します。	OIM_RECON_CHANGES_BY_RES_MVマテリアライズド・ビューの作成	ユーザーはマテリアライズド・ビューを作成できません。SYSユーザーのみ、これを行うことができます。このマテリアライズド・ビューは、レポート目的でのみ必要です。
SELECT ON V$XATRANS SELECT ON PENDING_TRANS$ SELECT ON DBA_2PC_PENDING SELECT ON DBA_PENDING_TRANSACTIONS	XAリソース・マネージャを有効にして権限を設定し、XAリソース・マネージャがOracle databaseとアプリケーション間の相互作用を管理できるようにします。	該当なし	削除はお薦めしません。XAのサポートに必要です。
ADMINISTER DATABASE TRIGGER	データベースレベルのトリガーの作成を可能にします。	Oracle Identity Managerでのddl_triggerという名前のDDLトリガーの作成	ユーザーは新しいDDLトリガーを作成できません。これはスキーマ作成後に削除できます。

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

次の構成パラメータ設定のサンプルは、4つのCPU(64ビット)と8または20GBのRAMを備えたサーバーに基づいています。

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

注意: 表23-2では、ASMMは、Oracle Database 10g以降で使用可能な自動共有メモリー管理機能を意味しています。これにより、さまざまなサブコンポーネントのメモリーが自動的に分散され、メモリー使用率を最も効果的に高めることができます。 次の接続プール要件および外部プログラムに対する追加接続に対応するように、プロセス・パラメータを設定する必要があります。 アプリケーション・サーバーで構成されたXAデータソースの接続プール・サイズ アプリケーション・サーバーで構成された非XAデータソースの接続プール・サイズ xlconfig.xmlで構成されたダイレクト・データベース接続プール・サイズ

表23-2 構成パラメータのサンプル

パラメータ	Oracle Database 11gの推奨初期設定
db_block_size	8192
memory_target	Oracle Database 11gの自動メモリー管理機能を使用して、MEMORY_TARGETおよびMEMORY_MAX_TARGETパラメータでSGAとPGAを一緒に管理できます。 最小値は6 GBです。最大値は次の式で求められます。 MEMORY_TARGET/MEMORY_MAX_TARGET=合計メモリ X 80%または20GBのいずれか大きい方(コンピュータにプライマリ・コンシューマとしてデータベースがあると仮定した場合) MEMORY_TARGETをデータベース・メモリー・コンポーネントの管理用とする場合は、SGA_TARGETとPGA_AGGREGATE_TARGETは割り当てずに0にしておくことができます。
sga_target	Oracle Database 10g以降で使用可能なASMMを使用する場合は、SGA_TARGETおよびSGA_MAX_SIZEパラメータを指定してSGAコンポーネントを管理できます。PGAはPGA_AGGREGATE_TARGETを使用して個別に管理されます。次の2つのメモリー管理方法のいずれかを使用してください。 Oracle Database 11gで使用可能なMEMORY_TARGET Oracle Database 10g以降で使用可能なSGA_TARGET/PGA_AGGREGATE_TARGET Oracle ASMMを使用します。最小値は4 GBです。最大値は次の式で求められます。 SGA_TARGET=合計メモリー X 80% X 60%または16 GB (Oracle Identity Managerデータベースの実行時のメモリー・キャップ全体を20 GBと仮定した場合)。 コンピュータにプライマリ・コンシューマとしてデータベースがあると仮定します。 注意: これらのメモリー・パラメータ値は概算値です。データベース管理者は、メモリー・アドバイザを参照してデータベースを管理および調整することもできます。
sga_max_size	10 GB
pga_aggregate_target	最小値は2 GBです。最大値は次の式で求められます。 PGA_TARGET=合計メモリー X 80% X 40%または4 GBのいずれか大きい方 コンピュータにプライマリ・コンシューマとしてデータベースがあると仮定します。
db_keep_cache_size	800M
log_buffer	15 MB
cursor_sharing	FORCE
open_cursors	2000
session_cached_cursors	800
query_rewrite_integrity	TRUSTED
db_file_multiblock_read_count	16
db_writer_processes	2
processes	接続プール設定に基づく

23.3 物理データの配置

Oracle Identity Managerの基本インストールでは、データベース・オブジェクトの格納に使用する物理表領域は次の2つです。1つは編成関連のLOBデータ用の(oim_lob)、もう1つはその他すべてを格納する(oim)です。Oracle Identity Managerのデータベース・オブジェクトは、次のカテゴリのいずれかに属します。

• 物理表

• 索引

• ラージ・オブジェクト(LOBまたはCLOB)

ヒント: 使用ディスク領域を最小限にするために、次のようにすることをお薦めします。 デプロイメントの最初の起動フェーズでは、Oracle Identity Managerの表領域は、Oracle Identity Managerにリコンサイルされるユーザー100Kごとに20Gの割合で増加すると予測されます。同じユーザーに対して、LOB表領域はOracle Identity Managerの主要な表領域のサイズの約30%増加します。Oracle Identity Managerでの編成の使用はLOB表領域の増加に影響するため、広範囲に編成が使用されるというシナリオでは、これに応じて、LOB表領域は主要な表領域の60% - 100%の割合で増加する可能性があります。 ディスク領域を効率的に管理するために、データベース管理者は、実際のシステムで正確な増加率をモニタリングする必要があります。

パフォーマンスを向上させるため、ローカルで管理する複数の表領域を作成し、各カテゴリのデータベース・オブジェクトを専用の表領域に格納してください。これによりストレージが最適化され、データ・アクセスが効率的になります。次のユーザー・プロファイル監査(UPA)コンポーネント表と索引を、個別の表領域に配置することをお薦めします。

• UPA

• UPA_FIELDS

• UPA_GRP_MEMBERSHIP

• UPA_RESOURCE

• UPA_USR

これらの表には大量の履歴データを格納でき、履歴レポートで使用できます。

データベース・スキーマには、リコンシリエーション・データのための次の表が含まれます。

• RCB

• RCE

• RCH

• RCM

• RCP

• RCU

• RPC

• OSI

• SCH

• OSH

• ORC

• OBI

• OUI

• OIO

使用する環境で大量のリコンシリエーション・データが生成される場合は、これらの表を新たな表領域に移動してください。自動エクステント割当てにはローカル管理の表領域を使用します。

パフォーマンス・メトリックを使用して、頻繁にアクセスする表(ホット表)を特定できます。I/O競合を削減するため、ホット表を専用の表領域に移動します。パフォーマンス・メトリックの詳細は、「データベース・パフォーマンスの監視」を参照してください。

REDOログ・ファイル

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

プールの変更の保存

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

ALTER TABLE USR STORAGE(buffer_pool default);

ALTER TABLE PCQ STORAGE(buffer_pool default);

23.4 データベース・パフォーマンスの監視

Oracle Identity Managerデータベースのリアルタイム・パフォーマンス・メトリックを監視すると、パフォーマンス・ボトルネックを特定できます。

次のことを定期的に実行してください。

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

  
  

  注意: Oracle Enterprise Manager 11g Fusion Middleware Controlを使用して、Oracle Identity Managerを監視できます。これを行うには、次のようにします。 Identity Managementで、Oracle Identity Managerを選択して「ホーム」ページに進みます。「ホーム」ページで、Oracle Identity Managerを監視できます。 「Oracle Identity Manager」メニューからパフォーマンスを選択して、パフォーマンス・メトリックを表示します。

  
  

• Oracle Database Enterprise Manager (EM)を使用してルーチン統計とレポートを収集します。これはOracle Database 11g(標準機能)で使用可能です。

  • ルーチン統計の収集

    ルーチン統計の収集は、自動メンテナンス・タスクによって行われます。これはOracle Database 11gの次のナビゲーション・パスで使用できます。

    Oracle EM→「サーバー」タブ→「問合せオプティマイザ」→オプティマイザ統計の管理→自動メンテナンス・タスク・リンク

  • Oracle Database 11g EMによる統計のレポート要件

    現在収集されている統計の状態をレポートするために、EMには次のナビゲーション・パスにレポート・インタフェースが用意されています。

    Oracle EM→「サーバー」タブ→「問合せオプティマイザ」→オプティマイザ統計の管理→「オブジェクト統計」リンク

    このインタフェースを使用して、失効、欠落またはロック状態のオブジェクトやすでに分析済みのオブジェクトまで、すべてのオブジェクトをレポートできます(スキーマのオブジェクトや選択肢のオブジェクトも含みます)。

• 完全なスキーマ統計をOracle Identity Manager実装で収集します。

  スキーマ統計を定期的に更新すると、コストベース・オプティマイザ(CBO)で最新の統計にアクセスできます。ユーザーやアカウントの一括ロード、新規コネクタのインポート、新規ターゲットからの大規模なリコンシリエーションの実行、アーカイブ・リコンシリエーションやアーカイブ・ユーティリティの使用などの大量なデータ変更イベントでは、完全なスキーマまたは表統計を考慮してください。

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

  
  

  関連項目: ルーチン統計の収集とレポートは、Oracle Database 11gで使用可能な自動メンテナンス・タスクによって実行できます。詳細は、『Oracle Database パフォーマンス・チューニング・ガイド』を参照してください。

  
  

  DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> schema_owner,
    ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,
    DEGREE=>8,
    OPTIONS=>'GATHER AUTO',
    NO_INVALIDATE=>FALSE);
  

• 「自動データベース診断モニター(ADDM)」や「自動ワークロード・リポジトリ」レポートのアドバイザ・セクションにある関連推奨事項を参照し、推奨された設定に従ってインスタンス構成パラメータを調整します。これは特に、新しいコネクタをインポートして、新しいターゲット・システムからの一連のリコンシリエーションを完了した後で、一致ルールに応じた新しい索引の必要性を識別するために必要になります。