Oracle 11i Tuning Advanced

Pricing for Optimal Performance

An Oracle Technical White Paper
October 2001

Tuning Advanced Pricing for Optimal Performance

EXECUTIVE OVERVIEW

Oracle Advanced Pricing is designed to deliver maximum flexibility when pricing

customer transactions. In and e-Business, transactions may be being entered by
consumers using Oracle iStore, by telephone sales personnel using Oracle Telesales, from EDI orders being received electronically into Oracle Order
Management, or from a variety of other sources. The applications mentioned all
integrate with Advanced Pricing in Oracle Release 11i. All depend on the
Advanced Pricing Engine to instantly and correctly price these transactions,
regardless of the complexity of the pricing computations being performed.
Each time a customer transaction is entered, the Pricing Engine component of
Advanced Pricing is called to search through the applicable pricing rules - called
qualifiers - that apply to this transaction, and then to use these rules to select the
correct set of pricing actions including price lists, formulas, discounts, and
promotions that are needed to correctly price the transaction. Potentially, there are
thousand or even tens of thousands of available actions that may have been setup
in Advanced Pricings internal tables, so the task of the Pricing Engine--providing
maximum flexibility while delivering the extremely fast performance demanded by
e-Businesses--is very challenging.
Throughout the development of Advanced Pricing, meeting the demanding
performance requirements of e-Businesses has been a major design goal. To that
end, the software design of the product has been optimized, and the Pricing
Development team is continuously striving to find ways to further improve
product performance, particularly of the pricing engine.
The choices you make when selecting certain settings, or how you elect to set up
your pricing data can substantially improve the performance of the Advanced
Pricing Engine.
The objective of this paper is to share with you our understanding and insights
about these implementation and setup considerations, and to give you specific
recommendations that if followed will improve the performance you receive from
Advanced Pricing.

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 1

SOME TERMINOLOGY

Advanced Pricing utilizes pricing rules, called qualifiers to inform the pricing engine
component of the software when to apply pricing actions to a transaction. There
are several types of pricing actions, including price lists, formulas, and modifiers.
Modifiers include such pricing actions such as giving a discount, promotional
products, coupons, item substitutions, and several others.
The pricing engine cycles each time a calling application makes a pricing request to
the engine. Calling applications in 11i include iStore, Order Management, Oracle
Contracts, and Oracle Tele-sales.

PROCESS FLOW

Advanced Pricing Engine Cycle

Calling Application
Pricing Request
Pricing
Qualifiers
(Rules)

Selection
Engine

Selected
Pricing
Actions

Possible
Pricing
Actions

Calculation
Engine
Qualified?
Effective Now?

Yes

Pricing Result

Figure 1 Pricing Engine Cycle Flow

Pricing Engine performance is the amount of cycle time that elapses between
when the pricing request is submitted to the engine by the calling application, and
when the pricing result is returned to the calling application by the engine.
The pricing engine goes through two types of processing activities each time it
executes. First, the engine runs a selection engine component that evaluates the
qualifier rules users have established, and based on those rules chooses the
qualified pricing actions that the calling application may need to apply the
transaction they were processing when they called the pricing engine. Pricing
actions include price lists, such formulas as may be attached to price lists, and a the
wide variety of modifiers including discounts, promotional free goods, other item

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 2

discounts, accruals, and so forth.

The second activity is the calculation engine. The calculation engine processing
begins when the selection engine has completed the task of selecting the proper
pricing actions to apply to the transactions. The task of the calculation engine is to
perform all necessary calculations needed to compute net selling prices.
Our development teams analysis of the Pricing engines performance
characteristics has revealed that the selection process is subject to more variability
of execution time, because the number of records that may be selected is subject to
much variability. Most of the material in this paper is aimed at improving selection
engine performance.
ADVANCED PRICING SETUP CONSIDERATIONS

The best opportunity for improving Pricing engine performance can be had by
analyzing the pricing data setups that the selection engine must process. In
general, by purging unneeded qualifiers, price lists, and modifiers, you will be
rewarded by improved Pricing Engine performance.
However, there are distributions of data in the pricing data setup that can slow the
Pricing engine execution. In the remainder of this paper we will describe these,
and make recommendations about how to avoid or eliminate them. The first of
these we will deal with is qualifier selectivity.
Qualifier Selectivity

In the process flow topic presented previously, we learned that the selection
component of the Pricing Engine looks at qualifiers to determine which pricing
actions to apply. As the Pricing engine finds qualifiers that apply to a transaction,
it preliminarily selects all price lists or modifier actions that the qualifier pertains to.
When pricing qualifiers are defined in such a manner that the qualifier identifies a
narrow range of pricing actions, the majority of which should be applied to the
transaction, then that qualifier has high selectivity. Conversely, when a single
qualifier is linked to many pricing actions, the majority of which cannot be
simultaneously applied to a transaction, then that qualifier is said to have low
selectivity.
New Search Optimizer was introduced with the latest performance patch. Search
optimizer introduces a mechanism by which pricing engine tags the most selective
qualifier within a group of qualifiers attached to the same modifier. For example
modifier 2% discount has two qualifiers namely Price list = Corporate and
Customer = XYZ. Price List = Corporate is a non-selective qualifier because it is
attached to many modifiers. However Customer = XYZ is a selective qualifier
where its occurrence is very low. Pricing engine will first match the most selective
qualifier within the qualifier group and then only match the less selective qualifiers
for the selected modifier. Search optimizer uses the number of occurrences as a
criterion to tag the selectivity. Hence pricing engine would be intelligent to

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 3

distinguish the selectivity of the qualifier price list = common price list and
price list = customer specific price list.
If a modifier has qualifier as well as the product attached to it then the Pricing
Engine is Qualifier Driven -rather than Product Driven. For example a
modifier 2% discount has a qualifier attached Price list = Corporate and also
has a product attached as Item=ABC. Pricing Engine will match the Qualifier
first and then match the product. Hence it is extremely important that at least one
qualifier is selective within the qualifier group.
Impact of Low Qualifier Selectivity

Low selectivity will have an adverse impact on Pricing engine performance.

Whether the impact will be enough to be deleterious depends on the exact
distribution of the pricing data. The larger the volume of data where qualifier
selectivity is low, the greater the deleterious impact on performance.
Example of High Qualifier Selectivity

To illustrate this, lets look at a business examples involving promotional pricing,

and consider how different pricing setups with high and low qualifier selectivity
might be structured. Then we will look at the Pricing Engine performance
implications of each.
Lets assume a hypothetical company whose customers belong to one of 3 groups:
wholesale, retail, and other. This company normally gives a 2% discount through
out the year, but each quarter it also uses promotional pricing. When the company
is having the promotion, it uses a special price list in lieu of the regular price list
and it also gives promotional discounts that vary depending on the customer class.
When the company is between promotions, it relies on a single price list, called
Corporate and offers one discount of 2%
Here is an example of pricing setup having high qualifier selectivity
Qualifier - Customer Class = Wholesale Effective 2/15/2001 - 3/31/2001
Price List = First Quarter Wholesale Price List 2/15/2001 - 3/31/2001
Modifier = 5% Discount 2/15/2001 - 3/31/2001
in exclusivity group 1
Precedence = 100
Qualifier - Customer Class = Retail Effective 2/15/2001 - 3/31/2001
Price List = First Qtr Retail Price List Effective 2/15/2001 - 3/31/2001
Modifier = 8% Discount
Precedence = 100
Qualifier - Customer Class = Other Effective 2/15/2001 - 3/31/2001

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 4

Price List = First Qtr Other Price List Effective 2/15/2001 - 3/31/2001
Modifier = 3% Discount Effective 2/15/2001 - 3/31/2001
in exclusivity group 1
Precedence = 100
Price List = Corporate Price List 1/01/2001 - 12/31/2001
Modifier = 2% Discount Effective 1/01/2001 - 12/31/2001
in exclusivity group 1
Precedence = 200
In the above example, the pricing engine, when run, would find that a customer
belongs to one of the three classes and then would use the price list and modifier
for that specific class - Retail, Wholesale, or Other. It will also pull in the
Corporate Price List and the- 2 % discount modifier.
Since the price lists are by definition exclusive, and the modifiers have been
assigned to exclusivity group 1, the engine will use precedence to select the price
list and modifier that are qualified by customer class, because customer class is
more specific than customer all.
Performance of the engine using the above setup will be good, because the
qualifiers cause the engine to retrieve price list and modifier records very
selectively. In the cases where Price List is passed by the calling application (for
example Order Management) qualifier will not be used to find the price list but it
will be used only to validate the price list. Hence in such a situation qualifier
selectivity may not impact the list price selection but will only impact Modifiers
selection.
Example of Low Selectivity Due to Historical Records

Now lets take a case to illustrating lowered setup selectivity, where the cause is a
large number of modifier and price list records with effectivity dates in the past.
Lets assume this company has been in business many years, and so has many price
lists and discount records in their system, with many being outside their effectivity
dates but still in the system for historical purposes. Using our hypothetical
company example, the setup data might look like this.
Qualifier - Customer Class = Wholesale Effective 2/15/1991 Price List = First Quarter Wholesale Price List 2/15/2001 - 3/31/2001
= First Quarter Wholesale Price List 2/15/2000 - 3/31/2000
= First Quarter Wholesale Price List 2/15/1999 - 3/31/1999
and so forth back to 1991.
Modifier = 5% Discount 2/15/2001 - 3/31/2001

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 5

= 4% Discount 2/15/2001 - 3/31/2000

= 6.% Discount 2/15/2001 - 3/31/1999
and so forth back to 1991
in exclusivity group 1
Precedence = 100
Lets assume the other classes, Retail and Other, have data that looks largely the
same. Now lets look at customer all, where management has experimented with
many different discount structures over time.
Qualifier Customer All Effective 1/01/2001 - 12/31/2001
Price List = Corporate Price List 1/01/2001 - 12/31/2001
Modifier = 2% Discount Effective 1/01/2001 - 12/31/2001
= 1.8% Discount Effective 1/01/2000 - 06/30/2000
= 1.5% Discount Effective 7/01/2000- 12/31/2001
= 2% Discount Effective 1/01/2001 - 12/31/2001
and so forth back to 1991
in exclusivity group 1.
Precedence = 200
In the previous example, the qualifier selectivity is very low, negatively impacting
pricing engine performance. When the pricing engine executes against this data, it
will find that all the historical records (those with effectivity dates that are already
past) will be preliminarily qualified and selected by the Pricing Engine for further
processing, even though only one price list and modifier will be finally selected to
apply to the transaction. Specifically, for the historical records, the pricing engine
will be forced to compare the exterior pricing date passed to it from the calling
application to the effectivity date range of each record to determine if whether the
selection process should proceed to the next step of considering the precedence.
Since the effectivity date evaluation is a record-by-record process, large number of
historical records will have an adverse impact on Pricing engine performance.
Correcting Low Qualifier Selectivity due to Historical Records

Clearly, an opportunity exists to improve Pricing Engine performance by properly

handling historical records. While the most direct route to improving engine
performance is to eliminate historical records from the system, many companies
have a business process need to retain historical records for a period of time.
Advanced Pricing provides a flag on both price list and modifier records that
informs the engine whether the record is inactive or active. Since the Pricing
Engine checks status of the record as part of the qualifier scan process, records set

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 6

to inactive are automatically excluded from being selected for further

consideration.
Low Qualifier Selectivity Due to Release 10.7/11 Pricing

The predecessor releases of Oracle Applications provided far less flexibility about
how you set up your pricing data. Advanced Pricing is much more flexible,
providing you the capability to define your pricing rules and actions in a more
concise manner than could be done in either Release 10.7 or Release 11.
In Release 10.7 and in Release 11.0, discounts had to be associated to a price list.
Price List was a mandatory qualifier for a discount in R10.7/11. Because
R10.7/R11 system functionality required users to create different discounts
because in that release, one discount could only be linked to one price list. In turn,
price lists could be linked to either the customer or the Order Entry order type, or
they could be manually overridden on the order.
Therefore, in release 10.7 and 11.0, many Oracle customers find themselves with
large numbers of discount records, even when the number of different discrete
discounts in use is low.
Correcting Low Qualifier Selectivity due to Release 10.7/11 Upgrade

Here, as in the previous example, reducing of the number of discount records and
making the qualifiers specific will help you optimize 11i Pricing Engine
Performance. Consider merging these discount records into as few 11i modifier
records as possible, and then using 11i Pricing capability to tie them to customer
groups.
Very likely, if you examine your qualifiers and your business pricing requirement,
you will find you can qualify pricing either through the use of price lists or
modifiers at the higher level of product hierarchy. For example if you are selling
greeting cards and you only have 15 distinct prices but 100,000 items. By grouping
the items together in to item categories, and using item category as the qualifier,
you will have create only 15 price list lines rather than 100,000 lines. This will
result in the Pricing engine searching through price list lines, which will boost
Pricing engine performance measurably.
Also, if there is no business need for a Price list to act as a qualifier to a discount,
you should delete any such records that have been created as part of your upgrade
processing.
Using Qualifiers as Constraints may result into Low Selectivity :

Example: If you have 1000 modifier lists. Out of which 200 lists have Price List =
Corporate as the only qualifier . This results into low selectivity of the qualifier
because Pricing engine will be processing every list which satisfies this qualifier.
Correcting Low selectivity when Qualifiers is used as Constraints:

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 7

If your business requirement is to have a non selective qualifier as the only qualifier
then consider combining these lists so that there will be less number of lists for
engine to scan.
Redundant Qualifiers - Another Enemy of Performance

Performance of the Pricing engine can be boosted by avoiding qualifiers that are
redundant. Here is an example of a redundant qualifier:
Customer = XYZ AND Customer Site =ABC
For purposes of the Pricing engine selecting the proper price list or modifiers,
customer site is sufficiently specific to act as a qualifier, as it is more specific than
customer. Adding customer qualifier causes the Pricing Engine to evaluate the
customer condition unnecessarily. Eliminating such redundant qualifiers will act to
speed the Pricing engine on its way.
Blind Modifiers - Another Enemy of Performance

Modifiers without any qualifier or any product attached. These modifiers are
processed by engine for every request line. Engine performance will be negatively
affected as the more number of blind modifiers get defined in the system.
Use of ALL_ITEMS as a product - Another Enemy of Performance

Modifiers defined for ALL_ITEMS are processed by the engine for every
request line. Engine performance will be negatively affected as more number of
modifiers having ALL_ITEMS get defined in the system.
USE OF EXCLUSIONS AND THE NOT= OPERATOR

Please note that pricing engine will take additional processing time to evaluate
NOT= operator in qualifiers as well as to evaluate EXCLUDE in the product
hierarchy. If you have a very high volume of setup data then it is recommended
that you use caution when implementing these operators.
ANALYZING YOUR DATA DISTRIBUTIONS: A SCRIPT

Pricing provides a script to analyze the data distribution. This script needs to be
run at the SQLPLUS prompt using APPS login and the results need to be provided
to the pricing team in case of any performance bug logged by the customer.
TECHNICAL IMPROVMENTS TO PRICING ENGINE PERFORMANCE

When you implement Advanced Pricing, there are several technical measures that
can be taken to ensure the best response time from the Pricing Engine. These
measures are related to implementation time activities.
Attribute Mapping

New in Release 11i, Advanced Pricing provides the capability to perform attribute

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 8

mapping. A patch is now available (please refer to Appendix 2) that allows you to
use Static Generation for attributes mapping. If in your implementation you are
extending Advanced Pricing by mapping new attributes, then you will want to
apply this patch, as it will give you for faster Pricing performance. Additionally, it
also fixes a known PL/SQL memory issue.
Also, be careful while writing your own attribute sourcing. Please note that the
code you write will be executed for every pricing engine call. if not tightly written,
there will be a negative impact on Pricing Engine performance.
Performance Opportunities with Phases and Events

11i Advanced Pricing provides a configurable capability that allows the pricing
engine execution to be broken up into phases, and allows each phase to be
associated with an event taking place in the calling application. This presents some
implementation time opportunities to improve Pricing engine performance.
If there is no need to fetch or view the discounts at the time of entering the order
lines, then you can modify the event phases records to execute the discounting
phases just at the line save. This approach will cause the engine to perform the
price list line selections as each line is entered, while preventing the engine from
doing the selection or calculation of modifiers until the line save event causes the
modifier selection to cycle. For users not needing to view the discounts line by
line as the ordered is entered, this technique can enhance perceived pricing engine
performance.
Another performance opportunity in the case of unused Pricing Event phases, to
set an end date for an unused phases to a date in the past. The effect of this will
prevent Pricing Engine from attempting selection activity when the event that
triggers the Pricing Phase occurs.
Temporary Tablespace

Advanced Pricing makes extensive use of the temporary tablespace feature of

Oracle 8i. Therefore, proper sizing of temporary tables is very important to
obtaining optimal performance. Depending on the size of the transaction that will
be priced, the initial extent for temporary tables should be sized at between 64K
and 256K and the temporary tablespace should be defined as locally managed.
Memory Considerations:

Since Pricing engine is frequently called during order entry process it is important
that the pricing packages are always loaded into the memory. It is recommended
that you PIN e.g. keep the following Pricing packages in the memory
1. QP_PREQ_GRP
2. QP_BUILD_SOURCING_PVT

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 9

3. QP_resolve_incompatability_PVT
4. QP_FORMULA_PRICE_CALC_PVT
5. QP_Calculate_Price_PUB
6. QP_CUSTOM
IMPORTANT! MAKE SURE THAT YOUR SHARED_POOL SIZE IS
APPROPRIATELY CALCULATED BASED ON THE USE OF THE
SYSTEM.
PERFORMANCE IN THE PRICING SETUP SCREEN

Following performance related improvements in the setup screen have been made:

Price List setup screen: Query List price by product - A new find window has
been provided

Agreements Setup screen - A new find window has been provided

Modifiers Screen - A List of Values Customer Name, site_use, ship_to has

been provided

A word of caution: The user is responsible for the performance of the List of
Values/ validation of the user extended qualifiers/pricing attributes. Hence please
make sure that the where clause in the user defined Value set is properly tuned.
PERFORMANCE IN UPGRADE FROM 10.7/11 TO 11.I

Performance in upgrading the 10.7/11 pricing has been improved by

Providing parallel threads

Providing bifurcation so that the pricelists/modifiers of active orders can be

upgraded first and other data upgrade can be deferred to a later convenient
time.

A Suggestion! Purging the unneeded pricing data prior to the upgrade will
improve the performance of the pricing upgrade as well as improving the
performance of the pricing engine. While purging the data please ensure that the
data integrity of the transaction system is maintained. An approach many
customers have successfully used for accomplishing this is to purge the price list
lines of the obsolete price list and upgrade just the price list header to maintain the
data integrity.
PERFORMANCE IN APPLYING CERTAIN PRICING DE-NORMALIZATION
PATCHES

If you have a very high volume of price list and modifiers data then you may
experience that the certain pricing patches take anywhere from 5 minutes up to an
hour to apply. The reason for this delay is that the patch also includes denormalization script for the existing data. Please do not kill the application of this

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 10

patch. These de-normalized columns are important for the pricing engine to select
the list price or modifiers. Large de-normalization patches have been provided
with parallel threading to improve the performance.
SUMMARY OF RECOMMENDATIONS:

Background: Pricing Engine is a resource intensive process, which uses Oracle 8I

Temporary tables. Performance of Pricing Engine statements are significantly
affected by inaccurate CBO settings, memory settings or any other significant highload process. Many of the pricing performance bugs were resolved by tuning the
database parameters, or correcting other high-load statements. Following table lists
certain common causes of performance issue.
Symptom
1. Performance is slow
and OM debug file is
getting created in the
debug directory

Probable Cause
OM debug or QP debug
is causing very high
pl/sql processing

How to fix it
Make sure that Profile
ONT_DEBUG_LEVEL is set to 0
(metalink Note 130511.1 has a script)
And profile QP:QP_DEBUG is set
to No.
1. Some other non-pricing statement
may be taking a huge amount of
Logical Reads (These high-load
statements would deteriorate Pricing
engine performance). Execute the
following statement to find high-load
sql.
Select sql_text, buffer_gets from
v$sql where buffer_gets in
(select max(buffer_gets) from v$sql);
2. Change db_block_buffers to a
higher number.
3. There may be CPU contention.
Make sure that there are no
runaway processes. Check your
hardware resources.
Check appendix A for Pricing
performance patches

2. Trace File is showing

a big difference between
CPU and Elapsed time

Pricing Engine
Temporary tables are
being thrown out of
memory.

3. Significant amount of
time is spent during
Pricing
4. Trace File is showing
Misses in library cache
during parse

Pricing Performance
patches may not have
been applied
Not enough Shared
Pool

5. Trace file shows huge

volume in the pricing
temporary table
qp_preq_qual_tmp

Qualifiers may be
unselective. Causing
huge number of records
being selected by the
engine

6. Trace File is showing

obj$ and other sys
statements
7. CBO is causing full
table scans

SYS/SYSTEM schema
is analyzed

Increase the value of Shared Pool

parameter.
Pin the frequently used Pricing
Engine packages.
run qpperf.sql to see if there are any
unselective qualifiers. Restructure the
setup either by moving these
qualifiers to Pricing attribute or by
moving the qualifier from line to
header. Use qpperf.sql Stmt # 10,16
do not analyze SYS/SYSTEM
schema.

CBO parameters in
Init.ora may not be set

Use/fnddev/fnd/11.5/admin/sql/A
FCHKCBO.sql to check this).

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 11

8. Excessive calls made

to the pricing engine at
booking and scheduling
9. Form hangs
10. unnecessary Pricing
call is made at Booking

properly.
Pricing may be turned
on at scheduling.
ST patches for
temporary table may not
have been applied
Pricing Event Phase is
active for Book Event

11. Unnecessary
Modifiers are being
fetched with every line

Automatic or Manual
Modifiers are created
without any
qualification.

12. Sales Order

processing slow at
Booking
13. Many obsolete
modifier headers are
being queried by Pricing
Engine
14. Trace file is showing
custom code getting
executed many time as
well as taking huge time

OM performance
patches may not have
been applied
Upgraded obsolete
Pricing data is still
active.

15. Pricing debug screen

is showing unnecessary
qualifiers/ attributes
being passed to the
pricing engine.
16. Many modifiers, price
list lines coming into the
mix in the pricing engine
17. Temporary Table
space growing
significantly. Causing
huge overheads.

Inefficient Extension
/custom code is being
called by Attributes
mapping or by get
custom price. Caching
not implemented in the
custom code
somebody has setup
prototype modifies
using the qualifiers and
attributes which are not
used by the production
application
Excessive use of
ALL_ITEMS product
element
Initial extent of the
Temp table space may
be high. Pricing engine
temp tables are created
with big initial extents.

OM profile OM: Deactivate Pricing

at Scheduling should be set to yes.
check metalink Note 119542.1
Use Pricing Manager responsibility ,
invoke Event-Phase screen, Query
Book event, set the end date to some
prior date.
Analyze the price adjustments data to
check if certain modifiers are selected
for every line and are unnecessary.
Inactivate these modifiers. Use
qpperf.sql Stmt # 17, 27
Check metalink for recommended
performance patches.
Inactivate the obsolete List headers
by unchecking the active flag. Use
qpperf.sql Stmt# 5.
Implement caching, tune the custom
code

Pricing engine will get all the

qualifiers, pricing attributes even if
those are setup for prototype
purpose. If you have setup such
modifiers then inactivate these
modifiers in the production instance.
Too many lines of the same product
element or same qualifier will reduce
the selectivity of the engine. Evaluate
alternate setup.
Change the storage clause of
Temporary table space with a
minimal setting of initial extent.
Change the temporary table space to
be locally managed.

CONCLUSION

This technical white paper has given an overview of the major causes of inadequate
Pricing Engine performance, and has outlined corrective measures. For additional
information on Advanced Pricing, see the Oracle Advanced Pricing Users Guide.

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 12

APPENDIX 1: PERFORMANCE PATCHES (SUBJECT TO CHANGE)

Following patches have been provided to improve the Performance of the Pricing
Engine. You should always check with support for any changes in this list of patches.
Patch #
Pricing
1508982
1806021
2043597

Pack E
X
X

Pack F

Pack G

11i.5

Comments

X
X

Dec 2000 - in 11i.4

May 2001
Oct 2001 - in G

The above table lists the pricing patch numbers. Check mark (X) indicates that the
patch needs to be applied if you are at that patch set level.
Important:! Certain performance patches have been released in the area of Pricing
and OM Integration. These patches are under the product Order Management.
Please check with your support representative to obtain these patches.

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 13

APPENDIX 2: DATA DISTRIBUTION ANALYSIS SCRIPT

Important! This script is subject to change. Always check with Oracle Support to ensure you
have latest version of this script.
column qualifier_context format a10
column qualifier_attribute format a22
column qualifier_attr_value format a15
column qualifier_attr_value_to format a10
column active_flag format a5 head 'ACTIV'
column pricing_phase_id format 99999 heading 'Phase'
column product_attribute format a10 heading 'Prod Type'
column product_attr_value format a10 heading 'Prod
Value'
column pricing_attribute_context format a10 heading 'Pr
Context'
column pricing_attribute format a10 heading 'Pr Attr'
column pricing_attr_value_from format a11 heading 'Pr
Attr Val'
set pages 66
set lines 80
set feed on
ttitle 'Pricing Data Distribution'
spool qp_perf_distr.lis
prompt 'This script is useful for diagnosing the
performance problems'
prompt 'Please refer to the pricing performance
whitepaper on the metalink for more details'
prompt 'Stmt # 1 : Database Parameters'
prompt '==================='
select name, value from v$parameter where name in
('db_block_buffers','db_block_size','shared_pool_size');
prompt 'Stmt # 2 : High-load statement'
prompt '==================='
select buffer_gets, disk_reads , sql_text from v$sql
where
buffer_gets = (select max(buffer_gets) from v$sql);
prompt 'Stmt # 3 : Pricing Engine version'
prompt '==============='
select text from user_source where line=2 and
name='QP_PREQ_GRP';
prompt 'Stmt # 4 : QP_List_Headers'
prompt '==============='
select list_type_code,active_flag, count(*) from
qp_list_headers_b group by
active_flag, list_type_code;
prompt 'Stmt # 5 : Active List Headers Having Expired
Date'
prompt '======================================='
select list_type_code, count(*) from qp_list_headers_b
where active_flag = 'N' and
nvl(end_date_active, sysdate+1) < sysdate
group by list_type_code ;
prompt 'Stmt # 6 : QP_List_Lines'
prompt '============='
prompt 'QP_List_lines - distribution by type, qual,
phase'
select list_line_type_code, qualification_ind ,

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 14

pricing_phase_id ,
count(*) from
qp_list_lines group by list_line_type_code,
qualification_ind,
pricing_phase_id ;
prompt 'Stmt # 7 : QP_PRICING_ATTRIBUTES'
prompt '====================='
prompt 'QP_Pricing_Attributes- grouping by phase '
select pricing_phase_id, count(*) from
qp_pricing_attributes group by pricing_phase_id ;
prompt 'Stmt # 8 : QP_QUALIFIERS'
prompt '============='
prompt 'QP_Qualifiers- Total Count'
prompt '=========================='
SELECT count(*) from qp_qualifiers;
prompt 'Stmt # 9 : QP_Qualifiers- distinct qualifiers '
prompt '==================================='
SELECT qualifier_context, qualifier_attribute, count(*)
from qp_qualifiers
group by qualifier_context, qualifier_attribute;
prompt 'Stmt # 10 : QP_Qualifiers- Highest non-selective
'
prompt '-=================================== '
prompt 'These Qualifiers will lead to performance
problems.'
prompt '================================================= '
select QUALIFIER_CONTEXT,QUALIFIER_ATTRIBUTE,
QUALIFIER_ATTR_VALUE,
QUALIFIER_ATTR_VALUE_TO , count(*) from qp_qualifiers
where active_flag = 'Y' group by
QUALIFIER_CONTEXT,QUALIFIER_ATTRIBUTE,
QUALIFIER_ATTR_VALUE,
QUALIFIER_ATTR_VALUE_TO having count(*) > 50;
prompt 'Stmt # 11 : QP_Qualifiers - customer and
customer_site in the same group'
prompt
'=======================================================
====='
select count(*) from
qp_qualifiers a where
a.qualifier_context='CUSTOMER' and
a.qualifier_attribute='QUALIFIER_ATTRIBUTE2'
and exists
(select 'x' from qp_qualifiers b where b.list_header_id
= a.list_header_id
and nvl(b.list_line_id,1) = nvl(a.list_line_id,1) and
b.qualifier_grouping_no = a.qualifier_grouping_no and
b.qualifier_context = 'CUSTOMER' and
qualifier_attribute=
'QUALIFIER_ATTRIBUTE5');
prompt 'Stmt # 12 : QP_Qualifiers- modifiers where
pricelist is the only qualifier '
select count(*) from
qp_qualifiers a , qp_list_headers_b qlh where
a.list_header_id = qlh.list_header_id and
qlh.list_type_code not in
('PRL','AGR') and
a.qualifier_context='MODLIST' and

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 15

a.qualifier_attribute='QUALIFIER_ATTRIBUTE4'
and not exists
(select 'x' from qp_qualifiers b where b.list_header_id
= a.list_header_id
and nvl(b.list_line_id,1) = nvl(a.list_line_id,1) and
b.qualifier_id <> a.qualifier_id);
prompt 'Stmt # 13 : QP_Qualifiers- Line level '
prompt '=============================='
select count(*) from qp_qualifiers where list_line_id <>
-1;
prompt 'Stmt # 14 : QP_Qualifiers- not null group '
prompt '==========================='
select count(*) from qp_qualifiers where
QUALIFIER_GROUPING_NO <> -1;
prompt 'Stmt # 15 : QP_Qualifiers- grouping by operator
'
select count(*),COMPARISON_OPERATOR_CODE from
qp_qualifiers group by
COMPARISON_OPERATOR_CODE ;
prompt 'Stmt # 16 : QP_Qualifiers- Search Ind = 1 but
not selective '
select max(distinct_row_count) from qp_qualifiers where
search_ind=1;
prompt 'Stmt # 17 : Are there any manual modifiers '
select automatic_flag, count(*) from qp_list_lines where
list_line_type_code in ('DIS','SUR') group by
automatic_flag;
prompt 'Stmt # 18 : QP_rltd_modifiers'
prompt '================='
prompt 'QP_rlst_modifiers- group Count'
SELECT RLTD_MODIFIER_GRP_TYPE, count(*) from
qp_rltd_modifiers
group by RLTD_MODIFIER_GRP_TYPE;
prompt 'Stmt # 19 : QP_Product Selectivity > 50 '
prompt '==========================='
select pricing_phase_id, product_attribute,
product_attr_value , count(*) from
qp_pricing_attributes group by pricing_phase_id,
product_attribute, product_attr_value having count(*) >
50;
prompt 'Stmt # 20 : QP_pricing_attribute Selectivity >
50 '
prompt '==========================='
select
pricing_phase_id, product_attribute, product_attr_value
,
pricing_attribute_context, pricing_attribute,
pricing_attr_value_from, count(*) from
qp_pricing_attributes group by pricing_phase_id,
product_attribute,
product_attr_value,
pricing_attribute_context, pricing_attribute,
pricing_attr_value_from
having count(*) > 50;
prompt 'Stmt # 21 : QP_Formula Headers '
prompt '==========================='
select count(*) Formula_Headers from qp_price_formulas;
prompt 'Stmt # 22 : QP_Formula Lines '
prompt '==========================='

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 16

select price_formula_line_type_code , count(*) from

qp_price_formula_lines
group by price_formula_line_type_code;
prompt 'Stmt # 23 : Number of Orders '
prompt '==========================='
select count(*) from oe_order_headers_all ;
prompt 'Stmt # 24 : Number of Order Lines '
prompt '==========================='
select count(*) from oe_order_lines_all ;
prompt 'Stmt # 25 : Number of Price Adjustments '
prompt '==========================='
select count(*) from oe_price_adjustments ;
prompt 'Stmt # 26 : Number of manual Price Adjustments '
prompt '==========================='
select automatic_flag, count(*) from
oe_price_adjustments
group by automatic_flag;
prompt 'Stmt # 27 : Are there any blind modifiers '
prompt '==========================='
select count(*) from qp_list_lines where
pricing_phase_id > 1 and
qualification_ind=0;
prompt 'END of script'
prompt '*************'
commit;
exit;
/

Tuning Advanced Pricing Engine for Optimal Performances 10/26/01 1:30 PM

Page 17

Tuning Advanced Pricing to Ensure Optimal Performance

October 2001
Author: Tony Maxey
Contributing Authors: Nitin Hase, Jayrama Holla, Ravi Tata
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
Web: www.oracle.com
This document is provided for informational purposes
only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark, and Oracle Order Management is (are) a
trademark(s) or registered trademark(s) of Oracle corporation.
All other names may be trademarks of their respective owners.
Copyright Oracle Corporation 2001
All Rights Reserved