Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Oracle Database Tips by Donald Burleson


Improving I/O Speed is Not a Silver Bullet

SSD and RAM buffer caching are only important to I/O-intensive Oracle databases.  If an Oracle database is constrained by other environmental factors such as CPU or network, speeding up the I/O subsystem will not result in any appreciable performance gains.  To learn about databases resource bottlenecks, the DBA need only display the top-5 timed events from STATSPACK.

The following is a typical OLTP database where I/O delay is the main source of wait time.  I/O comprises more than 70% of total elapsed time.

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                         % Total
Event                              Waits      Time (s)      Ela Time
--------------------------- ------------   -----------      --------
db file sequential read            2,598         7,146         48.54
db file scattered read            25,519         3,246         22.04
library cache load lock              673         1,363          9.26
CPU time                           1,154          7.83          6.21
log file parallel write           19,157           837          5.68

Again, it is critical to note that additional RAM resources may not have any appreciable effect on databases that are not I/O intensive.  For example, some scientific Oracle databases only read a small set of experimental results and spend the majority of database time performing computations. The output of such a database is shown below:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~                                           % Total
Event                                     Waits    Time (s) Ela Time
---------------------------------- ------------ ----------- --------
CPU time                                  4,851       4,042    55.76
db file sequential read                   1,968       1,997    27.55
log file sync                           299,097         369     5.08
db file scattered read                   53,031         330     4.55
log file parallel write                 302,680         190     2.62

In this example, CPU time is the primary source of database delay, and improving the speed of the I/O with SSD may not have an appreciable effect on overall Oracle performance.

One must be cognizant that it is foolish to focus solely on minimizing physical disk I/O.  For databases with sub-optimal SQL statements, poor performance is commonly combined with a high data buffer cache hit ratio and little disk I/O.  For these databases, the root cause of the performance problem is excessive logical I/O, whereby the sub-optimal SQL rereads data blocks over and over from the RAM data buffers. 

There are several myths of Oracle physical I/O that must be exposed at this point:

  • All Oracle databases are I/O-bound:  Untrue.  Databases with a reasonable data buffer cache size and a small working set will usually be constrained by CPU or network latency.

  • The Data Buffer Hit Ratio (DBHR) will yield caching efficiency:  Untrue, except in cases of a super small cache.  The DBHR only measures the propensity that a data block will be in the buffer on the second I/O request.

  • Only faster disk can remove I/O bottlenecks:  Untrue.  This is a common myth.  There are other non-RAM approaches to reducing disk I/O for Oracle databases:

  • Adjusting optimizer_mode:  Oracle will generate widely differing SQL execution plans depending on the optimizer mode.

  • Re-analyze SQL Optimizer statistics:  Using better quality CBO statistics with dbms_stats and adding column histograms can make a huge difference in disk activity.

  • Adjusting Oracle  parameters: Resetting the optimizer_index_cost_adj  and optimizer_index_caching parameters can affect physical reads.

  • Improve clustering_factor for index range scans: Manually resequence table rows to improve clustering_factor , sometimes using single-table clusters, can reduce disk I/O.

  • Use Materialized Views: Systems with batch only updates may greatly benefit from Materialized Views  to pre-join tables.  Of course, the overhead of refresh commit is too great for high update systems.

With that information on the historical issues about how Oracle uses RAM, the next step is to look at the issues of duplicated RAM caching in large Oracle systems.

See code depot for complete scripts

This is an excerpt from the book Oracle RAC & Tuning with Solid State Disk.  You can get it for more than 30% by buying it directly from the publisher and get immediate access to working code examples.

Market Survey of SSD vendors for Oracle:

There are many vendors who offer rack-mount solid-state disk that work with Oracle databases, and the competitive market ensures that product offerings will continuously improve while prices fall.  SearchStorage notes that SSD is will soon replace platter disks and that hundreds of SSD vendors may enter the market:

"The number of vendors in this category could rise to several hundred in the next 3 years as enterprise users become more familiar with the benefits of this type of storage."

As of January 2015, many of the major hardware vendors (including Sun and EMC) are replacing slow disks with RAM-based disks, and Sun announced that all of their large servers will offer SSD.

Here are the major SSD vendors for Oracle databases (vendors are listed alphabetically):

2008 rack mount SSD Performance Statistics

SearchStorage has done a comprehensive survey of rack mount SSD vendors, and lists these SSD rack mount vendors, with this showing the fastest rack-mount SSD devices:

manufacturer model technology interface performance metrics and notes
IBM RamSan-400 RAM SSD

Fibre Channel

3,000MB/s random sustained external throughput, 400,000 random IOPS
Violin Memory Violin 1010 RAM SSD


1,400MB/s read, 1,00MB/s write with ×4 PCIe, 3 microseconds latency
Solid Access Technologies USSD 200FC RAM SSD

Fibre Channel

391MB/s random sustained read or write per port (full duplex is 719MB/s), with 8 x 4Gbps FC ports aggregated throughput is approx 2,000MB/s, 320,000 IOPS
Curtis HyperXCLR R1000 RAM SSD

Fibre Channel

197MB/s sustained R/W transfer rate, 35,000 IOPS

Choosing the right SSD for Oracle

When evaluating SSD for Oracle databases you need to consider performance (throughput and response time), reliability (Mean Time Between failures) and TCO (total cost of ownership).  Most SSD vendors will provide a test RAM disk array for benchmark testing so that you can choose the vendor who offers the best price/performance ratio.

Burleson Consulting does not partner with any SSD vendors and we provide independent advice in this constantly-changing market.  BC was one of the earliest adopters of SSD for Oracle and we have been deploying SSD on Oracle database since 2005 and we have experienced SSD experts to help any Oracle shop evaluate whether SSD is right for your application.  BC experts can also help you choose the SSD that is best for your database.  Just  call 800-766-1884 or e-mail.:  for SSD support details.

DRAM SSD vs. Flash SSD

With all the talk about the Oracle “flash cache”, it is important to note that there are two types of SSD, and only DRAM SSD is suitable for Oracle database storage.  The flash type SSD suffers from serious shortcomings, namely a degradation of access speed over time.  At first, Flash SSD is 5 times faster than a platter disk, but after some usage the average read time becomes far slower than a hard drive.  For Oracle, only rack-mounted DRAM SSD is acceptable for good performance:

Avg. Read speed

Avg. write speed

Platter disk

10.0 ms.

  7.0 ms.


 0.4 ms.

  0.4 ms.

Flash SSD    

 1.7 ms.

 94.5 ms.



APEX support:

For APEX development support just call to get an Oracle Certified professional for all APEX development projects.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.