Read Oracle RMAN 11g Backup and Recovery Online
Authors: Robert Freeman
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
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
ACO (Advanced Compression
recovering control file from
alter database datafile end backup
autobackup not using
active online redo log
alter database datafile offline
recovering SPFILE from specific
alter database disable block change
storing S3 as default SBT
Active Session History (ASH),
alter database drop logfile command,
V$ACTIVE_SESSION_HISTORY
view
, 457
alter database enable block change
troubleshooting TSM
admin user
, OSB installation, 120,
alter database open command
allocate channel for maintenance
ARCHIVELOG mode full
Administration Center
, TSM, 194
recovery
, 29
administrative data, OSB, 119–120
allocOperandList command,
loss of current online redo log
administrative domain, OSB,
alter database activate standby
offline RMAN backups using
Advanced Compression Option
alter database add logfile command,
point-of-failure database
advise failure command, Data
Recovery Advisor
, 297,
alter database add standby logfile
alter database open resetlogs
command
alert log messages
alter database begin backup
ARCHIVELOG point-in-time
managing space in FRA,
alter database checkpoint
completing repair failure
in new Fault Diagnosability
alter database clear logfile
recovery from complete
database loss
alter database clear logfile group
(NOARCHIVELOG) with
restore command failover
, 271
split mirror backups of
alter database clear unarchived
restoring database in
alter database command
alter database rename file command,
maxpiecesize parameter
, 240
managing online redo logs,
offline RMAN backups without
alter system archive log current
passing environment
634
Oracle RMAN 11
g
: Backup and Recovery
alter system checkpoint command,
backups, modifying with change
point-in-time recoveries in, 30–31
backups up with encryption, 96
restore and recovery of database
alter system switch logfile command,
as database physical
alter tablespace begin backup
tablespace and datafile recovery
alter tablespace offline command, 29
full database recovery in
taking datafile offline in, 14
alter tablespace online command, 29
ARCHIVELOG mode, configuring
alter tablespace tablespace_name
offline for recover command, 364
destination directories, 62–64
alter tablespace users offline
log sequence-based recovery
FRA and
ASM, 70
alter tablespace users online
FRA
benefits, 71
FRA
views, 67–69
Amazon Web Services.
See
AWS
recovery catalog views for,
if you created database with
(Amazon Web Services)
recovery from complete database
other FRA
features, 70
loss with recovery catalog, 541
Apache web server backup daemon,
recovery, troubleshooting,
switching between
NOARCHIVELOG mode and,
Application Backup Schedule,
restoring from backup using
archivelog parameter, copy