There are two key concepts associated with RAID. The first is mirroring. Here you store the same information on multiple disk drives. The thought behind this is that if you lose one of the disk drives due to a hardware failure, you still have your data online and available from the other disk drive. When you repair the physical problem with the failed disk drive, you copy the contents of the working disk drive to this drive to resynchronize (resilver) their contents. Mirroring is the key to reliability in a RAID system.

The second concept associated with RAID is striping. Here you scatter the contents of a single file sequentially across multiple disk drives. You can then read block 1 from disk 1, block 2 from disk 2 and so forth. Striping provides speed in that you are now working multiple disk drives in parallel to read a single file, thereby eliminating bottlenecks associated with the data transfer speed of a single disk drive.

The next topic that I want to touch on is RAID levels. Mirroring is RAID level 0 and striping is RAID level 1. If you use both mirroring and striping, it is referred to as RAID 0 plus 1. However, there are also RAID levels 2 through 5. These RAID levels are alternatives to mirroring that provide much the same protection. It costs twice as much to make two copies of a given data file on two disk drives. If you work through some storage algorithms, you can find ways to scatter the information across multiple disk drives with check sums that would enable you to reconstruct data that might be lost if a given physical disk drive were to fail. That way, you have to spend some time calculating these check sums, but you save disk space. The most common RAID level other than 0 and 1 that you will run across is RAID level 5. With this technology you can use approximately 75 to 80 percent of the total disk storage space for storing your data as opposed to 50 percent utilization if you were mirroring your data.

There are a couple of other concepts associated with RAID that you should be aware of when planning the installation of your database. Some systems implement RAID at the hardware level. Here disk controllers take care of the functions such as making copies of the data or calculating check sums. Hardware RAID tends to be faster and does not add an extra burden to your CPU. Software RAID, on the other hand, uses operating system software to implement the RAID algorithms.

One final concept that you should be aware of when planning your database system is that of warm recovery. This is usually associated with hardware RAID arrays. What this enables you to do is remove a bad disk from an operating system and replace it with a new disk. The RAID array senses the new disk and automatically resilvers the new disk with the correct content. This can be important on systems were you have to be up a high percentage of the time.

So why did I put all of this hardware stuff in the midst of an Oracle planning chapter? Some Oracle databases are used to support the most critical systems at organizations. If the database is down, the business is down. Oracle internally has a number of features that promote a high degree of availability. However, there are also system options that can be used in conjunction with Oracle options to provide the needed reliability.

Processing Options

Even though it is not really required in the basic Oracle installation procedure, take a little time to plan out the processes that you will be using in your Oracle instances. The installer will create an instance for you that is running the four basic Oracle processes: Process Monitor (PMON), system monitor (SMON), log writer (LGWR), and database writer (DBWR). However, because you have spent so much time planning out your disk and memory usage, take a little time to consider the other processes that you may want to start up as part of the post-installation activities that you will perform.

Recall the introductory discussion of the Oracle processes in Chapter 2, “Oracle Database Architecture.” The following are some of the additional processes that you may want to configure via the initialization files and the rationale for using them:

•  Multithreaded server processes. These processes enable multiple users to use a single set of server processes. These processes eliminate the need for dedicated server processes for users who are not all that active on the system. Consider these on all systems that use SQL*Net and have a relatively large number of users connecting to the system.

•  Multiple database writer processes. Consider these if you have write operations that go to multiple disk drives and you have a relatively large write volume on operating systems that do not have asynchronous input/output capabilities.

•  Checkpoint process. Use this process only when your log writer process is having trouble keeping up with the volume of checkpoints.

•  Archiver. This process is needed if you want to be able to guarantee recovery from the loss of a disk drive (or pair in the case of mirrored disks).

•  Recoverer. This process comes into play only when you are implementing a distributed database.

•  Net/8 listeners. If you are planning a client/server installation, you need to start up Net/8 listeners for each of the versions and protocols of Net/8 that you are using.

•  Parallel query processes. Consider this option when you have databases that execute heavy queries. Typically, this is used in applications such as data warehouses.