Backup Recovery   «Prev 

Setting Oracle Parameter Values

  1. Connect to the database by using PETSTORE as the User Name, GREATPETS as the Password, and MYDB as the Host String. Click the OK button to approve the entries.
  2. Build a SQL string to set the parameter value of LOG_ARCHIVE_DUPLEX_DEST to d:\oradata\mydb\archive\duplex by entering 
    ALTER SYSTEM SET LOG_ARCHIVE_DUPLEX_DEST = 'd:\oradata\mydb\archive\duplex'
    at the SQL> prompt. Approve the entries and execute the SQL. Press ENTER.
  3. Build a SQL string to set the parameter value of LOG_ARCHIVE_DEST_n to d:\oradata\mydb\archive by entering 
    ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 = 'LOCATION= d:\oradata\mydb\archive OPTIONAL'
    at the SQL> prompt. Approve the entries and execute the SQL. OPTIONAL is mentioned within the ALTER SYSTEM statement, because Oracle8i allows the user to specify five locations for maintaining the archived redo log files, the first being mandatory and the rest specified as optional. Approve the entries and execute the SQL string.
  4. SQL*Plus now displays the result of compilation of your query. Click Exit to end the simulation.

The Fast Recovery Area

The Fast Recovery Area (FRA) is not a requirement for using RMAN, but it should be. The FRA was introduced in Oracle Database version 10g. It was first called the Flash Recovery Area but was then renamed to the Fast Recovery Area. The term recovery files refers to all files that might be required for a media recovery operation: full datafile backups, incremental backups, datafile copies, backup control files, and archive logs. The FRA also functions as a repository for mirrored copies of online redo log files, the blockchange tracking file, and for a current control file. If set up, flashback logs for using the flashback database option also live in the FRA. The concept behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and RMAN can then micromanage, while the DBA moves on to other important duties. The FRA really is part of an overall backup and recovery architecture strategy that is designed to ensure that the database is recoverable, with a minimum of work on the part of the DBA.

The FRA that you set up can be either a directory on a normal disk volume or an Automatic Storage Management (ASM) disk group. The FRA is determined by two initialization parameters: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. The first determines the location; the second, the size. These can be set in your init.ora file, if you still use one, or in the SPFILE via an alter system set command.
With an FRA configured, you are not required to set any other LOG_ARCHIVE_DEST_n parameter for archive logs; by default, with an FRA, Oracle will default the setting for LOG_ARCHIVE_DEST_10 to use the FRA. There may be some cases where you will want to set other log archived destination directories for example, with standby databases.
It should also be noted that with an FRA in use, the parameters
  1. LOG_ARCHIVE_DEST or
  2. LOG_ARCHIVE_DUPLEX_DEST
are mutually exclusive, but you certainly rid yourself of these outdated parameters long ago, right? The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates when the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format. Significant internal directory structures exist for file management. However, the point of an FRA is that you do not need to spend much time worrying about the files. The same FRA can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes.