RMAN
RMAN
RMAN
• Planning
• RMAN Basics
• Advanced RMAN Features
• RMAN Strategies
• RMAN Best Practices
• 11gR2 RMAN New Features
• Q&A
Lets start at the beginning…
Planning
Planning for Data Protection
• Identify critical data
• Design data recovery requirements
– Recovery Time Objective (RTO)
• AKA – Outage
• Downtime (identify – plan – recover)
• Granularity (database, tablespace, datafile, etc.)
– Recovery Point Objective (RPO)
• AKA – Data loss
• Frequency (weekly, daily, ½ day, etc.)
• PiTR (Point-In-Time Recovery)
– Retention
• Time (7 years, 2 week, etc.)
• Location (Onsite or offsite)
– Cost
• Affected by RTO, RPO, and retention
• Data protection requirements
– Physical: disaster, corruption, failure, etc..
– Logical: application errors, user errors, etc.
Selecting the Right Tool
Feature RMAN User-Managed Data Pump Export
Closed database backups Supported. Requires instance to be mounted. Supported. Not supported.
Open database backups Supported. No need to use BEGIN/END BACKUP Supported. Must use Requires rollback or undo
statements. BEGIN/END segments to generate consistent
BACKUP statements. backups.
Incremental backups Supported. Not supported. Not supported.
Corrupt block detection Supported. Identifies corrupt blocks and logs in Not supported. Supported. Identifies corrupt
V$DATABASE_BLOCK_CORRUPTION. blocks in the export log.
Automatic specification of Supported. Establishes the name and locations of all Not supported. Files Not applicable.
files to include in a backup files to be backed up (whole database, tablespaces, to be backed up must
datafiles, control files, and so on). be located and copied
manually.
Backup repository Supported. Backups are recorded in the control file, Not supported. DBA Not supported.
which is the main repository of RMAN metadata. must keep own
Additionally, you can store this metadata in a recovery records of backups.
catalog, which is a schema in a different database.
Backups to a media Supported. Interfaces with a media manager. RMAN Supported. Backup to Not supported.
manager also supports proxy copy, a feature that allows a tape is manual or
media manager to manage completely the transfer of controlled by a media
data between disk and backup media. manager.
Backup of initialization Supported. Supported. Not supported.
parameter file
Backup of password and Not supported. Supported. Not supported.
networking files
Platform-independent Supported. Not supported. Supported.
language for backups
For this presentation, we selected…
RMAN Basics
The basics of RMAN
• What is RMAN?
– Recovery MANager is an Oracle Database client that performs backup and
recovery tasks on your databases and automates administration of your
backup strategies. It greatly simplifies backing up, restoring, and recovering
database files.
• RMAN Purposes:
– Data protection – physical backups of your database
– Data preservation – a copy for year end accounting
– Data transfer – move a database from one platform to another
• RMAN Benefits:
– Incremental backups
– Block validation
– Compression
– Encryption
– Duplication
– Cross-platform data conversion
The basics of RMAN
• RMAN components:
– Target database - the Oracle database which the backup or recovery
operations are being performed.
– RMAN client – executable that interprets commands, directs server sessions
to execute those commands, and records its activity in the target database
control file (or catalog).
– Fast Recovery Area (Optional) – a disk location that you can use to store
recovery-related files such as control file and online redo log copies, archived
redo log files, flashback logs, and RMAN backups.
– Media manager (Optional) - an application required for RMAN to interface
with sequential media devices such as tape libraries. A media manager
controls these devices during backup and recovery, managing the loading,
labeling, and unloading of media.
– Recovery catalog (Optional) - A separate database schema used to record
RMAN activity against one or more target databases. A recovery catalog
preserves RMAN repository metadata if the control file is lost, making it much
easier to restore and recover following the loss of the control file.
Types of Backups
• Cold (off-line) backups
– Requires downtime
– Full database only
– No PiTR
• Hot (on-line) backups
– No required downtime
– Types: full, incremental, or archivelog
– Granularity: database, tablespace or datafile
– Granularity applies to recovery options as well as the capability to recover
corrupted blocks
– Any PiTR capable with the proper data protection plan
Incremental Backups
• Level 0
– A full backup that happens to be the parent of incremental backups whose
level is greater than 0
– If no level 0 backup is available and compatibility is >=10.0.0, RMAN copies all
blocks that have been changed since the file was created. Otherwise, RMAN
behaves as it did in previous releases, by generating a level 0 backup.
• Level 1
– Differential (default) - RMAN backs up all blocks that have changed since the
most recent incremental backup at level 1 (cumulative or differential) or level 0
– Cumulative - RMAN backs up all blocks used since the most recent level 0
incremental backup in either the current or parent incarnation
• Block Change Tracking
– Improves incremental backup performance by recording changed blocks in
each datafile in a block change tracking file.
– RMAN tracks changed blocks as redo is generated.
– Avoids the need to scan every block in the datafile.
– Only uses block change tracking when the incremental level is greater than 0
Differential
Cumulative
Basic Examples
• Connecting:
– $ rman target /
– $ rman
RMAN> connect target /
– $ rman target / log /backup/db.log append
– RMAN> exit
• Configuration:
– RMAN> show all;
– RMAN> configure retention policy to recovery window of 14
days;
• Cold Backup:
– RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> backup as copy;
RMAN> alter database open;
• Hot Backup:
– RMAN> backup database plus archivelog;
Everyone still with me?
RMAN Strategies
Recovery Objectives
• RTO
– BACKUP AS COPY and RECOVER COPY
– Extremely fast recovery times
– Relatively simple strategy
– Requires 2x of database size
• RPO
– Multi-level with archivelogs backups
– Compression is an option
– Somewhat complex strategy
– Slower recovery times
• RTO + RPO
– Hybrid using COPY, FLASHBACK, and ARCHIVELOG
– Best of breed
– Complex strategy
– Obviously cost is not an issue Physical via RMAN
Logical via FLASHBACK
RTO Example (Initial)
allocate channel for maintenance type disk;
crosscheck backupset;
crosscheck archivelog all;
run
{
allocate channel bc_1
type disk
maxpiecesize 32G
format='/backup/rman/testdb/%d_%U.bak';
...
allocate channel bc_12
type disk
maxpiecesize 32G
format='/backup/rman/testdb/%d_%U.bak';
backup
as copy
tag = Full
database;
backup current controlfile
tag = CtlFile;
release channel bc_1;
...
release channel bc_12;
delete noprompt obsolete redundancy = 2;
}
RTO Example (Subsequent)
allocate channel for maintenance type disk;
crosscheck backupset;
crosscheck archivelog all;
run
{
allocate channel bc_1
type disk
maxpiecesize 32G
format='/backup/rman/testdb/%d_%U.bak';
...
allocate channel bc_12
type disk
maxpiecesize 32G
format='/backup/rman/testdb/%d_%U.bak';
backup
incremental level 1
for recovery of copy
with tag level_1
database;
recover
copy of database
with tag level_1;
backup current controlfile
tag = CtlFile;
release channel bc_1;
...
release channel bc_12;
delete noprompt obsolete redundancy = 2;
}
RPO Example (Level 0)
allocate channel for maintenance type disk;
crosscheck backupset;
crosscheck archivelog all;
run
{
allocate channel bc_1
type disk
maxpiecesize 32G
format='/backup/rman/testdb/10_04_01/%d_%U.bak';
...
allocate channel bc_12
type disk
maxpiecesize 32G
format='/backup/rman/testdb/10_04_01/%d_%U.bak';
backup
as compressed backupset
incremental level 0
tag = Level_0
database
plus archivelog delete input;
backup current controlfile
tag = CtlFile;
release channel bc_1;
...
release channel bc_12;
delete noprompt obsolete redundancy = 2;
}
RPO Example (Level 1)
allocate channel for maintenance type disk;
crosscheck backupset;
crosscheck archivelog all;
run
{
allocate channel bc_1
type disk
maxpiecesize 32G
format='/backup/rman/testdb/10_04_01/%d_%U.bak';
...
allocate channel bc_12
type disk
maxpiecesize 32G
format='/backup/rman/testdb/10_04_01/%d_%U.bak';
backup
as compressed backupset
incremental level 1
tag = Level_1
database
plus archivelog delete input;
release channel bc_1;
...
release channel bc_12;
delete noprompt obsolete redundancy = 2;
}
Practices I follow… Sometimes.