There are three distinct options available for an installer of an Oracle database. Those available storage options for database files are File Systems, Oracle's Automatic Storage Management (ASM), or Raw Devices. Each of these storage options are defined further in the Installation Guides for the particular operating system supported. The Installation Guide should be read to determine how to take advantage of the storage option chosen.

File Systems

File Systems are what most DBAs are familiar with and have extensively used. For instance, File Systems can reside on disks through locally attached disks internal to a server, through a Logical Volume Manager (LVM) or Redundant Array of Inexpensive Disks (RAID) that are on some form of attached storage device such as a Storage Area Network (SAN). Regardless of the form, these file systems are mounted on the host server and when Oracle storage is required to create objects or store data Oracle will make use of physical files in some form of predefined directory structure. These physical files can either be named by an Oracle DBA or can be automatically generated by Oracle. The Installation Guides provided by Oracle should be consulted for your particular operating system to determine how to place database files on a File System and how to follow Oracle's Flexible Architecture (OFA) to ensure a reliable and manageable installation.

Automatic Storage Management (ASM)

Automatic Storage Management (ASM) is Oracle's proprietary storage solution for Oracle databases that simplifies and removes most of the need for traditional disk management tools. A DBA no longer needs to lay out or create database directory structures. ASM handles all underlying disk usage. ASM is able to manage all forms of database files, provide redundancy, and handle disk corruption and failures. ASM is another Oracle instance that communicates with a database instance through Oracle Cluster Synchronization Services (CSS). One or more disk devices are allocated to an ASM instance and then placed in ASM Disk Groups that in turn are referenced by the database instance. The Installation Guide provided by Oracle for your particular operating system should be read to determine how to install and configure ASM, and then enable use with an Oracle database.

Raw Devices

Raw devices are nothing more than disks that have not been formatted with a file system. When data is written from Oracle it bypasses the operating system file system layer and writes directly to the partition or volume. Because of the complexity to manage, Oracle does not recommend using raw devices. As such, this paper will not present additional information about raw devices and is merely here as a placeholder to let the reader know they are available.

Flash Recovery Area

Oracle's Flash Recovery Area is an allocated disk storage location where all backup and recovery related files are stored. The Flash Recovery Area can be pointed to a File System or Automatic Storage Management (ASM) disk group. All database related files required for recovery can be backed up and stored in the Flash Recovery Area. These files include the control file, online logs, archive logs, flashback logs, control file auto backups, control file copies, data file copies, and backup pieces.

The Flash Recovery Area is tightly integrated within the Oracle database and is an opportunistic area for performing disk-to-disk backups. With the use of RMAN and the Flash Recovery Area, assuming it has been allocated enough storage, a powerful mechanism can be created to provide faster, simpler, and automatic recovery of an Oracle database. Oracle also manages and keeps the Flash Recovery Area clean by storing only what is necessary and automatically removing obsolete files that might would not be needed for a recovery scenario, are redundant copies, or have been backed up to another storage device such as tape.

The Installation Guide provided by Oracle for your particular operating system should consulted to determine how to configure the Flash Recovery Area. It is as easy as setting two init.ora parameters. Those being: DB_RECOVERY_FILE_DEST (location of Flash Recovery Area) and DB_RECOVERY_FILE_DEST_SIZE (Amount of disk available for Flash Recovery Area) and then all RMAN backups, archive logs, control file auto backups, and data file copies will automatically be written to the specified file system or ASM group.

The Flash Recovery Area can also be tailored to meet any database's needs. It can be large enough to keep full, incremental, and archive logs available, as large as the database itself so a complete backup can be done, or small enough to just keep archive logs around. Flash Recovery Area should be taken advantage of if for nothing else than archive redo logs, online redo logs, and control files. These database structures already take up disk space and thus there is no real advantage to not having them within the Flash Recovery Area. Moreover, administration of recoveries becomes much easier with added features that would not normally be available.

Integration of Flash Recovery Area

Archive log destinations are directly written to the Flash Recovery Area as well as handling online redo logs. Also, but not shown on the figure, control files may be stored in the Flash Recovery Area. Backups through RMAN are also written to this area.

When configuring database storage, keep in mind that the same storage option is not required for database or recovery area. File Systems may be used for the database while the Flash Recovery Area might be ASM. The only unsupported file type would be raw devices for the Flash Recovery Area, thus another reason to stay away from raw devices.

Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN) is an Oracle utility used for backups and restores to an Oracle database. Its use has been widely accepted in the Oracle community for the ease and efficient method with which it can be scheduled, determining backup and recovery needs, as well as finding corruption down to the database block level. Under best practices, the RMAN environment consists of a dedicated RMAN instance, which can be directed at any number of target database instances for backup and recovery needs.

With the reduction in cost of many disks coupled with the simplicity of RMAN and the plain fact that many storage vendors are unable to keep pace with Oracle technology, Oracle suggests that disk to disk (D2D) backups should be done using the RMAN utility. The intuitive nature of RMAN and the fact that RMAN is tightly integrated with the Oracle database makes this a strategy that should be seriously thought of. Plus, many database need to be near real time, which can only be accomplished if disk to disk backup and restores have been implemented.

As noted earlier in this paper, RMAN can use the Flash Recovery Area to make backups of a target database. This type of backups is inline with Oracle's suggested strategy for full and incremental backups as well as the keeping of archive and online redo logs. The tight integration of RMAN with the Oracle kernel and its knowledge of what resides in the Flash Recovery Area, and what needs to be backed up or recovered makes it nearly the only choice for optimal management of Oracle databases to circumvent disaster. There is no comparison when placed side by side with user-managed backups and no backup strategy should be considered that does not take advantage of RMAN in some form or fashion. For instance, RMAN is able to detect block-level corruption that is not available in most alternative backup solutions. RMAN also contains a catalog that keeps information about each backup and aids in the recovery process.

Conclusion

Availability will often dictate the backup and recovery device actually required. However, for database environments that need to be available as much as possible there is no comparison when confronted with the question of tape or disk.

Backups in themselves do not necessarily hinder the availability of a database because an Oracle database can be continually available while hot backups are being done. The real determining factor for disk over tape is the recovery time. Recovering a database from tape can, very conservatively, take in excess of 10 times the amount of time it would from disk. Compound this with the time required to reassemble the individual pieces of Oracle, an Oracle database could be down for hours if not days depending on how large the database is and what pieces are actually going to be restored.

The advantages to disk based backups and restores can easily be seen in the following:

Decreasing cost of high-volume low-cost storage such as SATA drives

Decreased backup window by using multiple I/O streams

Decreased recovery time by using multiple I/O streams

Increased availability of backups

Increased protection through RAID technology

Increased usage and viability of backups through SANtricity Premium Features

For more details on RMAN Disk to Disk you can view on ORACLE DBA SUPPORT