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


Allocating Oracle Objects into Multiple RAM Data Buffers

Since very few Oracle databases can afford the cost of full RAM caching, many rules of thumb have been developed for the segregation and isolation of cached objects.  Some of these rules of thumb will yield clues about the best way to utilize SSD in a solid-state Oracle environment:

  • Segregate large-table full-table scans: Tables that experience large-table full-table scans will benefit from the largest supported block size and should be placed in a tablespace with the largest block size.

  • Use the RECYCLE Pool: If db_cache_size is not being set to the largest supported block size for the server, the db_recycle_cache_size  parameter should not be used. Instead, a db_32k_cache_size, or whatever the user's max is, should be created and all tables that experience frequent large-table full-table scans should be assigned to the largest buffer cache in the database.

  • Segregate Indexes:  In many cases, Oracle SQL statements will retrieve index information via an index range scan, scanning the b-tree or bitmap index for ranges of values that match the SQL search criteria. Hence, it is beneficial to have as much of an index residing in RAM as possible. One of the first things the Oracle 9i DBA should do is to migrate all of their Oracle indexes into a large blocksize tablespace. Indexes will always favor the largest supported blocksize.

  • Segregate random access reads: For those databases that fetch small rows randomly from the disk, the Oracle DBA can segregate these types of tables into 2K tablespaces. While disk is becoming cheaper every day, it is still not wise to waste any available RAM by reading in more information to RAM than is actually going be used by the query. Hence, many Oracle DBAs will use small block size is in cases of tiny, random access record retrieval.

  • Segregate LOB column tables: For those Oracle tables that contain raw, long raw, or in-line LOBs, moving the table rows to large block size will have an extremely beneficial effect on disk I/O. Experienced DBAs will check dba_tables.avg_row_len to make sure that the blocksize is larger than the average size. Row chaining will be reduced while at the same time the entire LOB can be read within a single disk I/O, thereby avoiding the additional overhead of having Oracle to go out of read multiple blocks.

  • Segregate large-table full-table scan rows: When the recycle pool was first introduced in Oracle8i, the idea was the full-table scan data blocks, which are not likely to be reread by other transactions, could be quickly flushed through the Oracle SGA thereby reserving critical RAM for those data blocks which are likely to be reread by another transaction. In Oracle9i, the RECYCLE pool can be configured to use a smaller block size.

  • Check the average row length: The block size for a table's tablespace should always be greater than the average row length for the table, dba_tables.avg_row_len. Not only is it smaller than the average row length, rows chaining occurs and excessive disk I/O is incurred.

  • Use large blocks for data sorting: The TEMP tablespace will benefit from the largest supported blocksize. This allows disk sorting to happen in large blocks with a minimum of disk I/O.

These suggestions are very important to the study of the best way to utilize SSD as an alternative caching mechanism.

However, recent TPC-C benchmarks make it clear that very large RAM regions are a central component in high performance Oracle databases.  The 2004 UNISYS Oracle Windows benchmark exceeded 250,000 transactions per minute using a Windows-based 16-CPU server with 115 gigabytes of Oracle data buffer cache.  The following are the Oracle parameters that were used in the benchmark, and the benefit of large scale RAM caching is clear:

  • db_16k_cache_size  = 15010M

  • db_8k_cache_size  = 1024M

  • db_cache_size  = 8096M

  • db_keep_cache_size  = 78000M

At this point, it is very clear that RAM resources are an important factor in maintaining the performance of I/O intensive 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.

Oracle RAC & Tuning with Solid State Disk
Expert Secrets for High Performance Clustered Grid Computing

Includes Oracle10g!
Get immediate access to working code examples

Buy it now for 30% off - Only $9.95

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.




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.