To execute the backup script that we created within the previous lesson, issue the call to run the backup_acct procedure,
as shown within the RMAN run command:
RMAN> RUN {EXECUTE SCRIPT backup_acct;}
You may want to create a set of standard scripts for routine tasks. For example, you may have a set of scripts that allocate channels (allocate_1_disk, allocate_3_ tapes, and so on). You can call these scripts from within other scripts. Alternatively, you can write the RMAN commands to operating-system command files and invoke them either from within RMAN, byusing the @filename notation, or on the RMAN command line, by using the cmdfile= argument.
Managing Archive Logs
RMAN identifies when ARCH has finished writing to a log, which is available to the DBA. RMAN provides several features to assist you with backing up and keeping track of archive log files. You back up archived redo logs in much the same way you do datafiles. Use the RMAN backup command and specify criteria indicating the files to be backed up. Because RMAN works with the contents of the control files rather than the operating-system directory, it knows which log files are still being written by ARCH. The following script backs up all complete archived redo logs within the log_arch_dest directory. (Note that you can use RMAN and SQL statements within a single piece of code.)
RMAN> REPLACE SCRIPT ARCHLOG_ALL {
2> ALLOCATE CHANNEL T1 TYPE sbt_tape;
3> SQL "ALTER SYSTEM ARCHIVELOG CURRENT";
3> BACKUP ARCHIVELOG ALL FORMAT 'arch_%u';
4> RELEASE CHANNEL T1;
5> }
You can be more selective when deciding which logs to back up, and you can delete log files once they've been successfully backed up.
Selection criteria can include creation date/time, sequence number, or thread number.
The following example backs up, then deletes all logs generated more than 48 hours ago:
RMAN> REPLACE SCRIPT archlog_old {
2> ALLOCATE CHANNEL T1 TYPE sbt_tape;
3> BACKUP ARCHIVELOG
4> UNTIL TIME 'sysdate-2'
5> ALL FORMAT 'arch_%u'
6> DELETE INPUT;
7> RELEASE CHANNEL T1;
8> }
A complete Backup
You can base a full-database-backup strategy on the examples shown so far. If you created a script called backup_db
that included the code within the first database-backup example, the following code extract could perform full-database backups,
including backups of control files and archived redo logs. It also automates housekeeping for log_arch_dest.
If your database is particularly large, you may want to consider making incremental backups. Unlike incremental exports, which operate at a table level, RMAN incremental backups back up only changed blocks. This approach optimizes not only backup times but recovery operations as well, because RMAN intelligently decides what combination of full, incremental, and archive-log backups will produce the optimal recovery path.
RMAN uses the concept of multilevel incremental backups, with levels 0, 1, or 2. Level 0 is equivalent to a full backup. An incremental backup at a level greater than 0 copies only those blocks that have changed since a previous incremental backup at the same or lower level.
For example, Level 1 incremental backup backs up any blocks that have changed since the most recent backup at Level 0 or 1. Level 2 backup backs up only blocks that have changed since the last backup at any level. To execute an incremental backup, include the incremental keyword and a level number within the backup statement:
RMAN> RUN {
2> ALLOCATE CHANNEL T1 TYPE sbt_tape;
3> BACKUP
4> INCREMENTAL LEVEL 0
5> FORMAT 'full_inc1_%u'
6> DATABASE;
7> RELEASE CHANNEL T1;
8>
}
Creating scripts with RMAN
To use RMAN, you must first connect to it. This connection is necessary to:
Authenticate you as a valid user
Identify your target database, which is the database that you are backing up or restoring
Identify the database containing the recovery catalog (if you use a recovery catalog)
Using backup scripts can do the following:
Back up Control files
Back up Archive log files
Back up Tablespaces
Back up data files
Specify where to save the backup, disk or tape
Specify more than one channel, to parallelize the process, so the backup can be done more quickly
Important benefits of using RMAN
You can perform basic backup and recovery tasks using operating system utilities and standard SQL commands.
However, there are several drawbacks to using these so-called user-managed backup and recovery techniques.
For example, you cannot perform incremental backups using user-managed techniques. In general, user-managed backup and recovery techniques require you to manually keep track of your backup files, their status, and their availability. You must write your own SQL and operating system scripts to manage the backup and recovery operations. In addition, you must provide the necessary data files and archived log files during a database recovery operation. If the database is operating during your backups (online or hot backups), you must place the database files in the backup mode before performing the actual file backups.
Oracle explicitly states that you can use user-managed techniques to perform backup/recovery activities. Oracle actually states that both user-managed techniques and RMAN are alternative ways of performing backup and recovery tasks. However, Oracle strongly recommends using RMAN to make your backups and perform database recovery, because of the tool’s strengths and powerful features. Although you can perform a basic backup and recovery task with user-managed techniques without ever having to even start the RMAN interface, you should make RMAN your main backup and recovery tool for several reasons. Several important backup and recovery features are available to you only through RMAN.
Here is a brief description of the important benefits of using RMAN instead of user-managed backup and recovery techniques:
You can take advantage of the powerful Data Recovery Advisor feature, which enables you to easily diagnose and repair data failures and corruption
There are simpler backup and recovery commands.
It automatically manages the backup files without DBA intervention.
It automatically deletes unnecessary backup data files and archived redo log files from both disk and tape.
It provides you with detailed reporting of backup actions.
It provides considerable help in duplicating a database or creating a standby database
It lets you test whether you can recover your database, without actually restoring data.
It lets you verify that available backups are usable for recovery.
It lets you make incremental backups, which isn’t possible by any other means of backup.
It lets you perform database duplication without backups by using the network-enabled database duplication feature, also known as active duplication.
It automatically detects corrupt data blocks during backups, with the corruption-relevant information recorded in the V$DATABASE_BLOCK_CORRUPTION view.
When only a few data blocks are corrupted, you can recover at the data block level, instead of recovering an entire data file.
You can take advantage of the unused block compression feature, wherein RMAN skips unused data blocks during a backup.
Only RMAN provides the ability to perform encrypted backups.
You can use RMAN with a variety of third-party storage systems.
You can use a powerful yet easy-to-use scripting language, which lets you write custom backup and recovery scripts quickly.
We will detail the necessary steps for creating a backup script. But prior to that, you may find the link above helpful for understanding the benefits of using RMAN to write a backup script. The following series of images illustrates the details of writing a backup script by using the line mode of RMAN:
Through RMAN, you can specify where to place the backup files by using the format parameter.
RMAN creates several client connections, or channels, between the target database and the backup storage device.
RMAN scripts can be integrated with operating-system command scripts.
You can be more selective when deciding which archive logs to be backup, and you can delete log files once they are successfully backed up
The script starts with RUN statement, which specifies that the following script must be executed.
This is an example of a specific type of backup for the TEMP tablespace
The following section discusses how to create a script that performs a complete database backup.
Creating backup Scripts in Oracle
The code should look similar to what is listed below.
RMAN> RUN {
2> ALLOCATE CHANNEL C1 TYPE DISK;
3> BACKUP DATABASE FORMAT 'D:\BACKUPS\%u';
4> RELEASE CHANNEL C1;
5> }
Allocate RMAN Channel
To manually allocate a channel, which is a connection between RMAN and a database instance. Each connection initiates an Oracle server session on the target or auxiliary instance: this server session performs the work of backing up, restoring, or recovering backup sets and copies.
Manually allocated channels (allocated by using ALLOCATE) are mutually exclusive with automatically allocated channels (specified by using CONFIGURE).
Manually allocated channels apply only to the RUN job in which you issue the command. Automatic channels apply to any RMAN job in which you do not manually allocate channels. You can always override automatic channel configurations by manually allocating channels within a RUN command.