www'SageLogix'Com

1
Ottawa Oracle Users Group
Is RMAN Really Worth the Trouble?Tim
GormanPrincipal Consultant - SageLogix, Inc.

• www.SageLogix.Com

2
Agenda

• RMAN architecture
• So whats the hassle?
• What makes it worthwhile?
• Standardized backup/recovery strategy
• Three features that only RMAN has
• Are these features important to you?
• If so, RMAN is worth the hassle. Just do it!
• If not, dont worry - be happy!

3
RMAN Architecture Basics

• Target database
• the database which is to be backed up, restored,
  or recovered
• Recovery catalog database
• the database containing the recovery catalog,
  which contains information facilitate RMAN
  operations
• all backup, restore, and recoveries
• database structure (replicated from targets
  control files)
• Recovery catalog is optional all of the basic
  and most important RMAN operations can be
  performed with only the information stored in the
  target databases control files
• recovery catalog database ! target database !!!!!

4
RMAN Architecture Basics
Backup media
true recovery catalog in
control files
online redo logfiles
Backup Manager (OEM)
MMV
Oracle server
MMV
Oracle server
data files
Oracle server
Oracle server
data files
RMAN
Recovery Catalog (replicated)
Target database
5
RMAN Architecture Basics
Backup media
true recovery catalog in
control files
online redo logfiles
Backup Manager (OEM)
MMV
Oracle server
MMV
Oracle server
data files
RMAN
Nocatalog mode
Target database
6
RMAN Architecture Basics

• Oracle server processes perform RMAN operations
• processes issue consistent-read requests to
  database and write data out to (or read data
  from) the RMAN application programming interface
  (API)
• Media-management vendors (MMVs) implement the
  RMAN API
• most platforms use a dynamically-linked library
  (DLL) architecture
• these are separate executable files which are
  invoked only on demand
• on Solaris, the LD_LIBRARY_PATH environment
  variable directs the oracle executable to find
  the libobk.so shared-link-object (written by
  the MMV)

7
So whats the hassle?

• Its (relatively!) new
• its predecessor (Oracle7 EBU) was poorly
  designed
• there have been serious bugs, mostly prior to
  8.0.5
• counterpoint its been generally available
  since 1997
• Its unfamiliar
• it seems complicated (its not!)
• it has its own scripting language to learn and
  some new concepts to master
• People trust their existing homegrown scripts or
  other 3rd-party products
• BMC SQLBacktrack is an excellent competing
  product

8
So whats the hassle?

• RMAN installation can be a pain
• this is true linking the MMV software can be
  frustrating, due to version-compatibility issues
• now were mixing and matching versions, bugs,
  patches, and upgrades from two software vendors
  instead of just one
• As recently as 2-3 years ago, the typical RMAN
  installation has sometimes involved days or weeks
  of efforts to
• acquire appropriate compatible software versions
• configure MMV software
• debugging RMAN and MMV glitches
• Learning the RMAN way of doing things
• No longer true for mainstream MMVs
• Veritas, Legato, ADSM

9
What makes it worth it?

• Forget the GUI packaging hype and the
  bells-and-whistles and hype about ease of use
• Every other competing product has the same stuff!
• But one-click or one-command
  restore-and-recovery is a nice thing at 230am on
  Sunday morning!
• What is really important to consider is that RMAN
  does three things better than any other solution
• 1. hot backups without the need for the ALTER
  TABLESPACE xxx BEGIN/END BACKUP commands (only
  RMAN can do this!)
• 2. Incremental backups
• 3. Detection of corrupted database blocks during
  backup

10
Hot backups the old way

• Tablespaces must be put into BACKUP mode
• ALTER TABLESPACE xxx BEGIN BACKUP
• datafile headers are frozen
• database blocks continue to be written down by
  DBWR
• nothing is stored anywhere else while the
  backup is in-progress (a popular misconception)
• initial changes to blocks (after BEGIN BACKUP)
  cause entire block image to be written to redo
  logs, instead of just the data being changed
• subsequent changes to blocks are normal vectors
  only
• ALTER TABLESPACE xxx END BACKUP
• CKPT continues writing to datafile headers
• normal redo logging resumes

11
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
10001
10001
10001
10001
10001
10001
10001
SYSTEM
USERS
TEMP
DATA
INDEXES
12
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
12053
12053
12053
10001
10001
12053
12053
SYSTEM
USERS
TEMP
DATA
INDEXES
13
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
15791
15791
15791
10001
10001
15791
15791
SYSTEM
USERS
TEMP
DATA
INDEXES
14
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
16330
16330
16330
10001
10001
16330
16330
SYSTEM
USERS
TEMP
DATA
INDEXES
15
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
16995
16995
16995
10001
10001
16995
16995
SYSTEM
USERS
TEMP
DATA
INDEXES
16
Hot backups the old way
sys01.dbf
usr01.dbf
tmp01.dbf
dat01.dbf
dat02.dbf
idx01.dbf
idx02.dbf
17201
17201
17201
10001
10001
17201
17201
X
X
SYSTEM
USERS
TEMP
DATA
INDEXES
17
Hot backups the old way

• While a tablespace is in BACKUP mode, we are
  purposely copying in-flux datafiles!
• Changes are being made to the datafile as we copy
  them! We are copying corrupted files...
• and we dont care! Because datafile headers
  contain the System Change Number (SCN) which
  time-stamped the BEGIN BACKUP command
• recovery would start from the BEGIN BACKUP
  point-in-time if instance fails before END BACKUP
  command
• after END BACKUP, recovery would start from last
  checkpoint point-in-time, just like normal
• The backup of the datafile is simply a baseline
  against which redo logs are applied during
  recovery roll-forward.

18
Hot backups the old way

• A fractured block is a database block where an
  earlier copy was made of the beginning of the
  block and a later copy was made of the end of the
  block
• Redo log change vectors can not mend this
  condition
• Oracle has no control over the I/O blocksize used
  by copy utilities
• RDBMS has to assume the worst (i.e. the backups
  I/O blocksize does not match DB_BLOCK_SIZE)
• To deal with this situation, full block-images,
  not the normal change vectors data structures,
  are logged to the redo logs for the first change
  to a block after the tablespace is put into
  BACKUP mode.
• Subsequent changes are normal change vectors
• Full block-images protect against fractured blocks

19
Hot backups the old way

• Thus, the volume of redo increases dramatically
  while a heavily-updated tablespace is in BACKUP
  mode
• possibly overwhelming the LGWR
• bottlenecking online RDBMS performance
• possibly overwhelming the ARCH process(es) and
  the file systems storing archived redo logs
• Without RMAN, solutions are hideously expensive
• example double-mirrored RAID1 (i.e. three copies
  of data)
• put tablespace into BACKUP mode, then logical
  volume manager splits off one copy, then take
  tablespace out of BACKUP mode (all 3 steps take
  only seconds)
• backup then performed against split-off copy
• split-off copy must be resilvered back into live
  copies

20
Hot backups RMAN

• RMAN uses a consistent-read mechanism, almost
  exactly like regular server processes
• if the database block is current in the Buffer
  Cache, then that image is used
• eliminates the possibility of fractured blocks
• So RMAN doesnt put tablespaces into BACKUP mode
• Extra redo information is not generated during a
  hot backup from RMAN
• excessive I/O due to additional redo volume can
  be a serious problem for databases with high
  transaction rates

21
Incremental backups

• Instead of performing a complete file copy of the
  datafiles, why not just copy database blocks that
  have been changed since the last backup?
• For many applications, the number of database
  blocks that have been changed since the last
  backup is small
• data warehouses are a good example
• Other backup utilities cannot read the contents
  of database blocks
• those that can (i.e. SQLBacktrack) are
  explicitly not supported by Oracle Support!
• During incremental backups, Oracle stores the SCN
  of the last backup
• and only copies database blocks changed since then

22
Incremental backups

• Depending on the type of application, incremental
  backups can decrease the volume of backups
  dramatically
• reduces cost of backup media
• reduces I/O bandwidth required to backup media
• important if backup media is located on network
• reduces time of backups

23
Incremental backups

• Considering tradeoffs in optimizing backups or
  optimizing restores
• If your goal is to minimize volume of backups
• Sat level 0 (full)
• Sun level 1 (incr since level 0 on Sat)
• Mon level 2 (incr since level 1 on Sun)
• Tues level 3 (incr since level 2 on Mon)
• Wed level 1 (incr since level 0 on Sat)
• Thurs level 2 (incr since level 1 on Wed)
• Fri level 3 (incr since level 2 on Thurs)

24
Incremental backups

• Considering tradeoffs in optimizing backups or
  optimizing restores
• If your goal is to minimize time of restore
• Sat level 0 (full)
• Sun level 1 (incr since level 0 on Sat)
• Mon level 1 (incr since level 0 on Sat)
• Tues level 1 (incr since level 0 on Sat)
• Wed level 1 (incr since level 0 on Sat)
• Thurs level 1 (incr since level 0 on Sat)
• Fri level 1 (incr since level 0 on Sat)
• Its good to have choices!

25
Corrupt-block detection

• Like the bumper sticker says
• Corruption Happens!
• The best solution for fixing database corruption
  is
• if the problem is a hardware or software bug, fix
  it!
• restore the affected datafile(s) from backup
  taken prior to occurrence of corruption
• recover by rolling forward with redo logs
• There are other possible solutions
• Oracle Support has utilities for block editing,
  etc
• Oracle8i has the new DBMS_REPAIR package

26
Corrupt-block detection

• It is crucial to detect corrupted blocks before
  they are backed up
• otherwise, it will be impossible to fix using the
  restore and recover approach
• betting on any other solution (frequent exports,
  block editing by Oracle Support, etc) is a poor
  bet!
• Prior to Oracle8 and RMAN
• the only way to accomplish this was some form of
• EXP FULLY FILE/dev/null
• even this wouldnt check the SYSTEM tablespace!
• big waste of resources (unless it discovers
  something!)
• SQL-generating-SQL scripts that SELECT COUNT()
  every table in the database is another option

27
Corrupt-block detection

• Because RMAN uses Oracle server processes to read
  database blocks, the normal block validations are
  performed upon read
• if process cannot interpret the block header, the
  block is marked as hard-corrupt or media-corrupt
  by writing a new header
• ORA-01578 ORACLE data block corrupted (file
  nnn, block nnn) to alert.log
• RMAN also stores list of corrupt blocks in
  control file
• can be viewed in VBACKUP_CORRUPTION and
  VCOPY_CORRUPTION

28
Corrupt-block detection

• If DB_BLOCK_CHECKSUM set to TRUE (default FALSE),
  RMAN will also checksum and compare
• detects logical corruptions inside database
  blocks
• blocks will be marked soft-corrupt or
  logical-corrupt
• also generates ORA-01578 message to alert.log
• can be disabled with NOCHECKSUM command
• Caveat RMAN cant detect every form of
  corruption!
• Nothing can corruption is (by definition)
  unpredictable
• RMAN will allow corrupt blocks on the backup up
  to the limit specified by SET MAXCORRUPT
• if threshold is exceeded, backup terminates with
  errors
• default is SET MAXCORRUPT0

29
Summary

• If any of the following are true, then RMAN is
  worth the trouble
• backups take too long or too many tapes
• data loss cannot be tolerated
• database generates too much redo when in hot
  backup mode
• An RMAN solution better enables VLDB
• enables more frequent backups (important if using
  NOLOGGING, for example)
• prevents data loss due to corruption
• If these are not important, then rest easier when
  considering another (3rd-party) backup utility or
  when using custom-built backup/recovery scripts

30
Documentation

• Oracle8i Backup and Recovery Guide
• part II, chapters 4 through 10, Using Recovery
  Manager
• Oracle Backup and Recovery 101 by Stephan
  Haisley, from Oracle Press
• Oracle9i Backup and Recovery Handbook by Rama
  Velpuri, from Oracle Press
• New technical library section of MetaLink
  (http//metalink.oracle.com) contains lots of
  sample scripts on RMAN

31
QA