Oracle Advanced Pricingインプリメンテーション・マニュアル リリース12 E05612-01

目次

前へ

次へ

最適なパフォーマンス

この付録では次のトピックについて説明します。

• 最適なパフォーマンスの概要
• Oracle Advanced Pricingの設定に関する考慮事項
• クオリファイアの選択性
• クオリファイアの選択性の例
• パフォーマンス改善のためのその他のヒント
• スクリプトによるデータ配布の分析
• 技術的な改善

最適なパフォーマンスの概要

この付録では、実装および設定に関する考慮事項を説明し、Oracle Advanced Pricingのパフォーマンスを改善するための推奨事項を提示します。

Oracle Advanced Pricingは、顧客取引の価格設定に最大限の柔軟性を提供するように設計されています。 E-Businessにおいて、取引は次のような方法で入力されます。

• 消費者がOracle iStoreを使用する。

• 電話セールスの担当者がOracle Telesalesを使用する。

• Oracle Order ManagementでEDI受注を電子的に受信する。

• その他のソースから入力する。

これらのOracle Applicationsは、Oracleリリース11iのAdvanced Pricingと統合されており、取引の価格設定にAdvanced Pricingの価格設定エンジンを使用します。

顧客取引が入力されるたびに、価格設定エンジンが呼び出され、その取引に適用可能な価格設定ルール（クオリファイアと呼ばれる）が検索されます。 これらのルールを使用して、取引の適切な価格設定に必要な価格表、算式、値引、販促など一連の価格設定処理が選択されます。

Advanced Pricingの内部表には非常に多くの使用可能な処理が設定されている場合があるため、E-Businessにおいて高速なパフォーマンスと最大限の柔軟性を同時に提供することは、価格設定エンジンにとって非常に困難な作業です。

価格設定エンジンは、呼出し側アプリケーションがエンジンに価格設定要求を行うたびに、サイクル処理を実行します。 リリース11iの呼出し側アプリケーションには、Oracle iStore、Oracle Order Management、Oracle Contracts、Oracle TeleSales、Oracle Inventory、Oracle Quotingなどがあります。

価格設定エンジンのパフォーマンスは、価格設定要求がエンジンに対して発行されてから価格設定の結果が戻されるまでのサイクル時間に関係します。

価格設定エンジンは、実行されるたびに2種類の処理アクティビティを実行します。 最初に、価格設定エンジンは、ユーザーが作成したクオリファイア・ルールを評価します。 このルールに基づき、価格設定エンジンは、処理中の取引に呼出し側アプリケーションが適用する必要のある、認定された価格設定処理を選択します。 次に、計算エンジンが販売価格の計算に必要な計算を実行します。

次の図は、Oracle Advanced Pricingのエンジンのサイクルを示しています。

Advanced Pricingのエンジンのサイクル

価格設定エンジンのパフォーマンス特性を分析すると、選択可能なレコード数に応じて、選択処理の実行時間が変化することがわかります。 この章では、選択エンジンのパフォーマンスの最適化について説明します。

E-Businessの厳しいパフォーマンス要件を満たすことは、設計における主要な目標です。 この目標を達成するために、Oracle Advanced Pricingの開発では特に価格設定エンジンの製品パフォーマンスの最適化に重点を置いています。

設定の選択や価格設定データの設定を適切に行うことで、Advanced Pricingエンジンのパフォーマンスを大きく向上させることができます。 このため、このマニュアルに記載された実装に関する推奨事項と考慮事項は、ユーザーがOracle Advanced Pricingから最適なパフォーマンスを得られるように配慮されています。

Oracle Advanced Pricingの設定に関する考慮事項

Oracle Advanced Pricingエンジンのパフォーマンスを改善する最善の方法は、価格設定データの設定を分析することです。 不要なクオリファイアを削除し、不要な価格表やモディファイアを無効にすることによって、価格設定エンジンのパフォーマンスを大幅に改善できます。

価格設定データの設定にはデータ配分が含まれており、これによって価格設定エンジンの実行速度が遅くなる場合があります。 最初に、クオリファイアの選択性について説明します。

クオリファイアの選択性

価格設定エンジンでは、取引に適用するクオリファイアを検索するときに、そのクオリファイアが関係している有効な価格表またはモディファイア処理がすべて選択されます。 クオリファイアによって狭い範囲の価格設定処理が識別され、その処理の大部分が取引に適用されるものである場合、そのクオリファイアは選択性が高いといえます。 これに対し、1つのクオリファイアが多数の価格設定処理にリンクされ、その処理の大部分が取引に同時に適用できないものである場合、そのクオリファイアは選択性が低いといえます。

新しい検索オプティマイザは、最新のパフォーマンス機能を備えています。 検索オプティマイザによって、同じモディファイアに添付されている複数のクオリファイアの中で最も選択性の高いクオリファイアにタグを付ける機能が価格設定エンジンに導入されました。 たとえば、2%値引のモディファイアに、「価格表」=「法人」、および「顧客」=「XYZ」という2つのクオリファイアがあるとします。 「価格表」=「法人」は多数のモディファイアに添付されているため、選択性のないクオリファイアです。 これに対し、「顧客」=「XYZ」は出現する頻度が低いため、選択性の高いクオリファイアです。 価格設定エンジンは、選択されたモディファイアについて、まずクオリファイア・グループ内で最も選択性の高いクオリファイアを照合し、次に、選択性の低いクオリファイアを照合します。 検索オプティマイザは、選択性の高いクオリファイアにタグを付ける基準として、クオリファイアの出現回数を使用します。 価格設定エンジンは、「価格表」=「共通価格表」と「価格表」=「顧客固有の価格表」の2つのクオリファイアの選択性を区別できます。

モディファイアにクオリファイアと製品が添付されている場合、価格設定エンジンは、製品よりもクオリファイアを優先します。 たとえば、2%値引のモディファイアに、「価格表」=「法人」というクオリファイアが添付されているとします。 また、同じモディファイアに、「品目」=「ABC」という製品も添付されているとします。 価格設定エンジンは、最初にクオリファイアを照合し、次に製品を照合します。 クオリファイア・グループ内で、少なくとも1つのクオリファイアに選択性があることが必要です。

クオリファイアの選択性が低い場合の影響

クオリファイアの選択性が低い場合は、価格設定エンジンのパフォーマンスが低下します。 選択性の低さによる影響は、価格設定データの配分によって決まります。 クオリファイアの選択性が低い場合は、データ量が多いほど、パフォーマンスが低下します。

クオリファイアの選択性の例

クオリファイアの選択性が高い場合

選択性による影響を示すため、次のビジネス例を使用して、選択性の異なるクオリファイアを使用して価格設定を体系化する方法を説明します。 ここでは、価格設定エンジンのパフォーマンスについて検討します。

クオリファイア・グループには、「顧客名」、「受注タイプ」、「価格表」および「地区」の4つのクオリファイアがあります。 「顧客名」が出現したのは5回です。 したがって、グループ内で最も選択性の高いクオリファイアとして「顧客名」にタグが付けられます。 その他のクオリファイアの選択性は高くありませんが、価格設定エンジンでは選択性の最も高いクオリファイアが最初に検索されるため、パフォーマンスが向上します。 次の表は、選択性の高いクオリファイアを使用する場合の設定を示しています。

履歴レコードが原因で選択性が低い場合

ある会社では、有効日を過ぎたモディファイアと価格表レコードが多数あるため、設定の選択性が低くなっています。 この会社は、数年間にわたって営業しています。 この会社のシステムには複数の価格表と値引レコードが存在し、その多くは有効日を過ぎていますが、履歴を保存するためにシステム内に残っています。 前出の例と同じベースを使用すると、この会社の設定データは次のようになります。

これ以外の区分の「小売」および「その他」についても、同様のデータが保存されているとします。 次に、顧客区分「全て」について検討します。この会社では、長期にわたり多くの異なる値引体系を実施しています。

この例では、クオリファイアの選択性は非常に低く、価格設定エンジンのパフォーマンスを低下させます。 このデータに対して価格設定エンジンを実行すると、最終的に取引に適用するために選択される価格表とモディファイアが1つのみになる場合でも、すべての履歴レコード（有効期間はすでに過ぎている）が準備段階で認定され、続く処理の対象として価格設定エンジンにより選択されることがわかります。 特に、履歴レコードの場合、価格設定エンジンは、呼出し側アプリケーションから渡された外部の価格設定日と各レコードの有効期間を比較して、選択処理を次のステップ（優先を考慮するステップ）に進めるかどうかを判断することが要求されます。 有効日の評価はレコードごとに行われるため、履歴レコードが多数ある場合は、価格設定エンジンのパフォーマンスが低下します。

履歴レコードが原因で選択性が低い場合の改善方法

価格設定エンジンのパフォーマンスは、履歴レコードを適切に処理することで改善できます。 価格設定エンジンのパフォーマンスを改善する最も単純な方法は、履歴レコードをシステムから削除することですが、多くの会社は履歴レコードを保持する必要があります。

Oracle Advanced Pricingには、価格表およびモディファイアのレコードについて、レコードが有効かどうかを価格設定エンジンに伝えるためのフラグが用意されています。 価格設定エンジンでクオリファイアのスキャン処理中にレコードのステータスが判断されるため、無効と設定されたレコードは自動的に除外されて考慮されません。

リリース10.7/11のOracle Advanced Pricingが原因でクオリファイアの選択性が低い場合

Oracle Advanced Pricingでは、リリース10.7やリリース11と比べて、価格設定データの設定がさらに柔軟に行えるようになっています。

リリース10.7とリリース11.0では、価格表が値引の必須クオリファイアであったため、値引を価格表と関連付ける必要がありました。 1つの値引は1つの価格表にしかリンクできなかったため、ユーザーは複数の異なる値引を作成する必要がありました。 そのかわり、価格表を顧客または「受注」受注タイプのいずれかとリンクするか、またはその受注に手動で上書きすることができました。

したがって、リリース10.7と11.0では、使用する値引の種類の数が少ない場合でも、大勢の顧客が多数の値引レコードを持つ可能性がありました。

リリース10.7/11のアップグレードが原因でクオリファイアの選択性が低い場合の改善方法

値引レコードの数を減らし、クオリファイアの特殊性を高めることが、11iの価格設定エンジンのパフォーマンスの最適化に役立ちます。 これらの値引レコードを、11iのできるだけ少数のモディファイア・レコードにマージし、11iのOracle Advanced Pricingを使用して顧客グループと関連付けることを検討してください。

クオリファイアとビジネスの価格設定要件について検証すると、価格設定を、価格表または製品階層のより上位レベルのモディファイアを使用して認定できることが判明する場合があります。 たとえば、グリーティング・カードの販売で、100,000ある品目数に対し、価格は15通りのみであるとします。 このような場合、品目を品目カテゴリにグループ化し、その品目カテゴリをクオリファイアとして使用すると、価格表明細を15件作成するだけで済み、明細を100,000件作成する必要はなくなります。 この結果、価格設定エンジンが価格表明細を検索するパフォーマンスが大きく向上します。 自社のビジネスで、値引のクオリファイアとして価格表が不要な場合、アップグレード・プロセスで作成されたレコードは削除してください。

クオリファイアが制約として使用されているために選択性が低い場合

たとえば、モディファイア・リストの中の200リストに、クオリファイア「価格表」=「法人」のみが設定されている場合、価格設定エンジンはこのクオリファイアを満たすすべてのリストを処理する必要があるため、選択性が低くなります。

クオリファイアが制約として使用されているために選択性が低い場合の改善方法

ビジネスで選択性のないクオリファイアを唯一のクオリファイアとして使用する場合は、リストを結合して、エンジンがスキャンするリストの数を減らすことを検討してください。

冗長なクオリファイア

価格設定エンジンのパフォーマンスは、冗長なクオリファイアを削除することで改善できます。 次に、冗長なクオリファイアの例を示します。

「顧客」=「XYZ」AND「顧客サイト」=「ABC」

このクオリファイアは「顧客」のみの場合よりも限定的ですが、適切な価格表またはモディファイアを選択するには「顧客サイト」のみで十分です。 「顧客」クオリファイアを追加すると、不要な顧客条件の評価が発生します。 このような冗長なクオリファイアを削除することによって、価格設定エンジンのパフォーマンスが最適化されます。

ブラインド・モディファイア

クオリファイアまたは製品が添付されていないモディファイアをブラインド・モディファイアと呼びます。 このようなモディファイアは、すべての要求明細に対して処理されます。 システムで定義されたブラインド・モディファイアが多いほど、エンジンのパフォーマンスは低下します。

製品としてALL_ITEMSを使用する場合

ALL_ITEMSに定義されたモディファイアは、すべての要求明細に対して処理されます。 システムで定義されたALL_ITEMSが多いほど、エンジンのパフォーマンスは低下します。

除外および「NOT=」演算子を使用する場合

価格設定エンジンでは、クオリファイア内の「Not =」演算子および製品階層内の「除外」を評価するための処理時間が必要です。 大量の設定データがあるとき、これらの演算子を実装する場合は注意が必要です。

パフォーマンス改善のためのその他のヒント

処理の改善に役立つ他のヒントは次のとおりです。

1. ビジネス上の要件が特にないかぎり、価格設定で使用する必要がある価格表を必ず渡してください。

2. 複数の価格表明細によって不適格な価格表明細を排除する非互換処理が起動されることがないようにしてください。これによって、不要な選択後の処理の実行を防止できます。

3. ヘッダー・レベルと明細レベルの両方のクオリファイアに同じ属性を使用しないでください。 たとえば、Customer=Joe's Dinerがヘッダー・レベルのクオリファイアである場合、同じ内容を明細レベルのクオリファイアとして再度定義する必要はありません。

スクリプトによるデータ配分の分析

Oracle Advanced Pricingには、データ配分を分析するためのスクリプトが用意されています。 スクリプトは、製品の一部として提供され、$QP_TOP/patch/115/sql/qpperf.sqlに格納されています。パフォーマンスの問題を抱えている顧客は、APPSログインを使用してこのスクリプトをSQL*Plusプロンプトで実行してください。 パフォーマンス・バグを記録した場合は、スクリプトの結果を価格設定チームに提供して検討を依頼してください。 このスクリプトには、顧客がパフォーマンス上の問題を特定するのに役立つヒントが含まれている場合もあります。

また、このスクリプトをコンカレント・プログラムとして実行し、コンカレント要求の出力ファイルでその出力を表示することも可能です。 それには、Oracle Pricingマネージャ職責で「レポート」にナビゲートし、コンカレント・プログラム「診断: パフォーマンス分析」に対する要求を発行します。

注意: スクリプトは変更される場合があるため、オラクル社カスタマ・サポート・センターに問い合せて、最新バージョンのスクリプトかどうか確認してください。

技術的な改善

Oracle Advanced Pricingを実装するときに、価格設定エンジンから最善の応答時間を得るための技術的な方法がいくつかあります。 次の方法は、実装時のアクティビティに関連しています。

属性マッピング

Oracle Advanced Pricingでは、属性マッピングを実行できます。 独自の属性ソースを記述する場合は注意が必要です。 記述したコードは、価格設定エンジンの呼出しごとに実行されます。 コードが簡潔に記述されていないと、価格設定エンジンのパフォーマンスが低下します。

価格設定には、すべての設定属性または有効な価格表やモディファイアのみの属性を取得するためのオプションがあります。 プロファイル「QP: 属性マッピング・オプションのビルド」を有効に設定した場合のみ、パフォーマンスが改善されます。

フェーズおよびイベント

Oracle Advanced Pricingでは、価格設定エンジンの実行を複数のフェーズに細分化し、各フェーズを呼出し側アプリケーションの1つのイベントに関連付けることができます。

受注明細の入力時に値引をフェッチまたは表示する必要がない場合は、イベント・フェーズ・レコードを変更して、値引フェーズを保存時に実行できます。 この方法の場合、エンジンは各明細の入力時に価格表明細を選択し、モディファイアの選択または計算は、保存イベントでモディファイアの選択がサイクル処理されるまで実行しません。 受注の入力時に値引を明細ごとに表示する必要がないユーザーの場合は、この方法によって価格設定エンジンのパフォーマンスを改善できます。

価格設定イベント・フェーズを使用しない場合は、終了日を過去の日付に設定します。 これによって、価格設定エンジンは、価格設定フェーズを起動するイベントの発生時点を選択しません。

一時表領域

Oracle Advanced Pricingは、Oracle Databaseの一時表領域機能を拡張して使用します。 最適なパフォーマンスを得るためには、一時表を適切なサイズに設定することが重要です。 価格設定を行う取引のサイズに応じて、一時表の初期サイズは64〜256KBの間に設定する必要があります。 一時表領域は、ローカル管理として定義する必要があります。

メモリーに関する考慮事項

価格設定エンジンは受注入力処理中に頻繁に呼び出されるため、価格設定パッケージは常にメモリーにロードしておく必要があります。 次の価格設定パッケージをメモリーに保持してください。

• QP_BUILD_SOURCING_PVT

• QP_CALCULATE_PRICE_PUB

• QP_CLEANUP_ADJUSTMENTS_PVT

• QP_CUSTOM

• QP_FORMULA_PRICE_CALC_PVT

• QP_PREQ_GRP

• QP_PREQ_PUB

• QP_RESOLVE_INCOMPATIBILITY_PVT

警告: 共有プール・サイズがシステムの使用状況に基づいて計算されていることを確認してください。

「価格設定の設定」ウィンドウでのパフォーマンス

設定ウィンドウで実施されたパフォーマンスに関連する改善点は、次のとおりです。

• 「価格表」ウィンドウ: 製品ごとの定価の問合せのために、新しい検索ウィンドウが提供されています。

• 「基本契約」ウィンドウ: 新しい検索ウィンドウが提供されています。

• 「モディファイア」ウィンドウ: 顧客名、site_use、ship_toの値リストが提供されています。

  注意: ユーザーが拡張したクオリファイアや価格設定属性の値リストまたは検証機能のパフォーマンスについては、ユーザーの責任になります。 したがって、ユーザー定義の値セット内のWHERE句が適切にチューニングされていることを確認してください。

価格設定非正規化パッチの適用時のパフォーマンス

価格表およびモディファイアのデータが大量にあると、価格設定パッチの適用に5分から1時間かかる場合があります。 既存のデータに対する非正規化スクリプトが含まれています。 非正規化された列は、価格設定エンジンで定価またはモディファイアを選択する場合に重要となります。パフォーマンスを改善するために、大規模な非正規化パッチがパラレル・スレッドで提供されています。

価格設定エンジンのREDOログ

取引の価格設定を行うと、REDOログが大幅に増加します。 最新リリースでは、一時表で削除操作を実行しないため、このREDOは最小限になっています。 REDOを最小限にするパッチを適用済かどうかを、オラクル社カスタマ・サポートに確認してください。

販促要求のパフォーマンス

システムで販促要求を定義すると、パフォーマンスが大幅に低下します。 最新リリースでは、販促要求を事前に照会することによってこの問題が解決されています。 最新のパフォーマンス・パッチを適用済かどうかを、オラクル社カスタマ・サポートに確認してください。

推奨事項の要約

価格設定エンジンは、Oracle8iの一時表を使用するリソース集中型のプロセスです。 価格設定エンジンの文のパフォーマンスは、不正確なCBO設定、メモリー設定、または大量のロード処理によって大きく影響を受けます。 価格設定のパフォーマンスの問題の多くは、データベース・パラメータをチューニングしたり、大量のロード処理の文を修正することによって解決できます。 次の表は、パフォーマンスの問題に関する一般的な原因を説明しています。

「価格設定の設定」ウィンドウ

パフォーマンスに関連する改善点は、次のとおりです。

• 「価格表の設定」ウィンドウには、製品ごとの定価の問合せのために、新しい検索ウィンドウが提供されています。

• 「基本契約」設定ウィンドウには、新しい検索ウィンドウが提供されています。

• 「モディファイア」ウィンドウでは、顧客名、site_use、ship_toの値リストが提供されています。

• 高速検索を行うため、「モディファイアからモディファイア・オーガナイザを呼出し」ウィンドウが提供されています。

  注意: ユーザーが拡張したクオリファイアや価格設定属性の値リストまたは検証機能のパフォーマンスについては、ユーザーの責任になります。 ユーザー定義の値セット内のWHERE句が適切にチューニングされていることを確認してください。

属性マッピングをキャッシュするグローバル・エンジン・フラグ

価格再設定時に、価格設定エンジンは受注ごとに1回ずつ呼び出されます。 受注明細が複数ある場合、build_sourcingは明細ごとに実行されて、受注額や顧客情報などすべての属性が指定されます。 したがって、属性は繰返し指定されます。

価格設定エンジンのグローバル・フラグG_NEW_PRICING_FLAGは、最初の明細で属性が指定されたことを示すために導入されました。このフラグによって、後続のすべての明細で属性を指定する必要がなくなります。 このフラグの初期値は'Y'です。この値が'Y'の場合のみbuild_sourcingが実行されます。 最初にbuild_sourcingが呼び出された後、この値は'N'に設定されるため、後続のbuild_sourcingは不要になります。 価格設定エンジンの呼出しが終了すると、このフラグは'N'にリセットされます。 この実装によって不要な処理が実行されないため、パフォーマンスが向上します。

カスタマイズされた属性を使用する顧客は、このフラグを同じ方法で使用すると、価格設定エンジンの応答時間を短縮できます。 このフラグは、前述のように内部的に設定されます。 開発者は、このフラグの値を使用して、属性の再取得が必要かどうかを判断できます。

フラグ: QP_PREQ_GRP.G_NEW_PRICNG_CALL

値: 'Y'または'N'

受注額のキャッシュの例

PROCEDURE Get_Order_AMT_and_QTY (p_header_id IN NUMBER) IS
     orders_total_amt      NUMBER;
     orders_total_qty      NUMBER;
     returns_total_amt    NUMBER;
     returns_total_qty    NUMBER;
BEGIN

     SELECT SUM(nvl(pricing_quantity,0)*(unit_list_price)),
          SUM(nvl(pricing_quantity,0))
          INTO  orders_total_amt, orders_total_qty
     FROM oe_order_lines
     WHERE header_id = p_header_id
          AND (cancelled_flag = 'N' OR cancelled_flag IS NULL)
          AND (line_category_code <>'RETURN' OR line_category_code IS NULL)
               GROUP BY header_id;
     G_Order_Info.header_id := p_header_id;
     G_Order_Info.order_amount := FND_NUMBER.NUMBER_TO_CANONICAL(NVL(orders_total_amt,0)-NVL(returns_total_amt,0));
     G_Order_Info.order_quantity := FND_NUMBER.NUMBER_TO_CANONICAL(NVL(orders_total_qty,0)-NVL(returns_total_qty,0));
EXCEPTION
     WHEN no_data_found THEN
          OE_DEBUG_PUB.ADD('NO Data Found');
END;

FUNCTION Get_Order_Amount(p_header_id IN NUMBER) RETURN VARCHAR2 IS

BEGIN
     IF qp_preq_grp.g_new_pricing_call = qp_preq_grp.g_no THEN
          RETURN G_Order_Info.order_amount;
     ELSE
          Get_Order_AMT_and_QTY(p_header_id);
          RETURN G_Order_Info.order_amount;
     END IF;
END Get_Order_Amount;

Oracle Applicationsと統合するカスタム・アプリケーション

Oracle Applicationsと統合するすべてのカスタム・アプリケーションは、最新の機能と改善されたパフォーマンスを得るために、QP_PREQ_GRP.PRICE_REQUESTにかわってQP_PREQ_PUB.PRICE_REQUEST APIと統合する必要があります。 詳細は、「Oracle Advanced Pricing との統合」を参照してください。

パフォーマンス・パッチ

価格設定エンジンのパフォーマンスを改善するために、次のパッチが提供されています。 このリスト内のパッチについては、オラクル社カスタマ・サポートに必ず確認してください。

Copyright © 2004, 2007, Oracle.All rights reserved.