26
RN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it Backup & Recovery with RMAN LCG 3D Workshop, Bologna June 12 th , 2007 Jacek Wojcieszuk LCG

BackupRecovery With RMAN

Embed Size (px)

DESCRIPTION

BackupRecovery With RMAN

Citation preview

Backup & Recovery with RMANBackup & Recovery with RMAN
LCG 3D Workshop, Bologna
Agenda
RMAN Architecture
Types of failures
Media Failure
Block Corruption
Human error
Database user or DBA
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Backup options in Oracle
Do not provide flexibility for point in time recovery (PiTR)
Hot (on-line) backups
Different scopes: full database, tablespace(s) or datafile(s)
Do not require database downtime
Can be used to recover full database, single/multiple tablespace(s)/datafile(s) or a corrupted block
Database can be recovered to any point in time within assumed backup retention period
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Backup options in Oracle (2)
Logical backups
Support for different backup granularity
Can be taken either with legacy Export/Import tools or with Data Pump (10g)
Standby systems (Data Guard)
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
How hot backups are possible?
SGA
RMAN architecture
Types of RMAN hot backups
Copy or backupset
Full database backup
Incremental backups (in 10g 2 levels available: 0 and 1)
Cumulative, differential
Can be used to update a copy of the database
Archivelog backups
Manual vs. RMAN backups
Supports incremental backup strategies
RMAN on-line backups are not so heavy for the system as manual on-line backups
RMAN can detect corrupted blocks
RMAN automatically track database structure changes
Provides easy, automated backup, restore and recovery operations
Keeps invenotory of taken backups
Can seamlessly work with third party media managers
Disadvantage: something new to learn
RMAN concepts and command syntax sometimes are not intuitive
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
On-tape backups with RMAN
RMAN allows to take on-disk backups out of the box
Flash recovery area, if configured, further simplifies such backups
On disk backups are interesting but usually not sufficient for a disaster recovery
On-disk backups can be manually sent to tapes
Recovery can be very troublesome
RMAN can seamlessly work with third party Media Managers
Media Manager Library (MML) is required
Different configuration tasks for different MMLs
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
On-tape backups with RMAN (2)
Many vendors of Media Management software provide MMLs
Most popular are:
Tivoli Storage Manager
RMAN Configuration
RMAN can be preconfigured
Configuration is stored in the control file and in the recovery catalog (if used)
Can facilitate backup automation
Device type
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
RMAN Configuration (2)
configure DEFAULT DEVICE TYPE TO 'sbt';
configure DEVICE TYPE 'sbt' PARALLELISM 2;
configure CHANNEL DEVICE TYPE ‘sbt’ parms='ENV=
(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)';
configure MAXSETSIZE TO 200 G;
configure archivelog backup copies for device type 'sbt' to 1;
configure controlfile autobackup on;
The SHOW ALL command lists all RMAN configuration settings
To clear a given settings append CLEAR at the end of the CONFIGURE command
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
RMAN backup strategies
RMAN allows many types of backups
It possible to build own backup strategy that suits given database best
There are also Oracle recommended backup strategies:
Incremental backup strategy: level 0 backups + level 1 backups (cumulative and/or differential) and archivelog backups inbetween.
Incrementally updated database copy: 1 backup as copy of the whole database + incremental backups used to update the copy + archived redo logs.
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Backup strategy used at Tier0
Both Oracle-recommended strategies implemented for all production systems
Incremental backup strategy:
Backups go to tapes
Weekly or biweekly level 0 backups (depending on the DB size)
A level 1 cumulative backup inbetween
Daily incremental level 1 differential backups
Archivelog backup every 30 minutes
Incrementally updated DB copy strategy:
daily incremental differential backups applied with 2 days of delay
Copies, incremental backups and archived redo logs stored in the Flash Recovery Area
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Backup operations at Tier0
Central RMAN catalog exported on regular basis
Examples of RMAN commands being used:
run {
database force format '%d_%T_%U_lvl0T'
plus archivelog format '%d_%T_%U_lvl0Tarch';
delete noprompt force archivelog all completed before „sysdate - 2";
}
database format '%d_%T_%U_lvl1D'
plus archivelog format '%d_%T_%U_lvl1Darch';
delete noprompt force archivelog all completed before ‘sysdate – 2’;
}
Backup operations at Tier0 (2)
run {
format '%d_%T_%U_arch';
}
run {
backup maxsetsize 2047G tag ' DB_Copy_tag' device type disk incremental level 1 for recover of copy with tag ‘DB_Copy_tag’ database;
recover device type disk copy of database with tag DB_Copy_tag until time ‘sysdate -2 ‘;
}
Complete database recovery
Needed when:
All datafiles are lost or the SYSTEM tablespace datafiles are lost
At least one member of each redo log group survived
Requires:
Datafile restore from a backup
Database recovery using incremental backups and/or archived redo logs and online redo logs
startup mount
restore database check readonly;
Database point-in-time recovery
All copies of the current control file are lost
Or all online redo log group members are lost
The most typical recovery in case of systems implementing SAME approach
If done after a disaster it has to be preceded by:
Hardware configuration
Re-creation or restore from non-RMAN backup of listener.ora, tnsnames.ora and other important configuration files
ASM instance and diskgroup configuration (if needed)
MML installation and configuration
run {
allocate channel c1 device type disk|sbt;
allocate channel c2 device type disk|sbt;
restore database check readonly;
restore spfile to ‘some_location’ from autobackup;
recover database;
restore controlfile from autobackup;
Tablespace point-in-time recovery
Can be done with few clicks in OEM
Requires
Point in time recovery of the whole database (an auxiliary instance is created)
Export/import of selected tablespaces schemas or objects
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Block media recovery
Can be done with an open database
Only the table(s) containing corrupted blocks are not available
Database corruptions can be discovered with RMAN backup validate database command
Corrupted blocks can be found in V$DATABASE_BLOCK_CORRUPTION
run {
blockrecover datafile 19 block 44;
}
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
Single/multiple datafile/tablespace recovery
SYSTEM tablespace is intact
Requires
The database can be open and available to users
run {
allocate channel c1 device type disk|sbt;
restore tablespace users;
recover tablespace users;
}
Demo
Hands on preparation
CERN - IT Department CH-1211 Genève 23 Switzerland www.cern.ch/it
More info
Oracle Database 10g RMAN Backup & Recovery (by Mathew Hart and Robert G. Freeman)
Oracle Documentation
Backup and Recovery Reference