After setting OPTIMIZER_FEATURES_ENABLE to 9.2.

0, most of the performance issues

were resolved as it kept the release 9.2.0 optimizer behavior and worked accord
ingly.
rem LONGOPS.SQL
rem Long Running Statements
rem Helmut Pfau, Oracle Deutschland GmbH
set linesize 120
col opname format a20
col target format a15
col units format a10
col time_remaining format 99990 heading Remaining[s]
col bps format 9990.99 heading [Units/s]
col fertig format 90.99 heading "complete[%]"
select sid,
opname,
target,
sofar,
totalwork,
units,
(totalwork-sofar)/time_remaining bps,
time_remaining,
sofar/totalwork*100 fertig
from v$session_longops
where time_remaining > 0
/
Before analyzing the stats on the tables, its safe to backup the existing stats
to Table, which will help us to restore the old stats if required.
Steps to export or backup the Stats on tables.
1. exec dbms_stats.create_stats_table(<schema_name>,<table_name>,<tablespace>);
2. exec dbms_stats.export_table_stats('<schema_name>,<table_name>,<stats backup
tablename>);
3. export the table using export utility.
This export option is available at column level, table level, schema level, inde
x level and Database level, System stats.
Steps to import or restore the Stats on tables
1. Import the table from Dump file if its not there in the database.
Oracle Performance Diagnostic Guide (OPDG) [ID 390374.1]
TESTING SQL PERFORMANCE IMPACT OF AN ORACLE 9i TO ORACLE DATABASE 10g RELEASE 2
UPGRADE WITH SQL PERFORMANCE ANALYZER [ID 562899.1]
How to use the Sql Tuning Advisor. [ID 262687.1]
Microsoft SQL Server Tuning Tips for PeopleSoft 8.x [ID 747562.1]
Query Tuning Overview [ID 199083.1]
How To Analyze and Modify Sort Orders [ID 477590.1
Solving Convertible or Lossy data in Data Dictionary objects when changing the N
LS_CHARACTERSET [ID 258904.1]
Database Performance - FAQ [ID 402983.1]

2. exec dbms_stats.import_table_stats('<schema_name>,<table_name>,<stats backup

tablename>);
This option would be very handy to move Analyzed statistics across instances, in
stead of analyzing huge tables on each instance is time consuming.
Database Instance Tuning
- SQL Tuning
- Performance
- Tuning of Applications
- Performance Monitoring
- Tuning Tips and Tricks

While application knowledge and experience is helpful, I've got a methodical app
roach I use when asked to tune a SQL statement.
Here's the basic approach/process I use to diagnose and analyze a SQL statement.
.
Analyze the Statement
1. I start by reviewing the WHERE clause, dividing it into clauses that restrict
rows and those that join tables.
2. I locate candidate Driving Tables by looking at the "restrict rows" clauses a
s determining which table has the most restrictive clauses ( i.e. those that wil
l result in the fewest rows). If not sure between a couple of candidates, I pick
one.
3. Next I list all the tables in the FROM clause, starting with the driving tabl
e, using the JOIN criteria to link from one table to the next. This generates an
ordered list of how the database should be accessing the tables, starting with
the candidate driving table. This exercise generates all possible ways to join t
he tables together as well as making sure there are Join criteria for all the ta
bles in the FROM clause.
4. Look for indexes on the driving table and determine which should be used or i
f a full table scan would be best. If I find a better index than the one the opt
imizer picks I add an Index hint to get the desired index to be used. If a full
table scan is in order, I consider adding a parallel hint.
5. I try to join to tables that have restrictive where clauses before joining to
tables that don't have any such clauses.
6. I now have one or more candidate explain plan(s) that need to be tested.
Compare Plans
1. Next I compare the actual explain plan of the statement in question with the
candidate plans generated in the above exercise
2. Looking at the actual data (and running some queries to collect metrics) I co
nsider trying different driving tables and join orders.
3. I review and compare each, and subjectively arrive at my best guess plan.
Test it out
1. The most effective hint I've found is the ORDERED hint. This works especially
well when you have a lot of tables in the FROM clause.
2. I add /*+ ordered */ after the Select verb and the list the tables in the fro
m clause from first to last the way I listed them in Analysis Step 3. Adding oth
er hints like /*+ Full (driving table alias) */ is also a good way to get the op
timizer to use the proper driving table.
3. Run an explain plan using the above HINTs.
4. If the plan looks good, execute it for real. Set Timing On and set Autotrace
On (hopefully you have that enabled in your database)
5. Run the old and new statements several times to see how the timings work out.
The Autotrace summary of blocks touched is a. good indicator of performance: th
e fewer blocks touched, the better.
Tuning Hints and Tips
1. There are many other hints and techniques that can influence an explain plan.
Keep in mind that a Hash Join is nearly always better than a Merge Join
2. Nested Loop is better only if a few rows are being retrieved.
3. Tuning sub-selects can be tricky. I will often rewrite a statement to replace
" IN (Select...) or a NOT IN" with a join to an in-line view and achieve signif
icant performance increase by avoiding executing thousands of Nested Loop index
reads with a hash join. Listing more statement rewrite options is beyond the sco
pe of this article so I'll stop at that one lest this article become too lengthy
.
Those are the basic steps I follow. Give them a try and over time I'm confident
your SQL tuning skills will expand.
Happy Tuning!
Consolidated Reference List For Migration / Upgrade Service Requests [ID 762540.
1]
--------------------------------------------------------------------------------