Statspack Analyzer

Page 1 of 3

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?

WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst Num Release RAC Host ------------ ----------- ------------ -------- ----------- --- -----------ORCL 1256961120 orcl 1 10.2.0.4.0 NO LDS9202 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------Begin Snap: 2984 17-Jan-11 00:10:06 195 1.9
Submit and continue Clear

Database Info
DB ID 1256961120 Instance orcl

Thu May 10 15:50:22 UTC+0200 2012 Release 10.2.0.4.0 RAC NO Host LDS9202

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

601.12 (min) 75.66 (min) 292 MB 8,192 bytes 7.11 per second

36,067.2 (sec) 4,539.72 (sec)

Performance Summary
Physical Reads: Physical Writes: Single-block Reads: Multi-block Reads: Tablespace Reads: 9/sec 1/sec 0.78/sec 0.61/sec 0/sec MB per second: MB per second: Avg wait: Avg wait: Writes: 0.07 MB/sec 0.01 MB/sec 2.66 ms 1.04 ms 0/sec

Top 5 Events
Event CPU time os thread startup db file sequential read db file scattered read log file sync Percentage of Total Timed Events 85.6% 2.3% 1.6% 0.5% 0.3%

Tablespace I/O Stats

Tablespace UDBMOV SHADOW TICKET SYSAUX LOGGIN Read/s 0 0 0 0 0 Av Rd(ms) 1.7 2.2 2.8 2.7 1.1 Blks/Rd 13 9.6 1.2 1.2 2.9 Writes/s 0 0 0 0 0 Read% 74% 55% 38% 42% 90% % Total IO 28.17% 13.67% 10.54% 9.94% 8.74%

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

10.05.2012

Statspack Analyzer

Page 2 of 3

SYSTEM STATIS SETTLM AQDATA UNDOTBS1 OPERAT CUSTOM

0 0 0 0 0 0 0

2.3 2.2 1.8 4.6 2 2.2 4.5

1.2 4.3 6.3 1 1 1.6 2.7

0 0 0 0 0 0 0

88% 54% 70% 6% 0% 74% 55%

7.51% 5.3% 4.62% 4.2% 3.12% 3.05% 0.46%

Load Profile
Logical reads: Physical reads: Physical writes: Rollback per transaction: 1 Recommendations: Your database has relatively high logical I/O at 82,877 reads per second. Logical Reads includes data block reads from both memory and disk. High LIO is sometimes associated with high CPU activity. CPU bottlenecks occur when the CPU run queue exceeds the number of CPUs on the database server, and this can be seen by looking at the "r" column in the vmstat UNIX/Linux utility or within the Windows performance manager. Consider tuning your application to reduce unnecessary data buffer touches (SQL Tuning or PL/SQL bulking), using faster CPUs or adding more CPUs to your system. 82,877/s 9/s 1/s 0.09% Parses: Hard parses: Transactions: Buffer Nowait: 32.26/s 1.06/s 7.11/s 100%

Instance Efficiency
Buffer Hit: Library Hit: Memory Usage: 0 Recommendations: 99.99% 97.47% 82.36% In-memory Sort: Latch Hit: Memory for SQL: 100% 99.98% 98%

SQL Statistics
Click here to see all SQL data

Wait Events
Event os thread startup db file sequential read db file scattered read log file sync log file parallel write control file sequential read read by other session buffer busy waits log file sequential read latch: library cache 0 Recommendations: Waits 126 28,154 22,010 204,424 255,790 39,900 2,754 46,347 507 44 Wait Time (s) 106 75 23 13 13 10 6 5 5 4 Avg Wait (ms) 842 3 1 0 0 0 2 0 10 101 Waits/txn 0.0 0.1 0.1 0.8 1.0 0.2 0.0 0.2 0.0 0.0

Instance Activity Stats

Statistic consistent gets consistent gets - examination db block changes execute count parse count (hard) parse count (total) physical reads physical reads direct physical writes Total 2,986,834,982 1,639,586,854 2,259,029 1,039,247 38,288 1,163,606 351,151 58 63,175 per Second 82,812.7 45,459.0 62.6 28.8 1.1 32.3 9.7 0.0 1.8 per Trans 11,654.3 6,397.5 8.8 4.1 0.2 4.5 1.4 0.0 0.3

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

10.05.2012

Statspack Analyzer

Page 3 of 3

physical writes direct redo writes session cursor cache hits sorts (disk) sorts (memory) table fetch continued row table scans (long tables) table scans (short tables) workarea executions - onepass 3 Recommendations:

63 255,790 643,250 0 395,072 264 24 62,319 0

0.0 7.1 17.8 0.0 11.0 0.0 0.0 1.7 0.0

0.0 1.0 2.5 0.0 1.5 0.0 0.0 0.2 0.0

You have 45,459.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. To reduce logical I/O, you may consider moving your indexes to a large blocksize tablespace. Because index splitting and spawning are controlled at the block level, a larger blocksize will result in a flatter index tree structure. You have high update activity with 62.6 db block changes per second. The DB block changes are a rough indication of total database work. This statistic indicates (on a per-transaction level) the rate at which buffers are being dirtied and you may want to optimize your database writer (DBWR) process. You can determine which sessions and SQL statements have the highest db block changes by querying the v$session and v$sessatst views. 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. 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

Init.ora Parameters
Parameter cursor_sharing db_block_size db_cache_size db_file_multiblock_read_count pga_aggregate_target shared_pool_size _optimizer_cost_model session_cached_cursors 3 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 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. Value similar 8,192 252MB 16 400MB 200MB choose 50

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