This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
Raw Devices have been in use for
a very log time. They were the primary storage structures for data
files of the Oracle Parallel Server. They remain in use even in the
RAC versions 9i and 10g. Raw Devices are difficult to manage and
administer but provide high performing shared storage structures.
When using the raw devices for data files, redo log files, and
control files, it may be necessary to use the local file systems or
some sort of network attached file system for writing the archive
log files, handling the utl_file_dir files and files supporting the
The following is an example
where raw devices are still in use. When a RAC database is
implemented on Solaris platform with Sun Cluster software, raw
devices will have to be used as the shared storage for database
files. Of course, if using the Veritas DB edition for Cluster on
Solaris platform, the Veritas Cluster File system can be used and
this provides more options.
Figure 5.4 shows the various
types of Oracle related files located on raw devices and non-raw
Figure 5.4: Using raw
devices for shared storage structures
A raw device, also known as a
raw partition, is a disk partition that is not formatted.
Applications issue I/O calls to transfer data directly from buffers
in the user virtual address space to disk. There is no operating
system buffering (e.g., page cache), nor is write-order locking
imposed. The I/O transfers are conducted through the
character-special device driver. As such, I/O transfers generally
must adhere to strict requirements imposed by the device driver such
as alignment and I/O size and file offsets.
Raw partitions have several
* They are not subject to any
operating system locking.
* The operating system buffer or
cache is bypassed, giving performance gains and reduced memory
* Multiple systems can be easily
* The application or database
system has full control to manipulate the internals of access.
* Historically, the support for
asynchronous I/O on UNIX systems was generally limited to raw
The creation and usage of raw
partitions should be carefully planned, even if the creation and
administration of the raw volumes is relatively simple with the use
of the logical volume manager.
Issues and Difficulties
There are many administrative
inconveniences and drawbacks such as:
* The unit of allocation to the
database is the entire raw partition. A raw partition cannot be used
for multiple tablespaces. A raw partition is not the same as a file
system where many files can be created.
* Administrators have to create
them with specific sizes. When the databases grow in size, raw
partitions cannot be extended. Partitions need to be added to
support growing tablespaces. Sometimes there may be limitations on
the total number of raw partitions that can be used in the system.
Furthermore, there are no database operations that can occur on an
individual data file. There is, therefore, no logical benefit from
having a tablespace consist of many data files except for those
tablespaces that are larger than the maximum Oracle can support in a
* The standard file manipulation
commands cannot be used on raw partitions, and therefore on the data
files. Commands such as cpio or tar cannot be used for backup
purposes. Backup strategy will become more complicated.
* Raw partitions cannot be used
for writing the archive logs.
* Administrators need to keep
track of the raw volumes with their cryptic naming conventions.
However, by using symbolic links, the DBA can reduce the hassles
associated with names.
For example, a cryptic name like
/dev/rdsk/c8t4d5s4 or a name like /dev/sd/sd001 is an administrative
challenge. To alleviate this, administrators often rely on symbolic
links to provide logical names that make sense. This, however,
substitutes one complexity for another.
In a clustered environment like
Linux clusters, it is not guaranteed that the physical devices will
have the same device names on different nodes or across reboots of a
single node. To solve this problem, manual intervention is needed
that increases administration overhead.