Network Storage for Databases

Database systems can function either as filing entities in storage networks or as applications that use the services of a file system. The remainder of this chapter briefly discusses the relationship between databases and file systems.

Database Filing: Raw Partitions

Databases that provide their own filing functions are said to be running "raw partitions." A raw partition is a storage address space that is unoccupied by a file system. The way it is commonly used in the context of database discussions, raw partition implies a storage address space managed by a database system and accessed through its own internal layout reference system.

Until recently, database administrators (DBAs) favored using raw partitions for the performance advantages they offered. The rationale used for raw partitions was that the database system had the most efficient processes for locating its own data on disk and that working through a file system to locate data was too slow.

The other problem with storing database data in a file system was the risk that the file system would cache data in system buffers and not write it to disk immediately. A system crash that prevented data from being flushed to storage would result in the loss of data consistency and the ensuing long and costly work restoring the database to a functioning state.

Storing Databases on File Systems

The problem with using raw partitions is data management. All storage and data management processes with raw partitions must use facilities provided in the database, because there is no other way to identify database components in storage. These database internal processes tend to take a long time to run and can severely impact the performance of the database while they are running.

As it turns out, most DBAs run their databases on file system storage because it is much more flexible than raw partitions. In addition, data management applications like backup and recovery are much simpler if the database is being run on a file system. This is not a problem as long as file system caching does not risk data consistency by holding write data in system cache. A facility called direct I/O is used with some databases to ensure write caching is not used by a file system storing database data.

The storage software company Veritas has a technology called Quick I/O that creates a virtual raw partition within a special file in the Veritas VxFS file system. The Quick I/O file is mounted like a device by the database system, which accesses it like a raw partition. However, the contents of the file can be copied during backup or other data management processes just like any other file.

Oracle 10g Automated Storage Manager

The newest version of the Oracle database system, Oracle 10g, ships with a facility called Automated Storage Manager (ASM). ASM provides a volume manager function to create storage address spaces from available storage and then creates a proprietary Oracle file system to store database files, in accordance with Oracle database tuning algorithms. ASM assumes that storage management for its 10g database can be provided more effectively by an automated function in the Oracle database than it can by an Oracle DBA.

ASM is considerably different from the old raw partition method. Database administrators were responsible for configuring the raw partitions that formed database storage. Oracle had its own layout reference system that it used to locate data within a raw partition. In contrast, ASM is a complete automated storage environment manager, including low-level storage redundancy. The file system created by ASM is not mountable by the host operating system and is managed entirely by Oracle. It remains to be seen whether the remaining Oracle tools for backup and recovery as well as remote copy will compare with methods that use file systems.

Database Data Types

Databases create two basic types of data during their normal operations: log data and tablespace data.

Log Data

Database logs are similar to file system journals (actually, file system journaling was modeled after database logging designs). They write the intent of every I/O in the system, and they acknowledge their completion after the operation finishes. Logging I/Os allows a DBA to find the exact state of a database when an unexpected shutdown occurred and restore the database data to a consistent, reliable state.

Databases often employ multiple log files (three or more) and use them in rotation. After a log file has been actively logging I/Os for a prescribed amount of time, it is taken out of use and replaced by another log file. The deactivated log file can be copied by an archiving process for historical purposes. When the log file is needed again by the database rotation, it is activated and overwritten by the next logging session.

Log data files are unusual in two ways: they are used exclusively for writing (while they are active), and they are written to sequentially. Because every I/O must be logged, and log data must be written to disk and acknowledged, the log data storage is an obvious potential bottleneck for the database system. For that reason, many administrators elect to use mirrored storage for log files to avoid the RAID 5 write penalty. (See Chapter 9, "Bigger, Faster, More Reliable Storage with RAID," for a discussion of the RAID 5 write penalty.)

Tablespace Data

Tablespaces contain the data stored by the database system and used by applications. This is the data that most people think of when they think of a database. Tablespace data is used for transaction processing, reports, and many types of data analysis.

Tablespaces can be large and involve many concurrent I/O operations. The rule of thumb for tablespace data is to stripe the data across a large number of drives to reduce the likelihood of disk contention on a single disk drive.

Database Backup and Business Continuity

Backup and recovery of databases is normally a specialized task requiring the oversight and involvement of DBAs. Large databases are rarely backed up in their entirety, but instead are backed up in parts.

Database log files are sometimes used as part of the business continuity plan. The log files can be applied by a log file utility in the database to re-create the transactions and the state of the database. This is an application of delta, or difference, redundancy, which was introduced in Chapter 8, "An Introduction to Data Redundancy and Mirroring."

Databases and Network Storage

Databases can run in a variety of network storage environments, including SANs, NAS, and distributed file systems.

Databases and SANs

Databases can connect to SAN-based storage without much difficulty or trouble. They typically are implemented in SANs using a variety of fencing methods, including LUN masking, zoning, and virtual SANs (VSANs).

Databases and NAS

One of the more controversial topics in the storage industry over the last decade has been whether it is safe to store database data on NAS file systems. For the most part, this has been resolved positively for most applications. Many databases stored on NAS systems depend on clustered NAS for high availability.

In essence, the database system creates its files on NAS systems and processes transaction I/Os by making file byte-range requests for data in the NAS file system. Gigabit Ethernet and fiber-optic cables are recommended as the connecting network between the database and NAS systems. Transmission Control Protocol/Internet Protocol (TCP/IP) may be required, as opposed to User Datagram Protocol/Internet Protocol (UDP/IP), to guarantee in-order delivery of data. Just as direct I/O is used to bypass file system write caching on local file systems, direct I/O may be needed on the NAS system also.

Databases and Distributed File Systems

Distributed database systems can use a distributed file system for storing their database data. This is not much different from storing a database system on a NAS system, except the file system is provided by a DFS farm instead of a NAS cluster. Some DFS products, such as the IBM SAN File System, support direct I/O and can be used to store very large databases.