Oracle Retail Application Performance Tuning Best Practices V14

1 Copyright 2012, Oracle and/or its affiliates. All rights reserved.
Proprietary and Confidential

Oracle Retail Application Performance Tuning
Philip Zeng
Oracle Certified Master
Chief Performance Architect
2 Copyright 2012, Oracle and/or its affiliates. All rights reserved. Proprietary and Confidential
Safe Harbor Statement
The following is intended to outline our general product direction.

It is intended for information purposes only, and may not be
incorporated into any contract. It is not a commitment to deliver
any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracles
products remains at the sole discretion of Oracle.
Agenda
Understand the challenges with Retail Application performance<Insert
Picture
Find the key factors affecting Retail Application performance Here>
Identify where to tune the Retail Application performance

Setup Retail Applications for best performance
Handle database statistics for staging tables smartly
Maintain database for best performance
Advance your SQL tuning techniques
Develop instance tuning skills
Increase I/O efficiency
<Insert
Picture
Here>
SECTION 1
APPLICATION SPECIFIC TUNING
Why Retail Application Performance is a
Challenge
Logic complexity
Many analytical functions and cross-row computations
Many UNION and OR statements to cover all the scenarios
SQL length often measured by pages
Data volume
One of the industries with the largest data volume
Data processed can be at Item/Loc/Date level
Often 10s million line/item transactions per day
The largest tables are the frequently accessed tables
Challenge
Data Model complexity
Data model designed for RMS, and shared with many other
Oracle Retail applications
Flexibility of application
Many Oracle Retail Applications are very flexible, and can be
setup and used in different ways
Different business practices
Each customer has its unique business process and data profile
Challenge
Rapidly growing tables and difficult to purge
Hard to set up data to test every block of application
code
Different data will hit different code block
Different data generates different SQL Execution Plan
Different server objects
PL/SQL object table no statistics available
Staging/working tables No data when the gather Statistics job is
running, but with data there when the application is running
Key Factors for Performance
Areas that you can change in the field

SQL execution plans database statistics & SQL tuning
Data volume and data profile optimize the way to setup and use
applications and purge inactive data
Database physical design partitioning, index design, Initrans,
Freelist/ASSM, data cluster effect, etc.
Database maintenance
Key Factors for Performance
Areas you can change in the field - comntinued

Database instance efficiency parameter tuning
I/O performance
Adequate server processing power, memory and I/O bandwidth
server capacity planning
Server resources utilization level multi-threading and balance
workload
Where to Tune?
Application specific setting and tuning

Generic application code tuning 80% of the total efforts
Generic database and system performance tuning
Database Statistics Maintenance
Data purging
Performance Testing Methodologies
Unit Test
Make the codes efficient and make the single user and single thread faster
80% of the work
Volume/Load Test
Resolve contentions
Fine tune threading and system resources utilization
Do NOT start Load test before the application codes are fine tuned
Stress Test
Increase the number of concurrent users and transactions or threads
Test the maximum throughput of the hardware and software
Endurance Test
Test if the system is stable after the system is heavily used for an extended period
Test to Scale -- when you dont have the full size hardware
Due to the data volume and logic complexity of the Oracle Retail systems, Performance testing
and tuning are very important for the success of the Oracle Retail implementation.
On the Enterprise Application side, RPM, RFM, RA, RMS/ReSA, and Allocation are the
applications that need significant performance tuning efforts
Performance testing and tuning efforts are very time consuming. For most of the customers, 20%
of the total man-dates are allocated to the performance testing and tuning efforts
Performance testing itself does not fix the issues. It is to detect the potential performance issue.
Tuning is the way to fix the issues. So allocate more time to the tuning efforts
Hardware has its limit of processing speed and scalability. Some performance issues may not
have resolution due to the limitation of the current technologies. In this case, change of business
process or the way to setup and use the application may be required for some issues. This is part
of the Oracle Retail Application Tuning Best Practice
Performance tuning has 2 levels, Macro-level and Micro-level
Macro-level is to tune the system, database and application configurations and
parameters to increase the database and system efficiency and resolve the
contentions.
Micro-level is to tune the application code to make the application codes efficient.
Micro-level tuning fixes 80% of the performance issues and need 80% of the efforts
After application codes are well tuned, some database and system level contentions
will disappear. So always start the application tuning first with a typical database and
system configurations
The 2 tuning levels impact each other, but they can not completely replace the efforts
of the other level
Poor configurations make the Micro-level tuning difficult and the inefficient application
codes make the Macro-level tuning difficult
Dedicated performance testing environment (at least dedicated application
server instance and dedicated physical database if sharing the same
hardware)
Same kind of servers and storage, and similar amount of memory as
Production, CPU count can be much less for the atomic tuning phase
The performance requirements and data volume should be pre-defined
The testing environment, users and data should be pre-tested end to end
for the target batches and online screens before the performance project
starts
Dedicated performance testing and tuning technical resources
The performance tuning team sit side by side
Three Phases Performance Tuning Efforts
Before go-live
Data are created by scripts or data conversion, data are not 100% Production like
With foundation data basically. History data is limited, the performance tests before go-live can not detect all
of the potential performance issues, especially for RPM
6 to 12 months after go-live
RPM performance is very historical length sensitive due to the Roll Forward computation, Price Event
Inheritance and the sibling records for Rollup to the hierarchy level
Some performance issues start to show up 3 months after go-live, especially RPM
With real Production data
Should use physical copy of the Production database
Ongoing Performance Tuning
Performance tuning is an ongoing effort, especially for RPM
Performance will be getting stable along the ongoing tuning after 1 year
Before the Christmas busy season is a good time to fine tune the performance again
Who need to involve the tuning efforts?
The tuning services provided by Oracle Retail are mainly for training purpose instead
of full tuning service
The performance DBA should be an application performance DBA in addition to a
system performance DBA. The should understand retail logic, application codes, the
SQL Execution Plan and database Wait Events
Application Engineers are needed to setup the testing data, execute the tests,
implement the code changes and do the functional tests.
Application Administrator to change application configurations and restart the
Application Servers
Because the performance tuning is a ongoing efforts, the customers performance
DBAs and application Administrators need to involve the tuning efforts deeply.
How to Create the Testing Data and Database?
Database foundation data must be production like in terms of data volume and data
profile
Database history data must be production like in terms of data volume and data
profile (especially for RPM)
Testing data volume and profile must be Production like
Testing scenarios must be production like
A heavily used UAT system with end to end tests every day is a good way to detect
potential performance issues before go-live
Physical Copy of the Production database is a good testing database after go-live
Database identical Block by Block with physical copy
Generic Tuning
Application/SQL tuning (micro-level) 80% of issues can

be fixed at this level
Application Design tuning (macro-level) algorithm &
driving cursor design if it is customization
Database physical design
Generic Tuning
Database instance tuning

I/O performance tuning
OS and system tuning
Optimize the network configurations
Application Settings Tuning
Functional configuration and usage

Data purging
Batch schedule optimization
Multi-threading settings
LUW settings
Java JVM settings
Optimize the way to use Application
Functional Considerations
Effective usage of Bulking Vs chunking

Creating price events at higher levels (Style/Zone level) whenever
possible
Using NIL strictly for new items (Not for Initial Data Loading or
Seeding)
Using injector to create price events for higher volumes instead of UI
for better efficiency and to avoid Out Of Memory exceptions, and
also minimize the impact of network latency
Data Purging
Inactive item purging

If there are active transactions or non-zero Stock On Hand with
an item, the item cant be purged
History data purging. The purging logic for some tables
is complex.
PRICE_HIST
FUTURE_COST
RPM_FUTURE_RETAIL

RMS Batch Configuration Tunings
The Threading and Commit Max Counter for RMS Batch
jobs are basically controlled by RESTART_CONTROL
Most of the RMS batch jobs are multi-threads capable
The UPDATE_ALLOW column is only for reference
Please refer the RMS Operation Guide for detail
If the Unit of Work is at low level (e.g. Item/Loc), start the
COMMIT_MAX_CTR setting with 10,000
If the Unit of Work is at higher level (e.g. Loc), start the
COMMIT_MAX_CTR setting with 1
If the batch program is multi-threads capable
Start the number of threads to 1.2 x of CPU cores,
Fine tune the number of threads to the level that the DB servers
CPU resources are just or nearly fully utilized
The number of threads should be 1.5 to 2 times of No. of CPU
cores
If the batch job is running during the online window, control the
number of threads to leave adequate resources for online users
Both under threading and over threading will reduce the
throughput
RMS Batch Configuration Tuning
Balance the workload across the threads and start the
largest thread first.
This is to cut the batch tail.
Balance the workload across nodes with RAC cluster
The CPU Utilization Level Based load balancing does
not work well on batch job
The better load balancing algorithm is Round Robin.
For partitioned tables, make the Partition key match the
threading key (or threading key to match the partition
key).
This is especially important for RAC cluster to reduce the Global
Cache related waits and Inter-connect traffic
Gigabit network has adequate network bandwidth for
batch server to connect to DB server usually
The network latency is much more important for
performance than bandwidth
Direct network link (like Cross-over direct link) has the
least latency
If the customer has batch servers on different data
centers(e.g. D/R site), the local batch server should
connect to the local DB node normally
RMS Pro*C batches can take the following options in
command line for performance tuning:
SQL_TRACE=8 (or 12) to turn on SQL trace
SORT_AREA_SIZE=[a number] to set the SORT_AREA_SIZE
HASH_AREA_SIZE=[a number] to set the HASH_AREA_SIZE
DB_FILE_MULTIBLOCK_READ_COUNT=[a valid number] to
change the session level parameter
Command line syntax: batch_name $UP SQL_TRACE=8
It is not easy to pass those parameters into UC4/Appwox
RPM Batch Configuration Setting
The threading for RPM Batch jobs is controlled by
RPM_BATCH_CONTROL
Start the LUW with 10,000 for medium to large Price
Events and fine tune LUW based on data profile
Small Price Events and/or long Time Line Sequence
should use smaller LUW.
E.g. the Item/Loc level Price Events use 1,000 LUW
PROGRAM_NAME NUM_THREADS THREAD_LUW_COUNT
------------------------------------------------------------ ----------- ---------------------------------------------------------
com.retek.rpm.batch.PriceEventExecutionBatch 16 5000
com.retek.rpm.batch.LocationMove.LocationMoveBatch 16 5000
com.retek.rpm.batch.LocationMove.PurgeLocationMovesBatch 1 5000
com.retek.rpm.batch.MerchExtract.MerchExtractKickOffBatch 16 5000
com.retek.rpm.batch.WorksheetAutoApproveBatch 16 5000
com.retek.rpm.batch.PromotionPurgeBatch 1 5000
com.retek.rpm.batch.NewItemLocBatch 16 5000
com.retek.rpm.batch.RegularPriceChangePublishBatch 1 5000
com.retek.rpm.batch.ClearancePriceChangePublishBatch 1 5000
com.retek.rpm.batch.PromotionPriceChangePublishBatch 1 5000
com.retek.rpm.batch.PriceEventExecutionRMSBatch 16 5000
com.retek.rpm.batch.PriceChangeAreaDifferentialBatch 16 5000
com.retek.rpm.app.bulkcc.service.BulkConflictCheckAppService 5000
com.retek.rpm.app.bulkcc.service.ChunkConflictCheckAppService 10000
com.retek.rpm.batch.refreshPos.RefreshPosDataBatch 16 5000
RPM Batch Configuration Settings
OAS Configurations
RPM conflict checking multi-threading is controlled by
orion-ejb-jar.xml in $ORACLE_HOME/j2ee/rpm_oc4j/application-
deployments/rpm13/rpm13
Review the following settings in orion-ejb-jar.xml
Start with the following thread settings and fine tune based on
system resource utilization
RPMTaskMDB RPMChunkMDB
MinListenerThreads = 0.5 X #CPU
MinListenerThreads = #CPU
MaxListenerThreads = 1 X #CPU
MaxListenerThreads = 1.5 X #CPU
Note: Large Price Events use smaller ratio
WebLogic
RPM conflict checking multi-threading is controlled by
weblogic-ejb-jar.xml in rpm14.jar under
${WLS_HOME}/user_projects/domains/base
domain/servers/<RPM_SERVER>/tmp/_WL
user/rpm14/wieeho/rpm14.jar
In the rpm14.jar, META-INF\weblogic-ejb-jar.xml
How To Set Up the Connection Factory and the
Threading Work Manager in Retail Price Management
(RPM) (Doc ID 1970823.1)
WebLogic
Review the following settings in weblogic-ejb-jar.xml
(DEFAULT is 16 THREADs):
Start with the following thread setting and fine tune based on
system resources utilization
For RPMTaskMDB and RPMChunkMDB
<weblogic-enterprise-bean>
<ejb-name>RPMTaskMDB</ejb-name>
<message-driven-descriptor>
<destination-jndi-name>jms/taskQueue</destination-jndi-name>
</message-driven-descriptor>
<reference-descriptor>
</reference-descriptor>
<dispatch-policy>threading_workmanager</dispatch-policy>
</weblogic-enterprise-bean>
App Server Configuration Parameters
RPM JVM Size settings (for typical customers)

OAS: $OAS_HOME/opmn/conf/opmn.xml
WebLogic: <ORACLE_HOME>/user_projects/
domains/<DOMAIN_NAME>/startWeblogic.sh
Min 2 GB
Max 4 GB or the O/S allowed size
$J2EE_HOME/j2ee/rpm_oc4j/applications/rpm14/JnlpLaunchServlet
/client/ rpm_jnlp_template.vm
inital-heap-size=512M"
max-heap-size=1024M"
RPM Logging & Tracing
Logging: Records batch timing step-by-step(useful for
current & historical analysis)
RPM_BATCH_LOG table to hold the logging information
RPM_V_BATCH_LOG view to output a readable format of the
logs
Tracing: Generate a trace with meaningful name without
using a tracing trigger. Just update a column in
RPM_BATCH_TRACE table for the batch you want to
trace
<Insert
Picture
Here>
SECTION 2
DATABASE MAINTENANCE FOR

PERFORMANCE
Application Tuning
General rules:
Minimize workload make the application more efficient
Parallel processing multi-threading, parallel query
Balance workload make the workload balanced across
threads and nodes
Resolve contentions
SQL Tuning
Tune Execution Plan
Why the Optimizer Picks up an Inefficient
Execution Plan
Without or inaccurate table and/or index statistics
Poorly written SQL that forces the Optimizer to pick up a
certain type of Execution Plan
Inadequate or improper indexing
Wrong hints
Unevenly distributed data
Bind Variable Peaking

Database Maintenance
Gather database statistics

With the right frequency
With the right options
Handle statistics on Staging/Temporary tables smartly
Rebuild the indexes on tables with frequent or large
deletion
Truncate Permanent Staging tables if you can
Shrink Space Cascade for the Permanent Staging tables
that cannot be truncated
Job to Gather Table/Index Statistics
DBMS_STATS package is better than the Analyze

Command to gather database statistics
Weekly database statistics gathering is frequently
enough for most of the large tables
Stats on new partitions should be handled smartly
Default options are good enough for most of the cases
May parallelize the statistics gathering to make stats
gathering job faster
Statistics on Global Temporary Tables
Easy Option
Delete the statistics on the Global Temporary Tables and their Indexes
Reply on the Dynamic Sampling on the runtime (Note: the schema level
stats gathering will skip the GTT tables automatically)
Select table_name, num_rows, last_analyzed from user_tables
where Temporary=Y;
If any GTT tables are analyzed when they are empty, delete the
statistics:
Dbms_stats.delete_table_stats(RMS,<TABLE_NAME>);
Statistics on Global Temporary Tables
Easy Option
For the SQLs not picking up the right Execution Plan
with the Easy Option:
You may set table and index Stats using DBMS_STATS package
on GTT and retest
Note: You need to know the data profile very well to set the Stats manually.
The Set Stats may be good for some scenarios but not good for others.
Statistics on Permanent Staging Tables
The statistics on many permanent staging tables do not reflect the

actual data. For example:
Table Name NUM_ROWS LAST_ANALYZED
RPM_BULK_CC_PE_ITEM 0 16-DEC-11
Temp Table List in RMS Database (including but not limited to):
%_TEMP -- Working/Staging tables
%_TMP -- Working/Staging tables
%MFQUEUE - -- RIB Staging tables
Table List in RPM Database (including but not limited to):

RPM_BULK_CC% -- Conflict Checking Working tables
RPM_PE_CC_LOCK -- Conflict Checking Working tables
RPM_%_PAYLOAD -- Interface Staging tables
RPM_%_WS -- Conflict Check Chunking Working tables
RPM_%WORKSPACE% -- RPM Worksheet Working tables
RPM_%STAGE% -- RPM Batch Staging tables
RPM_PRICE_EVENT_THREAD
RPM_EVENT_ITEMLOC
Tables list in RPM database (including, but not limited to)

whose stats can NOT be locked:
RPM_PRICE_EVENT_THREAD and RPM_EVENT_ITEMLOC RPM
Stage tables for PriceEventExecution Batch job.
Will be analyzed by the batch job code. Stats can NOT be locked.
Statistics on Staging Tables
Best Option
Delete the wrong statistics in the Staging tables
When application is running with a reasonable size transaction, Gather the
Tables and their Index Statistics when the data are still there (you may
want to kill the transaction (on Test system only) if there is no enough time
to gather the Stats before the transaction finishes). You can manually insert
the data into the staging tables if you know the data very well
You may set table and index Stats using DBMS_STATS package instead of
Gather Stats if you know the data profile very well
Test the performance with SQL Trace on
If the stats are good for performance, lock the statistics
Best Option
Export the statistics to a table and transfer the Stats to Production
Database, export the stats table as a backup
If the statistics are over written for any reason, import the statistics
Dbms_stats.delete_table_stats(RMS,<TABLE_NAME>);
Dbms_stats.delete_index_stats(RMS,<INDEX_NAME>);
Dbms_stats.gather_table_stats(RMS,<TABLE_NAME>);
Dbms_stats.gather_index_stats(RMS,<INDEX_NAME>);
Dbms_stats.lock_table_stats(RMS,<TABLE_NAME>);
Note: You need to know the data profile very well to lock the Stats. The locked
Stats may be good for some scenarios but not good for others.
Easy Option
If the application performance is optimal, leave the wrong statistics as it is
If there is a performance issue with a module, SQL trace it, find out the
Staging/Permanent tables used in this module, delete the wrong statistics in
the Staging tables and re-run it
If any of the modules are not happy with the staging tables without statistics,
apply the method defined into Best Option
Test the performance with SQL Trace ON
If the stats are good for performance, lock the statistics
If any of the Staging tables are analyzed again when they are empty or
unintended, repeat the right process again
Staging Table and Index Maintenance
Permanent Staging Tables with frequent or large Inserts and Deletes should
be Truncated or Shrink Space Cascade to reset its high water mark, clean
up the indexes and clean up the left over data due to failed/killed sessions
Most of the Permanent Staging Tables should not have any data needed by
the application anymore if the transaction or batch finished, can be
truncated when there is no application running (e.g. after the online window
and before the batch)
Some Permanent Staging Tables have useful data therefore cannot be
truncated. For those tables, we can use:
ALTER TABLE TABLE_NAME SHRINK SPACE CASCADE;
Note: The table should be on ASSM tablespace and ROW MOVEMENT enabled
Staging/Working Table List in RMS database that may

be truncated (including but not limited to):
%_TEMP -- Most can be truncated
%_TMP -- Most can be truncated
Back up the data before truncating the working
tables
Please check the RMS Operation Guide or contact Oracle
Support to check if the table can be truncated!
Staging/Working Table List in RPM database that may
be truncated (including but not limited to):
RPM_BULK_CC%
RPM_PE_CC_LOCK
RPM_%_WS
RPM_%WORKSPACE%
RPM_STAGE_ITEM_LOC_CLEAN
Please run the RPM PurgeBulkConflictCheckArtifacts batch job to clean up
the pending transaction before truncate the RPM working tables, just in
case there are any pending transactions!
Back up the data before truncating the working tables. The data can be for
trouble shooting purpose.
Staging Table List in RMS and RPM database that can

NOT be truncated (including but not limited to):
RPM_%_PAYLOAD POS Interface tables
RPM_%STAGE% except RPM_STAGE_ITEM_LOC_CLEAN RPM
online to batch staging tables
%MFQUEUE RIB Interface tables
Please always check the Operation Guides or contact
Oracle Support to check if the table can be truncated if
you are not sure!
<Insert
Picture
Here>
SECTION 3
APPLICATION PERFORMANCE TUNING
SQL Tuning
SQL Tuning is all about SQL Execution Plan

4 key elements with SQL Execution Plan:
Access Order usually start with the small table
Access Methods
INDEX UNIQUE/RANGE SCAN
INDEX (FAST) FULL SCAN
TABLE ACCESS BY (LOCAL) INDEX ROWID
TABLE ACCESS FULL (PARTITION) (FTS)
Join methods: NESTED LOOPS, HASH JOIN, MERGE JOIN,
Operations: Sort, Filter, Parallel Query, Remote Query and etc
SQL Tuning
Optimal Execution Plan

Minimum CPU Time (mainly logical I/O)
Minimum Elapsed Time (mainly physical I/O and other
wait events)
Minimum blocks and rows accessed
Minimum waits on database events
Minimum contention to other sessions
SQL Tuning
How to identify the wrong Execution Plan

A Few Rows (Index lookup, USE_NL) vs. Many Rows (FTS,
USE_HASH)
Usually Merge Join Cartesian is bad
Full Table Scan is not always bad
Usually too many rows accessed is bad
Usually < 10 blocks/row and < 1 ms/row are good
SQL Tuning
SQL Tuning is all about influencing the Execution Plan

What to influence:
Access Order
Access Methods
Join Methods
Operations
How to Influence the Execution Plan?
Fix or manipulate the Table and Index Statistics

Re-design the SQLs
Add or modify the index
SQL Plan Management
Use hints
SQL Plan Management
Equivalent to adding hints to a SQL with changing the

application codes
No need to change application codes
No need to recompile the application
No need to kill the application run
Do not change the application functionalities
SQL Plans will not be over written by patching
Can be transfer from Test to Production DB
SQL Plan Management
On Testing DB
Set optimizer_capture_sql_plan_baselines=TRUE (Need larger SYSAUX TBS)
Set optimizer_use_sql_plan_baselines=TRUE (on both Test and Prod)
Run the applications
Identify, enable, accept and fix the SQL Plan with the good Execution Plan for the slow SQL
If there is no good SQL Plan generated, add hints to the SQL codes and compile the new codes,
run the application and capture the SQL Plan again
Disable SQL Plan with the wrong Execution Plans
Link the hinted Execution Plan to the non-hinted SQL Handle
Re-compile the original non-hinted codes and re-test.
Transfer the good SQL Plans to Production and review the Execution Plan and performance on
Production
SQL Plan Management
To Check the Baseline Records: DBA_SQL_PLAN_BASELINES
To Check The Execution Plan:
DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE
Important SQL Plan Management Functions:

DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE
DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE
DBMS_SPM.ALTER_SQL_PLAN_BASELINE
DBMS_SPM.DROP_SQL_PLAN_BASELINE
DBMS_SPM.CREATE_STGTAB_BASELINE
DBMS_SPM.PACK_STGTAB_BASELINE
DBMS_SPM.UNPACK_STGTAB_BASELINE
SQL Plan Management
Link the hinted SQL Plan to the non-hinted SQL Handle
declare
l_op pls_integer;
begin
l_op := dbms_spm.load_plans_from_cursor_cache
(sql_id => 'cnazndd6j7d1v' -- sql_id of the hinted SQL
,plan_hash_value => 3724264953 -- plan hash value of the hinted Plan
,sql_handle => 'SQL_11f0e4472549338d' -- sql handle of the non-hinted SQL
);
end;
/
Specify Hints
Can be on a:
simple SELECT, UPDATE, DELETE, or MERGE statement
parent statement or sub-query of a complex statement
part of a compound query or inline view
Immediately after the SELECT, UPDATE, DELETE, or
MERGE key words
For sub-query (or Union query) add hints after SELECT
key word in the sub-query
Specify Hints
Always use table alias in the Hint if table alias is used in

the FROM clause
Syntax: /*+ hint1(arguments) hint2(arguments) */
SELECT /*+ INDEX(IM, PK_ITEM_MASTER) INDEX(ILS, PK_ITEM_LOC_SOH)
Use_NL(im, ils) Leading(im) */ ils.item, ils.loc, ils.stock_on_hand
FROM item_master im, item_loc_soh ils
WHERE ils.loc = :b1 AND im.item = '4943902008' AND im.status='A' AND im.item =
ils.item;
Types of Hints
Single-Table Hints: operate on one table or view. E.g. INDEX and

USE_NL
Multi-Table Hints: operate on one or more tables or views. E.g.
LEADING, ORDERED. Note that USE_NL(table1 table2) is not
considered a multi-table hint because it is a shortcut for
USE_NL(table1) and USE_NL(table2)
Query Block Hints: operate on single query blocks. E.g.
STAR_TRANSFORMATION and UNNEST
Statement Level Hints : apply to the entire SQL statement. E.g.
ALL_ROWS, FIRST_ROWS(n), CHOOSE, RULE
Hints by Category
Hints for optimization approaches and goals: ALL_ROWS

or FIRST_ROWS(n), CHOOSE, RULE
Hints for access paths: FULL, CLUSTER, HASH, INDEX
and NO_INDEX, INDEX_ASC and INDEX_DESC,
INDEX_COMBINE and INDEX_JOIN, INDEX_FFS and
NO_INDEX_FFS, INDEX_SS and NO_INDEX_SS,
INDEX_SS_ASC and INDEX_SS_DESC
Hints for join orders: LEADING, ORDERED
Hints by Category
Hints for join operations: USE_NL and NO_USE_NL,

USE_NL_WITH_INDEX, USE_MERGE and
NO_USE_MERGE, USE_HASH and NO_USE_HASH
Hints for parallel execution: PARALLEL and
NO_PARALLEL, PARALLEL_INDEX and
NO_PARALLEL_INDEX, PQ_DISTRIBUTE
Note: The highlighted ones in Red are the frequently used hints.
Hints by Category
Hints for enabling optimizer features:
OPTIMIZER_FEATURES_ENABLE
Hints for online application upgrade:
CHANGE_DUPKEY_ERROR_INDEX,
IGNORE_ROW_ON_DUPKEY_INDEX,
RETRY_ON_ROW_CHANGE
Hints for Query Transformations: NO_QUERY_TRANSFORMATION,
USE_CONCAT, EXPAND, NO_EXPAND, REWRITE and
NO_REWRITE, MERGE and NO_MERGE,
STAR_TRANSFORMATION and NO_STAR_TRANSFORMATION,
FACT and NO_FACT, UNNEST and NO_UNNEST
Hints by Category
Additional Hints: APPEND, APPEND_VALUES, and

NOAPPEND, CACHE and NOCACHE, PUSH_PRED and
NO_PUSH_PRED, PUSH_SUBQ and NO_PUSH_SUBQ,
QB_NAME, CURSOR_SHARING_EXACT,
DRIVING_SITE, DYNAMIC_SAMPLING,
MODEL_MIN_ANALYSIS, ORDERED_PREDICATE,
MATERIALIZE, PRECOMPUTE_SUBQUERY,
CARDINALITY, RESULT_CACHE etc.
SQL Trace
SQL Trace is the most useful tool for tuning
SQL Trace (level 1, 4, 8, 12) for session level (4=bind variables,
8=wait events, 12=both)
alter session set events '10046 trace name context forever, level 8';
alter session set TRACEFILE_IDENTIFIER=Your_Name';
Rms_batch username/password@db SQL_TRACE=8
Exec sys.DBMS_SYSTEM.SET_EV(SID, SERIAL#, 10046, 8, '');
TOAD or SQL Developer Click TOADs green button
How to get the SID and Serial#
select 'exec sys.dbms_system.set_ev('||sid||','||serial#||',10046,12,'||''''');' from
v$session where program like '%slsupld%';
SQL Trace
Formatting the raw trace
tkprof trace_file.trc output.txt sort=exeela,fchela explain=username/password@db sys=no
Interpreting the SQL Trace

Trace statistics:
Call (Parse, Execute, Fetch, Total) count cpu elapsed disk query current
rows
Row source operation very useful!
Rows
(cr=consistent reads pr=physical read pw= physical writes
time=accumulated time in micro seconds)(objectID)
Explain plan start of most indented line
Sample of Row Source Operation
Rows Row Source Operation
------- ---------------------------------------------------
0 FOR UPDATE (cr=44232 pr=43156 pw=0 time=0 us)
1065 HASH JOIN (cr=44232 pr=43156 pw=0 time=19558 us cost=8527 size=205 card=1)
1064 TABLE ACCESS FULL RPM_BULK_CC_PE_ITEM (cr=62 pr=0 pw=0 time=19578 us cost=2 size=66 card=1)
2128 TABLE ACCESS FULL RPM_BULK_CC_PE_THREAD (cr=66 pr=7 pw=0 time=1369895 us cost=2 size=52 card=1)
2446797 PARTITION HASH SINGLE PARTITION: KEY KEY (cr=44055 pr=43149 pw=0 time=427934665 us cost=8509 size=85452010
card=2441486)
2446797 TABLE ACCESS FULL RPM_FUTURE_RETAIL PARTITION: KEY KEY (cr=44055 pr=43149 pw=0 time=427754896 us
cost=8509 size=85452010 card=2441486)
2128 TABLE ACCESS FULL RPM_BULK_CC_PE_LOCATION (cr=49 pr=0 pw=0 time=0 us cost=2 size=52 card=1)
Other Tools for SQL Tuning
Set timing ON
Set Autotrace ON
(OFF/TRACEONLY/EXPLAIN/STATISTICS)
Explain Plan
Use SQL Developer (or TOAD)
Command line
SQL Tuning
Explain plan set statement_id = 'SQL1' for SELECT /*+ INDEX(IM, PK_ITEM_MASTER) INDEX(ILS,
PK_ITEM_LOC_SOH) USE_NL(IM, ILS) LEADING(IM) */ ils.item, ils.loc, ils.stock_on_hand
FROM item_master im, item_loc_soh ils
WHERE ils.loc = 65 AND im.item = '4943902008' AND im.status='A' and im.item = ils.item;
Set linesize 200

@?/rdbms/admin/utlxplp.sql for parallel query and non- parallel query
select * from table(dbms_xplan.display());
@?/rdbms/admin/utlxpls.sql for non-parallel query

select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
Application Design Tuning
Driving cursor design
Match the partitioning key
Minimize looping (by bulk/set processing)
Make the Work Unit size reasonable
Avoid contention (data and database block overlapping)
Multi-threading
Balanced threads
Adequate threads to make the server busy more than 1.5 x #CPU
Dynamic thread allocation vs. static thread allocation
Setup the number of threads to just fully utilize the system resources but
not over threading
Application Design Tuning
Bulk processing
Define the loop to the optimal level
Location is a good looping key usually
Item/Loc is too low
Avoid Row by Row processing where possible
Avoid unnecessary processing (incremental computation)
Use Bind Variables where possible
Minimum network roundtrips and latency
Application Profiling
Application profiling tools

PL/SQL Profiler for PL/SQL heavy codes
Java Profiling tools
JProbe, OptimizeIT,
C Program Profiling tools
Gprof, Vtune,
ps el, ps ef and check for the Time column
Application Profiling
Last method: write timing to a log file or table

More on
http://en.wikipedia.org/wiki/List_of_performance_analysis
_tools
Database Instance Tuning
Database Performance Monitoring Tools
Automatic Workload Repository (AWR)
Taking a manual AWR snapshot (10g and beyond):
EXEC sys.dbms_workload_repository.create_snapshot;
Note: There is a hourly snapshot job by default database installation
Usually only tune the SGA, PGA and LOG buffer related parameters
and leave others as default
Oracle Optimizer is very sensitive to a few parameters
OPTIMIZER_*
DB_FILE_MULTIBLOCK_READ_COUNT
Tuning application code is our major task
Important Sections in AWR Report
All sections are useful

Recommend starting on:
Top 5 timed foreground events
SQL statistics
Instance efficiency
Advisory statistics
init.ora parameters
Database Physical Tuning
RDA tool or db_size.sql

Partitioning key matches business data access pattern
Data Clustering
Partitioning
Get all column from self contained indexes
Index organized table
Sort data before store
Working tables
Hash clustering
Database Physical Tuning
Global vs. local indexes

Inittrans, ASSM tablespace or FREELIST
Local managed tablespace
System Tuning
System Performance Monitoring Tools
Nmon (Aix and Linux, tracing mode and interactive mode)
Tracing mode to cover 24 hours: nmon f s 30 c 2880
Nmon_analyser.xls
Sar (all Unix)
Filemon (Aix)
Iostat (all Unix)
Netstat (all Unix)
Top (Solaris, Linux, HP UX)
Topas (Aix)
Vmstat (all Unix)
Glance/gpm (HP UX)
NMON CPU/IO Utilization Chart
SWAP/Paging Configuration
General rules
Adequate SWAP space to keep system running
Adequate memory, reasonable and efficient memory allocation to avoid
swapping
Swapping is worse than smaller SGA and PGA
Available RAM Minimum Swap Space Required

Between 1024 MB and 2048 MB 1.5 times the size of RAM
Between 2049 MB and 8192 MB Equal to the size of RAM
More than 8192 MB 0.75 times the size of RAM
Storage Configurations
Oracle recommends SAME: Strip and Mirror Everything

Usually use RAID 10
Use 1 MB or larger strip size
Typical disk service time: 5 to 10 ms is ok, < 5 ms is very
good, >10 ms is poor
One physical disk can only provide 30 to 50 IOPS
Storage Configurations
Solid state drive/flash memory drive is a revolutionary

new generation of storage technology for performance
Pros: up to 180,000 IOPS random read performance per disk or
PCI card, 0.1 ms service time, lower power consumption
Improved: write endurance
Need more improvement: random write performance
Exadata Smart Cache
To enable Flash_Cache on Exadata
alter|create table|index objectname
Storage (flash_cache { keep | default }); -- host level
alter|create table|index objectname
Storage (cell_flash_cache { keep | default }); -- storage cell level
To pre-cache the data or index keys
Select /*+ FULL(ILS) PARALLEL(ILS, 16) */ count(*) from ITEM_LOC_SOH ILS;
Select /*+ INDEX (ILS, PK_ITEM_LOC_SOH) */ count(*) from ITEM_LOC_SOH;
Select /*+ INDEX (ILS, PK_ITEM_LOC_SOH) INDEX_FFS (ILS, PK_ITEM_LOC_SOH) */ count(*) from
ITEM_LOC_SOH;
Exadata can cache 1 billion rows in 30 second. The cache is persistent even if the
database and ASM instances are restarted.
Kernel Parameter Tuning
Parameters for the system to control the limit of system

resources that can be used
Some parameters can affect performance
Some kernel parameters are not dynamically modifiable
Data Model Tuning for Customizations
Make the Data Model as close to your information needs as possible
Normalization vs. de-normalization
Size of N in the 1 N relationship
Fatness of the Parent and Child tables
Data assess pattern: Parent only or Parent + Child join
Consider making them in one table when,
N is very small
Parent table is slim and tall
Parent + Child often join together
Links and Resources
Health Check: Maintenance Steps to Improve Retail Price
Management Application Performance (Doc ID 1387247.1)
To Setup The Connection Factory And The Threading Work Manager
In Retail Price Management (RPM) (Doc ID 1970823.1)
Oracle Retail Price Management Implementation Guidelines and
Checklist Release 13.2.6 and Release 14.0.x (Doc ID 1590869.1
How To Profile Java 6 Apps Using Visual VM and JRockit Mission
Control (Doc ID 1589626.1) 1589626.1
Links and Resources
More info for Hints

http://download.oracle.com/docs/cd/E11882_01/server.11
2/e16638/hintsref.htm#i17496
Application Profiling Tools

http://en.wikipedia.org/wiki/List_of_performance_analysis
_tools

Oracle Retail Application Performance Tuning Best Practices V14

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Oracle Retail Application Performance Tuning Best Practices V14

Hochgeladen von

Copyright:

Verfügbare Formate

1 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

Proprietary and Confidential

The following is intended to outline our general product direction.

Identify where to tune the Retail Application performance

APPLICATION SPECIFIC TUNING

Areas that you can change in the field

Areas you can change in the field - comntinued

Application specific setting and tuning

Application/SQL tuning (micro-level) 80% of issues can

Database instance tuning

Functional configuration and usage

Effective usage of Bulking Vs chunking

Inactive item purging

RPM JVM Size settings (for typical customers)

DATABASE MAINTENANCE FOR

Gather database statistics

DBMS_STATS package is better than the Analyze

The statistics on many permanent staging tables do not reflect the

Table List in RPM Database (including but not limited to):

Tables list in RPM database (including, but not limited to)

Staging/Working Table List in RMS database that may

Staging Table List in RMS and RPM database that can

APPLICATION PERFORMANCE TUNING

SQL Tuning is all about SQL Execution Plan

Optimal Execution Plan

How to identify the wrong Execution Plan

SQL Tuning is all about influencing the Execution Plan

Fix or manipulate the Table and Index Statistics

Equivalent to adding hints to a SQL with changing the

Important SQL Plan Management Functions:

Always use table alias in the Hint if table alias is used in

Single-Table Hints: operate on one table or view. E.g. INDEX and

Hints for optimization approaches and goals: ALL_ROWS

Hints for join operations: USE_NL and NO_USE_NL,

Additional Hints: APPEND, APPEND_VALUES, and

Interpreting the SQL Trace

Set linesize 200

@?/rdbms/admin/utlxpls.sql for non-parallel query

Application profiling tools

Last method: write timing to a log file or table

All sections are useful

RDA tool or db_size.sql

Global vs. local indexes

Available RAM Minimum Swap Space Required

More than 8192 MB 0.75 times the size of RAM

Oracle recommends SAME: Strip and Mirror Everything

Solid state drive/flash memory drive is a revolutionary

Parameters for the system to control the limit of system

More info for Hints

Application Profiling Tools

Das könnte Ihnen auch gefallen