Eastern Caribbean Oracle Users Group

1
Eastern Caribbean Oracle Users Group
Is RMAN Really Worth The Trouble?Tim
Gorman14 March, 2001Evergreen Database
Technologies, Inc.

• www.EvDBT.Com

2
Agenda

• RMAN architecture
• So whats the hassle?
• What makes it worthwhile?
• Standardized backup/recovery strategy
• Three features that only RMAN has...
• and nothing else 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
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
Target database
5
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)

6
So whats the hassle?

• Its (relatively!) new
• its predecessor (Oracle7 EBU) was seriously
  flawed
• there have been serious bugs, mostly prior to
  8.0.5
• counterpoint its been generally available
  since 1997
• with Oracle8i, its no longer a .0 release
• Its unfamiliar
• it seems complicated
• 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

7
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 18-24 months 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 is all this true, in most cases

8
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

9
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

10
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
11
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
12
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
13
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
14
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
15
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
16
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.

17
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

18
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

19
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 backed up
• If the database block needs to be read from disk,
  then its most-recent image is constructed in the
  Shared Pool or Large Pool
• 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

20
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

21
Incremental backups

• Depending on the type of application, incremental
  backups can decrease the volume of backups by 50
  or more, on average
• reduces cost of backup media
• reduces I/O bandwidth required to backup media
• important if backup media is located on network
• reduces time
• Actually, you can reduce by much more than that
  (if that is your goal), but at a cost in
  speed-of-restore

22
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

23
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

24
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

25
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

26
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

27
New RMAN features for Oracle8i

• LIST command has been enhanced for more reporting
• PURGE command
• COPY DATABASE command
• Recovery Catalog cross-check
• synchronize the recovery catalog with the
  media-management vendors (MMVs) internal
  catalog
• for example, some MMVs automatically expire tapes
• Optimizations for massively-parallel processing
  (MPP) clustered environments
• Used with Oracle Parallel Server (OPS)

28
Documentation

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