Symantec NetBackup 7.x For Oracle GUIDE

CONFIDENTIAL - NOT FOR DISTRIBUTION
Symantec
NetBackup 7.x for
Oracle for UNIX
200-002674
COURSE DEVELOPER
Lisa Childress
LEAD SUBJECT MATTER
EXPERTS
Geoff Bergren
Dustin Scharf
TECHNICAL
CONTRIBUTORS AND
REVIEWERS
Copyright 2011 Symantec Corporation. All rights reserved.
John Gerhardson
Lisa Goldring

Symantec, the Symantec Logo, and VERITAS are trademarks or
registered trademarks of Symantec Corporation or its affiliates in
the U.S. and other countries. Other names may be trademarks of
their respective owners.
THIS PUBLICATION IS PROVIDED AS IS AND ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS
AND WARRANTIES, INCLUDING ANY IMPLIED
WARRANTY OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH
DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR
INCIDENTAL OR CONSEQUENTIAL DAMAGES IN
CONNECTION WITH THE FURNISHING, PERFORMANCE,
OR USE OF THIS PUBLICATION. THE INFORMATION
CONTAINED HEREIN IS SUBJECT TO CHANGE WITHOUT
NOTICE.
No part of the contents of this book may be reproduced or
transmitted in any form or by any means without the written
permission of the publisher.
Symantec NetBackup 7.x for Oracle for UNIX
Symantec Corporation
World Headquarters
350 Ellis Street
Mountain View, CA 94043
United States
http://www.symantec.com
Table of Contents
Course Introduction ................................................................................... Intro-1
Lesson 1: Oracle Concepts
Oracle architecture ...................................................................................... 1-4
Oracle instance ......................................................................................... 1-22
Environment variables and functions ........................................................ 1-25
Database queries ...................................................................................... 1-39
Oracle alert log and trace files ................................................................... 1-41
Lesson 2: Database Backup and Restore Fundamentals
Database failures ......................................................................................... 2-4
Database backup types.............................................................................. 2-19
Protecting your databases ......................................................................... 2-26
Lesson 3: NetBackup Essentials
The NetBackup environment ....................................................................... 3-4
NetBackup concepts ................................................................................. 3-13
NetBackup notify scripts ............................................................................ 3-26
Lesson 4: RMAN Concepts and Backup Operations

RMAN architecture ...................................................................................... 4-4
RMAN commands ....................................................................................... 4-9
RMAN backups ......................................................................................... 4-19
RMAN configuration .................................................................................. 4-41
The RMAN recovery catalog ...................................................................... 4-45
Lesson 5: Performing Backups Using NetBackup for Oracle with RMAN

Verifying NetBackup for Oracle requirements ............................................. 5-4
Configuring NetBackup for Oracle with RMAN ............................................ 5-7
Configuring a NetBackup for Oracle policy ............................................... 5-12
Managing the runtime environment ........................................................... 5-25
Using shell scripts ...................................................................................... 5-31
The NetBackup for Oracle backup wizard.................................................. 5-35
Testing the NetBackup for Oracle configuration ........................................ 5-42
Lesson 6: Simple Restore and Recovery Operations
Restore operations ....................................................................................... 6-4
Shell scripts and templates ........................................................................ 6-13
Lesson 7: RMAN Recovery Catalog Management
Recovery catalog maintenance .................................................................... 7-4
Storing scripts .............................................................................................. 7-9
Querying the recovery catalog ................................................................... 7-11
Managing the repository............................................................................. 7-15

Table of Contents
iii
Backing up and recovering the recovery catalog ....................................... 7-28

Lesson 8: Advanced RMAN Recovery Topics
Recovering critical files ................................................................................. 8-4
Incomplete recovery ................................................................................... 8-10
Database recovery challenges ................................................................... 8-18
Redirecting restores ................................................................................... 8-22
Guided application recovery ...................................................................... 8-26
Using the guided application recovery wizard ........................................... 8-30
Lesson 9: RMAN Management and Monitoring
RMAN tuning ............................................................................................... 9-4
Appendix: Labs

iv

Intro-1
Lesson introduction
This introduction provides a high-level abstract of the Symantec NetBackup 7.x
for Oracle course, including its intended audience and instructional objectives.
Importance
Before exploring the particulars of this course, you should understand for whom
it is intended and the tasks it addresses.
Intro-2
Course objectives
This course describes the proprietary backup functionality of Oracles RMAN,
how it is used to back up and restore Oracle database components, and how
NetBackup for Oracle enhances RMANs capabilities.
Importance
Oracle database backup

p and recovery
y is an inherently
y challenging
g gp
process that
becomes more difficult as databases grow in size and as increasing demands
on database availability limit the time available to perform backups. Mastering
this course will enable database and system administrators to create and
administer backup and recovery plans specific to their needs.
The integration of Oracles Recovery Manager (RMAN) with Symantec

NetBackup 7.x for Oracle (NBUO) provides the facilities to perform enterprisewide storage management. This course offers comprehensive instruction of
Oracle database backup, restore, and recovery using RMAN and Symantec
NBUO, and provides you with the knowledge and skills to effectively deploy
these tools in support of your enterprise business continuity plan.
Intro-3
Intended audience
This course traditionally enrolls two distinct audiences:
Database administrators (DBAs) responsible for the maintenance of Oracle

databases within their enterprise environment
This group may already be familiar with RMAN.
UNIX system administrators

administrators, system engineers
engineers, technical support personnel
personnel,
and system integration staff responsible for the backup and recovery of
systems within their enterprise environment
This group is usually familiar with Symantec NetBackup, but may not be
familiar with Oracle or RMAN.
This course is designed with consideration to both audiences, although a basic

familiarity with Symantec NetBackup is expected.
Note: This course uses Oracle 10g. Materials and labs instruct to this version of
Oracle.
Intro-4
Course prerequisites
This course builds on concepts introduced in the Symantec NetBackup 7.x
Administration for UNIX course.
Students attending as DBAs should be familiar with Oracle database
administration. Familiarity with NetBackup 7.x is expected.
Students attending as system administrators should be familiar with the

administration and configuration of a UNIX or Linux environment, including
experience developing shell scripts. Experience administering NetBackup 7.x,
particularly the management of backup policies, is expected.
Crossover knowledge between these areas (database administration and

system administration) is desirable.
Knowledge of Oracle 10g is desirable, but not required.
Intro-5
10
Intro-6
11
1-1
Overview
This lesson describes the essential files and processes that comprise an Oracle
database and how Oracle uses them for data storage.
Importance
A knowledge of the structure and storage concepts that underline an Oracle

provides a basis on which to build an understanding
g of the p
procedures
database p
necessary to back up, restore, and recover a database.
12
1-2
Lesson topics and objectives
After completing this lesson, you will be able to describe the underlying
architecture of an Oracle database with an understanding of how it relates to the
backup and restore process. You will also be able to perform fundamental tasks
that are required as you move into backup and restore functions later in the
course.
13
1-3
This is Topic 1: Oracle architecture.
After completing this topic, you will be able to identify the components of an
Oracle database.
14
1-4
Oracle architecture
A user interfaces to an Oracle database through a front-end application process
that communicates in a client/server relationship with an Oracle server process.
The Oracle server process executes the user or application requests upon the
database.
As illustrated in the diagram, an Oracle database consists of three primary

components:
t background
b k
d processes, system
t
memory known
k
as the
th System
S t
Global Area (SGA), and various disk files.
15
Each component performs specific functions and can have particular

relationships to the other components. These functions and relationships are
explained in this lesson.
1-5
16
Disk: Data files

Every database has one or more physical data files. The data files contain a
physical copy of the user data and the data dictionary, which is the description of
the structure of the user data.
Within the database, user data is organized logically into tablespaces. A
tablespace is a collection of one or more data files.
A data file can only contain data for a single tablespace
tablespace.
A data file is structured into data blocks, which are the smallest units of space
within an Oracle database. All read and write actions performed upon a
database occur at the block level. The first data block of a data file contains the
data file header. This includes information such as the size of the data file, the
block size, tablespace, creation timestamp, and system change number (SCN).
The SCN is an internal Oracle number that increments over time as changes are
made to the redo log.
An extent is a contiguous set of data blocks obtained in a single allocation, and
a segment is a collection of all extents for a specific structure. There are
different types of segments, including data segments, index segments, and
rollback segments.
NetBackup for Oracle with RMAN can back up entire databases, individual
tablespaces, or individual data files. It is not possible to back up lower-level
structures such as blocks, extents, or segments.
1-6
Disk: Redo log files
Every database has two or more redo log files. The complete set of redo log files
for a database is collectively known as the databases redo log. The primary
function of the redo log is to record all changes made to the database. If a
failure prevents modified data from being written permanently to a data file,
changes are still available from the redo log. Therefore, data is never lost.
17
The redo
Th
d llog iis critical
iti l iin protecting
t ti a d
database
t b
against
i t ffailure.
il
Th
The iinformation
f
ti
in the redo log is used only to recover the database from a system or media
failure that prevents data from being written to a databases data files. The
process of applying the redo log during a recovery operation is called rolling
forward.
Data is written to the redo log files sequentially. When one log file is filled, the
next one is used. After the last redo log is used, Oracle cycles back to the first
log file.
When a set of changes to the database is committed, Oracle generates a new
redo log record and assigns an SCN to the set of changes.
There are two categories of redo log files: online and archived.
1-7
Online redo log files
Oracle generates online redo log files by default. These are simply another
name for the redo log files.
Archived redo log
g files
Archived redo log files contain redo entries and are copied to one or more
archive destinations before reuse.
If the database runs in ARCHIVELOG mode, online redo logs are archived
before reuse, and the database can be fully recovered from both application and
hardware failures. The database can also be backed up when it is open.
g are not archived, and
If the database is in NOARCHIVELOG mode, redo logs
the database can only be consistently backed up when it is closed after a clean
shutdown.
Maintaining archived redo log files is optional, but it is highly recommended.
Redo logs, together with archived redo logs, contain all committed transaction
information since the last backup. To perform a complete restore and recovery
of a database, first restore from backups; next recover from archived redo logs;
finally use the online redo logs used since the last backup
backup.
Redo log groups
Redo logs can be organized into groups. You can define one or more redo logs
as members within a group. Multiple members within a redo log group provide
for the mirroring of redo logs at the Oracle level. There must be at least two redo
log groups.
When a redo group is filled
filled, Oracle performs a checkpoint and then proceeds to
use the next group. A checkpoint causes all the modified contents of the buffer
cache to be flushed out to disk. When all redo log groups have been used,
Oracle cycles back to use the first group and overwrites the previous groups
contents.
Redo log members in each group should be spread across multiple disks,
preferably disks mounted under separate disk controllers. This prevents data
l
loss
if a di
disk
k containing
t i i th
the online
li redo
d llog groups ffails
il or if a di
disk
k controller
t ll
fails.
18
1-8
Disk: Rollback structures

Rollback segments are used to store undo records for uncommitted
transactions.
An undo record represents the before image of a block that is safely stored in
rollback segments before an application is allowed to change it. Undo records
are used to return blocks to a previous consistent state in the following
situations:
it ti
19
When an application issues a rollback statement, undo records are used to

roll back uncommitted changes to the database.
During database recovery, undo records are used to undo any uncommitted
transactions in progress at the time of the database failure.
Redo records also provide read consistency by retaining a consistent or before

i
image
off records
d for
f users simultaneously
i lt
l attempting
tt
ti to
t access the
th same
blocks. If one user is attempting to change the block, other users accessing the
same data view the before image instead of the uncommitted changes.
Undo tablespaces
In more recent versions of Oracle, Undo Tablespaces provide another, less

complex option for storage of undo records.
1-9
20
Disk: Control files

Every Oracle database has a control file. The control file records the physical
structure and attributes of the database, including:
A list of the path names of the files that comprise the database
The database name
The names and locations of the data files and redo log files
The database creation timestamp
The current log sequence number
The state of the data files
The time period covered by each archived redo log
The control file is always open while the database is in use. Consequently, you
cannot consistently back up active control files. Instead, Oracle provides a
mechanism for producing a consistent, inactive copy of the control file, which
you can back up.
During database recovery, the control file is used to guide the automated
progression of the recovery operation.
To ensure database protection, maintain at least two copies (or mirrors) of the
control file.
1-10
Disk: Parameter files

The parameter file is read when the database is started. This file specifies
database configuration parameters, such as how much memory the database
uses, and the location of other critical database files. The parameter file is often
referred to as the init.ora file.
Beginning with Oracle9i, there are two types of parameter files:
21
A PFILE (Parameter FILE), the traditional type of parameter file, is an

ordinary text file that can be directly modified with a text editor. The
parameters it contains are only read at database startup and any changes
the DBA makes to a running database using the ALTER SYSTEM command
are not automatically written to the PFILE. The PFILE must be updated
manually for changes to be persistent across database shutdowns and
startups.
An SPFILE (Server Parameter FILE) is a binary file initially built from a

PFILE using the CREATE SPFILE statement. For example:
$CREATE SPFILE=/oradata/admin/ORCL/pfile/spfileORCL.ora
FROM PFILE=/oradata/admin/ORCL/pfile/initORCL.ora
Unlike a traditional PFILE, any changes made to the database using the ALTER
SYSTEM statement are automatically reflected in the SPFILE; therefore, manual
updates are not necessary for persistent changes
changes.
1-11
Viewing parameter settings
To view parameter settings in the PFILE, use any text editor to open the file and
view it.
g an editor to view settings
g in the SPFILE is not recommended
However,, using
because of the danger of accidently corrupting the file. Because database
startup fails if the SPFILE is corrupted, it is recommended to use an alternate
method.
View parameter settings in the SPFILE using:
The SHOW PARAMETERS command from SQL*Plus

Examples:
p
SQL> SHOW PARAMETERS large_pool_size
NAME
TYPE
VALUE
large_pool_size
Biginteger
8388608
SQL> SHOW PARAMETERS shared_pool_size

shared pool size
NAME
TYPE
VALUE
shared_pool_size
Biginteger
33554432
The V$PARAMETER dynamic view

Examples:
p
SQL> SELECT name, value FROM v$parameter

WHERE name = control_files;
22
NAME
VALUE
control_files
/oracle/oradata/CONTROL01.CTL,
/oracle/oradata/CONTROL02.CTL,
/oracle/oradata/CONTROL03.CTL
Note: You can also use the V$SPPARAMETER view to determine if you are
using a PFILE: if the "value" column is NULL for all parameters, you are using a
PFILE.
1-12
DISK: The password file

A databases password file can be used as an alternative to operating system
identities for controlling access to administrative functions within the Oracle
database. A password file is optional for a database except in cases where
remote users connect through Oracle Net with administrative privileges.
1. As the Oracle user, use the orapwd utility to create a password file, as
f ll
follows:
$orapwd file=filename password=password entries=max_users
23
The filename is the name of the password file. The path defaults to the current
directory unless a full path is specified in the command. The password is the
password for the SYS user of the database. The max_users value is the
number of users that can be granted SYSDBA or SYSOPER.
2 Edit th
2.
the parameter
t file
fil and
d ensure th
the remote_login_passwordfile
l i
dfil is
i
set to EXCLUSIVE. When this parameter is set to SHARED, the password
file can be used by multiple databases, but only the SYS user is recognized.
If this parameter is set to EXCLUSIVE, only one database can use the
password file, but multiple users can exist (in addition to SYS).
3. Add users and grant them SYSDBA or SYSOPER privileges. The information
is automatically added to the new password file.
1-13
Memory: System Global Area (SGA)

A System Global Area (SGA) is allocated in memory when a database is started;
the SGA is deallocated when a database is shut down. Users that connect to the
database share the data in the SGA. The SGA contains several memory
structures including the shared pool, the database buffer cache, and the redo
log buffer.
Server processes
A server process is created when a user runs an application.
Oracle creates a separate server process to service requests from each

individual user application process.
24
The server process reads data from the data files into the buffer cache within
the SGA where it performs transactions by modifying the contents of the buffer
cache.
cache
When changes are made to blocks within the buffer cache, Oracle copies the
original contents of the blocks into rollback segments (or tablespaces) before
applying the changes. This enables an incomplete transaction to be rolled back.
1-14
Memory: Database buffer cache

Data blocks are retrieved from the data files on disk and placed in the SGA
database buffer cache before they are accessed by the user. Using the principle
that the most recently accessed data is often also the most frequently used, the
buffer cache improves I/O performance by reducing I/O required to retrieve
frequently accessed blocks.
Blocks
Bl
k are modified
difi d iin th
the b
buffer
ff cache
h b
before
f
th
the changes
h
are written
itt tto th
the
datafiles on disk. Periodically, all the modified buffers are written to the datafiles
in system events called checkpoints.
25
Buffers are also written to disk between checkpoints if space is needed in the
buffer cache for new data blocks. When space is needed for new data blocks,
Oracle uses a least recently used (LRU) algorithm to manage the aging of data
buffers out of the buffer cache.
The size of the database buffer cache is initially determined by the database
block size parameter DB_BLOCK_SIZE and by the number of blocks cached in
memory, as indicated by the parameter DB_BLOCK_BUFFERS. However,
memory structures are dynamically tuneable as of Oracle 9i.
1-15
Memory: The shared pool

The shared pool caches various constructs that can be shared between users.
Entries in the shared pool include SQL statements, stored procedures, and
cached data dictionary information.
An SQL program requires an entry in the shared pool before it can execute.
The shared SQL area:
26
Processes identical SQL statements
Contains the text of SQL or PL/SQL (stored procedure) statements
Contains the parsed form of the SQL or PL/SQL statements
Contains the Execution plan for SQL or PL/SQL statements
Information about SQL p

programs
g
can be shared with other users of the
database. This sharing places less demand on shared memory, freeing shared
memory for other uses.
The data dictionary is the metadata that describes the structure of the database.
Oracle uses a least recently used (LRU) algorithm to manage the shared pool.
When structures, such as execution paths, in the pool are not accessed for a
while they can be aged out of the shared pool to make room for new structures
coming
i iin.
1-16
Memory: Redo log buffers

The redo log buffers hold database change records before they are written to
the online redo logs on disk.
Redo log buffers improve database performance by reducing the I/O required to
maintain a consistent record of changes. However, redo log buffers are flushed
to the online redo logs during checkpoints and any time modified data buffers
are flushed
fl h d to
t the
th datafiles
d t fil on disk.
di k To
T ensure transaction
t
ti information
i f
ti is
i safely
f l
stored on disk in the event of database failure, the contents of the redo log
buffers are always flushed before the data buffers.
27
All completed transactions at the time of a failure can be replayed by restoring

the database from backups and then processing the records from the archived
and online redo logs.
The size of the redo log buffer is determined by the LOG
LOG_BUFFER
BUFFER initialization
parameter.
1-17
Processes: The database writer process (DBWR)

The DBWR process is responsible for writing modified blocks in the database
buffer cache to the physical data files on disk.
Circumstances that cause the DBWR process to write modified blocks include:
28
Performing a checkpoint
The DBWR process updates the datafile contents with committed
transactions within the redo log.
Freeing up space in the buffer cache

The DBWR process writes the least recently used blocks first.
Tablespace taken off line in normal or immediate mode
Dropping or truncating a table
Online back
backup
p performed on a tablespace
1-18
Processes
The log file writer process (LGWR)
All changes made to data blocks in the database buffer cache are recorded in
the redo log buffer. At certain times, the LGWR process writes the transaction
information recorded in the redo log buffers to the online redo logs. Events that
force the redo log buffers to flush include:
29
Oracle commits a transaction.
The redo log buffer reaches one-third full.

If there is more than 1 megabyte (MB) of redo changes in the redo log buffer,
LGWR automatically writes that information to the redo logs.
Checkpoints
y one LGWR process

p
p
per instance.
There is only
DBWR always signals LGWR to flush the redo buffer before it writes data back
to the data files.
The archive process (ARCH)
ARCH is an optional process that copies the contents of the online redo log to
an archive log file that you can then back up. In order to run ARCH, the
database must run in ARCHIVELOG mode.
1-19
Processes: Other Oracle processes

The system monitor process (SMON)
SMON performs instance recovery when an instance is started after a failure.

This process also monitors and reorganizes free space within the data files.
The process monitor process (PMON)
PMON monitors user processes accessing the database and cleans up after
abnormal termination of a user process.
The checkpoint process (CKPT)
30
Whenever changes in the buffer cache are permanently recorded in the

database, CKPT updates database status information in the control files and
data files.
The recoverer process (RECO)
RECO resolves failed transactions in a distributed Oracle environment. When a

network or node failure occurs, some transactions are put in an in-doubt state.
The RECO process works to establish communication with remote servers and
then automatically resolves all in-doubt transactions.
1-20
Checkpoints
Checkpoints are critical Oracle system events that provide a point of database
consistency that is the basis for recovery operations.
Some of the events that trigger checkpoints include:
31
Redo log switches
The LOG_CHECKPOINT_TIMEOUT
LOG CHECKPOINT TIMEOUT parameter in the parameter file
The FAST_START_MTTR_TARGET parameter in the parameter file

This parameter replaces the old LOG_CHECKPOINT_INTERVAL parameter,
although it may still be used.
Hot tablespace backups
1-21
This is Topic 2: Oracle instance.
After completing this topic, you will be able to describe an Oracle instance and
the basics of its operation from a storage perspective.
32
1-22
Oracle instance description

An Oracle instance is a set of shared memory and processes that enable you
and other users to access the database.
An Oracle instance consists of the System Global Area (SGA) and a collection
of background processes.
Usually, there is one instance per database. However, Oracle Real Application
Clusters (RAC) allow multiple instances per database. This enables higher
performance access to the database on loosely coupled computer architectures.
33
1-23
Oracle architecture summary
The following files comprise the Oracle architecture:
34
Data files
Redo log files
Archive Redo log files
Control files
Rollback segments or undo tablespaces
Parameter file (initSID.ora or spfileSID.ora)
Password file (optional)
The following processes comprise the Oracle architecture:
DBWR
SMON
PMON
CKPT
LGWR
ARCH
1-24
This is Topic 3: Environment variables and functions.
After completing this topic, you will be able to:
35
Identify the variables critical to installing Oracle.
Describe how an Oracle database is administered.
1-25
The Oracle environment: UNIX/Linux

Oracle is usually installed by the UNIX/Linux ORACLE user, whose primary
group is DBA. In addition, subsequent administrative tasks on the database are
typically performed by the ORACLE user. The UNIX/Linux environment must be
set up correctly prior to running any Oracle utilities. Perform this setup by
running a shell script as part of the UNIX or Linux login process.
Th ffollowing
The
ll i environment
i
t variables
i bl are critical:
iti l
36
ORACLE_BASE defines the path to the base directory for the Oracle
installation. An example is /opt/oracle.
ORACLE_HOME defines the path to the Oracle system home directory. An

example is /u01/oracle. This directory contains all of the subdirectories
and files used by the Oracle installation.
ORACLE SID d
ORACLE_SID
defines
fi
th
the O
Oracle
l server system
t
id
identifier
tifi (SID).
(SID) Th
The SID
uniquely identifies a specific Oracle instance. For single instance databases,
the SID is probably the same as the database name.
1-26
Database administration
You perform database administration using SQL*DBA commands.
To perform database administration, connect to the database using a database
account that has database administrator (DBA) privileges.
By default, two database accounts with DBA privileges are created for each
database. These accounts are SYS and SYSTEM.
The SYS account owns all of the critical database tables, which are
automatically updated during database operation. Do not alter these tables
manually.
37
The SYSTEM account does not own any table by default. Use this account to
create tables and views that contain general database or user data.
1-27
SQL*Plus: Normal operations

SQL*Plus is used to perform normal operations on an Oracle database. Invoke
SQL*Plus by typing the following command at the Oracle command line:
$> sqlplus
Log on to a started database using SQL*Plus using one of the following methods:
Type the username and password individually when prompted
Type the username/password pair directly on the command line when you invoke
SQL*Plus.
The following examples invoke SQL*Plus for a user system whose password is
manager:
38
Example 1
$> sqlplus
Enter user name: system
Enter password: manager
SQL>
Example 2
$> sqlplus system/manager
SQL>
1-28
SQL*Plus: Database startup

Using SQL*Plus to start a database requires the use of the /nolog command
switch to enable SQL*Plus to start without connecting to the database first.
The database you start must have a remote password file if you are connecting
remotely using SQLNet.
The following construct enables you to log on with administrator privileges and
start the database:
connect username/password as admin_role
39
The first example on the slide invokes SQL*Plus without starting the database,
connects to the database as user SYS with DBA privileges (using the remote
password change_on_install), and starts the database.
The second example on the slide shows a user connecting using OS
credentials.
1-29
Remote access: Oracle Net

Remote access to a database is supported by Oracle Net, a protocolindependent communication service that supports client/server interactions.
Oracle Net enables transparent connection from client tools to a database or
from one database to another.
The setup of the Oracle Net service requires the configuration of a listener
service
i on th
the d
database
t b
server and
d configuration
fi
ti fil
files on b
both
th th
the client
li t and
d th
the
server.
To log on to a remote database instance, use SQL*Plus and provide the location
of the server as it is configured in the tnsnames.ora file.
40
1-30
Oracle Net: The listener

A listener process is required for remote database connections. The purpose of
the listener is to monitor an assigned port for incoming database connections
and route the user connection to the correct SID.
The listener process is configured by creating the

$ORACLE_HOME/network/admin/listener.ora file on the system hosting
th database
the
d t b
server. Among
A
other
th things,
thi
th
the listener.ora
li t
fil iincludes
file
l d SID
and port information used by the lsnrctl utility when it starts the listener
service. To start the listener service manually, use the following command line:
$lsnrctl start <SERVICENAME>
41
1-31
Oracle Net: The tnsnames.ora file

The $ORACLE_HOME/network/admin/tnsnames.ora file must be
configured on the client attempting to establish a connection with a remote
database. It contains a list of SIDs with host and port connection information that
correspond to entries configured in the listener.ora file on the database
server.
Users can establish
U
t bli h a connection
ti tto th
the remote
t d
database
t b
with
ith a connectt string
ti
that specifies their user credentials and the correct SID.
For example:
$sqlplus lchildre23/mypassword@RMANCAT
42
SQL*Plus looks up the requested SID in the connect string in the

tnsnames.ora file to find the database server host and connection information
needed
d d tto make
k th
the remote
t connection.
ti
1-32
Starting and stopping an Oracle database
An Oracle database exists in one of four modes.
43
Shutdown
All files are closed and the instance is not started.
Nomount
The instance is started,, but no files are opened.
p
Use startup
p nomount
when first creating the database or restoring the control file.
Mount
The instance is started and the control file is opened. No other files are open.
Use startup mount for DBA operations, such as recovery or changing
between archivelog mode and noarchivelog mode.
Open
Th instance
The
i t
is
i started,
t t d the
th control
t l file
fil is
i opened,
d and
d allll other
th fil
files are
opened. Use startup open for normal startup of a database. Open is the
default parameter to start up.
1-33
Database startup modes
This diagram illustrates the processes Oracle undertakes when each of the
three startup commands runs.
44
1-34
Database shutdown: Normal
There are four ways to shut down the database.
45
Normal
Immediate
Transactional
Abort
The shutdown normal command waits for connected users to end their
sessions normally. This method also enables all running processes to terminate
normally. During a backup, the start of the backup may be delayed or blocked if
a user does not log off.
1-35
Database shutdown: Immediate

The shutdown immediate command terminates any currently executing SQL
statements and rolls back any uncommitted transactions.
Database shutdown: Transactional
The shutdown transactional command waits until all current transactions

complete, prevents new transactions from beginning, and disables new
connections from being made. After all transactions complete, the instance
shuts down in the same way as with the shutdown immediate command.
46
1-36
Database shutdown: Abort

This command provides the fastest possible shutdown. This method terminates
all processing and results in an inconsistent database.
An inconsistent database is one in which changes recorded within the redo logs
are not committed to the database.
y execute a shutdown normal or shutdown

Byy contrast,, when you
immediate command, the changes are committed to the database before it is
closed, and therefore, the database is consistent.
47
1-37
Summary of shutdown modes
The slide on this page shows a summary of the shutdown modes that are
discussed in this topic.
48
1-38
This is Topic 4: Database queries.
After completing this topic, you will be able to query an Oracle database about
its structure.
49
1-39
Querying the database structure

You can determine the locations of files and their relationship to the database
structure by using v$ views. This is helpful when deciding which pathnames to
back up.
To query the pathnames of data files:

SQL>SELECT
Q
name FROM v$datafile;
$
;
50
To query the pathnames of data files by tablespace:

SQL>SELECT t.name Tablespace, f.name datafile
FROM v$tablespace t, v$datafile f
WHERE t.ts# = f.ts#
ORDER BY t.name;
To query pathnames of online redo log files:

SQL>SELECT * FROM v$logfile;
To query the names and pathnames of control files:

SQL>SHOW PARAMETERS control_files;
1-40
This is Topic 5: Oracle alert log and trace files.
After completing this topic, you will be able to use the Oracle alert log and
Oracle trace files when debugging an Oracle environment.
51
1-41
The Oracle alert log

The Oracle alert log is created at the same time you create a database and
contains important information about the status and health of the Oracle
database.
The location of the alert log is configured using the background_dump_dest
parameter in the parameter file but you can locate it quickly using the following
SQL*Plus query:
SQL*Pl
SQL> SELECT value FROM v$parameter

WHERE name = background_dump_dest;
52
The alert log is continually updated with information about actions such as:
Database startup and shutdown
Recovery Actions
Log Switches
DDL statements
Error conditions and location of trace files
1-42
Oracle trace files

Oracle trace files are created automatically when an internal error occurs. The
creation of trace files is documented in the alert log along with the Oracle error
number and the name and location of the trace file created.
Trace files, such as the alert log, are not automatically purged and must be
managed by the DBA to prevent disk space problems.
53
1-43
Lesson summary
This lesson covered the basic architecture, functions, and processes of an
Oracle database. It also described the methods of starting and stopping an
Oracle database, how to query the database about its structure, and how to use
the Alert Log and trace files to debug errors.
Reference materials
54
Kevin Loney and Bob Bryla. Oracle Database 10g DBA Handbook.
Emeryville, CA: The McGraw-Hill Companies, Inc., 2005.
The Symantec support web site at:

http://www.symantec.com/business/support
1-44
55
2-1
Lesson introduction
This lesson describes the fundamentals of backing up and recovering a
database.
Importance
A knowledge of the fundamental concepts and processes for database backup

yp
provides an essential context for the remainder of the course.
and recovery
Oracles Recovery Manager (RMAN) is the integrated utility in Oracle that

handles backup and recovery functions.
56
Symantec NetBackup for Oracle (NBUO) is an extension package to Symantec

NetBackup (NBU). NBUO functions as a media manager to RMAN, enabling
RMAN to write to and read from robotic tape devices. NBUO also handles
backup scheduling functions.
2-2
After completing this lesson, you will be able to describe the most common
causes and corresponding consequences of database failure. With that
knowledge, you will be able to outline the different methods and types of
database backup, the strengths and weaknesses of each, and the necessary
components for each method.
57
2-3
This is Topic 1: Database failures.
58
Identify the types of database failures.
Determine how to successfully recover an Oracle database.
Describe the recovery methods used to recover a database.
2-4
Types of database failures

Oracle databases can fail for a variety of reasons. Some failures result from
internal errors within the database; others, from external variables. Knowing the
types of failures can help you determine appropriate recovery strategies.
Statement failure
A statement failure results from a syntax error within a SQL statement.

The consequence of this failure is that the intended changes representing
the transaction cannot be completed. The database exists in a partially
updated state.
59
Application process failure/network failure

An application process failure results from a failure of the application process
or its communication path with the database server. The latter type of
application
li ti failure
f il
is
i called
ll d a network
t
k failure.
f il
Th
The d
database
t b
iis lleft
ft iin a
partially updated state.
Instance failure
An instance failure follows the failure of either the System Global Area (SGA)
or the background processes. Changes to the contents of the SGA buffer
cache may not be written to the data files.
2-5
User or application failure

A user or application failure stems from an error committed by a database
user or from an error within the logic of an application. Such a failure can
result in the destruction or corruption of data in the database. Examples of
thi type
this
t
off failure
f il
are:
o The deletion of a table from the database
o A user accidently deleting the wrong records
Media failure
Media failure is an external failure caused by the crash of the media or the
physical device containing the media that store the files that support the
database. An example of this type of failure is a hard drive crash that results
in the loss of data from a tablespace.
60
2-6
Requirements for recovering a failed database
Note: For the purposes of this lesson, the terms restore and recover are defined
as follows (from the Oracle Backup and Recovery Guide):
61
Restore is defined as the replacement of a lost or damaged file with a

backup. In some situations, a restore can occur without the need for
recovery.
Recovery is defined as the application of redo data or incremental backups

to database files in order to reconstruct lost changes. Whenever recovery of
a database is necessary, the database must first be restored.
The successful recovery of an Oracle database depends upon the successful

backup of critical files. When you develop a backup strategy, you should plan to
include the following files:
D t fil
Datafiles
The Oracle datafiles contain your critical user data.
Control File
The control file is a binary file that contains information required to maintain
and verify database integrity. Every time an Oracle instance mounts a
database, the control file is read to locate data and redo log files. All control
fil are updated
files
d t d continuously
ti
l d
during
i d
database
t b
use.
2-7
Online redo logs

Redo logs are a set of two or more files that actively record all changes
made to an Oracle database. A database must have at least two redo log
files. Log files can be multiplexed (mirrored) on multiple disks to ensure that
they are not lost.
Archived redo logs

Archived redo log files are log files that have been backed up along with a
previous version of a database. These point-in-time files list the actions that
occurred in the backed-up database. They are neither active nor current.
Parameter file
The parameter file contains all parameter settings for the Oracle database.
Oracle password file

The Oracle password file contains user names and passwords necessary for
database administration and other related functions.
Oracle directory structures
The Oracle directory structures containing the Oracle software and binaries
are also critical for successful recovery of a database in the event of
complete system failure.
62
2-8
Managing datafiles
Managing your datafiles requires thought and planning. Before you configure a
NetBackup policy to back up your Oracle databases, determine your backup
strategy:
Should you perform physical or logical backups of your datafiles?

Physical backups can be performed with NetBackup alone or RMAN alone.
63
Should you perform hot or cold backups?

Cold backups can be performed with NetBackup alone, but require you to
shut down the database for a consistent backup. Hot backups can be
performed without shutting down the database but require RMAN.
Should you perform full backups only or full backups plus incremental
backups?
Full backups every time are ideal for fast, easy restores, but can be too timeconsuming to be practical. Larger databases usually require incremental
backups.
These backup strategies are described on the following pages.

Disaster recovery policies are beyond the scope of this course but are critical for
proper datafile management. Duplication of critical backups and offsite storage
are a few of the disaster recovery issues you need to consider.
2-9
Managing the control file

It is recommended that you maintain multiple copies of the control file. In the
initSID.ora parameter file, specify the multiple control file copies:
control_files = (/db/MYDB/data/control1.dbf, /db/MYDB/
data/control2.dbf)
It is also recommended that you back up the control file after every change to
the physical structure of the database. Examples of commands that result in
structural changes are:
ALTER DATABASE [ADD|DROP] LOGFILE
64
ALTER DATABASE [ADD|DROP] LOGFILE MEMBER

ALTER DATABASE [ADD|DROP] LOGFILE GROUP
ALTER DATABASE [ARCHIVELOG|NOARCHIVELOG]
ALTER DATABASE RENAME FILE
CREATE TABLESPACE
ALTER TABLESPACE [ADD|RENAME] DATAFILE
ALTER TABLESPACE [READ WRITE|READ ONLY]
DROP TABLESPACE
2-10
Backing up the control file
Because the control file is open when the database is open, a normal file backup
is not possible while the database is up. However, Oracle provides two methods
for hot control file backups.
p
Back up to binary file

You can create a binary backup copy of the control file by using the
statement:
ALTER DATABASE BACKUP CONTROLFILE
TO '/oracle/backup/control1.bak' REUSE;
This statement creates a binary copy of the control file using the pathname
specified. You can then back up the control file to offline storage by copying
the backup control file. The REUSE parameter indicates that an existing file
with the same filename can be overwritten.
Binary copies of the control file contain RMAN metadata about your backups
and archived redo logs. This is not the case when you back up the control
file to a trace file.
Back up to trace file

Backing up the control file produces an SQL script that enables the control
file to be reconstructed in case of a loss or corruption of the control file.
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
However, restoring a control file from a trace file renders any previous
backups and archived redo logs of the database unusable; the checkpoint
and the system change number (SCN) information now differ. That is, the
header information in the data files and the control file is no longer
synchronized. Therefore, it is recommended that you back up the database
again immediately after recovery.
Because of this problem, backing up and restoring the control file from a
trace file is an action of last resort. Use it only when all other restore
attempts fail.
65
2-11
Managing online redo logs

Because redo logs are critical to ensure database consistency, Oracle has the
built-in capability to archive redo logs, independent of other backup operations.
It is recommended that you do not back up the online redo logs because you
can corrupt the database when you perform a recovery.
Online redo log groups
Configure at least three online redo log groups. If one redo log group fails,
you still have two groups to use for continuity. Oracle switches redo logs
when one group is full and performs a checkpoint operation.
66
Mirror online redo logs

To perform mirroring at the Oracle level (also called multiplexing), define two
or more members of each redo log group. Oracle then writes a separate
copy off every redo
d llog record
d tto each
h member
b off th
the group.
Perform mirroring at the operating system level through disk mirroring or
logical volume mirroring. Oracle performs a single write of the redo log
record, but multiple copies are written by the OS.
Regardless of the method of mirroring that is used, ensure that the mirror
copies are stored on separate disks and, if possible, on different controllers.
2-12
67
Managing archived redo logs

Because archived redo log files are used in the recovery of a failed database,
they are crucial to your backup strategy. To assist in managing the archived redo
log files, consider the following actions.
Enable redo log archiving
Place the database into ARCHIVELOG mode by issuing the following
command:
$ ALTER DATABASE ARCHIVELOG
Online redo logs are automatically archived before being overwritten by the
LGWR process. Specify the primary location of the archive redo logs using
the log_archive_dest_1 parameter in the parameter file.
Archive redo logs to multiple destinations
When you archive the redo logs to multiple destinations, you safeguard your
ability to recover and restore them in the event of multiple media failures.
Specify the secondary destination in the parameter file using:
LOG_ARCHIVE_DUPLEX_DEST
Take multiple backups
Taking multiple backups is an extension of the concept of maintaining
multiple
p archive log
g destinations.
2-13
Managing other critical files
Parameter Files
A PFILE, which is the traditional type of parameter file, must be backed up
with an ordinary file system backup. RMAN does not back up PFILEs. To
back up the Oracle directory structure containing the PFILE, perform a file
system backup with NetBackup.
SPFILEs are backed up automatically by RMAN as of Oracle version 9i.
Password files
Back up Oracle password files with a file system backup.
68
Oracle directory structures

Back up Oracle directory structures with file system backups.
Typically, a single NetBackup policy is used to perform a file system backup
of the Oracle directory structures that include the PFILE and the password
file. It is not necessary to back them up individually.
2-14
69
Database recovery methods

The table on this slide describes three database recovery methods.
Media restore
Media restore is the reconstruction of the contents of storage media by
restoring from a copy of the data taken at a previous point in time. The
restored copy does not reflect changes made to the database by
transactions executed after the time of the backup copy
copy. Therefore,
Therefore media
restore is typically used in conjunction with the Oracle roll forward procedure,
which updates the database.
Roll forward
Roll forward is used to reapply changes to the database recorded in the redo
log files (both archived and online). This is used when changes recorded in
the redo logs are not represented in the contents of the data files. Roll
forward is an automatic process handled by the Oracle System Monitor
(SMON).
Roll back
Roll back is the reversal of changes made by an incomplete or uncommitted
transaction. A copy of data prior to a change is recorded in the undo
tablespaces or roll back segments and can be used to reverse the changes,
provided the changes have not been committed. Roll back is an automatic
process handled by
p
y the Oracle Process Monitor ((PMON).
)
2-15
Recovery by media restore and roll forward

In the event of a media failure or an application or user error that results in the
loss of data from the database, replace the lost data by restoring from a backup
copy. You can then update the database by rolling forward, using the contents of
the archived redo logs and the available online redo log.
The following table describes the roll forward types and their functions.
70
RollForwardType
Function
Timebased
Recoverdatauptoaspecifiedpointintime.
Changebasedrecovery
RecoveruntilthespecifiedSystemChangeNumber
(SCN)
L S
LogSequencerecovery
R
Recoveruntilthespecifiedlogsequencenumber.
til th
ifi d l
b
These options enable you to stop the roll forward process at a point that avoids
applying unwanted changes; for example, the inappropriate deletion of a table.
2-16
Recovery by roll forward
When the database is started and the data files do not reflect a current version
of the database (as can occur with an instance failure), Oracles SMON
automatically rolls the database forward by reapplying the changes recorded in
the redo log files (both archived and online).
71
2-17
Recovery by roll back
Roll back is handled through PMON and is applied automatically when a

statement failure occurs or if there is a failure in the sequence of commands
from an application. Such a failure can occur if the application process
unexpectedly terminates or if the communication channel between the
application and the database server fails.
72
2-18
This is Topic 2: Database backup types.
After completing this topic, you will be able to identify the types of database
backups.
73
2-19
Database backup methods

You have numerous options and choices when backing up a database. One of
the first choices you must make is how to execute the backup process. How you
choose to back up your database influences other choices later in the process.
The most common backup method is a physical backup of a database. This

method creates a mirror image of the database that is complete in detail down to
th physical
the
h i l llocation
ti off th
the d
data
t bl
blocks.
k Y
You may occasionally
i
ll perform
f
a logical
l i l
backup, which exports a snapshot of the data from the database but does not
record the physical structure of the database.
74
The choices you make when performing physical backups are determined by the
requirements and demands of your Oracle database. If you can take the
database offline with little or no impact on operations, then you can perform a
consistent backup (sometimes referred to as an offline or cold backup). If,
however, your database must operate 24 hours per day, seven days per week,
then the preferred method is to perform an inconsistent backup (sometimes
referred to as an online or hot backup).
2-20
Physical versus logical backup

Physical backup
A physical backup copies the underlying physical files that constitute the
database. Physical backups can be performed on all elements of the Oracle
database structure, ranging from a single data file to the complete database.
Physical
y
backups
p can be p
performed using
g NetBackup
p alone by
y shutting
g down
the Oracle instance and performing a consistent (cold) backup of the datafiles.
To perform inconsistent (hot) physical backups to tape, use RMAN and NBUO
together.
Logical backup
75
A logical backup is one that copies a binary version of the database using the
database export utility. NetBackup for Oracle also supports XML format for
exports using the bporaexp utility.
utility
Note: Logical backups are not the subject of this course and are not discussed
in detail. This course deals primarily with physical backup and recovery
operations.
2-21
Cold (consistent) backups

A consistent backup is commonly referred to as a cold backup because the
database must be shut down (offline) while the backup is performed. Because
the database is offline when the backup is performed, it does not matter whether
it was operating in ARCHIVELOG mode or NOARCHIVELOG mode (see the
ARCHIVELOG Mode slide). The database must be closed cleanly using
shutdown normal or shutdown immediate.
With a cold backup, recovery actions are not needed to restart the database
after a restore. Because the database was closed cleanly, the contents of the
control file and the data file headers are consistent.
76
2-22
Hot (inconsistent) backup

An inconsistent backup is commonly referred to as a hot backup because the
database is open and operational (online) while the backup is performed.
The database must be running in ARCHIVELOG mode in order to maintain an
updated record of transactions that occur while the backup is performed (see the
ARCHIVELOG Mode slide).
With a hot backup, recovery actions are necessary before you can restart the
database after a restore.
77
2-23
Database and partial backups

Other factors to consider when performing physical backups are database size
and tablespace traffic. Complete database backups take longer and require
large amounts of storage space. If you structure your database so that only
certain data files or tablespaces are modified regularly, you can save time and
storage space by backing up only the elements that change.
D t b
Database
b
backup
k
When you conduct a database backup, all constituent files of the database
are backed up as a coherent whole. This includes all data files, the SPFILE
(as of Oracle9i), and the database control file.
78
A database backup can be performed as either a cold or hot backup.

ARCHIVELOG mode is required for hot backups.
T bl
Tablespace
B
Backup
k
An individual tablespace can be backed up independent of the remainder of
the database. Because tablespaces can consist of multiple data files,
backing up tablespaces is more common than backing up individual data
files.
Because tablespace backups can only be performed as hot backups, they
require the database to run in ARCHIVELOG mode
mode.
2-24
Individual file backups
Data file backup

As with a tablespace backup, individual data files can be backed up
independent of the remainder of the database. If a tablespace consists of
only one file, this is identical to a tablespace backup. Otherwise, the effect is
to back up only a portion of a tablespace.
Data file backups can only be performed as hot backups, and therefore
require the database to run in ARCHIVELOG mode.
79
Control file backup

Back up the database control file should whenever you perform a cold
backup. Because the control file is always open when the database is
mounted, use one of the methods discussed previously in this lesson when
performing
f
i hot
h t backups
b k
off your database.
d t b
Redo log backups

Do not back up a databases online redo logs!
Doing so can corrupt the database when you perform a recovery. Archived
redo log files are used in the recovery of a failed database, and are therefore
crucial to your backup strategy. Refer to the Managing Archived Redo Logs
slide
lid ffor recommendations
d ti
on working
ki with
ith archived
hi d redo
d log
l fil
files.
2-25
This is Topic 3: Protecting your databases.
After completing this topic, you will be able to explore the utilities and tools
available for protecting an Oracle database.
80
2-26
The ARCHIVELOG mode
81
An Oracle database has an integrated safety mechanism that protects the data. This
mechanism is known as the ARCHIVELOG mode. When a database runs in
ARCHIVELOG mode, it automatically archives the online redo logs, which track all
changes made to the database.
A database must run in either ARCHIVELOG mode or NOARCHIVELOG mode. One of
the most important decisions you make as an Oracle DBA is whether to run your
databases in ARCHIVELOG mode
mode. You make certain tradeoffs when you decide to
operate in ARCHIVELOG mode.
Advantages
You can perform hot backups, and your database can remain online continuously.
If managed properly, you can recover completely from any type of failure.
You can back up individual tablespaces or datafiles.
You have more recovery options in ARCHIVELOG mode than in NOARCHIVELOG
mode.
d
Disadvantages
ARCHIVELOG mode requires more disk space and increases I/O traffic over
NOARCHIVELOG mode, due to the continual archiving of redo log files.
Increased management and administrative work is required. This work includes
maintaining adequate disk space, establishing target directories for the archived
redo log files, and verifying that archived log files are copied to tape.
2-27
Backup management
You can manage backup and recovery operations for an Oracle database using
Oracles RMAN utility, a third-party application such as Symantec NetBackup, or
a combination of the two.
RMAN
The Oracle Recovery Manager (RMAN), a utility included with Oracle8 and
higher, controls the backup processes for an Oracle database. RMAN is a
command-line based utility. GUI applications, such as the Oracle Enterprise
Manager (OEM), help simplify and automate many of RMANs functions and
processes.
82
RMAN-initiated backups are saved in a proprietary format. Therefore, you

must use RMAN to perform restore and recovery operations. RMAN,
however cannot write directly to robotic tape devices without the integration
however,
of a third-party media manager, such as Symantec NetBackup for Oracle
(NBUO).
2-28
Symantec NetBackup
Symantec NetBackup is an operating system (OS)-based file system backup
tool. NetBackup can independently back up an Oracle database without
integrating with RMAN. To do this, the database is shut down, and
NetBackup backs it up as if it were any other type of file. Use NetBackup
notify scripts to automate the process of shutting down, backing up, and
restarting a database.
Because NetBackup treats the closed database as an OS file, this type of
database backup is sometimes referred to as a file system backup or an OSlevel backup.
p Using
g NetBackup
p to p
perform OS-level backups
p is not a viable
option if your Oracle database must remain online continuously.
NetBackup for Oracle

NetBackups Oracle extension (NBUO) expands NetBackups capabilities to
work within complex database structures. NBUO integrates the database
backup and recovery capabilities of RMAN with the backup and recovery
management capabilities of NetBackup and its Media Manager.
NBUO is a database aware application. It accounts for the complexities of
database backup and recovery. NBUO supports full and incremental
backups, as well as hot and cold backups. It further automates backup
processes through its built-in job scheduler and robotic tape device support.
In addition, NBUO manages the backup and recovery of all parts of the
Oracle database,, including
g archive redo logs
g and control files.
NBUO integrates with RMAN through an application program interface (API)

published by Oracle and implemented by NBUO. A complete explanation of
NBUO and RMAN integration is provided in the NetBackup for Oracle
Installation and Configuration lesson.
83
2-29
Lesson summary
This lesson covered the types of failure a database can experience and the
corresponding methods of recovering from those failures. It also outlined what is
required to prepare for backup and recovery operations. Finally, it described
tools and utilities you can use to back up and recover an Oracle database.
Reference materials
84

2-30
85
3-1
Lesson introduction
This lesson serves as an introduction to the NetBackup product, explaining at a
high level what NetBackup is and how it works.
Importance
To effectively and efficiently use NetBackup, you must first be familiar with what
the product does
does, how it can be configured
configured, and the terminology you use as you
learn to administer a NetBackup environment.
86
3-2
This lesson serves as an introduction to the NetBackup product, explaining at a

high level what NetBackup is and how it works. After completing this lesson you
will be more familiar with NetBackup concepts and terminology. This lesson
provides the building blocks for subsequent lessons on configuring successful
backups using NetBackup for Oracle and RMAN.
87
3-3
This is Topic 1: The NetBackup environment.
After completing this topic, you will be able to identify the function of the
NetBackup master server, media server, EMM server, and clients.
88
3-4
NetBackup component definitions

The five components of NetBackup architecture are shown on this slide. These
components are defined as follows:
The master server

A master server is a server that controls the backup and recovery activities
for the clients assigned to it.
it Specifically,
Specifically master servers track which files are
backed up to which backup media. (NetBackup management)
89
The Enterprise Media Manager (EMM) server

The EMM server is a centralized data store and group of services that
manage and allocate the resources required for all NetBackup operations.
(Resource management)
Media servers
The Media server has some form of storage attached to iteither directly or
through the network. Media servers manage the writing and reading of data
to and from media. (Data management)
Storage Area Network (SAN) media servers

A SAN media server is a specialized
p
server that can only
y back up
p its own
data to devices. This server cannot back up data residing on other clients.
3-5
Clients
Clients are any machines that have data to back up and on which NetBackup
Client software has been installed.
Symantec OpsCenter
Symantec OpsCenter is a Web-based software application that helps

organizations by providing visibility into their data protection environment. By
using Symantec OpsCenter, you can track the effectiveness of data backup
and archive operations by generating comprehensive reports.
90
3-6
NetBackup Server
NetBackup Server is designed for UNIX and Windows platforms.
NetBackup Server can perform backup and restore operations, but you can
have only one media server, and it is the same machine as the master server
and the EMM server.
A NetBackup domain is defined as all of the media servers and clients owned by
one NetBackup master server. In a NetBackup Server environment, this
includes the master server because there are no separate media servers.
91
3-7
NetBackup Enterprise Server: Separate media servers

NetBackup Enterprise Server is designed for large UNIX and Windows systems.
In a NetBackup Enterprise Server configuration, you can have one or many
media servers across your NetBackup environment. The master server can also
serve as a media server.
In the NetBackup Enterprise Server environment,
environment EMM manages the media and
device database, as well as functions as the resource broker for resource
requests.
Generally, the EMM server and master server are the same machine.
92
3-8
NetBackup Enterprise Server: Multiple media servers
As the data center gets larger, more media servers can be added to distribute
the load required for backing up clients and applications. Media servers may be
added due to increased data size, increased number of clients and applications,
or due to the distributed networks of client machines.
93
3-9
NetBackup Enterprise Server: Multiple NetBackup domains

When more than one data center exists, especially when connected through
wide area networks, design decisions need to be made regarding the
NetBackup topology.
As you can see on the slide, you can have separate data centers that each have
their own master and EMM servers. Each master server manages its own media
servers. A media server can be owned by only one master server. The EMM
server manages media and devices in its location. Devices are not shared
between separate EMM servers.
94
In the diagram on this slide, there are two NetBackup domains. NetBackup
domain 1 is defined as all the media servers managed by the first master server.
NetBackup domain 2 is defined as all the media servers managed by the second
master server.
In addition, an OpsCenter server has been added to help centrally manage and
report on the multiple master servers and their NetBackup domains.
3-10
SAN media server
A SAN media server is a specialized media server that can only back up its own
data to devices managed by itself. Unlike traditional media servers, such as
Media 1 in this diagram, the SAN media server cannot back up data residing on
other clients.
95
The Oracle database server in the diagram on the slide has the NetBackup
media server software installed and is acting as a SAN media server to perform
backups of local data to shared tape devices on the SAN. The backups perform
better because data does not have to travel across the LAN to a remote media
server. Data travels directly from shared memory on the Oracle server (the SAN
media server) to the tape devices.
Backup devices used by SAN media servers can be SAN-attached as shown on
the slide or directly attached to the SAN media server itself. Deployment of
SAN-attached tape hardware is not a requirement.
3-11
NetBackup OpsCenter
OpsCenter is a Web-based software application that helps organizations by
providing visibility into their data protection environment. By using Symantec
OpsCenter, you can track the effectiveness of data backup and archive
operations by generating comprehensive reports.
OpsCenter is a convergence of NetBackup Operations Manager or NOM, and

Veritas Backup Reporter or VBR, and is available as OpsCenter or OpsCenter
Analytics.
96
Both OpsCenter and OpsCenter Analytics require additional installation and

configuration steps.
3-12
This is Topic 2: NetBackup concepts.
97
Identify common terms used in the NetBackup product.
Describe how NetBackup backs up and restores data.
3-13
Backing up data: The big picture
The purpose of any backup software is to back up client and system data to a
safe place where it can be used, if needed, to restore that data. At this time,
NetBackup may be unfamiliar to you. By the end of this topic, you will
understand, at a very high level, all the components that enable backups.
98
3-14
NetBackup images
When a client sends its backup data to the media server, NetBackup
compresses it in GNU tar format and writes it to the backup media. This
compressed backup data is known as a NetBackup image, sometimes referred
to as a backup image or simply an image.
99
3-15
Storage units
A storage unit is a group of one or more storage devices of a specific type and
density that attach to a NetBackup server. The media can be removable (such
as tape) or a directory on a hard disk. Removable media can be in a robot or a
stand-alone drive. During a backup or archive, NetBackup stores the backup
data on the storage units that were specified during the policy configuration.
Storage units are logical entities within NetBackup that have several benefits,
such as:
100
Storage units simplify NetBackup administration. After storage units are

defined, the NetBackup configuration points to the storage units rather than
the individual devices they contain. For example, if a storage unit contains
two drives and one is busy, NetBackup can use the free drive without
administrator intervention.
NetBackup uses storage units rather than specific storage devices to help
ensure backup success. When configuring backups, you simply assign the
storage unit with the type of storage needed for a backup, as opposed to
selecting specific storage devices. This provides a virtual approach to
backup storage. If you need additional storage of a specific type, NetBackup
uses the
th configured
fi
dh
hardware
d
automatically.
t
ti ll
3-16
Volumes
When a tape is configured into media manager, it is referred to as a volume and
assigned a unique media ID to identify it. An optical platter is actually two
volumes because it can be written on either side each side being defined as a
volume.
Media manager volumes are logical units of data storage or cleaning capability
on media (tapes or optical disks) that have been assigned media IDs and other
attributes, which are recorded in the EMM database.
101
3-17
Volume pools
A volume pool is a set of volumes from which NetBackup can draw when
performing backups. The volume pool identifies sets of volumes whose use can
be reserved for specific backup jobs. The following volume pools are preconfigured:
102
NetBackup
NetBackup is the default volume pool and is automatically used for all
backups unless the administrator over-rides the default setting in the backup
policy. The NetBackup volume pool must be used for cold NetBackup catalog
backups (unless the Vault option is used to perform catalog backups).
DataStore
The DataStore volume pool is provided for Symantec partners in conjunction
with the DataStore API to enable access to media manager library functions.
CatalogBackup
The CatalogBackup volume pool is used for hot NetBackup catalog backups
that became available with NetBackup version 6. You may also configure
additional volume pools for hot catalog backups if desired.
3-18
None
The None volume pool is provided for non-backup activities. To enable
NetBackup to recognize tapes as cleaning tapes and use them to clean
drives,, place
p
them into the None p
pool.
Other volume pools include the following:
Scratch pool
The Scratch pool is an optional volume pool that you can configure. If a
Scratch pool is configured, it can be used as a temporary holding area for
unassigned media. Media manager moves volumes from the Scratch pool to
other volume pools that do not have volumes available
available.
Administrator defined volume pools
Other volume pools can be configured as needed. For example, an Oracle

volume may be configured to hold volumes for Oracle backups.
103
3-19
NetBackup catalog components

A NetBackup catalog features internal databases that contain backup and
configuration information, such as records of the files that have been backed up
and the media on which the files are stored. The catalog also contains
information about the media and storage devices.
The NetBackup catalog resides on the disk of the NetBackup master server.
The catalog has three specific databases:
104
The Image database contains information about what has been backed up.
The NetBackup configuration files include flat files concerning policy and
schedule information.
The relational database includes the media and device configuration for the
environment, or the EMM database, as well as any other relational database
that has been configured for NetBackup, such as Oracle.
3-20
NetBackup policies
A NetBackup policy defines the rules that NetBackup follows when backing up
clients. A policy can contain one or more clients, and every client must belong to
at least one policy.
A policy is a template for the backup of a single client or a group of clients with
common attributes and a common file list. Policies determine:
105
What
What files should be backed up?
Who
Which clients should be backed up?
Where
Where is the backup storage location?
When
When should the backup start? How often?
How
Are there any

y special
p
behaviors when backing
g up
p the files?
3-21
Backup types
There are three types of automatic backups: full backups, differential

incremental backups, and cumulative incremental backups.
106
A full backup backs up all files specified in the backup selections list for the
policy, regardless of when the files were last modified or backed up.
A differential incremental backup backs up only files specified in the backup

selections list for the policy that have changed since the last successful
incremental or full backup. A complete restore requires the last full backup,
and all differential incremental backups that have occurred since the last full
backup.
Cumulative incremental backups back up all files specified in the backup

selections list for a policy that have changed since the last successful full
backup. A complete restore requires the last full backup and the last
cumulative incremental backup.
You can also have backups that are initiated by users.
A user backup is initiated by the user through the Backup, Archive and
Restore client interface. A user backup backs up all files the user specifies.
3-22
107
A user archive archives all files that the user specifies. An archive is a
special type of backup that first backs up the file and then deletes it from the
local disk if the backup is successful. This frees local disk space while still
keeping a copy for future use.
An application backup is only used when a database agent, such as

NetBackup for Oracle is installed on the database server. It is used to
facilitate database backups initiated from the client (the database server) in a
similar fashion to a user backup or archive.
3-23
Backing up data
The graphic on the slide presents a more detailed picture of how NetBackup
backs up data.
First, NetBackup backs up the data to a tar file image over the network to tape,
disk, or other storage devices, according to your policies. During the backup,
NetBackup keeps status information in its log files, enabling you to monitor or
report on the backup.
108
Then, NetBackup stores information about what has been backed up in the
Image database and information about the media and volumes used during the
backup in the EMM database.
3-24
Restoring data
You can perform a restore operation as an administrator from the master server
or users can request their own restore operation to occur. To restore data, use
the NetBackup Backup, Archive, and Restore interface.
Simply select the files to be restored. NetBackup uses the information in the
Image database, the NetBackup database, and the EMM database to identify
which files are available, where the backup images are located, and where they
should be restored. Because NetBackup maintains status information about
restores in its log files, you can monitor and report on restores just like backups.
109
3-25
This is Topic 3: NetBackup notify scripts.
After completing this topic, you will be familiar with NetBackup notify scripts and
how to use them to automate database shutdown and startup for cold Oracle file
system backups.
110
3-26
NetBackup notify scripts
111
When using NetBackup to perform cold Oracle database backups without the
Oracle agent, you can incorporate the (unsupported) scripts included with the
NetBackup installation. These scripts enable simple integration with an Oracle
database in order to shut down or restart the database.
bpstart
p
_notify
y and bpend
p
_notify
y are the NetBackup
p scripts
p that can be
configured to respectively shut down or restart an Oracle database. You can
modify attributes related to these scripts (such as the timeout period) in the
bp.conf file located in /usr/openv/netbackup on the client, which is the
database server in this case.
You can customize the scripts so that they are only executed when a specific
policy is invoked by naming the script as follows:
bpstart_notify.policy_name
bpend_notify.policy_name
Locate the scripts in /usr/openv/netbackup/bin on the client (database

server) and ensure that both scripts have executable permissions.
3-27
Running the bpstart_notify script
To shut down the database properly, bpstart_notify must include the

following statements:
su oracle
sqlplus
connect username/password
shutdown immediate
Running the bpend_notify script
To restart the database p

properly,
p y, bpend
p
_notify
y must include the following
g
statements:
su oracle
sqlplus
connect username/password
startup
Additional logic can be added to the scripts as desired. For example, you may
want to include statements in the bpstart_notify script to check the Oracle
processes after issuing the shutdown immediate command.
112
3-28
Lesson summary
You are now familiar with the essential components of NetBackups environment
and possible configurations. Also, you are aware of terms that relate to
NetBackup and are familiar with the NetBackup catalogs. In addition, you were
introduced to NetBackup notify scripts, which provide a simple method of
automating database shutdown and startup for cold backups.
Reference materials
113
Symantec NetBackup for Oracle Administrators Guide
Symantec NetBackup System Administrators Guide for UNIX and Linux,

Volume I

http://www symantec com/business/support
3-29
114
3-30
115
4-1
Lesson introduction
This lesson describes how RMAN performs database backups and how users
(DBAs) can configure, execute, and monitor backup operations through RMAN.
Importance
RMAN is the Oracle utility that Symantec NetBackup for Oracle (NBUO)
g in order to p
perform high-level
g
database backup
p operations.
p
It is
manages
necessary to learn configuration and execution of RMAN backups before
incorporating NBUO in an overall backup strategy.
116
4-2
After completing this lesson, you will be able to leverage your understanding of
RMANs structure and commands as they relate to backup and restore
functions. Specifically, you will configure RMAN and its components in
preparation for database backup.
117
4-3
This is Topic 1: RMAN architecture.

After completing this topic, you will be able to describe the architecture of
Oracles recovery manager (RMAN).
118
4-4
119
RMAN architecture components

The chart on this slide diagrams the components of the RMAN architecture.
The RMAN Executable
The Oracle recovery manager (RMAN) is a standard utility included with an
Oracle installation as of Oracle 8.x. The RMAN executable, usually named
RMAN, is the program that manages all backup and recovery operations.
You interact with the RMAN executable to specify backup and recovery
operations you wish to perform.
User Interface
You can interface with RMAN using either the OS level command line
interface (CLI) or the Oracle enterprise manager (OEM) GUI.
Target Database
The target database is the database that you want to back up or restore.
Media manager layer (MML) requirements
RMAN backs up to disk under its own control, but in order to use tape media
for backups, RMAN requires the assistance of a third-party media manager,
such as Symantec NetBackup for Oracle (NBUO). RMAN integrates with
NBUO through an API published by Oracle and implemented by NBUO. You
will learn to integrate NetBackups Media Manager capabilities with RMAN in
the next lesson.
4-5
Oracle server processes

RMAN performs its operations through background processes started on the
server, called server sessions. These processes are used to communicate
between RMAN and the databases. They can also communicate between
RMAN and
d any di
disk,
k ttape, or other
th I/O devices.
d i
By
B default,
d f lt when
h RMAN
makes a client connection to the target database, two server processes are
spawned. One process is used to make calls to packages in the SYS
schema in order to perform the backup or recovery operations. The other
process polls any long-running transactions in RMAN and logs the
information internally.
When you use a recovery catalog with a target database, RMAN creates an
additional server process that interfaces with the recovery catalog database.
RMAN also creates and allocates an individual channel for each physical
disk or tape device used to store backups. Each channel corresponds to a
server process.
Because RMAN is an integral part of Oracle, rather than a separate utility, it
issues commands directly to an Oracle server process. The Oracle server
process reads the data files
files, control files
files, or archived redo logs that are being
backed up. (During a restore or recovery procedure, the Oracle server
process writes the appropriate data files, control files, or archived redo logs.)
This process uses the same mechanism for reading and writing data blocks
that the normal Oracle instance uses.
When an Oracle server process reads a data file, it detects any fractured
(split) blocks and rereads them to obtain a consistent block. Therefore, you
do not need to put tablespaces into hot backup mode when using RMAN to
perform open backups.
Channels
A channel is an RMAN server process started when there is a need to

communicate with an I/O device, such as disk or tape. A channel is the
process that reads and writes RMAN backup files.
120
4-6
The RMAN repository

The RMAN repository stores a set of metadata about the structure of the target
database and the backup and recovery operations performed upon it.
The RMAN repository is stored either in the RMAN recovery catalog or within
the control file of the target database.
The recovery catalog
You can create a recovery catalog within an existing database. It can hold
metadata pertaining to several different target databases, but it should not be
located within one of its own target databases.
121
If you manage very large or multiple databases, it is recommended that you

create a separate database exclusively for the recovery catalog. You can
also store the recovery catalog on a separate disk or machine from that of
th target
the
t
t database.
d t b
If the
th hardware
h d
for
f the
th target
t
t database
d t b
fails,
f il you do
d nott
risk losing the recovery catalog.
Using an RMAN recovery catalog is an effective way to manage Oracle
databases that are distributed across enterprise networks. Using an RMAN
recovery catalog enables you to use all RMAN functions and options and
simplifies backup and recovery operations.
4-7
Contents
The recovery catalog is a separate Oracle database that contains information
about the target databases structure. It also holds metadata pertaining to
backup, restore, and recovery operations that are performed upon the target
d t b
database.
The
Th information
i f
ti can be
b used
d to
t determine
d t
i how
h
backup
b k and
d
recovery operations are conducted.
The recovery catalog can also contain stored scripts, providing you with a
readily available repository for your regularly executed RMAN scripts.
Resynchronization
The recovery catalog metadata is obtained from the control file of the target
d t b
database.
In
I order
d to
t maintain
i t i concurrence between
b t
the
th two,
t
regularly
l l
resynchronize the contents of the recovery catalog with the control file.
Recovery catalog resynchronization is covered in more detail later in this
course.
Control file
Alternately, you can house the RMAN repository within the control file of the
target database
database. This method does not support stored scripts.
scripts This method
also introduces more risk than the use of a separate recovery catalog.
Because the repository cannot be used to recover a database after a control
file failure; the RMAN repository information is lost along with the control file.
122
4-8
This is Topic 2: RMAN commands.
123
Use the RMAN command line interface to run RMAN commands.
Identify RMAN command types and extension modes.
4-9
RMAN commands introduction

RMAN implements its commands through a set of PL/SQL packages. (PL/SQL
is Oracles procedural language extension to SQL.) These packages contain
functions that maintain the RMAN repository (see the RMAN Repository slide).
The packages also communicate with Oracle and the operating system to
create, restore, and recover backup sets.
You create
Y
t the
th PL/SQL packages
k
th
thatt manage th
the RMAN repository
it
when
h you
issue the create catalog command.
124
RMAN commands are compiled into a set of PL/SQL procedures upon

execution. The names of RMAN command objects translate into the appropriate
database entities. For example, backup database translates into the list of
data files that constitute the database.
Each channel or server session
session, representing a datastream to a storage device
device,
is assigned a separate PL/SQL program. These PL/SQL programs can execute
concurrently because they use nonblocking remote procedure calls (RPCs) on
the target database.
RMAN command types
RMAN uses two types of commands: stand-alone commands and job

commands.
4-10
Stand-alone commands
Stand-alone commands function independently; they are not subcommands
within a run statement. Stand-alone commands are used to manage the
recovery catalog, backup data, metadata, and scripts. Examples of standalone
l
commands
d iinclude:
l d
catalog
change
create catalog, drop catalog, upgrade catalog
create script, delete script, replace script
crosscheck
h k
delete expired backupset
list
report
The list and report commands enable you to perform queries about
available backup
p sets. These two commands are described in a later lesson.
Job commands
Job commands cannot run independently; they are subcommands within a
run statement. Job commands within the run statement are executed
sequentially.
If a command within the statement fails, RMAN ceases processing the
statement; further commands do not execute. Job commands manage and
control
t l backup
b k and
d restore
t
operations.
ti
E
Examples
l off jjob
b commands
d iinclude:
l d
allocate channel
backup
copy
duplicate
recover
restore
switch
125
Both
Three commands can be executed independently or as a subcommand
within a run statement. These three commands are:
change
crosscheck
delete
4-11
Running RMAN commands

There are two ways to access RMAN: the command line interface (CLI) or OEM.
Because the objective of this topic is to learn how to integrate RMAN and
NetBackup using the NetBackup for Oracle (NBUO) agent, this topic focuses on
the command line interface. In addition, NBUO uses the command line for
Oracle operations.
RMAN has
h many command
d line
li parameters.
t
Th
The ffollowing
ll i ttable
bl d
describes
ib some
of the most commonly used parameters:
126
RMANcommandline
parameter
Parameterargument
type
Purpose
target
Charstring
Definestheusername,password,and
servicenameofthetargetdatabase
catalog
Charstring
Definestheusername,password,and
servicenameoftherecoverycatalog
nocatalog
Noarguments
Preventsarecoverycatalogfrombeing
used(default)
4-12
RMANcommandline
parameter
Parameterargument
type
Purpose
cmdfile
Charstring
Indicatesthenameofacommandfile
scripttoexecute
log
Charstring
CausestheRMANsessiontobelogged
Thelogfiletakesthenameofthe
argumenttothisparameter.This
parameteralsocausesallRMAN
messagestothescreen(exceptthe
RMAN prompt) to be suppressed
RMANprompt)tobesuppressed.
trace
Charstring
CausestheRMANsessiontobetraced
Thetracefiletakesthenameofthe
argumenttothisparameter.
append
Noarguments
Causesthelogfile(definedbythelog
parameter)tobeappended
parameter)
to be appended
debug
Variousarguments
CausesRMANtobestartedindebug
mode
msgno
Noarguments
CausestheRMANprefixtobeshown
witheacherrormessage
If thi
Ifthisoptionisnotspecified,somenon
ti i
t
ifi d
errormessagesdonotincludeamessage
number.
127
send
Charstring
Sendsthecharacterstringmessageto
themediamanagementlayer
pipe
String
InvokestheRMANpipeinterface
timeout
Integer
Indicatesthenumberofsecondstowait
forpipeinput
4-13
RMAN execution modes

You can execute RMAN commands in one of three ways.
Interactive mode
In this mode, you enter commands directly at the RMAN command line
interface. This method limits you to entering one command at a time.
Batch mode
In batch mode, you create a script file containing the set of RMAN
commands to be executed. You execute the script by supplying it as a
parameter to an RMAN command at the RMAN command line.
128
Stored script
This mode is similar to the batch mode, except that the script files are stored
in the RMAN reco
recovery
er catalog and are executed
e ec ted from there.
there Yo
You can view
ie a
list of all available stored scripts by querying the view rc_stored_script:
SQL> SELECT * FROM rc_stored_script;
4-14
New RMAN enhancements and commands
Starting with Oracle 9i, an RMAN enhancement enables you to perform

automated backup and recovery operations. For example, RMAN now has the
ability to back up the control file and SPFILE. In addition, these backups can be
configured to take place by default. When autobackup of the control file and
SPFILE is configured, the backups occur automatically whenever:
129
Th backup
The
b k or copy command
d iis iissued
d outside
t id a run bl
block.
k
A run block is used, but the last command is not backup or copy.
Because of this autobackup enhancement, RMAN also provides two commands,

configure and show, to define and manage default values for automated
backup operations.
The configure command
Use the configure command to specify default values for RMAN parameters,
such as those shown in the slide. These defaults are tracked in the control file
and recovery catalog (if used), and remain persistent unless you change them
again using the configure command.
In addition to the configure options shown in the slide, you can also specify other
defaults, such as the maximum size of a backup set or the default number of
channels to allocate when performing RMAN operations.
4-15
The show command

Each RMAN configurable setting that you can change with the configure
command has a default value assigned to it. The defaults are stored in the
control file. You can use the show command to display the current default
values. The show command also tells you if a specific setting is using the
original default setting and the value of the original default.
E
Examples
l off the
th show
h command:
d
RMAN>show default device type;
RMAN>show maxsetsize;
130
RMAN>show retention policy;

RMAN>show all;
4-16
Using RMAN to manage the database state

RMAN can perform startup and shutdown operations on the database:
RMAN>shutdown immediate
However, to change the state of a database in MOUNT or NOMOUNT state, you
must either use a SQL*Plus session or use the RMAN SQL command.
Running SQL commands from within RMAN

Sometimes it is convenient to run SQL statements from within RMAN. This is
particularly handy when writing scripts to automate RMAN backups.
For example:
131
rman> sql alter database mount;
The RMAN host command

The host command enables you to run operating system commands from
within RMAN:
rman> host ls
4-17
Terminating RMAN jobs

You can terminate a running RMAN job using one of the following methods:
CTRL+C
Press CTRL+C (or the equivalent attention key combination for your UNIX
system) at the RMAN command line. This is the preferred method. This
action terminates all allocated channels for the job unless they are waiting for
media management services, such as waiting for a tape to be mounted in the
tape drive.
132
UNIX kill command

Kill the process at the operating system level using OS functions. In order to
terminate an RMAN job in this way, first determine the session ID for the
RMAN channel. You can determine the session ID by finding the RMAN08500 message within
ithi the
th RMAN log
l file.
fil Th
Then apply
l th
the UNIX kill
command to that process.
4-18
This is Topic 3: RMAN backups.

133
Perform cold and hot RMAN backups.
Perform full and incremental backups.
4-19
RMAN backup methods

RMAN supports two primary backup methods: backup sets and image copies. A
third backup method, operating system backups, uses system tools or thirdparty software utilities, such as Symantec NetBackup, to perform backups at the
OS level. Because operating system backups work independently of RMAN, this
method is not discussed in this course.
134
I
Image
copy
An image copy (sometimes referred to as a data file copy) contains a single
file (data file, archive log, or control file) that you can use as is to perform
recovery. An image copy backup is similar to an OS copy of a single file,
except that it is produced by an Oracle server process, which performs
additional actions associated with the backup process. These actions include
validating the blocks in the file and registering the image copy in the control
file.
Backup set
A backup set contains one or more data files or archive logs. However, this
set cannot contain both data files and archive logs. A data file backup set can
also contain a control file backup.
A backup set is written in an Oracle-proprietary format (similar to an export
file). To extract a file from a backup set, perform an RMAN restore operation.
4-20
Image copies
An image copy contains a single file (data file, archive log, or control file) that
you can use to replace the original file with no recovery operations required. It is
similar to an OS copy of a single file, except that it is produced by an Oracle
server process that performs additional actions associated with the backup
process. These actions include validating the data blocks in the file and
registering the image copy in the control file
file.
Image copy backups can only be written to disk.
135
An image copy is created using the copy command. The following RMAN
command sequence creates an image copy of the data file df1.f, marking it as
a level 0 incremental backup:
RMAN> run {
2 allocate
2>
ll
t channel
h
l stream1
t
1 t
type di
disk;
k
3> copy datafile '$ORACLE_HOME/testdb/df1.f' to
'$ORACLE_HOME/testdb_copy/df1copy.f;
4> level 0;
5> }
4-21
To replace the original file with the image copy, a switch command is provided to
point the control file at the copy and perform media recovery to make the copy
current. For example, the following command points the control file from df1.f
to df1copy.f:
RMAN> switch
it h d
datafile
t fil '$ORACLE
'$ORACLE_HOME/testdb/df1.f'
HOME/t tdb/df1 f' t
to
datafile copy '$ORACLE_HOME/testdb_copy/df1copy.f';
Image copies created by methods other than RMAN are supported. However,
before using such copies in a restore or switch, catalog them with the RMAN
recovery catalog database.
Oracle provides support for copying both closed and open files for users who
have other mechanisms for creating image copies of data files.
files For example
example,
some sites store their data files on mirrored disk volumes. This enables the
creation of image copies simply by breaking the mirrors. After the mirror is
broken, RMAN can be notified of the existence of the copy. You must notify
RMANs recovery catalog when the copy is no longer available.
136
4-22
Backup sets
A backup set consists of one or more backup pieces. A backup piece is a

physical operating system file that contains the backed up contents of the data
files, control files, and archived redo logs that were specified in the backup
command. Each backup piece is comprised of a single output file and is written
serially. Each backup piece contains individual control and checksum
information that enable the Oracle server process to validate the correctness of
the backup piece during a restore.
137
If multiple output devices are available, you can partition backups so that
multiple backup sets are created in parallel. RMAN can also perform this backup
partitioning automatically.
A backup set is the complete set of backup pieces. It contains all of the data
from a full or incremental backup of the object specified in the backup command.
For example, the backup set created from a backup database command
contains all of the information that constitutes a full backup of the target
database.
RMAN does not combine data files and archive log files in a single backup set. If
you attempt to back up both data files and archive log files in a single backup
operation, RMAN creates a separate backup set for each.
4-23
A backup set containing archived redo logs is called an archivelog backup set.
With the exception of an attached stand-alone tape drive, RMAN cannot archive
directly to tape. However, RMAN does allow you to back up archived logs from
disk to tape. During recovery, RMAN also automatically stages the required
archived logs from tape to disk.
disk
Backup set compression
The server session RMAN invokes does not write any data file blocks that have
never been used to a backup set.
RMAN groups data blocks within the data file into buffers. When RMAN reads a
used data block in the buffer, it writes only the used block to the backup set.
However, when RMAN finds four adjoining buffers of unused input blocks, it
writes a compression block to the backup set. The size of the compression block
is defined by the DB_BLOCK_SIZE parameter specified in the init.ora file.
Propriety format
Because backup set data is stored in an RMAN-specific format, you must use
RMAN to restore the data.
138
4-24
139
Backup types
Data file backup sets can be full or incremental.
Full backups
A full backup involves one or more data files and contains all of the data files
data blocks. Archive log backups and control file backups are always full
backups.
Incremental backups
An RMAN incremental backup copies only those data file blocks that have
changed since a previous backup. This saves space on the backup storage
media; however, because all the blocks in a data file must be read to
determine whether their contents have changed, this does not necessarily
save time in the backup process. RMAN determines if a block has changed
by comparing the SCN recorded within the block with the checkpoint SCN of
the parent backup.
There are two types of incremental backups, differential (noncumulative) and
cumulative. Both are based on the level indicator integer defined within the
backup set. A level 0 incremental backup copies all blocks containing data
and is the basis for subsequent incremental backups, whether cumulative or
differential. Levels can range from level 0 to level 4. if you specify an
incremental level higher than 0 and no level 0 exists for the object, RMAN
automatically performs a level 0 incremental.
4-25
Differential incremental backups

A differential (noncumulative) incremental backup includes only those data
blocks that have changed since the previous incremental backup at the same or
lower level. This method consumes less storage space on the backup media
than does the cumulative incremental method; however, because all the blocks
in a data file must be read to determine whether their contents have changed,
this method does not necessarily save time in the backup process
process. If you do not
define an incremental backup set as cumulative, RMAN defaults to differential.
Sample differential incremental backup schedule
140
Consider the example in the table on the slide as a typical weekly backup
schedule. Because you want to conserve space on your backup media, you
decide to structure each days backup set as differential .
Differential incremental backups have the benefit of saving space on tape, but
can cause restores to be longer and more complex than cumulative backups.
For example, in the example on the slide, if a restore operation is required
between the Wednesday and Thursday incremental backups, it requires a
restore from the Sunday level 0, the Monday level 1, the Tuesday level 1 and
the Wednesday level 1 before applying any archived redo logs. If this were a
cumulative schedule, it would require only the Sunday and Wednesday
incremental backups before applying the logs.
4-26
Cumulative incremental backups

A cumulative incremental backup includes all the data blocks that were changed
since the last backup at a lower level only. Although cumulative incremental
backups can reduce the amount of work needed during a restore operation, this
method consumes more space on the storage media.
Sample cumulative incremental backup schedule
To illustrate the concept of a cumulative incremental backup schedule, consider

the example in the table on the slide as a typical weekly backup schedule.
141
Cumulative incremental backups typically require more space on media than

differential incremental backups; however they usually enable faster restore and
recovery. For example, in the example on the slide, if a restore operation is
required between the Wednesday and Thursday incremental backups, only two
backup sets are required for the restore. You need only the backup set from the
Wednesday incremental backup plus the backup set from the Sunday level 0
backup. You then apply archived redo logs, if applicable.
4-27
What is backed up?

RMAN backs up standard database objects at the data file and tablespace
levels.
It also backs up SPFILEs, control files and archived redo logs.
RMAN does not backup PFILEs or password files. Back these up separately
with file system backups.
RMAN also does not back up standard operating system files. Back these up
using Symantec NetBackup.
142
Online redo logs are not normally backed up; they are stored as archived redo
logs using the archive process.
4-28
Database backup set

A database backup set contains all control files and database files. It includes all
data blocks, regardless of whether they have been used.
A database backup can be performed while the database is open or closed. If

you want to perform a database backup while the database is open, it must be
running in ARCHIVELOG mode. If the database is running in NOARCHIVELOG
mode,
d RMAN d
does nott allow
ll
ad
database
t b
b
backup
k tto b
be performed.
f
d Th
Therefore,
f
close and mount the database before performing the database backup. The
instance must be started for RMAN to establish a connection for the backup.
143
For a database running in NOARCHIVELOG mode, RMAN can only perform a

complete database backup; it cannot accomplish tablespace and data file
backups.
The control file and the SPFILE are automatically backed up any time datafile 1
is backed up (any database backup, cold or hot).
4-29
Example: Database backup set: Full cold backup

If the database is in NOARCHIVELOG mode, the only supported backup types
are cold database backups. To perform a consistent backup, first shut the
database down.
To shut down and start up the database, use the RMAN commands or the
SQL*Plus utility.
144
4-30
Example: Database backup set: Incremental level 0 hot backup
In the example on this slide, the run command provides a block structure for
executing complex operations.
145
The allocate channel command establishes a connection to the target

database. Each connection operates on one backup set at a time. For each
channel, RMAN starts an Oracle server process to access the target
d t b
database
and
d an output
t t device.
d i
Multiple
M lti l channels
h
l provide
id th
the means ffor
parallel backups and restores.
There are two valid channel types: disk and a quoted string, such as
SBT_TAPE, which directs the backup to the media management API library.
Oracle version 9i enables you to simply specify type sbt instead of a
quoted string.
The format parameter is used to label the backup set pieces that are
written to disk or sent down a channel. This parameter can also be provided
to the allocate channel command, or as part of the backup
specification.
The level 0 incremental backup shown in the example performs the equivalent of
a full backup and provides a baseline for an incremental strategy.
4-31
It is important to ensure that each backup set piece has a unique name.
Formatting variables are listed in the following table:
Formatvariable
Function
%d
Specifiesthecurrentdatabasename
%n
Specifiesthedatabasename,paddedontherightwithxstoa
totallengthofeightcharacters
%t
Specifiesthebackupsetstimestamp
%s
Specifies the backup set number

Specifiesthebackupsetnumber
Thevalueofthisnumberisregisteredinthecontrolfileand
incrementsbyoneforeachbackupsetcreated.
%p
Specifiesthebackuppiecenumberwithinthebackupset
Thevalueofthisnumberstartsatoneandincrementsbyone
The
value of this number starts at one and increments by one
foreachbackuppiececreated.
%u
Specifiesaneightcharacternamecomprisedofashortened
versionofthebackupsetnumberandthetimethebackupset
wascreated
%c
Specifiesthecopynumberofthebackuppiecewithinasetof
d l db k
duplexedbackuppieces
%U
Identicalto%u_%p_%c
Ifnoothervariablesaredefined,bydefault,RMANuses%U.
Used together, %s, %p, and %t provide a unique ID for a backup set piece.
146
Note: It is recommended that you place the %t variable at the end of your
format string with no additional characters attached. On occasion, NetBackup
for Oracle attempts to determine a files timestamp based on the files name.
NBUO cannot do so if the timestamp is located in the middle of the format string
or if extra characters are attached to the %t (for example, t_%t).
4-32
A backup specification consists of a backup object list and a number of optional

parameters. In the example on the slide, the first backup specification consists
of the single backup object list database. The most common backup object lists
are:
BackupObjectList
Designates
Database
Alldatafiles,includingthecontrolfile
Tablespacename[,]
Alistofoneormoretablespaces
Datafilename[,]
Alistofoneormoredatafiles
A hi l
Archivelogall|specifier
ll |
ifi
A fil
Afilepatternthatcanthenbepipedthrougha
tt
th t
th b i d th
h
specifier
Thisspecifierdefinesthetimerangeorlog
sequencerangetobeusedtochoosewhicharchive
logstoincludeinthebackup.
C
Currentcontrolfile
t
t l fil
147
B k
Backsuponlythecurrentcontrolfile
l th
t
t l fil
4-33
Tablespace backup set

A tablespace backup set backs up all the data files belonging to a specified
tablespace. This is a more common practice than backing up individual data
files, although you may prefer that level of control.
When performing manual backups, back up read-only tablespaces shortly after

making them read-only. When executing a hot backup of a tablespace, you do
nott need
d to
t use the
th alter
lt
t
tablespace
bl
command
db
because RMAN
automatically records the SCN at the start of the backup.
148
With the exceptions of read-only and offline-normal tablespaces, tablespace

backups are normally performed while the database is open and running in
ARCHIVELOG mode.
The structure of a tablespace backup set is very similar to the full database
backup set
set.
The filesperset parameter defines the maximum number of input files

RMAN places in each backup set.
The format parameter specifies a unique name for the backup piece using
substitution variables. In this case, RMAN creates a backup piece named
aatst_; the underscore is followed by the backup sets number, then the
backup piece number within the backup set, and finally the timestamp.
4-34
Datafile backup sets

Datafiles can be backed up by specifying the number or name of the datafile as
shown in the examples on the slide.
To specify more than one datafile, separate the names with commas.
149
4-35
Control file backup set

Because the control file contains the information necessary to maintain and
verify database integrity, backing up the target databases control file is critical to
any backup strategy. Any time the schema (SQL-specified data definitions) of a
database are modified, back up the control file.
When an entire database backup is performed, the control file is included, by
d f lt
default.
Because the control file is a relatively small file, it is not normally backed up
individually. The control file can be added to another backup script using the
include statement, as shown in the following example:
150
RMAN>run{
allocate channel stream1 type 'SBT_TAPE;
backup tablespace tablespace_name
include current controlfile;
}
SPFILE backup set
As of Oracle9i, RMAN also provides a method to back up only the SPFILE.

RMAN>backup spfile
4-36
Archived redo log files backup set

Because the archived log files contain information about the actions that have
been performed upon the database, you should back them up regularly.
Remember that it is neither required nor recommended to back up the
databases online redo logs because restoring them can corrupt the database.
You can back up all of a databases archived redo log files by using the all
parameter
t in
i your backup
b k sett script.
i t
You can also specify ranges of archived redo log files to back up based on their
log sequence numbers or, more commonly, as a point-in-time backup based on
the log files timestamps.
151
After the archived redo log files are backed up, you can delete them to preserve
disk space.
4-37
Parallel backup streams

When you allocate multiple channels, you enable a single RMAN command to
read or write multiple backup sets in parallel. When backing up to tape, allocate
one channel for each physical device (3 tape drives = 3 channels). When you
back up to disk, allocate as many channels as necessary to enable maximum
throughput.
IIn addition
dditi tto th
the allocate
ll
t channel
h
l command,
d parallel
ll l b
backup
k streams
t
require one of the following:
152
A backup object list that explicitly lists multiple objects (tablespaces or data
files) along with a filesperset parameter that forces the generation of
multiple backup sets
Multiple backup specifications
When employed
Wh
l
d th
thoughtfully,
htf ll parallel
ll l b
backup
k streams
t
are d
desirable
i bl b
because
they enable faster backups and less database downtime. They are also an
efficient method to control backup operations.
4-38
Parallel example: Tablespace backup, backup with list

In the example on this slide, two channels of type SBT_TAPE have been
allocated, instructing RMAN to provide two communication paths between the
target database and NetBackup. However, both of these channels are used only
if there are multiple backup sets that can be backed up concurrently.
The filesperset parameter defines the maximum number of files to place in

a single
i l b
backup
k set.
t IIn this
thi case, th
the filesperset
fil
t 4 parameter
t notifies
tifi
RMAN to only multiplex (a maximum of) 4 files into each backup set.
153
When RMAN compares the filesperset parameter to the total number of

files needing to be backed up, divided by the total number of allocated channels,
it takes the lower of the two numbers, therefore guaranteeing that all channels
are used.
The backup command in this example contains only one backup specification
specification.
It contains a tablespace backup object list and two optional parameters. The
include current controlfile parameter orders RMAN to back up the
control file. Normally, the control file is automatically backed up whenever the
first data file in the system tablespace is backed up.
4-39
Parallel example: Tablespace backup, multiple files

The example on this slide is very similar to the previous example. Both use
parallel backup streams that enable concurrent data streaming. This is a result
of forcing the use of two channels. However, the examples differ in their
approach to incorporating this method. To fully understand this, let us examine
each example.
IIn the
th previous
i
example,
l RMAN uses b
both
th channels
h
l ffor b
backups.
k
Thi
This iis
because we have allocated multiple channels, and we have specified multiple
tablespaces (and multiple data files as a result).
154
Normally, RMAN attempts to back up the data files concurrently in a single

backup set. However, because the script specifies that only four files are
multiplexed into a single backup set, RMAN splits them into multiple sets. The
backup sets are then sent down the two channels in parallel (concurrently).
In the example on this slide, the script defines two backup specifications, each
of which generates a backup set. Because there are two backup sets, they are
backed up down the two channels concurrently, as well. Essentially, the script
performs the split for RMAN and specifies how RMAN is to push the data down
the channels.
4-40
This is Topic 4: RMAN configuration.

After completing this topic, you will be able to configure the database for RMAN
backups and restores. This includes:
Creating the RMAN user.
155
Managing aging of control file records.

Using the RMAN configure command.
command
4-41
Setting up the RMAN user
RMAN needs to access packages at the target database that exist in the SYS
schema. RMAN also requires the privileges needed to start up and shut down
the target database. Therefore, RMAN connections to the target database are
always performed as a SYSDBA user. By default, you can use the SYS account
(as SYSDBA) to run RMAN commands, but this is not recommended. Rather,
set up a separate user account for RMAN operations and grant the new account
SYSDBA privileges.
156
4-42
Managing control file records

Control File records are separated into two types: records that can be aged out
of the control file when they are no longer needed; and records that can never
be deleted.
Records that can be aged out or deleted from the control file are referred to as
circular reuse records. Records that are never deleted are called noncircular
reuse records.
d
157
RMAN records are circular reuse records and can be aged out of the control file
based on the CONTROL_FILE_RECORD_KEEP_TIME parameter in the
init.ora file. The default value is seven days. This means that information
about RMAN datafile and archived redo log backups can be deleted after seven
days if more space is needed for additional, newer circular reuse records. This
could be catastrophic if you choose to use the control file for your RMAN
repository. If your latest database backup is more than seven days old and has
been aged out of the control file, you can no longer use it for recovery!
Using the control file for the RMAN repository
If you choose to use the control file for your RMAN repository, set the
CONTROL_FILE_RECORD_KEEP_TIME to a value equal to, or greater than,
your backup retention period.
4-43
Using a recovery catalog for the RMAN repository
If you choose to use a recovery catalog for your RMAN repository, the
CONTROL_FILE_RECORD_KEEP_TIME should not be an issue. All the RMAN
records are copied to the recovery catalog and synchronized with the control file.
As long as the recovery catalog is synchronized with the control file at least once
during the CONTROL_FILE_RECORD_KEEP_TIME interval, the records are
safe and are never aged out of the recovery catalog automatically.
Many operations (including backups) cause the recovery catalog to

automatically be synchronized with the control file. Performing regular,
scheduled backups is one way to ensure the recovery catalog has current
records.
158
4-44
This is Topic 5: The RMAN recovery catalog.
After completing this topic, you will be able to configure the recovery catalog for
RMAN backups and restores.
159
4-45
Creating the recovery catalog user

If you decide to use a recovery catalog instead of the control file to store RMAN
metadata, identify or create a database on a different server than the target
database. Also, create a separate tablespace for the RMAN data.
After you select the database, create the RMAN user account and grant
privileges for CONNECT, RESOURCE, and RECOVERY_CATALOG_OWNER
t the
to
th new account.
t
160
4-46
Creating the recovery catalog

After the recovery catalog database has been identified (or created) and the
RMAN user has been created, you can create the recovery catalog itself.
At the RMAN prompt, use the CATALOG parameter (to indicate that you want
RMAN to connect to a recovery catalog) and connect to the catalog database as
the RMAN user that was set up previously. After the connection is established,
i
issue
th
the create
t catalog
t l
command:
d
RMAN>connect catalog rmanowner/rmanowner
RMAN>create catalog;
161
If you created a special tablespace for the recovery catalog schema objects,
specify that tablespace as follows:
RMAN> c
create
eate catalog
cata og tablespace
tab espace rmants;
a ts;
4-47
Registering an Oracle database with RMAN

Before you can use the RMAN recovery catalog for backup or recovery
operations with a particular database, register that database with the recovery
catalog. When you register a database, RMAN creates a record of it in the
recovery catalog. The database is identified in the recovery catalog by its
database identifier number. Oracle generates a unique database identifier
number when a database is first created
created.
Resynchronization
162
The recovery catalog metadata is obtained from the control file of the target
database. In order to maintain concurrence between the two, regularly
resynchronize the contents of the recovery catalog with the control file.
Resynchronization can be either full or partial.
F ll res
Full
resynchronization
nchroni ation
Full resynchronization synchronizes all changed data, including metadata
about the target databases physical structure, including data files,
tablespaces, and online redo logs.
To execute a full resynchronization, use the resync catalog command.
4-48
Partial Resynchronization
Partial resynchronization synchronizes changed data in the control file but
does not resynchronize metadata about the physical structure or rollback
segments of the Oracle database.
The commands in the following list execute either a full or partial

resynchronization. When you execute these commands, RMAN reads the
control file, but does not resynchronize the physical structures metadata unless
the information has changed. If RMAN determines that this information has
changed, it performs a full resynchronization. These commands are:
backup
restore
change
h
switch
it h
copy
recover
crosscheck
list
deleteExpired
report
duplicate
T ensure a full
To
f ll resynchronization,
h i ti
connectt tto th
the recovery catalog
t l and
d run the
th
resync catalog command. Resynchronize manually after changes to the
database structure such as:
Adding or dropping a tablespace
Adding a new datafile
Adding or dropping a rollback segment
Also, resynchronize manually when running in ARCHIVELOG mode. Remember,

automatic resynchronization is not performed for redo log switches or when a
redo log is archived.
163
4-49
Lesson summary
This lesson covered the architecture, command functions, and execution modes
of Oracles resource manager (RMAN). It also introduced specific commands
and their use. Finally, the RMAN repository and recovery catalog were described
along with the process for registering a database with the RMAN recovery
catalog.
R f
Reference
materials
t i l
164
Oracle Database Backup and Recovery Basics 10g Release 2 (10.2)

4-50
165
5-1
Lesson introduction
This lesson details the procedures for configuring Symantec NetBackup for
Oracle and creating policies to perform database backups using RMAN and the
NetBackup for Oracle agent.
Importance
The configuration
g
of NetBackup
p for Operators
p
is a key
y component
p
of this course.
NetBackup for Operators automates backup tasks and functions as a media
manager to control tape storage devices. In addition, NetBackup for Operators
manages the backup and recovery of all parts of the Oracle database, including
archive redo logs and control files.
166
5-2

After completing this lesson, you will be able to verify that NetBackup for Oracle
is supported on your OS or platform. In addition, you will be able to successfully
integrate NetBackup for Operators with target Oracle databases by configuring
NetBackup for Operators with RMAN, thereby significantly extending Oracles
backup and restore capabilities.
This llesson will

Thi
ill teach
t
h you to
t configure
fi
a NetBackup
N tB k policy
li that
th t uses the
th
NetBackup media manager for use with RMAN. You will also be able to create
RMAN and NetBackup for Oracle shell scripts and templates to establish a
backup strategy that suits your needs.
167
5-3
This is Topic 1: Verifying NetBackup for Oracle requirements.
After completing this topic, you will be able to verify operating system and
platform compatibility for the NetBackup for Oracle software.
168
5-4
Pre-configuration requirements
The NetBackup for Oracle agent is embedded in the server and client software
with NetBackup 7.x. It no longer requires a separate installation.
However, normal configuration of the NetBackup environment is still required.
The standard NetBackup server software must already be installed on the
master server and media servers.
The machine hosting the target database must have the NetBackup server or
client software installed.
169
Finally, a valid NetBackup for Oracle license key must be added to the master
server. To add the license key, use the Help > License Keys menu option, the
get_license_key utility (UNIX/Linux), or the command line option.
Note: See the Symantec NetBackup System Administrators Guide for additional
iinformation
f
ti on adding
ddi lilicense kkeys.
5-5
Verify NetBackup for Oracle compatibility

To verify operating system and platform compatibility:
1. Access the Symantec Support Web page at:
http://www.symantec.com/business/support.
2. Under Top Products, click NetBackup Enterprise Server.
3 In the list of documents
3.
documents, under Compatibility List,
List click NetBackup 7
Database Agent.
4. For information on supported cluster environments for NetBackup for Oracle,

click More and click NetBackup 7 Cluster Compatibility.
170
Note: If you are installing NetBackup for Oracle on a server that is part of a
NetBackup cluster, see the Symantec NetBackup for Oracle Administrators
Guide for additional instructions.
5-6
This is Topic 2: Configuring NetBackup for Oracle with RMAN.
After completing this topic, you will be able to integrate NetBackup for Oracle
with target Oracle databases.
171
5-7
Linking NetBackup for Oracle with Oracle
In order to write to sequential devices, such as a robotic tape device, Oracle

must have access to the shared library provided by NetBackup for Oracle.
Oracle uses this shared library when it writes to or reads from devices supported
by the NetBackup media manager.
172
Linking RMAN with the library provided by NetBackup for Oracle is the only
N tB k requirement.
NetBackup
i
t B
Before
f
writing
iti to
t sequential
ti l devices,
d i
such
h as ttape, th
the
Oracle server software must be linked with the media management API library
installed by NetBackup for Oracle on the client machine. The linking process is
only necessary for new installations of NetBackup for Oracle. It is not required
for upgrades of the NetBackup for Oracle software. (It is only necessary to
restart the Oracle instance for NetBackup for Oracle upgrades.)
The default location for the NetBackup API library is
/usr/openv/netbackup/bin. The name of the API library differs, depending
on your platform, as shown in the following table.
5-8
Platform
Oracle
LibraryName
AIX
64bit
libobk.a64
HPItanium
64bit
libobk.so
LinuxItanium
64bit
libobk.so
IBMpSeries
64bit
libobk.so
Solaris(SPARC)
64bit
libobk.so.64.1
Solaris(Opteron)
64bit
libobk.so.1
Linking methods
The automatic linking method is recommended; only use the manual method if
the automatic method fails or if you receive messages from Oracle indicating
that a manual relink is required.
The manual linking process is not consistent across hardware platforms and
Oracle server release levels. On some platforms (such as HP-UX), it is even
inconsistent across OS levels. Verify your client machines platform and OS
before performing the linking process. Consult the Symantec NetBackup for
Oracle Administrators Guide for step-by-step instructions for performing the
manual linking process.
173
5-9
Automatic linking using the oracle_link script

Automatic linking using the oracle_link script is the recommended method.
The script determines the Oracle version level and then links Oracle with the
NetBackup API library. It is highly recommended to shut down Oracle instances
and listener processes before linking, but it may be possible to perform linking
without doing so. See TechNote 158276: Is it necessary to shut down Oracle
when upgrading third-party
third party backup software such as the NetBackup for Oracle
extension? for more details.
The script writes output to /tmp/make_trace.pid. To change the trace file

location, change the MAKE_TRACE variable in the oracle_link script.
174
Linking rollback procedure
If you encounter problems and are unable to link Oracle with NetBackup for
Oracle,
O
ac e, you ca
can roll
o bac
back. For
o e
example,
a p e, if tthe
eo
oracle
ac e_link sc
script
pt (or
(o you)
moved libobk.so to libobk.so.back during the linking process, enter the
following commands to roll back this change:
1. As the Oracle user, change to the $ORACLE_HOME/bin directory.
2. $cp oracle0 Oracle
3. $cd $ORACLE_HOME/lib (or lib64 if using 64-bit Oracle software)
4 $mv
4.
$
libobk.so.back
lib
bk
b k libobk.so
lib bk
5-10
Creating a NetBackup schedule for Oracle backups

NetBackup for Oracle supports two types of schedules: application backup
schedules and automatic backup schedules.
Application Backup Schedules
An Oracle backup requires an application backup schedule. There is an

application backup schedule named default-application-backup
default application backup that is
automatically created when you configure the attributes component of the
NetBackup for Oracle policy and select the Oracle policy type.
175
The start window in the application backup schedule determines when

RMAN scripts on the client are enabled to invoke the NetBackup media
manager functionality controlled by the NetBackup servers. There are other
critical functions addressed in the application backup schedule that will be
discussed later in this lesson
lesson.
Automatic backup schedules

You can also create additional schedules in the NetBackup for Oracle policy
to configure automatic full or incremental RMAN backups. Automatic backup
schedules are optional if you prefer to invoke the RMAN scripts from a thirdparty scheduler or manually, by initiating the script from the command line on
the client.
5-11
This is Topic 3: Configuring a NetBackup for Oracle policy.
After completing this topic, you will be able to configure a policy that integrates
the NetBackup media manager with RMAN. Configuration of an Oracle policy
enables the administrator to automate RMAN backups to tape or disk.
176
5-12
Media management: The role of NetBackup for Oracle
RMAN can back up data to disk or a stand-alone tape drive under its own
control, but it requires the assistance of a third-party media manager to use a
robotic tape library for backups. NetBackup serves as this media manager. The
Oracle extension included with NetBackup (collectively known as NetBackup for
Oracle, or NBUO) integrates with RMAN to provide a complete backup and
recovery solution.
solution NBUO simplifies both backup and recovery of Oracle
databases and increases database availability.
177
The primary function of a media manager is to track all of the tapes used by
RMAN for backups and to manage the mounting and unmounting of those
tapes. NBUO performs these functions and many others. The Oracle server
process allocated for a channel invokes that API to open a data stream, and the
call is then serviced by NBUO, which then locates and mounts a tape.
The integration of RMAN and NetBackup for Oracle is a two step process:
1. Link an API published by Oracle and implemented by NBUO (covered in the
previous lesson).
2. Configure a NetBackup for Oracle policy.
5-13
NetBackup for Oracle policy requirements
A NetBackup for Oracle policy has special requirements that make it different
from a normal file system backup policy. The differences are discussed in detail
in this lesson.
178
5-14
The policy attributes component

The policy type of an Oracle policy must be set to Oracle in the attributes
component. Setting the policy type to Oracle causes other NetBackup for Oracle
policy requirements, such as an application backup schedule, to automatically
be created and enables RMAN scripts to invoke the media manager.
If you have a specific storage unit you wish to assign to your RMAN backups,
you can specify
if it h
here. Y
You can also
l specify
if th
the storage
t
unit
it iin th
the application
li ti
backup schedule.
179
Note that many of the settings in the attributes component are disabled for
Oracle policy types. The Keyword phrase attribute, even though it is not
disabled, is ignored for Oracle policy types.
Note: The Oracle policy type is not displayed in the Policy type list unless a
valid NetBackup for Oracle license key has been installed on the master server
server.
5-15
The application backup schedule

An application backup schedule named default-application-backup is created by
default and contains several critical settings for your NetBackup for Oracle
backup policy.
Schedule window
The start window must encompass all of the periods during which RMAN is
able to start backup jobs. Typically, start windows in application backup
schedules are configured to be open 24 hours per day, seven days per week.
This ensures that your NBUO operations are never locked out due to a
closed window.
180
Multiple copies
The Multiple copies option enables you to configure multiple copies of
RMAN b
backups
k
tto diff
differentt d
destinations
ti ti
(diff
(differentt storage
t
units
it and
d volume
l
pools). It also enables you to configure a different retention period for each
copy. However, each storage unit selected must be managed by the same
NetBackup media server.
Override Storage Unit and Volume Pool

You can specify the storage unit and volume pool for your RMAN backups in
the policy attributes or here in the application backup schedule
schedule.
5-16
Backup retention
The Retention setting in the application backup schedule determines how
long your RMAN backups are to be maintained in the NetBackup catalogs.
When a backup image expires based on the retention period set here, it is
d l t d only
deleted
l ffrom th
the N
NetBackup
tB k catalogs:
t l
references
f
tto the
th backup
b k are nott
deleted from the RMAN repository. It is necessary to use RMAN commands
to delete references to the expired backups when enabling NetBackup to
manage backup expiration in this manner.
You may prefer to manage the expiration and deletion of backup images
through RMAN. When a request is issued to delete a backup file from an
RMAN repository, RMAN sends a request to NetBackup for Oracle to delete
the corresponding image from the NetBackup catalogs. To manage backup
images using RMAN repository commands, set the retention period in the
application backup schedule to infinity to prevent the expiration of backup
images from the NetBackup catalogs until commands are initiated through
RMAN utilities.
Multiplexing
Multiplexing settings are configured in the application backup schedule

schedule.
Multiplexing must also be configured for the selected storage unit.
181
5-17
Automatic backup schedules

Automatic backup schedules are required if you wish NetBackup to perform
scheduling tasks for your RMAN backups. The purpose of the automatic backup
schedule is to determine when the backups will start (day and time) and which
type of backup will be performed.
Automatic full backup

A full backup copies all blocks into the backup set, skipping only datafile
blocks that have never been used.
182
Automatic differential incremental backup

In a differential level n incremental backup, you back up all blocks that have
changed since the most recent backup at level n or lower.
Automatic cumulative incremental backup

In a cumulative level n incremental backup, you back up all blocks that have
changed since the most recent backup at level n-1 or lower.
5-18
Automatic backup schedule properties

Automatic backup schedules are used to automate RMAN backups. The
automatic backup schedule causes the RMAN script specified in the policy to be
invoked on the client, which results in the use of the application backup
schedule.
183
Type of backup
This setting specifies the type of backup that this schedule controls. The
selection list shows only the backup types that apply to NBUO policies. The
type of backup (full, differential, or cumulative) is passed to the invoked script
so that different RMAN configurations are used based on which type of
schedule invoked the job.
Schedule method
You select
Y
l t th
the method
th d used
d tto iinitiate
iti t automatic
t
ti RMAN b
backups
k
iin th
the
automatic backup schedule. Select either a frequency-based schedule or a
calendar-based schedule.
Frequency-based schedule
Frequency specifies the period of time that elapses until the next backup
operation can begin on this schedule. For example, if the frequency is seven
days and a successful backup occurs on Wednesday,
Wednesday the next full backup
does not occur until the following Wednesday.
5-19
Calendar-based schedule
The Calendar option enables you to schedule backup operations based on
specific dates, recurring week days, or recurring days of the month.
Start window
The Start window in the automatic backup schedule determines the day and
time that the backup is initiated. A start window is mandatory for both
frequency-based and calendar-based schedules. Automatic backups are not
initiated by the NetBackup scheduler without a start window.
Retention
As discussed previously, the retention period for an application backup
schedule refers to the length of time that NetBackup keeps backup images.
The retention period for an automatic backup schedule controls how long
NetBackup keeps records of when scheduled backups have occurred.
The NetBackup scheduler compares the latest record to the frequency to
determine whether a backup is due. This means that if you set the retention
period to expire the record too early, the scheduled backup frequency will be
unpredictable However,
unpredictable.
However if you set the retention period to be longer than
necessary, the NetBackup catalog will accumulate unnecessary records.
Therefore, set a retention period that is longer than the frequency setting for
the schedule.
Multiple copies
Multiple copies are not configured in an automatic backup schedule.
Storage units and volume pools

Storage unit and volume pool settings are not configured in the automatic
backup schedule.
Multiplexing
Multiplexing is not configured in the automatic backup schedule.
184
5-20
Backup selections
The Backup selections list in an NBUO policy has a different meaning than the
backup selections list has for other policies. In a standard policy, you list files
and directories to be backed up. But, because you are now configuring a
database policy, you list templates or scripts.
All templates or scripts specified in the backup selections list are executed
d i manuall or automatic
during
t
ti b
backups.
k
N
NetBackup
tB k starts
t t b
backups
k
b
by running
i th
the
templates or scripts in the order that they appear in the backup selections list.
185
Shell scripts
When listing Oracle scripts, specify the full pathname. For example:
/oracle/scripts/cold_database_backup.sh.
Also ensure that the Oracle scripts listed here are installed on each client in
the client
th
li t lilist.
t
Templates
Because templates are stored in a known location on the master server, only
the template file name should be entered. For example:
weekly_full_backup.tpl.
5-21
The client list
In the client list in the NetBackup for Oracle policy, specify only the Oracle
clients to be backed up at the same time using the specified script or template in
the backup selections list.
186
5-22
NetBackup for Oracle backup with queued jobs

The screenshot of the NetBackup Activity Monitor in this slide demonstrates the
default action if you configure a policy as described in the previous pages of this
lesson and initiate a backup.
Here, a NetBackup for Oracle policy named ora_hot has initiated three backup
jobs. In the State column you can see that two of the jobs are active and one is
queued.
d
Note that one of the active jobs has been initiated by an automatic backup
schedule named full_sched.
187
The automatic backup schedule is invoked by the NetBackup scheduler process

and always enters the job queue first (remember that it causes the RMAN script
to execute on the target database server). It continues to show an Active state
until all the jobs initiated by the default
default-application-backup
application backup schedule complete
complete.
Notice that two of the three jobs were initiated by the default-application-backup
schedule. There is a default-application-backup schedule job for each channel
allocated in the RMAN script. The RMAN script invoked by this policy specified
two channels and is attempting to perform a parallel backup of the target
database. However, the queued default-application-backup schedule job
indicates that NetBackup has not yet been configured to enable this client to
perform parallel backups.
backups This feature is known as multiple data streams in
NetBackup terminology.
5-23
Configuring multiple data streams for a policy

One way to configure a NetBackup client to perform parallel backups is to set
the Maximum jobs per client global attribute to a value greater than one.
The Maximum jobs per client global attribute determines the maximum
number of parallel backup streams for every client in the NetBackup domain.
Because Oracle internally determines when and how many streams to run in
parallel
ll l in
i order
d to
t optimize
ti i performance,
f
the
th number
b off jobs
j b is
i difficult
diffi lt tto
determine for Oracle backups and restores. Set the maximum to a value greater
than one to gain any benefit from allocating multiple channels in your RMAN
script.
188
Tip: To avoid problems, enter a value of 99 for the Maximum jobs per client
global attribute .
Note: The Maximum number of concurrent backup streams allowed per
client property in the client attributes enables you to configure multiple data
streams on a per-client basis. You can find client attributes in the list of
properties for the master server.
The Allow multiple data streams option must also be selected in the policy
attributes.
5-24
This is Topic 4: Managing the runtime environment.
After completing this topic, you will be able to manage the runtime environment.
189
5-25
Runtime order of precedence

When a NetBackup for Oracle backup is initiated by an automatic backup
schedule, information about the NetBackup server, the policy, and the type of
backup is automatically passed to the RMAN script as arguments at runtime.
However, if you prefer initiating the NBUO backups from the client, either
manually (by executing the script from the command line) or from the
NetBackup client interface,
interface use one of the following methods to configure the
required runtime configuration for the RMAN script.
The slide lists the order of precedence for the runtime configuration variable
settings.
190
5-26
NBU-set environment variables

When a NetBackup for Oracle backup is initiated by an automatic backup
schedule, NetBackup passes the variables listed in the table on the slide to the
invoked RMAN script.
These variables are used to perform conditional operations within the scripts.
They are set only if the backup is initiated from the master server, either
automatically
t
ti ll b
by th
the N
NetBackup
tB k scheduler
h d l or manually
ll th
through
h th
the N
NetBackup
tB k
Administration Console.
191
5-27
Setting Oracle environment variables through a listener

When accessing a database through a listener, the environment variables set at
the system level are not visible while RMAN is running. To specify those
variables, connect to the database using a transparent network substrate (TNS)
alias and use either a send command or a parms operand.
The way to set environment variables depends upon the version of Oracle you
are using.
i
B
Both
th th
the send
d command
d and
d th
the parms operand
d can b
be d
defined
fi d
within an RMAN script, as described in the example on the slide.
For Oracle 8.1.x and later versions:
192
Use the send command to send a vendor-specific quoted string to NBUO.
Specify the string variables in the RMAN script after all channels have been
allocated and before the backup command.
Use the send device type command to send the variables to all
channels of the specified type. Use the send channel command to send
the variables to specific channels.
See the Symantec NetBackup for Oracle Administrators Guide for more
information on Oracle 8.0.x and Oracle 8.1.x and the parms operand.
5-28
User-set environment variables

A user logged in on the Oracle client can define NBUO variables in the Oracle
environment as shown in the table on the slide.
Note: If these variables are undefined, they default to the first available Oracle
backup policy and schedule found in the NetBackup catalogs. If the type of
backup is undefined, the default is a level 0 incremental backup.
Users can initiate NBUO backups from the Oracle client in the following ways:
193
Use the NetBackup Administration Console provided with NetBackup for

Oracle (jnbSA).
Use the NetBackup client interface (jbpSA) and initiate the backup as a
user-directed backup
Use the RMAN command line or run an RMAN script.
5-29
Using the bp.conf file
A NetBackup for Oracle user can create a bp.conf file in the Oracle users
home directory on the client. When a NetBackup for Oracle operation is started,
the users bp.conf file is searched before the client bp.conf file in
/usr/openv/netbackup. Any option found at the user level takes precedence
over the same option in the client bp.conf file. The following table describes
the options that can be set in the users
user s bp.conf file.
194
Option
Description
BPBACKUP_POLICY
ThisoptionspecifiesthepolicytousefortheOracle
backup.
BPBACKUP_SCHED
Thisoptionspecifiesthenameoftheapplication
backupscheduletypetousefortheOraclebackup.
CLIENT_NAME
ThisoptionspecifiesthenameoftheOracleclient.It
isespeciallyusefulforaredirectedrestoreoperation.
CLIENT_READ_TIMEOUT
(optional)
Thisoptionspecifiesthenumberofsecondsthe
Oracleclientinitiallywaitsforaresponsefromthe
NetBackup server The default value is 900
NetBackupserver.Thedefaultvalueis900.
5-30
This is Topic 5: Using shell scripts.
After completing this topic, you will be able to create backup shell scripts for
use with NetBackup for Oracle.
195
5-31
Creating shell scripts and templates

RMAN templates and RMAN shell scripts contain commands that are used to
execute NetBackup for Oracle backup and recovery jobs. You create templates
and scripts before NetBackup for Oracle can perform scheduled backups. These
are the template files or shell scripts that are specified in the backup selections
during policy configuration .
196
Sh ll scripts
Shell
i t
Shell scripts are written by the user and must conform to RMAN and UNIX
shell syntax. Sample backup and recovery shell scripts are installed on the
client with the NetBackup for Oracle agent. Modify these scripts to meet your
individual requirements.
Templates
Th NetBackup
The
N tB k for
f Oracle
O l backup
b k wizard
i d iis used
d tto create
t b
backup
k
templates. This wizard is initiated from the NetBackup Backup, Archive, and
Restore (BAR) interface. The NetBackup for Oracle backup wizard does not
support all of the RMAN commands and options provided by Oracle. Write a
customized shell script for situations where a template does not provide all of
the required functionality.
5-32
Sample backup shell scripts

NetBackup for Oracle provides sample RMAN scripts with a shell script wrapper
that you can customize to suit your environment.
When working with these sample scripts, perform the following:
1. Copy the sample scripts to a different directory on the client.

These scripts can be located anywhere on the client. This keeps the original
files intact in case you need to reference them in the future.
197
2. Modify each script (in the new location) for your specific environment.
The scripts have good commentary to provide guidance on which variables
and commands to modify.
3. Ensure the su command logs onto the correct user.
If you do not include an su user statement (where user is the Oracle
administrator
d i i t t account)
t) in
i th
the scripts,
i t they
th do
d nott run with
ith th
the proper
permissions and environment variables. This results in problems with your
database backups and restores.
4. The sample scripts write to an output files named scriptname.out. Use
these output files as your first tool when debugging failed backups.
5-33
Sample NetBackup for Oracle RMAN script
The shell script excerpt in the slide shows a small segment of the
hot_database_backup.sh script. This shell script assumes the following:
198
You are backing up your database to two tape drives.
You want each backup set to include a maximum of 5 files.
You wish to include offline datafiles and read

read-only
only tablespaces in the backup.
backup
You want the backup to continue if any files are inaccessible.
You are not using a recovery catalog.
You want to archive the current log and back up all the archive logs using
two channels, placing a maximum of 20 logs in a backup set, and deleting
them after the backup is complete.
The scripts explicitly back up the control file to ensure this current backup is
registered in a control file that has also been backed up. Because you are
specifying NOCATALOG by default, the control file backup that occurs
automatically as the result of backing up the system file is not sufficient; it does
not contain records for the backup that is currently in progress.
The format string is constructed to guarantee uniqueness.
5-34
This is Topic 6: The NetBackup for Oracle backup wizard.
199
Use the NetBackup for Oracle backup wizard to perform immediate backups.
Create reusable templates that you can run as is or convert to shell scripts.
5-35
The NetBackup Backup, Archive, and Restore (BAR) interface

The NetBackup for Oracle backup wizard is accessed using the NetBackup
Backup, Archive, and Restore interface. To access the Backup, Archive, and
Restore Interface:
1. Type jbpSA from the UNIX command prompt.
2. Log in to the Backup, Archive, and Restore interface.
Because the login you use is the account accessing the target database to
perform the backup, log in to the interface as an Oracle user with
administrative privileges.
200
5-36
Launching the NetBackup for Oracle backup wizard

To access the NBUO Backup Wizard:
1. Click the Backup Files tab at the top of the interface.
2. In the left pane of the Backup, Archive, and Restore interface, select the
Oracle instance as shown in the slide.
3 In the right pane
3.
pane, select the Oracle objects to back up
up.
4. Click the Backup button.
The wizard launches and the Welcome screen is displayed.
201
5. Click Next and complete all steps in the wizard.
5-37
Creating backup templates using the NetBackup for Oracle backup wizard
The backup wizard displays configuration screens that correspond with the
steps in the table on the slide. Templates are saved on the master server.
1. Specify whether you wish to use OS or Oracle authentication.
If you specify Oracle authentication, specify the user and password of the
account. In the first configuration screen, indicate whether you wish to use a
recovery catalog.
t l
Th
The d
default
f lt is
i to
t use the
th control
t l file
fil ffor th
the repository
it
information.
2. If you opt to use a recovery catalog, fill in your recovery catalog credentials
and connection information.
202
3. Specify whether you wish to back up archived redo logs.

You can specify all logs or a range of logs. You can also check an option to
have the archived redo logs deleted after the backup
backup.
4. Enter the remaining configuration information.
The rest of the configuration can be obtained from a template you have
saved from a previous session. Either specify a saved template or select the
option to use defaults for the remaining configuration screens.
5. If you wish to override the naming default for backup pieces, specify format
options.
5-38
6. Specify whether to perform the backup with the database open or closed.
If performing a tablespace or datafile backup, opt to shut down the database
before the backup.
7. Specify runtime parameters, such as the policy name, application-backup
schedule
h d l name, master
t server, and
d client
li t name .
8. Specify backup limits, such as maximum backup piece size, maximum
number of open files, and number of parallel streams (channels).
9. The summary screen offers you options to run the backup immediately and
save the template for later use.
203
5-39
Using preconfigured templates
To reuse saved templates from the wizard, select Actions > Administer
Templates from the BAR interface. This enables you to use the templates
without having to step through the first few configuration screens. You can run,
edit, or delete templates from this option.
204
5-40
Converting backup templates to shell scripts using bpdbsbora

The bpdbsbora command is a NetBackup for Oracle command line utility used
to initiate template-based, user-directed backup and recovery. This utility is also
used to generate RMAN shell scripts from templates created by the backup
wizard.
The following options are supported:

-g script_file_name
205
This option generates a shell script from a template. Enclose

script_file_name in quotes if it contains blanks. This option may not be
used with the run option.
-t template_name
This option identifies the template. Because bpdbsbora retrieves backup
templates from a known location on the master server, you only need to
specify the template name.
5-41
This is Topic 7: Testing the NetBackup for Oracle configuration.
206
Test the NetBackup for Oracle configuration.
Troubleshoot a failed NetBackup for Oracle configuration.
5-42
Performing RMAN backups with NetBackup for Oracle

For testing, the easiest way to initiate a backup is to invoke RMAN directly from
the command line as the Oracle user on the target database host.
After you specify the correct policy type, the NetBackup scheduler initiates the
backup in accordance with any defined schedules. You can also perform a
manual backup of a configured Oracle policy, if necessary.
207
A database user on the client system can initiate a backup by running a

preconfigured script, such as a modified sample script provided by the
NetBackup for Oracle installation. As with standard backup procedures, the
NetBackup administrator must predefine an appropriate application backup
schedule to allow this.
Backups can also be initiated from a cron job. To set runtime variables, use
bp conf file entries or edit the RMAN script to include the send command.
bp.conf
command
5-43
Testing the scripts and templates

To test the configuration settings on a UNIX server:
1. Log on to the server as root and start the NetBackup Administration Console.
2. In the left pane, click Policies.
The right pane splits into an All Policies pane and a Details pane.
3 In the All Policies pane,

3.
pane click the policy you wish to test
test.
208
4. From the Actions menu, click Manual Backup.

The Manual Backup dialog box is displayed. The Schedules pane contains
the name of the schedules configured for the policy you are going to test.
The Clients pane contains the name of the clients listed in the policy you are
going to test.
5. Follow the instructions in the dialog box.
6. Click Activity Monitor on the NetBackup Administration Console.
5-44
Using logs to troubleshoot NetBackup for Oracle

There are a number of useful files and logs you can use when troubleshooting
NetBackup for Oracle.
Sample script output file
If you customize and use the sample scripts provided by NetBackup for
Oracle, start the troubleshooting process by viewing the output file the scripts
create in the local directory (directory where the script is initiated). This file
contains important trace information and RMAN message log output that will
help you identify where in the backup processing the failure occurred.
209
The RMAN message log

If you create your own scripts or run RMAN commands directly from the
command line, you can add send RMAN log information to a file using the
msglog
l
l fil
logfilename
syntax
t in
i your RMAN script.
i t
NetBackup troubleshooting logs

NetBackup logs can be useful for troubleshooting as well. Create the logs as
described in the slide and set the access permissions on the client
NetBackup logs to 777.
Note: The Oracle Alert Log and Trace files also contain useful details about
RMAN errors.
5-45
Useful NetBackup logs

Client logs
The following client logs are useful when debugging NetBackup for Oracle
issues:
dbclient
The dbclient log contains debugging information and execution status for the
Oracle NetBackup client processes linked to the library program provided
with NetBackup for Oracle.
210
bphdb
bphdb logs have the format obk_stdout.mmddyy. NetBackup writes
NetBackup for Oracle template or shell script output to this file. bphdb is the
NetBackup
p database binary.
y It is used for Oracle template
p
or shell script
p
execution.
bpcd
The bpcd process handles server authentication when backups or restores
are started. The bpcd log is a useful tool for finding information about name
service issues and other communication problems.
5-46
bpdbsbora
The bpdbsbora process is used when you use the NetBackup for Oracle
backup and recovery wizard and any time a template is run (automatically or
manually). The log file contains debug and status information when those
methods
th d are used
d tto perform
f
a backup
b k or a restore.
t
Log
L iinformation
f
ti iis also
l
generated when you use the bpdbsbora command line option.
Server logs
You can also use NetBackup server logs for NetBackup for Oracle
troubleshooting. nbpem, nbjm, nbrb, and bprd are good places to look for
communication or resource errors. nbpem, nbjm, and nbrb use unified logging
and must be viewed with the vxlogview utility.
211
5-47
212
Troubleshooting suggestions
1. If you receive errors backing up the target database the first time, test a
regular file system backup on the client using NetBackup. This is a good way
to troubleshoot standard communication problems and bp.conf
configuration errors. See the Symantec NetBackup Troubleshooting Guide
for more information on troubleshooting a standard backup.
If file system backups are successful, begin troubleshooting NetBackup for
O
Oracle
as follows:
f
2. Run an RMAN backup to disk from the command line to verify RMAN
functionality. Use the RMAN message log for troubleshooting help.
3. If RMAN works alone, troubleshoot RMAN with NetBackup for Oracle.
Create the NetBackup logs suggested on the previous pages and ensure the
logs have permissions set to 777.
4. Check for linking problems.
Run an RMAN backup to tape from the command line.
After the backup attempt, check for the existence of a dbclient log file.
If a log file exists it indicates that Oracle and NBUO are linked correctly
and the problem is not a linking problem.
If no log file exists, check the permissions on the dbclient log directory to
ensure they are set to 777. If the permissions are correct, the problem is
usually
y a linking
gp
problem.
5-48
5. Check the logs for communications errors.

If the dbclient log file exists, the problem may be a problem with NetBackup
server and client communication. Check the bprd logs on the Master Server
and the bpcd logs on the client for clues. Also verify the bp.conf settings on
th client.
the
li t (If you troubleshoot
t bl h t a standard
t d d file
fil system
t
backup
b k on th
the client
li t
using NetBackup for Oracle, this step is unnecessary.)
If backups to tape succeed from the RMAN command line, the problem is
most likely an Oracle policy configuration error. Examine the policy
thoroughly ensure you specified the correct policy type. Also, verify the script
path and name in the backup selections component are spelled correctly.
See the Symantec NetBackup for Oracle Administrators

Administrator s Guide for more
information on troubleshooting linking problems.
213
5-49
Lesson summary
This lesson provided in-depth information on how to integrate NetBackup for
Oracle and RMAN to configure RMAN backups to disk or tape. Through
thoughtful planning, scheduling, and the effective use of RMAN and NetBackup
for Oracle shell scripts, you are now able to establish a backup strategy that
suits your particular needs.
R f
Reference
materials
t i l
214
Symantec NetBackup System Administrators Guide for UNIX and Linux,

Volume I
Symantec NetBackup Troubleshooting Guide
Symantec
y
NetBackup
p 7.x Database and Application
pp
Agent
g
Compatibility
p
y List
NetBackup 7.x Cluster Compatibility List
TechNote 158276: Is it necessary to shut down Oracle when upgrading thirdparty backup software such as the NetBackup for Oracle extension?

5-50
215
NetBackup 7.x for Oracle
6-1
Lesson introduction
This lesson outlines the procedures for recovering a failed Oracle database.
This includes recovery of an entire database as well as recovery of component
parts of a database. This lesson also introduces scripts used to support basic
recovery operations.
Importance
216
Knowing the basics of Oracle database recovery helps you return a failed
database to full operation, keeping downtime to a minimum. This lesson also
serves as an introduction to more advanced restoration and recovery
operations, such as performing incomplete recoveries, managing the recovery
catalog effectively, and correcting failures caused by user errors.
6-2
After completing this lesson, you will be able to perform basic restorations of
complete Oracle databases, as well as restoration of individual components,
such as datafiles, tablespaces, control files, and archived redo logs. You will also
be able to use scripts to support basic recovery operations.
217
6-3
This is Topic 1: Restore operations.
218
Restore and recover a database.
Restore an individual tablespace.
6-4
Restore and recovery

Database recovery is required after a database failure. A restore is the
replacement of lost or damaged files with backup copies. For some failures,
Oracle can perform recovery without restoring any data from backups. For
example, during an instance failure in an Oracle Parallel Server (OPS)
configuration, a surviving instance can apply redo logs to the crashed instance.
However, if any off th

H
the files
fil th
thatt comprise
i th
the physical
h i l structure
t t
off th
the d
database
t b
are damaged, or if the database needs to be recovered to a point in time prior to
a logical corruption, a restore is required first, followed by a recovery. Recovery
involves rolling the restored files forward in order to reconstruct lost changes.
219
6-5
The database recovery process
When you first notice that your Oracle database has failed, immediately back it
up. This gives you a fallback position in case your recovery efforts make a bad
situation worse. After the backup completes, focus on correcting the problem.
220
6-6
Preparing the database

The first step in recovering a database is to determine exactly which parts of the
database are damaged. This is accomplished using Oracle diagnostic tools,
such as trace files and the alert log file.
If the database failure is a result of media failure, you need to perform

restoration operations. You must also determine the extent of the media failure
so you can decide
d id whether
h th tto restore
t
tto th
the original
i i l llocation
ti or tto an alternate
lt
t
location.
221
If the database was running in ARCHIVELOG mode before the failure, it should
be possible for you to recover the database to the point in time just before the
failure occurred. This is possible only if you have a complete set of archived log
files available. Assuming the recovery catalog is housed on a separate machine
and that machine has not failed, this is entirely possible.
If, however, the database was running in NOARCHIVELOG mode (or if the
recovery catalog or control file have also failed and are not recoverable), you are
only able to recover the database to the state it was in at the time of its last
complete cold database backup. In this case, it is not possible to roll the
database forward to the time when the failure occurred.
6-7
Restoring the data

If online backups are available and the database was running in ARCHIVELOG
mode before the failure, you do not need to restore the entire database. You
only need to restore the corrupted or damaged files.
RMAN restores from full backups, level 0 incremental backups, and data file
copies. It does not restore from level 1 or higher incremental backups. These
l
levels
l are used
d tto rollll th
the d
database
t b
fforward
dd
during
i recovery.
222
The method you choose for restoration depends, in part, on how you have
performed your backups. With proper planning and execution of a backup
strategy, well planned backup sets, and readily available media, you can keep
database downtime to a minimum.
6-8
Recovering the database
When performing a recovery, RMAN first attempts to use any available

incremental backups before applying transactions from the archived and online
redo logs. This rolls the database forward to the point of failure. Uncommitted
transactions (changes that have not been saved to the database) must be rolled
back using rollback segments. These recovery steps are automatically executed
by Oracle when you instruct RMAN to perform a recovery
recovery.
223
RMAN performs the actual recovery process, but NetBackup for Oracle is used
to manage restore and recovery operations. You can also use scripts to
automate some restore and recovery operations. Sample scripts are presented
later in this lesson.
6-9
Using RMAN for recovery
When you initiate recovery using RMAN to restore a particular database,

tablespace, or datafile, RMAN queries the recovery catalog to determine the
most appropriate backup set or image copy to use. Because image copies are
quicker to restore, RMAN prefers to use them over backup sets.Image copies
only require a switch command.
224
All specifications
ifi ti
(f
(from_tag,
t
f
from_type,
t
and
d until_clause)
til l
) mustt be
b
satisfied before a backup set or file copy is selected for restoration. RMAN also
considers the device types (disk, SBT_TAPE) of the allocated channels when
performing automatic selection. If no available backup set or image copy in the
recovery catalog satisfies all of the specified criteria, RMAN returns an error
during compilation of the restore job.
6-10
Restoring the database

Restoring and recovering a database from the most recent backups is quite
simple if you have your control file and online redo logs available. This is the
case if the restore was required because of a user error that corrupted the
database data.
The loss of the control file is more serious and is discussed in a later lesson.
If the database is in ARCHIVELOG mode, and the online redo logs are missing
or damaged, you can still recover the information available in the archived redo
logs. This scenario and point-in-time recovery are discussed in a later lesson.
225
If the database is in NOARCHIVELOG mode and the online redo logs are
missing, use options to recover without applying any redo records. Then use the
alter database open resetlogs; command to restart when the
database opens after the recovery.
recovery
6-11
Recovering a single tablespace: Tablespace is corrupt

In the example shown in the slide, a single tablespace, ts1, is corrupt. Because
the script does not shut down the database, it remains open and users can
access other tablespaces. You must be in ARCHIVELOG mode to perform
tablespace level restore and recovery.
The script performs the following functions:
1. It allocates a channel for restoring the backup sets.
2. It takes the damaged tablespace offline.
226
3. It restores the data files in the tablespace from backup.

RMAN first attempts to use an image copy of the data files. If none are
available, RMAN uses the most recent full or level 0 incremental backup.
4. It uses any available level 1 or higher incremental backups in order to bring
the data files to as close to the current time as possible. It then automatically
applies archived and online redo logs, as required.
5. After the recovery completes, the script brings the tablespace back online
and releases the allocated channel.
6-12
This is Topic 2: Shell scripts and templates.
After completing this topic, you will be able to create RMAN recovery shell
scripts and templates for use with NetBackup.
227
6-13
Sample recovery shell scripts

The sample recovery shell scripts are located in:
/usr/openv/netbackup/ext/db_ext/oracle/samples/rman
When working with these sample scripts, perform the following:
1. Copy the sample scripts to a different directory on the client.

These scripts can be located anywhere on the client
client. This keeps the original
files intact in case you need to reference them in the future.
228
2. Modify each script (in the new location) for your specific environment.
The scripts contain useful commentary to provide guidance on which
variables and commands to modify.
3. Ensure the su command logs onto the correct user.
If you do not include an su - user statement (user is the Oracle
administrator account) in the scripts, they will not run with the proper
permissions and environment variables. This results in problems with your
database backups and restores.
4. To assist in debugging, ensure your scripts write to an output file.
6-14
Accessing the NetBackup for Oracle recovery wizard

The NetBackup for Oracle recovery wizard is launched from the Backup,
Archive, and Restore interface. You can access the interface through the
NetBackup Administration Console or from the command line.
To start the interface from the NetBackup Administration Console, click Backup,
Archive, and Restore in the left pane of the console. To start the interface from
th command
the
d liline ttype jbpSA.
jb SA
The recovery wizard can be initiated from the server or client: be sure to specify
the database server (client) as the host when you log in.
229
Before launching the recovery wizard must perform the following steps in the
Backup, Archive and Restore interface to prepare for the recovery:
1. Start the NetBackup Backup, Archive, and Restore interface.
2. Click the Restore Files tab.
6-15
Select the source client, destination client and policy type

Before launching the recovery wizard specify the policy type and the source and
destination client. The Oracle wizard does not launch properly if the policy type
selected is not Oracle:
1. Select Actions > Specify NetBackup Machines and Policy Type from the
menu options at the top of the interface.
2. Click the Source client/Policy type tab.
3. Select your Oracle client from the Source client for restores drop-down list
and select Oracle from the Policy type for restores drop-down list.
230
4. Click the OK button to save your selections.
6-16
Launching the NetBackup for Oracle recovery wizard

After you have selected the source client, destination client, and policy type you
are ready to select the database to be recovered and launch the recovery
wizard:
1. Expand the Oracle node in the left pane to view the Oracle instance
hierarchy.
2. Select a node in the left pane to view details in the right pane.
3. Click the Restore button to launch the wizard.
231
6-17
Creating recovery templates using the NetBackup for Oracle recovery

wizard
NetBackup for Oracle includes a recovery wizard that solicits information from
the user about the desired RMAN restore and recover operations. The wizard
uses the information to create a template that can be used immediately or saved
for later use.
The NetBackup
Th
N tB k for
f Oracle
O l recovery wizard
i d saves a recovery ttemplate
l t locally
l
ll iin
a user-specified location on the NetBackup client. Recovery templates are not
stored on the server because recovery is always user directed, not scheduled.
232
Under normal circumstances, a recovery template is run immediately and then

deleted. The recovery process sometimes requires passwords for Oracle
database access and system user accounts. Templates store encrypted
passwords that are decrypted at runtime.
Because recovery can be a complex process, it may be necessary to perform
manual steps as part of the operation. Please review your Oracle Database
Backup and Recovery Advanced User's Guide for more information.
6-18
Running recovery templates from the command line

The bpdbsbora command enables you to run a recovery template created by
the NetBackup for Oracle recovery wizard.
The -r option runs a template.
The -t option identifies the template.
Restore templates do not reside in a predetermined location on the master

server. They are considered to be temporary and reside on the client. If the full
path is not specified as part of the restore template name, it must reside in the
current directory.
233
6-19
Lesson summary
This lesson introduced the basic procedures for performing simple restoration
and recovery operations of an Oracle database.
Reference materials
234
Oracle Database Backup and Recovery Advanced User's

User s Guide
Darl Kuhn and Scott Schulze. Oracle RMAN Pocket Reference. Sebastopol,
CA: OReilly & Associates, Inc., 2002.

http://www symantec com/business/support
6-20
235
7-1
Lesson introduction
This lesson outlines management techniques for the RMAN recovery catalog.
Importance
Configuring RMAN with a recovery catalog enables you to use all of RMANs
command options. This is particularly beneficial when managing Oracle
p
across enterprise
p
networks,, either independently
p
y or
databases that are spread
as a distributed database system.
236
7-2

After completing this lesson, you will be able to implement the advanced
features of RMAN that are available through the recovery catalog. You will also
be able to effectively manage the recovery catalog to ensure availability of
backup sets. Finally, you will be able use RMAN functions in order to avoid
potential problems with the recovery catalog in order to minimize database
downtime.
downtime
This module provides the tools used to deal with the following specific issues:
237
If the media manager marks tapes as expired, the RMAN repository may
contain outdated information. To ensure that data in the recovery catalog or
control file is synchronized with data in the media management catalog,
perform a cross check.
If you are running in ARCHIVELOG mode,

mode the recovery catalog is not
updated automatically when a log switch occurs or when a redo log is
archived. Therefore, resynchronize the recovery catalog regularly.
If you make any change to the physical structure of the target database, also
resynchronize the recovery catalog. The recovery catalog is not
automatically updated when a physical schema change is made.
If the recovery catalog is unavailable when you issue backup or copy

commands, you must resynchronize it manually.
7-3
This is Topic 1: Recovery catalog maintenance.

Synchronize the recovery catalog with the media management catalog.
238
Use the reset database command.
7-4
Maintaining the recovery catalog

Part of maintaining the recovery catalog is ensuring its contents are current with
the target databases control file. This is accomplished through a process known
as synchronization. During synchronization, RMAN compares the recovery
catalog to the target databases current control file (or a backed-up control file, if
the current one is not available) and updates itself with information that is
missing or has changed
changed.
Catalog resynchronization
239
Resynchronizations can be full or partial. When resynchronizing, RMAN creates

a snapshot control file in order to obtain a read-consistent view of the control file.
It then updates the catalog with any new information from the snapshot as
described in the slide.
Note: The recovery catalog should be of the same (or higher) version of Oracle
as the target databases it serves.
7-5
Resynchronizing the recovery catalog

Initial synchronization occurs when the target database is first registered with
the recovery catalog. After the initial synchronization, if the control file is
mounted and the recovery catalog is available, RMAN automatically performs a
full or partial resynchronization as needed when you execute the backup,
copy, restore, or switch commands. However, under certain circumstances
you must perform manual resynchronization.
M
Manually
ll resynchronizing
h
i i
the
h catalog
l
240
Use the resynch catalog command to perform manual resynchronization

when:
The recovery catalog is not available when you perform RMAN commands.
You are running in ARCHIVELOG mode. (The catalog is not updated
automatically when a log switch occurs or when an online redo log is
archived.))
You made structural changes to the target database, such as adding a
tablespace. (Nor is the catalog updated automatically for these.)
It is recommended that you resynchronize consistently, depending on the
frequency at which archive log files are created. How frequently you
resynchronize depends on your particular situation. Suggested rates range from
once per hour to once per week.
Note: At an minimum
minimum, resynchronize weekly
weekly.
7-6
The reset database command
When you open a database using the alter database open resetlogs
command, Oracle discards all information in the online redo log file. Oracle then
picks one log (from the control file) for every enabled thread and marks it as the
current log. Also, Oracle updates the file headings of all online data files to the
new database checkpoint. In other words, a new version (or incarnation) of the
database has been created
created.
241
Before you use the recovery catalog again with a target database that has been
opened with the alter database open resetlogs command, notify
RMAN that the database incarnation has been reset. Otherwise, RMAN cannot
distinguish between the resetlogs command and an accidental restoration of
an old control file, and for this reason, it does not access the recovery catalog.
The reset database command tells RMAN to create a new database
incarnation record in the recovery catalog. This new incarnation record becomes
the current incarnation. All subsequent backups and log archiving performed by
the target database are associated with the new database incarnation.
You can also reset the database to a previous incarnation. Typically, you do this
if you are attempting to undo an unsuccessful incomplete recovery.
Note: After opening a database using the alter database open
resetlogs command and resetting the recovery catalog
catalog, immediately perform
a backup of the CONFIDENTIAL
database.
- NOT FOR DISTRIBUTION
7-7
Resetting RMAN to a previous incarnation
If you are performing incomplete recovery to a point before a reset logs

operation, you can reset RMAN to a previous incarnation by using:
RMAN>RESET DATABASE TO INCARNATION primary_key
primary key
To obtain the primary key required by this command, run:
RMAN>LIST INCARNATION OF DATABASE database_name;
The database must be started in NOMOUNT mode to specify the to

incarnation option. After you start the instance and issue reset database
to incarnation, mount or restore a control file from the selected incarnation
and
d run additional
dditi
l RMAN commands.
d
242
7-8
This is Topic 2: Storing scripts.
After completing this topic, you will be able to store your RMAN scripts in the
recovery catalog.
243
7-9
Storing scripts in the RMAN catalog

The recovery catalog also serves as a repository for RMAN scripts. Storing
scripts enables you to save frequently executed collections of RMAN
commands.
Scripts are created and stored with the create script command or the
replace script command. They are executed from inside a run block, using
th execute
the
t script
i t command.
d
You can print stored scripts using the print script command and delete
scripts from the recovery catalog with the delete script command.
244
Note: Back up a copy of your scripts to tape for safekeeping. Add the path to
your scripts to the same standard NetBackup policy you use to back up the
other Oracle files that RMAN does not manage, such as the Oracle directory
structure the PFILE and password files
structure,
files. If the recovery catalog fails
fails, taking your
stored scripts and other files with it, you still have copies that are available to
use.
7-10
This is Topic 3: Querying the recovery catalog.
After completing this topic, you will be able to use the list and report
commands to query the recovery catalog.
245
7-11
Recovery catalog queries
RMAN enables you to generate a number of reports relevant for backup and recovery
using the report and list commands. Use the report and list commands to
determine what you have backed up, as well as what you need to back up. The
information is available whether you use a recovery catalog. Use the report command
to answer questions, such as:
246
Which files have not had a recent backup?

p
Which files are not recoverable due to unrecoverable operations?
Which backup files can be deleted?
What was the physical schema of the database at some previous point in time?
The list command queries the recovery catalog and control file and produces a listing
of its contents. Use the list command to list:
Backup sets containing a backup of a specified list of data files
Backup sets containing a backup of any data file that is a member of a specified list
of tablespaces
All backup sets or copies of all data files in the database
Backup sets containing a backup of any archive logs with a specified name and
within a specified range
Incarnations of a specified database or of all databases known to the recovery

catalog
7-12
The list command

You can determine the primary key for a backup object using the list
command. Most of the catalog maintenance commands have options that
enable you to you specify the primary key of a backup object.
The full syntax and options for the list command are:
list |
|copy
py | backupset
p
| incarnation of database |
tablespace name | datafile name |
archive_record_specifier[ tag tag | like file_pattern |
from time | until time | device_type_list ]
247
You can view details about the Oracle backups using the Status of Backups
report from the NetBackup interface.
Alternatively, use the NetBackup bplist command to browse Oracle backups.
Th resultlt off this
The
thi ttype off query iis a lilistt off allll b
backup
k fil
file names. Th
The ffollowing
ll i
example uses bplist to search all Oracle backups for a client named jupiter:
client# install_path/netbackup/bplist -C jupiter -t 4 -R /
The -t 4 in this command specifies the Oracle backups.The -R specifies the
default number of directory levels to search (999).
Refer to the bplist man page for more information on this command.
7-13
248
The report command

Generate reports from the recovery catalog by using the report command.
The full syntax and options for additional report commands are:
report unrecoverable report_object_list device_type_list;
report need backup incremental integer report_object_list
device_type_list;
report
t need
d b
backup
k
d
days i
integer
t
report_object_list
t bj t li t
device_type_list;
report need backup redundancy integer report_object_list
device_type_list;
report obsolete redundancy integer report_object_list
device_type_list;
report obsolete orphan report_object_list device_type_list;
report
t obsolete
b l t until
til value
l
report_object_list
t bj t li t
device_type_list;
report schema [at time time | scn scn | logseq logseq ]
report_object_list device_type_list;
A report_object_list is one or more data files, tablespaces, or the entire
database.
Use device_type_list to limit the report to objects residing on the specified device
types.
7-14
This is Topic 4: Managing the repository.
After completing this topic, you will be able to manage the recovery catalog
repository.
249
7-15
250
Cross-checking the recovery catalog

In the Performing Backups Using NetBackup for Oracle with RMAN lesson, you
learned that there are two ways to manage retention policies for your NetBackup
for Oracle backups.
Specify a non-infinite retention period in the application backup schedule to
enable NetBackup to manage backup retention.
Specify an infinite retention in the application backup schedule and manage
backup retention policies using RMAN commands.
If you decide to enable NetBackup to manage backup retention, NetBackup
expires backups based on your retention periods and it deletes the metadata it
keeps for those backups from the NetBackup catalogs. For this reason, the
recovery catalog may contain outdated information about available backup sets.
To ensure that data in the recovery catalog is synchronized with data in the
NetBackup catalogs, perform a crosscheck. Use RMANs
RMAN s crosscheck function
to:
Determine whether a backup is AVAILABLE or EXPIRED.
Request backup piece status from NetBackup and then mark it as
AVAILABLE or EXPIRED.
You can also use the changecrosscheck command to verify the availability
of specific files. These commands neither delete the actual files, nor do they
delete data from the recovery catalog
catalog.
7-16
The crosscheck command

The crosscheck command is used to validate the contents of the RMAN
repository against the actual physical backup set pieces that are on the backup
media. The function of the crosscheck command is to set the status of a
backup piece to either AVAILABLE (status code A) or EXPIRED (status code X)
in the recovery catalog or control file.
If you are using

i media
di manager software,
ft
such
h as NetBackup
N tB k for
f Oracle
O l with
ith
RMAN, the crosscheck command queries the media manager for status of
the backup pieces.
251
If you are using RMAN without media manager software, the crosscheck
command checks to see if each backup piece or image copy is physically
present on disk.
When the crosscheck command is executed
executed, RMAN checks each specified
backup set or copy and determines if it is on the backup media. If it is not on the
backup media, each missing backup piece is marked as EXPIRED (X). If the
backup piece exists, it maintains an AVAILABLE (A) status. If a backup piece
was marked as EXPIRED and then becomes AVAILABLE again, the
crosscheck command resets the status to AVAILABLE. Examples of this is are
a failed drive that has since been recovered or a backup expired by NetBackup
and then later imported.
p
7-17
Using the crosscheck command

To use the crosscheck command, ensure the target database instance is
started, start RMAN, connect to the target database and recovery catalog, and
then enter the crosscheck command.
Crosschecking all backups
RMAN automatically
y configures
g
a channel of type
yp DISK. If yyou used the
configure command to configure a default device type of SBT, you can run a
very simple crosscheck command to check the status of all backup sets on
tape and disk:
RMAN>CROSSCHECK BACKUP;
252
If you have not configured a default device type of SBT with the configure
command, manually allocate a channel of type SBT before the crosscheck
can check back
backups
ps on tape
tape:
RMAN>ALLOCATE CHANNEL FOR MAINTENANCE TYPE sbt;
RMAN>CROSSCHECK BACKUP;
RMAN>RELEASE CHANNEL;
However, If you have preconfigured a default device type of SBT, the effect of
y allocating
g a channel of type
yp SBT for maintenance is a crosscheck of
manually
only backup sets stored on tape. Backup sets stored on disk are not checked.
7-18
Additional crosscheck Options
You can perform many other types of crosscheck commands. For example:
To check datafile backups:
RMAN>CROSSCHECK BACKUP OF DATAFILE 1;
To check tablespace backups:
RMAN>CROSSCHECK BACKUP OF TABLESPACE users;
To check control file backups:
RMAN>CROSSCHECK BACKUP OF CONTROLFILE;
To check SPFILE backups:
RMAN>CROSSCHECK BACKUP OF SPFILE;
There are many options you can use to check archive log backups. For
example:
To check all archive log backups:
RMAN>CROSSCHECK ARCHIVELOG ALL;
To check specific archive log backups:
RMAN>CROSSCHECK ARCHIVELOG
FROM TIME TO_DATE(10-01-2006,
(
, mm-dd-yyyy);
yyyy )
To check specific archive log backups using a sequence number:
RMAN>CROSSCHECK ARCHIVELOG FROM SEQUENCE 64;
253
7-19
The delete command

The delete command is used to delete physical backups and copies (if they
still exist) as well as update their records in the control file and recovery catalog.
By default, the delete command displays a list of the files to be deleted and
prompts you before deleting any file in the list. However, if you run the command
from a command file or specify the delete noprompt option, the files are
li t d b
listed
butt th
there iis no promptt ffor confirmation.
fi
ti
254
To use the delete command, ensure the target database instance is started.
Connect RMAN to the target database and the recovery catalog. A maintenance
channel is not required for disk-only files created by RMAN without NetBackup
for Oracle, A maintenance channel is required if the backups are stored on tape
and you did not used the configure command to specify a default device type
of SBT.
Example:
RMAN>allocate channel for maintenance of type sbt;
RMAN>delete expired;
RMAN>release channel;
7-20
Managing backup retention policies: Strategy 1

In previous lessons, you learned about the two ways to manage retention
policies for backups performed with RMAN and NetBackup for Oracle.
Both methods require either manual or scripted management by the

administrator. If you choose to enable NetBackup to manage your retention
policies for backups,
backups perform regular crosschecks to synchronize the metadata
in the recovery catalog with the NetBackup catalogs. Also, periodically clean
your recovery catalog of obsolete backup set records using the delete
expired command discussed previously in this lesson.
255
7-21
Managing backup retention policies: Strategy 2
The second way to manage backup retention policies is to use RMAN

commands. The configure command simplifies this task. The delete
obsolete option notifies NetBackup of backup images to expire; as a result,
NetBackup deletes the necessary records from the NetBackup catalogs.
256
7-22
The change command

The change command can be used to:
Change the status of repository records for backup sets and pieces.
Delete backup pieces from disk media and remove associated records from
the target databases control files and recovery catalog.
The following table describes the various change command options:
257
Command
Description
CHANGEUNCATALOG
Thiscommandremovesreferencestodatafilecopiesor
archivedredologsfromtherecoverycatalogandupdates
recordsinthetargetcontrolfiletoDELETEDstatus.The
CHANGEUNCATALOG commanddoesnottouchphysical
backupsandcopies.UsethiscommandtonotifyRMANwhena
fileisdeletedbyOScommands.
CHANGEDELETE
Thiscommandremovesreferencestobackuppieces,datafile
copies,orarchivelogsfromthecontrolfileandrecovery
catalog.Thiscommandalsophysicallydeletesthosefilesfrom
theoperatingsystemormediamanager.
7-23
258
Command
Description
CHANGEVALIDATE
copies,orarchivelogsfromthecontrolfileandrecoverycatalog
whenthosefilesnolongerexistondisk.
CHANGEUNAVAILABLE
Thiscommandmarksbackuppieces,datafilecopies,orarchive
logsasUNAVAILABLE.
CHANGEAVAILABLE
Thiscommandmarksbackuppieces,datafilecopies,orarchive
logsasAVAILABLE.
CHANGECROSSCHECK
pp
,
copies,orarchivelogsfromthecontrolfileandtherecovery
catalogwhenthosefilesnolongerexist.
7-24
Recovery catalog validation

Validation is a test that determines whether a backup set or image copy can be
restored. Validation ensures that RMAN and NetBackup for Oracle are executing
backup operations correctly.
Using the validate backupset command
RMANs validate backupset

p
command examines all of the backup
pp
pieces
within a specified backup set and determines whether their contents are
complete so they can be restored, if necessary. It does this by examining the
checksums of the backup pieces to test for consistency.
259
As with crosschecking, use the list command to determine which backup set
to validate. If you have used the configure command to specify a default
device type of SBT, it is unnecessary to configure a channel manually, as shown
in the following example:
RMAN> list backup;
RMAN> run {
2> allocate channel stream1 type 'SBT_TAPE';
3> validate backupset backupset_id;
4> }
7-25
Restore validation
When you execute the restore validate command, RMAN simulates a

restore operation, but does not actually restore any files. If RMAN completes the
simulated operations without errors, the database backup sets are undamaged
and are ready for actual restore operations.
RMAN> run {
2> allocate channel stream1 type 'sbt_tape';
3> restore database validate;
4> }
260
RMAN returns status messages, indicating its progress in the operation. RMAN
returns error messages if any of the specified backup sets are not available.
7-26
Using restore validate to test tablespaces and data files
Using the restore validate command to test tablespaces and data files is
essentially the same operation as performing an entire database validation;
however, the target tablespaces or data files must first be taken offline. Use the
list command
d tto d
determine
t
i which
hi h b
backup
k sett tto validate.
lid t Th
Then specify
if th
the lilistt
key numbers within the restore validate command. For example:
RMAN> run {
3> restore tablespace 'tablespace_id' validate;
4> }
U i restore validate to
Using
t ttestt th
the control
t l file
fil
When using restore validate to test the target databases control file, the
database can be either open or closed.
In the following example, RMAN also tests all of the archive log files as well as
the system tablespace:
RMAN> run {
3> restore controlfile validate;
4> restore archivelog all validate;
5> restore tablespace 'system' validate;
6> }
261
7-27
This is Topic 5: Backing up and recovering the recovery catalog.
After completing this topic, you will be able to back up and recover the recovery
catalog.
262
7-28
Protecting the recovery catalog

Back up the recovery catalog whenever you back up the target database. Back
it up either by using RMAN or by making an operating system (OS) backup
using NetBackup. The advantage of the OS backup using NetBackup is that you
can restore the OS backup without RMAN or a recovery catalog.
Another safeguard for protecting the recovery catalog is to create a logical copy
off it using
i th
the export
t command.
d Thi
This iis b
beneficial
fi i l b
because th
the recovery
catalog can then be restored to any other existing Oracle database. Refer to the
Oracle 10g Backup and Recovery Guide for more information on logical backups
and the export command.
263
7-29
Guidelines for recovery catalog backup
It is recommended that you store the recovery catalog on separate media and in
a separate geographic location from the target databases it serves. However,
you do not necessarily need to create an additional database solely for use as a
recovery catalog. You can embed the recovery catalog within an existing
database. Also, remember that a single recovery catalog can store information
for multiple target databases
databases.
264
Back up the recovery catalog regularly. Because the recovery catalog resides in
an Oracle database, you can use RMAN to back it up by reversing the roles of
the recovery catalog database and a target database. In other words, the target
database becomes the recovery catalogs recovery catalog, and the original
recovery catalog is treated as the target database.
Restoring the recovery catalog
If you back up the recovery catalog using RMAN and NetBackup for Oracle,
restore and recover it as you would any other database covered in this course.
If you back up the recovery catalog as an OS file using NetBackup, restore it
using conventional NetBackup recovery methods.
If you export a logical copy of the recovery catalog, import it into another
database to recover it.
Refer to the Oracle 10g Backup and Recovery Guide for additional information.
7-30
Lesson summary
This lesson outlined management techniques for the RMAN recovery catalog. It
also introduced advanced RMAN functions available when it is configured with a
recovery catalog.
Reference materials
265
Symantec
y
NetBackup
p for Oracle Administrators Guide
Oracle Database Backup and Recovery Advanced User's Guide

7-31
266
7-32
267
8-1
Lesson introduction
As databases have become more intricate, the failures that can occur have
become proportionally more complex. But Oracles logical architecture enables
straightforward backup procedures, which result in straightforward recovery
procedures, regardless of the type of failure. This lesson provides an overview
of such complex failures and how to recover from them.
I
Importance
t
268
Knowing how to recognize and recover from challenging database failures is

central to the role of any DBA. The combination of NetBackup for Oracle and
RMAN, coupled with a sound backup policy, is a powerful tool that enable you to
recover from almost any database failure.
8-2
After completing this lesson, you will be able to leverage RMAN and NetBackup
for Oracle to recover from complex database failures. You will also learn to
perform incomplete recoveries, when all necessary elements for a complete
recovery are not available.
269
8-3
This is Topic 1: Recovering critical files.
After completing this topic, you will be able to recover from the loss of critical
database files.
270
8-4
The database ID (DBID)

One of the benefits of using a recovery catalog is to simplify the restore of
critical files such as the SPFILE and the control file. If you choose not to use a
recovery catalog and you need to recover your control file, you must know the
database ID (DBID) of the database.
If you are not using a recovery catalog

catalog, create a list of the DBIDs of your
databases during the initial setup and configuration and keep the list in a safe
place. Another method to find the DBID is to use RMAN, which displays the
DBID when it connects to the target database.
271
8-5
Restoring the server parameter file

As discussed in a previous lesson, the configure command is available
beginning in Oracle9i Release 2 and has an option to perform automatic
backups of the Control File and SPFile. By default, the backups are written to
$ORACLE_HOME/dbs. A restore of the SPFile automatically selects the SPFile
from an autobackup if you are using a recovery catalog.
C
Connect
t to
t the
th target
t
t database
d t b
and
d the
th recovery catalog,
t l
if it is
i used.
d If you are
not using a recovery catalog or if the target DB_NAME is not unique in the
recovery catalog, specify the DBID before you start the restore.
RMAN>SET DBID <DBID>;
272
Shut down the instance and restart it in NOMOUNT mode. Because the server
parameter file is lost, RMAN starts the instance with a dummy parameter file.
T restore
To
t
the
th SPFILE from
f
an autobackup
t b k when
h using
i a recovery catalog:
t l
RMAN>RESTORE SPFILE;
To restore the SPFILE from an autobackup when not using a recovery catalog:
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
8-6
If you are not using a recovery catalog and autobackup is not configured, omit
the FROM AUTOBACKUP clause and RMAN uses the control file to locate the
most current copy of the SPFILE.
If the control file is not available and you are not using a recovery catalog, the
simplest
i l t method
th d off restoring
t i th
the SPFILE is
i to
t restore
t
it from
f
a standard
t d d file
fil
system backup. For more information, see the Oracle Recovery Manager Users
Guide.
273
8-7
Restoring the control file

If you have used the configure command to configure autobackup of the
control file, RMAN automatically selects the latest autobackup copy if you are
using a recovery catalog. Specify the FROM AUTOBACKUP clause if you have
autobackup configured but do not use a recovery catalog.
RMAN automatically replicates the control file to all of the CONTROL_FILE
l
locations
ti
lilisted
t d iin th
the parameter
t fil
file.
If you specify an alternate (nondefault) location to which to restore the control

file, copy it to all control file destinations using the RESTORE CONTROL FILE
FROM command.
274
When restoring the control file, first connect to both the target database and the
recovery catalog from the RMAN prompt. Then start the database in NOMOUNT
mode.
mode
8-8
Restoring archived redo logs

Archived redo logs are restored by default to files whose names are constructed
using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT parameters in the
initSID.ora file. You can override this by specifying a SET ARCHIVELOG
destination command in the restore script. You can use this to restore a
large number of archive logs to different locations prior to performing a recovery.
RMAN records the location of all restored archive logs and uses them as
required during the recovery process.
When restoring redo logs files, connect to the target database and the recovery
catalog (optional) and start the database in MOUNT mode.
275
The following example (for demonstration purposes only) restores some archive
logs to a temporary location on disk (/oracle/temp_location1) and then
restores another range of archive logs to a different temporary location on disk
(/oracle/temp_location2):
run {
set archivelog destination to '/oracle/temp_location1';
restore archivelog from sequence 1 until sequence 5;
set archivelog destination to '/oracle/temp_location2';
restore archivelog from sequence 6 until sequence 10;

}
8-9
This is Topic 2: Incomplete recovery.
After completing this topic, you will be able to perform incomplete recovery
operations.
276
8-10
Point-in-time recovery
All recovery operations involve re-establishing a database up to a particular

point in time. This point is usually the time at which the database failed.
Whenever you recover a database to a different point in time, it is known as an
incomplete or a point-in-time recovery because it does not completely use all of
the available redo.
277
If you perform
f
an incomplete
i
l t recovery on an active
ti database,
d t b
allll ttransactions
ti
made since the point in time to which you are recovering are erased. For
example, suppose that a tablespace is deleted from a database on a Tuesday,
and the last available state of the database is from Sunday. You can only
perform an incomplete recovery to restore the tablespace to its last available
state. All transactions involving that tablespace from Sunday to Tuesday are
lost.
8-11
Preparing for an incomplete recovery

RMAN can perform an incomplete recovery of the entire database to a specified
time, SCN, or log sequence number. Incomplete recovery of the entire database
is also called database point-in-time recovery (DBPITR).
When you perform a DBPITR, the target database is opened using the alter
database open resetlogs command. This command instructs the
d t b
database
nott tto inadvertently
i d t tl apply
l any redo
d th
thatt was skipped.
ki
d
278
A data file cannot be recovered if it is offline during the incomplete recovery

operation unless it is part of a tablespace that was taken offline using the
normal option. If the immediate option is used to take the tablespace offline
and the data file remains offline when the resetlogs option is applied when
opening the database, the tablespace containing the offline data file must be
dropped and re-created. This is because the data file requires media recovery
from a point in time prior to the time the resetlogs option was applied.
8-12
Performing an incomplete recovery
In addition to the SET UNTIL TIME and SET UNTIL SEQUENCE clauses
shown in the slide, you can perform an incomplete recovery using the SET
UNTIL SEQUENCE clause to recover through a specific log sequence number:
For example:
279
RUN
{
SET UNTIL SEQUENCE 9302;
RESTORE DATABASE;
RECOVER DATABASE;
}
After finishing an incomplete recovery, open the database and reset the online
logs:
RMAN>ALTER DATABASE OPEN RESETLOGS;
8-13
Performing an incomplete recovery of a tablespace

In some cases, you may wish to recover only a single tablespace. Oracle
supports tablespace point-in-time recovery (TSPITR), but it requires you to
create an auxiliary instance (a temporary instance) for the restore.
The Auxiliary Instance
The Auxiliary
y instance must reside on the same system
y
as the target
g database.
To prepare the Auxiliary instance:
Create the password file.
Create the database parameter file.
280
Start the auxiliary instance and check network connectivity.

The parameter file of the auxiliary instance is a separate parameter file from the
one used with the target database
database. It requires a few additional parameters
parameters,
which are shown in the table on the following page.
8-14
ParameterName
Optional/Required
db_name
Optional
Samenameasthetargetdatabase
lock_name_space
Required
Auniquenameamongallother
databasesonthesystem
db_file_name_convert
or
db_file_name_convert_n
Optional
Defineasetoffilenamingconversion
patternsfordatafilesintheauxiliary
databaseastheyarerestoredby
RMAN
log_file_name_convert
or
log_file_name_convert_n
Optional
Defineasetoffilenaming
conversionpatternsforredolog
filesintheauxiliarydatabaseas
theyarerestoredbyRMAN
AnalternativetousingtheSET
NEWNAMERMANcommand
control_files
t l fil
R
Required
i d
D
Definesthenamesandlocations
fi
th
d l ti
oftheauxiliaryinstancecontrol
files
Thenamesshouldbeuniquein
namefromanyexistingcontrol
fileinthefilelocations.
remote_login_passwordfile
C
Compatible
tibl
db_block_size
281
Description
Optional/Required
EnablesRMANtoconnecttothe
auxiliarydatabaseusingOracle
ili d t b
i O l
Net.
Requiresthepresenceofacurrent
passwordfile.
Ifyouareconnectingtothe
auxiliarydatabaselocally,this
doesnotneedtobeset.
R
Required
i d
Mustbethesameastargetdatabase
M
b h
d b
setting
Optional/Required
Ifsetonthetargetdatabase,this
mustbesettothesamevalueinthe
auxiliarydatabase.
The easiest way to configure the parameter file is to make a copy of the target
instance parameter file and make the adjustments shown in the preceding table.
After the parameter file is ready, start the instance in NOMOUNT mode and
verify connectivity by connecting to it using Oracle Net.
8-15
Performing a tablespace point-in-time recovery

To perform the TSPITR, connect to the target database, the auxiliary database,
and the recovery catalog simultaneously. After you are connected, perform the
recovery using the UNTIL TIME, UNTIL SCN, or UNTIL SEQUENCE clause.
The example in the slide assumes you have default channels configured. If you
do not have default channels configured, manually allocate channels to perform
th restore.
the
t
After you have issued the recover command, Oracle restores the datafiles to
the auxiliary instance and enables it, recovering the tablespaces in the auxiliary
instance, and transporting the recovered tablespaces to the target database.
282
The following are TSPITR restrictions:
You cannot restore tablespaces with objects owned by SYS.
TSPITR is not supported for any tablespaces with replicated master tables.
Tablespaces with snapshot logs are not supported.
You cannot restore tablespaces with rollback segments.
If an object with the tablespace to be recovered has VARRAY, nested tables,

or external files, TSPITR is not supported.
TSPITR cannott be
b used
d to
t recover a dropped
d
d ttablespace.
bl
8-16
Sample recovery shell script

NetBackup for Oracle provides a sample script for incomplete recoveries.
The sample scripts are located in:

/usr/openv/netbackup/ext/db_ext/oracle/samples/rman.
283
8-17
This is Topic 3: Database recovery challenges.
After completing this topic, you will be able to manage common database
recovery challenges.
284
8-18
Restoring data files and tablespaces

By default, RMAN restores a data file back to its original location, overwriting the
existing data file. This means that the tablespace containing the data file must
be taken offline before the restore can take place. If you use the set newname
command, the file is restored to the alternate location. The recovery catalog is
updated to indicate that a new data file is available. Use the switch command
to put the data file in place before recovery is attempted
attempted.
If the database is open, take a tablespace offline before recovering it.
285
Because tablespace recovery does not require rolling the entire database
forward, it is faster than database recovery. However, for the recover
tablespace command to execute properly, the following are required:
All archived and online redo logs
A currentt control
t l file
fil
A backup of the data files within the target tablespace
If you do not have default channels configured, allocate at least one channel
before issuing the restore command. The restore command automatically
releases the allocated channel.
8-19
286
Recovering a single tablespace: Datafile is unavailable

In this example, a single tablespace, ts2, needs to be recovered. However, the
failure has occurred because of a disk crash, which is a serious media failure.
Consequently, the data file located on that disk (ts22.dbf) must be restored to
an alternate location.
The script performs the following steps:
1 Allocates two channels for this recovery.
1.
recovery The disk channel is used to perform
the switch, and the SBT_TAPE channel is used to restore the data files from
tape. (If default channels are configured, omit this step.)
2. Brings the target tablespace offline.
3. Uses the set newname command to specify the alternate location for the
data file prior to issuing the restore command.
4. Restores the target tablespace.
5. After the restore completes, uses the switch...all command to instruct
the database to use the newly restored data file.
6. Uses any available level 1 or higher incremental backups to bring the data
files up to as close to the current time as possible; automatically applies
archived and online redo logs, as required.
7. After the recovery completes, brings the tablespace back online and
releases the allocated channels.
8-20
Recovering a database: Datafile is unavailable

In this example, the datafile is unavailable and recovery is performed to
alternate disk locations.
The script performs the following steps:
1. Allocates the appropriate channels.
2 Uses the set newname command to direct alternate
2.
alternate-path
path restores for the
data files that are on the failed disk.
3. Restores the control file to an alternate location and then replicates to the
target database.
287
4. Mounts and restores the database, skipping the crashed tablespace.

5. Performs SQL functions to open the reset logs, drop the crashed tablespace,
and recreate the tablespace using data contained within the temp3.dbf
t
3 dbf
data file.
6. Releases the allocated channels.
8-21
This is Topic 4: Redirecting restores.
After completing this topic, you will be able to redirect a restore to an alternate
client.
288
8-22
Redirecting a restore to an alternate client

You have the option to restore a database to a client other than the one that originally
performed the backup. The process of restoring data to a different client is called an
alternate client restore.
The following sections describe how to restore a backup to an alternate client.
Server configuration
Ensure that the NetBackup master server is configured to enable an alternate client
restore. To remove restrictions for all clients, create the following file on the NetBackup
master server:
MASTER# install_path/netbackup/db/altnames/No.Restrictions
289
Alternately, to restrict clients to restore only from certain other clients, create and then
add client names to the following file:
MASTER# install_path/netbackup/db/altnames/client_name
install path/netbackup/db/altnames/client name
where client_name is the name of the client enabled to perform the alternate client
restore.
RMAN alternate client configuration and restore
Use the same user name (UNIX account) that was used for the Oracle database
backup for the alternate client restore.
Note: Ensure that server and user-directed regular file system backups work for the
client prior to debugging the Oracle RMAN backups.
8-23
290
Redirecting a restore
This example (adapted from the Oracle Backup and Recovery Guide) illustrates
a typical alternate client restoration.
In this example, assume:
The original client is mars.
The alternate client is venus.
The master server is earth.
The ORACLE_SID is lab.
The UNIX user is oracle on both mars and venus.
To apply these values:
1. Create the install_path/netbackup/db/altnames/venus file on
earth and edit it to contain the name mars.
2. Log on to venus as oracle.
3. Set SERVER=earth in ${ORACLE_HOME}/bp.conf.
4. Modify the network tnsnames.ora file to enable the RMAN catalog
connection.
5. Set the environment variables ORACLE_SID to lab and NB_ORA_CLIENT
to mars.
8-24
6. Verify that the directory exists and has appropriate access permissions.
The data files are restored to a directory path with the same name they had
when backed up.
p
file.
7. Create an spfilelab.ora
8. Start up the database as follows.
venus$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount
...
SQL> exit
9 Run
9.
R an RMAN restore
t
script:
i t
venus$ rman rcvcat rmanowner/rmanowner@rmancat
RMAN> connect target
RMAN> @restore_database.rcv
where restore_database.rcv is the RMAN script containing the specific
restore commands.
N t See
Note:
S the
h Symantec
S
t NetBackup
N tB k for
f Oracle
O l Administrators
Ad i i t t Guide
G id and
d the
h
Oracle Database Backup and Recovery Advanced Users Guide for details.
291
8-25
This is Topic 5: Guided application recovery (GAR).
After completing this topic, you will be able to clone the database using guided
application recovery (GAR).
292
8-26
Guided application recovery introduction
Guided application recovery (GAR), is a new feature in NetBackup 7.0. GAR

provides a simple method of cloning a database to perform a restore. It also
simplifies the restore of database objects, such as datafiles, control files, and
redo log files to a different disk location, which is a useful feature in the event of
a disk failure.
293
GAR iis accessed

d using
i th
the new O
OpsCenter
C t web-based
bb
d iinterface
t f
th
thatt was
introduced in NetBackup 7.0 . The GAR wizard steps you through selection of
restore criteria and provides an option to validate restore selections prior to
launching the cloning process. Validation greatly improves the chances of a
successful restore by verifying selected disk locations and checking for existing
database objects. Any problems flag an error.
In order to make the guided application recovery process possible, metadata is
collected from the client during database backups.
NetBackup stores collected metadata in the EMM database on the master
server. Information collected includes information about all database objects
including datafiles, control files, and redo log files and paths to these files.
8-27
GAR overview
The GAR process uses metadata gathered from a successful backup that had
metadata collection enabled. Metadata collection is enabled using one of the
following methods:
Add the ORACLE_METADATA=YES entry to the client bp.conf file.
parameters in the RMAN

Use the send command to set the metadata p
scripts.
After metadata collection is enabled, the only other requirement is to perform

successful backups of the target database using NetBackup for Oracle.
294
Metadata is retrieved from the EMM database when the user steps through the
GAR wizard during the cloning process. User selections are validated with the
Oracle RMAN catalog and Oracle control file and temporary recovery scripts are
created
t d and
d run b
by RMAN tto complete
l t th
the cloning
l i process.
8-28
Tracking metadata collection in the NetBackup Activity Monitor

The screenshot shown on this slide shows an example of a NetBackup for
Oracle backup with metadata collection enabled.
Jobs 190 and 191 represent metadata collection for the completed database
backup. Jobs 194 and 195 represent metadata collection for the completed
archive log backups and job 197 represents metadata collection for the
completed
l t d control
t l fil
file b
backup.
k
295
8-29
This is Topic 6: Using the GAR wizard.
After completing this topic, you will be able to perform cloning operations using
the guided application recovery wizard.
296
8-30
The NetBackup 7.x OpsCenter interface

Access the GAR wizard using the new NetBackup OpsCenter interface.
OpsCenter replaces the NetBackup Operations Manager that was introduced in
NetBackup version 6. It requires a separate installation from the NetBackup
server installation and has its own database.
OpsCenter provides a web-based alternative to the NetBackup Administration
C
Console
l ffor managing
i and
d monitoring
it i an established
t bli h d N
NetBackup
tB k environment.
i
t It
is also the only interface that supports guided application recovery (GAR).
There are unlicensed and licensed versions of OpsCenter. GAR can be used
with either version. Supported browsers for the OpsCenter console include:
297
Microsoft Internet Explorer 6.0, 7.0, 8.0
Mozilla Firefox 3.0 and higher
See the Symantec OpsCenter Administrators Guide for more information about
OpsCenter.
8-31
Initiating a GAR recovery

Select Manage > Oracle Cloning to access the GAR wizard.
Specify the name of the master server and click Go to begin the GAR cloning
process.
298
8-32
Selecting the database to clone

The source database selection screen is displayed. This screen shows the most
recent backups of databases backed up with metadata collection enabled.
Use the filters at the top of this screen to help you select the correct database to
be recovered. Select the database you wish to recover and click Next to
continue.
299
8-33
Selecting the control file backup

After you select an Oracle database for recovery, you select a backup of the
control file for that database for the recovery.
The recovery process begins by restoring the control file for the database being
recovered.
When the control file to be recovered is selected, there are three links available
for viewing details of the control file: View Database Schema, View Datafiles
Recovery Set, and View Archived Log Recovery Set. The link to view the
database schema was clicked in the screenshot shown in the slide.
300
8-34
Setting the destination host and credentials

The next step is to select the destination host. Browse for the host or simply
type it in the entry field.
Next, enter the login to use for OS authentication for the Oracle database. If the
clone is being recovered to a Windows server, enter a password and domain
name. If the recovery is being performed to a UNIX host, the password and
d
domain
i name fifields
ld are nott used.
d
301
8-35
Setting the destination database attributes

Next you set the database attributes for the destination. These parameters are
set using the four tabs on the screen shown in the slide.
Use the Database attributes tab to configure a new instance name, database
name, and database home if these are different for the selected host.
302
8-36
Setting the destination control file paths

The Control file paths tab enables you to modify paths for control files. The
defaults are usually acceptable unless a disk failure has occurred. If you are
restoring to a system with dissimilar directory structures, you may also need to
change the control file paths.
Changed paths are highlighted to give the user a visual reference. These
hi hli ht b
highlight
bars show
h
what
h th
has changed
h
d so ffar, which
hi h iis h
helpful
l f l when
h a llarge
number of changes are being made.
303
8-37
Setting the destination datafile paths

The third tab is the Datafile Paths tab.
The left side of the table displays the tablespaces associated with the database.
This tab enables you to collectively or individually change the destination path of
all tablespaces.
304
8-38
Setting the destination redo log paths
The fourth tab is the Redo log paths tab. This tab enables you to change the
destination path of redo logs individually.
305
8-39
The summary screen

The wizard displays a summary screen with all restore selections from the
previous screens. In addition to options to view restore selections, it includes a
link to view the parameter file settings that will be used for the cloning operation.
Select the appropriate links to view the recovery sets and archived log recovery
sets that will be used for the cloning operation.
306
8-40
Validate the selections and launch the recovery

The next screen that is displayed is the validation and launch page. Click the link
to validate the restore selections.
You can also specify an email address to be notified when the cloning process is
complete.
Click Launch Cloning Process to begin the cloning process. A message is

displayed prompting you to monitor the restore process.
307
8-41
The OpsCenter Monitor > Jobs screen
Monitor the cloning process on the OpsCenter Monitor > Jobs screen or by
using the NetBackup Administration Console Activity Monitor.
308
8-42
Lesson summary
This lesson showed you how to recognize and recover from complex database
failures. It also outlined strategies for performing incomplete recovery operations
and safeguarding against user errors.
Reference materials
309
Symantec
y
NetBackup
p for Oracle Administrators Guide
Symantec OpsCenter Administrator's Guide
Oracle Recovery Manager Users Guide
Oracle Database Backup and Recovery Advanced User's Guide
Matthew Hart and Robert G. Freeman. Oracle Database 10g RMAN Backup
& Recovery. Berkeley, CA: The McGraw-Hill Companies, Inc., 2007.

8-43
310
8-44
311
9-1
Lesson introduction
Backup performance can be improved for RMAN backups with the

implementation of asynchronous I/O and careful attention to parallel backup
strategies. This lesson focuses on tuning and monitoring your RMAN backups
312
9-2
After completing this lesson, you will be more familiar with tuning methods for
RMAN backups, such as utilizing asynchronous I/O, multiplexing, and parallel
channels. You will also learn about RMAN views used to monitor performance of
RMAN backups using asynchronous I/O.
313
9-3
This is Topic 1: RMAN tuning.
After completing this topic, you will be able to tune your RMAN backup and
restore environment to improve performance. This includes being able to:
Configure asynchronous I/O.
314
Configure multiplexing.
Manage parallel channels

channels.
Monitor RMAN performance.
9-4
Configuring asynchronous I/O

Most modern backup devices perform asynchronous I/O. Asynchronous I/O
enables a process to issue a write instruction to the device; and while that
operation is being performed, the process can continue to read data and fill
buffers in preparation for the next write operation. Synchronous I/O, on the other
hand, requires a process to wait for an I/O operation to complete before it can
continue work to prepare for the next write operation
operation. Asynchronous writes are
more efficient (and provide better performance) than synchronous writes.
Configuring RMAN to perform asynchronous I/O for tape backups
315
The BACKUP_TAPE_IO_SLAVES parameter, which defaults to FALSE,

enables asynchronous writes for RMAN backups when it is set to TRUE. After
this parameter setting is configured, you may configure a large pool to reduce
shared pool contention that can occur when asynchronous writes are enabled.
Asynchronous I/O when writing to disk
If you are backing up to disk using the native RMAN device type disk, RMAN
automatically uses asynchronous I/O if the operating system supports it (most
do). If your OS does not support asynchronous I/O, you can specify a non-zero
value for the DBWR_IO_SLAVES parameter, which starts multiple DBWR
processes during backups to simulate asynchronous I/O (experiment with values
to find a suitable setting).
9-5
Configuring tape I/O buffer size
The tape buffer size is determined when the channel is configured. The default
value is operating system specific, but is typically 64K. To configure this value to
be higher (or lower), use the parms argument in the allocate channel
command. For most tape device types, a value of 256K provides good
performance. Experiment with different values to find a setting that provides
good overall performance in your environment
environment.
316
9-6
Multiple channels for parallel backups

Performing parallel backups with RMAN requires allocating multiple channels.
As discussed in a previous lesson, each channel that has data allocated to it
during a backup or restore is working independently to create separate backup
sets. If the backed up data is distributed across multiple disks, the performance
will be better if you perform your backups in parallel this way.
Determining
D
t
i i th
the correctt number
b off channels
h
l tto allocate
ll
t ffor your environment
i
t can
be tricky and requires some testing for a definite answer. A general rule of thumb
is to specify a channel for each output device.
Configuring parallel backups in NetBackup (multiple data streams)
317
In the NetBackup Essentials lesson of this course, you learned about the
importance of configuring the NetBackup Max jobs per client global attribute
when using multiple RMAN channels. By default, NetBackup enables only one
active channel. If you plan to specify multiple RMAN channels, remember to
configure a Max jobs per client setting greater than one. Review the
NetBackup Essentials lesson for information on how to set this parameter.
9-7
Parallel backups using RMAN multiplexing
RMAN multiplexing can improve backup performance by reading multiple

datafiles at once. In addition, multiplexing can also improve performance by
maintaining a good flow of data to the tape devices, reducing a condition know
as shoe-shining, which occurs when the client is not able to read data fast
enough to keep the tape drive busy. The tape drive is forced to stop and wait for
a data buffer
buffer, causing it to back up and reposition to begin writing again when
the buffer arrives. The delays hurt your backup performance and the shoeshining is hard on the tape drives.
318
With multiplexing, a single datafile can span more than one backupset piece.
This is because it is possible to specify a MAXPIECESIZE to a value smaller
than that of a single datafile. However, it does not span backupsets. Specify a
MAXSETSIZE greater than or equal to the size of the largest tablespace you
back up
up.
Because a datafile is only backed up through one channel, RMAN multiplexing
is not a benefit if you are trying to improve performance backing up a single
large datafile. Therefore, If you allocate two channels and you specify a single
large datafile for backup, the entire datafile is backed up through the same
channel, and the backup is not multiplexed.
9-8
Tuning your backup strategy

Instead of using the backup database command to back up an entire
database with one command, you may see benefits from partitioning your
backup strategy. In addition to the benefits noted in the slide, a partitioned
strategy may be useful in a disaster recovery situation.
If you restore an entire database with the restore database command,

problems
bl
will
ill occur if you run outt off space d
during
i th
the restore.
t
Thi
This iis a strong
t
possibility if you are forced to restore to a different system during a disaster
recovery scenario and the disk layout is not the same as what you had on the
original system where you performed the backups.
319
If you run out of disk space during a restore, RMAN removes every file it
restored in the restore session before the failure. This will be painful if the
restore process took hours to complete. You will have wasted that much time
and have nothing to show for your trouble. However, if you used a partitioned
backup strategy, you can restore your database in more granular tablespace
restores (in parallel if you have multiple tape devices available) and the failure of
one restore session will not affect the others.
9-9
Tuning views (1 of 2)
You can use the V$SESSION_LONGOPS and V$SESSION views to monitor

your RMAN backups or restores to determine how much longer they are
expected to run.
320
9-10
Tuning views (2 of 2)
The V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO views contain detailed
information about RMAN asynchronous and synchronous backup operations.
The views contain a row for each asynchronous or synchronous backup or
recovery operation, and they are cleared each time the database is shut down.
The sample query in the slide shows the effective transfer rate from the
database to the backup set, the name of the datafile that was backed up, and
the actual start and stop time of the backup.
321
The column EFFECTIVE_BYTES_PER_SECOND represents the rate at which

objects are backed up and recovered in rows where the TYPE column is equal
to AGGREGATE. The number should be close to the listed read/write rate of
your backup hardware. If it is not, investigate to find out why.
U th
Use
the ffollowing
ll i query tto show
h
th
the ratio
ti off I/O
I/Os to
t long
l
waits.
it Use
U this
thi
information to determine if you have an I/O problem.
SQL>select b.io_count, b.ready, b.short_waits,
b.long_waits, b.long_waits/b.io_count,
b.filename from V$backup_async_io b;
9-11
Lesson summary
This lesson covered RMAN tuning techniques to help you improve backup and
restore performance.
Reference materials
322
Matthew Hart and Robert G.

G Freeman.
Freeman Oracle Database 10g RMAN Backup
& Recovery. Berkeley, CA: The McGraw-Hill Companies, Inc., 2007.

9-12

Symantec NetBackup 7.x For Oracle GUIDE

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Symantec NetBackup 7.x For Oracle GUIDE

Загружено:

Авторское право:

Доступные форматы

CONFIDENTIAL - NOT FOR DISTRIBUTION

Copyright 2011 Symantec Corporation. All rights reserved.

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Copyright 2011 Symantec Corporation. All rights reserved.

Lesson 4: RMAN Concepts and Backup Operations

Lesson 5: Performing Backups Using NetBackup for Oracle with RMAN

CONFIDENTIAL - NOT FOR DISTRIBUTION

Backing up and recovering the recovery catalog ....................................... 7-28

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

Oracle database backup

The integration of Oracles Recovery Manager (RMAN) with Symantec

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Database administrators (DBAs) responsible for the maintenance of Oracle

Copyright 2011 Symantec Corporation. All rights reserved.

UNIX system administrators

This course is designed with consideration to both audiences, although a basic

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

Students attending as system administrators should be familiar with the

Crossover knowledge between these areas (database administration and

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

A knowledge of the structure and storage concepts that underline an Oracle

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Lesson topics and objectives

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

This is Topic 1: Oracle architecture.

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

As illustrated in the diagram, an Oracle database consists of three primary

Each component performs specific functions and can have particular

CONFIDENTIAL - NOT FOR DISTRIBUTION

Symantec NetBackup 7.x for Oracle for UNIX

Copyright 2011 Symantec Corporation. All rights reserved.

Disk: Data files

Symantec NetBackup 7.x for Oracle for UNIX

Disk: Redo log files

Copyright 2011 Symantec Corporation. All rights reserved.

CONFIDENTIAL - NOT FOR DISTRIBUTION