There Is No Good Reason

For Not Using RMAN

Raj Pal, EchoStar Technologies Corp.

Topics

1. Caveat.
2. RMAN In A Rush.
3. Corruption Management Using RMAN With
Neither Budget Nor Space!
4. Corrupt Block Recovery (No Downtime)
Without Prior RMAN Backups!

2
 Caveat…
 RMAN is fantastic, important & necessary for:
 Corruption checking
 Restoring
 Recovering
 Duplicating
 Etc…
 RMAN, on its own, is not a good solution for high
availability (HA) of high visibility/important
database instances (especially for large
databases).

3
RMAN In A Rush!

4
Assumptions
• Business database instance must remain open
and functional.
• Offsite storage mechanism in place.
• 9i or higher (just for syntax below).

Requirements
• Front end app, Oracle binaries, init, etc… are
already being backed up.
• Sysdba or rman role.
• OS User is part of DBA group
• Archivelog mode.
• Sufficient amount of RMAN disk.
5
Space Considerations:
• Datafiles
• Controlfiles
• Archived Redologs
• Minimum space required is for redo generated during the
backup.
• Recommended space is for redo generated during and
between 3 regularly scheduled level0 backups.

6
 RMAN Disk
Offsite
Storage

Datafile BU Arch BU Control Copy

.rmn .rmn .ctl

Instance
Host

Static Files .dbf .arc .ctl

(.ora,bin,etc…)

7
Setup
• Separate backup types on RMAN disk by
directory (eg.)
• /RMAN/<SID>_ARCH
• /RMAN/<SID>_DATA
• /RMAN/<SID>_CONTROL

• Init parameters - dynamic (eg.)

• alter system set control_file_record_keep_time = 30;
• alter system set archive_lag_target = 900;
• Init.ora file too!

8
 Example of a POOR Setup
control_file_record_keep_time = 5

Feb 11

Feb 13

Feb 15
Feb 3

Feb 5

Feb 7

Feb 9
Arch 11-20

Arch 21-30
Level 0

Level 1

Level 0
Arch 1-10

Level 1

Current contolfile

Arch 30 contolfile

Controlfile’s Level 1 contolfile

9
Actions:
• Ensure other systems are not removing archived logs.
• Set environment.
• $ export ORACLE_SID=<SID>
• $ export ORACLE_HOME=<SID_HOME>
• $ rman target / nocatalog

• Backup archived logs (temporary).

run {
allocate channel a1 type disk format '/RMAN/<SID>_ARCH/%d_arch_%s_%p_%c_
%t.rmn';
backup
skip inaccessible
archivelog all
tag 'manual_arch'
filesperset 4
delete input;
}

10
(… Actions…)
• Backup level0.
$ rman target / nocatalog
run {
allocate channel b1 type disk format '/RMAN/<SID>_DATA/%d_%s_%p_%c_
%t_level0.rmn';
…
allocate channel b<n> type disk format '/RMAN/<SID>_DATA/%d_%s_%p_
%c_%t_level0.rmn';
sql 'alter system archive log current';
backup incremental level=0
tag ='level0'
check logical
database;
sql 'alter system switch logfile';
copy current controlfile to
'/RMAN/<SID>_CONTROL/<SID>_level0_<date>.ctl';
}

11
(…Actions…)

• Validate Archived logs.

$ rman target / nocatalog
run {
allocate channel v1 type disk;
allocate channel v2 type disk;
…
allocate channel v<n> type disk;
change archivelog all validate;
}

• Schedule archive backups.

• Set cron for regular level0 backups.
• Tape backup of RMAN disk.

12
Pros
• All benefits of RMAN!!
• No need for Oracle Agent from tape vendor!!
• Backups/Restores from disk are faster than
tape!!
• No need for ‘hot backup mode’!!
• RMAN utility is included with all standard and
Enterprise Oracle licenses!!
Cons
• Your controlfile has limited visibility into the
history of its backups.
• Disk is more expensive than tape.

13
Corruption Management Using
RMAN With Neither Budget Nor
Space!

14
FACTS
• Corruption can, and will, go undetected.
• Corruption can happen due to many reasons.
• Chance of corruption can never be eliminated.
• The longer corruption goes undetected, the
more difficult and potentially costly it is to
correct/overcome.

Do You Know If You Have Corruption?

Are you Sure?

15
What Are Your Options To Find Corruption?
• select * from <table>;
• analyze … validate structure cascade [online];
• exp/imp show=y
• DBV
• DBMS_REPAIR
• Init parameters
• db_block_checking
• db_block_compute_checksum
• db_block_checksum
• db_block_cache_protect=‘true’
• _db_block_cache_protect=true
• _check_block_after_checksum
• _db_always_check_system_ts
• Sum
• 3rd party
• RMAN

16
RMAN to find corruption without $$ or space
• Write Script
$ vi /RMAN/SCRIPTS/level0_validate.ksh

#!/bin/ksh
export ORACLE_SID=<SID>
export ORACLE_HOME=<SID_HOME>
echo "before_time: `date +"%Y%m%d%H%M%S"`"
rman target / nocatalog <<DONE
run {
allocate channel b1 type disk;
…
allocate channel b<n> type disk;
backup incremental level=0
tag ='level0_validate'
check logical
validate
database;
}
DONE
echo "after_time: `date+"%Y%m%d%H%M%S"`"

• Execute Script
$ chmod 700 /RMAN/SCRIPTS/level0_validate.ksh
$ /RMAN/SCRIPTS/level0_validate.ksh > level0_validate.log 2>&1

17
NOTE:
• Log output will NOT indicate corruption found!
• Database must be queried after RMAN validate
$ vi /RMAN/SCRIPTS/level0_validate.ksh

$ sqlplus '/as sysdba'

SQL> select distinct c.file# "File#",c.block# "Starting Block#", c.blocks "Range"

from v$backup_corruption c, v$backup_set s
where c.set_stamp = s.set_stamp
and c.set_count = s.set_count
and s.start_time > to_date(‘&before_time', 'YYYYMMDDHH24MISS')
order by 1,2;

• Get “before_time” variable from RMAN validate log

$ grep “before_time:” level0_validate.log

18
Pros
• You are backing up with RMAN!!
• Corruption checking as supported and designed
by Oracle!!
• Other than small log files, no additional space
was used for this system!!
• No additional cost was incurred!!
Cons
• RMAN uses host resources and can take time.
This should be during low instance activity.
• You are not actually backing anything up!
19
 Corrupt Block Recovery
(No Downtime) Without Prior
RMAN Backups!

20
What Are Your Options To Handle Corruption?

• DBMS_REPAIR
• Full database recovery
• Individual datafile recovery
• create table … as select …;
• drop table …; recreate from export.
• RMAN

21
RMAN to Repair Corruption
– Without Prior RMAN Backups!
– Without Downtime!
– Without Data Loss!

Will this work?

What is your present backup method?
1. Export-Only
2. Cold backup copies - noarchivelog
3. Cold backup copies - archivelog
4. ‘Hot backup mode’ copies
5. Consistent snap (crash-consistent) copies

22
Non-RMAN Backup Analysis:
1. Export-Only
• Not possible to restore without downtime!
• Data loss is likely!
• Terrible choice for backup!
2. Cold backup copies – noarchivelog
• Not possible to restore without downtime!
• Data loss is likely!
• Awful choice of backup for a database with high uptime needs!
3. Cold backup copies – archivelog
• RMAN can save the day!
• Why are you backing up cold with high uptime requirements?
4. ‘Hot backup mode’ copies
• RMAN can save the day!
5. Consistent snap (crash-consistent) copies
• RMAN can save the day!

23
Steps:
1. Note file# and block# of corrupt block(s).
2. Ensure that the last good backup of the
corrupted file is visible.
3. Catalog just the backup of the corrupt file
in the controlfile using the RMAN utility.
RMAN> catalog datafilecopy ‘/<HotBUModeFileCopyLocation>/<BUOfDataFileWithCorruptBlock>.dbf’;

4. Recover the corrupt block(s) using the

RMAN utility.
RMAN> blockrecover
datafile <#> block <#>[,#2,…]
[datafile <#2> block<#>];

24
Example:
No corruption in database yet (run after RMAN validate procedure).

25
(example)
‘Hot backup mode’ copy – Last “good” backup.

26
(example)
Corruption strikes.

27
Step #1
Note file# and block# of corrupt block(s).

Options:(after RMAN validate is run)

• Select from v$backup_corruption

select distinct c.file# "File#",c.block# "Starting Block#", c.blocks "Range"
from v$backup_corruption c, v$backup_set s
where c.set_stamp = s.set_stamp
and c.set_count = s.set_count
and s.start_time > to_date('&before_time', 'YYYYMMDDHH24MISS')
order by 1,2;

• Alert log
• Trace file
• DBV
dbv file=<file> blocksize=<blocksize>

28
(example) – Select

29
(example) – Alert log

30
(example) – Trace file

31
(example) – DBV

32
Step #2:
Ensure that the last good backup of the corrupted file is visible.

33
(example)
Proof that no RMAN backups exist & attempt block recover.

34
Step #3:
Catalog the backup of the corrupt file in the controlfile using the RMAN utility.

35
(example)
Only thing in controlfile.

36
Step #4:
Recover the corrupt block(s) using the RMAN utility.

37
(example) – DBV (after fix)

38
(example)
But record of corruption remains in view.

39
Pros
• RMAN just saved you from instance downtime
for a corruption recovery, without a prior RMAN
backup and without data loss!!
Cons
• If your first corruption check identifies corruption,
it will be difficult to find the last good, corruption-
less backup. To be effective, regular corruption
checks are highly recommended.
• If you wanted to make corruption sound like the
big deal that it is, you have just gone under the
radar by maintaining uptime, so you will not get
the attention that you had hoped for
40
 Summary…
 RMAN will not necessarily get your database
restored and recovered fast… But it WILL
restore and recover it!!
 Need to backup a datafile, tablespace or entire
database fast and surely? Use RMAN!!
 Do you have corruption in your database? Are
you sure? Use RMAN!!
 Did you find corruption in your database, have
no previous RMAN backups and can’t afford a
downtime? Use RMAN!!

41
 CONCLUSION

ThereIs No Good
Reason For Not
Using RMAN!
42
QUESTIONS?

Contact Info:
Raj@Palfoundation.net

43