Chapter 24 – Using RMAN to Back Up Databases

Intro

• There are four interfaces for using RMAN:
  • DB Control / Enterprise Manager
  • Batch mode / cron
  • Pipe interface
  • RMAN executable

RMAN in Batch Mode

• run {
• allocate channel t1 type sbt_tape;
• …
• backup copy of database delete input;}

The RMAN Pipe Interface

• Uses the PL/SQL package DBMS_PIPE which allows one database session to communicate with another. It does this by creating a data structure called a pipe in the SGA. One session will queue messages in the Pipe while the other will pick up these messages for execution. Output will be redirected to the controlling session.
• To create PIPEs:
  • rman PIPE rmpipe target sys/pass@ocp10g
  • Two pipes will be created:
    • ORA$RMAN_RMPIPE_IN – user input
    • ORA$RMAN_RMPIPE_OUT – user output
  • dbms_pipe.pack & dbms_pipe.send_message will be used by the controlling process.
  • dbms_pipe.unpack & dbms_pipe.receive_message will be used to retrieve output.

Backing Up with the RMAN Executable

Stand-Alone and Job/Command Block Commands

• run {} braces are used for commands that only make sense when run with others
  • run {
  • allocate channel d1 type disk;
  • backup database;
  • }
• Stand alone commands:
  • Connect

  Creating Backup Sets

  • RMAN can back up objects in two ways:
    • Image copy – identical binary copy of file
    • Backupset – format that can only be manipulated by Oracle
      • Controlfile
      • Spfile
      • Datafiles
      • Archive logs
      • Image copies
      • Other backupsets
  • It is quicker to restore from image copies but image copies are bigger and can only be written to disk (not tape).
  • Backup sets can make incremental backups and are the only option when backing up to tape.
  • Backup database creates a backupset with the datafiles, controlfile and spfile.
  • BACKUP DATABASE PLUS ARCHIVELOG causes the following actions to occur:
    • ALTER SYSTEM ARCHIVE LOG CURRENT
    • BACKUP ARCHIVELOG ALL
    • BACKUP WHOLE DB
    • ALTER SYSTEM ARCHIVE LOG CURRENT
    • Backup archive logs generated in steps 3 and 4.
  • Script to backup all archive logs older than 7 days
    • run {
    • allocate channel t1 type sbt;
    • backup as backupset archivelog until time ’sysdate -7′;}
  • Offline backups must be conducted in MOUNT mode. They also will fail if the database crashed or was shutdown aborted.
  • If the archive logs are multiplexed then the following commands will behave differently:
    • RMAN> backup as backupset archivelog all DELETE INPUT;
      • This will delete only archivelog copies in primary destination.
    • RMAN> backup as backupset archivelog all DELETE ALL INPUT;
      • This will delete all multiplexed archivelog copies.

  Making Image Copies

  • Image copies are exact binary copies, equivalent to an OS copy and paste. They cannot be backed up to tape.
  • Image copies can be made of:
    • Datafiles
    • Controlfile
    • Archive logs
    • NOT the spfile
  • Restores from image copies are faster then backupsets because they do not have to be extracted / decompressed.
  • The entire db can be backed up as an image copy:
    • RMAN> backup as copy database;

  Using Tags for Backup Sets and Image Copies

  • A tag is an assigned name to a backupset or a set of image copies.
  • RMAN> backup [as backupset] database tag=weekly;
  • RMAN> delete backupset tag weekly;

  Incremental Backups

  • Incremental backups are very dependent on SCN. Whenever a backup is taken, it is marked in the repository as having been taken at a particular SCN.
  • To determine what needs to be backed up for incrementals, rman only has to compare the scn of the last backup with the current scn of the db to see if data has been added.
  • Incremental backups only apply to datafiles because they rely on SCN.
  • Reasons to use incrementals:
    • Time – incrementals run quicker than a full backup every night with block change tracking enabled
      • If block change tracking is not enabled, then incrementals are not faster during the read but are writing less data to disk which is often the slowest portion (so in that way, it’s faster).
        
    • Space – disk space and tape backup space can be a problem if a full backup occurs every night
    • Impact on end users – the I/O needed for a full backup and disk contention can impact end users
  • Incremental backup levels:
    • Level 0 – full backup that can be used for subsequent incrementals
      • RMAN> backup incremental level 0 database;
    • Differential Level 1 – only the blocks that have changed since the last backup (whether it is level 0 or level 1)
      • RMAN> backup incremental level 1 differential database;
    • Cumulative Level 1 – all changes since the last level 0 incremental backup
      • RMAN> backup incremental level 1 cumulative database;
  • A full backup cannot be used for a cumulative level 1 backup. A cumulative level 1 backup must be done on top of an incremental level 0 backup.

  Combining Incremental Backups and Image Copies

  • It is possible to apply incremental backups to image copies (but not backupsets).
  • One technique would be an image copy once a week and incrementals, nightly.
  • Image copy:
    • run { backup as copy incremental level 0 database tag db_img_copy;}
  • Make incremental, apply it to copy of database, delete incremental:
    • run {
    • backup incremental level 1 for recover of copy with tag db_img_copy database tag db_incr_copy;
    • recover copy of database with tag db_img_copy;
    • delete backupset tag db_incr_copy;}

  Block Change Tracking

  • Incrementals will scan the entire database being backed up in order to detect changes, unless block change tracking is enabled.
  • Block change tracking enables an additional background process called CTWR (Change Tracking WRiter). This process records the address of each block that has been changed so that incrementals will no longer have to scan entire datafiles to find changed blocks.
    • By default, the change tracking file will go to the DB_CREATE_FILE_DEST. It is initially 10M and grows by increments of 10M.
    • SQL> alter database enable block change tracking using file ‘/home/oracle/ctwr.out’;

  Managing and Monitoring RMAN Backups

  LIST

  • RMAN> list backup; // backup sets
  • RMAN> list copy; // image copies
  • RMAN> list backup of database; // whole database backup sets, full or incremental
  • RMAN> list backup of datafile 1;
  • RMAN> list backup of tablespace users;
  • RMAN> list backup of archivelog all;
  • RMAN> list copy of archivelog from time=’sysdate – 2′;
  • RMAN> list backup of archivelog from sequence 1000 until sequence 1050;

  REPORT

  • RMAN> report schema; // “schema” is confusing. this just shows datafiles and has nothing to do with user objects.
  • RMAN> report need backup;
  • RMAN> report need backup days 3;
  • RMAN> report need backup redundancy 3;
  • RMAN> report obsolete;
  • RMAN> report obsolete redundancy 2; // shows backups that are older than two others

  DELETE

  • RMAN> delete obsolete;
  • RMAN> delete obsolete redundancy 2; // delete backups that are older than two others

  Views & Tables

  • These views and data are contained in the control file only (not recovery catalog).
  • V$BLOCK_CHANGE_TRACKING – to monitor block change tracking
  • V$BACKUP_FILES
  • V$BACKUP_SET
  • V$BACKUP_PIECE
  • V$BACKUP_REDOLOG – each archived log that has been backed up
  • V$BACKUP_SPFILE – each spfile that has been backed up
  • V$BACKUP_DEVICE – names of sbt devices
  • V$RMAN_CONFIGURATION

  Parameters

  • DB_CREATE_FILE_DEST – default location for the change tracking file