Professional Documents
Culture Documents
Backup & Recovery With Oracle10g RMAN
Backup & Recovery With Oracle10g RMAN
Backup & Recovery With Oracle10g RMAN
Legal Notice
Copyrights
Copyright 2005-2007 SkillBuilders, Inc. All rights reserved. Printed in the United States of
America.
No part of this publication may be reproduced, distributed or displayed in any form or by any
means, or stored in a database, retrieval system or other media without the prior written
permission of SkillBuilders, Inc. This publication is the Confidential Property of SkillBuilders,
Inc.
Trademarks
The product/service names mentioned herein are manufacturer/publisher trademarks and are used
only for purposes of identification.
Microsoft, Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT, and
Microsoft Windows are registered trademarks of Microsoft Corporation. Netscape, Netscape
Navigator, and the Netscape logo are registered trademarks of Netscape Communications
Corporation in the United States and other countries. Oracle, Oracle8i, Oracle9i and Oracle10g
are registered trademarks of Oracle Corporation.
All other brand, product and service names are the trademarks of their respective companies or
owners as mentioned herein.
Disclaimer
Information within this publication is subject to change without notice. Although every
precaution has been taken in the preparation of this book, the publisher and author assume no
responsibility for errors or omissions. The author and SkillBuilders, Inc. make no representation
or warranty with respect to the contents herein and specifically disclaims any implied warranties
of fitness for any particular purpose. SkillBuilders, Inc. disclaims all liability for any direct,
indirect, incidental or consequential, special or exemplary damages resulting from the use of the
information in this document or from the use of any products described in this document.
Compressed Backups................................................................................................13.25
Change Tracking...................................................................................................13.26
Incrementally Updated Image Copies...................................................................13.28
SWITCH DATABASE Command ...........................................................................13.30
Encrypted Backups ...................................................................................................13.32
RMAN DROP DATABASE ....................................................................................13.33
RMAN CATALOG Command.................................................................................13.34
DURATION Parameter ............................................................................................13.35
New V$ Views..........................................................................................................13.36
More RMAN Enhancements ................................................................................13.37
Additional R2 RMAN Enhancements ..................................................................13.39
User-Managed Enhancements ..................................................................................13.41
Oracle Secure Backup...............................................................................................13.42
Lesson Summary...................................................................................................13.43
Lesson 1
Introduction to
Recovery Manager
What is Recovery Manager?
SKILLBUILDERS
2005-2007 SkillBuilders, Inc.
1.2
Lesson Objectives
What is RMAN?
Basic Feature Summary
Focus on the RMAN Repository
9i New Features
1.3
What is RMAN?...
Oracle utility for backup, restore and recovery
Provides server-managed recovery
Can be used in place of OS copy (user-
managed) backup techniques
Automates many tasks
Could be considered easier
Shipped with all versions of Oracle
Recovery Manager (usually called RMAN) is a utility for the backup and recovery of Oracle 8.0, 8.1
and 9.x databases. It is not compatible with Oracle7 databases. It replaces the version 7 Enterprise
Backup utility, which is now obsolete.
RMAN can be used in place of OS backup techniques (note that Oracle documentation now refers to
OS copy backup techniques as user-managed).
RMAN will automate many tasks. For example, RMAN Full Backups will always backup all datafiles
without script modification because RMAN has access to the controlfile and knows the current
structure of your database. Also, RMAN eliminates the need to locate the files needed to recover -
RMAN keeps track of this automatically. RMAN also allows administrators to create and save scripts
that perform repeated tasks.
RMAN is shipped with all versions of Oracle. A separate purchase and install is NOT necessary.
1.4
...What is RMAN?
Extra cost
Software - $0 unless purchasing Tape software
Veritas, Legato
Training - ???
Supports Oracle 8 and up
Cannot use with version 7 databases
Command line execution
Or Graphical UI through Oracle Enterprise
Manager
Since RMAN is shipped with all editions of Oracle, there is no extra cost. This changes perhaps
drastically if you require direct backup to tape. Except for a very rudimentary plus-in supplied by
Legato, RMAN does not ship with the capability to write to tape you must purchase software such
as Legato Networker or Veritas Netbackup. Well discuss this in further detail later in this course.
RMAN was first introduced with Oracle8.0. It is not compatible with Oracle7 databases. It replaces
the version 7 Enterprise Backup utility, which is now obsolete.
RMAN commands can be executed via a command line utility (much like Server Manager) or through
the graphical user interface in Oracle Enterprise Manager.
1.5
Basic Features...
Full and incremental backups
Online (hot) or offline backups
Elimination of complex hot backup procedures
RMAN server sessions automatically re-reads inconsistent
blocks
No extra redo generated
RMAN Intelligence:
Maintains repository of backup metadata
Remembers backup set location
Knows what needs to be backed up
Knows what is required for recovery
Knows what backups are redundant
1.6
...Basic Features...
Parallel operations
Backup to disk or tape
Tape requires vendor MML
Compress backups by skipping never-used blocks
Extensive Reporting
Scripting
Create scripts for often repeated tasks
O/S independent scripting language
Can store in central repository
Multiple server sessions can be created on the target database; these are used to perform
backup and recovery operations in parallel
Backup to tape (using tape vendor software more on this later) or disk
Compress backups by skipping unused blocks. RMAN does not backup blocks in datafiles
that have never been used.
Extensive reporting on backups taken, what has not been backed up, what backups are
redundant and more. This includes the ability to create readable and printable logs of all
operations.
RMAN can store often-repeated tasks as scripts in a recovery catalog - a central repository.
1.7
...Basic Features
Duplex backup sets
Support for up to 4 copies
Corrupt block detection
Prevents creation of unusable backups
Backup archive logs
Housekeeping - optional automatic delete of
backed up logs
Test restore
Duplicate a database for testing or standby
RMAN will detect and report on corrupt blocks during the backup operation, eliminating the
creation of unusable backup sets.
Via a simple command, RMAN will backup archive logs and optionally delete the logs after
successful backup.
Test if backups can be restored. See the VALIDATE command.
Create a duplicate database for testing or standby database use. See the DUPLICATE
command.
1.8
RMAN creates and maintains a repository of metadata about the target databases. (Target in
RMAN parlance simply means the database that your backup up.) This is not an optional feature.
The repository provides the intelligence in RMAN. For example, this allows RMAN to keep track of
backups. RMAN knows what has been backed up, what has not and where the backup sets (one or
more OS files) are located, plus much more.
1.9
Located in 1 or 2 places
TargetDatabase control file
Optional Recovery catalog on separate database
The repository contains redo log information including the history of log switches and archived logs,
the history of backups taken and the structure of the target database.
RMAN always maintains a copy of the repository in the target databases control file this is not
optional.
Additionally, RMAN can keep a copy of the repository in a separate recovery catalog. The recovery
catalog should be stored in a separate database optimally on a separate machine.
We will study more about the control file, repository and recovery catalog in the RMAN Architecture
lesson.
1.10
9i New Features...
Persistent Configurations
Use the CONFIGURE command to tailor RMAN environment
Configure automatic channels, retention policies, number of
backup copies and more
Automatic Channels
RMAN automatically allocates channel (optional)
Channels are configurable
AUTOBACKUP of control file
Automatic backup to known name and location
Recover even if control file and RMAN catalog are lost
1.11
RMAN now supports restartable operations. The unit of restart is a backupset (complete set of
backed up datafiles or archived logs). Multiple backupsets can be created in a single backup
the advantage of this is that if the backup fails, any complete backupsets do not need to be
redone. See the NOT BACKED UP SINCE clause and Restartable Backups section of the
Recovery Manager Users Guide for more information.
The command syntax has been simplified. No longer is it necessary to code the backup,
restore an recover commands in a RUN block.
Block Media Recovery (BMR), is the ability to restore and recover corrupt blocks, rather than an
entire datafile or tablespace. See the BLOCKRECOVER command.
1.12
Restore optimization: RMAN will not restore a file is it has not changed. Can be overridden with
the FORCE option.
Backup optimization: Use the CONFIGURE BACKUP OPTIMIZATION command to tell RMAN
not to backup a file if it has not changed (checks SCN and timestamp). This will decrease
backup elapsed time.
9i can easily backup online and archive logs with the BACKUP DATABASE PLUS
ARCHIVELOG command. This insures that you create a consistent backup set for backups
done while the database is open.
Create user-defined retention policies. For example, we can configure RMAN so that backups
are retained for 30 days:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
The REPORT OBSOLETE and DELETE OBSOLETE commands will now only report and
delete, respectively, backup sets that are older than 30 days. Alternatively, you can configure
RMAN to retain multiple copies of a backup:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
Redundancy is mutually exclusive from RECOVERY Window. Recovery Window is usually a
better method but redundancy 1 is the default to maintain compatibility with the 8i REPORT
OBSOLETE command.
1.13
9i R2 New Features...
Backup of Server Parameter Files
Structural DB changes initiate automatic
control file and SPFILE backup
Smarter handling of archived logs
Create duplicate backups before deleting archive
logs with NOT BACKED UP x TIMES
Control and limit space used during recovery with
RESTORE . . . DELETE ARCHIVELOG command
1.14
1.15
Introduction Complete!
OK, we know what RMAN is
We know some basic functions
We have seen some Release 2 features
Lets look at the architecture
Lesson 2
RMAN Architecture
An introduction to the architecture and
components used by the RMAN utility.
SKILLBUILDERS
2005-2007 SkillBuilders, Inc.
2.2
Lesson Objectives
RMAN Components
Effect of mixed releases
Control File and RMAN
CONTROL_FILE_RECORD_KEEP_TIME parameter
Creation
Size
2.3
RMAN Components...
RMAN executable
Client application
Can run on entirely separate machine
Starts server sessions on Target Database
Target Database
Database to be backed up
Control file contains RMAN metadata
Catalog Database
Optional database to hold Recovery Catalog
An RMAN environment is comprised of several components, each of which has a release (or version)
number.
The RMAN executable is an Oracle client application. This client application spawns server
sessions on the target database to do the work of backup or recovery. It is similar in some
ways to SQL*Plus in that it allows connections to databases and provides a line mode
command interface. It is different in that it allows multiple concurrent connections (one to the
target, one to the catalog database and optionally a third to an auxiliary database) and it does
not support SELECT statements. (RMAN actually spawns multiple sessions on the target
database, but supports one CONNECT to the target.)
The Target database is the database to be backed up or recovered. It is where the server
sessions spawned by the RMAN executable run. The target databases control file contains
recovery metadata - that is, information about backups that have been taken. This information
is needed to perform recovery.
The Catalog database is a separate database created to hold the recovery catalog. It is
optional database because the recovery catalog is optional. See the next page for more
information on the Recovery Catalog.
2.4
...RMAN Components
Recovery Catalog
Optional
Secondary location for RMAN repository
Primary location is target database control file
Contains backup metadata
Media Management Library
Required if backing up to tape
Communicates with server session on target
database
Reads and Writes to tape
The recovery catalog is a series of tables and view owned by a single user (typically called
RMAN) populated with backup and recovery information for one or more databases. Since the
target databases control file also contains this information, this is an optional component.
However, it is recommended. See more in the section Recovery Catalog" later in this lesson.
Oracle and RMAN do not come with the ability to directly read and write to tape. You must
install compliant software, called a media management library, from a tape software vendor.
Oracle ships with an free but scaled down MML from Legato (e.g. the tape drive must reside on
the server). For a list of vendors supplying MMLs visit:
http://otn.oracle.com/deploy/availability/htdocs/bsp.htm.
2.5
Component Releases
Each component has a release or version
Mixing releases can be problematic
For example, assume
Group of 8.1.x production databases targets
Install new 9i database to hold recovery catalog
Want to use 9i RMAN to backup 8.1.x DBs
No Good!
See RMAN compatibility matrix
The versions of the RMAN executable and the target
database should be the same
http://metalink.oracle.com
Each component in the RMAN environment has a release and often they are not the same. For
example, you may have a group of release 8.1.x production (target) databases that you would like to
back up with RMAN. You would like to create a new database to hold you recovery catalog and
choose to install Oracle9i. Finally, to take advantage of the new 9i RMAN features, you would like to
use 9i RMAN to backup your 8.1.x databases. However, this is not valid! You will need to backup
your 8.1.x databases with a 8.1.x version of RMAN. Oracle documentation states The versions of
the RMAN executable and the target database should be the same. So, in fact, you will need
multiple copies of RMAN to backup your mixed release environment.
See the RMAN compatibility guide for more information. Login to Metalink and search on RMAN
compatibility for the latest compatibility guide.
2.6
The control file is actually always used as a repository for RMAN metadata, even if you also use a
recovery catalog. It is the only repository of data if you use RMAN in NOCATALOG mode. See the
NOCATALOG Mode section later in this lesson.
The control file is made up of records or slots. There are 3 types of records in the control file:
Circularly reusable records these records can be overwritten after they are older than value
specified in CONTROL_FILE_RECORD_KEEP_TIME parameter.
Non-Reusable records these records cannot be overwritten.
Persistent Configuration records these records contain the RMAN environment settings. They
are changed with the CONFIGURE command.
Initially, (just after CREATE DATABASE) the records are mostly empty. As activity occurs on the
database, the control file receives information about log switches and archived logs from the log
writer and archive writer background processes. This information is stored in reusable records in the
control file. The CONTROL_FILE_RECORD_KEEP_TIME parameter controls when a reusable
record expires which means the record can be overwritten. The purpose of the CFRKT parameter
is to specify a recovery window how far back in time you would like to be able to recover to.
Tom Kyte of asktom.oracle.com says: set your control_file_record_keep_time to be at least one
day GREATER then the period of time between your backups, else there is a chance that an archive
record gets aged out during the backup which thoroughly confuses the situation.
2.7
The control file become larger as log switches, archiving and backups are performed. The records
generated for log switches and archive logs can be overwritten thus negating the need for the
control file to expand but not until the records are older than the value in the
CONTROL_FILE_RECORD_KEEP_TIME parameter. Thus, this parameter has a direct affect on the
size of the control file.
2.8
CFRKT Parameter...
CONTROL_FILE_RECORD_KEEP_TIME parameter
controls reuse of reusable records
Minimum age in days of a reusable record before it
can be overwritten
Reusable records EXPIRE
Default is 7 days
Maximum 365 days
Minimum 0
Overwritten metadata is lost, unless
Using a recovery catalog and RESYNC catalog prior to
overwrite
More on this later
2.9
...CFRKT Parameter
system@DAVE>
system@DAVE> show
show parameter
parameter control_file_record_keep_time
control_file_record_keep_time
NAME
NAME TYPE
TYPE VALUE
VALUE
------------------------------------
------------------------------------ ----------- ------
----------- ------
control_file_record_keep_time
control_file_record_keep_time integer
integer 77
system@DAVE>
system@DAVE> alter
alter system
system
22 set
set control_file_record_keep_time
control_file_record_keep_time == 30 30
33 comment='30
comment='30 days
days of
of history
history in
in control
control file'
file'
44 scope
scope == both;
both;
System
System altered.
altered.
2.10
The CREATE DATABASE command creates the control file. Several parameters on this command
affect the construction of the control file. For example, the MAXDATAFILES parameter allocates a
fixed number of empty records (slots) to hold information about the datafiles. In this example, we can
add 100 datafiles to this database. The control file would need to be re-created if we later want to
add more datafiles.
2.11
TYPE
TYPE RECORD_SIZE
RECORD_SIZE RECORDS_TOTAL
RECORDS_TOTAL RECORDS_USED
RECORDS_USED
------------------
------------------ ----------- ------------- ------------
----------- ------------- ------------
DATABASE
DATABASE 192
192 11 11
REDO LOG
REDO LOG 72
72 55 33
DATAFILE
DATAFILE 180
180 100
100 66
RMAN
RMAN CONFIGURATION
CONFIGURATION 1108
1108 50
50 00
LOG HISTORY
LOG HISTORY 36
36 226
226 77
OFFLINE RANGE
OFFLINE RANGE 56
56 145
145 00
ARCHIVED LOG
ARCHIVED LOG 584
584 13
13 00
BACKUP
BACKUP SET
SET 40
40 204
204 00
2005-2007 SkillBuilders, Inc.
2.12
Here are some notable comparisons between the CREATE DATABASE on the previous page and
this example:
CREATE DATABASE MAXLOGFILES 5 And the control file contains 5 records of type REDO
LOG. Only 3 are used because the CREATE DATABASE command only specifies 3 log files.
CREATE DATABASE MAXDATAFILES 100 And the control file contains 100 records of type
DATAFILE. Only 6 are used because so far only 6 datafiles have been created.
CREATE DATABASE MAXLOGHISTORY 1 But the control file created 226 records of type
LOG HISTORY. These record information about log switches. This is not documented, but I
believe this is the minimum (and default) for a Windows 2000 system.
Note that only 13 records have been created for ARCHIVED LOGS. There is no documented
control for this on the CREATE DATABASE command. Certainly, we will want to keep history for
more than 13 archived logs. This will happen because additional records will be dynamically added
to the control file, causing the control file size to increase. See the next page for more information.
2.13
The size of the control file will grow in size because of the RMAN data.
If new information needs to be recorded, and all the available slots have been used, RMAN will do
one of the following:
If there are expired records, RMAN will overwrite the expired records. No warnings are given.
If there are no expired records, RMAN will allocate more. This will cause the size of the file to grow.
No warnings are given.
If the LOG HISTORY and/or ARCHIVED LOG section has reached its maximum of 65,535 records
AND there are no expired records, Oracle will begin to overwrite non-expired records, starting at the
oldest record. Warnings are produced in the alert log.
2.14
Not only did my control file grow to 81MB, but we now start to receive warnings that the control file
cannot be expanded further because the log history records section has reached its maximum of
65,535 records.
2.15
The initial number of records allocated for log switches is defined by MAXLOGHISTORY. The
Oracle documentation says that the number of records that can be allocated is limited only by OS file
size limitations or available disk space. This is incorrect. So, if your CFRKT parameter is high, say
for example 300, and the number of log switches is also high, say 350 a day, then in 187 days (350 *
187) or less, you will have a problem. The problem is that your control file will have allocated the
maximum 65535 slots for log switches, and the oldest record has not expired, meaning that Oracle
has nowhere to put the new log switch data.
2.16
We can see here that Oracle will start to overwrite non-expired log records.
Possible Solutions:
Set the CONTROL_FILE_RECORD_KEEP_TIME parameter = 0. This will turn off the expiration
check. Use with caution because non-expired records will be written over. If you are using a
recovery catalog, be sure to resync catalog immediately and frequently. Consider an hourly
scheduled job to resync the catalog.
Increase the size of the log files. This will reduce the number of log switches and archived logs.
2.17
NOCATALOG Mode...
Control file is sole source of backup data
Self-contained RMAN environment
Recommended for
Single database environments
Test and development databases
Recovery catalog databases
Set CFRKT to the maximum number of days that you
would think you would possibly want to go back for
recovery
E.g. Weekly full backups
CFRKT = 15 provides 2 weeks of archive log history
NOCATALOG mode is the default. This means that a recovery catalog will not be used and the
target databases control file is the only repository of RMAN backup information. Oracle
recommends that you use this mode for small, single database environments and development
databases. Environments with many production databases should use CATALOG mode.
Set CONTROL_FILE_RECORD_KEEP_TIME to the maximum number of days that you would think
you would possibly want to go back for recovery.
2.18
...NOCATALOG Mode
Protect control file!
Contains history of backups and archive logs
Needed to RESTORE and RECOVER
Duplex with CONTROL_FILES parameter
Backup frequently
Use 9i AUTOBACKUP feature
In the event of a RESTORE/RECOVERY operation, RMAN relies on the control file for a record of
backups taken when a recovery catalog is not used. What happens if you lose the control file in this
mode? That depends on a few things:
Oracle9i and AUTOBACKUP ON Easy to RESTORE CONTROLFILE. Oracle9i and
AUTOBACKUP OFF Difficult, possibly impossible, to recover.
Note this warning about loss of control files is included in the Oracle8i Backup and Recovery
manual:
WARNING: It is difficult to restore and recover if you lose your control
files and do not use a recovery catalog. The only way to restore and
recover when you have lost all control files and need to restore and
recover datafiles is to call OracleWorldWide Support (WWS). WWS will need
to know:
The current schema of the database.
Which files were backed up.
When the files were backed up.
The names of the backup pieces containing the files.
Overcome this problem by using the Oracle9i control file AUTOBACKUP feature. See the lesson
titled Backup with RMAN for details on using AUTOBACKUP.
2.19
Recovery Catalog...
Tables and views contain metadata
Backup data for 1 or more target databases
Owned by user RMAN
See the RC_ views
Optional
Target database control file also contains recovery metadata
But, some functionality lost:
Cannot store RMAN scripts
Cannot restore to an old incarnation of the database
(see the OPEN RESETLOGS option)
The recovery catalog is a series of tables and view owned by a single user (typically called RMAN).
Via the RMAN REGISTER command, these views are populated with backup and recovery
information for one or more databases.
After creating the catalog in the RMAN schema, you will notice a series of views starting with RC_.
These are the recovery catalog views; these views can be queried for information on backups.
Since the target databases control file also contains this information, this is an optional component.
However, it is recommended.
Using a recovery catalog is optional. The control file of the target database also contains recovery
metadata (in fact, the recovery catalog is populated from information stored in the target databases
control file with the RESYNC CATALOG command). However, though RMAN is still very useful
without a recovery catalog, some RMAN functions are lost. For example, you cannot create and
store RMAN scripts and you cannot restore to an older incarnation of the database. (An incarnation
of the database is created when you open the database with the RESETLOGS option necessary
when a point-in-time recovery is performed.)
2.20
...Recovery Catalog...
The recovery catalog stores information on:
Backup sets and pieces
Image copies
Archived redo logs
Structure of target database
User scripts
2.21
...Recovery Catalog...
Create a separate database to hold RMAN recovery
catalog
On a separate server (with OEM?)
Can create 1 recovery database/catalog for many target
DB1 databases
Target databases RCAT database
The RMAN client application can CONNECT to both a TARGET and a CATALOG (recovery)
database. The target database is the database to be backed up. The recovery database contains a
recovery catalog. The recovery catalog can contain metadata for many target databases.
Create the recovery catalog in a separate database! You do not want to lose the recovery catalog if
you lose your production (target) database you would not be able to recover. A helpful
recommendation that I found on the Oracle Technology Network
(otn.oracle.com/availability/htdocs/9ifaq.html) was to create your recovery catalog in the same
database that contains your Oracle Enterprise Manager repository.
2.22
...Recovery Catalog
Backup recovery catalog database
Consider:
RMAN in NOCATALOG mode
EXPORT
User-managed backups
Increase
CONTROL_FILE_RECORD_KEEP_TIME to
maintain safe restore window
The database that contains the recovery catalog must also be backed up. For the RMAN catalog
database, Oracle suggests using RMAN in NOCATALOG mode (to eliminate the need for a recovery
catalog for the recovery catalog). If you choose this technique, consider increasing the
CONTROL_FILE_RECORD_KEEP_TIME to a larger value so more days of backup data are kept
before being overwritten.
You could also consider:
user-managed backups for the recovery catalog database. (User-managed backups are the
old-style OS copy command backups.)
EXPORT. This is a flexible option because you could restore (IMPORT) the recovery catalog
into any working database for the recovery.
2.23
Recovery Catalog
Maintenance...
RESYNC CATALOG command updates
recovery catalog
Propagate new and changed information into
catalog
Log history
New datafiles
Keeping the recovery catalog updated with the information from the current control file is critical and
is easily accomplished with the RESYNC CATALOG RMAN command. If we never updated the
recovery catalog with metadata from the control file, and we lost the target database and control file,
RMAN would not know, for example, the most recent structure of the database and the that certain
archived logs exist and would not be able to fully recover your database.
RMAN performs automatic resynchronizations whenever you issue a backup command (other
commands as well).
2.24
...Recovery Catalog
Maintenance
Must re-sync before data in control file overwritten!
Check CONTROL_FILE_RECORD_KEEP_TIME parameter
Backup or issue RESYNC CATALOG before CFRKT
parameter value!
Frequency of manual re-sync?
Log switches and archiving can occur frequently
e.g. 1000 log switches before backup taken
Consider scheduling hourly job to resync catalog
Inexpensive operation
Alternative: expensive resync during backup
2.25
Control File
Initial
repository of RMAN metadata
Watch for growth
2.26
Chapters 16 through 18 of the Oracle9i Recovery Manager Users Guide is dedicated to maintaining
and querying the RMAN repository. In the next lesson in this course we will learn and practice
setting up a recovery catalog.
2.27
2. Assume you have twelve Oracle databases that you are responsible for backing up. They
range in release from 7.3 to 9.1. All can be reached from your workstation via SQL*Net.
Answer the following questions:
1. Q. How many copies of the RMAN executable will you use?
2. Q. Where will you install the RMAN executables?
3. Q. Will you use a Recovery Catalog? Why?
3. Assume that you have one Oracle 9.0.1 database to backup, and only one machine at your
disposal. Answer the following questions:
1. Q. Will you use a Recovery Catalog? Why?
2. Q. If you decide to backup every 7 days, what value will you set the
CONTROL_FILE_RECORD_KEEP_TIME parameter to?
4. Look in the alert log on your sample database for the CREATE DATABASE command. What
are the following set to:
1. MAXLOGHISTORY:
2. MAXLOGFILES:
3. MAXDATAFILES: