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

 
 Home
 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
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

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

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Oracle Disk I/O Throughput Speed

 

Oracle Tips by Burleson Consulting

In a nutshell, an Oracle database is a mechanism to store and retrieve large volumes of data, and many end-users visualize Oracle as a big electronic filing cabinet.

This filing cabinet must be fast and people have come to expect sub-second response time.  These instant response time expectations are driven by tools like Google that can scan a billion web sites for keywords in a fraction of a second. 

But how do you make your Oracle system as fast as Google?  Speed is all about delivering the goods, and serving-up the data.

Also see rows per second Oracle throughput Tips.

Even while 64-bit technology and the accompanying large data buffers has reduced disk I/O bottlenecks, many database remain I/O-bound.  You can easily know if your database has significant disk I/O if your AWR of STATSPACK reports shows top-5 wait events that contain "db file sequential reads" (single I/O fetches) or "db_file_scattered_reads" (db_file_multiblock_read_count I/O fetches).

The standard measurement for disk is megabytes per second (MBps) and gigabytes per second (GBPS) and you can make your I/O faster by moving to a faster disk, using SSD, or caching the data inside large data buffers.

Let's explore the relative speeds of disk storage.  A PC laptop transfers data at about 15 MBps and the fastest disk for a PC is solid-state disk at 400 MBps.  In the larger server arena, we see SSD twice as fast as platter disk, with platter-based disk speeds ranging from 200-800 MBPS.

Large Server disk I/O speeds:

This is a list of disk I/O speeds in descending order, and, SSD leads the way for tertiary storage devices:

  • 50 MBps - IEEE1394 is the standard designation for a very fast external bus standard that supports data transfer rates of up to 400 Mbps (in 1394a) and 800 Mbps over copper (in 1394b). IEEE1394 a, in its peer-to-peer bus topology, allows 100 to 400 Mbps data transfer rates for up to 63 nodes, allowing 16 hops at 4.5  meters per hop.
     

  • 100 MBps - IEEE1394 b allows for higher speeds and longer distances. IEEE1394 b is completely compatible with IEEE1394 a providing up to 800 Mbps to 3200 Mbps data transfer over 4.5 meter copper and 100 Mbps over 100 meter copper. If used with Category 5 UTP wiring you can get 400 Mbps over 100 meter plastic optical fiber and 3200 Mbps over 100 meters of glass optical fiber.
     

  • 266 MBps - The Apple Xserve RAID’s list price for 5.6 TB is $12,999, or $2.32 per GB. Its performance is excellent. For a workload of 8KB random reads, it can sustain 1100 I/Os per second (IOPS). For a multi-user sequential workload, it can sustain 266 MBps of read throughput.
     

  • 1,600 MBps - SSD leads the pack in data transfer rates and speed (500,000 I/O's per second)
     

PC Oracle disk speeds:

  • 400-500 MBps - See Texas Memory Systems SSD devices.
     

  • 50-70 MBps - PC laptop SSD - Samsung says the SSD's outperforms a comparably sized HDD by more than 150 per cent. The company quotes the storage disk as reading data at 57 Mbytes per second (MBps) and writes at 32MBps.

Maximum Large MBPS=18.27

Maximum Large MBPS=25.65

  • 15-20 MBps - These reports from Doug Burns with a Windows XP Professional, SP2 laptop.

Maximum Large MBPS=18.27

In sum, most disk deliver data in the range of 200-800 MBPS and SSD can often halve the disk I/O latency.

Disk enqueues can occur when the disk is unable to quickly service concurrent requests.  Super-large disks can be problematic, and the most popular Oracle data files can be placed on the middle absolute track of the device to minimize read-write head movement.

 Disk I/O speed references:

This article from Mike Ault's book "Oracle Disk I/O Tuning, Disk IO Performance & Optimization for Oracle Databases", and great article by Doug Burns in "Doug's Oracle Blog".  These excerpts provide disk I/O speed comparisons.  Also, this informative SSD Speed page has details on solid-state disk technology.

Seeing disk I/O speed using STATSPACK


Here is sample output from a real system showing an empirical sample of average disk I/O speed.  We always expert scattered reads (full-table scans) to be far faster than sequential reads (index probes) because of Oracle sequential prefetch (db_file_multiblock_read_count):
 
col c1 heading 'Average Waits for|Full Scan Read I/O' format 9999.999
col c2 heading 'Average Waits for|Index Read I/O' format 9999.999
col c3 heading 'Percent of| I/O Waits|for scattered|Full Scans' format 9.99
col c4 heading 'Percent of| I/O Waits|for sequential|Index Scans' format 9.99
col c5 heading 'Starting|Value|for|optimizer|index|cost|adj' format 999
 
select
   sum(a.time_waited_micro)/sum(a.total_waits)/1000000 c1,
   sum(b.time_waited_micro)/sum(b.total_waits)/1000000 c2,
   (
      sum(a.total_waits) /
      sum(a.total_waits + b.total_waits)
   ) * 100 c3,
   (
      sum(b.total_waits) /
      sum(a.total_waits + b.total_waits)
   ) * 100 c4,
  (
      sum(b.time_waited_micro) /
      sum(b.total_waits)) /
      (sum(a.time_waited_micro)/sum(a.total_waits)
   ) * 100 c5
from
see code depot for full script
   dba_hist_system_event a,
   dba_hist_system_event b
where
   a.snap_id = b.snap_id
and
   a.event_name = 'db file scattered read'
and
   b.event_name = 'db file sequential read';
 
 
- scattered read (full table scans) are fast at 13ms (c3)
- sequential reads (index probes) take much longer 86ms (c4)
- starting setting for optimizer_index_cost_adj at 36:

C1         C2         C3         C4         C5
---------- ---------- ---------- ---------- ----------
13,824     5,072      13         86         36

 
Here is another variant, showing changes to optimizer_index_cost_adj wait components over time:

set pages 80
set lines 130
col c1 heading 'Average Waits for|Full Scan Read I/O' format 999999.999
col c2 heading 'Average Waits for|Index Read I/O' format 999999.999
col c3 heading 'Percent of| I/O Waits|for scattered|Full Scans' format
999.99
col c4 heading 'Percent of| I/O Waits|for sequential|Index Scans' format
999.99
col c5 heading 'Starting|Value|for|optimizer|index|cost|adj' format 99999

select a.snap_id "Snap",
       sum(a.time_waited_micro)/sum(a.total_waits)/10000 c1,
       sum(b.time_waited_micro)/sum(b.total_waits)/10000 c2,
       (sum(a.total_waits) / sum(a.total_waits + b.total_waits)) * 100 c3,
       (sum(b.total_waits) / sum(a.total_waits + b.total_waits)) * 100 c4,
       (sum(b.time_waited_micro)/sum(b.total_waits)) /
(sum(a.time_waited_micro)/sum(a.total_waits)) * 100 c5
from
see code depot for full script
   dba_hist_system_event a,
   dba_hist_system_event b
where a.snap_id = b.snap_id
and a.event_name = 'db file scattered read'
and b.event_name = 'db file sequential read'
group by a.snap_id
order by 1
/

 
  Snap       Full Scan Read I/O    Index Read I/O    Full Scans    Index Scans
 ---------- ------------------ ----------------- ------------- --------------
       5079               .936              .074         10.14          89.86  
       5080               .936              .074         10.14          89.86  
       5081               .936              .074         10.14          89.86  
       5082               .936              .074         10.14          89.86
       5083               .936              .074         10.13          89.87  
       5084               .936              .074         10.13          89.87  
       5085               .936              .074         10.13          89.87

This script will calculate Oracle I/O throughput in I/O per second (IOPS):

 select
    to_char(sn.end_interval_time,'yyyymmddhh24') the_date,
    sum(decode(sn2.startup_time,sn3.startup_time,(newreads.value-oldreads.value),newreads.value)) reads,
    sum(decode(sn2.startup_time,sn3.startup_time,(newwrites.value-oldwrites.value),newwrites.value)) writes,
    (sum(decode(sn2.startup_time,sn3.startup_time,(newreads.value-oldreads.value),newreads.value)))+
    (sum(decode(sn2.startup_time,sn3.startup_time,(newwrites.value-oldwrites.value),newwrites.value)))
total
from
    dba_hist_sysstat  oldreads,
    dba_hist_sysstat  newreads,
    dba_hist_sysstat  oldwrites,
    dba_hist_sysstat  newwrites,
    dba_hist_snapshot sn,
    dba_hist_snapshot sn2,
    dba_hist_snapshot sn3
where
see code depot for full script
group by
       to_char(sn.end_interval_time,'yyyymmddhh24')
order by
       to_char(sn.end_interval_time,'yyyymmddhh24')
;


Here is another PL/SQL script so calculate the I/O per second:

rem FUNCTION: PL/SQL to calculate IO/sec data
rem Mike Ault
rem

set serveroutput on
declare
cursor get_io is select
nvl(sum(a.phyrds+a.phywrts),0) sum_io1,to_number(null) sum_io2
from sys.gv_$filestat a
union
select
to_number(null) sum_io1, nvl(sum(b.phyrds+b.phywrts),0) sum_io2
from
sys.gv_$tempstat b;
now date;
elapsed_seconds number;
sum_io1 number;
sum_io2 number;
sum_io12 number;
sum_io22 number;
tot_io number;
tot_io_per_sec number;
fixed_io_per_sec number;
temp_io_per_sec number;
begin
see code depot for full script
open get_io;
for i in 1..2 loop
fetch get_io into sum_io1, sum_io2;
if i = 1 then sum_io12:=sum_io1;
else
sum_io22:=sum_io2;
end if;
end loop;
select sum_io12+sum_io22 into tot_io from dual;
select sysdate into now from dual;
select ceil((now-max(startup_time))*(60*60*24)) into elapsed_seconds from gv$instance;
fixed_io_per_sec:=sum_io12/elapsed_seconds;
temp_io_per_sec:=sum_io22/elapsed_seconds;
tot_io_per_sec:=tot_io/elapsed_seconds;
dbms_output.put_line('Elapsed Sec :'||to_char(elapsed_seconds, '9,999,999.99'));
dbms_output.put_line('Fixed IO/SEC:'||to_char(fixed_io_per_sec,'9,999,999.99'));
dbms_output.put_line('Temp IO/SEC :'||to_char(temp_io_per_sec, '9,999,999.99'));
dbms_output.put_line('Total IO/SEC:'||to_char(tot_io_Per_Sec, '9,999,999.99'));
end;
/


The following sample output from io_sec.sql displays the total elapsed seconds since the database was started, the I/O per second for both temporary I/O and fixed I/O as well as the total I/O per second. The report should be run periodically to determine if I/O rates are fluctuating. A version of this report that uses STATSPACK data is also available so that interval I/O rates can be determined.

Elapsed Sec : 2,183,399.00
Fixed IO/SEC: 190.96
Temp IO/SEC : .00
Total IO/SEC: 190.96

PL/SQL procedure successfully completed.


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
InfiniBand

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

PCIe

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

Fibre Channel
SAS
SCSI

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.

DRAM SSD

 0.4 ms.

  0.4 ms.

Flash SSD    

 1.7 ms.

 94.5 ms.

 

Additional information on Oracle response time components is available HERE.


 

 

��  
 
 
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.