The database server can use regular operating-system files to store data. On operating systems that support raw disks, the database server can also use raw disk space to store data. It is recommended that you use raw disks to store data whenever performance or data consistency is important.
You can allocate disk space in two ways:
Unbuffered disk access can be through a raw disk device, or character-special files. As a general guideline, you experience better performance and increased reliability when you use unbuffered file access.
On UNIX, the raw disk interface that character-special files provide yields significant performance advantages. I/O to raw disk bypasses the buffering operations that the operating system performs on regular (cooked) files.
UNIX uses the concept of a device to describe peripherals such as magnetic disks and tapes, terminals, and communication lines. One type of device is a block device, such as a hard disk or a tape. A block device can be configured with an interface that provides buffering or with a raw interface that leaves the buffering to the application. When you configure a block device with a raw interface, the device is called a raw device, and the storage space that the device provides is called raw disk space. Space in a chunk of raw disk space is physically contiguous.
A raw interface is also referred to as a character-special device. The name of the chunk is the name of the character-special file in the /dev directory. In many operating systems, you can distinguish the character-special file from the block-special file by the first letter in the filename (typically r). For example, /dev/rsd0f is the character-special device that corresponds to the /dev/sd0f block-special device.
A cooked file is a regular file that the operating system manages. Although the database server manages the contents of cooked files, the operating system manages all I/O to cooked files. Unlike raw disk space, the logically contiguous blocks of a cooked file might not be physically contiguous.
Even though a cooked file is a regular file, the database server manages the internal arrangement of data within the file. Never edit the contents of a cooked file that the database server manages. To do so puts the integrity of your data at risk.
When the operating system reads from a cooked file, it reads the data from disk to an internal buffer pool. Later, a second copy operation copies it from the operating system to the location requested by the application. Therefore. when two users both read the same file, the data is read from disk only once but copied from the operating-system buffer twice.
By contrast, when the operating system reads data from an unbuffered file or a raw disk device, it bypasses the operating-system buffer pool and copies the data directly to the location requested by the application. The database server requests that the data be placed in shared memory, making it immediately available to all database server virtual processors and running threads with no further copying.
A raw device or unbuffered file can directly transfer data between shared memory and the disk with direct memory access (DMA), which results in better performance by orders of magnitude.
When you use a raw device or unbuffered file to store your data, the database server guarantees that committed data is stored on disk. (The next section explains why no such guarantee can be made when you use cooked files to store your data.)
When you decide to allocate raw disk space to store your data, you must take the following steps:
For more information on these steps, see Allocating Raw Disk Space on UNIX.
You can more easily allocate cooked files than raw disk space. To allocate raw space, you must have a disk partition available that is dedicated to raw space. To allocate a cooked file, you need only create the file on any existing partition. However, you sacrifice reliability and might experience diminished performance when you store the database server data in cooked files.
The buffering mechanism that most operating systems provide can become a performance bottleneck. If you must use cooked UNIX files, store the least frequently accessed data in those files. Store the files in a file system located near the center cylinders of the disk device or in a file system with minimal activity.
In a learning environment, where reliability and performance are not critical, cooked files can be convenient.
When performance is not a consideration, you can also use cooked files for static data (which seldom or never changes). Such data is less vulnerable to the problems associated with UNIX buffering in the event of a system failure.
When a chunk consists of cooked disk space, the name of the chunk is the complete pathname of the file. Because the chunk of cooked disk space is an operating-system file, space in the chunk might not be physically contiguous.
When you decide to allocate cooked space to store your data, you must take the following steps:
These steps are described in detail in Allocating a File for Disk Space on UNIX.
The system administrator might divide a physical disk into partitions, which are different parts of a disk that have separate pathnames. Although It is recommended that you use an entire disk partition when you allocate a chunk on a raw disk device, you can subdivide partitions or cooked files into smaller chunks using offsets. For more information, see Strive to Associate Partitions with Chunks.
An offset allows you to indicate the number of kilobytes into a device or cooked file to reach a given chunk. For example, suppose that you create a 1000 kilobyte chunk that you want to divide into two chunks of 500 kilobytes each. You can use an offset of zero kilobytes to mark the beginning of the first chunk and an offset of 500 kilobytes to mark the beginning of the second chunk.
You can specify an offset whenever you create, add, or drop a chunk from a a dbspace.
On Extended Parallel Server, the maximum chunk size and offset can be 4 gigabytes or even larger for 64-bit platforms. To determine which chunk size your platform supports, refer to your machine notes file.
You might also need to specify an offset to prevent the database server from overwriting partition information. Allocating Raw Disk Space on UNIX explains when and how to specify an offset.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]