Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We want to improve the performance of our oracle database which stores around 10 TB and is OLTP.

I noted that the Oracle server uses IDE hard drive, and have heard that SCSI is faster than IDE. Will switching over a server which uses SCSI improve performance of our queries and stored proc. updates?

PS: I am aware that it is important to look at other aspects of query optimization, but am looking for the hard disk aspect. I can also ask our DBA directly, but his answer would be biased depending on if he wishes to take the headache.

share|improve this question

migrated from stackoverflow.com Apr 6 '11 at 16:55

This question came from our site for professional and enthusiast programmers.

4 Answers 4

There are a lot of ways of improving Oracle performance through physical disk layout optimization.

Changing to a faster SCSI (or SATA) drive would definitely help. But you can also consider using multiple disk for your database to reduce I/O contention, placing indexes and tables in separate tablespaces (stored in separate disks) and several others. Oracle documentation is pretty good in this aspect. I would suggest you to read it.

share|improve this answer

The short answer to your question is you are probably barking up the wrong tree, swapping out you server hard drives will probably give you the smallest performance increase for the most amount of effort.

share|improve this answer
1  
hmm a downvote without comments. If you disagree with my opinion then it is considered polite to offer a counter argument. –  Ben Robinson Apr 6 '11 at 15:15

Highly doubtful.

"IDE" is a very generic term these days. What specific version/speed are you using? What hard disk are you using? What's your typical access pattern look like? What's your bottleneck?

A typical hard disk today might be a metal platter on SATA 2 (3 Gbps on the wire). The next SCSI version faster than this is Ultra640. I would say that SCSI drives tend to be rarer and more expensive and lower in capacity (so 10 TB would probably take a lot of drives!), but I don't think anybody makes a metal platter on Ultra640 at all.

A fast metal platter hard disk might be in the neighborhood of 0.5 Gbps for sequential reads, so even SATA 2 is many times faster than it. Seek time and latency could be a little bit lower for SCSI drives, but that depends entirely on the particular drive. If you're read-heavy, mirroring your existing drive could help with latency. If you're concerned about the hard disk's cache being faster than the interface wire speed, adding RAM would be a much easier and cheaper solution.

Again, you've not told us what your bottleneck is, so we can only guess, but it would have to be a pretty specific set of circumstances for the hard disk's wire protocol to make any difference at all.

Most of the very fastest drives available today are SSDs, which nobody seems to make in SCSI any more, and certainly not at any wire speeds greater than SATA 2. The fastest storage devices are solid state but go straight through PCI-Express. And companies like Google seem pretty concerned with performance but don't bother with expensive parts like SCSI.

share|improve this answer

With a database of 10T size, you probably have quite an array of disks under the storage. What is the problem. Are reads slow, or writes? Are single block reads slow or are scans slow? When did this slowness popup? What is the current disk configuration? Do you use a filesystem (which) or ASM? If you use ASM, how many disks are in, in how many groups? Do you have addm report available to study?

Your question is a bit vague and impossible to answer without knowing what you are trying to solve. SCSI drives might be quicker, can also be slower, depending how you configure the controllers ... hmm, you mentioned updates .... RAID-5?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.