Académique Documents
Professionnel Documents
Culture Documents
Source: http://www.orafaq.com Web site has given permission to distribute this FAQ for non-profit purpose provided the Disclaimer and Copyright mentioned at the end of the document is included along with FAQ. Author: Frank Naud Proper Preparation Prevents Poor Performance
Topics
Why and when should one tune performance? What database aspects should one monitor? Where should the tuning effort be directed? What tuning indicators can one use? What tools/utilities does Oracle provide to assist with performance tuning? What is STATSPACK and how does one use it? When is cost based optimization triggered? How can one optimize %XYZ% queries? Where can one find I/O statistics per table? My query was fine last week and now it is slow. Why? Why is Oracle not using the damn index? When should one rebuild an index? How does one tune Oracle Wait events? Where can one get more info about Oracle Tuning?
The speed of computing might be wasting valuable human time (users waiting for response); Enable your system to keep-up with the speed business is conducted; and Optimize hardware usage to save money (companies are spending millions on hardware).
Although this FAQ is not overly concerned with hardware issues, one needs to remember than you cannot tune a Buick into a Ferrari.
Is the database up and responding to requests Are the listeners up and responding to requests Are the Oracle Names and LDAP Servers up and responding to requests Are the Web Listeners up and responding to requests Etc.
Is the archive log destination filling up? Objects getting close to their max extents Tablespaces running low on free space/ Objects what would not be able to extend User and process limits reached Etc.
3.
4.
5. 6.
problems are resolved by coding optimal SQL. Also consider proper scheduling of batch tasks after peak working hours. Memory Tuning: Properly size your database buffers (shared_pool, buffer cache, log buffer, etc) by looking at your buffer hit ratios. Pin large objects into memory to prevent frequent reloads. Disk I/O Tuning: Database files needs to be properly sized and placed to provide maximum disk subsystem throughput. Also look for frequent disk sorts, full table scans, missing indexes, row chaining, data fragmentation, etc. Eliminate Database Contention: Study database locks, latches and wait events carefully and eliminate where possible. Tune the Operating System: Monitor and tune operating system CPU, I/O and memory utilization. For more information, read the related Oracle FAQ dealing with your specific operating system.
Buffer Cache Hit Ratio Formula: Hit Ratio = (Logical Reads - Physical Reads) / Logical Reads Action: Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) to increase hit ratio Library Cache Hit Ratio Action: Increase the SHARED_POOL_SIZE to increase hit ratio Etc.
TKProf
Explain Plan UTLBSTAT.SQL and UTLESTAT.SQL - Begin and end stats monitoring Statspack Oracle Enterprise Manager - Tuning Pack
-- Take a performance
-- Get a list of snapshots select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT; @spreport.sql difference report Other Statspack Scripts:
sppurge.sql - Purge a range of Snapshot Id's between the specified begin and end Snap Id's spauto.sql - Schedule a dbms_job to automate the collection of STATPACK statistics spcreate.sql - Installs the STATSPACK user, tables and package on a database (Run as SYS). spdrop.sql - Uninstall STATSPACK from database (Run as SYS) sppurge.sql - Delete a range of Snapshot Id's from the database spreport.sql - Report on differences between values recorded in two snapshots sptrunc.sql - Truncates all data in Statspack tables
Which tables are currently analyzed? Were they previously analyzed? (i.e. Was the query using RBO and now CBO?) Has OPTIMIZER_MODE been changed in INIT.ORA? Has the DEGREE of parallelism been defined/changed on any table? Have the tables been re-analyzed? Were the tables analyzed using estimate or compute? If estimate, what percentage was used? Have the statistics changed? Has the INIT.ORA parameter DB_FILE_MULTIBLOCK_READ_COUNT been changed? Has the INIT.ORA parameter SORT_AREA_SIZE been changed? Have any other INIT.ORA parameters been changed?
What do you think the plan should be? Run the query with hints to see if this produces the required performance. Back to top of file
USER_TAB_COLUMNS.NUM_DISTINCT - This column defines the number of distinct values the column holds. USER_TABLES.NUM_ROWS - If NUM_DISTINCT = NUM_ROWS then using an index would be preferable to doing a FULL TABLE SCAN. As the NUM_DISTINCT decreases, the cost of using an index increase thereby making the index less desirable. USER_INDEXES.CLUSTERING_FACTOR - This defines how ordered the rows are in the index. If CLUSTERING_FACTOR approaches the number of blocks in the table, the rows are ordered. If it approaches the number of rows in the table, the rows are randomly ordered. In such a case, it is unlikely that index entries in the same leaf block will point to rows in the same data blocks. Decrease the INIT.ORA parameter DB_FILE_MULTIBLOCK_READ_COUNT - A higher value will make the cost of a FULL TABLE SCAN cheaper.
Remember that you MUST supply the leading column of an index, for the index to be used (unless you use a FAST FULL SCAN or SKIP SCANNING).
There are many other factors that affect the cost, but sometimes the above can help to show why an index is not being used by the CBO. If from checking the above you still feel that the query should be using an index, try specifying an index hint. Obtain an explain plan of the query either using TKPROF with TIMED_STATISTICS, so that one can see the CPU utilization, or with AUTOTRACE to see the statistics. Compare this to the explain plan when not using an index. Back to top of file
Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i)/ Analyze contention from SYS.V$BH Increase LOG_BUFFER parameter or move log files to faster disks