5.3. Managing the Flash Recovery Area with Recovery Manager

Flash recovery is new with release Oracle 10g. The flash recovery area is designed to centralize the storage of all recovery files in a certain location on disk. The flash recovery area can use the local disk, a disk subsystem like a Storage Area Network (SAN) or Network Attached Storage (NAS), or Oracle Automatic Storage Management (ASM). ASM is new with 10g and is part of the new Automation Features of 10g, which are designed to minimize the workload by simplifying the disk and file system configuration. ASM is targeted at the smaller end database market, which may not have a dedicated database administrator.

Flash recovery provides a couple of key benefits to the recovery process:

  • All recovery files are stored in centralized location.

  • It provides a much faster method of backing up and restoring because the information is written to disk as opposed to tape.

Flash recovery is created by initializing a database parameter. The size and location of the flash recovery area are also defined in a database parameter. This information is automatically recorded in the database alert log as files are added or deleted from the flash recovery area. There is also a database view that provides information about the status of the flash recovery area: DBA_OUTSTANDING_ALERTS.

The retention period of the files in the flash recovery area are determined by the Recovery Manager (RMAN) retention policy, which is defined by the RMAN CONFIGURE RETENTION POLICY command. This command specifies the number of days to retain backups. Only files with retention policies can be deleted from the flash recovery area. Files that exceed the retention policy or are obsolete are then deleted from the flash recovery area. Files that are not obsolete are not deleted and are available for restore.

The Oracle 10g database will send warnings to the alert log when the flash recovery area has reached 90 percent and 95 percent full. At 90 percent full, Oracle 10g will automatically remove files that are obsolete from the flash recovery area.

Now that we understand what is involved in managing the flash recovery area, we will walk through configuring the flash recovery area in the next sections. We will also write RMAN backups to the flash recovery area.

5.3.1. Configuring the Flash Recovery Area

Setting up a flash recovery area is fairly straightforward procedure. All that is required to create this feature is to add a couple of database parameters to your database.

Let's go through an example of setting up the flash recovery area:

  1. Add the following database parameter for the size of the flash recovery area to the init.ora and/or SPFILE:

    SQL> alter system set db_recovery_file_dest_size=10M scope=both;

  2. Add the following database parameter for the location of the flash recovery area:

    SQL> alter system set db_recovery_file_dest='
    
    C:oracleflash_recovery_areaora101t';

There are also commands to modify the size of and disable the recovery area. These commands are performed with a similar ALTER SYSTEM statement. Let's look at these commands:

To increase the size of the flash recovery area to 25MB, use this command:

SQL> alter system set db_recovery_file_dest_size=25mb;

To disable the flash recovery area, use this command:

SQL> alter system set db_recovery_file_dest=';

5.3.2. Using the Flash Recovery Area

As mentioned earlier, the flash recovery area is a centralized recovery area where recovery-related files can be managed. Before, Oracle 10g archive log files could get out of synch with backups and require manual cleanup. One characteristic of the flash recovery area is that these files are related with the datafiles and control files. This reduces the manual cleanup of unneeded archive logs. Once the flashback recovery area is set up, it is a straightforward process to perform a backup. You need to specify the flash recovery database to be the default for backups using the CONFIGURE command. Next, you can perform a BACKUP or BACKUP AS COPY command. The backup will be directed to the flash recovery area for centralized storage. You can also check the space consumed and other statistics about the flash recovery area by querying V$RECOVERY_FILE_DEST. This dynamic view displays all the information about the usage of the flash recovery area. You need to access RMAN and back up the recovery area.

Let's walk through performing an automated disk-based backup and recovery:

  1. First, connect to the target database:

    C:Documents and Settings> set ORACLE_SID=ora101c
    
    C:Documents and Settings> rman
    Recovery Manager: Release 10.1.0.2.0 - Production
    Copyright (c) 1995, 2004, Oracle. All rights reserved.

    RMAN> connect target
    connected to target database: ORA101C (DBID=1736563848)
    RMAN>

  2. Next, perform a backup of the target database:

    RMAN> backup as copy database;
    
    Starting backup at 22-JUN-04
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=146 devtype=DISK
    channel ORA_DISK_1: starting datafile copy
    input datafile fno=00001 name=C:ORACLEORADATAORA101CSYSTEM01.DBF
    output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
      
    %REC_AREA_7_1.BAK tag=TAG2 0040622T225613 recid=2 stamp=529541843 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15 channel ORA_DISK_1: starting datafile copy input datafile fno=00003 name=C:ORACLEORADATAORA101CSYSAUX01.DBF output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
    %REC_AREA_8_1.BAK tag=TAG2 0040622T225613 recid=3 stamp=529541892 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:28:55 channel ORA_DISK_1: starting datafile copy input datafile fno=00005 name=C:ORACLEORADATAORA101CEXAMPLE01.DBF output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
    %REC_AREA_9_1.BAK tag=TAG2 0040622T225613 recid=4 stamp=529543607 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting datafile copy input datafile fno=00002 name=C:ORACLEORADATAORA101CUNDOTBS01.DBF output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
    %REC_AREA_10_1.BAK tag=TAG 20040622T225613 recid=5 stamp=529543617 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:08 channel ORA_DISK_1: starting datafile copy input datafile fno=00004 name=C:ORACLEORADATAORA101CUSERS01.DBF output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
    %REC_AREA_11_1.BAK tag=TAG 20040622T225613 recid=6 stamp=529543621 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:47 channel ORA_DISK_1: starting datafile copy

    copying current controlfile
    output filename=C:ORACLEFLASH_RECOVERY_AREAORA101C
      
    %REC_AREA_12_1.BAK tag=TAG 20040622T225613 recid=7 stamp=529543727 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 Finished backup at 22-JUN-04 RMAN>

  3. Finally, query the V$RECOVERY_FILE_DEST to determine if the SPACEJJSED column value has increased.

    SQL> select * from v$recovery_file_dest;
    
    NAME                       SPACE_LI SPACE_US SPACE_REC NUM_FILES
    -------------------------- -------- -------- --------- ---------
    C:flash_recovery_areaora   214748   330852   2932735         5

The flash recovery area can also be used to create many types of Oracle database files. The flashback recovery area can contain datafiles, control files, online redo logs, miscellaneous RMAN files, and flashback logs. To fully take advantage of the flash recovery area, you can store files like redo logs, control files, and archived redo logs when these files are created.

There are few important facts you need to know about creating database files in the flash recovery area. We will discuss these unique behaviors for each initialization parameter that creates files in the flash recovery area. The following commands can be used to create online redo logs in the flash recovery area:

  • CREATE DATABASE

  • ALTER DATABASE ADD LOGFILE

  • ALTER DATABASE ADD STANDBY LOGFILE

  • ALTER DATABASE OPENRESET LOGS

Let's discuss some of the impacts of creating specific database files in the flash recovery area. There are some initialization parameters that decide the location of the online redo log files in general. These initialization parameters are

  • DB_CREATE_ONLINE_LOG_DEST_n

  • DB_RECOVERY_FILE_DEST

  • DB_CREATE_FILE_DEST

These initialization parameters can be used to create the online redo log files and must be considered when creating the online redo logs in the flash recovery area.

The default size of the redo logs that are created in the flash recovery area is 100MB.


The following initialization parameters decide the location of the control files in general:

  • CONTROL_FILES

  • DB_CREATE_ONLINE_LOG_DEST_n

  • DB_RECOVERY_FILE_DEST

  • DB_CREATE_FILE_DEST

All these initialization parameters decide where the database control file is created and must be considered when creating the control file in the flash recovery area. There are some important behaviors to be aware of when using Oracle Managed Files. Oracle Managed Files (OMF) is a feature where Oracle creates the database files and manages these for you. This was the precursor to Automated Storage Management (ASM), which is new to 10g.

It is important to note that if you use both DB_RECOVERY_FILE_DEST and DB_CREATE_FILE_DEST initialization parameters with OMF, the control file will be created in the location of each parameter. When using DB_CREATE_ONLINE_LOG_DEST_n with OMF, the control files will be located in n number of locations with the first location as the primary control file. When using the DB_RECOVERY_FILE_DEST, the control file will be placed in the flash recovery area. The initialization parameters that impact the location of archived log files are

  • LOG_ARCHIVE_DEST_n

  • LOG_ARCHIVE_DEST

  • LOG_ARCHIVE_DUPLEX_DEST

However, only the LOG_ARCHIVE_DEST_n parameter can be used to create archived log files in the flash recovery area.

As you can see, using the flash recovery area is relatively simple. Once the flash recovery area has been set up, you just need to use the CONFIGURE command to set the flash recovery area as the default for backups. Then you can perform backups normally. You can see from querying the V$RECOVERY_FILE_DEST dynamic view in the NUM_FILES column that five datafiles were added to the flash recovery area. You can also see the SPACE_LIMIT information and how much space you have used in the SPACE_USED column.

Database files can also be created from their conception in the flash recovery area. The method of creating files is the same as if you created these files otherwise. There are some limitations and defaults with some of the initialization parameters that we discussed. You should be aware of these limitations.

5.3.3. Backing Up the Flash Recovery Area

Backup of the flash recovery area is an important activity because this area contains important backup information that is critical to the recovery of the database. Oracle has developed special commands to back up the flash recovery area. This is performed to a tape device so that the backups to the flash recovery can be recovered if there is a disk failure that supports the flash recovery area.

There are two commands that are used in backing up the flash recovery area:

  • BACKUP RECOVERY AREA backs up the whole recovery area.

  • BACKUP RECOVERY FILES just backs up the files in the recovery area.

Here's the syntax for the two commands that back up the flash recovery area to a tape device:

RMAN> backup recovery area;

RMAN> backup recovery files;

As you can see, these commands are straightforward. The purpose of these commands is to protect the flash recovery area. These commands must be used with a tape device and a media manager configured to use with RMAN.

When backing up the flash recovery area, only datafiles and miscellaneous RMAN files will be backed up and removed. Current redo log files and control files are not backed up, made obsolete, and then removed because Oracle considers current redo log files and multiplexed control files to be permanent. While flashback logs are not backed up, they are still considered transient, the same as datafiles and RMAN working files.


5.3.4. Configuring the Flashback Database

In order to use the Flashback Database, the database must have multiple features configured prior to configuring the Flashback Database. The database must have ARCHIVE LOG enabled. As mentioned before, the flash recovery area must be configured to store the Flashback Database logs.

First, you can configure the Flashback Database, so the database must be shut down. Next, the database must be started in MOUNT mode. Then, the database parameter DB_FLASHBACK_RETENTION_TARGET can be set to the desired value, which is based on minutes. This value determines how far back in time you can flash back the database. This is like a baseline for the Flashback Database. Next, the Flashback Database can be enabled with the ALTER DATABASE FLASHBACK ON command. Finally, the database can be opened for normal use.

Let's walk through these steps in more detail:

  1. Start the database in MOUNT mode:

    SQL> connect / as sysdba
    SQL> startup mount
    ORACLE instance started.
    
    Total System Global Area    88080384 bytes
    Fixed Size                    787588 bytes

    Variable Size               78642044 bytes
    Database Buffers             8388608 bytes
    Redo Buffers                  262144 bytes
    Database mounted.

  2. Set the DB_FLASHBACK_RETENTION_TARGET parameter to the desired value. This value can be set as an initialization parameter if you're not using the SPFILE. This value is in minutes, which equates to three days:

    SQL> alter set system db_flashback_retention_target=4320;

  3. Enable the flashback capability:

    SQL> alter database flashback on;

  4. Now the database can be opened for normal use:

    SQL> alter database open;

As you can see, enabling the Flashback Database is fairly simple. A key point for you is to know is how far back in time you need to be able to flash back from or know the DB_FLASHBACK_RETENTION_TARGET parameter value. The DB_FLASHBACK_RETENTION_TARGET value will determine how far back you can flash back the database to in minutes. In the preceding example, you specified the value of 4,320, which is for three days.

5.3.5. Using the Flashback Database with RMAN

The Flashback Database can be used with RMAN to perform recoveries. Using the RMAN interface to perform Flashback Database recovery is a straightforward process. Once the database is configured for the Flashback Database, you just need to start the database in MOUNT mode, and you are ready to perform a Flashback Database recovery. You also need to get either OLDEST_FLASHBACK_SCN or OLDEST_FLASHBACK_TIME from the V$FLASHBACK_DATABASE_LOG view. This will allow you to utilize the TO SCN or TO TIME clause in the FLASHBACK DATABASE clause. There is also the TO SEQUENCE clause, which uses the redo log sequence and thread to perform the recovery.

Let's walk through performing a Flashback Database recovery to a SCN:

  1. First, query the V$FLASHBACK_DATABASE_LOG view to retrieve the OLDEST_FLASHBACK_SCN:

    C:Documents and Settingsdstuns> sqlplus /nolog
    
    SQL*Plus: Release 10.1.0.2.0 - Production on Fri Oct 1 22:12:36 2004
    
    Copyright (c) 1982, 2004, Oracle. All rights reserved.
    
    SQL> connect / as sysdba
    Connected.

    SQL> select oldest_flashback_scn, oldest_flashback_time
       2 from v$flashback_database_log;
    
    OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME
    -------------------- ---------------------
                  689316 29-SEP-04
    
    SQL>

  2. Next, shut down and start the database in MOUNT mode:

    SQL> shutdown
    
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL>
    SQL> startup mount
    ORACLE instance started.
    
    Total System Global Area     88080384 bytes
    Fixed Size                     787588 bytes
    Variable Size                78642044 bytes
    Database Buffers              8388608 bytes
    Redo Buffers                   262144 bytes
    Database mounted.
    SQL>

  3. Next, issue the Flashback Database recovery from RMAN:

    C:Documents and Settingsdstuns> rman
    
    Recovery Manager: Release 10.1.0.2.0 - Production
    
    Copyright (c) 1995, 2004, Oracle. All rights reserved.
    
    RMAN> connect target
    
    connected to target database: ORA101 (DBID=4215248570)
    
    RMAN> flashback database to scn=689316;

    Starting flashback at 01-OCT-04
    using target database controlfile instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=158 devtype=DISK
    
    
    starting media recovery
    
    archive log thread 1 sequence 1 is already on disk as file
      
    C:ORACLEORAARCHORA101ARC00001_0538108686.001 media recovery complete Finished flashback at 01-OCT-04 RMAN>

  4. Finally, open the database with the RESETLOGS option, because you recovered to a time prior to the current database:

    SQL> alter database open resetlogs;
    
    Database altered.

As you can see, the Flashback Database recovery is a fairly simple process. The V$FLASHBACK_DATABASE_LOG dynamic view is useful for both TO SCN and TO TIME recoveries. The Flashback Database recovery is a quick and efficient method for recovering from user errors or logical corruptions in the database. This is a great alternative to performing a traditional incomplete recovery.

NOTE

The Flashback Database can also be performed in SQL*Plus with the FLASHBACK DATABASE command as well as RMAN.

5.3.6. Monitoring the Flashback Database

The Flashback Database can be monitored by using a few dynamic views: V$DATABASE, V$FLASHBACK_DATABASE_LOG, and V$FLASHBACK_DATABASE_STAT. These views provide some valuable information regarding the status of the Flashback Database and the supporting operations.

The V$DATABASE view displays if the Flashback Database is on or off. This tells you whether the Flashback Database is enabled or not.

Let's query the V$DATABASE view and see the results:

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------
YES

SQL>

The V$FLASHBACK_DATABASE_LOG view is new to Oracle 10g and was created to support the Flashback Database. The main purpose of this view is to allow you determine the amount of space required in the recovery area to support the flashback activity generated by changes in the database. The values in the OLDEST_FLASHBACK_SCN and OLDEST_FLASHBACK_TIME columns give you information regarding how far back you can use the Flashback Database. This view also shows the size of the flashback data in the FLASHBACK_SIZE column. The column ESTIMATED_FLASHBACK_SIZE can be used to identify the estimated size of flashback data that you need for your current target retention. Shown next is an example of querying the V$FLASHBACK_DATABASE_LOG.

SQL> select
   1 oldest_flashback_scn,
   2 oldest_flashback_time,
   3 retention_target,
   4 estimated_flashback_size
   5 from v$flashback_database_log;

OLDEST_FLASH_SCN OLDEST_FLASH_TIME RET_TARGET EST_FLASHBACK_SIZE
---------------- ----------------- ---------- ------------------
689316           29-SEP-04         1440       298967040

SQL>

The V$FLASHBACK_DATABASE_STAT view is used to monitor the overhead of maintaining the data in the Flashback Database logs. This view allows you to make estimates regarding future Flashback Database operations. This is done by coming up with an estimate about potential required space.

Let's look at the V$FLASHBACK_DATABASE_STAT:

SQL> select * from v$flashback_database_stat;

BEGIN_TIM END_TIME FLAS_DATA DB_DATA REDO_DATA EST_FLASHBACK_SIZE
--------- -------- --------- ------- --------- ------------------
29-SEP-04 29-SEP-04  7774208 16531456  4586496                  0

29-SEP-04    29-SEP-04    12976128    26238976    7306240     294862848
29-SEP-04    29-SEP-04    11100160    23257088    7217152     293437440
29-SEP-04    29-SEP-04    10903552    23003136    7135232     296165376
29-SEP-04    29-SEP-04    11173888    22495232    6960128     300023808
29-SEP-04    29-SEP-04    12435456    23420928    7499264     304029696
29-SEP-04    29-SEP-04    13565952    27009024    8587264     304865280
29-SEP-04    29-SEP-04    12255232    23420928    7854080     301522944
29-SEP-04    29-SEP-04    11771904    22192128    7110144     303071232
29-SEP-04    29-SEP-04    10969088    21127168    7652352     308232192
29-SEP-04    29-SEP-04    11067392    20873216    8052736     322805760
29-SEP-04    29-SEP-04    11132928    21135360    7340544     350158848
29-SEP-04    29-SEP-04    19652608    49127424    10739200    425238528

13 rows selected.
SQL>

As you can see, the V$FLASHBACK_DATABASE_STAT dynamic view shows the utilization of the Flashback Database log. This is determined by the begin and end times.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset