Globusz^® Publishing 

Using the Flash Recovery Area

The flash recovery area serves as the default storage area for all files related to backup and restore operations.

The flash recovery area provides the following benefits:

• Single storage location for all recovery-related files.
• Automatic management of recovery-related disk space.
• Faster backup and restore operations, since you don’t need to restore tape backups.
• Increased reliability of backups, since disks are generally safer storage devices than tapes.

What’s in the Flash Recovery Area?

The flash recovery area may contain the following files:

• Datafile copies: The new RMAN command BACKUP AS COPY can be used to create image copies of all datafiles and automatically store in the flash recovery area.
• Control file autobackups: The database places any control file backups it generates in the flash recovery area.
• Archived redo log files: If you store Archived redo log files in the flash recovery area, Oracle will automatically delete the files.
• Online redo log files: Oracle recommends that you save a multiplexed copy of your online redo log files in the flash recovery area. The following statements can create online redo logs in the flash recovery area: CREATE DATABASE, ALTER DATABASE ADD LOGFILE, ALTER DATABASE ADD STANDBY LOGFILE, and ALTER DATABASE OPEN RESETLOGS.
• Current control files: Oracle also recommends that you store a multiplexed current control file in the flash recovery area.
• RMAN files
• Flashback logs: If you enable the flashback database feature, Oracle copies images of each altered block in every datafile into flashback logs stored in the flash recovery area.

Note: Oracle calls the multiplexed redo log files and control files in the flash recovery area permanent files, since they should never be deleted and are part of the live database. Oracle terms all the other files in the flash recovery area (recovery related files) transient files, since Oracle will delete them eventually after they have become obsolete or have already been copied to tape.

Creating a Flash Recovery Area

You use the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters to configure a flash recovery area in your database.

When you use the DB_RECOVERY_FILE_DEST parameter to specify the destination of your flash recovery area, you can use a directory, file system, or ASM disk group as your destination.

Dynamically Defining the Flash Recovery Area

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G SCOPE=BOTH

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = 'C:\ORACLE\RECOVERY_AREA' SCOPE=BOTH

You must always specify the size parameter before specifying the location parameter.

Disabling the Current Flash Recovery Area

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = ''

Note: even after you disable the flash recovery area, the RMAN will continue to access the files located in the flash recovery area for backup and recovery purposes.

Default File Location and the Flash Recovery Area

The initialization parameters DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n determine the location of all OMF files.

Control Files

If you haven’t set the CONTROL_FILES parameter, Oracle will create the control files in various default locations, according to the following rules:

• If you specify the DB_CREATE_ONLINE_LOG_DEST_n parameter, Oracle will create an OMF-based control file in n number of locations, with the first directory holding the primary control file.
• If you specify the DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST parameters, Oracle will create an OMF based control file in both of these locations.
• If you just specify the DB_RECOVERY_FILE_DEST parameter, Oracle will create an OMF-based control file in the flash recovery area only.
• If you omit all three of the initialization parameters, Oracle will create a non-OMF-based control file in the system-specific default location.

Note: If the database creates an OMF control file, and it is using a server parameter file, then the database sets the CONTROL_FILES initialization parameter in the server parameter file.

Redo Log Files

If you omit the LOGFILE clause during database creation, Oracle will create the redo log files according to the same rules as mentioned above.

Backing Up the Flash Recovery Area

In order to back up the flash recovery area itself using RMAN, you must set CONFIGURE BACKUP OPTIMIZATION to ON.

You can back up the flash recovery area only to a tape device using these backup commands:

BACKUP RECOVERY AREA

• This command backs up all flash recovery files in the current or previous flash recovery area destinations.
• It backs up only those files that have never been backed up to tape before.
• The files that the command will back up include full backups, incremental backups, control file autobackups, archive logs, and datafile copies.

BACKUP RECOVERY FILES

This command backs up all the files that the BACKUP RECOVERY AREA command does, but from all areas on your file system, not just from the flash recovery area.

BACKUP RECOVERY FILE DESTINATION

Use this command to move disk backups created in the flash recovery area to tape.

Note: Neither of the two commands, BACKUP RECOVERY AREA or BACKUP RECOVERY FILES, will back up any permanent files or the flashback logs in the flash recovery area.

Managing the Flash Recovery Area

Space Management

If you ever receive the out-of-space warning (85) and critical alerts (97) because of space pressure in you flash recovery area, you have the following options:

• Consider changing your backup retention and archive log retention policies.
• Increase the size of the DB_RECOVERY_FILE_DEST_SIZE parameter to allocate more space to your current flash recovery area.
• Use the BACKUP RECOVERY AREA command in the RMAN to back up the contents of the flash recovery area to a tape device.
• Use the RMAN to delete unnecessary backup files. The RMAN commands CROSSCHECK and DELETE EXPIRED come in handy during this deletion process.

Data Dictionary Views

V$RECOVERY_FILE_DEST

This view is the main source and contains the following columns:

V$FLASH_RECOVERY_AREA_USAGE

This view provides information about the flash recovery area disk space usage. Following is its main columns:

Flash Recovery Area Columns in Other Views

The Yes/No column IS_RECOVERY_DEST_FILE is added to some dictionary views to indicate whether the file was created in the flash recovery area. It exists in V$CONTROLFILE, V$LOGFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY, V$BACKUP_PIECE.

Moving the Flash Recovery Area

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/app/oracle/new_area' SCOPE=BOTH

Eventually, Oracle will delete all the transient files from the previous flash recovery area location, when each of them become eligible for deletion. However, if you want to move your current permanent files, transient files, or flashback logs to the new flash recovery area, you can do so by using the standard file-moving procedures.

Using Incremental Backups

Recovering with Incrementally Updated Backups

You can apply incremental backups to your datafile image copies when you use the RMAN. This takes much less time than performing a full image copy of the datafiles every day.

This is applied through two phases:

1. Apply the incremental backups to datafile image copies. This is done at the database block level.
2. Then apply the archive logs since the last incremental backup only. This is done at the transaction level (slower than previous phase).

To implement this option, you do the following steps:

1. Use the BACKUP INCREMENTAL LEVEL 1...FOR RECOVER OF COPY WITH TAG ... form of the BACKUP command to create incremental backups that can be incrementally updated. If an incremental level 0 backup does not already exist, then executing this command creates a level 0 backup with the specified tag.
2. Apply any incremental backups to a set of data file copies with the same tag using the RECOVER COPY ...WITH TAG ... form of the BACKUP command. Tags must be used to identify the incremental backups and data file copies created for use in this strategy, so that they do not interfere with other backup strategies that you implement.

Fast Incremental Backups

• RMAN reads change tracking file to find out which data blocks to read and copy during an incremental backup process, to avoid needing to read entire datafiles during incremental backups.
• A new background process, the change tracking writer (CTWR), is in charge of writing the block change information to the change tracking file.

Change Tracking File Features

• The change tracking file contains the physical location of all database changes.
• The minimum size is 10MB. Oracle creates the file automatically and allocates additional space in 10MB increments.
• The file’s size depends on your database size, number of instances in an RAC, and the number of old backups the file maintains.
• V$BLOCK_CHANGE_TRACKING shows the name, size, and status of your change tracking file.

Enabling Block Change Tracking

ALTER DATABASE

ENABLE BLOCK CHANGE TRACKING

USING FILE 'C:\ORACLE\RECOVERY_AREA\CHANGETRACK.LOG'

To relocate the file, while in mount stage:

ALTER DATABASE RENAME FILE

'C:\ORACLE\RECOVERY_AREA\CHANGETRACK.LOG'

TO 'C:\ORACLE\NEWCHANGE.LOG'

To disable the file:

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Enhancements in RMAN

Configuration Changes

• When opening a database that was recovered using a backup or a current control file, the Oracle server automatically re-creates any locally managed temporary files if they do not exist. The files are re-created with the same creation size and storage settings. You can change the temporary file names by using the RMAN SET NEWNAME FOR TEMPFILE and SWITCH TEMPFILE command options.
• You no longer need to re-create the control file when any of the following configuration parameters are modified: MAXLOGFILES, MAXLOGMEMBERS, MAXINSTANCES. This ensures that you do not lose the RMAN catalog metadata through control file re-creation, and reduces system down-time requirements.
• RMAN backups to backup sets do not back up never-used blocks. In addition, Oracle Database 10g no longer backs up nonused blocks in locally managed tablespaces. Examples of such blocks are blocks that belong to dropped or truncated objects.

Using the BACKUP AS COPY Command

• The RMAN COPY command has been deprecated in Oracle Database 10g and replaced with BACKUP AS COPY command.
• BACKUP AS COPY command enables you to copy: database, tablespaces, datafiles, archived redo logs and control files.
• If you want RMAN to create image copies by default (rather than backuset):

RMAN> configure device type disk backup type to copy

• To create a backup set in the command level:

RMAN> backup as backupset database

Performing Backups

RMAN> backup database;

RMAN> backup copy of database;

RMAN> backup tablespace users;

RMAN> backup copy of tablespace users;

RMAN> backup datafile 10;

RMAN> backup copy of datafile 10;

RMAN> backup current controlfile;

RMAN> backup controlfilecopy all;

Using the CATALOG Command

RMAN> catalog backuppiece 'filename'

RMAN> catalog datafilecopy 'filename'

RMAN> change backuppiece 'file_name' uncatalog

Using the CATALOG START WITH Command

You can ask the RMAN to search in a certain directory for all backup files that aren’t part of the catalog already:

RMAN> catalog start with "C:\ORACLE\FLASH_RECOVERY_AREA\NINA\DATAFILE"

Compressed Backups

• Oracle Database 10g lets you compress RMAN backups to save on storage.
• You must set the COMPATIBLE initialization parameter to a minimum of 10.0.0.
• You can’t compress an image copy; you can compress a backup only if you are using backup sets.
• The V$BACKUP_FILES view contains information on backup files including the compression status.

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE

Automatic Channel Failover

If one of the channels on which the RMAN is performing a backup fails, the RMAN will automatically try to use an alternative channel, provided you are using multiple channels.

Enhancements in RMAN Scripts

1. Convertibility of RMAN Scripts

In Oracle Database 10g, you can change a stored script into a text script and vice versa.

RMAN> print script full_backup to file 'my_script_file.txt'

2. Global RMAN Scripts

Oracle Database 10g provides a new concept of global scripts, which you can execute against any database registered in the recovery catalog, as long as your RMAN client is connected to the recovery catalog and a target database simultaneously.

RMAN> create global script global_full_backup

{ backup database plus archivelog;

delete obsolete; }

Using the Database Control to Configure Backups

On the Database Control home page, follow the links: Maintenance tab | Configure Backup Settings.

You can use one of the following choices to tell RMAN where to place its target files:

• FORMAT option in a backup command
• CONFIGURE CHANNEL FORMAT option
• DB_RECOVERY_FILE_DEST

Implementing Fast Recovery

For those special times when you really need a fast recovery, Oracle Database 10g offers the SWITCH DATABASE command.

The RMAN simply adjusts the pointers for the datafiles in the control file, so they now point to the backup files in your flash recovery area.

RMAN> SWITCH DATABASE TO COPY

Note: Consider this fast recovery method as a temporary solution. Later, you should relocate your database datafiles to permanent locations.

This method applies in the tablespace level as well:

RMAN> sql 'alter tablespace users offline';

RMAN> switch datafile 4 to copy;

RMAN> recover datafile 4;

RMAN> sql 'alter tablespace users online';

Recovering Datafiles without Backups

The ability to recover a file that has never been backed up has always been available from SQL*Plus, with the help of the CREATE DATAFILE .. AS .. statement. Now, in Oracle Database 10g, you can create the lost file as part of an RMAN RESTORE DATABASE command.

Simplified Recovery Through RESETLOGS

• In Oracle Database 10g, you can use backups taken before an incomplete recovery operation; that is, you can use backups from older incarnations of the database.
• The new archive redo log format in Oracle Database 10g is of the following form:

LOG_ARCHIVE_FORMAT="log%t_%s_%r.arc"

The additional variable r stands for the RESETLOGS identifier.

• The V$DATABASE view contains now RESETLOGS_CHANGE#, RESETLOGS_TIME, and RESETLOGS_ID.
• The V$LOG_HISTORY contains now RESETLOGS_CHANGE# and RESETLOGS.

Dropping a Database

Here are some features of the DROP DATABASE command:

• Oracle will drop all control files and datafiles automatically, whether you use the SQL*Plus, RMAN, or DBCA interface to drop a database.
• Oracle does not remove archived redo logs and backups. To make the RMAN remove all database backup copies as well as the archived redo log files:

RMAN> DROP DATABASE INCLUDING BACKUPS

• If you are using SPFILE, Oracle will remove it automatically.
• After you drop a database, the RMAN catalog continues to list the dropped database information. You need to use the following RMAN command:

RMAN> UNREGISTER DATABASE

Specifying Limits for Backup Duration

You can use the DURATION command as an option for your regular backup commands, such as BACKUP AS COPY, to specify the time (in hours and minutes) a backup job can take. This makes the job taken less resources during its operation.

DURATION <hrs>:<mins> [PARTIAL] [MINIMIZE {TIME|LOAD}]

PARTIAL

Normally, when your database backup jobs run past the time interval you specify through the DURATION parameter, the RMAN job errors out and the backup is canceled. You can override this default behavior by specifying the PARTIAL clause, which will prevent the issuing of any RMAN error messages.

MINIMIZE TIME

This option tells the RMAN to “hurry up” and finish as fast as it can.

MINIMIZE LOAD

This option tells the RMAN to “slow down” if it is well within its allotted time for a backup job.

Note: It is recommended that you do not use the MINIMIZE LOAD option with tape.

Automatic Auxiliary Instance Creation

When you perform a tablespace point-in-time recovery (TSPITR) to recover from certain database errors, Oracle Database 10g will now automatically create the auxiliary instance and remove it after the recovery is over.

This automatically generated instance will be in the same database server. Remember, as with previous versions, instance creation introduces performance overhead during the recovery operation.

Automatic creation of Temporary Datafiles

Starting from release 2, Temporary datafiles that belong to locally managed temporary tablespaces are automatically re-created during RMAN recovery operation. This eliminates the need to manually create temporary tablespaces after recovery.

New RMAN Dynamic Performance Views

In Oracle 10.2 and above, in order to provide more details about its operation, RMAN is supported by a number of new dynamic performance views including:

V$BACKUP_ARCHIVELOG_DETAILS

V$BACKUP_ARCHIVELOG_SUMMARY

V$BACKUP_CONTROLFILE_DETAILS

V$BACKUP_CONTROLFILE_SUMMARY

V$BACKUP_COPY_DETAILS

V$BACKUP_COPY_SUMMARY

V$BACKUP_DATAFILE_DETAILS

V$BACKUP_DATAFILES_SUMMARY

V$BACKUP_JOB_DETAILS

V$BACKUP_PIECE_DETAILS

V$BACKUP_SET_DETAILS

V$BACKUP_SET_SUMMARY

V$BACKUP_SPFILE_DETAILS

V$BACKUP_SPFILE_SUMMARY

One other useful view is V$RMAN_BACKUP_JOB_DETAILS. It informs you about history of all backups done by the RMAN. You will find details like how long the backup took, how many RMAN jobs have been issued, the status of each job, what time they started and completed, rate of the backup produced and how fast data was read and written by the process.

COL STATUS FORMAT A9

COL HRS FORMAT 999.99

SELECT

SESSION_KEY, INPUT_TYPE, STATUS,

TO_CHAR(START_TIME,'DD/MM/YY HH24:MI') START_TIME,

TO_CHAR(END_TIME,'DD/MM/YY HH24:MI') END_TIME,

ELAPSED_SECONDS/3600 HRS

FROM V$RMAN_BACKUP_JOB_DETAILS

ORDER BY SESSION_KEY

COL INS FORMAT A10

COL OUTS FORMAT A10

SELECT SESSION_KEY,

OPTIMIZED,

COMPRESSION_RATIO,

INPUT_BYTES_PER_SEC_DISPLAY INS,

OUTPUT_BYTES_PER_SEC_DISPLAY OUTS,

TIME_TAKEN_DISPLAY

FROM V$RMAN_BACKUP_JOB_DETAILS

ORDER BY SESSION_KEY

Another new view is V$RMAN_BACKUP_TYPE. It informs the type of backups performed by RMAN : BACKUPSET, SPFILE, CONTROLFILE, ARCHIVELOG, DATAFILE INCR, DATAFILE FULL, DB INCR, RECVR AREA and DB FULL.

The view V$RMAN_OUTPUT records the output (log) from the RMAN jobs so that you can view it later. This view is useful for checking log of scripted RMAN jobs as well as ad-hoc jobs.

Note: All those view are in-memory and cleared upon the instance shut down.

Oracle Secure Backup

• In Oracle Database 10g Release 2, a new tool called Oracle Secure Backup (OSB) is available. OSB enables you to use RMAN to backup directly to tape library without using the costly third-party MML layer.
• OSB can be controlled and administered via Oracle Enterprise Manager or obtool command-line.
• Beside backing up the database, OSB can be used to backup filesystems as well.

Cross-Platform Transportable Database

• The RMAN CONVERT DATABASE command is used to automate the movement of an entire database from one platform (the source platform) to another (the destination platform).
• The source and destination platform must share the same endian format.

Note: If the source and destination platform have different endian format, you can create a new database on a destination platform manually, and transport needed tablespaces from the source database using cross-platform transportable tablespace.

A. Preparing for CONVERT DATABASE: Using the DBMS_TDB Package

A.1 Using DBMS_TDB.CHECK_DB to Check Database State

DBMS_TDB.CHECK_DB checks whether a database can be transported to a desired destination platform, and whether the current state of the database permits transport.

It is a function that returns TRUE if the source database can be transported using CONVERT DATABASE, and FALSE otherwise.

It has the following parameters:

TARGET_PLATFORM_NAME

The name of the destination platform, as it appears in V$DB_TRANSPORTABLE_PLATFORM.

SKIP_OPTION

Specifies which, if any, parts of the database to skip when checking whether the database can be transported. Supported values (of type NUMBER) are:

• SKIP_NONE (or 0), which checks all tablespaces
• SKIP_OFFLINE (or 2), which skips checking datafiles in offline tablespaces
• SKIP_READONLY (or 3), which skips checking datafiles in read-only tablespaces

Set SERVEROUTPUT to ON to see output includes why the database cannot be transported.

SET SERVEROUTPUT ON

DECLARE

DB_READY BOOLEAN;

BEGIN

DB_READY := DBMS_TDB.CHECK_DB('Microsoft Windows IA (32-bit)',DBMS_TDB.SKIP_READONLY);

END;

A.2 Using DBMS_TDB.CHECK_EXTERNAL to Identify External Objects

DBMS_TDB.CHECK_EXTERNAL must be used to identify any external tables, directories or BFILEs. RMAN cannot automate the transport of such files.

SET SERVEROUTPUT ON

DECLARE

EXTERNAL BOOLEAN;

BEGIN

/* value of external is ignored */

EXTERNAL := DBMS_TDB.CHECK_EXTERNAL;

END;

B. Using the RMAN CONVERT DATABASE Command

1. Open the database in READ ONLY mode then use the RMAN command CONVERT DATABASE as follows:

CONVERT DATABASE  
NEW DATABASE 'newdb' 
TRANSPORT SCRIPT '/tmp/convertdb/transcript'

TO PLATFORM 'Microsoft Windows IA (32-bit)'

DB_FILE_NAME_CONVERT '/disk1/oracle/dbs' '/tmp/convertdb'

Alternatively, you can use ON TARGET PLATFORM clause makes the datafile conversion on the target database. This means RMAN will generate the appropriate conversion scripts to be run on the target server to perform the datafile conversion there.

CONVERT DATABASE

ON TARGET PLATFORM 
NEW DATABASE 'newdb'

CONVERT SCRIPT '/tmp/convertdb/newdb.cnv'

TRANSPORT SCRIPT '/tmp/convertdb/transcript'

DB_FILE_NAME_CONVERT = '/disk1/oracle/dbs' '/tmp/convertdb'

Note: CONVERT DATABASE ON TARGET PLATFORM does not produce converted datafile copies.

2. Copy all of the files produced to the destination host and place the datafiles in the desired locations on the destination host.
3. If the path to the datafiles is different on the destination, then edit, if any, the conversion script and the transport script to refer to the new datafile locations.

CONVERT DATAFILE  
'/tmp/SYSTEM01.DBF' 
FROM PLATFORM 'Microsoft Windows IA (32-bit)' 
FORMAT 
'/u01/app/oracle/oradata/newdb/system01.dbf'

4. Edit the PFILE to change any settings for the destination database.
5. Execute the transport script in SQL*Plus to create the new database on the destination host.

SQL> @transcript

6. Open the database using RESETLOGS option

ALTER DATABASE OPEN RESETLOGS;

7. Execute some maintenance code:

ALTER TABLESPACE TEMP

ADD TEMPFILE '/u01/app/oracle/oradata/newdb/temp01.tmp'

SIZE 202375168 AUTOEXTEND ON NEXT 655360

MAXSIZE 32767M

SHUTDOWN IMMEDIATE;

STARTUP UPGRADE PFILE='/u01/../newdb/INIT_RPTREPOS.ORA'

SQL> @@ ?/rdbms/admin/utlirp.sql

SHUTDOWN IMMEDIATE;

SQL> STARTUP PFILE='/u01/../newdb/INIT_RPTREPOS.ORA'

@@ ?/rdbms/admin/utlrp.sql

8. Change the internal database identifier using DBNEWID Utility

Restore Points

• A restore point serves as an alias for an SCN or a specific point in time.
• It is stored in the control file.
• It can be used with: RECOVER DATABASE, FLASHBACK DATABASE, FLASHBACK TABLE.
• It requires the database to operate in ARCHIVEMODE and the database flashback logging enabled.
• Use V$RESTORE_POINT to obtain information about restore points

CREATE RESTORE POINT before_load

Guaranteed Restore Points

• A guaranteed restore point ensures that you can perform a FLASHBACK DATABASE command to that SCN at any time.
• It can be used to restore beyond time specified by  
  DB_FLASHBACK_RETENTION_TARGET parameter
• Even the effects of NOLOGGING operations such as direct load inserts can be reversed using guaranteed restore points.
• It must be manually deleted.

CREATE RESTORE POINT before_load GUARANTEE FLASHBACK DATABASE

To flashback database to a restore point

SHUTDOWN IMMEDIATE 
STARTUP MOUNT 
FLASHBACK DATABASE TO RESTORE POINT before_load

ALTER DATABASE OPEN READ ONLY

-- check the flashed back data

SHUTDOWN IMMEDIATE

STARTUP MOUNT

ALTER DATABASE OPEN RESETLOGS;

To recover the database to the restore point

RECOVER DATABASE UNTIL RESTORE POINT before_load

To flashback table to restore point

ALTER TABLE emp ENABLE ROW MOVEMENT

FLASHBACK TABLE emp TO RESTORE POINT before_load

To drop a restore point

DROP RESTORE POINT before_load

Placing All Files in Online Backup Mode

• In Oracle Database 10g, with a single command you can place all the data files in the database in online backup mode. You no longer need to place each tablespace in online backup mode individually. This makes user-managed online backup easier. The requirements for implementing the user-managed online backup still apply.

ALTER DATABASE BEGIN BACKUP

• When you issue this command, any nonexistent, offline, or read-only data files are simply skipped and the processing continues.
• However, for the command ALTER DATABASE END BACKUP, if you have a data file with an OFFLINE file status, you receive a warning message. Also, with this command, if you have a tablespace in read-only mode, you do not receive any messages.