sql&databasetuning

8/7/2019 sql&databasetuning

1/3

After setting OPTIMIZER_FEATURES_ENABLE to 9.2.0, most of the performance issueswere resolved as it kept the release 9.2.0 optimizer behavior and worked accordingly.rem LONGOPS.SQLrem Long Running Statementsrem Helmut Pfau, Oracle Deutschland GmbHset linesize 120

col opname format a20col target format a15col units format a10col 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_longopswhere time_remaining > 0/

Before analyzing the stats on the tables, its safe to backup the existing statsto 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(,,);2. exec dbms_stats.export_table_stats(',,);

3. export the table using export utility.

This export option is available at column level, table level, schema level, index 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.1Solving Convertible or Lossy data in Data Dictionary objects when changing the NLS_CHARACTERSET [ID 258904.1]

Database Performance - FAQ [ID 402983.1]

2. exec dbms_stats.import_table_stats(',,);

This option would be very handy to move Analyzed statistics across instances, in


2/3

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 approach 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 restrictrows and those that join tables.2. I locate candidate Driving Tables by looking at the "restrict rows" clauses as determining which table has the most restrictive clauses ( i.e. those that will result in the fewest rows). If not sure between a couple of candidates, I pickone.3. Next I list all the tables in the FROM clause, starting with the driving table, using the JOIN criteria to link from one table to the next. This generates anordered list of how the database should be accessing the tables, starting withthe candidate driving table. This exercise generates all possible ways to join the tables together as well as making sure there are Join criteria for all the tables 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 optimizer picks I add an Index hint to get the desired index to be used. If a fulltable scan is in order, I consider adding a parallel hint.5. I try to join to tables that have restrictive where clauses before joining totables 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 thecandidate plans generated in the above exercise2. Looking at the actual data (and running some queries to collect metrics) I consider 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 especiallywell 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 from clause from first to last the way I listed them in Analysis Step 3. Adding other hints like /*+ Full (driving table alias) */ is also a good way to get the optimizer 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 AutotraceOn (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: the fewer blocks touched, the better.Tuning Hints and Tips


3/3

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 Join2. 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 significant performance increase by avoiding executing thousands of Nested Loop index

reads with a hash join. Listing more statement rewrite options is beyond the scope 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 confidentyour SQL tuning skills will expand.Happy Tuning!

Consolidated Reference List For Migration / Upgrade Service Requests [ID 762540.1]

--------------------------------------------------------------------------------

Documents

sql&databasetuning