2.8. Working Examples Using RMAN

In the following sections, you will perform some common and practical examples that you may encounter in your daily routine. You will perform certain types of backups such as backing up the archived redo logs and using the image copy to back up an entire database.

You will also learn how to do certain tasks that are common in daily operations such as enabling ARCHIVELOG mode and scheduling a backup job in RMAN.

2.8.1. Enabling ARCHIVELOG Mode

Enabling ARCHIVELOG mode is a must-know process that is essential to managing an Oracle database. Enabling ARCHIVELOG mode is necessary for creating online backups and performing certain types of database recovery.

ARCHIVELOG mode allows backups to a point-in-time in the future and complete backups from media failure using online and offline backups. Without ARCHIVELOG mode enabled, the database cannot be rolled forward from the backup time of the database backup to the point of failure.

Let's see how to enable ARCHIVELOG mode:

  1. Set LOG_ARCHIVE_START to TRUE in the init.ora file or in Oracle 9i or greater SPFILE by using the ALTER SYSTEM SET command in SQL*Plus:

    LOG_ARCHIVE_START=TRUE

SQL> alter system set log_archive_start=true scope=spfile;

  2. The init.ora or SPFILE parameters are used to specify the location and name of the ARCHIVELOG files. The LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT are just examples:

    LOG_ARCHIVE_DEST=/d01/arch/ora101c
LOG_ARCHIVE_FORMAT= arch%s.arc

  3. The database needs to be restarted in NOMOUNT mode, and then ARCHIVELOG mode needs to be enabled.

    C:Documents and Settingsdstuns>sqlplus /nolog

SQL*Plus: Release 10.1.0.2.0 - Production on Mon Aug 2 22:33:01 2004

Copyright (c) 1982, 2004, Oracle. All rights reserved.

    SQL> connect / as sysdba
SQL> startup nomount
SQL> alter database archivelog;

  4. Next the database must be opened: SQL> alter database open;

At this point, the ARCHIVELOG mode is now enabled.

2.8.2. Using RMAN to Back Up Archived Redo Logs

Another important part of a complete database is including the archive logs. The archive logs are required to roll forward from online backups. The section describes an example of a complete database backup that includes the archive logs.

The first activity performed is backing up the database. Next, all redo logs that can be archived are flushed to archive logs in the file system. Next, the archive logs are backed up in the RMAN catalog by using the command BACKUP (ARCHIVELOG ALL), which backs up all available archive logs in the file system.

run {
    allocate channel c1 type disk;
    allocate channel c2 type disk;
    backup database;
    backup (archivelog all);
     }

2.8.3. Scheduling a Backup Job

An important function for routine jobs is to schedule backup jobs to be run on a regular basis. Many third-party media managers provide GUI tools that include scheduling tools which interact with the operating system's scheduling features. It is possible to use the basic scheduling capabilities of the operating system to execute an RMAN command file.

A typical backup command RUN block can be stored in a file such as DAILY_BACKUP.RCV. This file can then be put into a command-line sequence, which is called by CRON in Unix or AT in the Windows operating systems.

Let's look at what the command-line sequence would look like:

rman target sys/sys_password@target_db catalog

.rman_user/rman_password@rman_catalog_db@daily_backup.rcv

In this example, the RMAN utility is called with the target database SYS user and SYS password, followed by the target database SQL*Net service identifier, which in this case is called TARGET_DB. Next, the CATALOG code word is specified with the RMAN catalog owner—which in this case is RMAN_USER—and the password of RMAN_PASSWORD. Then, the SQL*Net service identifier for the catalog database is specified, which in this case is called RMAN_CATALOG_DB. Lastly, the script file daily_backup.rcv is called out.

Real World Scenario: How to Clean Up From Manually Deleting Archive Logs

Let's look at an event that can occur in everyday database operations. A database is being rolled out to production soon, and most of the development staff is focused on meeting the delivery schedule. The database is in ARCHIVELOG mode, but the daily rigors of backup and recovery have not been enforced in development as stringently as in a production environment. The file system with the archive logs fills up before a backup is performed. The developers are unable to use the database because no log activity can be generated, so work comes to a halt. Finally, someone hastily deletes some of the archive logs to free up space.

The DBA now gets around to backing up the database with RMAN, but errors are generated because not all the archive logs are available. The problem is that the RMAN repository or the RMAN catalog knows the required archive logs that are needed since the last backup. RMAN will not allow you to back up the database without the complete set of archive logs.

What you need to do is reset the RMAN catalog or RMAN repository information to look at the existing archive logs only. This can be performed with RMAN command CHANGE ARCHIVELOG ALL CROSSCHECK. This command tells RMAN to use the available archive logs only and disregard the deleted ones. This information becomes the new baseline for this database. So, all future backups will not search for these deleted archive logs.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset