Recovery-Related Structures in the Flash Recovery Area

The flash recovery area is essential for data protection in Oracle Database XE. It is a dire ctory, separate from the database itself, where recovery-related structures are stored. These recovery-related structures include:

Backups of the physical files that make up the database (datafiles, the control file, and the server parameter file (SPFILE))

Note:
Oracle database backup and recovery is based on protecting the physical files of the database, rather than individual database objects such as tables.

Backups are stored in collections called backup sets. A backup set consists of one or more backup pieces, which are files in a proprietary archival format that can be accessed only by an Oracle database. See "About Backing Up and Restoring the Database" for more information.
Online redo logs

The online redo log files record all changes made to the database. They can be used to reconstruct data in the event of a failure. See "Online Redo Log Files" for more information.
Archived redo logs

If you enable log archiving, filled redo log files are archived (copied) in the flash recovery area before being reused. The online and archived logs together constitute a record of all changes committed to the database since the last backup was taken. See "Archived Redo Log Files" for more information.

The database automatically manages all contents of the flash recovery area. You must not directly manipulate files within the flash recovery area using operating system commands.

Table: Flash Recovery Area Default Locations lists the default location for the flash recovery area on each platform.

Flash Recovery Area Default Locations

Platform	Location
Linux	`/usr/lib/oracle/xe/app/oracle/flash_recovery_area/`
Windows	`c:\oraclexe\app\oracle\flash_recovery_area\`

Caution:

The default configuration of Oracle Database XE stores the flash recovery area on the same disk as your database files. In this configuration, if a media (disk) failure occurs, you can lose both your database and your backups. For any database where data protection is essential, change the location of the flash recovery area so that it is stored on a different disk. See "Setting Flash Recovery Area Location and Size" for instructions.

Online Redo Log Files

The most crucial structure for database recovery is a set of redo log files. This set of files is collectively known as the redo log for the database. A redo log is made up of redo entries, which are also called redo records.

The primary function of the redo log is to record all changes made to data in the database. If an Oracle instance failure or operating system failure prevents modified data from being permanently written to the datafiles, the changes can be recovered from the redo log so that committed data updates are not lost.

The database writes to the redo log files in a circular fashion. When the current redo log file fills, the database begins writing to the next available redo log file. (The redo log files that are not current are called inactive.) When the last available redo log file is filled, the database returns to the first redo log file and writes to it (overwriting previous redo entries), starting the cycle again.

Multiplexed Redo Log

To protect against a failure involving the redo log itself, Oracle Database XE allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations. For the most benefit, these locations should be on separate disks. Even if all copies of the redo log are on the same disk, however, the redundancy can help protect against I/O errors, file corruption, and so on.

Multiplexing is implemented by creating groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is said to be a member of the group. When the database writes to the current log file, all members in that log file's group are updated so that they remain identical. Each redo log group is defined by a number, such as group 1, group 2, and so on.

The current and inactive redo log files—that is, the current and inactive log groups and all their members—taken together, are called th e online redo log files, to distinguish them from archived redo log files, which are described later in this section.

The default installation of Oracle Database XE configures two redo log groups of one member each. Thus, the default configuration for the redo logs does not use multiplexing. As shown in Figure: Database Storage Structure, both single-member redo log groups are stored in the flash recovery area.

You may want to multiplex the redo logs to protect against failures. Again, the ideal configuration is to separate members of the same log group onto different disks to protect against disk failure. Assuming that you decided to configure two members per group, the best practice for Oracle Database XE would be the following:

Move the flash recovery area to a different disk.

See "Setting Flash Recovery Area Location and Size" for instructions.
Create the second member of each redo log group in the same location as the datafiles.

See "Creating Redo Log Members" in Oracle Database Administrator's Guide for instructions. Table: Datafile Locations shows the location of the datafiles on each platform.

Datafile Locations

Platform	Datafile Location
Linux	`/usr/lib/oracle/xe/oradata/XE/`
Windows	`C:\oraclexe\oradata\XE\`

Moving the flash recovery area to a different disk is preferred over leaving the flash recovery where it is and creating the second group member on a different disk. This is because the flash recovery area also contains database backups, and backups are best placed on a disk other than the disk that contains the datafiles.

Note:

When you multiplex the redo log, the database must increase the amount of I/O that it performs. Depending on your configuration, this may impact overall database performance.

Archived Redo Log Files

Oracle Database XE can be configured so that a background archiving process makes copies of filled, inactive redo log files in the flash recovery area before they are reused. Redo log files copied in this way are called archived redo log files. A database configured to archive redo logs is said to be in ARCHIVELOG mode. (A database not configured to archive redo logs is said to be in NOARCHIVELOG mode.)

The advantages of running in ARCHIVELOG mode are the following:

After a media failure causing the loss of some or all database files, the database can be reconstructed with all committed transactions intact if you have backups of the control file and datafiles, and a complete set of all archived and online log files created since the last backup. The online and archived redo log files contain a complete record of all database changes since the last backup. This reconstruction process is called media recovery.
A database in ARCHIVELOG mode can be backed up while it is online. A NOARCHIVELOG mode database can be backed up only while it is offline (shut down). Your applications are unavailable during the backup of a NOARCHIVELOG database.

The disadvantages of running in ARCHIVELOG mode are the following:

Archived redo log files require disk space in the flash recovery area, and the flash recovery area requires monitoring to ensure that it does not fill completely.
There is some performance overhead associated with the background process that archives redo log files.

Log archiving is disabled by default, to simplify the management of your database. Therefore, the default configuration of Oracle Database XE protects your database from instance failure or operating system failure, but does not protect your database from media failure.

Oracle recommends that you enable ARCHIVELOG mode for optimal data protection.

Note:

When the redo log is multiplexed, when it is time to archive a log file, the database selects one member of that log file's group and copies it. If a member is damaged or unavailable, the database attempts to copy another member.