Statspack Analyzer

Page 1 of 4

Home | Write Accelerator | Sample Report | How To | About SSD | About Us | Feedback | Logout | Forum

Statspack Analyzer 2.0

To submit your Oracle Statspack or AWR, paste the contents of your file into the text area below. Need help?

STATSPACK report for DB Name DB Id Instance Inst Num Release Cluster Host ------------ ----------- ------------ -------- ----------- ------- -----------ORCL 1175660343 orcl 1 9.2.0.1.0 NO LDS Snap Id Snap Time Sessions Curs/Sess Comment ------- ------------------ -------- --------- ------------------Begin Snap: 12 10-Apr-12 11:00:05 193 1.6
Submit and continue Clear

Database Info
DB ID 1175660343 Instance orcl

Thu May 10 15:51:37 UTC+0200 2012 Release 9.2.0.1.0 RAC NO Host LDS

Elapsed: DB Time: Cache: Block Size: Transactions:

780 (min) 2,215.86 (min) 704 MB 4,096 bytes 3.32 per second

46,800 (sec) 132,951.75 (sec)

Performance Summary
Physical Reads: Physical Writes: Single-block Reads: Multi-block Reads: Tablespace Reads: 7,528/sec 12/sec 20.53/sec 469.49/sec 490/sec MB per second: MB per second: Avg wait: Avg wait: Writes: 29.41 MB/sec 0.05 MB/sec 24 ms 2.36 ms 0/sec

Top 5 Events
Event buffer busy waits db file scattered read db file sequential read CPU time log file sync Percentage of Total Timed Events 38.96 % 38.92 % 17.35 % 2.74 % .79 %

Tablespace I/O Stats

Tablespace LOGGIN UDBMOV TICKET STATIS Read/s 469 9 8 2 Av Rd(ms) 1.5 9.5 13.1 9.8 Blks/Rd 16 1.4 1.3 1.6 Writes/s 0 0 0 0 Read% 100% 97% 99% 94% % Total IO 95.13% 1.91% 1.72% 0.42%

http://www.statspackanalyzer.com/analyze090630.asp

10.05.2012

Statspack Analyzer

Page 2 of 4

Load Profile
Logical reads: Physical reads: Physical writes: Rollback per transaction: 3 Recommendations: It appears you have a large amount of waiting on both the physical I/O layer and in the SGA. You may want to consider tuning your SQL using broad brush techniques in order to encourage index use. In a well tuned system, you may want to consider moving to solid state disk in order to decrease the amount of waiting Oracle must do for disk resources. You are performing more than 7,528 disk reads per second. High disk latency can be caused by too-few physical disk spindles. Compare your read times across multiple datafiles to see which datafiles are slower than others. Disk read times may be improved if contention is reduced on the datafile, even though read times may be high due to the file residing on a slow disk. You should identify whether the SQL accessing the file can be tuned, as well as the underlying characteristics of the hardware devices. Check your average disk read speed later in this report and ensure that it is under 7ms. Assuming that the SQL is optimized, the only remaining solutions are the addition of RAM for the data buffers or a switch to solid state disks. Give careful consideration these tablespaces with high read I/O: LOGGIN , UDBMOV , TICKET , STATIS , TEMP . 7,792/s 7,528/s 12/s 0% Parses: Hard parses: Transactions: Buffer Nowait: 12.58/s 0.09/s 3.32/s 98.77%

Instance Efficiency
Buffer Hit: Library Hit: Memory Usage: 1 Recommendations: Your Buffer Hit ratio is 3.54%. The buffer hit ratio measures the probability that a data block will be in the buffer cache upon a re-read of the data block. If your database has a large number of frequently referenced table rows (a large working set), then investigate increasing your db_cache_size. For specific recommendations, see the output from the data buffer cache advisory utility (using the v$db_cache_advice utility). Also, a low buffer hit ratio is normal for applications that do not frequently re-read the same data blocks. Moving to SSD will alleviate the need for a large data buffer cache. 3.54% 99.75% 79% In-memory Sort: Latch Hit: Memory for SQL: 99.94% 99.98% 84.28%

SQL Statistics
Click here to see all SQL data

Wait Events
Event buffer busy waits db file scattered read db file sequential read log file sync direct path read log file parallel write control file parallel write db file parallel write control file sequential read library cache lock 2 Recommendations: You have excessive buffer busy waits at 12 milliseconds. Buffer busy waits are most commonly caused by segment header contention and can be remedied by increasing the value of the tables & index freelists or freelist_groups parameters, tuning your database writer (DBWR process, or by using Automatic Segment Storage Management (ASSM) in the tablespace definition. Using super-fast SSD can dramatically reduce wait times for other reads and in some cases lessen the buffer busy waits. Your average wait time for db file sequential read is 24 milliseconds, which is very slow. The sequential read event occurs when Oracle reads single blocks of a table or index. Index reads or single block reads typically cause this event. In addition, check to ensure that you are using non-buffered direct I/O. If these steps fail to reduce your disk wait times, moving some of your datafiles to solid state disk will reduce the amount of time spent waiting for this event. Waits 4,481,954 21,972,108 960,884 157,623 25,518 157,160 15,273 9,060 4,005 166 Wait Time (s) 51,798 51,749 23,064 1,046 766 678 69 61 49 20 Avg Wait (ms) 12 2 24 7 30 4 5 7 12 119 Waits/txn 28.8 141.3 6.2 1.0 0.2 1.0 0.1 0.1 0.0 0.0

Instance Activity Stats

Statistic SQL*Net roundtrips to/from client consistent gets Total 838,254 363,576,480 per Second 17.9 7,768.7 per Trans 5.4 2,337.9

http://www.statspackanalyzer.com/analyze090630.asp

10.05.2012

Statspack Analyzer

Page 3 of 4

consistent gets - examination db block changes execute count parse count (hard) parse count (total) physical reads physical reads direct physical writes physical writes direct redo writes sorts (disk) sorts (memory) table fetch continued row table scans (long tables) table scans (short tables) workarea executions - onepass 3 Recommendations:

1,137,208 1,176,243 515,619 3,994 588,882 352,322,121 524,081 594,730 524,163 157,160 28 49,055 108 5,899 38,245 28

24.3 25.1 11.0 0.1 12.6 7,528.3 11.2 12.7 11.2 3.4 0.0 1.1 0.0 0.1 0.8 0.0

7.3 7.6 3.3 0.0 3.8 2,265.5 3.4 3.8 3.4 1.0 0.0 0.3 0.0 0.0 0.3 0.0

You have high disk reads with 7,528.3 per second. Reduce disk reads by increasing your data buffer size or speed up your disk read speed by moving to SSD storage. You can monitor your physical disk reads by hour of the day using AWR to see when the database has the highest disk activity. You have 28 disk sorts during this period. Disk sorts are very expensive and increasing your PGA (sort_area_size or pga_aggregate_target) may allow you to perform these sorts in RAM. You have high small table full-table scans, at 0.8 per second. Verify that your KEEP pool is sized properly to cache frequently referenced tables and indexes. Moving frequently-referenced tables and indexes to SSD or the WriteAccelerator will significantly increase the speed of small-table full-table scans.

Latch Activity
Latch library cache 1 Recommendations: You have high library cache waits with 2.1% get miss. Consider pinning your frequently-used packages in the library cache with dbms_shared_pool.keep. Get Requests 7,075,325 % Get Miss 2.1 % NoWait Miss 0.0 Wait Time (s) 4

Buffer Pool Advisory

Current: Optimized: Improvement: 2,640,111,725 disk reads 2,011,037,575 disk reads 23.83% fewer

The Oracle buffer cache advisory utility indicates 2,640,111,725 disk reads during the sample interval. Oracle estimates that doubling the data buffer size (by increasing db_cache_size) will reduce disk reads to 2,011,037,575, a 23.83% decrease.

Init.ora Parameters
Parameter cursor_sharing db_block_size db_cache_size db_file_multiblock_read_count log_archive_start pga_aggregate_target shared_pool_size _optimizer_cost_model session_cached_cursors 4 Recommendations: You are not using large blocksizes for your index tablespaces. Oracle research proves that indexes will build flatter tree structures in larger blocksizes. You have the default value for db_file_multiblock_read_count at 16. The CBO uses this parameter to determine the cost of a full-table scan. The default value is sometimes too large, and you can run scripts to determine the optimal setting. If full-table scans are unavoidable, you may consider placing those tables on SSD . Value similar 4,096 704MB 16 true 200MB 144MB choose 50

http://www.statspackanalyzer.com/analyze090630.asp

10.05.2012

Statspack Analyzer

Page 4 of 4

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. Consider setting your optimizer_index_caching parameter to assist the cost-based optimizer. Set the value of optimizer_index_caching to the average percentage of index segments in the data buffer at any time, which you can estimate from the v$bh view.

If the statspack analyzer is unable to process your report, please email your statspack file, and we will reply with your results.

Copyright 2010 by StatspackAnalyzer.com. All Rights Reserved.

http://www.statspackanalyzer.com/analyze090630.asp

10.05.2012