The database server can use regular operating-system files or raw disk devices to store data. On UNIX, you should use raw disk devices to store data whenever performance is important. On Windows, using NTFS files to store data is recommended for ease of administration.
An Informix storage space can reside on an NFS-mounted file system using regular operating-system files.
On Windows, both raw disks and NTFS use kernel asynchronous I/O (KAIO). The Windows file system manager adds additional overhead to disk I/O, so using raw disks provides slight performance advantages. Because NTFS files are a more standard method of storing data, you should use NTFS files instead of raw disks. Consider using raw disks if your database server requires a large amount of disk access.
On Windows, raw disk space can be either a physical drive without a drive letter or a logical disk partition that has been assigned a drive letter using the Disk Administrator. The space can either be formatted or unformatted. If it contains data, the data will be overwritten after the space has been allocated to the database server. For more information, see Allocating Raw Disk Space on Windows.
You must use NTFS files, not FAT files, for disk space on Windows. For more information, see Allocating NTFS File Space on Windows.
You can allocate disk space in two ways:
When dbspaces reside on raw disk devices (also called character-special devices), the database server uses unbuffered disk access. Performance is much better when you use raw disk devices than cooked files because the database server has direct I/O access to the devices. A raw disk directly transfers data between the database server memory and disk without also copying data.
To create a raw device, configure a block device (hard disk) with a raw interface. The storage space that the device provides is called raw disk space. A chunk of raw disk space is physically contiguous.
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.
For more information, see Allocating Raw Disk Space on UNIX.
A cooked file is a regular file that the operating system manages. Cooked file chunks and raw disk chunks are equally reliable. Unlike raw disk space, the logically contiguous blocks of a cooked file might not be physically contiguous.
You can more easily allocate cooked files than raw disk space. To allocate a cooked file, you need only create the file on any existing partition. The name of the chunk is the complete pathname of the file. These steps are described in detail in Allocating Cooked File Spaces on UNIX.
In a learning environment, where performance is not critical, or for static data, cooked files can be convenient. If you must use cooked UNIX files, store the least frequently accessed data in those files. Store the files in a file system with minimal activity.
For cooked file chunks, the operating system processes all chunk I/O from its own buffer pool and ensures that all writes to chunks are physically written to the disk.
When using raw disks, you do not need to take any special action to create chunks and files that are larger than two gigabytes. If you want to create large chunks in cooked files, or if you want to use the various database export and import utilities with large files, you must ensure that the files systems that will hold the large files are properly configured.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]