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.
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:
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;
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=';
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:
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>
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>
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 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.
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:
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.
|
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:
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.
Enable the flashback capability:
SQL> alter database flashback on;
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.
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:
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>
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>
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>
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.
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.