Statspack for slow database

Question

Guys,
This is my first time i generated a statspack report as the users were complaining slow response from datbase.
This report is taken when the reports that takes a long time were run.
This is my statspack report.
Message was edited by:
jkestely

Answer 1

Hi,
FYI, some tuning guru's are developing an open source free tool to help analyze STATSPACK and AWR reports, which is helpful to beginners:
http://www.statspackanalyzer.com
Also, It may be be a good idea to publish your prouction SQL here (or anywhere else). I've seen DBA's get canned for disclosing proprietary details about their employers database . . . .
Also, a short duration snapshot is not so bad, and I often do on minute snaps when diagnosing a system. Anyhow, here are some observations from SP analyzer:
Hope this helps. . . .
Donald K. Burleson
Author of "Oracle 9i High Performance Tuning with STATSPACK" by Oracle Press
You have enabled system-level parallel query. This can influence the cost-based optimizer to favor full-table scans over index access. Consider using parallel hints instead, or invoking parallelism at the session level.
You may have an application issue causing excessive rollbacks with 47.62% rollbacks per transaction. Due to Oracle´s assumption of a commit, the rollback process is very expensive and should only be used when necessary. You can identify the specific SQL and user session that is executing the rollbacks by querying the v$sesstat view.
Remember that some applications may automatically perform rollback operations (commit-then-rollback or rollback-then-exit) after each commit. If this is the case, speak with your application developers to find out if there is a way to disable this. While these "empty rollbacks" do not incur performance expense, it will case this metric to appear very high.
You have high latch free waits of 1.3 per transaction. The latch free wait occurs when the process is waiting for a latch held by another process. Check the later section for the specific latch waits. Latch free waits are usually due to SQL without bind variables, but buffer chains and redo generation can also cause them.
You have 27,717.0 consistent gets examination per second. "Consistent gets - examination" is different than regular consistent gets. It is used to read undo blocks for consistent read purposes, but also for the first part of an index read and hash cluster I/O.
You have 203,044 table fetch continued row actions during this period. Migrated/chained rows always cause double the I/O for a row fetch and "table fetch continued row" (chained row fetch) happens when we fetch BLOB/CLOB columns (if the avg_row_len > db_block_size), when we have tables with > 255 columns, and when PCTFREE is too small. You may need to reorganize the affected tables with the dbms_redefintion utility and re-set your PCTFREE parameters to prevent future row chaining.
You have 1.1 long table full-table scans per second. This might indicate missing indexes, and you can run plan9i.sql to identify the specific tables and investigate the SQL to see if an index scan might result in faster execution. If your large table full table scans are legitimate, look at optimizing your db_file_multiblock_read_count parameter.
You have high small table full-table scans, at 1.7 per second. Verify that your KEEP pool is sized properly to cache frequently referenced tables and indexes.
You are not using your KEEP pool to cache frequently referenced tables and indexes. This may cause unnecessary I/O. When configured properly, the KEEP pool guarantees full caching of popular tables and indexes. Remember, an average buffer get is often 100 times faster than a disk read.
Any table or index that consumes > 10% of the data buffer, or tables & indexes that have > 50% of their blocks residing in the data buffer should be cached into the KEEP pool. You can fully automate this process using scripts.