ORACLE DATABASE

RMAN strategies for different types of databases

Agenda

• 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?

Advanced RMAN Features

Advanced RMAN Features
• Devices, Channels and Parallelism
– Multiple backup devices
• Tape or SBT
• Local disk or DISK
– Multiple channels
• Each channel is a writing head
• Can have different devices on each channel
– Parallelism
• Automatic channel allocation
• Duplicate
– Creates a duplicate database from backups
– Exclude tablespaces and rename the database
• Catalog
– NOCATALOG option (default)
• Uses the target database controlfile for storing recovery metadata
• Simple backup and recovery for a single database
– CATALOG option
• Centralized recovery metadata repository via a Recovery Catalog
• Simple to complex backup and recovery for multiple databases on multiple servers
Advanced RMAN Features
• BACKUP AS COPY and RECOVER COPY
– Incremental backup rolls forward recovery area backup
• No need to do full backups
• recover copy of database with tag ‘NIGHLY’;
– Easy instantaneous restore:
• switch datafile 4 to copy;
• recover datafile 4;

Database (s) Apply FRA

Nightly (backup Archive
Incremental destination) (OSB)
And now, lets pull this all together…

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.

RMAN Best Practices

RMAN Best Practices
• Turn on block checking
– To detect corrupt blocks as early as possible
– alter system set db_block_checking = true scope=both;
• Turn on block tracking
– To reduce the amount of time required for incremental backups
– alter database enable block change tracking;
• Duplex log groups and members
– Mitigate risk of lost or corruption of redo/archive logs
– alter system set
log_archive_dest_2='location=/loc/archive2' scope=both;
– alter database add logfile member
‘/loc/online/redo21.log' to group 1;
• Use check logical parameter
– Cause RMAN to check for logical corruption
– backup check logical database;
RMAN Best Practices
• Test your backup
– The lazy way, but “Your backup is only as good as your last restore”
– restore validate database;
• Datafile per backup piece
– Speed partial restores, as it does not need to read the entire piece
– backup database filesperset 1;
• Maintain your catalog/controlfile
– Control your control file size and retention policy
– alter system set control_file_record_keep_time=21
scope=both;
– delete obsolete;
– crosscheck backup;
– delete expired backup;
• Backup you controlfiles
– It is pretty tough to restore with a controlefile
– configure controlfile autobackup on;
– backup current controlfile;
RMAN Best Practices
• Test your recovery
– Can avoid multiple restore to get it right during an outage
– recover database test_db;
• Avoid delete all input
– delete input will backup from one location and delete what has been
backed up.
Almost done, but lets talk about what's next…

11gR2 RMAN New Features

New Features
• Automatic Block Repair
– Allows corrupt blocks on the primary database to be automatically repaired from
physical standby database, as they are detected.
– In-line and transparent. User sees brief wait from query on corrupt block while it is
being repaired.
– Requires Active Data Guard (real-time query on physical standby database).
– Can also be performed on-demand via RECOVER command
• Multiple Compression levels
– Levels & throughput
• [BASIC] | HIGH | MEDIUM | LOW
• HIGH – reduces backup size by 40%+ depending on data type
• LOW – least impact on backup throughput
• MEDIUM – best balance between compression and throughput
• HIGH | MEDIUM | LOW require Advanced Compression Option
– Popular way to save on storage costs
• Enhanced DUPLICATE
– Connection to source database not needed for environments where network
connection is not available
New Features
• Backup FRA to disk location
– Protect Fast Recovery Area with on-disk backup of its RMAN backups,
archived logs, and controlfiles
• Extended tablespace point-in-time recovery (TSPITR) capabilities
– Recover a dropped tablespace
– Perform multiple tablespace point-in-time recoveries, without requiring
recovery catalog
• Resumable DUPLICATE
– DUPLICATE can resume processing from most points of failure, reducing
overall time
• CONVERT DATABASE can skip unneeded datafiles
– Reduces overall conversion time by only processing the required UNDO-
containing data files
• SET NEWNAME FOR TABLESPACE | DATABASE
– Simplifies renaming of datafiles for RESTORE
Q&
A