Oracle RMAN 11g Backup and Recovery (185 page)

That being said, try to avoid using production Grid Control for RMAN test environments. The databases will be down, up, down, lost, trashed, crashed, and lost. This means lots of alerts will be sent to the Oracle Management Service (OMS) and, consequently, e-mailed out to people.

Avoid bot spam! If you have not already deployed a test Grid Control environment for your enterprise, get one set up for your RMAN backups, and then offer it to others for testing purposes.

For Database Control, expect a memory hit of 150 to 200MB per instance. Also, Database Control makes heavy use of CPUs and uses up database space. Database Control generates about 200MB of archive logs per day just by itself, with an idle database.

For Grid Control, you need a 2GB system all by itself for the repository database and OMS.

Factor it in as a separate system. On the RMAN test system itself, the agent will use only about 60MB of memory and enough CPU to run its Perl scripts.

OEM, either Database or Grid Control, is highly dependent on a stable and predictable networking sublayer, which means you cannot constantly change the hostname or IP address.

Sorry. It’s just easier that way. If you have to, create your own subnet and manually assign dummy IP addresses in the hosts files. The easiest checks you can implement to ensure everything will operate correctly are the
nslookup
command on the hostname and a reverse lookup on the IP

address.

Media Management Considerations

If possible, you should install a version of the media management client that you will be using in production. Then, install the Oracle Plug-In and do the backups to tape the same as you would in production. This gives you the best opportunity to anticipate what to expect when you implement your strategy in your enterprise.

If you can’t get access to the media management product that is used for your enterprise, there is little alternative left. The best option is to try Oracle Secure Backup, as outlined in Chapter 5 of this book.

If you simply need to test tape channel allocations, or the process of staging the flash recovery area to tape, you still have access to the Oracle SBT API, which enables you to write “tape” backups to a disk location. This is described in the RMAN Workshop “Test Tape Channels with the Oracle Default SBT Interface” in Chapter 4.

630
Part V: Appendixes

The RMAN Configuration

Now that you have your system set up with Oracle installed and databases built, we have a few hints on the testing process:

■
Have a cold backup that remains untouched.
Before you do any RMAN testing, shut down your database, take a cold OS copy backup, and place it in a folder that doesn’t get touched. This is your last line of defense if you completely mess everything up during your RMAN testing.

■
Switch your redo logs a lot.
One of the biggest mistakes that happens with RMAN testing is that the timeframe between the backup and restore is unrealistically short. Confusion sets in because there is no space between the completion time of the backup and the

“until time” of the restore operation. So, after any backup, make sure you switch the log file three or four times, just to put a little “distance” between operations.

■
Set the NLS_DATE_FORMAT environment variable.
This is good advice for RMAN in general, but particularly in a test situation, where the timeframe between a backup and a restore will be unrealistically short, and you will want to know the timeframe of a backup to the second. So, before starting RMAN, be sure to run the following:

export NLS DATE FORMAT 'mon-dd-yyyy hh24:mi:ss'

Then, when you start RMAN and issue a
list backup
command, the time will always show details to the minute and second.

■
Leave your catalog database alone
. You will be tempted to use the database that houses your catalog as a target and to perform some tests with it. That is fine—

that’s why it’s

called a test environment. But you can seriously undermine your testing if you foul up your catalog. Do yourself a favor and leave the catalog database alone. And export your catalog schema with a user-level export before any new test session begins.

■
Keep up with catalog maintenance.
This may be your test environment, but you will be creating a lot of backups over time, and you have a limited amount of space on your little test box. Take the opportunity to test using retention policies to get rid of old backups.

■
Remove clones as soon as possible.
Attack of the clones! If you use the
duplicate
command, you can end up with numerous different instances running and taking up precious memory and disk space. Hey, it’s a clone, and you’re in a test environment—

get

rid of it as soon as you make it.

■
Leave a clone file system in place.
You don’t need to go through the steps of building the file system and the init.ora file for your duplicate database every time you want to test the
duplicate
or
duplicate for standby
command. Leave the file system and supporting files in place, and use the same DB_NAME and SID. On Windows, be sure to leave the Oracleservice in place in the Services control panel.

Appendix C: Setting Up an RMAN Test Environment
631

■
Don’t get attached to your test environment.
Sometimes you need to just blow everything away and start over from scratch, particularly if you don’t have good maintenance habits.

Eventually, your database will get to the point that it has had tablespaces dropped; has had re-created, dropped, and forgotten files placed in the wrong directory; has had archive logs stored all over the place—

basically it’s a rambling mess. Don’t worry. That’s

why they call it testing. Don’t get too wrapped up in the environment you have; just whack everything and start over from the cold backup you took prior to testing.

You’ll surely find some of your own valuable lessons after you’ve done a bit of testing. After you go through the conceptual learning, take the scripts you’ve built and the knowledge you’ve gained, and schedule some time on a production-grade system to make sure that everything is going to scale up to your enterprise. You’ll be glad you took the time to learn it before you went live.

This page intentionally left blank

Index

A

performing RMAN backup using alter database create standby

TDPO, 199–203

controlfile command, 252

ACO (Advanced Compression

recovering control file from

alter database datafile end backup

Option), 116

autobackup not using

command, 267

active online redo log

FRA, 273

alter database datafile offline

loss of, 296

recovering SPFILE from specific

command, 292

overview of, 17–18

backup set, 272

alter database disable block change

recovering from loss of, 294

storing S3 as default SBT

tracking, 256

Active Session History (ASH),

channel, 149

alter database drop logfile command,

V$ACTIVE_SESSION_HISTORY

syntax details, 564–565

70, 295

view
, 457

testing tape channels, 107

alter database enable block change

admin class, OSB rights, 122

troubleshooting TSM

tracking, 255

admin user
, OSB installation, 120,

backups, 206

alter database open command

125–126

allocate channel for maintenance

ARCHIVELOG mode full

Administration Center
, TSM, 194

command, 565

recovery
, 29

administrative data, OSB, 119–120

allocOperandList command,

loss of current online redo log

administrative domain, OSB,

612–613

group, 296

117–1
18

alter database activate standby

offline RMAN backups using

Advanced Compression Option

database command, 493

default settings, 230–231

(ACO), 116

alter database add logfile command,

point-of-failure database

advise failure command, Data

70, 294–295

recoveries, 290

Recovery Advisor
, 297,

alter database add standby logfile

alter database open resetlogs

299–300, 564

command, 70

command

alert log messages

alter database begin backup

ARCHIVELOG point-in-time

defined, 6

command, 28

recoveries, 30

managing space in FRA,

alter database checkpoint

completing repair failure

64, 67

command, 296

command with, 297

in new Fault Diagnosability

alter database clear logfile

recovery from complete

Infrastructure, 74

command, 296

database loss

online redo logs, 17

alter database clear logfile group

(NOARCHIVELOG) with

restore command failover
, 271

command, 295–296

recovery catalog, 536

split mirror backups of

alter database clear unarchived

restoring database in

datafiles, 522

logfile command, 296

NOARCHIVELOG mode, 282

allocate channel command, 85

alter database command

alter database rename file command,

maxpiecesize parameter
, 240

managing online redo logs,

70, 256

offline RMAN backups without

19–20

alter system archive log current

configured defaults, 233–235

referencing datafiles, 293

command, 247–248, 363

passing environment

syntax details, 566

variable, 107

634
Oracle RMAN 11
g
: Backup and Recovery

alter system checkpoint command,

backups, modifying with change

physical backups in, 27–28

294–296

command, 409

point-in-time recoveries in, 30–31

alter system command, 68

backups up with encryption, 96

recovering control file, 278

alter system set command, 56

creating image copies of, 255

restore and recovery of database

alter system switch logfile command,

crosschecking backups, 402

in, 29, 287–291

27, 62

as database physical

RMAN requiring, 46

alter tablespace begin backup

component, 15

tablespace and datafile recovery

command, 27–28

defined, 7–8

in, 29–30

alter tablespace offline command, 29

full database recovery in

taking datafile offline in, 14

alter tablespace online command, 29

ARCHIVELOG mode, 29

ARCHIVELOG mode, configuring

alter tablespace tablespace_name

listing backups of, 432–433

database in, 62–73

offline for recover command, 364

listing copies of, 436–437

destination directories, 62–64

alter tablespace users offline

log sequence-based recovery

FRA, 64–67

command, 292

of, 349

FRA and
ASM, 70

alter tablespace users online

log sequence number of, 9, 19

FRA
benefits, 71

command, 292

online backups, 250–251

FRA
views, 67–69

Amazon Web Services.
See
AWS

recovery catalog views for,

if you created database with

(Amazon Web Services)

217, 219

ODBCA, 71–72

ANS errors, TSM, 205–206

recovery from complete database

other FRA
features, 70

ANU errors, TSM, 205–206

loss with recovery catalog, 541

overview of, 62

Apache web server backup daemon,

recovery, troubleshooting,

switching between

OSB, 119

375–376

NOARCHIVELOG mode and,

Application Backup Schedule,

restoring from backup using

71–73

163–164, 167

RAC, 509

archivelog parameter, copy

ARCH processes, 12–13, 18–20