リリース12
E05663-01
目次
前へ
次へ
| Oracle Workflow管理者ガイド リリース12 E05663-01 | 目次 | 前へ | 次へ |
この付録では、Oracle Workflowの実行時にパフォーマンス改善のために使用できる概念と技法について説明します。
この付録の内容は、次のとおりです。
Oracle Workflowのパフォーマンスは、複数の要因に依存します。設計したワークフロー・プロセスは、同期プロセス、非同期プロセス、強制同期プロセス、項目属性、メッセージ属性、サブプロセスおよび遅延アクティビティを効果的に使用することにより、パフォーマンスを向上させることができます。また、パーティション化およびパージを使用して、大量のランタイム・データに関連するパフォーマンスの問題を解決することもできます。 さらに、ビジネス・イベント・システムのパフォーマンスを向上させるには、最大キャッシュ・サイズを調整する方法と、カスタムPL/SQLファンクションに静的ファンクション・コールを使用可能にする方法があります。
詳細は、『Oracle Applications Tuning Handbook』、Andy Tremayne/Steve Mayze著（Oracle Press、ISBN 0-07-212549-7）および『Oracle Database概要』を参照してください。
効果的なプロセス設計により、ワークフロー・プロセスのパフォーマンスを向上させることができます。
ワークフロー・プロセスの設計時に、同期プロセスとして実行するか、非同期プロセスとして実行するかまたは強制同期プロセスとして実行するかを決定する必要があります。プロセスの設計は、ワークフロー・エンジンからプロセスを開始したコール元のアプリケーションに制御が戻るまでの所要時間に影響します。
同期: 同期プロセスには、すぐに実行可能なアクティビティのみが含まれます。このため、プロセスは開始から終了まで中断しないで実行されます。ワークフロー・エンジンは、プロセスが完了するまで、コール元のアプリケーションに制御を返しません。同期プロセスの場合、項目属性に書き込まれたプロセスの結果またはデータベースに直接書き込まれたプロセスの結果をすぐにチェックできます。ただし、ユーザーはプロセスが完了するまで待機する必要があります。プロセスの実行に時間がかかる場合、アプリケーションがハングしているように見えます。この場合、プロセスを非同期プロセスに変更する必要があります。
非同期: 非同期プロセスには、フローを中断するアクティビティが含まれます。このため、ワークフロー・エンジンは非同期プロセスの実行を待機します。非同期プロセスを要求するアクティビティには、遅延アクティビティ、応答を必要とする通知、ブロック・アクティビティ、待機アクティビティなどがあります。ワークフロー・エンジンがこれらのアクティビティを検出すると、無期限に待機するのではなく、監査表を適切に設定したうえでコール元のアプリケーションに制御を返します。非同期ワークフロー・プロセスは、再開されるまで未完了の状態になります。プロセスの再開は通常、通知システム、ビジネス・イベント・システムまたはバックグラウンド・エンジンによって行われます。非同期プロセスの場合、ユーザーはプロセスが完了するまで待機する必要がなく、アプリケーションの使用を続行できます。ただし、プロセスの結果は、プロセスが完了するまで確認できません。
強制同期: 強制同期プロセスは、開始から終了まで1つのSQLセッションで完了し、データベース表に対する挿入または更新を実行しません。そのため、強制同期プロセスの実行速度は、通常の同期プロセスよりもかなり速くなります。プロセスの結果は、完了時にすぐに確認できます。ただし、監査証跡は記録されません。強制同期プロセスは、監査証跡を記録する必要がなく、特定の結果をすばやく出力したいときに使用します。強制同期プロセスを作成するには、プロセスの項目キーを#SYNCHに設定し、プロセスを設計するときに一定の制限（通知アクティビティを含めないなど）に従う必要があります。
『Oracle Workflow APIリファレンス』のワークフロー・エンジンの概要の概要に関する項と、同期プロセス、非同期プロセスおよび強制同期プロセスに関する項を参照してください。
項目タイプ属性はグローバル変数として機能し、ワークフロー・プロセス内のすべてのアクティビティから参照または更新できます。 項目属性の数は、作業項目の開始時間に直接影響します。新しい作業項目が作成されると、デフォルトでワークフロー・エンジンによってすべての項目属性のランタイム・コピーが作成されるためです。このため、項目属性の数は最小限に抑える必要があります。
必要な場合は、ワークフロー・エンジンでは必要時にのみ項目属性のランタイム・コピーを作成するように指定して、プロセスのパフォーマンスを向上させることができます。 そのためには、最上位レベルの実行可能プロセス・アクティビティに対して、#ONDEMANDATTRという特殊なアクティビティ属性を定義します。 この場合、ワークフロー・エンジンでは、プロセスにより項目属性の値が設定される場合にのみ、その項目属性のランタイム・コピーが作成されます。 それ以外の場合は、単に設計時ワークフロー定義で項目属性に対して指定されたデフォルト値が参照されます。 『Oracle Workflow開発者ガイド』の#ONDEMANDATTR属性に関する項を参照してください。
項目属性は、次の目的で使用します。
作業項目に関する作業情報を格納します。
メッセージのトークンを置換します。グループの繰り返しなどのために行数が異なるメッセージの場合は、行ごとに項目属性を作成しません。かわりに、「文書」タイプの項目属性およびメッセージ属性を使用して行を結合してください。
関数がデータベースから必要な値をすべて検索できるように、主キーの値を格納します。
アクティビティ属性を動的に設定するための一時プレースホルダとして使用します。たとえば、通知の実行者が実行時までわからない場合は、項目属性を参照して、通知を実行する直前に必要な値をシードすることができます。
項目属性は、静的値（データベースにない値）を参照するため、値を同期する必要はありません（ただし、主キーの値は変わりません）。表内のすべての列を項目属性として実装しないでください。
『Oracle Workflow開発者ガイド』の項目タイプ属性に関する項、および項目タイプまたはアクティビティ属性の定義に関する項を参照してください。
次の項目属性タイプを使用すると、必要な属性の数を減らすことができます。
文書: 属性値は埋込みまたは添付文書です。複雑な構造をインラインで表示したり、通知に添付できます。次の種類の文書を指定できます。
PL/SQL文書: データベースのデータを文字列として表す文書で、PL/SQLプロシージャから生成されます。
PL/SQL CLOB文書: データベースのデータをキャラクタ・ラージ・オブジェクト（CLOB）として表す文書で、PL/SQLプロシージャから生成されます。
PL/SQL BLOB文書: データベースのデータをバイナリ・ラージ・オブジェクト（BLOB）として表す文書で、PL/SQLプロシージャから生成されます。
Oracle Application Frameworkリージョン: 通知メッセージに含めるためのOracle Application FrameworkリージョンのJSPコール。
ロール: 属性値はロールの内部名です。通知メッセージにロール・タイプのメッセージ属性が含まれる場合、属性は自動的にロールの表示名に設定されるため、ロールの内部名と表示名について別々の属性を保守する必要がなくなります。また、Webブラウザから通知を表示する場合は、ロールの表示名がそのロールのEメール・アドレスを示すハイパーテキスト・リンクになります。
『Oracle Workflow開発者ガイド』の属性タイプに関する項を参照してください。
複数の項目属性が作成される場合やワークフローの処理中に複数の項目属性値が設定される場合は、ワークフロー・エンジンAPIのAdd Item AttributeおよびSet Item Attributeの配列（AddItemAttributeArrayとSetItemAttributeArray）を使用します。これらのAPIを使用すると、ワークフロー・エンジンAPIのコール数が大幅に減少し、バッチ処理中のパフォーマンスが大きく向上します。『Oracle Workflow APIリファレンス』のAddItemAttributeArrayに関する項およびSetItemAttributeArrayに関する項を参照してください。
パフォーマンスを向上させるには、メッセージ属性の数を最小限に抑える必要があります。グループの繰り返しなどのために行数が異なるメッセージの場合は、行ごとに項目属性およびメッセージ属性（LINE_INFO1、LINE_INFO2など）を作成しません。かわりに、「文書」タイプの項目属性およびメッセージ属性を使用して行を結合してください。
『Oracle Workflow開発者ガイド』の属性タイプに関する項、送信および応答メッセージ属性に関する項、メッセージ属性の定義に関する項を参照してください。
ワークフロー・プロセスを設計するときに、いくつかのアクティビティを1つのプロセス・アクティビティにまとめて、メイン・プロセス内のサブプロセスとして表すことができます。サブプロセスを適切に使用すると、ワークフロー・ダイアグラムがわかりやすくなり、ワークフローのモニタリングと管理が容易になります。ただし、サブプロセスを使用すると、ワークフロー表に追加のDML操作や追加のステータス情報が格納されます。このため、機能面の利点がない場合は不必要にサブプロセスを使用しないでください。
たとえば、次の「プロセス1」と「プロセス2」は、両方とも「関数1」という関数を実行するため、機能的には同じですが、ワークフロー表に格納されるステータス行の数が異なります。
「プロセス1」には、「開始」アクティビティ、「サブプロセス」アクティビティおよび「終了」アクティビティが含まれます。サブプロセスには、「開始」アクティビティ、「関数1」アクティビティおよび「終了」アクティビティが含まれます。このプロセスでは、7つのステータス行がワークフロー表に格納されます。
サンプル・プロセス1
「プロセス2」には、「開始」アクティビティ、「関数1」アクティビティおよび「終了」アクティビティが含まれます。このプロセスでは、4つのステータス行がワークフロー表に格納されます。
サンプル・プロセス2
「プロセス1」のような設計では、より多くの行がワークフロー表に格納されるため、「プロセス2」の設計よりもワークフローのスループットが遅くなり、ワークフローのランタイム表をより頻繁にパージする必要があります。
注意: このガイドラインは、サブプロセスの使用を禁止するものではありません。すべてのサブプロセスを解除すると、ワークフロー・ダイアグラムがわかりにくくなり、管理しにくくなることがあります。ここでは、サブプロセスを不必要に使用すると、パフォーマンスが低下する可能性があることを説明しています。
『Oracle Workflow開発者ガイド』のプロセス・アクティビティに関する項およびプロセス・アクティビティの作成に関する項を参照してください。
オンライン・ユーザーの応答時間を最も簡単かつ効果的に向上させるには、関数アクティビティを遅延します。完了までに大量の処理リソースや時間が必要になるアクティビティを遅延できます。Oracle Workflowでは、このようなコストの高いアクティビティをバックグラウンド・タスクとして実行する補助エンジンを設定して、ワークフロー・エンジンの負荷とユーザーの応答時間を管理できます。このような場合、コストの高いアクティビティはワークフロー・エンジンによって遅延され、後でバックグラウンド・エンジンによって実行されます。
アクティビティが遅延すると、メインのワークフロー・エンジンは、次に使用可能なアクティビティに進むことができますが、これによりプロセスの別の並列する分岐が発生する可能性があります。実行可能なアクティビティがなくなると、ワークフロー・エンジンはコール元のアプリケーションにすぐに制御を返します。実行時間が短くなるため、ユーザーは処理が実行中であることを意識する必要がありません。
アクティビティを遅延するには、設計時にアクティビティのコストをデフォルトのしきい値コストより高く設定します。しきい値コストはPL/SQLパッケージ変数の1つで、デフォルト値は50/100秒です。遅延しないアクティビティのコストにはすべて、このしきい値より高い値を設定します。
ワークフロー・エンジンがしきい値より高いコストのアクティビティを実行時に検出すると、それらのスレッドを遅延してバックグラウンドに回します。バックグラウンド・エンジンは、そのプロセスを遅延として識別し、実行を続行します。
バックグラウンド・エンジンは、遅延アクティビティの他に、タイムアウトになったアクティビティと停止しているプロセスも処理します。バックグラウンド・エンジンは必要な数だけ実行できます。バックグラウンド・エンジンは、タイムアウトになったアクティビティをチェックし、遅延アクティビティを処理し、停止しているプロセスに対応するためにそれぞれ1つ以上必要です。少なくとも、タイムアウト/遅延アクティビティ用に1つ、停止しているプロセス用に1つは設定する必要があります。
通常、停止しているプロセスをチェックするバックグラウンド・エンジンは、遅延アクティビティを処理するバックグラウンド・エンジンと別個に設定する必要があります。ただし、実行頻度は少なくてもかまいません（通常は、1日に1度以下）。システムの負荷が低いときにバックグラウンド・エンジンを実行して、停止しているプロセスをチェックします。
『Oracle Workflow APIリファレンス』の遅延処理に関する項、『Oracle Workflow開発者ガイド』のアクティビティ・コストに関する項、「バックグラウンドのワークフロー・エンジンの設定」および「エンジンのしきい値の設定」を参照してください。
ワークフロー・エンジンが強制同期プロセス以外のワークフローを実行すると、ステータス情報がランタイム表に格納されます。これらの表に格納されるデータの量は、実行されるワークフローの複雑さと数に応じて増加します。
大量のランタイム・データに関連するパフォーマンスの問題は、次の方法で解決できます。
パーティション化
パージ
大きな表や索引を使用するときの主要な問題を解決するには、パーティションと呼ばれる管理しやすい小さな単位に表を分割（パーティション化）します。パーティション表にアクセスするためにSQL問合せとDML文を変更する必要はありませんが、パーティションを定義すると、DDL文は表または索引全体ではなく、個々のパーティションにアクセスして操作できるようになります。このように、パーティション化により、大きなデータベース・オブジェクトの管理を簡素化できます。また、パーティション化はアプリケーションに対して完全に透過的です。
スクリプトを実行して、ランタイム・ステータス・データを格納する特定のワークフロー表をパーティション化することもできます。パフォーマンス改善のため、このステップを実行することをお薦めします。スクリプトを実行する前に、パーティション化する表をバックアップし、スクリプトの実行に必要な空き領域と時間を確保していることを確認してください。 スクリプト名はwfupartb.sqlで、$FND_TOPのadmin/sqlサブディレクトリに格納されています。「ワークフロー表のパーティション化」を参照してください。
Workflow PURGE APIを使用して、完了作業項目に関する不要なランタイム・データ、作業項目に関連付けられていない不要なランタイム情報、および不要な設計情報を削除できます。このような廃止データをシステムから定期的に削除することで、パフォーマンスが向上します。Workflow PURGE APIは、WF_PURGEというPL/SQLパッケージに定義されています。
ランタイム・データをパージできるかどうかは、項目タイプの維持タイプによって決まります。維持タイプにより、項目タイプのインスタンスごとに維持される実行ステータス情報の期間を制御します。
項目タイプの「維持」を「永続」に設定すると、ランタイム・ステータス情報はプロシージャWF_PURGE.TotalPerm( )をコールして情報を意図的に削除するまで、無期限に保存されます。
項目タイプの「維持」を「一時」に設定した場合は、維持日数（「n」）も指定する必要があります。「一時」項目タイプの各インスタンスの実行ステータス情報は、その完了日以後少なくともn日間は維持されます。n日間維持された後は、WF_PURGE APIのいずれかを使用して項目タイプのランタイム・ステータス情報を削除できます。『Oracle Workflow APIリファレンス』のWF_PURGEに関する項を参照してください。
項目タイプの「維持」を「同期」に設定すると、その項目タイプのインスタンスは、項目キー#SYNCHが指定されたステータスで強制同期プロセスとして実行されます。強制同期プロセスは、単一SQLセッション内で開始および終了し、データベース表に対して挿入または更新を行いません。強制同期プロセスではランタイム・ステータス情報が保持されないため、通常は、「同期」維持タイプのプロセスを削除する必要はありません。ただし、同期モードでプロセスを実行するときに、テストまたはデバッグを目的として一意の項目キーを使用した場合は、プロセス・インスタンスのランタイム・ステータス情報が保持されます。この情報を削除するには、項目タイプを「維持」から「一時」に変更してから、任意のWF_PURGE APIを実行します。実行したら、項目タイプを「一時」から「同期」に戻します。『Oracle Workflow APIリファレンス』の同期プロセス、非同期プロセスおよび強制同期プロセスに関する項を参照してください。
また、特定の項目タイプのランタイム・データを削除する場合は、管理スクリプトwfrmtype.sqlを使用します。このスクリプトを実行すると、削除する項目タイプを有効な値リストから選択するように求めるプロンプトが表示されます。次に、指定した項目タイプに関連したすべてのランタイム・データを削除するか、または指定した項目タイプの完了したアクティビティと項目のランタイム・データのみ削除するかが確認されます。「Wfrmtype.sql」を参照してください。
関連項目
『Oracle Workflow APIリファレンス』のWorkflow PURGE APIに関する項
『Oracle Workflow開発者ガイド』の維持タイプに関する項
ビジネス・イベント・システムでは、サブスクリプション処理中のパフォーマンスを向上させるために、イベント、サブスクリプションおよびエージェントの定義がキャッシュされます。 キャッシュのデフォルトの最大サイズは50レコードです。 必要に応じて最大キャッシュ・サイズを大きくして、ビジネス・イベント・システムにより実行されるデータベース問合せ数を減らしたり、最大キャッシュ・サイズを小さくして、キャッシュに使用されるメモリーの量を減らすことができます。 「ビジネス・イベント・システムの最大キャッシュ・サイズの変更」を参照してください。
ビジネス・イベント・システム内でイベント・データ生成ファンクション、イベント・サブスクリプション・ルール・ファンクション、キュー・ハンドラ・エンキューAPIおよびキュー・ハンドラ・デキューAPIなどのカスタムPL/SQLファンクションを使用する場合、Oracle Workflowではこれらのファンクションのコールにデフォルトで動的SQLが使用されます。 ただし、Oracle Workflowでカスタム・ファンクションを静的にコールできるようにして、パフォーマンスを向上させることができます。 「カスタムPL/SQLファンクションに対する静的ファンクション・コールの有効化」を参照してください。
