recovery manager (rman) updated for rac · 2018. 3. 18. · recovery manager (rman) updated for rac...

Recovery Manager (RMAN)

updated for RAC Topics

RMAN Major Features and Options

Architecture

o Terminology

o Connection to RMAN Target

o Flash Recovery Area and Estimate Size

Catalog Option

Configuration

o Create Catalog (optional)

o Check Flash Recovery Area (optional)

o Register your DB (optional, if using a Catalog)

o Backup Catalog and SYNC Databases (optional, if using a Catalog)

o Setup RMAN Settings

o Validate Backup

o Create the Backup

o Test Restore Process (optional)

Simplest Backup Command

Understanding the Backup Process

Delete specified archivelogs and backups

Special Considerations for RAC

Backing up Backups

Unregister a DB from RMAN or Delete data from Catalog if Backups has been

deleted

Image Copies

Incremental Backups

o Incremental Updated Backup

Backup and Recovery Best Practices

Scripting

REPORT AND LIST Commands

Recovery From Failure (with Examples)

http://www.pafumi.net/rman.htm#Recovery_Manager_Major_Featureshttp://www.pafumi.net/rman.htm#Recovery_Manager_Major_Featureshttp://www.pafumi.net/rman.htm#Architecturehttp://www.pafumi.net/rman.htm#Architecturehttp://www.pafumi.net/rman.htm#Terminology_in_RMANhttp://www.pafumi.net/rman.htm#Connection_to_RMAN_Targethttp://www.pafumi.net/rman.htm#Flash_Recovery_Area_FRAhttp://www.pafumi.net/rman.htm#Cataloghttp://www.pafumi.net/rman.htm#SetupConfigurationhttp://www.pafumi.net/rman.htm#Create_Cataloghttp://www.pafumi.net/rman.htm#Check_Flash_Recovery_Areahttp://www.pafumi.net/rman.htm#Register_DBhttp://www.pafumi.net/rman.htm#Backup_Catalog_and_SYNC_Databaseshttp://www.pafumi.net/rman.htm#RMAN_Settingshttp://www.pafumi.net/rman.htm#Validate_Backupshttp://www.pafumi.net/rman.htm#Create_Backuphttp://www.pafumi.net/rman.htm#Test_Restore_Processhttp://www.pafumi.net/rman.htm#Simple_Backup_on_RMANhttp://www.pafumi.net/rman.htm#Understanding_the_Backup_Process_http://www.pafumi.net/rman.htm#RMAN:_Delete_specified_archivelogs_andhttp://www.pafumi.net/rman.htm#Special_Considerations_for_RAChttp://www.pafumi.net/rman.htm#Backing_up_Backupshttp://www.pafumi.net/rman.htm#Unregister_a_Database_From_RMANhttp://www.pafumi.net/rman.htm#Unregister_a_Database_From_RMANhttp://www.pafumi.net/rman.htm#Image_Copieshttp://www.pafumi.net/rman.htm#IncrementalBackuphttp://www.pafumi.net/rman.htm#Incrementally_Updated_Backupshttp://www.pafumi.net/rman.htm#Backup_and_Recovery_Best_Practiceshttp://www.pafumi.net/rman.htm#Scriptinghttp://www.pafumi.net/rman.htm#ReportListhttp://www.pafumi.net/rman.htm#RecoveryfromFailure

o Recover from Missing or Corrupted Datafile or Tablespace or a non-

backed up Datafile

o Recover from Block Corruption

o Recover from Missing or Corrupted Redo Log Group

o Database Point-in-Time Recovery

o Restore Archive Log Files

o Recover a Table from Hot Backup

o Restore Backup Files from Disk Location other than Default

o Recover to a Restore Point

o Recover a NOARCHIVELOG database using a backup controlfile

Duplicate a Database

Managing Errors

11g New Feature: RMAN Data Recovery Advisor (DRA)

RMAN Backup Strategy

Scripts to get Information from RMAN

Unix Scripts

Collected Resources

Quick Backup with Details run {

allocate channel t1 type disk;



# Backup the whole DB

backup database spfile tag="Full_Database" format

'C:\app\RMAN_Backup\backup_%d_set%s_piece%p_%T_%U' ;

# Switch out of the current logfile

alter system archive log current;

# Backup the archived logs

crosscheck archivelog all;

backup archivelog all format

'C:\app\RMAN_Backup\arch_logs_%u';

# Backup a copy of the controlfile that contains records

for the other backups just made

backup current controlfile tag="Control_File" format

http://www.pafumi.net/rman.htm#Missing_or_Corrupted_Datafile-Tablespacehttp://www.pafumi.net/rman.htm#Missing_or_Corrupted_Datafile-Tablespacehttp://www.pafumi.net/rman.htm#Recovery_from_block_corruptionhttp://www.pafumi.net/rman.htm#Recovery_from_missing_or_corrupted_redo_log_grouphttp://www.pafumi.net/rman.htm#Case_6_-_Database_Point-in-time_recoveryhttp://www.pafumi.net/rman.htm#Case_7_-_Restore_Archiveloghttp://www.pafumi.net/rman.htm#Case_8_-_Recovering_a_Table_from_Hothttp://www.pafumi.net/rman.htm#Case_9-_Restore_Backup_files_from_Diskhttp://www.pafumi.net/rman.htm#Case_11:_Recover_to_a_Restore_Pointhttp://www.pafumi.net/rman.htm#Restore_a_NOARCHIVELOG_database_using_ahttp://www.pafumi.net/rman.htm#Duplicate_a_Databasehttp://www.pafumi.net/rman.htm#Managing_Errorshttp://www.pafumi.net/rman.htm#11g_New_Feature:_RMAN_Data_Recoveryhttp://www.pafumi.net/rman.htm#RMAN_Backup_Strategyhttp://www.pafumi.net/rman.htm#ScriptsforReportshttp://www.pafumi.net/rman.htm#Unix_Scriptshttp://www.pafumi.net/rman.htm#Resources

'C:\app\RMAN_Backup\rman_backup_controlfile_%d_ctl.bckp'

reuse;

# Creates a ccontrolfile copy on a specific location

backup as copy current controlfile

format 'C:\app\RMAN_Backup\Control_File_copy.ctl';

#Crosschecking will check that the catalog/controlfile

matches the physical backups. If a backup is missing, it

will set the piece to 'EXPIRED' (missing)

CROSSCHECK BACKUP;

# Delete un-necessary backups. This command deletes

backups based on the retention policy.

# Ignores any I/O errors, including those that occur when

a backup is missing from disk or tape

DELETE NOPROMPT force OBSOLETE;

# Delete the expired backups.

DELETE NOPROMPT EXPIRED BACKUP;

RELEASE CHANNEL t1;

RELEASE CHANNEL t2;

RELEASE CHANNEL t3;

}

Recovery Manager Major Features Recovery Manager contains a number features to aid in the backup, restore and

recovery operations in large, complex Oracle environments. These include:

o Backup file compression

o Incremental backups

o Corrupt block detection

o Fractured Block Detection

o Automatic parallelization

o Backup usability and restore validation reporting

o Recovery catalog for centralizing operations

o Trial Recovery

o Skip Unused blocks

o Block Level Recovery

Backup file Compression Recovery Manager only copies data blocks that contain data. A tablespace that is only

half filled will be backed up into a file half the size of an OS image copy of the same

tablespace.

Incremental Backups This feature allows backups to be performed that contain only database blocks that

have changed since the last full or incremental backup. This can greatly reduce the

size of backups. It can also reduce the time required to do a restoration. A typical

scenario would be to perform a weekly full backup and daily incrementals.

Change-Aware Incremental Backups In previous releases of the Oracle database, RMAN had to examine every block in the

data file to determine which blocks had been changed when performing an

incremental backup. The time to perform an incremental backup was proportional to

the size of the data files. Therefore, performing an incremental backup on a very

large database could take some time, even if only a few blocks were changed.

You can create a block change tracking file that records the blocks modified since the

last backup. RMAN uses the tracking file to determine which blocks to include in the

incremental backup. RMAN no longer needs to examine the entire data file. The

time to perform an incremental backup is now proportional to the amount of content

modified since the last backup. Here are the steps RMAN will perform to do an

incremental backup:

1. Read the Block Change Tracking File to determine which blocks in the data file

need to be read.

2. Scan only the changed blocks in the data file and then back them up.

The size of the block change tracking file is proportional to:

- The database size in bytes: the block change tracking file contains data representing

every data file block in the database. The data is approximately 1/250000 of the total

size of the database.

- The number of enabled threads: In a Real Application Cluster (RAC) environment,

the instances update different areas of the tracking file without any locking or inter-

node block swapping. You enable block change tracking for the entire database and

not for individual instances.

- The number of old backups: The block change tracking file keeps a record of all

changes between previous backups, in addition to the modification since the last

backup. It retains the change history for a maximum of eight backups.

The size of the file is calculated by the following formula:

Size of the Block Change Tracking File = ( (Threads*2) + number of old backups )

* database size in bytes / 250,000

The initial size for the block change tracking file is 10 MB. Using this formula, a 2

TB database with only one thread and having five backups in the RMAN repository

will require a block change tracking file of 59 MB.

Enabling, Disabling and Monitoring Block Change Tracking

By default, Oracle will not record block change information. To enable this feature,

you need to issue the following command: SQL> alter database enable block change tracking USING

FILE ‘/u01/oradata/ora1/change_tracking.f’;

To disable this feature, you issue this command: SQL> alter database disable block change tracking;

To monitor the status of block change tracking, you type: select file, status, bytes

from v$block_change_tracking;

STATUS FILE BYTES

-------- ---------------------------- ---------------

ENABLED /dba/backup/01_mf_yzmrr7.chg 10,000,000

If the location needs to be moved, change tracking can be disabled, and a new change

tracking file can be created, but this causes the database to lose all change tracking

information. Moreover, unfortunately the change tracking file cannot be moved

without shutting down the database, moving it with the appropriate ALTER

DATABASE RENAME FILE command, and then restarting the database.

Oracle does recommend that this feature be activated for any database whose disaster

recovery plan utilizes incremental backups of differing levels. Oracle also notes that

theirs is a small performance hit during normal operations, but that hit should be

discounted against the need to avoid scans of datafiles during restoration and recovery

operations.

Corrupt Block Detection When a backup is executed with Recovery Manager, the database blocks are read and

corruption is automatically detected. By default, when a corrupt block error is

detected by Recovery Manager, an error message will be displayed (or written to a log

file if not running interactively), and the backup terminates. This error message will

identify the file that the corrupt block is in. By setting the value of maxcorrupt to

something greater than zero (the default) and re-executing the backup or copy, more

information on the corrupt block will be put in the views

V$BACKUP_CORRUPTION or V$COPY_CORRUPTION.

Fractured Block Detection Another benefit of an Oracle server process being used when executing Recovery

Manager is that an Oracle server process can detect when a data block is fractured. A

data block is considered fractured when the control information in the header does not

match the information stored in the footer. A fractured block can occur during an

online backup because the Oracle data blocks are not always the same size as the

operating system block size.

Oracle data blocks are referred to as logical blocks while operating system blocks are

called physical blocks. In most environments, the logical block contains multiple

physical blocks. Therefore, while the operating system is backing up a database,

Oracle can be writing into multiple physical blocks at the same time the operating

system is reading a subset of the physical blocks written to by Oracle. To resolve this

problem, Oracle implemented the hot backup mode , which tells Oracle to copy the

entire logical block to the redo log buffer when a data block is modified. When the

database is not in hot backup mode, only the before and after image of the modified

row is written to the redo buffer. Since the server process can detect fractured blocks

and will reread the block if a fracture is detected, the hot backup mode is not

necessary using Recovery Manager.

Automatic Parallelization Backup and restore operations are automatically parallelized. This is supported with

both disk and tape backup/restore operations. The parallelization can be implemented

by using the allocate channel and filesperset Recovery Manager commands. Allocate

channel is used to assign I/O devices, and the filesperset is used to define how many

database files will be written to a single backup output file (called a backup set). The

total backup time can be reduced by taking advantage of parallelism.

Backup Usability and Restore Validation Reporting Recovery Manager has several features that allow a DBA to look at their backups and

analyze if the backups are OK.

The RMAN commands report and recover will help you to identify the backup status.

These commands can be executed interactively, or as scripts.

To find out if a tablespace has a datafile that can't be recovered (this could be due to

an unrecoverable operation, such as running SQL*Loader in UNRECOVERABLE

mode), enter:

report unrecoverable tablespace "users";

To determine if a database has not been backed up within the last 7 days, enter:

report need backup days 7 database;

Backups can become obsolete for various reasons including: a backup of a database

file that no longer exists, or there is a more recent backup of an existing file. A report

of obsolete backups can be used to determine what could be deleted from backup

media to free up space. To find backups that are obsolete because there are at least 2

more recent backups, enter:

report obsolete redundancy 2;

Recovery Manager has the capability of doing a "dry run" restoration of a database.

This can be valuable in determining that all files needed for the restoration are

available from backup media. The following is an example of validating restoration

for an entire database:

restore database validate;

This command checks for the database files needed for restoration, but not the archive

log files that may be needed to recover.

Recovery Catalog for Centralized Operations The recovery catalog is used to store information regarding backup and restore

operations. The catalog is a schema that should reside in a database other than those

being backed up (target databases). The recovery catalog can contain information

about multiple target databases. The reports described in the previous section were

generated from information stored in the recovery catalog. The recovery catalog is

also used to store scripts of Recovery Manager commands.

If you have just a few databases, then the recovery catalog is probably not worth the

extra effort and hassle. If you have a database environment with many databases in it,

you should consider using a recovery catalog. Generally, the added flexibility and

centralized enterprise-wide reporting benefits of the recovery catalog outweigh the

additional maintenance and administrative requirements that are added with the use of

a recovery catalog. One downside to using a recovery catalog, though, is that if the

catalog database is down, your backups will all fail unless you have coded your

backup scripts to perform a backup without the recovery catalog in cases where the

first backup with the recovery catalog fails.

Additionally, a recovery catalog is an essential part of a Data Guard backup

environment and Split mirror backups. In these configurations, when you back up the

database from the backup host, the recovery catalog is considered the most current

information, so it is the brains behind the strategy and becomes a single point of

failure if not maintained properly. The bottom line is that you need to decide for

yourself whether your environment calls for a recovery catalog.

Expanded Image Copying Features

A standard RMAN backup set contains one or more backup pieces, and each of these

pieces consists of the data blocks for a particular datafile stored in a special

compressed format. When a datafile needs to be restored, therefore, the entire datafile

essentially needs to be recreated from the blocks present in the backup piece.

An image copy of a datafile, on the other hand, is much faster to restore because the

physical structure of the datafile already exists. Since version 10g Oracle permits

image copies to be created at the database, tablespace, or datafile level through the

new RMAN directive BACKUP AS COPY. For example, here is a command script

to create image copies for all datafiles in the entire database:

RUN {

# Set the default channel configuration. Note the use of the

# %U directive to insure unique file names for the image copies

ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT

'c:\oracle\rmanbkup\U%';

# Create an image copy of all datafiles in the database

BACKUP AS COPY DATABASE;

}

More examples:

RUN {

# Set the default channel configuration

ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT

'c:\oracle\rmanbkup\ic_%d_%s_%t_%p';

# Back up specific datafiles and retain them as an image copies

BACKUP AS COPY (DATAFILE 2, 6, 9 MAXSETSIZE 25M);

# Back up a specific tablespace and retain it as an image copy

BACKUP AS COPY (TABLESPACE example MAXSETSIZE 15M);

# Back up the whole database and retain it as an image copy

BACKUP AS COPY DATABASE;

}

Incrementally Updated Backups As we saw before, it is now much simpler to create image copy backups of the

database. Another new feature since Oracle 10g is to incrementally updated backups,

allows me to apply incremental database changes to the corresponding image copy

backup - also known as rolling forward the datafile image copy -- of any datafile in

the database. Since image copy backups are much faster to restore in a media recovery

situation, this new feature gives me the option to have updated image copies ready for

restoration without having to recreate the image copies on a regular basis.

To utilize this feature, you will use the new BACKUP ... FOR RECOVER OF

COPY command to create the incremental level 1 backups to roll forward the changes

to the image copy of the datafiles, and use the new RMAN RECOVER COPY OF

DATABASE command to apply the incremental backup to the image copies of the

datafiles. Note that the TAG directive becomes extremely important to this

implementation, as it is used to identify to which image copies the changes are to be

rolled forward. Here is a script that illustrates a daily cycle of creation and application

of the incrementally updated backups. This would be appropriate for a database that

has sufficient disk space for storage of image copies, and has a relatively high need

for quick restoration of media:

RUN {

# Roll forward any available changes to image copy files

# from the previous set of incremental Level 1 backups

recover copy of database with tag 'img_cpy_upd';

# Create incremental level 1 backup of all datafiles in the database

# for roll-forward application against image copies

backup incremental level 1

for recover of copy with tag 'img_cpy_upd' database;

}

Though this appears a bit counter-intuitive at first, here is an explanation of what

happens during the initial run of this script:

* The RECOVER command actually has no effect, because it cannot find any

incremental backups with a tag of img_cpy_upd.

* However, the BACKUP command will create a new Incremental Level 0 backup

that is labeled with a tag of img_cpy_upd because no backups have been created yet

with this tag.

And during the second run of this script:

* The RECOVER command still will have no effect, because it cannot find any

Level 1 incremental backups with a tag of img_cpy_upd.

* The BACKUP command will create its first Incremental Level 1 backup that is

labeled with a tag of img_cpy_upd.

But during the third and subsequent runs of this script:

* The RECOVER command finds the incremental level 1 image copy backups from

the previous night's run tagged as img_cpy_upd, and applies them to the existing

datafile image copies.

* The BACKUP command will create the next Incremental Level 1 backup that is

labeled with a tag of img_cpy_upd.

After the third run of this script, RMAN would then choose the following files during

a media recovery scenario: the image copy of the database for tag img_cpy_upd from

the previous night, the most recent incremental level 1 backup, and all archived redo

logs since the image copy was taken. This strategy offers a potentially quick and

flexible recovery, since the datafile image copies will be relatively quick to restore,

and the incremental level 1 backup plus all archived redo logs can be used to perform

either a point-in-time or a complete recovery.

Example: Incrementally-Updated Backups: A Weekly Implementation

RUN {

######

# This script will create image copy backups to which incremental

# changes can be applied on a weekly schedule

######

# Roll forward any available changes to image copy files

# from the previous set of incremental Level 1 backups. Note that

# the roll-forward will not occur until 7 days have elapsed!

recover copy of database with tag 'img_cpy_upd'

until time (sysdate-7);

## Create incremental level 1 backup of all datafiles in the database

# for roll-forward application against weekly image copies

backup incremental level 1

for recover of copy with tag 'img_cpy_upd' database;

}

Database Dropping and Deregistration Oracle allows a database to be dropped and its entry removed from the RMAN

catalog. The following statement drops the entire database and removes the database

files:

RMAN> drop database;

The statement below drops the entire database, removes the database files, and deletes

all backup copies of the database and the archive log files:

RMAN> drop database including backups;

The two statements above drop the database and delete the database files. However,

they do not unregister the database from the RMAN catalog. The following statement

will remove the database information from the RMAN catalog:

RMAN> unregister database grid;

RMAN Architecture The production database that you are backing up is called the target. A separate

database, called the recovery catalog, contains information about datafile and

control-file copies, backup sets, archived redo logs, and other key elements needed for

recovery.

RMAN performs two main functions:

- It maintains the RMAN metadata in the control file or the recovery catalog.

- It communicates with the Oracle database and the operating system in order to

create, restore, and recover backup sets and image copies. (RMAN writes image

copies to disk only, not to tape.)

RMAN creates several client connections, or channels, between the target database

and the backup storage device. RMAN can create backup sets on disk or directly on

tape. To use tape storage, RMAN requires a media manager.

If you have more than one database to back up, you can create more than one recovery

catalog and have each database serve as the other's recovery catalog. For example,

assume there are two production databases, one called "prd1," and a second called

"prd2." You can install the recovery catalog for "prd1" in the "prd2" database, and the

recovery catalog for the "prd2" database in "prd1." This enables you to avoid the extra

space requirements and memory overhead of maintaining a separate recovery catalog

database. However, this solution is not practical if the recovery catalog databases for

both reside in tablespaces residing on the same physical disk.

To get the most out of RMAN, you should always use a recovery catalog, which

contains details of all backup-and-recovery-related operations. RMAN uses the

catalog to identify the relationship between backups and database files, automatically

deciding which recovery events will minimize the mean time to recover (MTTR). If

you run RMAN without using a recovery catalog, it will gather the necessary

information from the database's control file but won't support point-in-time recovery.

And if you lose all copies of your control file you'll be out of luck. That's why unless

you have only one computer running the Oracle software, you should always use a

recovery catalog and store it on totally separate hardware from any of your production

or target instances - preferably in a separate location. The catalog itself rarely

occupies more than 40MB.

IMPORTANT NOTE: Save the database id displayed in the RMAN output if you are operating RMAN

backups in nocatalog mode, since it is required during disaster recovery.

You will see the database id in output from RMAN on connecting to target database

like:

connected to target database: INVENTORY (DBID=1670954628)

There are 2 ways to find the DBID:

a. If RMAN Backup text logs are maintained, the DBID can be found when the initial

connection is made to the target , or

b. If autobackup is enabled and has the autobackup format set (let’s say the format is

'%F'), then the filename of the autobackup has the DBID in it.

For example, 'c-1106578690-20100408-00' is the name of the autobackup file; so the

DBID should be '1106578690'.

It's also recommended to save your init.ora file and your tnsnames.ora file in a "safe"

place.

Terminology in RMAN When you issue an RMAN backup command, RMAN creates backup sets, which are

logical groupings of physical files. You can see this value in your reports as the "BS

KEY" column.

The physical files that RMAN creates on your backup media are called backup

pieces. When working with RMAN, you need to understand that the following terms

have specific meanings:

a) RMAN Backup - A backup of all or part of your database. This results from

issuing an RMAN backup command. A backup consists of one or more backup sets.

b) Backup Set - A logical grouping of backup files -- the backup pieces -- that are

created when you issue an RMAN backup command. A backup set is RMAN's name

for a collection of files associated with a backup. Backup sets consist of datafiles or

archivelogs. A single backup set cannot contain a combination of archivelogs and

datafiles.

Backup sets consist of one or more individual backup files. The individual files

contained in a backup set are called backup pieces.

Backup sets can be full or incremental. A full backup is a backup of all of the blocks

that make up a datafile or datafiles. Recovery Manager allows you to take full

backups of datafiles, datafile copies, tablespaces, archive logs, control files and

databases. Incremental backups copy blocks that have been changed since a previous

backup. Incremental copes can be taken of datafiles, tablespaces and databases.

Recovery Manager also provides cumulative backups. Cumulative backups copy all

blocks that have been changed since the most recent incremental backup.

c) Backup piece: A physical binary file created by RMAN during a backup. Backup

pieces are written to your backup medium, whether to disk or tape. They contain

blocks from the target database's datafiles, archived redo log files, and control files.

When RMAN constructs a backup piece from datafiles, there are a several rules that

it follows:

* A datafile cannot span backup sets.

* A datafile can span backup pieces as long as it stays within one backup set.

* Datafiles and control files can coexist in the same backup sets.

* Archived redo log files are never in the same backup set as datafiles or control

files.

RMAN is the only tool that can operate on backup pieces.

d) Image Copy: Is a bit-by-bit copy of database files created on Disk. This is

equivalent to cp (on Linux) or copy (on windows).

An image copy is a single datafile that you can use as input to a recovery. The Oracle

server process validates the blocks in the file during backup and registers the copy in

the recovery catalog. Image copies do not require the execution of a recovery

operation, the datafile can be renamed to the image copy.

As a result, image copies:

Do not store header or footer control information.

Must be written to disk.

Cannot be compressed.

Cannot contain multiple input or output files.

Cannot be multiplexed (discussed later).

e) Parallel Backup and Recovery Recovery Manager is able to parallelize a single backup, recovery or restore

operation, but is unable to process multiple commands in a stored script in parallel.

The RMAN script below uses three channels to back up three data files identified by

their file number. This creates three separate server processes each one sending a data

stream to the tape device.

RUN

{

ALLOCATE CHANNEL t1 DEVICE TYPE sbt;



BACKUP DATAFILE 3,4,5 ;

}

- Hot backup - backup taken while Oracle Database is Up. (Database should be in

“Archive Log” mode for hot backup)

- Cold backup - backup taken while Oracle database is down or in mount state (NOT

OPEN).

- Full Backup - Backing up entire database is called as full backup

- Incremental Backup - Backup of block level changes to database made after

previous incremental/full backup.

- “Level 0" Incremental backup - This backs up all blocks in database. This is

equivalent to full backup.

- “Level 1" Incremental backup - This backs up database block changes after

previous incremental backup.

If there is no level 0 incremental backup and you run level 1 incremental backup,

RMAN will automatically make level 0 incremental backup.

- Cumulative incremental backup - level 1 incremental backup which includes all

blocks changed since most recent level 0 incremental backup.

- Differential incremental backup - level 1 incremental backup which includes only

block changed since most recent incremental backup.

By default, incremental backups are differential

Connection to RMAN Target There are several ways to connect to your target DB:

rman target /

rman target=sys/passwd@PROD

rman

connect target sys/mh_flyers@PROD

If you get ORA-01031, you can also perform: rman target sys

or rman target sys/passwd

or rman

connect target sys

or rman

connect target sys/passwd

Flash Recovery Area (FRA) and Estimate

Size

Please READ HERE FIRST!!!!

With Automatic Disk-Based Backup and Recovery, you can create a flash recovery

area, which automates management of backup-related files. Choose a location on disk

and an upper bound for storage space and set a retention policy that governs how long

backup files are needed for recovery, and then the database manages the storage used

for backups, archived redo logs, and other recovery-related files for your database

within that space.

Files no longer needed are eligible for deletion when RMAN needs to reclaim space

for new files. If you do not use a flash recovery area, you must manually manage disk

space for your backup-related files and balance the use of space among the different

types of files. Oracle recommends that you enable a flash recovery area to simplify

your backup management.

Using a flash recovery area simplifies the ongoing administration of your database by

automatically naming files, retaining them as long as they are needed for restore and

recovery activities, and deleting them when they are no longer needed to restore your

database and space is needed for some other backup and recovery-related purpose.

Your long-term backup and recovery administration can be greatly simplified by

using a flash recovery area. Use of the flash recovery area is strongly recommended.

You may want to set up a flash recovery area as one of the first steps in implemeting

your backup strategy.

By configuring the RMAN RETENTION POLICY, the FRA will automatically delete

obsolete backups and archive logs that are no longer required based on that

configuration. If you set the RETENTION POLICY to a recovery window of 7 days,

then RMAN will retain all backups required to recover the database 7 days in the past.

FRA will delete obsolete files once the disk is arriving to the quote defined.

All files that are needed to completely recover a database from a media failure are part

of the Flash Recovery Area. Those recovery related files include:

• Control file: A copy is created in the Flash Recovery Area location at database

creation.

• Archived log files: When the Flash Recovery Area is configured, the archiver

background process then creates archived files in the Flash Recovery Area and in

other configured LOG_ARCHIVE_DEST_n locations.

http://www.pafumi.net/Flash_Recovery_Area.html

• Flashback logs: the Flash Recovery Area automatically manages Flashback

Database logs.

• Control file autobackups: The default location for control file .

• Data file copies: The default location for data file copies created by RMAN is

stored in the Flash Recovery Area.

• RMAN backups: The default location for RMAN to create files during backup &

copy operations. It is also the default location to restore archive logs from tape if they

are required during a recover task.

Per default a backuppiece is created in the Flash Recovery Area unless it is overruled

by using the FORMAT-clause. The FORMAT-clause can be specified in the

BACKUP command or configured in the persistent configuration, by using

CONFIGURE command.

Like with normal backup, the Controlfile autobackup will be stored in the Flash

Recovery Area unless the location is overruled by the FORMAT for the autobackup.

RMAN> configure controlfile autobackup format for device type disk to ;

By default RMAN restores the archived redologs in the LOG_ARCHIVE_DEST_n

location. If one of the LOG_ARCHIVE_DEST_n parameters is set

to "LOCATION=USE_DB_RECOVERY_FILE_DEST" then restored archived redo

log files will be stored in the Flash Recovery Area.

This can be overrulled by using the RMAN command :

RMAN> SET ARCHIVELOG DESTINATION ;

RMAN File Creation in the Flash Recovery Area This section describes RMAN commands or implicit actions (such as control file

autobackup) that can create files in the flash recovery area, and how to control

whether a specific command creates files there or in some other destination. The

assumption in all cases is that a flash recovery area has already been configured for

your database. The commands are:

- BACKUP

If you do not specify a FORMAT option to the BACKUP command, and do not

configure a FORMAT option for disk backups, RMAN creates backup pieces and

image copies in the flash recovery area, with names in Oracle Managed Files name

format.

- Control File Autobackup

RMAN can create control file autobackups in the flash recovery area. Use the RMAN

command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE

TYPE DISK CLEAR to clear any configured format option for the control file

autobackup location on disk. Control file autobackups will be placed in the flash

recovery area when no other destination is configured.

- RESTORE ARCHIVELOG

Explicitly or implicitly (as in the case of ), set one of the LOG_ARCHIVE_DEST_n)

parameters to 'LOCATION=USE_DB_RECOVERY_FILE_DEST'. If you do not

specify SET ARCHIVELOG DESTINATION to override this behavior, then restored

archived redo log files will be stored in the flash recovery area.

- RECOVER DATABASE or TABLESPACE, BLOCKRECOVER, and

FLASHBACK DATABASE

These commands restore archived redo logs from backup for use during media

recovery, as required by the command. RMAN restores any redo log files needed

during these operations to the flash recovery area, and delete them once they are

applied during media recovery.

To direct the restored archived redo logs to the flash recovery area, set one of the

LOG_ARCHIVE_DEST_n parameters to

'LOCATION=USE_DB_RECOVERY_FILE_DEST", and make sure you are not

using SET ARCHIVELOG DESTINATION to direct restored archived logs to some

other destination.

Sizing FRA If you want to keep:

–Control file backups and archived logs

Then estimate total size of all archived logs generated between successive backups on

the busiest days x 2 (in case of unexpected redo spikes)

–Flashback logs

Then add in {Redo rate x Flashback retention target time x 2}

–Incremental backups

Then add in their estimated sizes

–On-disk image copy

Then add in size of the database minus size of temporary files

FRA File Retention and Deletion When FRA space needs exceed quota, automatic file deletion occurs in the following

order:

1. Flashback logs = Oldest Flashback time can be affected (with exception of

guaranteed restore points)

2. RMAN backup pieces/copies and archived redo logs that are:

• Not needed to maintain RMAN retention policy, or

• Have been backed up to tape (via DEVICE TYPE SBT) or secondary disk

location (via BACKUP RECOVERY AREA TO DESTINATION ‘..’)

If archived log deletion policy is configured as:

– APPLIED ON [ALL] STANDBY = Then archived log must have been applied to

mandatory or all standby databases

– SHIPPED TO [ALL] STANDBY = Then archived log must have been transferred to

mandatory or all standby databases

– BACKED UP TIMES TO DEVICE TYPE [DISK | SBT] = Then archived log

must have been backed up at least times

– If [APPLIEDor SHIPPED] and BACKED UPpolicies are

configured, both conditions must be satisfied for an archived log to be considered for

deletion.

Installing a Catalog One important decision when using RMAN is deciding whether to use a recovery

catalog. This section covers the pros and cons of a catalog and then details catalog

implementation issues.

What Is the Catalog? In many respects, RMAN can be thought of as an Oracle database file backup and

restoration utility. RMAN must keep track of many things. When was the last backup

taken? Which files were backed up? Which backup sets contain which database files?

The answers to these questions can be found in the target control files. Optionally,

RMAN can be configured to store this information in a separate database known as

the catalog. The catalog consists collectively of a database and a database schema.

The schema objects hold the RMAN-specific information for each of your target

databases.

Catalog advantages When you use a catalog repository, you get more flexibility and access to all the

features of RMAN. The advantages of using a catalog accrue in the following areas:

You can retain backup and recovery metadata for long periods of time.

You can centralize operations.

RMAN becomes more flexible in certain backup and recovery scenarios.

A catalog enables you to recover your control files in the event that they are all

corrupted or lost. If you are not using a catalog, and you haven't backed up your

control files via an ALTER DATABASE BACKUP CONTROLFILE command, you

could find yourself in the unenviable position of not being able to recover your target.

Another good reason to use a catalog is that information pertaining to your RMAN

backup and recovery activities can be stored for very long periods of time. If for any

reason you had to use a backup set that was several months old, a catalog provides

more flexibility to go back further in time than with the NOCATALOG option.

With a catalog, you can manage all of your backup and recovery activities from one

repository. The advantage of this is that if you have multiple databases to maintain,

you're storing all of your backup and recovery metadata in one place.

Finally, when using the catalog, you have greater flexibility during certain recovery

situations. For example, you can use previous incarnations of the database for

recovery.

Catalog disadvantages While the advantages of the catalog are substantial, there are a few potential

headaches that you should be aware of:

Upgrades and compatibility can be problematic.

A catalog adds complexity.

A catalog can increase your needs for hardware and DBA resources.

If you're backing up production databases, and you want the most flexibility possible

for any given backup and recovery scenario, Oracle recommends that you use a

catalog database. However, if you have nonproduction databases for which you want

to implement RMAN functionality, but you don't want the overhead of a catalog, you

may want to consider just using the target control files.

Using RMAN without a catalog RMAN can be used out of the box to back up, restore, and recover a database without

setting up a catalog. You may decide not to use a catalog because you have limited

resources or because you want a quick and easy backup and recovery mechanism for

your databases. This section points out the issues you need to be aware of if you

choose this route:

If you are using Oracle8i or an earlier version, you may not be able to recover your

database if you lose all of your control files. If this happens, you may not be able to

recover your database. If you exclusively use the target control files for the repository,

you must put into place a mechanism that backs up your control files. (This should be

a standard practice anyway.) You should also multiplex your control files to multiple

disk drives. If you do not use a catalog, make sure that your control files are backed

with: ALTER DATABASE BACKUP CONTROLFILE ......

Catalog Issues The creation of the catalog database is fairly straightforward. It is, after all, just a

database, schema, and objects. Here are some issues you should consider:

Where to put the database that will host the catalog

Which database version to use for the catalog

How to size the catalog

How to manage multiple target databases

Physical location of the catalog

You should place the catalog database on a different server than the target database. If

you fail to do this, you jeopardize backup and recovery operations, because you make

it possible to lose both the catalog and target databases.

The catalog can coexist in a database used for other applications. The advantage to

this is that you leverage existing resources. The disadvantage is that the performance

and availability of your catalog can be affected by other applications within the same

database.

Version of catalog

What version of Oracle should you use to create the catalog database? We suggest that

the catalog database be created with the latest version of Oracle in your production

environment. This helps to minimize compatibility issues and complexity when you

start to back up your target databases.

RMAN Configuration STEP 1 Modify your Net Connnections and Create the Recovery Catalog

(Optional) Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG

environment variables. Much of the RMAN LIST output is date/time related. It is

often necessary to have this information displayed as accurately as possible when

performing time-based recovery. Example NLS settings:

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS THIS ONE IS VERY

IMPORTANT!!!

Your TNSNAMES.ORA file should have an entry for both your catalog and target

databases. For this example, we will use two databases, the catalog

database (RMAN) and the target database (PROD).

Then, create the catalog (optional)

Connect to the Oracle RMAN instance by using your DBA account, create an account

for RMAN, and grant it appropriate rights.

sqlplus "sys@RMAN as sysdba"

create tablespace RMAN datafile '.......' size 150M autoextend on next 10M maxzize

700M

EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

create user RMAN identified by rman temporary tablespace TEMP default tablespace

RMAN quota unlimited on RMAN;

grant recovery_catalog_owner, connect, resource, create session, dba to RMAN;

connect RMAN/RMAN@RMAN

rman catalog=rman/rman@RMAN

rman> create catalog;

To drop the catalog run (no backups performed yet):

rman> drop catalog;

STEP 2 Check Flash Recovery Area for your PROD (optional) This is where the backups are going to be saved. You can check this parameter by

quering query v$recovery_file_dest view. If the space is not big enough, then increase

it.

If this parameter is not defined yet, cou can do it by:

alter system db_recovery_file_dest = '/temp/...' scope=both;

alter system db_recovery_file_dest_size = 10G scope=both;

(ALTER SYSTEM set db_recovery_file_dest_size=60G scope=both

sid='*' ; if using RAC)

STEP 3 Register Your Database (only if you created a catalog) Now you need to register your target database (PROD) with the catalog you've created

(if you did it). This populates the catalog with initial information regarding the

configuration of your target database and includes a full synchronization of the

catalog with the target database's control file. Call to the rman command file FROM

your TARGET DB. For example from the PROD box:

rman target / catalog=rman/rman@RMAN

OR

rman target [rcvcat | cmdfile |

msglog | append | trace ]

TARGET= A connect string containing a userid and password for the database on

which Recovery Manager is to operate.

RCVCAT= A connect string that contains a userid and password for the database that

contains the recovery catalog (RMAN).

CMDFILE= The name of a file that contains the input commands for RMAN. If this

argument is specified, RMAN operates in batch mode; otherwise, RMAN operates in

interactive line mode.

MSGLOG= The name of a file where RMAN records commands and output Results.

If not specified, RMAN outputs to the screen.

APPEND= This parameters causes the msglog file to be opened in append mode. If

this parameter is not specified and a file with the same name as the msglog file

already exists, it is overwritten.

TRACE= A file name where RMAN will dump a trace information. (useful feature

for RMAN jobs debugging)

Note: RMAN automatically requests a connection to the target database as SYSDBA.

In order to connect to the target database as SYSDBA, you must either:

Be part of the operating system DBA group with respect to the target

database. This means that you have the ability to CONNECT INTERNAL

to the target database without a password.

-or -

Have a password file setup. This requires the use of the "orapwd"

command and the initialization parameter "remote_login_passwordfile".

--As a comment, you can start RMAN from any PROD server using:

rman catalog=rman/rman@RMAN target=sys/passwd@PROD

or

rman

connect target sys/mh_flyers@PROD

connect rcvcat rman/rman@RMAN

Then Register the Database:

rman> register database

Once complete, the DBID, DB_NAME and structure are captured in the recovery

catalog. To verify the registration run:

rman> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 38 39 PROD 4283267716 YES 19688901 10-MAY-01

NOTE= Take a note of your DB ID!!!!!!

STEP 4 Back Up the Catalog and Synchronize All Databases If you lose your catalog, you can partially regenerate it from the information in the

control file, but you should avoid that predicament by backing it up. You can use

RMAN to back up the catalog by creating a recovery-catalog schema in one of your

other instances, using that as the catalog for your primary catalog instance. Providing

that these two instances do not share any common resources, this role reversal is free

from single points of failure.

It's important that your recovery catalog has an up-to-date view of your database.

When you execute RMAN operations on the database, RMAN automatically

synchronizes the catalog with the target. However, depending on the volatility of your

database, you may need to resynchronize the catalog more frequently. Always include

catalog resynchronization as part of any structural database change (the addition of

files, tablespaces, and so on) and ensure that a resynchronization occurs at intervals

less than the init.ora setting for the parameter

CONTROL_FILE_RECORD_KEEP_TIME. To perform this action, issue

the RESYNC CATALOG command from within RMAN.

STEP 5 Setup RMAN Settings You can always setup the settings from the OEM Console: DB Home Page/Maint

Property / Backup and Recovery. This settings are specified only one time.

Use the following command to check your settings once you connect:

rman target / catalog=rman/rman@RMAN

rman> show all;

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #

default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO

'/u01/app/oracle/product/9.2.0/dbs/snapcf_ORA920.f'; # default

Recommended Configuration Parameters

configure default device type to disk;

configure retention policy to redundancy 2;

configure device type disk parallelism 2;

configure channel device type disk format

'/orabackup/rman/ORA920/backup_%d_set%s_piece%p_%T_%U' maxpiecesize

5000M;

configure controlfile autobackup on;

configure controlfile autobackup format for device type disk to

'/orabackup/rman/ORA920/rman_backup_controlfile_%d_ctl';

configure backup optimization on;

rman> show all; CONFIGURE DEFAULT DEVICE TYPE TO DISK;

#By Default save all the Backups to disk

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

# Keep at least two copies of each datafile and controlfile backup.

# Note that when configuring a retention policy, RMAN will not cause backups

to be automatically deleted.

# The retention policy will, however, mark backups as OBSOLETE that have

fallen outside the retention period.

# RMAN commands like "REPORT OBSOLETE" and "DELETE OBSOLETE" will work with

these obsolete backups.

# If you have certain backups which must be retained longer than this

retention policy,

# you can use the KEEP option with the BACKUP command when creating those

backups

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;

# By default put 2 channels per backup:



CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT

'/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 5000 M;

# Specifies the location and name of the backup files. We need to specify the

format for each channel.

# The format specifier %t is replaced with a 4-byte timestamp, %s with the

backup set number, and %p with the backup piece number.

The "%U" ensures that Oracle appends a unique identifier to the backup file

name.

The MAXPIECESIZE (optional) attribute sets a maximum file size for each file

in the backup set.


CONFIGURE CONTROLFILE AUTOBACKUP ON;

# Performs backup of controlfile and spfile to the same backup piece each

time a backup or copy is performed (default location is FRA).

NOTE= If you are not going to use a recovery catalog, and you wish to be able

to recover your control file after an automated control file backup,

you must know the DBID of the database. You should, as a part of your initial

setup and configuration of RMAN, note the DBIDs of the databases that

you will be backing up and save that list somewhere safe.

The DBID of the database is available from the V$DATABASE view in the DBID

column and it's also displayed when you start RMAN and connect to a target

database.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO

'/some_location/rman_backup_controlfile_%d_%F_ctl.bckp';

# Performs the Backup of the controlfile on that place instead of the Flash

Recovery Area,

# The "%F" in the file name translates into c-IIIIIIIIII-YYYYMMDD-QQ, where:

* IIIIIIIIII - stands for the DBID. (The DBID is printed in decimal so

that it can be easily associated with the target database.

* YYYYMMDD - is a time stamp in the Gregorian calendar of the day the

backup is generated.

* QQ - is the sequence in hexadecimal number that starts with 00 and has

a maximum of 'FF' (256).

CONFIGURE BACKUP OPTIMIZATION ON;

#If we turn this command ON, then RMAN will not backup already backuped

unchanged data files

Other Options:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/some_location/snapcf_ORA920.f';

# Where to create the snapshot file for resync

CONFIGURE EXCLUDE FOR TABLESPACE tbl_exclude;

# Excludes tbs_exclude from full database backups.

# NOEXCLUDE can be specified with the BACKUP command to override this

configuration.

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Governs archived redo log deletion policy for the flash recovery area.

Possible options :

APPLIED ON STANDBY - enables FRA to delete archivelogs that are applied on

mandatory standby.

NONE - enables FRA to delete archivelogs that are backed up to

tertiary device and that are obsolete based on the configured backup

retention policy.

This is the default configuration.

CLEAR - clears the deletion policy and returns the specified

configuration to default value. The default value is NONE.

By default, archived redo log files in a FRA that were backed up to a

tertiary device or made obsolete (as defined by the RMAN retention policy)

are eligible for deletion.

Examples of the CONFIGURE ARCHIVELOG DELETION POLICY Command:

When backups of archived redo log files are taken on the standby database:

1. Issue the following command on the primary database:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

2. Issue the following command on the standby database:


When backups of archived redo log files are taken on the primary database:

1. Issue the following command on the standby database:


2. Issue the following command on the primary database:


Reconfiguring the Deletion Policy After a Role Transition :

After a switchover or failover, you may need to reissue the RMAN CONFIGURE

ARCHIVELOG DELETION POLICY command on each database.

If the backup site for archived redo log files remains the same, then do nothing.

Otherwise, you must switch the archivelog deletion policy by issuing the

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

statement on the database where backups are not taken, and issuing the CONFIGURE

ARCHIVELOG DELETION POLICY TO NONE statement on the database where

backups are taken.

Viewing the Current Deletion Policy

To view the current setting (APPLIED ON STANDBY, CLEAR, NONE) for a

database,issue the following query:

SELECT NAME, VALUE

FROM V$RMAN_CONFIGURATION

WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%';

NAME VALUE

----------------------------- --------------

ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

You can also find the existing configuration using the RMAN SHOW ARCHIVELOG

DELETION POLICY command:

RMAN> SHOW ARCHIVELOG DELETION POLICY



Using Substitution Variables RMAN can make use of substitution variables in creating format strings to generate

filenames. Without due care, non-unique filenames can be generated and, under

certain circumstances, this can cause backup data to be overwritten and therefore lost.

So be careful; this is not a bug with Oracle, but rather a usage error.

Format Description

%p specifies the backup piece number within the backup set. This value starts at 1 for each

backup set and is incremented by 1 as each backup piece is created.

%s

specifies the backup set number. This number is a counter in the control file that is

incremented for each backup set. The counter value starts at 1 and is unique for the

lifetime of the control file. If you restore a backup control file, then duplicate values

can result. Also, CREATE CONTROLFILE initializes the counter back to 1.

%d specifies the database name.

%n specifies the database name, padded on the right with 'x' characters to a total length of

8 characters. For example, if PROD1 is the database name, then PROD1xxx is the

padded database name.

%t specifies the backup set timestamp, which is a 4-byte value derived as the number of

seconds elapsed since a fixed reference time. The combination of %s and %t can be

used to form a unique name for the backup set. Format YYYYMMDD

%u specifies an 8-character name constituted by compressed representations of the backup

set number and the time the backup set was created.

%c

(Oracle8i or higher) - specifies the copy number of the backup piece within a set of

duplexed backup pieces. If you did not issue the set duplex command, then this

variable will be 1 for regular backup sets and 0 for proxy copies. If you issued set

duplex, the variable identifies the copy number: 1, 2, 3, or 4.

%U (Oracle8i or higher) - specifies a convenient shorthand for %u_%p_%c that guarantees

uniqueness in generated backup filenames. If you do not specify a format, RMAN uses

%U by default. %U is the default in Oracle8i.

We can always clean these settings to its default values using:

configure ...... clear;

STEP 5.5 Validating Backups (optional) You can run a test RMAN backup that does not generate any output. The test checks

datafiles for physical and logical corruption and that all database files exist and are in

the correct locations. For example:

RMAN> backup validate database archivelog all;

or a Full Validation: run

{


restore archivelog from time 'sysdate-1' validate;

restore controlfile validate;

restore spfile validate;

}

If you get: RMAN-06059: expected archived log not found, lost of

archived log compromises recoverability

It means that the Archive Log Files doesn't exist (maybe was removed on OS level but

not by RMAN). Your options are either to restore the missing file(s), or to perform a

crosscheck. To perform a crosscheck, run the following command from within

RMAN:

RMAN> crosscheck archivelog all;

This will give non-existing archivelogs status of 'EXPIRED', these are no longer used

for backups.

When an archive log crosscheck is performed, RMAN checks each archive log in turn

to make sure that it exists on disk (or tape). Those that are missing are marked as

unavailable. If you have got missing logs, this won't bring them back. It will allow

you to get past this error and back-up the database though.

It is advisable to perform a full backup of the database at this point. Schedule a

crosscheck every once in a while (e.g. weekly) in order to prevent this.

And then run:

RMAN> list expired archivelog all;

to see if it lists any missing archive logs.

And then:

RMAN> delete expired archivelog all;

to remove the expired ones.

The VALIDATE command initiates data integrity checks, logging physical, and

optionally logical, block corruptions of database files and backups in the

V$DATABASE_BLOCK_CORRUPTION view and the Automatic Diagnostic

Repository as one or more failures.

The following code shows some of the possible syntax variations.

# Check for physical corruption of all database files.

VALIDATE DATABASE;

# Check for physical and logical corruption of a

tablespace.

VALIDATE CHECK LOGICAL TABLESPACE USERS;

# Check for physical and logical corruption of a

datafile.

VALIDATE CHECK LOGICAL DATAFILE 4;

# Check for physical corruption of all archived redo logs

files.

VALIDATE ARCHIVELOG ALL;

# Check for physical and logical corruption of the

controlfile.

VALIDATE CHECK LOGICAL CURRENT CONTROLFILE;

# Check for physical and logical corruption of a specific

backupset.

VALIDATE CHECK LOGICAL BACKUPSET 3;

The BACKUP VALIDATE and RESTORE VALIDATE commands perform the

same checks as the VALIDATE command for the files targeted by the backup or

restore command, but they don't actually perform the specified backup or restore

operation. This allows you to check the integrity of a backup or restore operation

before actually performing it.

The following code shows some of the possible syntax variations.

# Check for physical corruption of files to be backed up.

BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

# Check for physical and logical corruption of files to

be backed up.

BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

# Check for physical corruption of files to be restored.

RESTORE VALIDATE DATABASE;

# Check for physical and logical corruption of files to

be restored.

RESTORE VALIDATE CHECK LOGICAL DATABASE;

STEP 6 Create Database Backups Now you are ready to run a Full Backup.

The simplest backup is an offline (Cold) backup, you can:

% rman target system/manager@PROD

RMAN> shutdown immediate

RMAN> startup force dba;

RMAN> shutdown immediate

RMAN> startup mount

RMAN> backup database include current controlfile tag 'before_upgrade';

RMAN> alter database open;

Note the inclusion of the current control file with the backup, and the use of the tag to

identify the backup. To use this backup of the database, the control file must be

restored from the same backup as the rest of the database. Adding INCLUDE

CURRENT CONTROLFILE ensures that a usable backup of the control file is

included with the backup and tagged in order to simplify restoring the control file with

the rest of the database.

Now for an Online (Hot) Bakup:

export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

% rman target system/manager@PROD

rman> backup spfile; #Just to test the

backup of this file, it will save it to the default place (Flash Recovery Area or Disk)

rman> backup database plus archivelog tag="Full_Database"; # Will backup to the

default place (Flash Recovery Area or Disk) with a tag

rman> backup database format '/tmp/%U'; #Backup to a

Specific Place, the %U generates a unique name.

rman> backup archivelog all delete input; #Backup All

Archive log Files and delete the ones that were backuped from PROD

rman> backup archivelog all delete all input; #Backup All

Archive log Files and delete all of them from PROD

Next we perform a complete database backup using a single command, we will put a

tag and delete obsolete files:

RMAN> run {

backup database plus

archivelog tag="Full_Database";

delete noprompt force obsolete;

}

When you run RMAN in command line mode, it sends the output to the terminal.

If you specify the msglog option, then RMAN writes the output to a specified log file

instead. Example:

rman target=/ nocatalog msglog Full_RMAN_Backup.txt

In this example, a sample RMAN script is placed into a command file called

commandfile.rcv. You can run this file from the operating system command line and

write the output into the log file outfile.txt as follows:

rman TARGET / CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG

outfile.txt

The Abbreviated Syntax is: BACKUP [ FULL | INCREMENTAL LEVEL integer ]

[ CUMULATIVE ]

[ FORMAT '/path/filename' ]

[ TAG tag ]

{DATABASE | TABLESPACE 'name' , .... |

DATAFILE 'name' | number

BACKUPSET ALL | number | time

CURRENT CONTROLFILE} (choose one)

[ PLUS ARCHIVELOG [DELETE INPUT] ]

STEP 7 - Test Restore process of your backup (optional) This will do everything except actually restore the database. This is the best method to

determine if your backup is good and usable before being in a situation where it is

critical and issues exist.

The following commands can be run any time to check if RMAN is capable of

restoring database/tablespace using existing backups.

# Check if database can be restored

RMAN> restore database validate;

or a Full Validation: run

{


restore archivelog from time 'sysdate-1' validate;

restore controlfile validate;

restore spfile validate;

}

# Check if tablespace is restorable

RMAN> restore validate tablespace read_only_tablespace_name ;

# Check if controlfile can be restored

RMAN> restore controlfile validate ;

#check if archivelogs for the past two weeks can be restored

RMAN> restore archivelog from time 'sysdate-14' validate;

Some Points to Remember: - RMAN doesn't automatically delete obsolete files, you need to specify the DELETE

OBSOLETE command, but if you are using FRA you don't need to specify the

OBSOLETE command. - The catalog is usefull ONLY to save some scripts, except for that, all the RMAN

features work equally well with or without a catalog. The repository is ALWAYS on

the controlfile of the TARGET DB.

- A whole backup is a backup of all database files and current control file, perform

this one using the BACKUP DATABASE command.

- You can specify SQL commands on RMAN like:

rman> alter system archive log current; #switch log files

Other RMAN Commands #Backup Some tablespaces only:

rman> backup tablespace users, tools;

rman> backup tablespace SYSTEM format

'/u01/oracle/db/AKI1/bck/ora_df%t_s%s_s%p';

#Backup a datafile:

rman>backup datafile copy '/tmp/system01.dbf';

#Also backup the Archve log Files:

rman>backup ....... plus archivelog;

#Backup all the archive log Files:

rman> backup archivelog all;

#Backup all the archive log Files and delete them from their location:

rman> backup archivelog all delete all input;

#Backup current control file to specific place:

rman> backup current controlfile to '/.../....' reuse;

Step 7 (optional) - You can create a Unix Script That will call the saved script in RMAN

We want to run it every Sunday night as a scheduled job. Let's run it as a cron job.

Create a Korn shell script called "rman_backup.ksh". This shell script will run the

RMAN script, prod_full_backup.rcv.

#!/bin/ksh

# Shell script to run RMAN script prod_full_backup.rcv

# Logging messages to prod_full_backup.log

# Set environment variables

export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

export ORACLE_SID=PROD

export ORACLE_HOME=/usr/local/OraHome1

# Connect to RMAN and run the backup script (all in one line)

rman target / rcvcat rman/rman@rman cmdfile

/home/oracle/script/rman_prod_full_backup.rcv msglog

/home/oracle/script/rman_full_backup.log

exit

Change permissions on the shell script appropriately.

chmod 755 rman_backup.ksh

Now, create the RMAN script file, prod_full_backup.rcv. This just runs the previously

stored catalog script, prod_full_backup. Here are the contents of prod_full_backup.rcv

run {execute script prod_full_backup;}

Finally, schedule the shell script using the crontab.

[prod-server:oracle] $ crontab -e

00 21 * * 0 /home/oracle/script/rman_backup.ksh

We have scheduled our script to run every Sunday night at 9:00 PM.

Simplest Backup Command

The following is one example of RMAN doing an online database backup. In this

example, the backup sets are written to disk.

run {




#backup the whole db

backup tag 'whole_database_open' format

'/oracle/backups/BFS/backup_%d_set%s_piece%p_%T_%U'

database;

# switch out of the current logfile

alter system archive log current;

#backup the archived logs

crosscheck archivelog all;

backup archivelog all format

'/oracle/backups/BFS/arch_logs_%u';

# backup a copy of the controlfile that contains records

for the other backups just made

backup current controlfile tag = "Control_File" format

'/oracle/backups/BFS/ControlFile_%u' reuse;

CROSSCHECK BACKUP;

DELETE NOPROMPT OBSOLETE;

DELETE NOPROMPT EXPIRED BACKUP;

RELEASE CHANNEL t1;

RELEASE CHANNEL t2;

RELEASE CHANNEL t3;

}

Understanding the Backup Process Now that RMAN is configured, backing up the database (including backing up all

archive redo logs), is as easy as:

RMAN Statements to Perform Full (online) Database Backup

% rman target system/manager@PROD nocatalog msglog

rman_full_backup_db_online_ORA920.log

RMAN> backup database plus archivelog delete input;

RMAN> delete noprompt force obsolete;

RMAN> exit

The following table includes all resulting backup sets contained in the control file

after performing the above backup routine.

B

S

K

Backu

p

Type

De

vic

e

Cont

rolfil

e

SPF

ILE

Incl

Pie

ce

Nu

Handle (Piece) Name Start

Time End

Time

Ela

pse

d

Tag Bl

oc

k

e

y Ty

pe Incl

uded

?

ude

d? mb

er Sec

on

ds

Si

ze

2 Datafil

e Full DI

SK 1

/orabackup/rman/ORA920/backu

p_db_ORA920_S_5_P_1_T_543

443342

11/28/0

4

20:29:0

2

11/28/0

4

20:32:4

4

222 TAG2004

1128T202

902

8,

19

2

2 /orabackup/rman/ORA920/backu

p_db_ORA920_S_5_P_2_T_543

443342

11/28/0

4

20:32:4

7

11/28/0

4

20:34:4

5

118 TAG2004

1128T202

902

8,

19

2

3 Archiv

ed

Logs

DI

SK 1

/orabackup/rman/ORA920/backu

p_db_ORA920_S_6_P_1_T_543

443693

11/28/0

4

20:34:5

3

11/28/0

4

20:34:5

3

0 TAG2004

1128T203

452

51

2

4 Datafil

e Full DI

SK YES YES 1

/orabackup/rman/ORA920/c-

2542143170-20041128-01

11/28/0

4

20:34:5

4

11/28/0

4

20:34:5

5

1 8,

Now, let's talk see actual steps that were performed by RMAN after running the full

(online) database backup statements. I attempted to annotate the RMAN log file

(below) with the following steps. Note that the first 6 steps were all part of the backup

database plus archivelog delete input; statement. The 7th step includes the delete

noprompt force obsolete; statement

1. The first action performed by RMAN is a log switch (using the alter system srchivelog current command).

2. Next, all existing archived redo logs (including the one just archived) are backed up to a Archive Log backup set. Note that at the end of the RMAN

statements in our example, this archive log backup set

(backup_db_ORA920_S_4_P_1_T_543443326) will be removed as it will no longer

be needed once the database files are backed up.

3. RMAN then starts the backup of the actual database files. For this backup set, (BS Key - 2), RMAN creates two backup

pieces: backup_db_ORA920_S_5_P_1_T_543443342 and backup_db_ORA920_S_5_P_2

_T_543443342.

4. After the full database backup, RMAN performs another archive redo log switch (using the alter system archivelog current command).

5. After the archive redo log switch completes, RMAN creates an Archived Log backup set (BS Key - 3) of the remaining archived redo logs (using

the backup archivelog all command). This is backup

piece backup_db_ORA920_S_6_P_1_T_543443693. Keep in mind that this archived

redo log backup set includes the redo logs that occured during the full database

backup.

6. Finally, the autobackup of the control file and SPFILE occurs and creates another datafile backup set (BS Key - 4). This is contained in backup piece c-

2542143170-20041128-01. Since a full database backup will always include

datafile 1, which belongs to the SYSTEM tablespace, there will always be a

backup of the control file and the SPFILE. At this point, all tasks for the backup

database plus archivelog delete input; statement have been completed.

7. The delete noprompt force obsolete; statement is then run to apply the retention policy we have configured. In our example, the first Archive

Log backup set (that was performed at the begining on this example) will be

removed. This was piece backup_db_ORA920_S_4_P_1_T_543443326.

RMAN Full (online) Database Backup Log File

Recovery Manager: Release 9.2.0.5.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: ORA920 (DBID=2542143170)

using target database controlfile instead of recovery catalog

RMAN>

Starting backup at 28-NOV-04

current log archived (Step 1)

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=16 devtype=DISK

channel ORA_DISK_1: starting archive log backupset (Step 2)

channel ORA_DISK_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=89 recid=1 stamp=543441301





channel ORA_DISK_1: starting piece 1 at 28-NOV-04

channel ORA_DISK_1: finished piece 1 at 28-NOV-04

piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15

channel ORA_DISK_1: deleting archive log(s)

archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s89.dbf

recid=1 stamp=543441301









Finished backup at 28-NOV-04


using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset (Step 3)

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00001 name=/u06/app/oradata/ORA920/system01.dbf

input datafile fno=00010 name=/u06/app/oradata/ORA920/users01.dbf

input datafile fno=00002 name=/u06/app/oradata/ORA920/undotbs01.dbf

input datafile fno=00011 name=/u06/app/oradata/ORA920/perfstat01.dbf

input datafile fno=00007 name=/u06/app/oradata/ORA920/example01.dbf

input datafile fno=00003 name=/u06/app/oradata/ORA920/cwmlite01.dbf

input datafile fno=00004 name=/u06/app/oradata/ORA920/drsys01.dbf

input datafile fno=00005 name=/u06/app/oradata/ORA920/odm01.dbf

input datafile fno=00006 name=/u06/app/oradata/ORA920/xdb01.dbf

input datafile fno=00008 name=/u06/app/oradata/ORA920/indx01.dbf

input datafile fno=00009 name=/u06/app/oradata/ORA920/tools01.dbf

input datafile fno=00012 name=/u06/app/oradata/ORA920/users02.dbf




comment=NONE




comment=NONE




current log archived (Step 4)


channel ORA_DISK_1: starting archive log backupset (Step 5)

channel ORA_DISK_1: specifying archive log(s) in backup set





comment=NONE


channel ORA_DISK_1: deleting archive log(s)




Starting Control File and SPFILE Autobackup at 28-NOV-04 (Step 6)

piece handle=/orabackup/rman/ORA920/c-2542143170-20041128-01 comment=NONE

Finished Control File and SPFILE Autobackup at 28-NOV-04

RMAN>

RMAN retention policy will be applied to the command (Step 7)

RMAN retention policy is set to redundancy 2


Deleting the following obsolete backups and copies:

Type Key Completion Time Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set 1 28-NOV-04

Backup Piece 1 28-NOV-04

/orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326

deleted backup piece

backup piece

handle=/orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326 recid=1

stamp=543443326

Deleted 1 objects

RMAN>

Recovery Manager complete.

Delete specified archivelogs and backups As part of the regular backup file log maintenance, the recovery window and

redundancy commands are usually used within backup scripts to define how long the

backups would stay on disk or on tape. For archive log retention, the delete archivelog

command is utilized.

DELETE Archive logs To clean-up older archives the “backup archive log delete input” is very commonly

used to manage the archive log retention on disk. This however has a very serious

drawback because as soon as the backup is finished all the archive logs are purged. In

this scenario if recovery is required then the backup of the archive from tape has to be

restored and then they can be applied. This increases the downtime due to the slower

recovery rate from tape. Also for environments that extract data from archive logs,

immediate purging of these log files could interfere with processes like Golden Gate

and Streams, in case these processes are down for some reason and the backup job

fires, it will remove the archive logs that will be required on the process start-up.

Thus to retain these archive logs for a longer time the following can used in the

backup script to manage the archive logs on disk

DELETE archivelog ALL COMPLETED BEFORE ‘sysdate-1’;

DELETE archivelog ALL BACKED UP 2 TIMES to disk;

DELETE NOPROMPT archivelog UNTIL SEQUENCE = 3790;

Delete Archive log Backups The following command can be used to manage the backup of the archive log when

storage space needs to be released.

DELETE BACKUP OF archivelog UNTIL TIME='sysdate-5';

Obsolete database backups Backups that fall outside the specified recovery window can be purged uisng the

obsolete command

DELETE OBSOLETE RECOVERY WINDOW OF 4 DAYS;

Special Considerations for

RAC - Check that your DB is in archive log mode

- Set up Flash Recovery to save the archive log files and backuped files to an NFS

mounted drive or to the cluster file system (much better). The directory for Archive

Log Files MUST exist in all the nodes.

- Setup the snapshot control file Location. The snapshot control file is a temporary

snapshot control file that RMAN creates to re-synchronize from a read-consistent

version of the control file. RMAN only needs a snapshot control file when re-

synchronizing with the recovery catalog or when making a backup of the current

control file.

In RAC, the snapshot control file is only needed on the nodes on which RMAN

performs backups; the snapshot control file does not need to be globally available to

all instances in a RAC environment.

You can specify a cluster file system file or a raw device destination for the location

of your snapshot control file.

- Verify connectivity to all the boxes

- Connect to RMAN to verify and set the controlfile persistent configuration. The

controlfiles are shared between the instances. Also note the target DBID at

connection. Perform the following parameter modifications:

rman> show all;


CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #

default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default




CONFIGURE SNAPSHOT CONTROLFILE NAME TO

'/u01/app/oracle/product/9.2.0/dbs/snapcf_ORA920.f'; # default

configure rete

recovery manager (rman) updated for rac · 2018. 3. 18. · recovery manager (rman) updated for rac...

Documents