Page 36
RAID levels 2, 4, and 6 are rarely sold or implemented in industry. The mathematics behind the parity information for these levels is too computationally intense to be practical.
A final word about RAID. With regards to striping, RAID does what can be done manually with RDBMS and OS utilities and techniques. However, it usually does a better, finer-grained form of striping, and offers more features such as partitioning volumes (stripe sets), adjustable stripe sizes, and so forth. In addition, although the striping part of RAID can be done in a gross manner without much difficulty, you still have to manage those stripes. RAID usually excels at this and offers a single file interface in a virtual file system (VFS), leveraging OS file-level commands and utilities, as well as offering other features such as files larger than physical disk size.
Lastly, while you might be able to manage some form of striping, you have no safety net other than your standard backup and restore mechanisms. Whereas RAID will give you the tolerance to lose one disk and recover, it would be too complex for you to attempt to write this software that already exists.
Recommendation: Use gross, manual RDBMS or OS striping when availability is not a major concern. Otherwise, use RAID when you need the availability it offers, want even better performance through finer-grained stripes, or need its other features such as large files.
Most often in the past, DBMSs have always been accused of being I/O-bound, or disk-bound. This is the same as saying that a DBMS is bottlenecked in a system by its reading to and writing from disk. Studying the storage hierarchy we just covered, this is hardly a revelation. A disk has a much slower access speed than memory or CPU. And this actually has been the case for many database applications over the years. It is especially true for DSSs, VLDBs, and DWs, because huge amounts of data (GB) must be moved with single queries. However, this is not always the case. OLTP and OLAP (On-Line Analytical Processing) systems can often be memory- or CPU-bound.
If a database hardware server has a low memory-to-disk ratio, meaning that the application is memory-poor, that database will suffer considerably due to the lack of room in the memory for data and code caching. If a database application is of the OLAP type, such as a scientific database, number-crunching speed is of utmost importance. Hence, if that type of application runs on a server with a relatively weak CPU, performance will surely be poor in terms of user expectations (such as response time). The lesson here is that bottlenecks in any system, database systems included, are application-specific.
Finally, in client/server database systems, the network is the slowest component of the total system, slower even than disk. For a client/server system to function efficiently, proper application segmentation must occur, and the network must not be overloaded. Further, the network must be designed, like the other resources, to minimize contention. Further the network hardware and software should be modernized to take advantage of the current networking capabilities. We'll revisit all of these bottlenecks in Chapter 29, "Performance Tuning Fundamentals."
Page 37
When choosing what type of hardware database server and operating system is right for your application, there are many things to consider, including:
The current major RDBMS vendors are Oracle, Sybase, and Informix. CA has yet to do much with Ingres, and Microsoft only offers SQL Server on NT. Smaller, desktop databases aren't considered here. Now, considering only Oracle, UNIX and Windows NT are its two major platformsfor UNIX, specifically Sun Solaris. Oracle also ports to the other flavors of UNIX, of course. And Oracle also has some large installed bases on MVS and VMS. However, Solaris and Windows NT are its current top two porting priorities as of this writing.
As for hardware, Sun is the only real choice for Solaris, of course, not counting Intel machines. Sun has many available processors, but its latest is the UltraSPARC. Windows NT is predominantly found on Compaq, but also on DEQ and HP machines. The significant thing about Windows NT on DEC is that DEC offers both Alpha and Intel machines. Both Solaris and Windows NT can run on multiprocessing machines. However, Windows NT can only handle a limited number of processors (14), and its ability to scale flattens out at about 4 processors for Oracle. Solaris can scale very well past 20 processors, even for Oracle. Disk storage options are roughly equivalent, although some larger options are more readily available with Sun than with Compaq or HP. DEC, of course, can offer large storage like Sun.
Rather than getting further bogged down with hardware comparisons, let's make a recommendation: As a set of general guidelines, consider all the options listed earlier when trying to pick a platform. If your predominant environment is DEC/VMS and you're likely to stay there for a few more years, your next platform might as well be DEC/VMS, especially if you're only planning to buy one additional machine. If you're buying for a whole department and the risk is not critical, however, it might be time to consider Windows NT or UNIX.