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 


 

 

 


 

 

 

 

 

Why disks are obsolete

Oracle Database Tips by Donald Burleson

By Mike Ault

When will disk manufacturers join the rest of the industry? When you look at their specification sheets they do things like "320 Gigabyte Capacity (unformatted)" then you read further and in the footnotes it says "gigabyte is defined as 1000000000 bytes" so what does this really mean?

If you do the math, for the rest of the computer industry, a gigabyte is 1024 bytes cubed or 1073741824 bytes. This means the unformatted capacity of the drive is about 298 gigabytes or less. Assuming you only lose about 10% for formatting, this leaves you with 268 gigabytes, doesn't sound near as impressive as 320 does it?

And how about stated transfer rates? On one manufacturers site they state that their disk can transfer data at 200 Mbytes per second on a fibre channel loop and about 320 Mbytes per second on a SCSI connection. Of course these numbers are really the transfer rates of the interface itself.

When you look at the manuals it gives the true details, the maximum sustained transfer rate of the drive is actually 76 Mbyte/sec (with M being 1,000,000) so to the rest of the industry this is actually 72.5 Mbyte/sec. So to actually achieve the 200 Mbytes/sec (of course this is real Mbytes) you would need 3 of the drives. Since most systems will read a megabyte at a time, this 72.5 Mbyte/sec is roughly 73 IO/second.

Is it any wonder I go to site after site with I/O issues? No wonder folks are confused. When you figure disk capacity in the last 20 years has gone from 30 megabytes on a hard drive to 300-500 gigabytes (a factor of 17067 increase) while disk transfer rates have only gone up by a factor of 20 or so it isn't hard to see why people have difficulty specifying their disk systems in a meaningful way.

For example, I ran a report at a client that shows the Oracle system was performing an average of 480 IO/sec (taking the IO statistics from the v$filestat and v$tempstat views and the elapsed seconds since startup) realizing this is an average, I double this value to get a peak load (I know, that is probably too low) of 960 IO/sec.

From our previous calculations if we use the 320 gig (right) disk, we will need 960/73 or 14 disks to support this systems peak IO load. Currently they use 4 drives and as load increases IO read times go from 2-3 milliseconds to over 20 milliseconds. The amount of data the system has is just less than a terabyte so in order to sustain the needed peak IO rate they need to buy 3.752 terabytes of disk, not even allowing for RAID10, or RAID5.

Kind of like having a huge dump truck with a Volkswagen beetle engine isn't it? Unfortunately the disk manufacturers are coming up against the laws of physics, someone needs to tell them bigger is not better. We end up buying much more capacity than is needed just to get the IO rates we require.

Yes, I know there is caching both at the disk level and usually the array level, but many times this is only a few gigabytes. Shoot, anymore the reference tables in a large database will fill up the cache area and then you are back to disk speeds for access times.

With 500 (419 usable) gigabyte drives many of my client systems would fit on one drive if all we had to consider was volume, however you and I both know there are two sides to the capacity issue. You need to look at both disk volume and disk IO capacity. Another wrench in the works is the needed number of disks to support concurrent access.

Believe me, while you can put a terabyte database on 3 of these huge drives you won't support more than a couple of concurrent users before performance suffers.

So when you do your next disk purchase consider true formatted size and actual IO speed and compare that to your real IO requirements. Generally if you meet your needed IO and concurrent access requirements, you will more than meet the needed disk volume needs for your application.

 
Get the Complete
Oracle SQL Tuning Information 

The landmark book "Advanced Oracle SQL Tuning  The Definitive Reference"  is filled with valuable information on Oracle SQL Tuning. This book includes scripts and tools to hypercharge Oracle 11g performance and you can buy it for 30% off directly from the publisher.

 

 

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

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational