Optical Disk and Tape Systems

WORM (write-once, read-many) or MWMR (multiple-write, multiple-read) optical disks can be used to great advantage in an Oracle system. Their main use will be in storage of export and archive log files. Their relative immunity to crashes and their long shelf life provide an ideal solution to the storage of the immense amount of data that proper use of archive logging and exports produce. As access speeds improve, these devices will be worth considering for these applications with respect to Oracle. They have also shown great benefits in read-only tablespaces and in transportable tablespace sets, a new feature of Oracle8i and 9i,.

Tape Systems 

Nine-track, 4mm, 8mm, and the infamous TK series from DEC can be used to provide a medium for archive logs and exports. One problem with doing so, however, most installations require operator monitoring of the tape devices to switch cartridges and reels. With the advent of stacker-loader drives for the cartridge tapes, and tape libraries such as those provided by StorageTek, this limitation has all but been eliminated in all but the smallest shops.

Random Access Memory (RAM) Drives

Though RAM drives have been around for several years, they have failed to gain the popularity their speed and reliability would seem to warrant. One reason has been their small capacity in comparison to other storage mediums. Several manufacturers offer solid-state drives of steadily increasing capacities. For index storage, these devices are excellent. Their major strength is their innate speed. They also have onboard battery backup sufficient to back up their contents to their built-in hard drives. This backup is an automatic procedure invisible to the user, as is the reload of data upon power restoration.

The major drawback to RAM drives is their high cost. However, rapid reductions in memory chip costs, along with the equally rapid increase in the amount of storage per chip, may soon render this drawback nonexistent. Use of RAM drives for temporary tablespaces and index tablespaces, as well as for lookup and easily rebuilt tables, could increase processing speeds severalfold. At last check the cost for a RAM drive in the 16 gigabyte capacity range was about $20,000.00 so beware, they are pricey!

System Considerations

Within each Oracle installation there are several operating system considerations that must be taken into account. These affect how Oracle uses global memory and processes memory areas. The DBAs will be responsible for tuning and maintaining these areas.

What Is an SGA and How Does It Apply to You?

SGA is an abbreviation for Shared Global Area. As the term global implies, this area is accessible to all Oracle processes and users. Each instance will have its own SGA. Oracle processes and users must share large amounts of data. If all of the processes had to get the data from the disk, the I/O load would soon render totally unacceptable response times. To prevent this, Oracle uses global memory areas, that is, CPU memory. This memory is dedicated to use for Oracle alone. In Oracle8i, the SGA contains data buffer areas, redo log buffers, and the shared pool (context areas). Each area is important to the database's overall performance. An additional area, the LARGE POOL, is also configured. Under Oracle8i, another area has been added, the Java shared pool area. Oracle9i has the capability to divide the database buffer regions into multiple varying block sized areas (2K, 4K, 8K, 16K and 32K block sizes are supported).

The shared pool context areas and database buffers provide immediate access to data that has been preread from either the data dictionary tables or the data tables. The Oracle kernel process uses an LRU (least recently used) algorithm to write data back to the disks. Data is never altered on the disks directly; it is altered in memory first. In Oracle8 the ability to have areas where LRU aging was turned off, know as the KEEP area and where LRU aging was accelerated, known as the RECYCLE area were added.

The redo buffers contain row change information, transaction commit history, and checkpoint history. This data is written into the redo logs and eventually to the archive logs. A commit will force a disk write, as will the filling of a redo log buffer or the reaching of a predefined checkpoint.