Treat this document as a general introduction to RMAN, with no scary details.
One if the most important aspect of managing a database is backing it up. That means taking backup of your database to restore it in case of some disaster. Disaster may include incidents like someone dropping OR truncating one or all tables, deleting whole table data, the disk on which database resides getting damaged somehow, the system housing the database get damaged due to some reason or any other reason causing database unavailability.
In such scenarios, the database must be restored for business to continue. And you can restore it only if you have a backup of it taken sometime in the past. Database backup is just like a copy of database which can be used for restoring it. The term Database restore means copying the database files from the backup taken in the past.
Now think about this scenario, say you took backup of your database yesterday and it somehow got crashed today. So any transactions done between yesterday (from backup time) and today (when DB crashed) will not be available in the backup you took.
But for data consistency and for database to open correctly, those transactions must also be recovered somehow and this that is done by fetching those transactions (whether committed or uncommitted) from Redo logs. Those transactions are fetched from logs and applied on the database just restored from the backup taken earlier. This is called as database recovery.
The activities of backup, restore and recovery can be done via manual techniques (also called user managed backup & recovery) like copying database related files (like control files, data files, parameter file etc.) using copy/cp commands, restoring the files using copy/cp and then performing media recovery using RECOVER DATABASE command.
Click here for more info on various oracle database related files. Media recovery is different that automatic Oracle instance recovery.
RECOVER DATABASE command looks for archive log files in parameter location specified by "LOG_ARCHIVE_DEST_n" and uses redo logs to recover database.The user managed backup & recovery method has limitations, which are overcome by RMAN tool.
RMAN is Oracle's tool for database backup and recovery. The RMAN client is a command line utility included in the installation of the Oracle database, in the $ORACLE_HOME/bin directory, written in PRO*C. language that executes the PL/SQL API. This means that internally RMAN actually executes PL/SQL code for doing backup/recovery tasks.
The most important tasks we can perform with RMAN are:
- Taking database backup
- Performing database recovery
- Performing failure diagnostic (i.e. in case of DB restart failure, we can do troubleshooting easily using ADR (Automatic Diagnostic Repository) utility)
- Performing instance duplication (i.e. creating another DB instance like current)
- Checking backups history using commands like LIST, REPORT etc, which fetch backup data from control file or recovery catalog.
Benefits of RMAN
Here are the advantages of using RMAN over user managed method:
- You can perform incremental backups using RMAN. It means the size of the backups doesn't depend on database size; rather, it depends on the activity level within the database, because unchanged blocks are skipped during incremental backups, only changed ones are backed up.
- You can repair a datafile with a few corrupt data blocks online, without needing to resort to restoring a file from backup. This is called block media recovery.
- Human error is minimized because RMAN, not the individual DBA, keeps track of all the file-names and locations. Once you understand the use of the RMAN utility, it’s easy for you to take over the backup and recovery of databases from another DBA.
- A simple command, such as BACKUP DATABASE, can back up an entire database, without the need for complex scripts.
- The unused block compression feature of RMAN lets you skip copying never-used data blocks in a datafile during a backup, thus saving storage space and backup time.
- It’s easy to automate the backup and recovery process through RMAN. RMAN can also automatically parallelize the backup and recovery sessions.
- RMAN can perform error checking during backups and recovery, thus ensuring that the backed-up files aren’t corrupt.
- During online backups, no redo is generated, unlike when online backups are performed using the operating system utilities (or user managed technique). Thus, the overhead is low for online backups.
- The binary compression feature reduces the size of backups saved on disk.
- If you use the recovery catalog, you can store backup and recovery scripts directly in it.
- RMAN enables you to make image copies, which are similar to operating system-based backups of files.
- RMAN can be easily integrated with powerful third-party media management products to make tape backups effortless.
- You can easily clone databases and maintain standby databases using the RMAN functionality.
Here's how you can connect to RMAN. First make sure the ORACLE_HOME and ORACLE_SID are set.
If ORACLE_HOME is not set, use absolute path to invoke appropriate version of RMAN executable.
If ORACLE_SID is not set, use tnsnames method to connect to DB, e.g. Rman target sys/xxxx@orcl12c
In below example, I have set both ORACLE_HOME and ORACLE_SID, so the syntax is simple. Here connection is made using operating system authentication, without using a database user account and password.
SET oracle_home=C:\oracle\product\12.1.0\dbhome_1 SET oracle_sid=orcl12c C:\windows\system32>rman target / Recovery Manager: Release 12.1.0.1.0 - Production on Wed Nov 26 14:36:10 2014 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL12C (DBID=687186962) RMAN> list backup summary; using target database control file instead of recovery catalog List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 333 B F A DISK 31-OCT-14 1 1 YES 10_31_2014 336 B A A DISK 31-OCT-14 1 1 YES 10_31_2014 337 B F A DISK 31-OCT-14 1 1 NO TAG20141031T142139 338 B F A DISK 31-OCT-14 1 1 NO TAG20141031T142353 RMAN> catalog rcat/xxxx@new2 connected to recovery catalog database RMAN> exit Recovery Manager complete. C:\windows\system32>
In the last lines in above code, I connected to Recovery catalog within RMAN prompt.
You can connect to RMAN and catalog simultaneously using a one liner too. Example:
C:\windows\system32> Rman target sys/xxxx@orcl12c catalog rcat/xxxx@new2Recovery catalog schema: This is the database schema in the recovery catalog database that owns the RMAN backup and recovery metadata (the RMAN repository).
Without a recovery catalog, you can view RMAN meta info via V$ views (like V$BACKUP_FILES etc), with recovery catalog, you use RC_ views (like RC_BACKUP_FILES).
Having a recovery catalog gives following advantages over not having one:
- You can use RMAN-stored scripts only if you use the recovery catalog.
- If you use the control file, you run the risk of some of the historical data being overwritten, but the recovery catalog will safeguard all such data.
- Recovery catalog can store meta information for several databases, but control file stores info for only a single database. One recovery catalog in your system can perform backup, restore, and recovery activities for dozens of Oracle databases.
- There are some commands which run only when recovery catalog is present.
TOP