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


When a System Will Not Benefit From Moving to SSD

The move to SSD assets from standard SCSI, ATA or SATA disks can be a blessing when it answers a specific performance problem related to disk I/O saturation. However, one must be careful when diagnosing the I/O related problems on a system. This section will provide some example STATSPACKs and use them to show whether or not there is a benefit to moving to SSD assets.

The following listing includes an events report for a system that will not benefit from SSD:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                        1,127    73.25
global cache cr request                           213,187         122     7.95
db file sequential read                           152,521          96     6.27
control file sequential read                      118,104          78     5.06
SQL*Net message from dblink                           890          38     2.48

The system in the above listing spends 73% of its time in the CPU with only 11 percent of the time spent waiting on disks. If the system were tuned to eliminate the CPU bottleneck, chances are the bottleneck will move to the disks and at that time, it would benefit from SSD technology. As the system in the listing stands right now, moving to SSD could actually hurt performance as it would place more stress on the already over worked CPU assets.

In the next example, the move to SSD might be beneficial since there is reserve CPU capacity of 40%, and it is spending the other wait time waiting on disks as shown in the following listing:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                        1,300    60.46
db file sequential read                           342,625         616    28.67
db file scattered read                             12,986          66     3.07
log file parallel write                             2,889          65     3.03
db file parallel write                              1,080          59     2.75

The system in the above listing indicates index and table stress as well as stress on log files. Assuming that the sample amount of time in the STATSPACK is representative of the overall system performance, the DBA needs to look further to determine what should be moved, tables or indexes, to the SSD asset.  The file I/O profile from this same report is shown in the following listing:

                 Av      Av     Av                    Av        Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
        12,680       4    6.7     1.0       18,943        6          0    0.0
        30,282      10    3.0     2.5          623        0          0    0.0
            14       0   35.7     1.0       28,733        9          0    0.0
         2,799       1    4.5     1.0       18,038        6          0    0.0
        16,604       5    1.8     1.0            8        0          0    0.0
         7,560       2    1.6     1.0           18        0          0    0.0
         6,242       2    2.0     1.2           36        0          0    0.0
         5,636       2    1.5     1.0            4        0          0    0.0
         4,240       1    2.0     1.0            4        0          0    0.0
         3,812       1    2.1     1.0            4        0          0    0.0
         3,656       1    1.6     1.0            4        0          0    0.0

The heavy-hitters in this listing are the srcd, system, nomad, tst_globallx and tst_globald tablespaces. The actual report from which the listing is extracted is over ten pages long for this section on datafiles, but these are the largest contributors to the I/O profile.  Analysis of the system showed improper use of the SYSTEM tablespace.  Once this was corrected, the others were left as the I/O stress points. Moving the heavy hitters to an SSD asset would do the following for this system:

  • Shift the load to the CPUs

  • Reduce I/O stress on the I/O subsystem allowing other datafiles to be accessed more efficiently.

  • Speed access to the data/indexes contained in the moved datafiles.

The above benefits might actually provide greater than the percentage benefit quoted above. One of the other waits deals with redo log files, specifically log file parallel write.  Since this is a log file write specific wait, moving the redo logs would also show some benefit but not as great as that shown by moving tables and indexes.

The following listing provides a false positive indicator for use of SSD:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                         6,261,550         691    96.72
control file parallel write                         1,274          19     2.73
CPU time                                                            2      .24
db file parallel write                                 28           1      .14
db file scattered read                              2,248           1      .12

What is a false positive indicator? In this case, the STATSPACK seems to indicate that the database is doing a lot of full table scans and that this is 96-97 percent of wait times, which should indicate a move to SSD would be beneficial. However, a review of the entire report should be conducted.  The header for the file is shown in the following listing:

STATSPACK report for 

DB Name         DB Id    Instance     Inst Num Release     Cluster Host
------------ ----------- ------------ -------- ----------- ------- -----------
TSTPRD        3265066449 tstprd              1   NO      test08 

            Snap Id     Snap Time      Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------

Begin Snap:       3 09-Nov-03 13:20:20       10       2.1
  End Snap:       4 09-Nov-03 14:26:01       10       2.1

Elapsed:               65.68 (mins)


Cache Sizes (end)
               Buffer Cache:        24M      Std Block Size:         8K
           Shared Pool Size:        48M          Log Buffer:       512K

The tiny size for the buffer cache and shared pool should be noted along with the restricted time period monitored. Unless the server has severe memory limitations, the company using this database would be better off increasing the memory allocated to the instance and then looking at SSD if the waits are still an issue. The small elapsed time indicates that this STATSPACK run was probably for a specific transaction and is not indicative of full system load.

While a move to SSD may benefit many systems, the DBA should carefully review all information to ensure that another fix is not more appropriate.

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.



HTML-DB support:

For HTML-DB development support just call to get an Oracle Certified professional for all HTML-DB 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.