ベンダー固有データベースのチューニングに関するガイドライン

ここでは、Oracle と SQL Server のリポジトリデータベースをチューニング際のベンダー固有のガイドラインについていくつか説明します。

現在、開発とデモ用にサポートされているのは、MySQL^TM データベースだけです。

Oracle データベース

ここでは、Oracle リポジトリデータベースをチューニングする際のガイドラインについて説明します。

• Identity Manager アプリケーションは、Oracle データベースの機能やオプションを必要としません。

• Oracle リポジトリデータベースと Identity Manager サービスプロバイダ や Identity Manager を使用する場合、Identity Manager は LOB データ型ではなく LONG データ型をデフォルトで使用するため、オブジェクトテーブルの断片化の問題に遭遇するかもしれません。LONG データ型を使用すると、使用可能スペースに作成できないエクステントスペースの「未割り当て」量が増えることがあります。

  この問題を抑制するには、次の項目を実行します。

  • Object テーブルの EXPORT をダンプし、インポートし直して未割り当てのエクステントスペースを解放します。インポートしたら、データベースを終了して再起動する必要があります。

  • LOB データ型と、Oracle に標準の LOB 実装を提供する DataDirect Technologies の Merant ドライバを使用します。

  • 自動的に空きスペースを管理するローカルマネージメントテーブルスペース (LMT) を使用します。この LMT は、Oracle 8.1.5 で使用できます。

Identity Manager は、SGA サイズ変更、バッファサイズ変更、オープンカーソル、プロセスなどに Oracle の init.ora パラメータ設定を必要としません。

• Identity Manager リポジトリは汎用的なデータベースでありながら、まさにオブジェクトデータベースと言えます。

  Identity Manager テーブルのうち、TASK テーブルセットが最もトランザクション処理の特徴を備えています。LOG と SYSLOG テーブルセットは直列化オブジェクトを格納しないため、これらも例外です。

  テーブルの説明、各テーブルに格納されるオブジェクト型、および各テーブルの一般的なアクセス方式については、「リポジトリテーブルの種類」と「データクラス」を参照してください。

• Oracle データベースにパフォーマンスの問題がある場合は、Identity Manager では比較的効率がよいと思われるクエリーに対して選択されているクエリー計画に問題がないか調べてください。

  たとえば、インデックスが使用可能な場合、Identity Manager はテーブルの完全スキャンが実行されるように設定されています。こういった問題は、自動ワークロードリポジトリ (AWR) レポートにある SQL の buffer gets テーブルによく見られます。この問題は、Enterprise Manager ツールでも表示することができます。

  パフォーマンス問題は、データベーステーブルの統計が不良か紛失した場合によく起こります。この問題を解決すれば、データベースと Identity Manager の両方のパフォーマンスを向上させることができます。

  次の記事は Oracle から入手でき、Oracle のコストベースオプティマイザ (CBO) を調べるのに役立ちます。

  • 『Understanding System Statistics』

  • 『Oracle MetaLink: Note:114671.1: Gathering Statistics for the Cost Based Optimizer』

  • 『Cost Control: Inside the Oracle Optimizer』

  • 最適なクエリー計画を選択するもう一つの方法として、SQL プロファイルを用いた調査も行えます。パフォーマンスの悪い SQL を特定する際には、Enterprise Manager から SQL Advisor を使用してこれらのプロファイルを作成します。

  Oracle 再実行ログに予想外の増加が検出された場合は、手動操作で無限ループに陥っているワークフローがあるかもしれません。ループによってリポジトリが絶えず更新され、その結果 TaskInstance ごとのサイズが大幅に増加してしまいます。ワークフローのエラーは、WF_ACTION_TIMEOUT を不適切に取り扱ったり、ワークフローの途中でブラウザを閉じたりすると起こります。

  問題のあるワークフローを回避するには、本番稼動前に各手動操作のプレビューを行い、次の点を検証します。

  • タイムアウトを設定しているか。

  • 手動操作で用いる動作に、タイムアウトの処理に合った遷移ロジックを作成しているか。

  • TaskInstance に大量のデータがある場合、手動操作に公開変数タグを使用しているか。

  CURSOR_SHARING パラメータ値を EXACT から SIMILAR に変更すると、Identity Manager のパフォーマンスを大幅に向上できることがよくあります。

  Identity Manager は、準備済み文をいくつかの動作 (データベース行の挿入や更新など) に使用することはあっても、これらの文をクエリーに使用することはほぼありません。

  Oracle を使用するとき、この動作によってライブラリキャッシュに問題が生じることがあります。特に、文のバージョンが多数存在するとライブラリキャッシュのラッチに競合が生じることがあります。CURSOR_SHARING を SIMILAR に変更すると、Oracle が SQL 文内のリテラルをバインド変数に置き換えるため、バージョンの数を大幅に減少できます。

  詳細は、「準備済み文」を参照してください。

SQL Server データベース

SQL Server 2000 データベースをリポジトリとして使用している顧客より、並行処理が増加するときに SQL Server の内部で悲観的 (Pessimistic) ロックを使用すること (主にロックエスカレーション) によるデッドロックの問題が SQL Server 2000 に発生するという報告がありました。

これらのデッドロックエラーは、次の形で表示されます。

com.waveset.util.IOException:
  ==> com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 51) 
was deadlocked on lock | communication buffer resources with another 
process and has been chosen as the deadlock victim. Rerun the transaction.

このデッドロック問題を回避または解決するには、次の項目を実行します。

1. SQL Server 2005 データベースを使用します。

2. 次のようにコマンドを初期化して、READ_COMMITTED_SNAPSHOT パラメータを設定します。

   ALTER DATABASE waveset SET READ_COMMITTED_SNAPSHOT ON

   READ_COMMITTED_SNAPSHOT パラメータを有効にすると、次のようになります。

   • SELECT 文の実行中にブロックの原因となりうる競合がなくなります。そのため、SQL Server 内部へのデッドロックの危険性が大幅に減少します。

   • 不確実なデータが読まれなくなります。そのため、SELECT 文が確実なデータの一貫したビューを受信できるようになります。

   READ_COMMITTED_SNAPSHOT パラメータの詳細は、http://msdn2.microsoft.com/en-us/library/ms188277.aspx を参照してください。