Справочник Пользователя для IBM 000-8697

Installation and Initial Configuration

Cooked files are unreliable because

I/O

 on a cooked file is managed by the

UNIX

 operating system. A write to a cooked file can result in data being

written to a memory buffer in the

UNIX

file manager instead of being written

immediately to disk. As a consequence,

UNIX

 cannot guarantee that the

committed data has actually reached the disk. This is the problem. OnLine
recovery depends on the guarantee that data written to disk is actually on
disk. If, in the event of system failure, the data is not present on disk, the
OnLine automatic recovery mechanism could be unable to properly recover
the data. (The data in the

UNIX

 buffer could be lost completely.) The end

result could be inconsistent data.

Performance degrades if you give up the efficiency benefits of OnLine-
managed

I/O

. If you must use cooked

UNIX

 files, try to store the least

frequently accessed data in the cooked files. Try to store the files in a file
system that is 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 concerns, cooked files are acceptable. (Since
OnLine manages the internal arrangement of data, you cannot edit the
contents of a cooked file.)

Significant performance advantages and increased data reliability are
ensured when OnLine performs its own disk management on raw disk space.

Raw disk space appears to your

UNIX

 operating system as a disk device or

part of a disk device. In most operating systems, the device is associated with
both a block-special file and a character-special file in the /dev directory.

When you link your raw disk space to an OnLine chunk pathname, verify
that you use the character-special file for the chunk name, not the block-special
file. (The character-special file can directly transfer data between the address
space of a user process and the disk using direct memory access (DMA),
which results in orders-of-magnitude better performance.)

This section applies only if you are configuring OnLine for a production
environment. The first step in answering the question “How much space?” is
to calculate the size requirements of the root dbspace. The second step is to
estimate the total amount of disk space to allocate to all OnLine databases,
including space for overhead and growth.