Anda di halaman 1dari 15

Privilege for RMAN: SYSDBA

Command: Backup as copy database:- It copies the files as image copies, bit-for-bit copies of database
files created on disk like OS created copy. It will be recorded in the RMAN repository and RMAN can use
them in restore operations. Image copies cannot be created on tape.

Command: Backup as Backupset:-,RMAN stores its backups in backup sets. A backup set,
consisting of one or more backup pieces, contains the physical file data being backed up. Only RMAN
can access and restore backupset.
Backing Up Individual Files


RMAN> BACKUP ARCHIVELOG from time 'sysdate-2';


RMAN> BACKUP TABLESPACE system, users, tools;







DELETE INPUT vs DELETE ALL INPUT: With DELETE INPUT, RMAN only deletes the specific copy of
the archived redo log that has been backed up. With DELETE ALL INPUT, RMAN will delete each
backed-up archived redo log file from all log archiving destinations.
Reporting on RMAN Operations
The RMAN LIST and REPORT commands generate reports on backup activities based on the RMAN
List: Use LIST to display information about backup sets, proxy copies, and image copies recorded in the
repository. The LIST command displays the files against which you can run CROSSCHECK and DELETE
List backup;
List Copy;

Report: The REPORT command performs more complex analysis than LIST. Use the REPORT
command to answer questions such as the following:
• Which files need a backup?
• Which files have not had a backup for some time?
• Which files are not recoverable due to unrecoverable operations?
• Which backup files can be deleted?
• What was the physical schema of the database at a previous time
RMAN> REPORT SCHEMA; (RMAN displays the datafiles currently in the target database.)
RMAN does not automatically delete backups rendered obsolete by the retention policy. Instead, RMAN
shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of
V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
Crosschecking and Deleting Backups
Crosscheck is needed when an archivelog file or backup is manually removed, or not deleted by
RMAN. This command ensures that information about backups in the recovery catalog or control file is
synchronized with corresponding data on disk or in the media management catalog.
And after that updates their repository records to EXPIRED (not available). Then, you can run DELETE
EXPIRED to remove the repository records.
If some backup pieces or copies were erroneously marked as EXPIRED and deleted then you can run the
CROSSCHECK BACKUP/COPY command to restore those files to AVAILABLE status.

Validating the Restore of a Backup

Check that you are able to restore the backups that you created without actually restoring them. Run the
RESTORE ... VALIDATE command as follows:


How Incremental Backups Work

During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it
to the checkpoint SCN of the parent incremental backup. If the SCN in the input data block is greater than
or equal to the checkpoint SCN of the parent, then RMAN copies the block.

Incremental Backup Strategy

When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0
whenever 50% or more of the data has changed.

Mechanics of Recovery: Incremental Backups and Redo Logs

RMAN does not need to apply incremental backups to a restored level 0 incremental backup: it can also
apply archived logs. Otherwise RMAN simply restores the datafiles that it needs from available backups
and copies, and then applies incremental backups to the datafiles if it can and if not applies logs.
How RMAN Searches for Archived Redo Logs During Recovery
If RMAN cannot find an incremental backup, then it looks in the repository for the names of archived redo
logs to use for recovery. Oracle records archived log details in the control file whenever one of the
following occurs:
· The archiver process archives a redo log
· RMAN restores an archived log
· The RMAN COPY command copies a log
· The RMAN CATALOG command catalogs a user-managed backup of an archived log

RMAN propagates archived log data into the recovery catalog during resynchronization. You can view the
log information through:
· The LIST command
· The V$ARCHIVED_LOG control file view
· The RC_ARCHIVED_LOG recovery catalog view

During recovery, RMAN looks for the needed logs using the filenames specified in the
V$ARCHIVED_LOG view. If the logs were created in multiple destinations or were generated by the
COPY, CATALOG, or RESTORE commands, then multiple, identical copies of each log sequence
number exist on disk.
If the RMAN repository indicates that no copies of a needed log sequence number exist on disk, then
RMAN looks in backups and restores archived redo logs as needed to perform the media recovery. By
default, RMAN restores the archived redo logs to the first local archiving destination specified in the
initialization parameter file. You can run the SET ARCHIVELOG DESTINATION command to specify a
different restore location. If you specify the DELETE ARCHIVELOG option on RECOVER, then RMAN
deletes the archived logs after restoring and applying them.
Incomplete Recovery
RMAN can perform either complete or incomplete recovery. You can specify a time, SCN, or log
sequence number as a limit for incomplete recovery with the SET UNTIL command or with an UNTIL
clause specified directory on the RESTORE and RECOVER commands. After performing incomplete
recovery, you must open the database with the RESETLOGS option.
About Block Media Recovery
You can also use the RMAN BLOCKRECOVER command to perform block media recovery. Block
media recovery recovers an individual corrupt datablock or set of datablocks within a datafile.
Benefits of Using the Recovery Catalog as the RMAN Repository
You can store metadata about multiple target databases in a single catalog. You can store RMAN scripts
in the recovery catalog.
RMAN does not back up the following:
• Online redo logs
• Transported tablespaces before they have been made read/write
• Client-side initialization parameter files or noncurrent server parameter files
----------------------------------------------------------------------------------------------------------------- ---
Disaster Recovery
A situation in which your database server has been destroyed and has taken all your database files
(control files, logs and data files) with it. Only the last full hot backup on tape is available. One can do
better if subsequent archive logs (after the last backup) are available.
Now the high-level steps involved in disaster recovery are:
• Build replacement server.
• Restore backup from tape.
• Install database software.
• Create Oracle service.
• Restore and recover database.
Step: Create Oracle service
An Oracle service must be exist before a database is created. The service is created using the oradim
utility, which must be run from the command line.
--create a new service with auto startup

C:\>oradim -new -sid ORCL -intpwd ORCL -startmode a

Unfortunately oradim does not give any feedback, but you can check that the service exists via the
Services administrative panel. The service has been configured to start automatically when the computer
is powered up.

Step: Restore and recover database

Now it is time to get down to the nuts and bolts of database recovery.
• Copy PASSWORD and TNSNAMES file from backup: The backed up password file and
tnsnames.ora files should be copied from the backup directory to the proper locations.
• Set ORACLE_SID environment variable. This can be set either in the registry (registry key:
HKLM\Software\Oracle\HOME<X>\ORACLE_SID) or from the system applet in the control panel.
• Invoke RMAN and set the DBID. No login credentials are required since we connect from an OS
account belonging to ORA_DBA. Note that RMAN accepts a connection to the database although
the database is yet to be recovered. RMAN doesn't as yet "know" which database we intend to
connect to. We therefore need to identify the (to be restored) database to RMAN. This is done
through the database identifier (DBID). The DBID can be figured out from the name of the
controlfile backup. Example: if you use the controlfile backup format, your controlfile backup
name will be something like "CTL_SP_BAK_C-1507972899-20050228-00". In this case the DBID
is 1507972899. Here's a transcript illustrating the process of setting the DBID:
RMAN> set dbid 1507972899
RMAN>connect target /

Restore spfile from backup:

RMAN> startup nomount

RMAN> restore spfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00';


The instance is now started up with the correct initialization parameters.

We are now in a position to determine the locations of control file and archive destination, as this
information sits in the spfile. This is done via SQL Plus as follows:

C:\>sqlplus /nolog

SQL>connect / as sysdba
SQL> show parameter control_file

SQL> show parameter log_archive_dest

The directories listed in the CONTROL_FILES and LOG_ARCHIVE_DEST_N parameters should be

created at this stage if they haven't been created earlier.

Restore control file from backup: The instance now "knows" where the control files should be restored,
as this is listed in the CONTROL_FILES initialization parameter.

RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00';

RMAN> shutdown
RMAN> exit
C:\>rman target /
RMAN>startup mount;

At this stage we can determine the locations of data files and redo logs if we don't know where they
should go. This is done from SQL Plus as follows:

C:\>sqlplus /nolog
SQL>connect / as sysdba
SQL>select name from v$datafile;
SQL>select member from v$logfile;

The directories shown in the output should be created manually if this hasn't been done earlier.

Restore all datafiles: This is easy. Simply issue a "restore database" command from RMAN, and it will
do all the rest for you:

RMAN> restore database;

Recover database: The final step is to recover the database that dependents on the available archived
(and online) redo logs. Since we have lost our database server and have no remote archive destination,
we can recover only up to the time of the backup. Further, since this is an incomplete recovery, we will
have to open the database with resetlogs. Here's a sample RMAN session illustrating this:

RMAN> recover database;

RMAN>alter database open resetlogs;

database opened


Note that RMAN automatically applies all available archive logs. It first applies the backed up log and then
searches for subsequent logs in the archive destination.
Restoring an RMAN Backup to Another Node
In certain circumstances, it may be desirable to restore a database from an RMAN backup onto a
machine other than the original host. For example, to recover data at a given point in time, or to duplicate
a production instance.

The example assumes:

The target database is on host A

The database is to be restored onto host B
The directory structure of host B is different to host A
The ORACLE_SID will not change for the restored database
A recovery catalog is being used.

The following steps are required:

Backup the target on host A

List the datafile locations on host A
Make the backup available to host B
Make a copy of the init.ora available to host B
Edit the init.ora to reflect directory structure changes
Configure SQL*Net connectivity from host to the recovery catalog and duplicated database
Set up a password file for the duplicated database
Startup nomount the duplicated database
RMAN restore the controlfile(s)
Mount the database
Restore and rename the datafiles
Recover and open the database
Media recovery not required in case of instance failure during hot backup
In normal instance failure situations, automatic crash recovery using the online redologs will be
automatically performed, with no intervention required.
If an instance crashes or is aborted while one of the tablespaces is in backup mode, the tablespace will
appear to need media recovery upon startup. Because hot backup mode artificially freezes the checkpoint
SCN in the datafile header, it will appear on startup after a crash to be a file restored from backup.
Consequently, Oracle will suggest that you apply archived redologs from the time that the tablespace was
placed in backup mode.
Introduction to Recovery
Using RMAN, you can recover datafiles with incremental backups, which are backups of a datafile that
contain only blocks that changed after a previous incremental backup.
After the necessary files are restored, media recovery must be initiated by the user. Media recovery
applies archived redo logs and online redo logs to recover the datafiles. Whenever a change is made to a
datafile, the change is first recorded in the online redo logs. Media recovery selectively applies the
changes recorded in the online and archived redo logs to the restored datafile to roll it forward.
To correct problems caused by logical data corruptions or user errors, you can use Oracle Flashback.
Oracle Flashback Database and Oracle Flashback Table let you quickly recover to a previous time.
Unlike media recovery, Oracle performs crash recovery and instance recovery automatically after an
instance failure. Crash and instance recovery recover a database to its transaction-consistent state just
before instance failure. By definition, crash recovery is the recovery of a database in a single-instance
configuration or an Oracle Real Application Clusters configuration in which all instances have crashed. In
contrast, instance recovery is the recovery of one failed instance by a live instance in an Oracle Real
Application Clusters configuration.
Overview of Media Recovery
The type of recovery that takes a backup and applies redo is called media recovery. Media recovery
updates a backup to either to the current or to a specified prior time. Typically, the term “media recovery”
refers to recovery of datafiles.
Complete Recovery
Complete recovery involves using redo data or incremental backups combined with a backup of a
database, tablespace, or datafile to update it to the most current point in time. It is called complete
because Oracle applies all of the redo changes contained in the archived and online logs to the backup.
Typically, you perform complete media recovery after a media failure damages datafiles or the control file.
You can perform complete recovery on a database, tablespace, or datafile. If you are performing
complete recovery on the whole database, then you must:
• Mount the database
• Ensure that all datafiles you want to recover are online
• Restore a backup of the whole database or the files you want to recover
• Apply online or archived redo logs, or a combination of the two
If you are performing complete recovery on a tablespace or datafile, then you must:
• Take the tablespace or datafile to be recovered offline if the database is open
• Restore a backup of the datafiles you want to recover
• Apply online or archived redo logs, or a combination of the two
Incomplete Recovery
Incomplete recovery, or point-in-time recovery, uses a backup to produce a noncurrent version of the
database. In other words, you do not apply all of the redo records generated after the most recent
backup. You usually perform incomplete recovery of the whole database in the following situations:
• Media failure destroys some or all of the online redo logs.
• A user error causes data loss, for example, a user inadvertently drops a table.
• You cannot perform complete recovery because an archived redo log is missing.
• You lose your current control file and must use a backup control file to open the database.
To perform incomplete media recovery, you must restore all datafiles from backups created prior to the
time to which you want to recover and then open the database with the RESETLOGS option when
recovery completes. The RESETLOGS operation creates a new incarnation of the database—in other
words, a database with a new stream of log sequence numbers starting with log sequence 1.
Note: Flashback Database is another way to perform incomplete recovery.
Tablespace Point-in-Time Recovery
The tablespace point-in-time recovery (TSPITR) feature lets you recover one or more tablespaces to a
point in time that is different from the rest of the database. TSPITR is most useful when you want to:
• Recover from drop or truncate table operation
• Recover a table that has become logically corrupted
• Recover from an incorrect batch job or other DML statement that has affected only a subset of
the database
• Recover one independent schema to a point different from the rest of a physical database (in
cases where there are multiple independent schemas in separate tablespaces of one physical
• Recover a tablespace on a very large database (VLDB) rather than restore the whole database
from a backup and perform a complete database roll-forward
TSPITR has the following limitations:
• You cannot use it on the SYSTEM tablespace, an UNDO tablespace, or any tablespace that
contains rollback segments.
• Tablespaces that contain interdependent data must be recovered together. For example, if two
tables are in separate tablespaces and have a foreign key relationship, then both tablespaces
must be recovered at the same time; you cannot recover just one of them.
Incomplete Media Recovery Options
Because you are not completely recovering the database to the most current time, you must tell Oracle
when to terminate recovery. You can perform the following types of media recovery.
Type of Recovery Function
Time-based recovery Recovers the data up to a specified point in time.
Cancel-based Recovers until you issue the CANCEL statement (not available when using
recovery Recovery Manager).
Change-based Recovers until the specified SCN.
Log sequence Recovers until the specified log sequence number (only available when using
recovery Recovery Manager).
Datafile Media Recovery
Datafile media recovery is used to recover from a lost or damaged current datafile or control file. It is also
used to recover changes that were lost when a tablespace went offline without the OFFLINE NORMAL
option. Media recovery has the following characteristics:
• Applies changes to restored backups of damaged datafiles.
• Can use archived logs as well as online logs.
• Does not detect media failure (that is, the need to restore a backup) automatically. After a backup
has been restored, however, detection of the need to recover it through media recovery is
RMAN Restore and Recovery
The basic RMAN recovery commands are RESTORE and RECOVER. Use RESTORE to restore datafiles
from backup sets or from image copies on disk, either to their current location or to a new location. You
can also restore backup sets containing archived redo logs, but this is usually unnecessary, because
RMAN automatically restores the archived logs that are needed for recovery and deletes them after the
recovery is finished. Use the RMAN RECOVER command to perform media recovery and apply archived
logs or incremental backups.
Recovery Using Oracle Flashback Technology
To correct problems caused by logical data corruptions or user errors, you can use Oracle Flashback.
Flashback Database and Flashback Table let you quickly recover to a previous time.
If an Oracle managed disk area, called a flash recovery area is configured, and if you have enabled the
Flashback functionality, then you can use the RMAN and SQL FLASHBACK DATABASE commands to
return the database to a prior time. Flashback Database is not true media recovery, because it does not
involve restoring physical files. However, Flashback is preferable to using the RESTORE and RECOVER
commands in some cases where restoring the whole database does not required.
To Flashback a database, Oracle uses past block images to back out changes to the database. Oracle
returns datafiles to the previous point-in-time, but not auxiliary files, such as initialization parameter files.
Overview of Oracle Flashback Table
Oracle Flashback Table lets you recover tables to a specified point in time with a single statement. You
can restore table data along with associated indexes, triggers, and constraints, while the database is
online, undoing changes to only the specified tables.
Flashback Table works like a self-service repair tool. Suppose a user accidentally deletes some important
rows from a table and wants to recover the deleted rows. You can restore the table to the time before the
deletion and see the missing rows in the table with the FLASHBACK TABLE statement.
You can revert the table and its contents to a certain wall clock time or user-specified system change
number (SCN). Use Flashback Table with Oracle Flashback Version query and Flashback Transaction
Query to find a time to which the table should be restored back to.
For Flashback Table to succeed, the system must retain enough undo information to satisfy the specified
SCN or timestamp, and the integrity constraints specified on the tables cannot be violated. Also, row
movement must be enabled. Oracle strongly recommends that you run your database in automatic undo
management mode.
Other Types of Oracle Recovery
This section contains the following topics:
• Overview of Redo Application
• Overview of Instance and Crash Recovery
Overview of Cache Recovery
The online redo log is a set of operating system files that record all changes made to any database block,
including data, index, and rollback segments, whether the changes are committed or uncommitted. All
changes to Oracle blocks are recorded in the online log.
The first step of recovery from an instance or disk failure is called cache recovery or rolling forward, and
involves reapplying all of the changes recorded in the redo log to the datafiles.
Rolling forward proceeds through as many redo log files as necessary to bring the database forward in
time. Rolling forward usually includes online redo log files (instance recovery or media recovery) and
could include archived redo log files (media recovery only).
After rolling forward, the data blocks contain all committed changes. They could also contain uncommitted
changes that were either saved to the datafiles before the failure, or were recorded in the redo log and
introduced during cache recovery.
Overview of Transaction Recovery
You can run Oracle in either manual undo management mode or automatic undo management mode. In
manual mode, you must create and manage rollback segments to record the before-image of changes to
the database. In automatic undo management mode, you create one or more undo tablespaces. These
undo tablespaces contain undo segments similar to traditional rollback segments.
After the roll forward, any changes that were not committed must be undone. Oracle applies undo blocks
to roll back uncommitted changes in data blocks that were either written before the failure or introduced
by redo application during cache recovery. This process is called rolling back or transaction recovery.
Oracle can roll back multiple transactions simultaneously as needed. All transactions systemwide that
were active at the time of failure are marked as terminated. Instead of waiting for SMON to roll back
terminated transactions, new transactions can recover blocking transactions themselves to get the row
locks they need.
Overview of Instance and Crash Recovery
Crash recovery is used to recover from a failure either when a single-instance database fails or all
instances of an Oracle Real Application Clusters database fail.
Instance recovery refers to the case where a surviving instance recovers a failed instance in an Oracle
Real Application Clusters database.
The goal of crash and instance recovery is to restore the data block changes located in the cache of the
terminated instance and to close the redo thread that was left open. Instance and crash recovery use only
online redo log files and current online datafiles.

Crash and instance recovery involve two distinct operations: rolling forward the current, online datafiles by
applying both committed and uncommitted transactions contained in online redo records, and then rolling
back changes made in uncommitted transactions to their original state.
The important point is that in both crash and instance recovery, Oracle applies the redo automatically: no
user intervention is required to supply redo logs.
Deciding Which Recovery Technique to Use
This section contains the following topics:
When to Use Media Recovery (Complete media recovery and Incomplete media recovery)
Complete media recovery is used when individual datafiles, tablespaces, or the entire database has been
damaged. This can happen due to hardware errors or user errors, such as accidentally deleting a file.
Use incomplete media recovery when individual datafiles, tablespaces, or the entire database has been
logically damaged. This can happen due to application error or user error, such as accidentally deleting a
table or tablespace. Incomplete media recovery is used only with the whole database, not with individual
datafiles or tablespaces. (If you do not want to do incomplete media recovery of the entire database, you
can do tablespace point-in-time recovery with individual tablespaces.)
Use block media recovery when a small number of blocks in one or more files have been physically
damaged. This usually happens due to hardware errors, such as a bad disk controller, or operating
system I/O errors. Block media recovery is used with individual data blocks, and the remainder of the
database remains online and available during the recovery.
When to Use Oracle Flashback
Flashback Database applies to the entire database. It requires configuration and resources, but it
provides a fast alternative to performing incomplete database recovery.
Flashback Table uses information of the undo tablespace to restore the table. For a primary database,
consider using Flashback Database rather than Flashback Table in the following situations:
• There is a logical data corruption, particularly undo corruption.
• A user error affected the whole database.
• A user error affected a table or a small set of tables, but using Flashback Table would fail
because of its DDL restrictions.
• Flashback Database works through all DDL operations, whereas Flashback Table does not. Also,
because Flashback Database moves the entire database back in time, constraints are not an
issue, whereas they are with Flashback Table. Flashback Table cannot be used on a standby
To do an out of place restore of the data, perform a CTAS (CREATE TABLE AS SELECT … AS OF …)
using the Flashback Query SQL “AS OF …” clause. For example, to create a copy of the table as of a
specific time:
FROM employees AS OF TIMESTAMP '2002-02-05 14:15:00'
For out of place creation of the table, you only get data back. Constraints, indexes, and so on are not
restored. This could take significantly more time and space than Flashback Table. However, Flashback
Table only restores rows in blocks that were modified after the specified time, making it more efficient.
When to Use Import/Export Utilities Recovery
Oracle import and export utilities work similarly to CTAS, but they restore constraints, indexes, and so on.
They effectively re-create the whole table if an export was performed earlier corresponding to the
Flashback time. Flashback Table is more performance efficient than import/export utilities, because it
restores only the subset of rows that got modified.
Flash Recovery Area
The flash recovery area is an Oracle-managed directory, file system, or Automatic Storage Management
disk group that provides a centralized disk location for backup and recovery files. Oracle creates archived
logs in the flash recovery area. RMAN can store its backups in the flash recovery area, and it uses it
when restoring files during media recovery. All files necessary to recover the database following a media
failure are part of flash recovery area.
Following is a list of recovery-related files in flash recovery area:
• Current control file
• Online logs
• Archived logs
• Flashback logs
• Control file autobackups
• Control file copies
• Datafile copies
• Backup pieces
Flash Recovery Area Disk Limit
Oracle lets you define a disk limit, which is the amount of space that Oracle can use in the flash recovery
area. A disk limit lets you use the remaining disk space for other purposes and not to dedicate a complete
disk for the flash recovery area.
The bigger the flash recovery area, the more useful it becomes. The recommended disk limit is the sum of
the database size, the size of incremental backups, and the size of all archive logs that have not been
copied to tape. If an ASM disk group of size 100 GB is used with normal redundancy for the flash
recovery area, then the flash recovery area disk limit must be set to 50 GB.
Tablespace Backups
A tablespace backup is a backup of the datafiles that constitute the tablespace. Tablespace backups,
whether online or offline, are valid only if the database is operating in ARCHIVELOG mode. The reason is
that redo is required to make the restored tablespace consistent with the other tablespaces in the
Datafile Backups
Datafile backups, which are not as common as tablespace backups, are valid in ARCHIVELOG
databases. The only time a datafile backup is valid for a database in NOARCHIVELOG mode is if:
• Every datafile in a tablespace is backed up. You cannot restore the database unless all datafiles
are backed up.
• The datafiles are read only or offline-normal.
RMAN and User-Managed Backups
There are two types of backups: image copies and backup sets. An image copy is an exact duplicate of a
datafile, control file, or archived log. You can create image copies of physical files with operating system
utilities or RMAN, and you can restore them as-is without performing additional processing by using either
operating system utilities or RMAN.
Unlike operating system copies, RMAN validates the blocks in the file and records the copy in the
A backup set is a backup in a proprietary format that consists of one or more physical files called backup
pieces. It differs from an image copy in that it can contain more than one database file, and it can also be
backed up using special processing, such as compression or incremental backup. You must use RMAN
to restore a backup set.
Control File Backups
You can make manual backups of the control file by using the following methods:
• The RMAN BACKUP CURRENT CONTROLFILE command makes a binary backup of the control
file, as either a backup set or an image copy.
• The SQL statement ALTER DATABASE BACKUP CONTROLFILE makes a binary backup of the
control file.
control file contents to a SQL script file. You can use the script to create a new control file. Trace
file backups have one major disadvantage: they contain no records of archived redo logs, and
RMAN backups and copies. For this reason, binary backups are preferable.
Archived Redo Log Backups
Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an
inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a
backup through the most recent log, every log generated between these two points must be available. In
other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then
you must halt recovery at log 172 and open the database with the RESETLOGS option.
Because archived redo logs are essential to recovery, you should back them up regularly. If possible,
then back them up regularly to tape.
You can make backups of archived logs by using the following methods:
• An operating system utility
What is RECOVERY Catalog? Why we need it? Complete command/steps of creating Recovery
Catalog? How will it know about the Primary Database? -What role/Privileges are given to user
when he is connected to Recovery Catalog?

To use RMAN, a recovery catalog is not necessary. Remember that RMAN will always use the control file
of the target database to store backup and recovery operations. To use a recovery catalog, you will first
need to create a recovery catalog database and create a schema for it. The catalog (database objects)
will be located in the default tablespace of the schema owner. Please note that the owner of the catalog
cannot be the SYS user.

The recovery catalog database should be created on a different host, on different disks, and in a different
database from the target databse you will be backing up. If you do not, the benefits of using a recovery
catalog are lost if you loose the database and need to restore.

Now, let's create the recovery catalog:

1. Start SQL*Plus and then connect with SYSDBA privileges to the database containing the recovery
% sqlplus "sys/change_on_install as sysdba"
2. Create a user and schema for the recovery catalog:

User created.
3. Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user with
privileges to maintain and query the recovery catalog:


Grant succeeded.
4. After creating the catalog owner you should now create the catalog itself by using the CREATE
CATALOG command within the RMAN interface. This command will create the catalog in the default
tablespace of the catalog owner.
5. you will need to connect to the database that will contain the catalog as the catalog owner as follows:
% rman catalog rman HYPERLINK "mailto:rman/rman@catdb"/ HYPERLINK

Now, run the CREATE CATALOG command to create the catalog. Note that this process can take
several minutes to complete.
RMAN> create catalog;
Recovery catalog created

Registering the Target Database

Before using RMAN using a recovery catalog, you will need to register the taget database(s) in the
recovery catalog. As long as each target database has a distinct DBID, you can register more than one
target database in the same recovery catalog. We will be using the command-line utilities. I will be
registering a database named TARGDB to a recovery catalog within a database named CATDB. The
target database must be either mounted or opened in order to register it.

% . oraenv
% rman target backup_admin/backup_admin catalog rman HYPERLINK "mailto:rman/rman@catdb"/
HYPERLINK "mailto:rman/rman@catdb"rman@catdb
connected to target database: TARGDB (DBID=2457750772)
connected to recovery catalog database

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete



- Recovery window: Time to the point of recoverability. In above example, the command ensures that for
each data file, one back up that is older than the point of recoverability (7 days) must be retained.


- Redundancy value indicates that any number of backups or copies beyond a specified number need not
be retained. The default is 1 day.


- We can create up to 4 copies (in above example 2) of each back up piece in a backup set for all backup
commands that use automatic channels. This applies only for datafiles and archived redo log files.


- With this setting on, the BACKUP command does not backup files to a device type if the identical file
has already been backed up to the device type. Default value is off.

THE SHOW COMMAND :- This command displays persistent configuration settings.




- LIST command is used to produce a detailed report listing all information for the following.




RMAN >LIST BACKUP OF DATAFILE ”/db1/oradata/u03/users1.dbf”;




- This command helps to analyze information in the RMAN repository in more detail.








- This command is used to identify all data files that need a backup. There are three options with this

INCREMENTAL: An integer specifies the maximum number of incremental backups that should be
restored during recovery. If this number or more is required then the data file needs a new full backup.

RMAN >REPORT NEED BACKUP incremental 3 database;

This example will report files needing three or more incremental backups for recovery.

DAYS: An integer specifies max. number of days since the last full or incremental backup of file. The file
needs a backup if the most recent backup is equal to or greater than this number.
RMAN >REPORT NEED BACKUP days 3 tablespace system;
To report what system files have not been backed up for three days, use above command.

REDUNDANCY: An integer specifies the min. level of redundancy considered necessary. For example,
redundancy level two requires a backup if there are not two or more backups.

Datafiles and Data Blocks

An Oracle database consists of one or more logical storage units called tablespaces. Each tablespace in
an Oracle database consists of one or more files called datafiles. The simplest Oracle database would
have one tablespace, stored in one datafile.
The database manages the storage space in the datafiles of a database in units called data blocks. Data
blocks are the smallest units of storage that the database can use or allocate.
Modified or new data is not written to datafiles immediately. Updates are buffered in memory and written
to datafiles at intervals. If a database has not gone through a normal shutdown then there are typically
changes in memory that have not been written to the datafiles.
Redo Logs
Redo logs record all changes made to a database's data files. Each time data is changed in the database,
that change is recorded in the online redo log first, before it is applied to the datafiles.
An Oracle database requires at least two online redo log groups, and in each group there is at least one
online redo log member, an individual redo log file where the changes are recorded.
At intervals, the database rotates through the online redo log groups, storing changes in the current
online redo log .
Because the redo log contains a record of all changes to the datafiles, if a backup copy of a datafile from
some point in time and a complete set of redo logs from that time forward are available, the database can
reapply changes recorded in the redo logs, in order to re-construct the datafile contents at any point
between the backup time and the end of the last redo log. However, this is only possible if the redo log
has been preserved. The first level of preserving the redo log is through a process called archiving. The
database can copy online redo log groups that are not currently in use to one or more archive locations
on disk, where they are collectively called the archived redo log.
Undo Segments
In general, when data in a datafile is updated, "before images" of that data are written into undo
segments. If a transaction is rolled back, this undo information can be used to restore the original datafile
In the context of recovery, the undo information is used to undo the effects of uncommitted transactions,
once all the datafile changes from the redo logs have been applied to the datafiles. The database is
actually opened before the undo is applied.
Time Based Recovery (INCOMPLETE RECOVERY). ----------Doubtful Answer
Suppose a user has a dropped a crucial table accidentally and you have to recover the dropped table.
You have taken a full backup of the database on Monday 13-Aug-2007 and the table was created on
Tuesday 14-Aug-2007 and thousands of rows were inserted into it. Some user accidently drop the table
on Thursday 16-Aug-2007 and nobody notice this until Saturday.
Now to recover the table follow these steps.
STEP 1. Shutdown the database and take a full offline backup.
STEP 2. Restore all the datafiles, logfiles and control file from the full offline backup which was taken on
STEP 3. Start SQLPLUS and start and mount the database.
STEP 4. Then give the following command to recover database until specified time.
SQL> recover database until time ‘2007:08:16:13:55:00′
using backup controlfile;
STEP 5. Open the database and reset the logs. Because you have performed a Incomplete Recovery,
like this
SQL> alter database open resetlogs;
STEP 6. After database is open. Export the table to a dump file using Export Utility.
STEP 7. Restore from the full database backup which you have taken on Saturday.
STEP 8. Open the database and Import the table.
Note: In Oracle 10g you can easily recover drop tables by using Flashback feature. For further
information please refer to Flashback Features Topic in this book.