Oracle Database 10g Backup Recovery Vol - 1

Oracle Database 10g:
Backup and Recovery
Volume I • Student Guide
n l y
e O
U s
A I
O
l &
D22057GC10
na
Production 1.0
June 2006
D46524
te r
I n
c l e
r a ®
O
Authors Copyright © 2006, Oracle. All rights reserved.
Donna Keesling Disclaimer

Maria Billings This document contains proprietary information and is protected by copyright and
other intellectual property laws. You may copy and print this document solely for your
Technical Contributors own use in an Oracle training course. The document may not be modified or altered in
any way. Except where your use constitutes "fair use" under copyright law, you may
and Reviewers not use, share, download, upload, copy, print, display, perform, reproduce, publish,
Christopher Andrews license, post, transmit, or distribute this document in whole or in part without the
express authorization of Oracle.
Tammy Bednar
Tom Best The information contained in this document is subject to change without notice. If you
Harald van Breederode find any problems in the document, please report them in writing to: Oracle University,
Mary Jane Bryksa 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Marielle Canning
Tim Chien Restricted Rights Notice
Donna Cooksey
Judy Ferstenberg If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is
Gerlinde Frenzen applicable:
Joel Goodman
Pete Jones U.S. GOVERNMENT RIGHTS
Isabelle Marchand The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Sabiha Miri license agreement and/or the applicable U.S. Government contract.
Manish Pawar
Jim Spiller Trademark Notice
George Stabler
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Anthony Woodell Corporation and/or its affiliates. Other names may be trademarks of their respective
owners.
Editor
Daniel Milne
n l y
Graphic Designer
Satish Bettegowda
e O
Publisher
U s
Jobi Varghese
A I
O
l &
n a
te r
I n
c l e
r a
O
Contents
1 Introduction
Objectives 1-2
Course Objectives 1-3
What Is Backup and Recovery? 1-4
Performing Backup and Recovery Operations for an Oracle Database 1-5
Using Oracle Recovery Manager 1-6
Recovery Manager Components 1-7
Using Oracle Secure Backup 1-9
Overview of Oracle Backup Methods 1-10
When Do You Need to Use a Backup for Recovery? 1-12
Responding to User Error 1-13
Overview of Data Recovery 1-14
Oracle Database Architecture: Crash Recovery 1-15
Oracle Database Architecture: Recovery After Media Failure 1-16
Developing a Backup and Recovery Strategy for Your Oracle Database 1-17
Oracle Solutions for High Availability 1-18
n l y
Summary 1-21
e O
Oracle High Availability Solutions for Unplanned Downtime 1-19
2 Configuring for Recoverability

U s
Objectives 2-2
A I
Configuring Your Database for Backup and Recovery Operations 2-3
Configuring ARCHIVELOG Mode 2-4
O
l &
Specifying a Backup Destination 2-5
Specifying a Retention Policy 2-6
n a
Using a Flash Recovery Area 2-8
te r
Defining a Flash Recovery Area 2-9
Defining Flash Recovery Area Using Enterprise Manager 2-10
I n
Flash Recovery Area Space Management 2-11
c l e
Flash Recovery Area Space Usage 2-13
Monitoring the Flash Recovery Area 2-14
r aBenefits of Using a Flash Recovery Area 2-15

Summary 2-16
O Practice Overview 2-17
iii
3 Using RMAN to Create Backups
Objectives 3-2
Using RMAN to Create Backups 3-3
Backup Destinations 3-4
Configuring Persistent Settings for RMAN 3-5
Using Enterprise Manager to Configure RMAN Settings 3-6
Managing Persistent Settings 3-7
Configuring and Allocating Channels for Use in Backups 3-8
Configuring Backup Optimization 3-9
Creating Backup Sets 3-11
Creating Image Copies 3-12
BACKUP Command Options 3-14
Creating a Whole Database Backup 3-16
RMAN Backup Types 3-17
Fast Incremental Backup 3-19
Enabling Fast Incremental Backup 3-20
Monitoring Block Change Tracking 3-21
Creating an Oracle-Suggested Backup 3-22
Creating Duplexed Backup Sets 3-23
Creating Duplexed Backup Sets Using CONFIGURE BACKUP COPIES 3-24
Creating Duplexed Backup Sets Using BACKUP COPIES 3-25
n l y
Creating Backups of Backup Sets 3-26
Configuring Control File Autobackups 3-27
e O
Using a Media Manager 3-29
Creating Proxy Copies 3-31
U s
Managing Backups: Reporting 3-32
A
Using Enterprise Manager to View Backup Reports 3-34
I
O
Managing Backups: Crosschecking and Deleting 3-35
Summary 3-37
l &
Using Enterprise Manager to Manage Backups 3-36
Practice Overview 3-38

n a
4
te r
Using RMAN to Perform Recovery
Objectives 4-2
I n
Using RMAN RESTORE and RECOVER Commands 4-3
c l e
Performing Recovery Using Enterprise Manager 4-4
r a
Comparing Complete and Incomplete Recovery 4-5
Complete Recovery Following the Loss of Datafiles 4-6
O
Performing Complete Recovery: Loss of a Non-Critical datafile in ARCHIVELOG
Mode 4-7
iv
Performing Complete Recovery: Loss of a System-Critical Datafile in ARCHIVELOG
Mode 4-8
Recovery Using Incrementally Updated Backups 4-9
Using the Flash Recovery Area for Fast Recovery 4-10
Performing Restore and Recovery of a Database in NOARCHIVELOG Mode 4-11
Using Incremental Backups to Recover a Database in NOARCHIVELOG Mode 4-12
Restoring and Recovering the Database on a New Host 4-13
Preparing to Restore the Database to a New Host 4-14
Restoring the Database to a New Host 4-15
Performing Recovery with a Backup Control File 4-19
Restoring the Server Parameter File from the Control File Autobackup 4-20
Restoring the Control File from Autobackup 4-21
Performing Disaster Recovery 4-23
Summary 4-25
5 Using Oracle Flashback Technologies

Objectives 5-2
Using Oracle Flashback Technology 5-3
Flashback Drop and the Recycle Bin 5-4
Understanding the Recycle Bin 5-5
Restoring Tables from the Recycle Bin 5-6
n l y
Automatic Space Reclamation in the Recycle Bin 5-7
Manual Space Reclamation in the Recycle Bin 5-8
e O
Bypassing the Recycle Bin 5-9
Querying the Recycle Bin 5-10 U s
Querying Data in Dropped Tables 5-11
A I
O
Using Flashback Technology to Query Data 5-12
Configuring Undo for Flashback 5-13
l
Flashback Query: Overview 5-14 &
a
Flashback Query: Example 5-15
n
te r
Flashback Versions Query: Overview 5-16
Using Enterprise Manager to Perform Flashback Versions Query 5-17
I n
Flashback Versions Query: Considerations 5-18
Flashback Transaction Query: Overview 5-19
l e
Using Enterprise Manager to Perform Flashback Transaction Query 5-20
c
Flashback Transaction Query: Considerations 5-21
r aFlashback Table: Overview 5-22
O Flashback Table 5-23

Enabling Row Movement on a Table 5-24
Performing Flashback Table 5-25
v
Flashback Table: Considerations 5-26
Flashback Database: Overview 5-27
Flashback Database Architecture 5-28
Configuring Flashback Database 5-29
Using Enterprise Manager to Configure Flashback Database 5-30
Flashback Database: Examples 5-31
Using Enterprise Manager to Perform Flashback Database 5-32
Flashback Database Considerations 5-35
Monitoring Flashback Database 5-36
Tuning Considerations for Flashback Database 5-39
Using Guaranteed Restore Points 5-41
Summary 5-42
6 Using RMAN to Create a Duplicate Database

Objectives 6-2
Using RMAN to Create a Duplicate Database 6-3
Using a Duplicate Database 6-4
Creating a Duplicate Database 6-5
Creating an Initialization Parameter File for the Auxiliary Instance 6-6
Specifying Parameters to Control File Naming 6-7
Starting the Instance in NOMOUNT Mode 6-9
n l y
Ensuring That Backups and Archived Redo Log Files Are Available 6-10
Allocating Auxiliary Channels 6-11
e O
Using the RMAN DUPLICATE Command 6-12
U s
Understanding the RMAN Duplication Operation 6-13
Specifying Options for the DUPLICATE Command 6-14
A I
O
Using Enterprise Manager to Create a Duplicate Database 6-15
Using Enterprise Manager: Source Working Directory 6-16
l &
Using Enterprise Manager: Select Destination 6-17
a
Using Enterprise Manager: Destination Options 6-18
n
Summary 6-20
te r
Using Enterprise Manager: Review Page 6-19
n
I
7
l e
Performing Tablespace Point-in-Time Recovery
c
Objectives 7-2
r a
Tablespace Point-in-Time Recovery (TSPITR) Concepts 7-3
O
Tablespace Point-in-Time Recovery (TSPITR): Terminology 7-4
Tablespace Point-in-Time Recovery: Architecture 7-5
Understanding When to Use TSPITR 7-7
vi
Preparing for TSPITR 7-8
Determining the Correct Target Time 7-9
Determining the Tablespaces for the Recovery Set 7-10
Identifying Objects That Will Be Lost 7-11
Performing Basic RMAN TSPITR 7-12
Performing Fully Automated TSPITR 7-13
Using Enterprise Manager to Perform TSPITR 7-14
Understanding TSPITR Processing 7-15
Performing Customized RMAN TSPITR with an RMAN-Managed Auxiliary Instance 7-17
Performing RMAN TSPITR Using Your Own Auxiliary Instance 7-18
Troubleshooting RMAN TSPITR 7-19
Summary 7-21
8 Using the RMAN Recovery Catalog

Objectives 8-2
RMAN Repository Data Storage: Comparison of Options 8-3
Storing Information in the Recovery Catalog 8-4
Reasons to Use a Recovery Catalog 8-5
Creating the Recovery Catalog: Three Steps 8-6
Configuring the Recovery Catalog Database 8-7
Creating the Recovery Catalog Owner 8-8
n l y
Creating the Recovery Catalog 8-9
e
Managing Target Database Records in the Recovery Catalog 8-10
O
Registering a Database in the Recovery Catalog 8-11
Using Enterprise Manager to Register a Database 8-12
U s
Cataloging Additional Backup Files 8-15 A I
Unregistering a Target Database from the Recovery Catalog 8-14
O
Manually Resynchronizing the Recovery Catalog 8-16
Using RMAN Stored Scripts 8-17
l &
n a
Creating RMAN Stored Scripts 8-18
Executing RMAN Stored Scripts 8-19
te r
Displaying RMAN Stored Script Information 8-20
Updating and Deleting RMAN Stored Scripts 8-21
I n
Backing Up and Recovering the Recovery Catalog 8-22
l e
Re-creating an Unrecoverable Recovery Catalog 8-23
c
Exporting and Importing the Recovery Catalog 8-24
r aUpgrading the Recovery Catalog 8-25
O Dropping the Recovery Catalog 8-26

Summary 8-27
vii
9 Monitoring and Tuning RMAN
Objectives 9-2
Monitoring RMAN Sessions 9-3
Monitoring RMAN Job Progress 9-5
Monitoring RMAN Job Performance 9-7
Interpreting RMAN Message Output 9-8
Using the DEBUG Option 9-9
Understanding RMAN Code Layer Error Numbers 9-10
Interpreting RMAN Error Stacks 9-11
Tuning RMAN 9-12
RMAN Multiplexing 9-13
Allocating Disk Buffer: Example 9-14
Allocating Tape Buffers 9-15
Comparing Synchronous and Asynchronous I/O 9-16
Monitoring RMAN Job Performance 9-18
Asynchronous I/O Bottlenecks 9-19
Synchronous I/O Bottlenecks 9-20
Tape Backup Speed 9-21
Tape Subsystem Performance Rules 9-22
Controlling Tape Buffer Size with BLKSIZE 9-23
Channel Tuning 9-24
Tuning the BACKUP Command 9-25 n l y
Tuning RMAN Backup Performance 9-26
e O
Setting LARGE_POOL_SIZE 9-27
Tuning RMAN Tape Streaming Performance Bottlenecks 9-28
U s
Summary 9-30
A I
O
10 Oracle Secure Backup Overview
Objectives 10-2
l &
a
Oracle Secure Backup Tape Backup Management 10-3
n
te r
What Is Oracle Secure Backup? 10-4
Oracle Secure Backup: Tape Management and Integration with Oracle Products 10-5
I n
Client/Server Architecture Host Roles 10-6
Oracle Secure Backup for Centralized Tape Backup Management 10-7
l e
Typical SAN Environment 10-8
c
r a
Oracle Secure Backup Interface Options 10-9
Media Concepts: Overview 10-10
O
Backup Pieces and Backup Images 10-11
Media Management Expiration Policies 10-12
Oracle Secure Backup Media Family 10-14
viii
Tape Drives and Libraries 10-15
Virtual Tape Libraries (VTL) 10-17
Managing Data to Be Protected 10-18
Oracle Secure Backup Jobs 10-19
Securing Data and Access to the Backup Domain 10-20
Oracle Secure Backup: The Integration Advantage 10-22
Why Use Oracle Secure Backup? 10-23
Summary 10-24
11 Installing Oracle Secure Backup

Objectives 11-2
Performing Preinstallation Tasks 11-3
Installation and Configuration of the Administrative Domain 11-4
Performing Installation Tasks 11-5
Administrative Server Installation: Example 11-6
Wizard-Based Installation on Windows 11-13
Oracle Secure Backup Interfaces 11-14
Integration with Enterprise Manager 11-15
Oracle Secure Backup Administrative Server Page 11-16
Configuring the Administrative Server in EM 11-17
Oracle Secure Backup Web Tool Home Page 11-18
Common obtool Commands 11-19 n l y
Configuring Oracle Secure Backup Users 11-20
e O
Adding Oracle Secure Backup Users 11-21
Preauthorizing Access 11-23
U s
Summary 11-24
A I
12 Using RMAN and Oracle Secure Backup O
Objectives 12-2
l &
a
RMAN and Oracle Secure Backup Basic Process Flow 12-3
n
te r
RMAN Database Backup to Tape 12-4
Database Backup Storage Selector 12-5
I n
Defining Database Storage Selectors 12-7
Media Families and RMAN 12-8
l e
Oracle Database Disk and Tape Backup Solution 12-9
c
r a
Backing Up the Flash Recovery Area to Tape 12-10
Defining Retention for RMAN Backups 12-11
O Backup Settings 12-12

Scheduling Backups with EM 12-13
Oracle-Suggested Backup to Tape 12-14
ix
RMAN and Oracle Secure Backup Job Execution 12-15
Managing Database Tape Backups 12-16
Performing Database Recovery 12-18
RMAN Automatic Failover to Previous Backup 12-19
Summary 12-20
13 Backing Up File-System Files with Oracle Secure Backup

Objectives 13-2
Backing Up File-System Files with Oracle Secure Backup 13-3
File-System Backups 13-4
Managing Media Families 13-5
Dataset Script: Examples 13-6
Creating Datasets 13-9
Creating Backup Windows 13-11
Creating Backup Schedules 13-13
Creating Backup Triggers 13-14
Previewing a Backup Trigger 13-16
Creating On-Demand Backup Requests 13-17
Submitting Backup Requests 13-19
Reviewing Jobs 13-20
Summary 13-21 n l y
e O
14 Restoring File-System Backups with Oracle Secure Backup
U s
Objectives 14-2
A I
Browsing the Catalog for File-System Backup Data 14-3
Restoring File-System Data 14-4
O
Restoring File-System Files with Oracle Secure Backup 14-5
The Restore Page 14-6
l &
a
Listing All File-System Backups of a Client 14-7
n
te r
Creating a Catalog-Based Restore Request 14-8
Submitting Restore Requests 14-12
Summary 14-13
I n
c l e
r a
O
x
15 Managing Oracle Secure Backup Security
Objectives 15-2
Guarding Access and Data 15-3
Managing User Access Control 15-4
Predefined Classes and User Rights 15-5
Defining an Oracle Secure Backup User 15-8
Oracle Secure Backup User: OS Permissions 15-9
Preauthorization 15-11
Assigning Windows Account Information 15-12
Authentication 15-13
Leveraging Oracle Security Technology 15-14
Administrative Server Certificate Authority (CA) 15-16
Oracle Wallets 15-18
Encrypted Backups to Tape 15-20
Creating RMAN Encrypted Backups 15-21
Using Transparent Mode Encryption 15-22
Using Password Mode Encryption 15-24
Using Dual Mode Encryption 15-25
Restoring Encrypted Backups 15-26
Performing Encrypted Recovery 15-27
Summary 15-28
Practice Overview 15-29 n l y
16 Managing the Administrative Domain
e O
Objectives 16-2
U s
Oracle Secure Backup Processes: Daemons 16-3
Managing Common Daemon Operations 16-5
A I
Managing Policies and Defaults 16-6
O
Configuring Oracle Secure Backup Policies 16-7
l &
Oracle Secure Backup: Backup Metadata Catalogs 16-8
a
Oracle Secure Backup: Directory Structure 16-10
n
te
Adding Clients 16-12 r
Backing Up the Catalog 16-11
I n
Adding Media Servers 16-13
NAS Devices 16-15
l e
Adding NDMP Media Servers 16-16
c
r a
Adding Devices 16-17
Discovering Devices on NDMP Hosts 16-19
O Managing Devices 16-20

Tape Library Properties 16-21
Tape Drive Properties 16-22
xi
Managing Volumes 16-23
Oracle Secure Backup Jobs 16-25
Managing Jobs 16-27
Viewing Job Properties and Transcripts 16-29
Suspending and Resuming Job Dispatching 16-31
Job Summaries 16-33
Displaying Log Files and Transcripts 16-34
Summary 16-35
Appendix A: Practices
Appendix B: Practice Solutions
Appendix C: Oracle Secure Backup Additional Installation Topics

Topics C-2
Windows Installation: Overview C-3
Stopping Tape Device Drivers C-4
Oracle Secure Backup Setup C-6
Service Startup Dialogs C-8
Service Login Dialog Box C-9
Oracle Secure Backup Installed Files C-10 n l y
Installed Files for Host Role: Administrative Server C-14
Installed Files for Host Role: Media Server C-16
e O
Installed Files for Host Role: Client C-17
U s
Specifying Installation Parameters C-18
Client Installation: Example C-20
A I
Media Server Installation: Example C-21
Verifying Your Installation C-22 O
l
Uninstalling Oracle Secure Backup C-23&
Summary C-25
n a
Appendix D: Glossary
te r
I n
c l e
r a
O
xii
Introduction
n l y
Copyright © 2006, Oracle. All rights reserved.
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives
After completing this lesson, you should be able to:

• Describe course objectives
• Describe backup methods
• Describe the forms of data recovery
• Describe Oracle Recovery Manager architecture
• Plan a recovery strategy
• Plan a backup strategy based on your recovery
strategy
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
Oracle Database 10g: Backup and Recovery 1 - 2
Course Objectives
After completing this course, you should be able to:

• Use Oracle Recovery Manager (RMAN) to perform
backup and recovery operations
• Create a duplicate database
• Perform tablespace point-in-time recovery
• Create and manage an RMAN recovery catalog
• Use Oracle Secure Backup to back up and restore
Oracle databases and file-system data to and from tape
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
What Is Backup and Recovery?
Backup and recovery constitutes the strategies and

procedures you employ to:
• Protect your database against data loss
• Reconstruct your database following data loss
n l y
e O
What Is Backup and Recovery?
U s
The phrase backup and recovery refers to the strategies and techniques that are employed by
should loss occur. A I

database administrators to protect the database from loss and to reconstruct the database
O
l &
n a
te r
I n
c l e
r a
O
Performing Backup and Recovery Operations for
an Oracle Database
For performing backup and recovery based on physical

backups, the following solutions are available:
• Recovery Manager: A utility with a command-line client
and an Enterprise Manager GUI interface
• User-managed backup and recovery: A technique that
involves using operating system commands to create
backups and using SQL*Plus commands for additional
backup and recovery operations
n l y
e O
Performing Backup and Recovery Operations for an Oracle Database
U s
Physical backups are backups of the physical files that comprise your Oracle database,
A I
including datafiles, control files, and archived redo log files. You can make backups of your
database by using Recovery Manager (RMAN), a utility that creates and manages backups and
O
enables you to perform recovery operations. Alternatively, you can create backups of your
l &
database files and perform recovery through a combination of SQL commands and operating
system commands. RMAN is the preferred solution for backup and recovery operations for an
Oracle database.
n a
te r
I n
c l e
r a
O
Using Oracle Recovery Manager
• RMAN:
– Is a command-line client for advanced functions
– Has powerful control and scripting language
– Has a published API that enables interface with most
popular backup software
– Backs up data, control, archived log, and server
parameter files
– Backs up files to disk or tape
• Enterprise Manager uses Recovery Manager (RMAN) to
perform backup and recovery operations.
n l y
e O
Using Oracle Recovery Manager
U s
RMAN is the component of Oracle Database that is used to perform backup and recovery
backups, and back up either the whole database or a portion of it. A I

operations. It can make consistent and inconsistent backups, perform incremental or full
O
RMAN uses its own powerful job control and scripting language, as well as a published API
&
that interfaces RMAN with many popular backup software solutions.
l
n a
RMAN can store backups on disk for quick recovery or place them on tape for long-term
storage. In order for RMAN to store backups on tape, an interface to the tape device known as
te r
a Media Management Library (MML) must be configured.
Enterprise Manager supplies a graphical interface to the most commonly used RMAN
I n
functionality. Advanced backup and recovery operations are accessible through the RMAN
c l e
command-line client.
r a
O
Recovery Manager Components
Server Recovery
Target database session Manager Enterprise
(control file (RMAN) Manager
repository)
Options
Server
session
Channel Channel Channel

Auxiliary
MML
database
Recovery
catalog
Disk Flash Recovery database
Area
n l y
e O
Recovery Manager Components
U
Recovery Manager executable: The Recovery Manager command-line interface is invoked
s
invokes server sessions to perform the desired tasks. A I
through the RMAN client application. RMAN interprets user commands and appropriately
O
Enterprise Manager: Enterprise Manager Database Control supplies a graphical interface to
the most commonly used RMAN functionality.
l &
n a
Server sessions: The server processes (UNIX) or threads (Windows) invoked by RMAN
connect to the target database to perform the backup, restore, and recovery functions through a
te r
PL/SQL interface. These sessions read or write files from or to disk, tape, or the Flash
Recovery Area, which is a storage location specified as the default storage area for files related
I
to database recovery.
n
c l e
Target database: The database for which backup and recovery operations are being
performed using RMAN is called the target database. The control file of the target database
r a
contains information about its physical structure, such as the size and location of datafiles,
online and archived redo log files, and control files. This information is used by the server
O
sessions invoked by RMAN in backup and recovery operations.

Recovery Manager Components (continued)
Auxiliary database: An auxiliary database is used when creating a duplicate database or
performing tablespace point-in-time recovery (TSPITR). For the tasks, the auxiliary database
serves as the destination of the new copy of the database or the recovered tablespaces. An
auxiliary database can reside on the same host as its parent or on a different host.
Channel: A channel represents one stream of data to a device type. To perform and record
backup and recovery operations, RMAN requires a link to the target database. A channel
establishes this link by creating a session in the target database that is able to interface with the
host file system (to interface with disks) and the Media Management Library (to interface with
tapes). You can allocate channels manually or preconfigure channels by using automatic
channel allocation.
Flash Recovery Area: The Flash Recovery Area is a location in which Oracle Database can
store and manage files related to backup and recovery. Additional information is provided later
in the lesson.
RMAN repository: RMAN maintains metadata about the target database and its backup and
recovery operations in the RMAN repository. Among other things, RMAN stores information
about its own configuration settings, the target database schema, archived redo logs, and all
backup files that are on disk or tape. RMAN repository data is always stored in the control file
of the target database.
Recovery catalog: The RMAN repository data can optionally be kept in a recovery catalog,
which is a separate Oracle database.
Media Management Library: The Media Management Library (MML) is used by RMAN
n l y
e O
when writing to or reading from tapes. The additional media management software required
for using the tape medium is provided by media and storage system vendors. Also, the Oracle
s
Secure Backup product allows RMAN to back up to tape without requiring third-party tools.
U
A I
O
l &
n a
te r
I n
c l e
r a
O
Using Oracle Secure Backup
• One tool to backup and restore Oracle databases and

file-system data to and from tape
• Integrated with RMAN and Enterprise Manager
• Supports Oracle9i and Oracle Database 10g
n l y
e O
Using Oracle Secure Backup
U s
The Oracle Secure Backup tape management system has been introduced to lower software
A I
costs and complexity. Oracle Secure Backup can back up all types of file-system files.
Although Oracle Secure Backup has no specialized knowledge of database backup and
O
recovery algorithms, it can serve as a media management layer for Recovery Manager
l &
(RMAN) through the system backup to tape (SBT) interface. In this capacity, Oracle Secure
Backup provides the same services for RMAN as other supported third-party SBT libraries.
n a
Oracle Secure Backup delivers reliable database and file system backup to tape, with support
te r
for the major tape drives and libraries accessible through various protocols, including Small
Computer System Interface (SCSI), Small Computer System Interface protocol (iSCSI),
I n
Network Data Management Protocol (NDMP), and Fibre Channel.
Note: Oracle continues to support third-party media management vendors (MMV) through its
l e
Backup Solutions Program (BSP). Oracle Secure Backup uses the same RMAN API as third-
c
r a
party media management software, so you have a choice of products to use for writing your
database backups to tape.
O
Overview of Oracle Backup Methods
• Backup strategies:
– Whole: A backup of the control file and all datafiles that
belong to a database
– Partial: A portion of the database
• Backup types:
– Full: A non-incremental RMAN backup
– Incremental: Only information that has changed since
some previous backup
• Backups modes:
– Offline: Consistent, also referred to as cold backup
– Online: Inconsistent, also referred to as hot backup
n l y
e O
Overview of Oracle Backup Methods
A whole database backup includes all datafiles and at least one control file.
U s
A I
Partial database backups may include zero or more tablespaces, zero or more datafiles, and
may or may not include a control file.
O
Full backups are non-incremental RMAN backups. You can make a full backup of only one
&
datafile. “Full” does not refer to how much of the database is backed up, but to the fact that the
l
backup is not incremental.
n a
te r
Incremental backups make a copy of all data blocks that have changed since some previous
backup. Oracle Database 10g supports two levels of incremental backup (0 and 1). A level 0 or
baseline backup is equivalent to a full backup and contains all data blocks. A level 1
I n
cumulative incremental backs up all database blocks changed since the level 0 backup. A level
c l e
1 differential incremental backs up all database blocks changed since a level 0 or level 1
backup. To restore using incremental backups, the baseline backup must first be restored, and
r
(RMAN). a
then the incremental backup. You can make incremental backups with Recovery Manager
O
Offline backups (also known as cold or consistent backups) are taken while the database is not
open. They are consistent because at the time of the backup, the system change number (SCN)
in the datafile headers matches the SCN in the control files.
Overview of Oracle Backup Methods (continued)
Online backups (also known as hot or inconsistent backups) are taken while the database is
open. The backups are inconsistent because, with the database open, there is no guarantee that
the datafiles are synchronized with the control files.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
When Do You Need to Use a Backup for
Recovery?
The use of a backup to perform recovery is often required

for the following types of errors:
• Media failure: The failure of a read or write of a
database file due to a physical problem with the file
• User errors: Data in your database is changed or
deleted incorrectly
n l y
e O
When Do You Need to Use a Backup for Recovery?
U s
When you experience media failure, such as the loss of a disk drive, you may need to recover
A I
your database. This type of recovery typically requires the use of a backup of the affected files.
In the case of user errors, when data in the database has been incorrectly updated or deleted, a
O
backup may be required to enable you to recover the database to a point before the unwanted
change.
l &
n a
te r
I n
c l e
r a
O
Responding to User Error
Possible responses to user error include:

• Reentering the lost data manually, if a record of the
changes exists
• Importing the dropped object, if a suitable export file
exists or the object is still available on a standby
database
• Performing tablespace point-in-time recovery (TSPITR)
of one or more tablespaces
• Returning the database to a past state using database
point-in-time recovery
• Using one of the Oracle Flashback features to recover
from logical corruption by returning affected objects to
a past state
n l y
e O
Responding to User Error
U s
When a user error occurs, your recovery options are based on the techniques and features you
implemented in anticipation of the error.
A I
In later lessons, you investigate tablespace point-in-time recovery, database point-in-time
recovery, and Oracle Flashback features. O
l &
n a
te r
I n
c l e
r a
O
Overview of Data Recovery
• Crash recovery: Automatic recovery after instance

failure
• Media recovery: Recovery of current datafiles, control
files
– Complete recovery: Recovery of the database to the
most recent point in time
– Incomplete recovery (point-in-time recovery): Recovery
of the database to its state at a specific time or system
change number (SCN)
n l y
e O
Overview of Data Recovery
U s
Crash (instance) recovery and media recovery are performed to restore data integrity.
A I
Crash recovery happens the first time an Oracle database instance is started after a crash (or
SHUTDOWN ABORT). The goal of crash recovery is to bring the datafiles to a transaction-
O
consistent state, preserving all committed changes up to the point when the instance failed.
&
Media recovery is initiated when you have experienced a loss of datafiles or all control files.
l
n a
You can perform a complete recovery to bring the database back to the point of failure by
restoring datafiles from a backup and performing a recovery operation. In addition, you can
system change number (SCN).

te r
perform an incomplete recovery operation by recovering the database to a named time or
I n
c l e
r a
O
Oracle Database Architecture: Crash Recovery
• The online redo log files are used to roll the database
forward.
• Uncommitted changes are rolled back.
Online redo
log files Undo blocks
Database at Database with Database with

time of instance committed and committed
failure uncommitted transactions only
transactions
n l y
e O
Oracle Database Architecture: Crash Recovery
Crash recovery employs two distinct operations:
U s
uncommitted transactions contained in online redo records A I
• Rolling forward the current, online datafiles by applying both committed and
O
• Rolling back changes made in uncommitted transactions to their original state
l &
n a
te r
I n
c l e
r a
O
Oracle Database Architecture: Recovery After
Media Failure
• Datafiles are restored from a backup.

• Archived and online redo log files are used to roll the
database forward.
Online and
archived redo
log files Undo blocks
Recovered
Database with Database with database
restored committed and
datafiles uncommitted
transactions
n l y
e O
Oracle Database Architecture: Recovery After Media Failure
U s
Media recovery is used to recover from a lost or damaged current datafile, server parameter
A I
file (SPFILE), or control file. It can also recover changes that were recorded in the redo log
files but not in the datafiles for a tablespace that went offline without the OFFLINE NORMAL
option.
O
• Must be explicitly invoked by the DBA
l &
Media recovery has the following characteristics:
n a
• Applies needed changes to datafiles that have been restored from backup, not to online
datafiles
te r
• Requires the use of archived redo log files as well as the online redo log file
I n
c l e
r a
O
Developing a Backup and Recovery Strategy for
Your Oracle Database
• Assess service-level criteria, including:

– Data availability requirements
– Data criticality
– Recovery point and time objectives
• Anticipate the errors that will arise in your environment
and put in place the backup procedures needed to
recover from those errors.
n l y
e O
Developing a Backup and Recovery Strategy for Your Oracle Database
U s
Developing best practices for backup and recovery of your Oracle database begins with an
objectives, data availability requirements, and data criticality. A I

assessment of all service level criteria for your environment, including recovery point and time
O
l &
n a
te r
I n
c l e
r a
O
Oracle Solutions for High Availability
In addition to backup and recovery strategies and

procedures, consider the following Oracle solutions:
• Oracle Data Guard: Provides a comprehensive set of
services that create, maintain, manage, and monitor
one or more standby databases
• Oracle Real Application Clusters (RAC): Enables
access to a single database from multiples instances
• Oracle Streams: Enables the propagation and
management of data, transactions, and events in a data
stream
• LogMiner: Enables you to query redo log files through
a SQL interface to provide data recovery
n l y
e O
Additional Oracle Solutions for High Availability
U s
High availability systems are computing environments configured to provide nearly full-time
available despite failures. A I

availability. These systems typically have redundant hardware and software that make them
O
Well-designed high availability systems avoid having single points of failure. When failures
the failed component to backup components.

l &
occur, the failover processes implemented as part of the system move processing performed by
n a
Oracle has a number of products and features that provide high availability in cases of
te r
unplanned downtime or planned downtime. In this course, you focus on various backup and
recovery techniques that help you to meet high availability needs. Additional Oracle solutions
I n
for high availability include Oracle Data Guard, Oracle Real Application Clusters (RAC),
Oracle Streams, and LogMiner.
c l e
r a
O
Oracle High Availability Solutions for
Unplanned Downtime
• Computer failure: Fast-start fault recovery, Real

Application Clusters (RAC), Data Guard, Oracle
Streams
• Storage failure: Automatic Storage Management (ASM),
RMAN with Flash Recovery Area, Data Guard, Oracle
Streams
• Human errors: Oracle security features, Oracle
Flashback technology, LogMiner
• Data corruption: Hardware Assisted Resilient Data
(HARD) initiative, RMAN with Flash Recovery Area,
Data Guard, Oracle Streams
• Site failure: RMAN, Data Guard, Oracle Streams
n l y
e O
Oracle High Availability Solutions for Unplanned Downtime
U s
Oracle provides high availability solutions for the following types of unplanned downtime:
A I
• Computer failure: The system on which the database operates is unavailable
• Storage failure: The storage holding some or all of the database is unavailable
O
• Human errors: Unintentional or malicious actions cause data within the database to
become logically corrupt or unusable
l &
• Data corruption: A hardware or software component causes corrupt data to be read or
written to the database
n a
te r
• Site failure: An event causes all or a significant portion of an application to stop
processing or slow to an unusable level
I n
The table on the following page describes the appropriate Oracle solution for the various types
of unplanned downtimes. Additionally, an estimate of recovery time is provided for each. Use
l e
this table to help plan the appropriate implementation of Oracle solutions to enable you to
c
meet your recovery goals.
r a
O
Oracle High Availability Solutions for Unplanned Downtime (continued)
Source: Oracle Database High Availability Overview
Outage Type Oracle Solution Benefits Recovery Time
Computer Fast-start Fault Tunable and predictable cache Minutes to hours
failures Recovery recovery
RAC Automatic recovery of failed No downtime
nodes and instances, fast
connection failover, and service
failover
Data Guard Fast start failover and fast < 1 minute
connection failover
Oracle Streams Online replica database No downtime
Storage ASM Mirroring; online auto rebalance No downtime
failure
RMAN with flash Fully managed database recovery Minutes to hours
recovery area and managed disk-based backups
Data Guard Fast start failover and fast < 1 minute
connection failover
Human errors Oracle security
features
Restrict user access No downtime
n l y
Oracle Flashback Fine-grained and database-wide
e O
< 30 minutes
technology
LogMiner
rewind capability
Log analysis
U s Minutes to hours
Data
corruption
HARD
storage array A I
Corruption prevention within a No downtime
RMAN with flash O

Online block media recovery and Minutes to hours
recovery area
&
managed disk-based backups
l
Data Guard
n a
Automatic validation of redo < 1 minute
te r blocks; fast failover to an

uncorrupted standby database
Site failure
e
RMAN In
Fully managed database recovery Hours to days
c l
Data Guard Fast start failover and fast Seconds to 5
r a connection failover minutes
O Oracle Streams Online replica database Seconds to 5

minutes

Summary
In this lesson, you should have learned how to:

• Describe backup methods
• Describe the forms of data recovery
• Describe Oracle Recovery Manager architecture
• Plan a recovery strategy
• Plan a backup strategy based on your recovery
strategy
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Configuring for Recoverability
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Configure your database in ARCHIVELOG mode
• Specify a retention policy
• Configure the Flash Recovery Area
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
Configuring Your Database for Backup and
Recovery Operations
• Operate the database in ARCHIVELOG mode.
Archiver
(ARCn)
Online redo Archived
log files redo log files
• Configure the Flash Recovery Area.
Archived Control file Datafile backups

redo log files backups
n l y
e O
Configuring Your Database
When you operate your database in ARCHIVELOG mode, you have more recovery options
U s
A I
after a data loss, including point-in-time recovery of the database or some tablespaces.
It is recommended that you take advantage of the Flash Recovery Area to store as many
O
backup and recovery-related files as possible, including disk backups and archived redo logs.
&
Some features of Oracle Database backup and recovery, such as Oracle Flashback Database
l
a
and guaranteed restore points, require the use of a Flash Recovery Area.
n
te r
I n
c l e
r a
O
Configuring ARCHIVELOG Mode
Perform the following steps to place the database in

ARCHIVELOG mode:
• Using Enterprise Manager:
1. Select the “ARCHIVELOG Mode” check box.
2. Click Apply. The database can be set to ARCHIVELOG
mode only from the MOUNT state.
3. Click Yes when asked whether you want to restart the
database.
• Using SQL commands:
1. Place the database in MOUNT mode.
2. Issue the ALTER DATABASE ARCHIVELOG MODE command
3. Open the database.
n l y
e O
Configuring ARCHIVELOG Mode
U s
Placing the database in ARCHIVELOG mode prevents redo logs from being overwritten until
they have been archived.
A I
The following SQL command is used to place the database in ARCHIVELOG mode:
SQL> ALTER DATABASE ARCHIVELOG; O
&
This command can be issued only while the database is in the MOUNT state.
l
n a
With the database in NOARCHIVELOG mode (the default), recovery is possible only until the
time of the last backup. All transactions made after that backup are lost.
te r
In ARCHIVELOG mode, recovery is possible until the time of the last commit. Most
I n
production databases are operated in ARCHIVELOG mode.
Note: Back up your database after switching to ARCHIVELOG mode because your database is
l e
recoverable only from the last backup taken in that mode.
c
r a
O
Specifying a Backup Destination
Backups can be written to:

• Disk directory
• Tape using Oracle Secure Backup
• Media Management Library (tape device)
• Flash recovery area: Disk area set aside for backup and
recovery and flashback database purposes
n l y
e O
Backup Destinations
U s
Backups can be written to a designated disk directory, a Media Management Library, or the
A I
Flash Recovery Area. Specifying a disk directory or the Flash Recovery Area means that
backups go to hard-disk media. Typically, backups are regularly moved offline to tape via the
O
media management interface in order to maintain disk space availability. Any disk directory
l &
can be specified as the destination of a backup provided that it already exists.
If you set up a Flash Recovery Area, many backup and recovery tasks are simplified for you.
n a
The Oracle database automatically names files for you, and deletes obsolete files when there is
lesson.
te r
space pressure. More information about configuring Flash Recovery is provided later in this
I n
c l e
r a
O
Specifying a Retention Policy
• Retention policy: Describes which backups will be kept

and for how long
• Two types of retention policies:
– Recovery window: Establishes a period of time within
which point-in-time recovery must be possible
File2 File1 Now
File2 needs
to be backed up:
Seven-day retention
– Redundancy: Establishes a fixed number of backups that

must be kept
• Retention policies are mutually exclusive.
n l y
e O
Specifying a Retention Policy
U s
A retention policy describes which backups will be kept and for how long. You can set the
A I
value of the retention policy by using the RMAN CONFIGURE command or Enterprise
Manager. The best practice is to establish a period of time during which it will be possible to
O
discover logical errors and fix the affected objects by doing a point-in-time recovery to just
l &
before the error occurred. This period of time is called the recovery window. This policy is
specified in number of days. For each datafile, there must always exist one backup that
satisfies the following condition:
n a
te r
SYSDATE - checkpoint_time <= recovery_window
For example, if the policy were to be set as follows:
I n
RMAN> CONFIGURE RETENTION POLICY
2 TO RECOVERY WINDOW OF 7 DAYS;
l e
Then, for each file there must be a backup that satisfies:
c SYSDATE - (SELECT checkpoint_time
r a FROM V$DATAFILE WHERE file#= …) >= 7
O
In the example in the slide, File1 has a backup that is within the seven-day retention period.
File2 does not, so it needs to be backed up in order to satisfy the retention policy.

Specifying a Retention Policy (continued)
You should keep the recovery window time period less than or equal to the value of the control
file parameter CONTROL_FILE_RECORD_KEEP_TIME to prevent the record of older
backups from being overwritten in the control file.
If you require a certain number of backups to be retained, then you can set the retention policy
on the basis of the redundancy option. This option requires that a specified number of backups
be cataloged before any backup is identified as obsolete. The default retention policy has a
redundancy of 1, which means that only one backup of a file must exist at any given time. A
backup is deemed obsolete when a more recent version of the same files has been backed up.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Using a Flash Recovery Area
• The Flash Recovery Area provides a centralized

location for control file backups, archived redo logs,
flashback logs, and database backups.
• The Flash Recovery Area can be defined as a directory,
file system, or ASM disk group.
• A single Flash Recovery Area can be shared by more
than one database.
Database area Flash Recovery Area
n l y
e O
Using a Flash Recovery Area
U s
The Flash Recovery Area is a unified storage location for all recovery-related files and
A I
activities in an Oracle database. All files that are needed to completely recover a database
from a media failure are part of the Flash Recovery Area. The recovery-related files include:
O
• Control file: A copy is created in the Flash Recovery Area location at database creation.
l &
• Archived redo log files: When the Flash Recovery Area is configured,
LOG_ARCHIVE_DEST_10 is automatically set to the Flash Recovery Area location. The
a
Archiver background process creates archived redo log files in the Flash Recovery Area
n
te r
and in other configured LOG_ARCHIVE_DEST_n locations. If no
LOG_ARCHIVE_DEST_n locations are defined, the default location for archived redo
I n
log files is in the Flash Recovery Area.
• Flashback logs: Flashback logs are generated when Flashback Database is enabled.
l e
• Control file autobackups: The default location for control file autobackups created by
c
RMAN and autobackups generated by the Oracle database server is the Flash Recovery
r a
Area.
• Datafile copies: The BACKUP AS COPY command creates image datafile copies in the
O Flash Recovery Area.
• RMAN files: This is the default location that is used by RMAN for backups and
restoration of the archive log content from tape for a recovery operation.
Defining a Flash Recovery Area
• The Flash Recovery Area is defined by setting the

following initialization parameters:
– DB_RECOVERY_FILE_DEST_SIZE: Sets the disk limit,
expressed in bytes
– DB_RECOVERY_FILE_DEST: Sets the location for the Flash
Recovery Area
• These parameters are dynamic and can be altered or
disabled.
n l y
e O
Defining a Flash Recovery Area
Use the following mandatory parameters to define the Flash Recovery Area:
U s
A I
• DB_RECOVERY_FILE_DEST_SIZE: You must define a disk limit, which is the
amount of space that the Flash Recovery Area is permitted to use. Setting a disk limit
O
allows the remaining disk space not dedicated to the Flash Recovery Area to be used for
l &
other purposes. The recommended size of the disk limit is the sum of the database size,
size of incremental backups, and size of all archive log files that have not been copied to
a
tape. In addition, when configuring the value of this parameter, it is recommended to set
n
te r
the value approximately 10 percent lower than what the operating system reports as free
space because this disk limit does not include any overhead size that is not known to the
I n
Oracle database. For example, the DB_RECOVERY_FILE_DEST_SIZE parameter
should account for any file system overhead due to file system metadata, compression, or
l e
mirroring. Therefore, if 10 GB is allocated for the Flash Recovery Area and the operating
c
system reports free space as 10 GB (neglecting any file system overhead), then set the
r a
value of this parameter 10 percent lower than 10 GB. The minimum size of the Flash
Recovery Area should be at least large enough to contain archived redo log files that have
O not been copied to tape.
• DB_RECOVERY_FILE_DEST: A Flash Recovery Area specification contains a location,
which is a valid destination to create files.
Defining Flash Recovery Area
Using Enterprise Manager
n l y
e O
Defining Flash Recovery Area Using Enterprise Manager
U s
You can use Enterprise Manager Grid Control and Database Control to easily define the Flash
A I
Recovery Area. On the Database Control home page, navigate to the Maintenance page and
click the Recovery Settings link in the Backup/Recovery Settings region. You can define the
O
Flash Recovery Area location and its size on the Recovery Settings page.
l &
You must set the size of the Flash Recovery Area when specifying its location. Specifying a
size allows any remaining disk space that is not dedicated to the Flash Recovery Area to be
used for other purposes.
n a
te r
I n
c l e
r a
O
Flash Recovery Area Space Management
Disk limit is
reached and a
Flash new file needs Files that are
Database file Recovery to be written no longer
backup Area into the Flash required on disk
1 Recovery Area are deleted
2
3 Space pressure
4 occurs
Warning issued
to user
RMAN updates 1
list of files that 2
may be deleted Backup files
to be deleted
n l y
e O
Flash Recovery Area Space Management
U s
Each time RMAN creates a file in the Flash Recovery Area, the list of files that are no longer
A I
required on disk is updated. When the Flash Recovery Area experiences space pressure or is
low on free space because there are no files that can be deleted from the Flash Recovery Area,
O
you are warned of the danger of running out of disk space. The Oracle Database server and
l &
RMAN continue to create files in the Flash Recovery Area until 100% of the disk limit is
reached. When setting DB_RECOVERY_FILE_DEST_SIZE, you must consider whether you
a
have allocated enough disk space before running out of space or necessitating a backup to
n
provide free space.
te r
tape. Files that are obsolete or have been backed up to tape are likely candidates for deletion to
I n
When a file is written into the Flash Recovery Area and space is needed for that file, the
Oracle Database server deletes a file that is on the obsolete files list. When a file is written and
l e
deleted from the Flash Recovery Area, notification is written into the alert log.
c
Note: When Flash Recovery Area used space is at 85%, a warning is issued, and when used
r a
space is at 97%, a critical warning is issued. These are internal settings and cannot be changed.
A sample alert log output follows:
O WARNING: db_recovery_file_dest_size of 52428800 bytes is
100.00% used, and has 0 remaining bytes available.

Flash Recovery Area Space Management (continued)
You can issue the following query to determine the action to take:
SQL> SELECT object_type, message_type, message_level,
2> reason, suggested_action
3> FROM dba_outstanding_alerts;
Your choice is to add further disk space, back up files to a tertiary device, delete files from the
Flash Recovery Area using RMAN, or consider changing the RMAN retention policy.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Flash Recovery Area Space Usage
• Configure the retention policy to the minimum value

appropriate for your database.
• Back up the archive log files regularly and delete the
files upon completion of the backup.
• Use the RMAN REPORT OBSOLETE and DELETE
OBSOLETE commands to remove backups and file
copies that are not required.
n l y
e O
Flash Recovery Area Space Usage
U s
To avoid running out of space in the Flash Recovery Area, you should never store user-
appropriate: A I
managed files in this area. You should also perform the following steps as needed or
O
• Use RMAN to delete unnecessary files from the Flash Recovery Area.
l &
• Use RMAN to take frequent backups of the Flash Recovery Area.
• Change the RMAN retention policy to retain backups for a smaller period of time.
a
• Change the RMAN archived log deletion policy.
n
te r
• Add disk space and increase the value of the DB_RECOVERY_FILE_DEST_SIZE
database initialization parameter if you are frequently running out of space.
I n
For example, to back up the archived log files in the Flash Recovery Area and then delete the
files after they have been successfully backed up, you would use the RMAN command:
c l e
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
If you use a backup solution other than RMAN, you still have to use RMAN to remove the
r a
files from the Flash Recovery Area. After the archived redo log files have been backed up and
O
removed from disk, use the RMAN CROSSCHECK and DELETE commands to reclaim the
archived log space from the Flash Recovery Area. You should do this on a regular basis, or
after every backup.

Monitoring the Flash Recovery Area
n l y
e O
Monitoring the Flash Recovery Area
U s
Real-time Flash Recovery Area metrics can be viewed through Enterprise Manager Database
Metrics. Scan the list and click Recovery Area. A I

Control. On the Maintenance page, scroll down to the Related Links section and select All
O
The displayed page shows the Recovery Area Free Space (%) metric, which indicates the
recovery area usage.

l &
percentage of the recovery that is free space. Click the percentage number to see the graph of
n a
te r
I n
c l e
r a
O
Benefits of Using a Flash Recovery Area
Using the Flash Recovery Area for recovery-related files:

• Simplifies the location of database backups
• Automatically manages the disk space allocated for
recovery files
n l y
e O
Benefits of Using a Flash Recovery Area
U
Using a Flash Recovery Area for all recovery-related files simplifies the ongoing
s
administration of your database.
A I
Oracle Corporation recommends the use of the Flash Recovery Area for all recovery-related
files. O
l &
n a
te r
I n
c l e
r a
O
Summary

• Configure your database in ARCHIVELOG mode
• Specify a retention policy
• Configure the Flash Recovery Area
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Practice Overview
This practice covers the following topics:

• Placing the database in ARCHIVELOG mode
• Verifying that the Flash Recovery Area is configured
• Using RMAN to connect to the target database
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Using RMAN to Create Backups
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Configure persistent settings
• Configure backup destinations
• Configure backup optimization
• Create duplexed backup sets
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
When creating a backup using RMAN, you can specify:

• Type: Full or incremental
• Files to back up: Entire database, datafiles, control file,
server parameter file, archived redo log files
• Backup type: Image copy or backup set
n l y
e O
U s
A backup is a copy of data from your database that can be used to reconstruct that data. The
When performing a backup using RMAN, you can specify: A I

results of a backup created through RMAN can be either image copies or backup sets.
O
• The type of backup to be performed. You can perform backups of the entire database to
l &
include every used data block in the files (a FULL backup) or incremental backups
(INCREMENTAL). If CONFIGURE CONTROLFILE AUTOBACKUP is enabled, RMAN
n a
automatically backs up the control file and the current server parameter file after a
te r
BACKUP command is executed.
• What to backup. Valid values are DATABASE, DATAFILE, TABLESPACE,
I n
ARCHIVELOG, CURRENT CONTROLFILE, or SPFILE.
• Whether an image copy (AS COPY) or backup set (AS BACKUPSET) is created
l e
• The file name format and location for backup pieces (FORMAT)
c
• Which datafiles or archived redo logs should be excluded from the backup set (SKIP)
r a
• That the input files should be deleted upon the successful creation of the backup set
O (DELETE INPUT)

Backup Destinations
Backups can be written to:

• Disk directory
• Media Management Library (tape device)
– Typically used for disaster recovery, when disk backups
are lost.
• Flash Recovery Area
– This is the disk area set aside for backup and recovery
and flashback database purposes.
– Define the location and the size.
– Files are automatically named by using Oracle Managed
Files.
– Files are automatically retained and deleted as necessary.
n l y
e O
Backup Destinations
U s
Backups can be written to a designated disk directory, a Media Management Library, or the
A I
Flash Recovery Area. Specifying a disk directory or the Flash Recovery Area means that
backups go to hard-disk media. Typically, they are regularly moved offline to tape via the
O
media management interface in order to maintain disk space availability. Any disk directory
l &
can be specified as the destination of a backup provided that it already exists.
If you configure a Flash Recovery Area, many backup and recovery tasks are simplified for
n a
you. The Oracle Database server automatically names files for you, and deletes obsolete files
when there is space pressure.
te r
I n
c l e
r a
O
Configuring Persistent Settings for RMAN
• RMAN is preset with default configuration settings.

• Use the CONFIGURE command to:
– Configure automatic channels
– Specify the backup retention policy
– Specify the number of backup copies to be created
– Set the default backup type to BACKUPSET or COPY
– Limit the size of backup pieces
– Exempt a tablespace from backup
– Enable and disable backup optimization
– Configure automatic backups of control files
n l y
e O
Configuring Persistent Settings for RMAN
U s
To simplify ongoing use of RMAN for backup and recovery, RMAN enables you to set a
A I
number of persistent configuration settings for each target database. These settings control
many aspects of RMAN’s behavior. You can save persistent configuration information such as
O
channel parameters, parallelism, and the default device type in the RMAN repository (which is
l &
stored in either the control file or a recovery catalog database).
These settings have default values, which allow you to use RMAN immediately. However, as
n a
you develop a more advanced backup and recovery strategy, you may have to change these
te r
settings to implement that strategy. You can use the CONFIGURE command to configure
persistent settings for RMAN backup, restore, duplication, and maintenance jobs. These
n
settings are in effect for any RMAN session until the configuration is cleared or changed.
I
c l e
r a
O
Using Enterprise Manager to Configure
RMAN Settings
n l y
e O
Using Enterprise Manager to Configure RMAN Settings
U s
You can use Oracle Enterprise Manager to specify the backup settings for an instance. To
Backup/Recovery Settings section. A I

specify backup settings, on the Maintenance page, select Backup Settings in the
The Backup Settings property page consists of three tabs: O

Management Library (MML) settings
l &
• Device: Used to set the disk and tape configuration settings, including the Media
n a
• Backup Set (shown in the slide): Used to specify parameters for backup sets and to enter
host credentials
te r
• Policy: Used to set various backup and retention policies before you initiate a backup,
I n
such as automatically backing up the control file and SPFILE. The Policy page also
allows you to configure block change tracking support, a feature that provides faster
l e
incremental backups.
c
r a
Note: Backup settings change the databasewide settings and apply to any backups that do not
override settings at the backup level.
O
Managing Persistent Settings
• Use the SHOW command to list current settings:

RMAN> SHOW CONTROLFILE AUTOBACKUP FORMAT;
RMAN> SHOW EXCLUDE;
RMAN> SHOW ALL;
• Use the CLEAR command to reset any persistent setting

to its default value:
RMAN> CONFIGURE BACKUP OPTIMIZATION CLEAR;
RMAN> CONFIGURE MAXSETSIZE CLEAR;
RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;
n l y
e O
Managing Persistent Settings
U s
Using the RMAN SHOW command, you can view the RMAN configuration settings. If SHOW
database configurations are displayed. A I

ALL is executed when connected to a target database, only node-specific configurations and
O
You can return to the default value for any CONFIGURE command by executing the same
command with the CLEAR option.
l &
n a
te r
I n
c l e
r a
O
Configuring and Allocating Channels for
Use in Backups
• Configure automatic channels with the CONFIGURE

command:
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt …
RMAN> BACKUP DATABASE;
• Allocate channels manually with the ALLOCATE
CHANNEL command within a RUN block:
RMAN> RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK; …
BACKUP DATABASE PLUS ARCHIVELOG;
}
n l y
e O
Configuring and Allocating Channels for Use in Backups
U s
Choose from the following options for configuring channels and executing backups:
BACKUP command at the RMAN prompt or within a RUN block. A I

• Configure automatic channels with the CONFIGURE command, and then issue the
O
• Manually allocate channels with the ALLOCATE CHANNEL command within a RUN
block, and then issue BACKUP commands.
l &
n a
te r
I n
c l e
r a
O
Configuring Backup Optimization
• The BACKUP command skips backing up files when the

identical files have already been backed up.
• It is used when the following conditions are true:
– Backup optimization is enabled.
– BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE
options, or BACKUP BACKUPSET ALL commands are
executed.
– Only one type of channel is allocated.
• It can be overriden with the FORCE option.
• It is always used for RECOVERY AREA,
DB_RECOVERY_FILE_DEST, and RECOVERY FILES
BACKUP options.
n l y
e O
Configuring Backup Optimization
U s
If you enable backup optimization, the BACKUP command skips backing up files when the
A I
identical files have already been backed up to the specified device type.
If RMAN determines that a file is identical and it has already been backed up, then it is a
O
candidate to be skipped. However, RMAN performs further checking to determine whether to
l &
skip the file, because both the retention policy and the backup duplexing feature are factors in
the algorithm that RMAN uses to determine whether there are sufficient backups on the
specified device type.
n a
te r
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for detailed
information about the criteria that RMAN uses to determine whether a file is identical and the
I n
backup optimization algorithm.
c l e
You can enable backup optimization on the Backup Settings page in Enterprise Manager or by
issuing the CONFIGURE BACKUP OPTIMIZATION ON command. By default, backup
r a
optimization is disabled.
Backup optimization is automatically enabled for the BACKUP RECOVERY AREA |
O
DB_RECOVERY_FILE_DEST and BACKUP RECOVERY FILES commands.

Configuring Backup Optimization (continued)
To override backup optimization and back up all files whether or not they have changed,
specify the FORCE option on the BACKUP command as in the following example:
BACKUP DEVICE TYPE sbt BACKUPSET ALL FORCE;
Note that the FORCE option does not apply to files in the recovery area.
You can disable backup optimization on a persistent basis using Enterprise Manager or by
issuing the following command:
CONFIGURE BACKUP OPTIMIZATION OFF;
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Creating Backup Sets
RMAN> BACKUP AS BACKUPSET

2> FORMAT '/BACKUP/df_%d_%s_%p.bus'
3> TABLESPACE hr_data;
Datafile Datafile
1 1
Datafile Datafile
2 2
Datafile Datafile
3 3
Tablespace Backup
HR_DATA set
n l y
e O
Creating Backup Sets
U s
RMAN can store its backups in an RMAN-exclusive format called a backup set. A backup set
file backups. A I
is a collection of files called backup pieces, each of which may contain one or more database
O
Note: The FORMAT parameter specifies a pattern to use in creating a file name for the backup
ALLOCATE CHANNEL and CONFIGURE commands.

l &
pieces created by this command. The FORMAT specification can also be provided through the
n a
te r
I n
c l e
r a
O
Creating Image Copies
RMAN> BACKUP AS COPY

2> DATAFILE '/ORADATA/users_01_db01.dbf'
3> FORMAT '/BACKUP/users01.dbf';
RMAN> BACKUP AS COPY
4> ARCHIVELOG LIKE '/arch%'
5> FORMAT 'arch_%U.bak';
Copy of datafile 3
Datafile 3 Datafile 3
Copy of archived log

Archived Archived
log file log file
n l y
e O
Creating Image Copies
U s
An image copy is a clone of a single datafile, archived redo log, or control file. An image copy
A I
can be created with the BACKUP AS COPY command or with an operating system command.
When you create the image copy with the RMAN BACKUP AS COPY command, the server
O
session validates the blocks in the file and records the copy information in the control file.
l &
An image copy has the following characteristics:
• An image copy can be written only to disk. When large files are being considered,
n a
copying may take a long time, but restoration time is reduced considerably because the
te r
copy is available on the disk.
• If files are stored on disk, they can be used immediately by using the SWITCH command
I n
in RMAN, which is equivalent to the ALTER DATABASE RENAME FILE SQL statement.
• In an image copy, all blocks are copied, whether they contain data or not, because an
l e
Oracle database process copies the file and performs additional actions such as checking
c
for corrupt blocks and registering the copy in the control file. To speed up the process of
r a
copying, you can use the NOCHECKSUM parameter.
O
• Image copy can be part of a full or incremental level 0 backup because a file copy always
includes all blocks. You must use the level 0 option if the copy will be used in
conjunction with an incremental backup set.

Creating Image Copies (continued)
The example in the slide creates two image copies:
• A copy of the users01_db01.dbf datafile, renamed as users01.dbf, and stored in
the BACKUP directory
• A copy of the archived redo log files
The example assumes that you are using automatic channel allocation. If you manually
allocate channels, you must include the COPY command within the RUN statement as follows:
RMAN> RUN {
2> ALLOCATE CHANNEL c1 type disk;
3> COPY
4> DATAFILE '/ORADATA/users_01_db01.dbf' to
5> '/BACKUP/users01.dbf',
6> ARCHIVELOG 'arch%' to
7> 'arch_%U.bak';
8> }
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
BACKUP Command Options
• Scan for logical corruptions and physical corruptions.

• Set a threshold on the number of detected corruptions
allowed before aborting.
• Validate the target input files before performing a
backup operation.
• Duplex the backup set.
• Overwrite an existing backup set or image copy.
• Pass control of the data transfer between storage
devices and the datafiles on disk to the media
management layer.
• Encrypt the backup files.
n l y
e O
BACKUP Command Options
U s
During the backup operation, an Oracle database process computes a checksum for each block
A I
to detect corruption. RMAN verifies the checksum when restoring the copy. This is referred to
as physical corruption detection. You can use the NOCHECKSUM option to suppress the
O
checksum operation and speed up the backup process. If the database is already maintaining
l &
block checksums, then this option has no effect.
You can use the CHECK LOGICAL option to test data and index blocks that pass physical
a
corruption checks for logical corruption—for example, corruption of a row piece or index
n
te r
entry. If logical corruption is detected, the block is logged in the alert log and trace file of the
server process. You can set a threshold for the allowed number of logical and physical
I n
corruptions with the MAXCORRUPT parameter. As long as the sum of physical and logical
corruptions that is detected for a file remains below this value, the RMAN backup operation
l e
completes and the Oracle database populates the V$DATABASE_BLOCK_CORRUPTION
c
view with the corrupt block ranges. If MAXCORRUPT is exceeded, then the operation
r a
terminates without populating the view.
O
You can use the VALIDATE option to check for physical and logical errors in database files.
When using the BACKUP command with the VALIDATE option, RMAN scans the specified
files and verifies their contents, testing whether this file can be backed up. This command does
not actually back up the specified files.
BACKUP Command Options (continued)
You can create up to four identical copies of each backup piece by duplexing the backup set.
Use any of the following commands to produce a duplexed backup set:
• BACKUP COPIES
• SET BACKUP COPIES
• CONFIGURE ... BACKUP COPIES
RMAN does not produce multiple backup sets, but produces identical copies of each backup
piece in the set. You cannot use this option with the BACKUP AS COPY command to create
multiple image copies.
If you specify REUSE, you enable RMAN to overwrite an already existing backup set or
image copy with the same file name as the file that BACKUP is currently creating.
The PROXY copy functionality backs up the specified files by giving the media management
software control over the data transfer between storage devices and the datafiles on disk. The
media manager—not RMAN—decides how and when to move data. When you run BACKUP
with the PROXY option, RMAN performs these steps:
1. It searches for a channel of the specified device type that is proxy capable. If no such
channel is found, then RMAN issues a warning and attempts a conventional (that is,
nonproxy) backup of the specified files.
2. If RMAN locates a proxy-capable channel, it calls the media manager to check whether it
can proxy copy the files. If the media manager cannot proxy copy, then RMAN uses
conventional backup sets to back up the files.
n l y
If you do not want RMAN to try a conventional copy when a proxy copy fails, use the ONLY
option.
e O
Because image copies are written only to disk, you cannot use the PROXY option with the
BACKUP AS COPY command.
U s
Note: If you specify PROXY, then the %p variable must be included in the FORMAT string
either explicitly or implicitly within %U.
Encryption of backups is discussed later in this lesson. A I
O
l &
n a
te r
I n
c l e
r a
O
Creating a Whole Database Backup
RMAN> BACKUP DATABASE

PLUS ARCHIVELOG;
Control
Archived log Datafile file SPFILE
file copies copies
n l y
e O
Creating a Whole Database Backup
U s
A whole database backup is a copy of all datafiles and the control file. You can optionally
A I
include the server parameter file (SPFILE) and archived redo log files. Using Recovery
Manager to make an image copy of all the database files simply requires mounting the
O
database, starting RMAN, and entering the BACKUP command shown in the slide.
described previously:
l &
Note: You must have issued the following CONFIGURE commands to make the backup as
n
• CONFIGURE DEFAULT DEVICE TYPE TO disk;
a
te r
• CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
• CONFIGURE CONTROLFILE AUTOBACKUP ON;
I n
You can also create a backup (either a backup set or image copies) of previous image copies of
all datafiles and control files in the database by using the following command:
c l e
RMAN> BACKUP COPY OF DATABASE;
r a
By default, RMAN executes each BACKUP command serially. However, you can parallelize
the copy operation by:
O
• Using the CONFIGURE DEVICE TYPE DISK PARALLELISM n command, where n is
the desired degree of parallelism
• Allocating multiple channels
• Specifying one BACKUP AS COPY command and listing multiple files
RMAN Backup Types
• A full backup contains all used Full, or "level 0

incremental backup"
datafile blocks.
• A level 0 incremental backup is
equivalent to a full backup that
has been marked as level 0.
• A cumulative level 1 Cumulative
incremental backup
incremental backup contains
only blocks modified since the
last level 0 incremental
backup.
Differential
• A differential level 1 incremental backup
incremental backup contains
only blocks modified since the
last incremental backup.
n l y
e O
RMAN Backup Types
Full Backups
U s
A I
A full backup is different from a whole database backup. A full datafile backup is a backup
that includes every used data block in the file. RMAN copies all blocks into the backup set or
O
image copy, skipping only datafile blocks that have never been used. For a full image copy,
l &
the entire file contents are reproduced exactly. A full backup cannot be part of an incremental
backup strategy; it cannot be the parent for a subsequent incremental backup.
Incremental Backups
n a
te r
An incremental backup is either a level 0 backup, which includes every block in the datafiles
except blocks that have never been used, or a level 1 backup, which includes only those blocks
I n
that have been changed since a previous backup was taken. A level 0 incremental backup is
c l e
physically identical to a full backup. The only difference is that the level 0 backup can be used
as the base for a level 1 backup, but a full backup can never be used as the base for a level 1
backup.
r a
Incremental backups are specified through the INCREMENTAL keyword of the BACKUP
O
command. You specify INCREMENTAL LEVEL = [0 | 1].

RMAN Backup Types (continued)
Incremental Backups (continued)
RMAN can create multilevel incremental backups as follows:
• Differential: Is the default type of incremental backup that backs up all blocks changed
after the most recent incremental backup at either level 1 or level 0
• Cumulative: Backs up all blocks changed after the most recent backup at level 0
Examples
• To perform an incremental backup at level 0, use the following command:
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
• To perform a differential incremental backup, use the following command:
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
• To perform a cumulative incremental backup, use the following command:
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
RMAN makes full backups by default if neither FULL nor INCREMENTAL is specified.
Unused block compression causes never-written blocks to be skipped when backing up
datafiles to backup sets, even for full backups.
A full backup has no effect on subsequent incremental backups, and is not considered part of
any incremental backup strategy, although a full image copy backup can be incrementally
updated by applying incremental backups with the RECOVER command. This is covered later
in this lesson.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Fast Incremental Backup
• Optimizes incremental backups

– Tracks which blocks have changed since the last backup
• Oracle Database 10g has integrated change tracking:
– A change tracking file is introduced.
– Changed blocks are tracked as redo is generated.
– Database backup automatically uses the changed block
list.
List of changed
1011001010110 Change
blocks
CTWR 0001110100101 tracking
Redo 1010101110011 file
generation
SGA Redo log
n l y
e O
Fast Incremental Backup
U s
The goal of an incremental backup is to back up only those data blocks that have changed
A I
since a previous backup. You can use RMAN to create incremental backups of datafiles,
tablespaces, or the whole database. During media recovery, RMAN examines the restored files
O
to determine whether it can recover them from an incremental backup. RMAN always chooses
faster than reapplying individual changes.

l &
incremental backups over archived redo logs because applying changes at a block level is
n a
If you enable the block change tracking feature, Oracle Database tracks the physical location
te r
of all database changes in a file called the change tracking file. RMAN uses this change
tracking data to determine which blocks to read during an incremental backup, creating much
I n
faster incremental backups by eliminating the need to read the entire datafile. The maintenance
of this file is fully automatic and does not require your intervention. The size of the block
l e
change tracking file is proportional to the:
c
• Database size in bytes
r a
• Number of enabled threads in a RAC environment
O
• Number of old backups maintained by the block change tracking file
The minimum size for the block change tracking file is 10 MB, and any new space is allocated
in 10 MB increments. The Oracle database does not record block change information by
default.
Enabling Fast Incremental Backup
ALTER DATABASE
{ENABLE|DISABLE} BLOCK CHANGE TRACKING
[USING FILE '...']
n l y
e O
Enabling Fast Incremental Backup
U s
You enable block change tracking from the Database Control home page. Click the Policy tab
A I
from the Backup Settings on the Maintenance tabbed page. You do not need to set the block
change tracking file destination if the DB_CREATE_FILE_DEST initialization parameter is
O
set because the file is created as an Oracle Managed File (OMF) file in the
l &
DB_CREATE_FILE_DEST location. You can, however, specify the name of the block
change tracking file, placing it in any location you choose.
a
You can also enable or disable this feature by using an ALTER DATABASE command. If the
n
te r
change tracking file is stored in the database area with your database files, then it is deleted
when you disable change tracking. You can rename the block change tracking file by using the
I n
ALTER DATABASE RENAME command. Your database must be in the MOUNT state to rename
the tracking file. The ALTER DATABASE RENAME FILE command updates the control file to
l e
refer to the new location. You can use the following syntax to move the block change tracking
file name:
c
r a ALTER DATABASE RENAME FILE '...' TO '...';
O
Monitoring Block Change Tracking
SQL> SELECT filename, status, bytes

2 FROM v$block_change_tracking;
SQL> SELECT file#, avg(datafile_blocks),
2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
5 FROM v$backup_datafile
6 WHERE used_change_tracking = 'YES'
7 AND incremental_level > 0
8 GROUP BY file#;
n l y
e O
Monitoring Block Change Tracking
The output of the V$BLOCK_CHANGE_TRACKING view shows where the block change
U s
size (in bytes) of the file. A I
tracking file is located, the status of block change tracking (ENABLED/DISABLED), and the
O
The query on the V$BACKUP_DATAFILE view shows how effective the block change
l &
tracking is in minimizing the incremental backup I/O (the PCT_READ_FOR_BACKUP
column). A high value indicates that RMAN reads most blocks in the datafile during an
n a
incremental backup. You can reduce this ratio by decreasing the time between the incremental
backups.
te r
A sample formatted output from the V$BACKUP_DATAFILE query is shown below:
FILE#
I n
BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
-----
1
c l e
--------------
56320
----------- ------------------- ----------------
4480 7 462
r
2
3 a 3840
49920
2688
16768
70
33
2408
4457
O 4
5
640
19200
64
256
10
1
1
91

Creating an Oracle-Suggested Backup
n l y
e O
Creating an Oracle-Suggested Backup
U s
Enterprise Manager makes it easy for you to set up an Oracle-suggested backup strategy that
A I
protects your data and provides efficient recoverability to any point in the preceding 24 hours.
The Oracle-suggested strategy uses the incremental backup and incrementally updated backup
O
features, providing faster recoverability than is possible when applying database changes from
the archived log files.
l &
To establish an Oracle-suggested strategy, navigate to the Maintenance page. In the
n a
Backup/Recovery region, select Schedule Backup. The Backup Strategy enables you to select
te r
from the Oracle-Suggested Backup and Customized Backup strategies. The Oracle-suggested
strategy takes a full database copy as the first backup. Because it is a whole database backup,
I n
you might want to consider taking this at a period of least activity. After that, an incremental
backup to disk is taken every day. Because these backups on disk are retained, you can always
l e
perform a full database recovery or a point-in-time recovery to any time within the past day.
c
r a
After you complete and accept your required options, your database is backed up once daily,
using incremental backups and incrementally applied backups, allowing quick recovery to any
O
time in the preceding 24 hours.

Creating Duplexed Backup Sets
To create a duplexed backup set use:

• CONFIGURE ... BACKUP COPIES
• BACKUP...COPIES
Datafile Datafile
1 1 Datafile
1
Datafile
Datafile 2 Datafile
2 2
Datafile
Datafile 3 Datafile
3 3
Backup
Tablespace set 1 Backup
HR_DATA set 2
n l y
e O
Creating Duplexed Backup Sets
U s
RMAN can make up to four copies of a backup set simultaneously, each an exact duplicate of
A I
the others. A copy of a backup set is a copy of each backup piece in the backup set, with each
copy getting a unique copy number (for example, 0tcm8u2s_1_1 and 0tcm8u2s_1_2).
O
In most cases, the easiest method of duplexing backup sets is to use BACKUP...COPIES or
l &
CONFIGURE ... BACKUP COPIES to duplex backup sets. For DISK channels, specify
multiple values in the FORMAT option to direct the multiple copies to different physical disks.
a
For sbt channels, if you use a media manager that supports Version 2 of the SBT API, then
n
separate tape).
te r
the media manager will automatically put each copy onto a separate medium (for example, a
I n
Note that it is not possible to duplex backup sets to the Flash Recovery Area, and that
duplexing only applies to backup sets, not image copies. You receive an error if you specify
l e
the BACKUP... COPIES option when creating image copy backups. The
c
CONFIGURE...BACKUP COPIES setting is ignored for image copy backups.
r a
Note: Duplexed backup sets are typically used for tape backups.
O
Creating Duplexed Backup Sets Using
CONFIGURE BACKUP COPIES
RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES

> FOR DEVICE TYPE sbt TO 2;
RMAN> CONFIGURE DATAFILE BACKUP COPIES
> FOR DEVICE TYPE sbt TO 2;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
RMAN> BACKUP DEVICE TYPE DISK AS COPY DATABASE;
n l y
e O
Creating Duplexed Backup Sets Using CONFIGURE BACKUP COPIES
Use the CONFIGURE ... BACKUP COPIES command to specify the number of identical
U s
A I
backup sets that you want to create on the specified device type. This setting applies to all
backups except control file autobackups (because the autobackup of a control file always
O
produces one copy) and backup sets when backed up with the BACKUP BACKUPSET
command.
l &
Note: You must have automatic channels configured.
n a
To create a duplexed backup set with CONFIGURE BACKUP COPIES perform the following
steps:
te r
1. Configure the number of copies on the desired device type for datafiles and archived redo
log files.
I n
2. Execute the BACKUP command.
l e
3. Issue a LIST BACKUP command to verify your backup.
c
r a
O
Creating Duplexed Backup Sets Using
BACKUP COPIES
RMAN> BACKUP AS BACKUPSET DEVICE TYPE sbt

2> COPIES 2
3> INCREMENTAL LEVEL 0
4> DATABASE;
n l y
e O
Creating Duplexed Backup Sets Using BACKUP COPIES
U s
You can use the BACKUP command with the COPIES option to override other COPIES or
DUPLEX settings to create duplexed backup sets.
A I
To duplex a backup with BACKUP COPIES, perform the following steps:
O
1. Specify the number of identical copies with the COPIES option of the BACKUP
command.
l &
2. Issue a LIST BACKUP command to verify your backup.
n a
te r
I n
c l e
r a
O
Creating Backups of Backup Sets
RMAN> BACKUP DEVICE TYPE DISK AS BACKUPSET

2> DATABASE PLUS ARCHIVELOG;
RMAN> BACKUP DEVICE TYPE sbt BACKUPSET ALL;
Datafile Datafile
1 1
Datafile
Datafile 2
2 Datafile
3
Datafile
3 Archived
redo logs
Archived
redo logs
Backup sets
n l y
e O
Creating Backups of Backup Sets
Use the RMAN BACKUP BACKUPSET command to back up previously created backup sets.
U s
backup sets can be backed up to any available device type. A I
Only backup sets that were created on device type DISK can be backed up using RMAN. The
O
The BACKUP BACKUPSET command uses the default disk channel to copy backup sets from
nondisk channel.
l &
disk to disk. To back up from disk to tape, you must either configure or manually allocate a
n a
te r
I n
c l e
r a
O
Configuring Control File Autobackups
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
n l y
e O
Configuring Control File Autobackups
U s
To avoid losing a copy of the current control file, you should configure RMAN to take
A I
automatic backups of the control file. The automatic backup of the control file occurs
independently of any backup of the current control file explicitly requested as part of your
O
backup command. If you are operating RMAN in NOCATALOG mode, it is highly
file, your database may be unrecoverable.

l &
recommended that you activate control file autobackup. Otherwise, if you lose your control
n a
To configure control file autobackup, modify the backup policy for your database by using
te r
Enterprise Manager or use the following RMAN command:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
I n
By default, control file autobackups are disabled. If you enable control file autobackups, then
RMAN automatically backs up the control file and the current server parameter file (if used to
l e
start up the database) in one of two circumstances:
c
• A successful backup is recorded in the RMAN repository.
r a
• A structural change to the database affects the contents of the control file, which,
O therefore, must be backed up. Control file autobackups that take place as the result of
structural changes are always written to disk.

Configuring Control File Autobackups (continued)
For non-Oracle Managed Files (non-OMF) files, the control file autobackup file name has a
default format of %F for all device types, so that RMAN can guess the file location and restore
it without a repository. This variable format translates into c-IIIIIIIIII-YYYYMMDD-
QQ, where:
• IIIIIIIIII stands for the DBID
• YYYYMMDD is a time stamp of the day the backup is generated
• QQ is the hex sequence that starts with 00 and has a maximum of FF
You can change the default format by using the CONFIGURE CONTROLFILE AUTOBACKUP
FORMAT FOR DEVICE TYPE type TO 'string' command. The value of string must
contain the substitution variable %F and cannot contain other substitution variables. For
example:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '/u01/oradata/cf_ORCL_auto_%F';
Note: Control file autobackups are stored in the Flash Recovery Area, unless otherwise
specified. Files created in the Flash Recovery Area are OMF files and do not adhere to the
naming convention described above.
With a control file autobackup, RMAN can recover the database even if the current control
file, recovery catalog, and server parameter file are inaccessible. Because the path used to
store the autobackup follows a well-known format, RMAN can search for and restore the
server parameter file or control file from that autobackup.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Using a Media Manager
Server
Recovery session
Manager (channel)
Media
management
library
Oracle Secure Or
Backup with
built-in MML Media
management
server software
n l y
e O
Using a Media Manager
U s
To use tape storage for your database backups, RMAN requires Oracle Secure Backup or a
A I
media manager. Oracle Secure Backup is covered in detail later in this course.
A media manager is a utility that loads, labels, and unloads sequential media, such as tape
O
drives for the purpose of backing up, restoring, and recovering data. The Oracle Database
controlled by the media manager.

l &
server calls MML software routines to back up and restore datafiles to and from media that is
n a
Some media management products can completely manage all data movement between Oracle
te r
datafiles and the backup devices. Some products that use high-speed connections between
storage and media subsystems can reduce much of the backup load from the primary database
server.
I n
c l e
Note that the Oracle Database server does not need to connect to the Media Management
Library (MML) software when it backs up to disk.
r a
O
Using a Media Manager (continued)
The Oracle Backup Solutions Program (BSP) provides a range of media management products
that are compliant with Oracle’s MML specification. Software that is compliant with the MML
interface enables an Oracle Database session to back up data to a media manager and request
the media manager to restore backups. Check with your media vendor to determine whether it
is a member of the Oracle BSP.
Before you can begin using RMAN with a media manager, you must install the media
manager software and make sure that RMAN can communicate with it. Instructions for this
procedure should be available in the media manager vendor’s software documentation.
Depending on the product that you are installing, perform the following basic steps:
1. Install and configure the media management software on the target host or production
network. No RMAN integration is required at this stage.
2. Ensure that you can make non-RMAN backups of operating system files on the target
database host. This step makes it easier to troubleshoot problems at a later time. Refer to
your media management documentation to learn how to back up files to the media
manager.
3. Obtain and install the third-party media management module for integration with the
Oracle database. This module must contain the library loaded by the Oracle Database
server when accessing the media manager.
Backup and Restore Operations Using a Media Manager
l y
The following Recovery Manager script performs a datafile backup to a tape drive controlled
by a media manager:
n
run {
# Allocating a channel of type 'sbt' for serial device
e O
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
BACKUP DATAFILE 3;
U s
I
}
A
When Recovery Manager executes this command, it sends the backup request to the Oracle
Database session performing the backup. The Oracle Database session identifies the output
O
channel as a media management device and requests the media manager to load a tape and
write the output.
l &
n a
The media manager labels and keeps track of the tape and the names of the files on each tape.
The media manager also handles restore operations. When you restore a file, the following
steps occur:
te r
1. The Oracle Database server requests the restoration of a particular file.
I n
2. The media manager identifies the tape containing the file and reads the tape.
3. The media manager passes the information back to the Oracle Database session.
l e
4. The Oracle Database server writes the file to disk.
c
r a
O
Creating Proxy Copies
• A proxy copy is a backup to a third-party media

storage device in which the entire data transfer is
conducted by a media manager.
• Media manager must support proxy copy functionality.
• It is created with BACKUP PROXY command.
• RMAN creates conventional backup if proxy copy is
not supported.
• Use PROXY ONLY to force failure if proxy copy is not
possible.
n l y
e O
Creating Proxy Copies
U s
A proxy copy is a backup to a third-party media storage device in which the entire data transfer
A I
is conducted by a media manager. You can use the PROXY option of the BACKUP command to
create a proxy copy. This option can be used only with media managers that support it. During
O
a proxy copy, RMAN turns over control of the data transfer to the media manager.
l &
When you execute the BACKUP PROXY command, RMAN queries the media manager to
determine whether it can perform a proxy copy for the specified file. If the media manager
n a
cannot proxy copy the file, then RMAN attempts a conventional backup of the file. You can
te r
use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.
Proxy copy can be used with datafiles or archived redo log files, as shown in these examples:
I n
BACKUP DEVICE TYPE sbt PROXY DATAFILE 3;
e
BACKUP DEVICE TYPE sbt PROXY ONLY DATABASE;
c l
BACKUP DEVICE TYPE sbt PROXY ONLY ARCHIVELOG ALL;
r a
Note: SBT channels must be configured with the appropriate parameters.
Control files are never backed up with proxy copy. If the PROXY option is specified on an
O
operation that includes backup of a control file, it is ignored for the control file backup.

Managing Backups: Reporting
Use the following RMAN commands to obtain information

about your backups:
• LIST: Displays information about backup sets, proxy
copies, and image copies recorded in the repository
• REPORT: Produces a detailed analysis of the repository
• REPORT NEED BACKUP: Lists all datafiles that require a
backup
• REPORT OBSOLETE: Identifies files that are no longer
needed to satisfy backup retention policies
n l y
e O
Managing Backups: Reporting
U s
Use the RMAN LIST command to display information about backup sets, proxy copies, and
image copies recorded in the repository. Use this command to list:
A I
• Backups and copies that do not have the AVAILABLE status in the RMAN repository
O
• Backups and copies of datafiles that are available and can possibly be used in a restore
operation
l &
• Backup sets and copies that contain a backup of a specified list of datafiles or specified
tablespaces
n a
or range
te r
• Backup sets and copies that contain a backup of any archived logs with a specified name
I n
• Backup sets and copies restricted by tag, completion time, recoverability, or device
• Incarnations of a specified database or of all databases known to the repository
l e
• Stored scripts in the recovery catalog
c
Use the RMAN REPORT command to analyze information in the RMAN repository in more
r
detail. a
O
The REPORT NEED BACKUP command is used to identify all datafiles that need a backup.
The report assumes that the most recent backup would be used in the event of a restore.

Managing Backups: Reporting (continued)
Using the REPORT OBSOLETE command, you can identify files that are no longer needed to
satisfy backup retention policies. By default, the REPORT OBSOLETE command reports
which files are obsolete under the currently configured retention policy. You can generate
reports of files that are obsolete according to different retention policies by using
REDUNDANCY or RECOVERY WINDOW retention policy options with the REPORT
OBSOLETE command.
Refer to the Oracle Database Backup and Recovery Reference for detailed syntax information.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Using Enterprise Manager to View Backup
Reports
n l y
e O
Using Enterprise Manager to View Backup Reports
U s
You can use the Backup Report page to display lists of backup jobs that are known to the
A I
database through the information recorded about them in the database control file.
You can filter the jobs that appear in the Result table by using the Filter By fields at the top of
O
the page. The Result table lists basic information about each backup job, such as the Start
l &
Time, the Time Taken, and the Status of the backup job. You can also use the Result table to
drill down to individual, detailed backup job reports by using the link in the Backup Name
column.
n a
te r
You can drill down to a “Summary of job” page of the backup job by clicking the Status of the
job in the Result table, where you can view the contents of the output log.
I n
You can use the View Backup Report Job page to display detailed information about the
c l e
current backup job selected on the Backup Report page. The information displayed on this
page is derived from the information recorded in the database control file.
r a
The View Backup Report Job page displays result information in the Result section in various
categories, such as Input Summary, containing rollup information about the files that were
O
backed up; Output Summary, containing rollup information about the Backup Sets and Image
Copies; and then Inputs and Outputs sections that display tables containing detailed job
information about the datafiles, control files, backup sets, backup pieces, and image copies.
Managing Backups: Crosschecking and Deleting
Use the following RMAN commands to manage your

backups:
• CROSSCHECK: Verifies the status of backups and copies
recorded in the RMAN repository against media such
as disk or tape
• DELETE EXPIRED: Removes only files whose status in
the repository is EXPIRED
• DELETE OBSOLETE: Deletes backups that are no longer
needed
n l y
e O
Managing Backups: Crosschecking and Deleting
U s
Use the CROSSCHECK command to ensure that data about backups in the recovery catalog or
A I
control file is synchronized with actual files on disk or in the media management catalog. The
CROSSCHECK command operates only on files that are recorded in the RMAN repository.
O
The CROSSCHECK command checks only objects marked AVAILABLE or EXPIRED by
l &
examining the files on disk for DISK channels or by querying the media manager for sbt
channels. The CROSSCHECK command updates the repository records for any files that it is
a
unable to find to EXPIRED. It does not delete any files that it is unable to find.
n
te r
The DELETE command can remove any file that the LIST and CROSSCHECK commands can
operate on. For example, you can delete backup sets, archived redo logs, and datafile copies.
I n
The DELETE command removes both the physical file and the catalog record for the file. The
DELETE OBSOLETE command deletes backups that are no longer needed. It uses the same
l e
REDUNDANCY and RECOVERY WINDOW options as REPORT OBSOLETE.
c
r a
If you delete backups without using RMAN, you can use the CROSSCHECK or UNCATALOG
commands to remove the files from the recovery catalog.
O
Refer to the Oracle Database Backup and Recovery Reference for detailed syntax information.

Using Enterprise Manager to Manage Backups
n l y
e O
Using Enterprise Manager to Manage Backups
U s
You can manage your backup records through Enterprise Manager. Backup maintenance
functions provided in Enterprise Manager include the following:
A I
• Viewing lists of backups (backup sets and image copies) recorded in the RMAN
repository
O
• Crosschecking your repository:
l &
- Verifying that the backups listed in the repository exist and are accessible
a
- Marking as expired any backups not accessible at the time of the crosscheck
n
te r
• Deleting the record of expired backups from your RMAN repository
• Deleting obsolete backups from the repository and from disk
I n
You can access the Manage Current Backups page in Enterprise Manager by clicking Manage
Current Backups in the Backup/Recovery region of the Maintenance page. The Manage
l e
Current Backups page has two property pages: Backup Set (the initial view) and Image Copy.
c
Each serves a similar purpose, listing the backups as recorded in the Recovery Manager
r a
repository.
O
Note: If you use a Flash Recovery Area for your backup storage, many maintenance activities
are reduced or eliminated because of the Flash Recovery Area’s automatic management of
disk space and file retention based on the retention policy.

Summary

• Configure persistent settings
• Configure backup destinations
• Configure backup optimization
• Create duplexed backup sets
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Practice Overview

• Configuring control file autobackup
• Configuring backup optimization
• Creating a whole database backup using the Oracle-
suggested strategy
• Creating duplexed backup sets
• Managing backups
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Using RMAN to Perform Recovery
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Perform complete recovery
• Perform recovery on a new host
• Perform recovery using a backup control file
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Using RMAN RESTORE and RECOVER Commands
• RESTORE command: Restores database files from

backup
• RECOVER command: Recovers restored files by
applying changes recorded in the redo log files
RMAN> SQL 'ALTER TABLESPACE inv_tbs OFFLINE IMMEDIATE';

RMAN> RESTORE TABLESPACE inv_tbs;
RMAN> RECOVER TABLESPACE inv_tbs;
RMAN> SQL 'ALTER TABLESPACE inv_tbs ONLINE';
n l y
e O
Using RMAN RESTORE and RECOVER Commands
U s
Reconstructing the contents of all or part of a database from a backup typically involves two
A I
phases: retrieving a copy of the datafile from a backup, and reapplying changes to the file since
the backup from the archived and online redo logs, to bring the database to the desired SCN
(usually the most recent one).
O
l &
The RESTORE command retrieves the datafile onto disk from a backup location on tape, disk, or
other media, and makes it available to the database server. RMAN restores from backup any
n a
archived redo logs required during the recovery operation. If backups are stored on a media
te r
manager, channels must be configured or allocated for use in accessing backups stored there.
The RECOVER command takes the restored copy of the datafile and applies to it the changes
I n
recorded in the database’s redo logs.
c l e
Refer to the Oracle Database Backup and Recovery Reference for additional information and
examples using the RESTORE and RECOVER commands.
r a
O
Performing Recovery Using Enterprise Manager
The Enterprise Manager Recovery Wizard creates and runs

an RMAN script to perform the recovery.
n l y
e O
Performing Recovery Using Enterprise Manager
U s
You can also perform complete or incomplete recovery by using the Recovery Wizard available
Backup/Recovery section. A I
through Enterprise Manager. On the Maintenance page, click Perform Recovery in the
O
l &
n a
te r
I n
c l e
r a
O
Comparing Complete and Incomplete Recovery
There are two types of recovery:

• Complete recovery: Brings the database up to the
present, including all committed data changes made to
the point in time when the recovery was requested
• Incomplete recovery: Brings the database up to a
specified point in time in the past, before the recovery
operation was requested
Complete
recovery
Incomplete
recovery Recovery
Restore from Missing transactions task started
this backup after incomplete recovery at this time
n l y
e O
Comparing Complete and Incomplete Recovery
U s
When you perform complete recovery, you bring the database to the state where it is fully up-to-
A I
date, including all committed data modifications to the present time. Incomplete recovery,
however, brings the database to some point in the past. This means there are missing
O
transactions; any data modifications done between the recovery destination time and the present
l &
are lost. In many cases, this is the desirable goal because there may have been some changes
made to the database that need to be undone. Recovering to a point in the past is a way to
remove the unwanted changes.
n a
te r
I n
c l e
r a
O
Complete Recovery Following the Loss of
Datafiles
Archived
log Archived
log Online
Redo log
Changes applied
Database
2 opened Undo applied
4 5
1 3 6
Restored Datafiles containing
datafiles committed and Recovered
uncommitted datafiles
transactions
n l y
e O
Complete Recovery Following the Loss of Datafiles
U s
The following steps describe what takes place during complete recovery following the loss of
datafiles:
1. Damaged or missing files are restored from a backup. A I
O
2. Changes from incremental backups, archived redo log files, and online redo log files are
l &
applied as necessary. The redo log changes are applied to the datafiles until the current
online log is reached and the most recent transactions have been reentered. Undo blocks are
a
generated during this entire process. This is referred to as rolling forward or cache recovery.
n
te r
3. The restored datafiles may now contain committed and uncommitted changes.
4. The database is opened before undo is applied. This is to provide higher availability.
I n
5. The undo blocks are used to roll back any uncommitted changes. This is sometimes referred
to as transaction recovery.
l e
6. The datafiles are now in a recovered state and are consistent with the other datafiles in the
c
database.
r a
O
Performing Complete Recovery: Loss of a
Non-Critical datafile in ARCHIVELOG Mode
If a datafile is lost or corrupted, and that file does not

belong to the SYSTEM or UNDO tablespace, then restore and
recover the missing datafile.
n l y
e O
Performing Complete Recovery: Loss of a Non-Critical datafile in ARCHIVELOG
Mode
U s
A I
With the database in ARCHIVELOG mode, the loss of any datafile not belonging to the SYSTEM
or UNDO tablespaces only affects objects that are in the missing file.
O
To restore and recover the missing datafile using Enterprise Manager, perform the following
steps:
l &
1. Click Perform Recovery on the Maintenance properties page.
n a
2. Select “Datafiles” as the recovery type, and select “Restore to current time.”
te r
3. Add all datafiles that need recovery.
4. Determine whether you want to restore the files to the default location or (if a disk or
I n
controller is missing) to a new location.
5. Submit the RMAN job to restore and recover the missing files.
l e
Because the database is in ARCHIVELOG mode, recovery up to the time of the last commit is
c
a
possible and users are not required to reenter any data.
r
O
Performing Complete Recovery: Loss of a
System-Critical Datafile in ARCHIVELOG Mode
If a datafile is lost or corrupted, and that file belongs to the

SYSTEM or UNDO tablespace, then perform the following
steps:
1. The instance may or may not shut down automatically.
If it does not, use SHUTDOWN ABORT to bring the
instance down.
2. Mount the database.
3. Restore and recover the missing datafile.
n l y
e O
Performing Complete Recovery: Loss of a System-Critical Datafile
U s
Datafiles belonging to the SYSTEM tablespace or containing UNDO data are considered system
(unlike other datafiles that may be restored with the database open).A I
critical. A loss of one of these files requires the database to be restored from the MOUNT state
Perform the following steps for complete recovery: O

2. Mount the database. l &
1. If the instance is not already shut down, shut it down.
n a
te r
4. Select “Datafiles” as the recovery type, and select “Restore to current time.”
5. Add all datafiles that need recovery.
I n
6. Determine whether you want to restore the files to the default location or (if a disk or
controller is missing) to a new location.
l e
7. Submit the RMAN job to restore and recover the missing files.
c
8. Open the database. Users are not required to reenter data because the recovery is up to the
r a
time of the last commit.
O
Recovery Using Incrementally Updated Backups
RMAN can recover image copies by using incremental

backup files:
• Image copies are updated with all changes up to the
incremental backup SCN.
• Incremental backup reduces the time required for
media recovery.
• There is no need to perform an image copy after the
incremental restoration.
RMAN> RECOVER COPY OF
Incremental 2> DATAFILE {n|'file_name'}
backup files
Image copy
of datafile Incrementally updated
backup
n l y
e O
Recovery Using Incrementally Updated Backups
U s
You can use RMAN to apply incremental backups to datafile image copies. With this recovery
A I
method, you use RMAN to recover a copy of a datafile—that is, you roll forward (recover) the
image copy to the specified point in time by applying the incremental backups to the image
O
copy. The image copy is updated with all changes up through the SCN at which the incremental
l &
backup was taken. RMAN uses the resulting updated datafile in media recovery just as it would
use a full image copy taken at that SCN, without the overhead of performing a full image copy
a
of the database every day. The benefits of applying incremental backups to datafile image copies
n
te r
are that you reduce the time required for media recovery (using archive logs) because you need
to apply archive logs only since the last incremental backup. Also, you do not need to perform a
I n
full image copy after the incremental restoration.
If the recovery process fails during the application of the incremental backup file, you simply
l e
restart the recovery process. RMAN automatically determines the required incremental backup
c
files to apply, from before the image datafile copy until the time at which you want to stop the
r a
recovery process. If there is more than one version of an image copy recorded in the RMAN
O
catalog, RMAN automatically uses the latest version of the image copy. RMAN reports an error
if it cannot merge an incremental backup file with an image copy.

Using the Flash Recovery Area for Fast Recovery
Use the Flash Recovery Area to perform fast recovery by

performing the following steps:
1. Use the SWITCH TO COPY command to switch to a file in
the Flash Recovery Area.
2. Recover the datafile in the Flash Recovery Area.
3. Create an image copy of the datafile in the original
datafile location.
4. Switch to the new image copy.
5. Recover the new image copy.
n l y
e O
Using the Flash Recovery Area for Fast Recovery
U s
You can use datafiles from the Flash Recovery area for fast recovery by performing the
following steps:
1. Take the datafile offline. A I
O
2. Use the SWITCH TO COPY command to restore the datafile from the flash recovery area.
3. Recover the datafile.
4. Bring the datafile online.
l &
a
5. Create an image copy of the datafile in the original location using the BACKUP AS COPY
n
command.
te
6. Take the datafile offline.r
I n
7. Switch to the copy you made in step 5 using the SWITCH TO COPY command.
8. Recover the datafile.
l e
9. Bring the datafile online.
c
r a
O
Performing Restore and Recovery of a Database
in NOARCHIVELOG Mode
• If the database is in NOARCHIVELOG mode, and any

datafile is lost, perform the following tasks:
1. Shut down the instance if it is not already down.
2. Restore the entire database, including all data and
control files, from the backup.
• Users must reenter all changes made since the last
backup.
n l y
e O
Performing Restore and Recovery of a Database in NOARCHIVELOG Mode
The loss of any datafile from a database in NOARCHIVELOG mode requires complete
U s
A I
restoration of the database, including control files and all datafiles.
With the database in NOARCHIVELOG mode, recovery is possible only up to the time of the last
O
backup. So users must reenter all changes made since that backup. For this type of recovery,
perform the following tasks:
l &
1. Shut down the instance if it is not already down.
n a
r
3. Select Whole Database as the type of recovery.
te
I n
c l e
r a
O
Using Incremental Backups to Recover a
Database in NOARCHIVELOG Mode
Use incremental backups to perform limited recovery of a

database in NOARCHIVELOG mode.
STARTUP FORCE MOUNT;

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE NOREDO;
ALTER DATABASE OPEN RESETLOGS;
n l y
e O
Using Incremental Backups to Recover a Database in NOARCHIVELOG Mode
U s
You can perform limited recovery of a NOARCHIVELOG mode database by using incremental
backups. The incremental backups must be consistent backups.
A I
If you have taken incremental backups, RMAN will use your level 0 and level 1 backups to
restore and recover the database. O
&
You must specify the NOREDO option on the RECOVER DATABASE command if the online redo
l
n a
log files are lost or if the redo cannot be applied to the incremental backups. If you do not
specify the NOREDO option, RMAN searches for the online redo log files after applying the
message.
te r
incremental backups. If the online redo log files are not available, RMAN issues an error
I n
Note: If the current online redo log files contain all changes since the last incremental backup,
c l
will be applied. e
you can issue the RECOVER DATABASE command without the NOREDO option and the changes
r a
O
Restoring and Recovering the Database
on a New Host
Use the procedure to:

• Perform test restores
• Move a production database to a new host
Backups RMAN>
Server Server
parameter file parameter file
n l y
e O
Restoring and Recovering the Database on a New Host
U s
Use the procedure described on the following pages to perform test restores. You can also use it
to move a production database to a new host.
A I
The database identifier (DBID) for the restored test database is the same as the DBID of the
O
original database. If you are using a recovery catalog and connect to the test database and the
l &
recovery catalog database, the recovery catalog is updated with information about the test
database. This can impact RMAN’s ability to restore and recover the source database.
n a
You should create a duplicate database using the RMAN DUPLICATE command if your goal is
te r
to create a new copy of your target database for ongoing use on a new host. The duplicate
database is assigned a new DBID which allows it to be registered in the same recovery catalog
I n
as the original target database. Refer to the lesson titled “Using RMAN to Create a Duplicate
Database” for detailed information about the DUPLICATE command.
c l e
r a
O
Preparing to Restore the Database to a New Host
Perform the following steps to prepare:

1. Record the database identifier (DBID) of your source
database.
2. Copy the source database initialization parameter file to
the new host.
3. Ensure that source backups, including the control file
autobackup, are accessible on the restore host.
n l y
e O
Preparing to Restore the Database to a New Host
U s
Perform the steps listed in the slide to prepare for the restore of the database to a new host.
A I
Note: If you are performing a test restore, do not connect to the recovery catalog when restoring
the datafiles. If you connect to the recovery catalog, RMAN records information about the
O
restored datafiles in the recovery catalog and considers the restored database as the current target
l &
database. If your control file is not large enough to contain all of the RMAN repository data on
the backups you need to restore and you must use a recovery catalog, export the catalog and
n a
import it into a different schema or database. Use the copied recovery catalog for the test restore.
te r
I n
c l e
r a
O
Restoring the Database to a New Host
Perform the following steps on the restore host to restore

the database:
1. Configure the ORACLE_SID environment variable.
2. Start RMAN and connect to the target instance in
NOCATALOG mode.
3. Set the database identifier (DBID).
4. Start the instance in NOMOUNT mode.
5. Create a RUN block to:
– Restore the server parameter file from the backup sets
– Shut down the instance (SHUTDOWN ABORT)
6. Edit the restored initialization parameter file.
7. Start the instance in NOMOUNT mode.
n l y
e O
U s
Perform the steps listed on this page and the next on the restore host to restore the database.
$ setenv ORACLE_SID orcl

A I
1. Configure the ORACLE_SID environment variable as shown in the following example:
O
2. Start RMAN and connect to the target instance. Do not connect to the recovery catalog as
shown in the following example:
$ rman TARGET /
l &
a
3. Set the database identifier (DBID). You can find the DBID of your source database by
n
te r
querying the DBID column in V$DATABASE.
RMAN> SET DBID 1090770270;
4. Start the instance in NOMOUNT mode:
I n
RMAN> STARTUP NOMOUNT
c l e
You will receive an error similar to the following because the server parameter file has not
been restored. RMAN uses a “dummy” parameter file to start the instance.
r a startup failed: ORA-01078: failure in processing system

parameters
O
Restoring the Database to a New Host (continued)
5. Create a RUN block to restore the server parameter file from the backup sets and shut down
the instance (SHUTDOWN ABORT) as shown in the example:
RUN
{
RESTORE SPFILE TO PFILE '?/oradata/test/initorcl.ora' FROM
AUTOBACKUP;
SHUTDOWN ABORT;
}
6. Edit the restored initialization parameter file to change any location-specific parameters,
such as those ending in _DEST, to reflect the new directory structure.
7. Start the instance in NOMOUNT mode using your edited text initialization parameter file.
RMAN> STARTUP NOMOUNT
> PFILE='?/oradata/test/initorcl.ora';
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
8. Create a RUN block to:

– Restore the control file
– Mount the database
9. Create the RMAN recovery script to restore and recover
the database.
10.Execute the RMAN script.
11.Open the database with the RESETLOGS option.
n l y
e O
U s
8. Create a RUN block to restore the control file from an autobackup and mount the database
as shown in the example:
RUN
A I
{
O
ALTER DATABASE MOUNT;
l &
RESTORE CONTROLFILE FROM AUTOBACKUP;
n a
9. Query V$DATAFILE to determine the file names of the database on your new host. Create
te r
the RMAN recovery script to restore and recover the database. Use the SET NEWNAME
command to specify the path on your new host for each of the datafiles. Use the SQL
I n
ALTER DATABASE RENAME FILE command to specify the path for the online redo log
l e
files. Include the SET UNTIL command to limit recovery to the end of the archived redo
log files. Include the SWITCH command so that the control file recognizes the new path
c
a
names as the correct names for the datafiles. An example of a recovery script follows:
r
O
RUN
{
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/sysaux.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/users01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SQL "ALTER DATABASE RENAME FILE
''/u01/app/oracle/oradata/orcl/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SET UNTIL SCN 4545727;
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}
10. Execute the recovery script.
11. Open the database with the RESETLOGS option:
RMAN> ALTER DATABASE OPEN RESETLOGS;
l y
After you have completed your test, you can shut down the test database instance and delete the
test database with all of its files.
n
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Performing Recovery with a Backup Control File
• Restore and mount a backup control file when all

copies of the current control file are lost or damaged.
• Execute the RECOVER command after restoring the
backup control file.
• Open the database with the RESETLOGS option after
performing complete or point-in-time recovery.
n l y
e O
Performing Recovery with a Backup Control File
U s
If you have lost all copies of the current control file, you must restore and mount a backup
A I
control file before performing recovery. Your recovery operation may be to recover lost datafiles
or it may be to simply recover the control file. If you are using a recovery catalog, the process is
O
identical to recovery with a current control file because RMAN can use the recovery catalog to
obtain RMAN metadata.
l &
n a
te r
I n
c l e
r a
O
Restoring the Server Parameter File from the
Control File Autobackup
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
RMAN> STARTUP FORCE;
Recovery
Manager
(RMAN) Flash Recovery
Area
Server
parameter
file Database
n l y
e O
Restoring the Server Parameter File from the Control File Autobackup
U s
If you have lost the server parameter file, you can restore it from the autobackup. The procedure
issue the RESTORE SPFILE FROM AUTOBACKUP command. A I

is similar to restoring the control file from autobackup. Set the DBID for your database and then
O
If you are restoring the SPFILE to a nondefault location, specify the command as follows:
&
RESTORE SPFILE TO <file_name> FROM AUTOBACKUP
l
as follows:
n a
If you are restoring the server parameter file from the flash recovery area, specify the command
RMAN> run {
te r
2> restore spfile from autobackup
I n
3> recovery area = '<flash recovery area destination>'
4> db_name = '<db_name>';
c l
5> }
e
r a
O
Restoring the Control File from Autobackup
Recovery
Manager
(RMAN) Flash Recovery
Area
Control
file
Database
RMAN> RESTORE CONTROLFILE TO

2> '/oradata/ctlfile.bak' FROM AUTOBACKUP;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
n l y
e O
Restoring the Control File from Autobackup
U s
If you are not using a recovery catalog, you should have autobackup of the control file
A I
configured, so that you are able to quickly restore the control file if needed. The commands used
for restoring your control file are the same, whether or not you are using a Flash Recovery Area.
O
However, if you are using a Flash Recovery Area, RMAN implicitly cross-checks backups and
l &
image copies listed in the control file, and catalogs any files in the Flash Recovery Area not
recorded in the restored control file, improving the usefulness of the restored control file in the
restoration of the rest of your database.
n a
te r
Note: Tape backups are not automatically cross-checked after the restoration of a control file. If
you are using tape backups, then after restoring the control file and mounting the database, you
I n
must cross-check the backups on tape.
c l e
r a
O
Restoring the Control File from Autobackup (continued)
To restore the control file from an autobackup, the database must be in a NOMOUNT state. You
must set the database identifier (DBID) before issuing the RESTORE CONTROLFILE FROM
AUTOBACKUP command as shown in the following example:
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP NOMOUNT;
RMAN> SET DBID 1090770270;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN searches for a control file autobackup. If one is found, RMAN restores the control file
from that backup to all the control file locations listed in the CONTROL_FILES initialization
parameter.
If you have a recovery catalog, you do not have to set the DBID or use the control file
autobackup to restore the control file. You can use the RESTORE CONTROLFILE command
with no arguments:
RMAN> RESTORE CONTROLFILE;
The instance must be in the NOMOUNT state when you perform this operation, and RMAN must
be connected to the recovery catalog. The restored control file is written to all locations listed in
the CONTROL_FILES initialization parameter.
Use the RESTORE CONTROLFILE... TO <destination> command to restore the control
file to a nondefault location.
l y
If you have also lost the SPFILE for the database and need to restore it from the autobackup, the
n
procedure is similar to restoring the control file from autobackup. You must first set the DBID
for your database, and then use the RESTORE SPFILE FROM AUTOBACKUP command.
e O
After you have started the instance with the restored server parameter file, RMAN can restore
backup information necessary to restore and recover the database.

U s
the control file from the autobackup. After you restore and mount the control file, you have the
A I
After restoring the control files of your database from backup, you must perform complete
media recovery and then open your database with the RESETLOGS option.
O
l &
n a
te r
I n
c l e
r a
O
Performing Disaster Recovery
• Disaster implies the loss of the entire target database,

the recovery catalog database, all current control files,
all online redo log files, and all parameter files.
• Disaster recovery includes the restoration and
recovery of the target database.
• Minimum required set of backups:
– Backups of some datafiles
– Corresponding archived redo logs files
– At least one control file autobackup
n l y
e O
U s
Disaster recovery includes the restoration of and recovery of the target database after the loss of
and the recovery catalog database (if applicable). A I

the entire target database, all current control files, all online redo log files, all parameter files,
O
To perform disaster recovery, the following backups are required as a minimum:
• Backups of some datafiles
l &
• Corresponding archived redo logs generated after the time of the backup
n a
• At least one autobackup of the control file
te r
Note: Refer to the Oracle Database 10g: Data Guard Administration course and the Oracle
Data Guard Concepts and Administration manual for information about how Oracle Data Guard
I n
can provide complete disaster protection.
c l e
r a
O
Basic procedure:
• Restore an autobackup of the server parameter file.
• Start the target database instance.
• Restore the control file from autobackup.
• Mount the database.
• Restore the datafiles.
• Recover the datafiles.
• Open the database with the RESETLOGS option.
n l y
e O
Performing Disaster Recovery (continued)
U s
The basic procedure for performing disaster recovery is outlined in the slide. After you have
A I
mounted the database, follow the steps for performing recovery with a backup control file.
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for a detailed
example. O
l &
n a
te r
I n
c l e
r a
O
Summary

• Perform complete recovery
• Perform recovery on a new host
• Perform recovery using a backup control file
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview

• Performing datafile recovery using different methods
• Performing control file recovery
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Using Oracle Flashback Technologies
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Use Flashback Drop to recover a dropped table
• Use Flashback Query to view the contents of the
database as of any single point in time
• Use Flashback Versions Query to view versions of a
row over time
• Use Flashback Transaction Query to view transaction
history of a row
• Use Flashback Table to restore the contents of a table
to a specific point in the past
• Configure Flashback Database
• Perform Flashback Database to a point in time
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Using Oracle Flashback Technology
Object Scenario Examples Flashback Uses Affects

Level Technology Data
Database Truncate table; Database Flashback TRUE
Undesired multitable logs
changes made
Table Drop table Drop Recycle TRUE
bin
Update with the wrong Table Undo data TRUE
WHERE clause
Compare current data Query Undo data FALSE
with data from the past
Compare versions of a Version Undo data FALSE
row
Tx Investigate several Transaction Undo data FALSE
historical states of data
n l y
e O
Using Oracle Flashback Technology
U s
Flashback technology can be used when a logical corruption occurs in an Oracle database and
A I
you need to recover data quickly and easily. It is often difficult to identify the objects and rows
that are affected by an erroneous transaction. With flashback technology, you can diagnose
O
errors introduced into the database and repair the damage. You can view the transactions that
l &
have contributed to specific row modifications, view the entire set of versions of a given row
during some time period, or just view data as it appeared at a specific time in the past.
n a
The table in the slide shows typical uses of flashback technology.
te r
Flashback Database uses the flashback logs to perform flashback. Flashback Drop uses the
Recycle Bin. All other techniques use undo data.
I n
Not all flashback features modify the database. Some are simply methods to query other
c l e
versions of data. The results of flashback queries can help you to:
• Determine which type of database-modifying flashback operation to perform to correct
r a
the problem
• Use the result set of the flashback queries in an INSERT, UPDATE, or DELETE statement
O that enables you to easily repair the erroneous data

Flashback Drop and the Recycle Bin
RECYCLEBIN = ON
Drop a table Realize a mistake

was made
DROP TABLE
FLASHBACK TABLE
employees;
employees
TO BEFORE DROP;
n l y
e O
Flashback Drop and the Recycle Bin
U s
In previous releases of the Oracle database, if you dropped a table by mistake, you had to
time consuming and resulted in loss of work of other transactions. A I

recover the database to a prior time to recover the dropped table. This procedure was often
O
Oracle Database includes the Flashback Drop feature, which you can use to undo the effects of
&
a DROP TABLE statement without having to use point-in-time recovery.
l
n a
Note: The RECYCLEBIN initialization parameter is used to control whether the Flashback
Drop capability is enabled. If the parameter is set to OFF, then dropped tables do not go into
te r
the Recycle Bin. If this parameter is set to ON, the dropped tables go into the Recycle Bin and
can be recovered. By default, RECYCLEBIN is set to ON.
I n
c l e
r a
O
Understanding the Recycle Bin
BIN$zbjrBdpw==$0 EMPLOYEES
BIN$zbjra9wy==$0 EMPLOYEES_PK
Recycle
bin
USER_OBJECTS
Objects are:
– Renamed
EMPLOYEES – Not moved BIN$zbjrBdpw==$0
EMPLOYEES_PK DBA_FREE_SPACE BIN$zbjra9wy==$0
DROP TABLE employees;
n l y
e O
Understanding the Recycle Bin
U s
Without the Recycle Bin enabled, when you drop a table, the space associated with the table
A I
and its dependent objects is immediately reclaimable (that is, it can be used for other objects).
If the Recycle Bin is enabled, when you drop a table, the space associated with the table and
O
its dependent objects is not immediately reclaimable, even though it appears in
l &
DBA_FREE_SPACE. Instead, the dropped objects are temporarily placed in the Recycle Bin
and still belong to their owner. The space used by Recycle Bin objects is never automatically
n a
reclaimed unless there is space pressure. This enables you to recover Recycle Bin objects for
the maximum possible duration.
te r
When a dropped table is moved to the Recycle Bin, the table and its associated objects and
I n
constraints are renamed using system-generated names. This is necessary to avoid name
conflicts that may arise if you later create a new object with the same name.
c l e
The Recycle Bin itself is a data dictionary table that maintains the relationships between the
r a
original names of dropped objects and their system-generated names. You can query the
contents of the Recycle Bin by using the DBA_RECYCLEBIN view.
O
Restoring Tables from the Recycle Bin
• Restore dropped tables and dependent objects.

• If multiple Recycle Bin entries have the same original
name:
– Use unique, system-generated names to restore a
particular version
– The restored table is last in, first out (LIFO)
• Rename the original name if that name is currently
used.
FLASHBACK TABLE table_name

TO BEFORE DROP [RENAME TO new_name];
n l y
e O
Restoring Tables from the Recycle Bin
Use the FLASHBACK TABLE ... TO BEFORE DROP command to recover a table and all of
U s
A I
its possible dependent objects from the Recycle Bin. You can specify either the original name
of the table or the system-generated name assigned to the object when it was dropped.
O
If you specify the original name, and if the Recycle Bin contains more than one object of that
l &
name, then the object that was moved to the Recycle Bin most recently is recovered first
(LIFO: last in, first out). If you want to retrieve an older version of the table, you can specify
n a
the system-generated name of the table that you want to retrieve, or issue additional
want.
te r
FLASHBACK TABLE ... TO BEFORE DROP statements until you retrieve the table you
I n
If a new table of the same name has been created in the same schema since the original table
was dropped, then an error is returned unless you also specify the RENAME TO clause.
c l e
Note: When you flash back a dropped table, the recovered indexes, triggers, and constraints
r a
keep their Recycle Bin names. Therefore, it is advisable to query the Recycle Bin and
DBA_CONSTRAINTS before flashing back a dropped table. In this way, you can rename the
O
recovered indexes, triggers, and constraints to more usable names.

Automatic Space Reclamation in the Recycle Bin
Recycle bin
BIN$zbjrBdpw==$0
BIN$zbjra9wy==$0 BIN$zbjrBdpw==$0
BIN$zbjra9wy==$0
DBA_FREE_SPACE - RECYCLEBIN 1
Autoextend 3
n l y
e O
Automatic Space Reclamation in the Recycle Bin
U s
As long as the space used by Recycle Bin objects is not reclaimed, you can recover those
• Manual cleanup when you explicitly issue a PURGE command A I

objects by using Flashback Drop. Recycle Bin object reclamation policies are as follows:
O
• Automatic cleanup under space pressure: While objects are in the Recycle Bin, their
l &
corresponding space is also reported in DBA_FREE_SPACE because their space is
automatically reclaimable. The free space in a particular tablespace is then consumed in
the following order:
n a
te r
1. Free space not corresponding to Recycle Bin objects
2. Free space corresponding to Recycle Bin objects. In this case, Recycle Bin objects
I
algorithm. n
are automatically purged from the Recycle Bin using a first in, first out (FIFO)
l e
3. Free space automatically allocated if the tablespace is autoextensible
c
Suppose you create a new table in the TBS1 tablespace. If there is free space allocated to this
r a
tablespace that does not correspond to a Recycle Bin object, this free space is used first. If this
O
is not enough, free space is used that corresponds to Recycle Bin objects that reside in TBS1.
If the free space of some Recycle Bin objects is used, these objects get purged automatically
from the Recycle Bin. You can no longer recover those objects by using the Flashback Drop
feature. As a last resort, the TBS1 tablespace is extended if possible.
Manual Space Reclamation in the Recycle Bin
PURGE {TABLE table_name|INDEX index_name}
PURGE TABLESPACE ts_name [USER user_name]
PURGE [USER_|DBA_]RECYCLEBIN
n l y
e O
Manual Space Reclamation in the Recycle Bin
U
Use the PURGE command to permanently remove objects from the Recycle Bin. When an
s
A I
object is purged from the Recycle Bin, the object and its dependent objects are permanently
removed from the database. Objects purged from the Recycle Bin are no longer recoverable by
O
using the Flashback Drop feature. PURGE can be used as follows:
• PURGE TABLE purges the specified table.
• PURGE INDEX purges the specified index.
l &
a
• PURGE TABLESPACE purges all the objects residing in the specified tablespace. In
n
te r
addition, objects residing in other tablespaces may get purged if they are dependent.
Optionally, you can also specify the USER clause to purge only those objects that belong
I n
to the specified user running low on disk quota for the specified tablespace.
• PURGE RECYCLEBIN purges all the objects that belong to the current user.
l e
RECYCLEBIN and USER_RECYCLEBIN are synonymous.
c
• PURGE DBA_RECYCLEBIN purges all the objects. You must have the appropriate
r a
system privileges or the SYSDBA system privilege to issue this command.
O
Note: For PURGE TABLE and PURGE INDEX commands, if you specify an original name and
if the Recycle Bin contains more than one object of that name, then the object that has been in
the Recycle Bin the longest is purged first (FIFO).

Bypassing the Recycle Bin
DROP TABLE table_name [PURGE] ;
DROP TABLESPACE ts_name

[INCLUDING CONTENTS] ;
DROP USER user_name [CASCADE] ;
n l y
e O
Bypassing the Recycle Bin
You can use the DROP TABLE PURGE command to permanently drop a table and its
U s
A I
dependent objects from the database. When you use this command, the corresponding objects
are not moved to the Recycle Bin. This command provides the same functionality that the
DROP TABLE command provided in previous releases.
O
l &
When you issue the DROP TABLESPACE ... INCLUDING CONTENTS command, the
objects in the tablespace are not placed in the Recycle Bin. Moreover, objects in the Recycle
n a
Bin belonging to the tablespace are purged. When you issue the same command without the
te r
INCLUDING CONTENTS clause, the tablespace must be empty for the command to succeed.
However, there can be objects belonging to the tablespace in the Recycle Bin. In this case,
I n
these objects are purged.
When you issue the DROP USER ... CASCADE command, the user and all the objects owned
l e
by the user are permanently dropped from the database. Any objects in the Recycle Bin
c
a
belonging to the dropped user are purged.
r
O
Querying the Recycle Bin
SELECT owner, original_name, object_name,

type, ts_name, droptime, related, space
FROM dba_recyclebin
WHERE can_undrop = 'YES';
SELECT original_name, object_name,

type, ts_name, droptime, related, space
FROM user_recyclebin
WHERE can_undrop = 'YES';
SQL> SHOW RECYCLEBIN
n l y
e O
Querying the Recycle Bin
U s
You can view all the objects that you have dropped by querying USER_RECYCLEBIN or
users and that are still in the Recycle Bin. A I

RECYCLEBIN. DBA_RECYCLEBIN shows you all the objects that have been dropped by all
O
You can also use the SQL*Plus SHOW RECYCLEBIN command. This command shows you
only those objects that can be “undropped.”
l &
n a
The examples show how to extract important information from the Recycle Bin:
• ORIGINAL_NAME is the name of the object before it is dropped.
te r
• OBJECT_NAME is the system-generated name of the object after it is dropped.
• TYPE is the object’s type.
I n
• TS_NAME is the name of the tablespace to which the object belongs.
• DROPTIME is the date at which the object was dropped.
l e
• RELATED is the object identifier of the dropped object.
c
• SPACE is the number of blocks currently used by the object.
r a
You can also see the contents of the Recycle Bin by using Enterprise Manager.
O
Note: For detailed information about the DBA_RECYCLEBIN view, refer to the Oracle
Database Reference manual.

Querying Data in Dropped Tables
USER_TABLES
DROPPED TABLE_NAME
NO SALES
Recycle
YES BIN$zbjrBdpw==$0 EMPLOYEES bin
YES BIN$zbjra9wy==$0 EMPLOYEES_PK
NO SALES_PK
DROPPED INDEX_NAME
USER_INDEXES
SELECT ...
FROM "BIN$zbjrBdpw==$0"
y
WHERE ...
n l
e O
Querying Data in Dropped Tables
U s
When you drop a table, the table is moved to the Recycle Bin, and its original name is changed
A I
to a unique, system-generated name. Because you still own the dropped table, you can see its
characteristics from various dictionary views such as DBA_TABLES, DBA_OBJECTS, and
O
DBA_SEGMENTS. To make a distinction between tables that are in the Recycle Bin and tables
tables that are still in the Recycle Bin.

l &
that are not, the DBA_TABLES view has a column named DROPPED that is set to YES for
a
As long as a system-generated table name is in the Recycle Bin, you can use it in a SELECT
n
te r
statement and also in flashback queries. However, you cannot issue any sort of DML or DDL
statements on objects that reside in the Recycle Bin.
I n
c l e
r a
O
Using Flashback Technology to Query Data
• Flashback Query
– Query all data at a specified point in time.
• Flashback Versions Query
– See all versions of a row between two times.
– See the transactions that changed the row.
• Flashback Transaction Query
– See all changes made Time
by a transaction.
Tx3
Tx2
Flashback
Tx1
n l y
e O
Using Flashback Technology to Query Data
U s
Flashback technology provides the capability to query past versions of schema objects, query
A I
historical data, and perform change analysis. Every transaction logically generates a new
version of the database. With Flashback technology, you can navigate through these versions
to find an error and its cause:
O
l &
• Flashback Query: Query all data as it existed at a specific point in time.
• Flashback Versions Query: See all versions of rows between two times and the
transactions that changed the row.
n a
r
• Flashback Transaction Query: See all changes made by a transaction.
te
I n
c l e
r a
O
Configuring Undo for Flashback
SYSTEM tablespace UNDOTBS1 tablespace
UNDO_RETENTION initialization parameter
n l y
e O
Configuring Undo for Flashback
U s
Flashback Query, Flashback Versions Query, and Flashback Transaction Query use data from
the undo tablespace.
A I
Use the UNDO_RETENTION initialization parameter to specify, in seconds, the amount of
committed undo information to be retained in the database. O
&
Note: If an active transaction needs undo space and the undo tablespace does not have any free
l
n a
space, then the system starts reusing undo space that would have been retained unless you had
specified RETENTION GUARANTEE for the tablespace.
te r
I n
c l e
r a
O
Flashback Query: Overview
Use to query all data at a specified point in time.
Employees Unwanted Employees

updates
t1 t2
SELECT employee_id, salary FROM employees

AS OF TIMESTAMP <t1>
WHERE employee_id = 200
n l y
e O
Flashback Query: Overview
U s
With the Flashback Query feature, you can perform queries as of a certain time. By using the
data. This is useful for analyzing a data discrepancy. A I

AS OF clause of the SELECT statement, you can specify the time stamp for which to view the
O
Note: TIMESTAMP and SCN are valid options for the AS OF clause.
l &
n a
te r
I n
c l e
r a
O
Flashback Query: Example
Employees Employees Employees
salary = 4,400 salary = 4,840 salary = 4,400
11:00 11:10
UPDATE employees
SET salary =
(SELECT salary FROM employees
AS OF TIMESTAMP TO_TIMESTAMP
('2005-05-04 11:00:00', 'yyyy-mm-dd hh24:mi:ss')
WHERE employee_id = 200)
WHERE employee_id = 200
n l y
e O
Flashback Query: Example
U s
If a raise has been erroneously given to a particular employee recently, you can update the
I
salary again, assigning the salary provided by a subquery that returns the flashed back value.
A
O
l &
n a
te r
I n
c l e
r a
O
Flashback Versions Query: Overview
Tx0 Tx1 Tx2
Employees Employees Employees
200
t1 t2
SELECT versions_xid, salary FROM employees
VERSIONS BETWEEN TIMESTAMP <t1> and <t2>
WHERE employee_id = 200;
Tx0 Tx1 Tx2
n l y
e O
Flashback Versions Query: Overview
U s
With the Flashback Query feature, you can perform queries on the database as of a certain
A I
time span or range of user-specified system change numbers (SCNs). The Flashback Versions
Query feature enables you to use the VERSIONS clause to retrieve all the versions of the rows
that exist between two points in time or two SCNs.
O
l &
The rows returned by Flashback Versions Query represent a history of changes for the rows
across transactions. Flashback Versions Query retrieves only committed occurrences of the
n a
rows. Uncommitted row versions within a transaction are not shown. The rows returned also
te r
include deleted and subsequently reinserted versions of the rows.
You can use Flashback Versions Query to retrieve row history. It provides you with a way to
I n
audit the rows of a table and retrieve information about the transactions that affected the rows.
You can then use the returned transaction identifier to perform transaction mining by using
l e
LogMiner or to perform a Flashback Transaction Query, as described later in this lesson.
c
r a
Note: VERSIONS_XID is a pseudocolumn that returns the transaction identifier of the
corresponding version of a row.
O
Using Enterprise Manager to Perform
Flashback Versions Query
n l y
e O
Flashback Versions Query Through Enterprise Manager
Flashback Versions Query can also be performed by using Enterprise Manager.
U s
On the Maintenance page, select Perform Recovery.
A I
O
On the Perform Recovery page, select Tables for the Object Type and select Flashback
Existing Tables for the Operation Type. Click Perform Object Level Recovery. On the
&
“Perform Object Level Recovery: Point-in-Time” page, select “Evaluate row changes and
l
a
transactions to decide on a point in time,” and specify the name of the target table.
n
te r
Select the columns that you want to view in the Available Columns box, and then enter a
search clause in the Bind The Row Value box. Select “Show all row history,” and then click
Next.
I n
c l e
r a
O
Flashback Versions Query: Considerations
• The VERSIONS clause cannot be used to query:

– External tables
– Temporary tables
– Fixed tables
– Views
• The VERSIONS clause cannot span DDL commands.
• Segment shrink operations are filtered out.
n l y
e O
Flashback Versions Query: Considerations
The VERSIONS clause cannot be used to query the following types of tables:
U s
• External tables
• Temporary tables A I
• Fixed tables
O
VERSIONS clause.
l &
You cannot use the VERSIONS clause to query a view. However, a view definition can use the
n a
The VERSIONS clause in a SELECT statement cannot produce versions of rows across the
te r
DDL statements that change the structure of the corresponding tables. This means that the
query stops producing rows after it reaches a time in the past when the table structure was
changed.
I n
c l e
Certain maintenance operations, such as a segment shrink, may move table rows across blocks.
In this case, the version query filters out such phantom versions because the row data remains
a
the same.
r
O
Flashback Transaction Query: Overview
FLASHBACK_TRANSACTION_QUERY
DBA
Erroneous
DML Undo
SQL
User
n l y
e O
Flashback Transaction Query: Overview
U s
Flashback Transaction Query is a diagnostic tool that you can use to view changes made to the
perform analysis and audits of transactions. A I

database at the transaction level. This enables you to diagnose problems in your database and
O
You can use the FLASHBACK_TRANSACTION_QUERY view to determine all the necessary
during a specific period of time.

l &
SQL statements that can be used to undo the changes made either by a specific transaction or
n a
te r
I n
c l e
r a
O
Flashback Transaction Query
n l y
e O
Using Enterprise Manager to Perform Flashback Transaction Query
U s
This feature is used in conjunction with the Flashback Versions Query feature with the help of
A I
the Perform Recovery Wizard. On the “Perform Object Level Recovery: Choose SCN” page,
click the corresponding Transaction ID link in the Flashback Versions Query Result region.
O
In the example in the slide, a Flashback Versions Query is performed on the JOBS table to
l &
retrieve the three versions of the JOBS row for JOB_ID = 'AD_PRES'. Then, one of the
transaction IDs is clicked, showing all the changes that were part of that transaction. Notice
a
that in addition to the JOBS table update, there was also an update to the EMPLOYEES table in
n
that transaction.
te r
I n
c l e
r a
O
Flashback Transaction Query: Considerations
• DDL commands are seen as dictionary updates.

• Dropped objects appear as object numbers.
• Dropped users appear as user identifiers.
n l y
e O
Flashback Transaction Query: Considerations
U s
Within the database, DDL operations are nothing but a series of space management operations
DDL command displays the changes made to the data dictionary. A I

and changes to the data dictionary. Flashback Transaction Query on a transaction underlying a
O
When Flashback Transaction Query involves tables that have been dropped from the database,
&
the table names are not reflected. Instead, object numbers are used.
l
n a
If the user who executed a transaction is dropped, Flashback Transaction Query of that
transaction displays the corresponding user ID only, and not the username.
te r
Note: When there is not enough undo data for a specific transaction, a row with a value of
UNKNOWN in the OPERATION column of FLASHBACK_TRANSACTION_QUERY is returned.
I n
c l e
r a
O
Flashback Table: Overview
• Flashback Table recovers tables to a specific point in

time.
• Flashback Table is an in-place operation.
• The database stays online.
Erroneous Flashed back

DMLs User tables
n l y
e O
Flashback Table: Overview
U s
Using Flashback Table, you can recover a set of tables to a specific point in time without
having to perform traditional point-in-time recovery operations.
A I
A Flashback Table operation is done in-place, while the database is online, by rolling back
O
only the changes that are made to the given tables and their dependent objects.
&
A Flashback Table statement is executed as a single transaction. All tables must be flashed
l
a
back successfully, or the entire transaction is rolled back.
n
te r
Note: You can use Flashback Versions Query and Flashback Transaction Query to determine
the appropriate flashback time.
I n
c l e
r a
O
Flashback Table
• Using Flashback Table, you can recover a table or

tables to a specific point in time without restoring a
backup.
• Data is retrieved from the undo tablespace to perform a
Flashback Table operation.
• The FLASHBACK TABLE privilege is required to flash
back a table.
• Row movement must be enabled on the table that you
are performing the flashback operation on.
n l y
e O
Flashback Table
U s
With Flashback Table, you can recover a table or tables to a specific point in time without
A I
restoring a backup. When you use this feature, the data in tables and their associated objects
(indexes, constraints, triggers, and so on) is restored. The data used to satisfy a Flashback
Table request is retrieved from the undo tablespace.
O
appropriate flashback time.
l &
You can use Flashback Versions Query and Flashback Transaction Query to determine the
n a
Flashback Table provides a way for users to easily and quickly recover from accidental
te r
modifications without a database administrator’s involvement. You must grant the
FLASHBACK TABLE or FLASHBACK ANY TABLE system privilege to any user that uses the
I n
Flashback Table feature. In addition, you must grant the SELECT, INSERT, DELETE, and
ALTER object privileges to the user.
c l e
You can use Enterprise Manager to flash back a table. The wizard guides you through the
process.
r a
Note: Enabling row movement is described on the next page.
O
Enabling Row Movement on a Table
ALTER TABLE employees ENABLE ROW MOVEMENT;
n l y
e O
Enabling Row Movement on a Table
U s
You must enable row movement on a table to be able to flash back the table. When you enable
Manager to enable row movement. A I

row movement, the Oracle server can move a row in the table. You can use Enterprise
O
Using Enterprise Manager, you can enable row movement on a table by performing the
following steps:
l &
1. Select Tables in the Schema region on the Administration property page. Enter the
n a
schema name to search for the table, and click Go.
te r
2. Click the table name of the table for which you want to enable row movement. You are
now on the View Table page.
I n
3. Click Edit, which takes you to the Edit Table page.
4. Click the Options tab, where you can change the Enable Row Movement setting for the
table.
c l e
5. Set Enable Row Movement to Yes, and click Apply. The update confirmation message is
r a
displayed.
O
Performing Flashback Table
FLASHBACK TABLE hr.employees TO TIMESTAMP

TO_TIMESTAMP('2005-05-05 05:32:00',
'YYYY-MM-DD HH24:MI:SS');
n l y
e O
Performing Flashback Table
U s
You can use Enterprise Manager to flash back a table by performing the following steps:
page. The Perform Recovery page appears. A I

1. Select Perform Recovery in the Backup/Recovery region on the Maintenance property
O
2. In the Object Level Recovery region, select Tables from the Object Type drop-down list.
l &
3. Select Flashback Existing Tables as the Operation Type. Click Perform Object Level
Recovery. The “Perform Object Level Recovery: Point-in-time” page is displayed.
a
4. Select “Flashback to a timestamp” or “Flashback to a known SCN” and then specify a
n
te r
time stamp or SCN to flash back to, and click Next.
5. Click Add Tables to add tables to the list for the flashback operation. Click Next.
I n
6. The Dependency Options page appears if there are dependent tables. Select the desired
option for dealing with dependent tables. Typically, you would select “Cascade” to ensure
l e
a consistent flashback. Click Next.
c
7. The “Perform Object Level Recovery: Review” page appears. Review the information
r a
and click Submit. The Confirmation page appears.
O
Note: You can also flash back tables from the Tables link in the Schema region of the
Administration page.

Flashback Table: Considerations
• The FLASHBACK TABLE command executes as a single

transaction, acquiring exclusive DML locks.
• Statistics are not flashed back.
• Current indexes and dependent objects are maintained.
• Flashback Table operations:
– Cannot be performed on system tables
– Cannot span DDL operations
– Generate undo and redo data
n l y
e O
Flashback Table: Considerations
U s
• The entire FLASHBACK TABLE statement is executed within a single transaction. All or
none of the specified tables are flashed back.
A I
• Flashback Table acquires exclusive data manipulation language (DML) locks on all the
O
tables that are specified in the statement over the period of time when the operation is in
progress.
l &
• Statistics of impacted objects are not flashed back.
a
• All existing indexes are maintained. Dropped indexes are not re-created. Dependent on-
n
te r
commit materialized views are also maintained automatically.
• Tables specified in the FLASHBACK TABLE statement are flashed back, provided that
I n
none of the table constraints are violated. If any constraints are violated during flashback
execution, the operation is aborted and the tables are left in the same state as they were
l e
just before the FLASHBACK TABLE statement invocation.
c
• You cannot perform Flashback Table to a particular time that is older than the time of the
r a
execution of a data definition language (DDL) operation that altered the structure of or
shrunk a table that would be involved in the flashback operation. This restriction does not
O apply to DDL statements that only change storage attributes of the tables.
• Flashback Table cannot be performed on system tables, remote tables, and fixed tables.

Flashback Database: Overview
The Flashback Database operation:

• Works like a rewind button for the database
• Can be used in cases of logical data corruptions made
by users
Users The Flashback Database: The

generate database is You “press the database is
errors. corrupted. rewind button.” “rewound.”
n l y
e O
Flashback Database: Review
U s
With Flashback Database, you can quickly bring your database to an earlier point in time by
A I
undoing all the changes that have taken place since that time. With this operation, you do not
need to restore backups. You can use this feature to undo changes that have resulted in logical
data corruption.
O
use traditional recovery methods.
l &
If you have experienced a loss of media or physical corruption in your database, then you must
n a
te r
I n
c l e
r a
O
Flashback Database Architecture
SGA
Redo log
Flashback buffer
buffer
Buffer cache
LGWR
Every
change
Log block
before
images
periodically.
Flashback Redo
RVWR logs
logs
Back out changes Do forward

1 to database using media recovery. 2
before images.
… …
n l y
e O
Flashback Database Architecture
U
When you enable Flashback Database, the RVWR background process is started. This
s
A I
background process sequentially writes Flashback Database data from the flashback buffer to
the Flashback Database logs, which are circularly reused. Subsequently, when a FLASHBACK
O
DATABASE command is issued, the flashback logs are used to restore to the blocks’ before
l &
images, and then redo data is used to roll forward to the desired flashback time.
The overhead of enabling Flashback Database depends on the read-write mix of the database
n a
workload. Because queries do not need to log any flashback data, the more write-intensive the
te r
workload, the higher the overhead of enabling Flashback Database.
Note: Flashback Database logs are not archived.
I n
c l e
r a
O
Configuring Flashback Database
1. Configure the Flash 2. Set the retention 3. Enable Flashback

Recovery Area. target. Database.
SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER SYSTEM SET
2 DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;
n l y
e O
Configuring Flashback Database
You can configure Flashback Database as follows:
U s
1. Configure the Flash Recovery Area.
A I
2. Set the retention target with the DB_FLASHBACK_RETENTION_TARGET initialization
O
parameter. You can specify an upper limit, in minutes, on how far back you want to be
l &
able to flash back the database. This parameter is only a target and does not provide any
guarantee. Your flashback time interval depends on how much flashback data has been
kept in the Flash Recovery Area.
n a
te r
3. Enable Flashback Database with the following command:
ALTER DATABASE FLASHBACK ON;
I n
Before you can issue the command to enable Flashback Database, the database must be
configured for archiving and started in MOUNT EXCLUSIVE mode.
l e
You can determine whether Flashback Database is enabled with the following query:
c SELECT flashback_on FROM v$database;
r a
You can disable Flashback Database with the ALTER DATABASE FLASHBACK OFF
O
command. As a result, all existing Flashback Database logs are deleted automatically.
Note: You can enable Flashback Database only when the database is mounted in exclusive
mode, not open.

Using Enterprise Manager to Configure
Flashback Database
Enable flashback logging and specify the Flash Recovery

Area.
n l y
e O
Using Enterprise Manager to Configure Flashback Database
U s
When you are certain that the database is in ARCHIVELOG mode, return to the Recovery
A I
Settings page and scroll down to the Media Recovery and Flash Recovery Area regions to
observe the new settings. When the Flash Recovery Area and archiving are configured,
O
USE_DB_RECOVERY_FILE_DEST is configured for archive log destination 10. Enable
l &
flashback logging by selecting Enable Flashback Logging. You also have the ability to set the
flashback retention time, and you can view important information regarding your flashback
database window.
n a
te r
Review the Flash Recovery Area location. The Flash Recovery Area is a unified storage
location for all recovery-related files and activities in an Oracle database. All files that are
I n
needed to completely recover a database from a media failure are part of the Flash Recovery
Area. The recovery-related files that can be created in the Flash Recovery Area include:
l e
archived redo log files, control files, backups created by Recovery Manager (RMAN),
c
flashback logs, and the change tracking file. By allocating a storage location and unifying
r a
recovery-related files within a specific area, the Oracle database server relieves the database
O
administrator of having to manage the disk files created by these components. The default
location for the Flash Recovery Area is $ORACLE_BASE. If you want it in a different
location, change it now. Scroll down to the bottom of the Recovery Settings page and click
Apply.
Flashback Database: Examples
RMAN> FLASHBACK DATABASE TO TIME =

2> "TO_DATE('2004-05-27 16:00:00',
3> 'YYYY-MM-DD HH24:MI:SS')";
RMAN> FLASHBACK DATABASE TO SCN=23565;
RMAN> FLASHBACK DATABASE

2> TO SEQUENCE=223 THREAD=1;
SQL> FLASHBACK DATABASE

2 TO TIMESTAMP(SYSDATE-1/24);
SQL> FLASHBACK DATABASE TO SCN 53943;
SQL> FLASHBACK DATABASE TO RESTORE POINT b4_load;
n l y
e O
Flashback Database: Examples
You can use the RMAN FLASHBACK DATABASE command to execute the Flashback
U s
A I
Database operation. You can use SEQUENCE and THREAD to specify a redo log sequence
number and thread as a lower limit. RMAN selects only files that can be used to flash back to,
but not including, the specified sequence number.
O
l &
Alternatively, you can use the FLASHBACK DATABASE SQL command to return the database
to a past time or SCN. If you use the TO SCN clause, you must provide a number. If you
a
specify TO TIMESTAMP, you must provide a time-stamp value. You can also specify a restore
n
point name.
te r
Note: The database must be mounted in EXCLUSIVE mode to issue the FLASHBACK
I n
DATABASE command and must be opened with the RESETLOGS option when finished.
c l e
r a
O
Flashback Database
Select the object and

operation type.
n l y
e O
Using Enterprise Manager to Perform Flashback Database
U s
On the Maintenance page, select Perform Recovery. From the Object Type drop-down list,
A I
select Whole Database. Next, select “Recover to the current time or a previous point-in-time”
as Operation Type. Finally, provide the operating system credentials for a database user (that
O
is, one who belongs to the DBA group). When these steps are completed, click Continue to
&
proceed to the next step in the Flashback Database operation.
l
n a
te r
I n
c l e
r a
O
Flashback Database
Starting the Recovery Wizard:
n l y
e O
Using Enterprise Manager to Perform Flashback Database (continued)
U s
After the recovery operation type has been chosen, the Recovery Wizard is started. You are
A I
informed that the database will be shut down and restarted in MOUNT mode. This operation
takes several minutes and you will be informed of the delay. After waiting an appropriate
O
amount of time, you must click Refresh to continue with the operation.
l &
n a
te r
I n
c l e
r a
O
Flashback Database
n l y
e O
Using Enterprise Manager to Perform Flashback Database (continued)
U s
The Recovery Wizard is now started. At this stage, the database is shut down and started in
MOUNT mode. Click Refresh.
A I
This displays the Perform Recovery: Point-in-time page. On this page, select the “Recover to a
O
prior point-in-time” option, and then specify either a date or an SCN. Then, click Next.
&
The Perform Recovery: Flashback page appears next, and you can choose to perform either
l
Next.
n a
recovery using flashback or regular recovery. Select the corresponding option, and then click
te r
This brings you directly to the Perform Recovery: Review page that is shown in the slide.
Click Submit to flash back the database.
I n
c l e
r a
O
Flashback Database Considerations
• When the Flashback Database operation completes,

open the database:
– In read-only mode to verify that the correct target time or
SCN was used
– With a RESETLOGS operation to allow for DML
• You cannot use Flashback Database in the following
situations:
– The control file has been restored or re-created.
– A tablespace has been dropped.
– A datafile has been shrunk.
• Use the TO BEFORE RESETLOGS to flash back to before
the last RESETLOGS operation.
n l y
e O
Flashback Database Considerations
U s
After the Flashback Database operation is complete, you can open the database in read-only
A I
mode to verify that the correct target time or SCN was used. If not, you can flash back the
database again, or perform a recovery to roll forward the database. To undo a Flashback
Database operation, you should recover the database forward.
O
l &
You cannot use Flashback Database to recover a data file that was dropped during the span of
time you are flashing back. The dropped data file is added to the control file and marked
n a
offline, but it is not flashed back. Flashback Database cannot flash back a data file to a time
te r
after its creation and before the resize operation. If a file was resized during the span of time to
which you are going to flash back the database, then you should take the file offline before
I n
beginning the Flashback Database operation. This is applicable for files that are shrunk rather
than expanded. You can use Flashback Database with datafiles that you have configured for
l e
automatic extension.
c
You can flash back to just before the last RESETLOGS operation by supplying the TO
r a
BEFORE RESETLOGS clause in the FLASHBACK DATABASE command.
O
Note: The flashback retention target is not an absolute guarantee that flashback will be
available. If space is needed for required files in the Flash Recovery Area, flashback logs may
be deleted automatically.

Monitoring Flashback Database
To monitor the ability to meet your retention target:

• View the Flash Recovery Area disk quota:
SQL> SELECT estimated_flashback_size,
2 flashback_size
3 FROM v$flashback_database_log;
• Determine the current flashback window:

SQL> SELECT oldest_flashback_scn,
2 oldest_flashback_time
3 FROM v$flashback_database_log;
• Monitor logging in the Flashback Database logs:

SQL> SELECT *
2 FROM v$flashback_database_stat;
n l y
e O
U s
It is important for you to monitor space usage of the Flash Recovery Area so that you know
view to monitor the Flashback Database retention target: A I

how well you are meeting your retention target. Use the V$FLASHBACK_DATABASE_LOG
O
• ESTIMATED_FLASHBACK_SIZE uses previously logged flashback data to provide an
l &
estimate of how much disk space is needed in the Flash Recovery Area for flashback logs
to meet the current flashback retention target. The estimate is based on the workload since
a
the instance was started, or during the most recent time interval equal to the flashback
n
te r
retention target, whichever is shorter.
• FLASHBACK_SIZE gives you the current size in bytes of the flashback data.
I n
• OLDEST_FLASHBACK_SCN and OLDEST_FLASHBACK_TIME display the
approximate lowest SCN and time to which you can flash back your database.
l e
CURRENT_SCN in V$DATABASE gives you the current database SCN.
c
Use the V$FLASHBACK_DATABASE_STAT view to monitor the overhead of logging
r a
flashback data in the Flashback Database logs. This view contains 24 hours of information,
O
with each row representing a one-hour time interval. You can use this view to determine rate
changes in the flashback data generation.

Monitoring Flashback Database (continued)
SQL> SELECT begin_time, end_time, flashback_data, db_data,
2 redo_data, estimated_flashback_size AS EST_FB_SZE
3 FROM v$flashback_database_stat;
BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA EST_FB_SZE

--------- --------- -------------- ---------- ---------- ----------
12-FEB-04 12-FEB-04 16384 0 24576 0
12-FEB-04 12-FEB-04 6594560 7471104 1533440 815923200
12-FEB-04 12-FEB-04 17235968 12361728 5150720 839467008
12-FEB-04 12-FEB-04 311648256 37249024 10272768 855195648
On the basis of this information, you may need to adjust the retention time or the Flash
Recovery Area size.
FLASHBACK_DATA and REDO_DATA represent the number of bytes of flashback data and
redo data written, respectively, during the time interval, and DB_DATA gives the number of
bytes of data blocks read and written. This view also contains the estimated flashback space
needed for the interval.
You can query V$RECOVERY_FILE_DEST to view information regarding the Flash
Recovery Area. The column descriptions are:
• NAME: Flash recovery area name, indicating location string
• SPACE_LIMIT: Disk limit specified in the DB_RECOVERY_FILE_DEST_SIZE
parameter
• SPACE_USED: Space used by Flash Recovery Area files (in bytes)
n l y
e O
• SPACE_RECLAIMABLE: Amount of space that can be reclaimed by deleting obsolete,
redundant, and other low-priority files through the space management algorithm
• NUMBER_OF_FILES: Number of files
U s
SQL> SELECT name, space_limit AS quota,
2 space_used AS used,
A I
3
4
space_reclaimable AS reclaimable,
number_of_files AS files O
5 FROM v$recovery_file_dest ;
l &
NAME
n
QUOTA a USED RECLAIMABLE FILES
te r
------------------------ ---------- ----------
/u01/flash_recovery_area 5368709120 2509807104
-----------
203386880
-----
226
I n
c l e
r a
O
n l y
e O
Monitoring Flashback Database (continued)
U s
Most of the Flashback Database statistics mentioned on the preceding pages can be viewed
A I
from the Recovery Settings page. These metrics include the current space used by all
flashback logs, the lowest SCN, and the time of the lowest SCN in the flashback data.
O
l &
n a
te r
I n
c l e
r a
O
Tuning Considerations for Flashback Database
• Performance overhead is approximately 2%.

– Sequential and often, bulk writes are used for writing
flashback data.
– In well-configured systems, no process needs to wait for
writing of flashback logs.
• Best practices:
– Use a fast file system for the Flash Recovery Area,
preferably without operating system file caching.
– Configure enough disk spindles for the file system that
holds the Flash Recovery Area.
– Configure the file system on top of striped storage
volumes, with a relatively small stripe size such as 128
KB.
– For large, production databases, set the LOG_BUFFER
initialization parameter to at least 8 MB.
n l y
e O
Tuning Considerations for Flashback Database
U s
Maintaining flashback logs imposes comparatively limited overhead on an Oracle database
infrequent, regular intervals, to limit processing and I/O overhead. A I

instance. Changed blocks are written from memory to the flashback logs at relatively
O
To achieve good performance for large production databases with Flashback Database
enabled, Oracle recommends the following:
l &
• Use a fast file system for your Flash Recovery Area, preferably without operating system
n a
file caching. Files created in the Flash Recovery Area, including flashback logs, are
te r
typically large. Operating system file caching is typically not effective for these files, and
may actually add CPU overhead for reading from and writing to these files. The
ASM. I n
recommendation is to use a file system that avoids operating system file caching, such as
l e
• Configure enough disk spindles for the file system that will hold the Flash Recovery Area.
c
For large production databases, multiple disk spindles may be needed to support the
r a
required disk throughput for the Oracle Database server to write the flashback logs
O effectively.

Tuning Considerations for Flashback Database (continued)
• If the storage system used to hold the Flash Recovery Area does not have non-volatile
RAM, try to configure the file system on top of striped storage volumes, with a relatively
small stripe size such as 128 KB. This will allow each write to the flashback logs to be
spread across multiple spindles, improving performance.
• For large, production databases, set the LOG_BUFFER initialization parameter to at least
8 MB. This ensures that the Oracle Database server allocates maximum memory
(typically16 MB) for writing flashback database logs.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Using Guaranteed Restore Points
A guaranteed restore point ensures that you can perform a

FLASHBACK DATABASE command to that SCN at any time.
SQL> CREATE RESTORE POINT before_load

2 GUARANTEE FLASHBACK DATABASE;
n l y
e O
Guaranteed Restore Points
U s
Like normal restore points, guaranteed restore points can be used as aliases for SCNs in
Flashback Database feature. A I

recovery operations. However, they also provide specific functionality related to the use of the
O
Creating a guaranteed restore point at a particular SCN enforces the requirement that you can
l &
perform a Flashback Database operation to return your database to its state at that SCN, even if
flashback logging is not enabled for your database. If flashback logging is enabled, creating a
n a
guaranteed restore point enforces the retention of flashback logs required for Flashback
te r
Database back to any point in time after the creation of the earliest guaranteed restore point.
A guaranteed restore point can be used to revert a whole database to a known good state days
I n
or weeks ago, as long as there is enough disk space in Flash Recovery Area to store the needed
logs.
c l e
Note: As with normal restore points, guaranteed restore points can be used to specify a point
a
in time for RECOVER DATABASE operations.
r
O
Summary

• Use Flashback Drop to recover a dropped table
• Use Flashback Query to view the contents of the
database as of any single point in time
• Use Flashback Versions Query to view versions of a
row over time
• Use Flashback Transaction Query to view transaction
history or a row
• Use Flashback Table to restore the contents of a table
to a specific point in the past
• Configure Flashback Database
• Perform Flashback Database to a point in time
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Practice Overview

• Enabling Flashback Database
• Setting Restore Points
• Performing Flashback Table
• Using Flashback Query and Flashback Versions Query
• Performing Flashback Database to undo unwanted
transactions
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Using RMAN to Create a Duplicate Database
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
ra
O
Objectives

• Describe the ways a duplicate database can be used
• Configure auxiliary database file names
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Use the RMAN DUPLICATE command to create a duplicate

database using target database backups.
Datafile backups
Archived
redo log files
Auxiliary instance
Target database
n l y
e O
U s
A duplicate database is a copy of the target database (or a subset of the target database) with a
A I
new, unique database identifier (DBID). The target database site and duplicate database site can
be on the same or separate hosts. The duplicate database is created using backups and archived
redo log files from the target database.
O
l &
n a
te r
I n
c l e
r a
O
Using a Duplicate Database
You can use a duplicate database to:

• Test backup and recovery procedures
• Recover objects by creating an export and importing
the objects into the production database
n l y
e O
Using a Duplicate Database
U s
A duplicate database is a copy of your target database. You can operate it independently of the
target database to:
• Test backup and recovery procedures A I
O
• Recover objects that were inadvertently dropped from the target database by creating an
production database.
l &
export containing the objects in the duplicate database and importing them into the
n a
te r
I n
c l e
r a
O
Creating a Duplicate Database
1. Create an Oracle password file for the auxiliary

instance.
2. Establish Oracle Net connectivity to the auxiliary
instance.
3. Create an initialization parameter file for the auxiliary
instance.
4. Start the auxiliary instance in NOMOUNT mode.
5. Mount or open the target database.
6. Ensure that backups and archived redo log files are
available.
7. Allocate auxiliary channels if needed.
8. Execute the DUPLICATE command.
n l y
e O
Creating a Duplicate Database
U s
The basic steps to creating a duplicate database are outlined in the slide. More detail is provided
in the lesson for some of the steps.
A I
O
l &
n a
te r
I n
c l e
r a
O
Creating an Initialization Parameter File for the
Auxiliary Instance
Specify parameters as follows:

• DB_NAME
– If the duplicate database is in the same Oracle Home as
the target database, names must be different.
– Use the same value in the DUPLICATE command.
• DB_BLOCK_SIZE
– Specify the same value as set for the target database.
n l y
e O
Creating an Initialization Parameter File for the Auxiliary Instance
U s
You must create a text initialization parameter file for the auxiliary instance. The text
execute the DUPLICATE command. A I

initialization parameter file must reside on the same host as the RMAN client that you use to
O
Take note of the requirements for each of the following parameters:
l &
• DB_NAME: If the target database and the duplicate database are in the same Oracle Home,
you must set DB_NAME to a different name. If they are in different Oracle Homes, you must
n a
ensure that the duplicate database name differs from the other names in its Oracle Home. Be
DUPLICATE command.
te r
sure to use the same database name that you set for this parameter when you execute the
I n
• DB_BLOCK_SIZE: The block size of the auxiliary database must match the block size of
the target database. Specify the same value in the initialization parameter file for the
l e
auxiliary database as set in the initialization parameter file for the target database. If the
c
parameter is not set in the initialization parameter file for the target database, do not set it in
r a
the auxiliary instance initialization parameter file.
O
In addition, be sure to verify the settings of all initialization parameters that specify path names.
Verify that all specified paths are accessible on the duplicate database host.

Specifying Parameters to Control File Naming
Specify the following parameters to control the naming of

the files of your auxiliary database:
• CONTROL_FILES
• DB_FILE_NAME_CONVERT
• LOG_FILE_NAME_CONVERT
CONTROL_FILES='/u01/app/oracle/oradata/aux/control01.ctl',
'/u01/app/oracle/oradata/aux/control02.ctl',
'/u01/app/oracle/oradata/aux/control03.ctl'
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
'/u01/app/oracle/oradata/aux'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
'/u01/app/oracle/oradata/aux'
n l y
e O
Specifying Parameters to Control File Naming
U s
RMAN generates names for the required database files when you execute the DUPLICATE
parameters in the auxiliary instance initialization parameter file: A I

command. You can control the naming of the files by specifying the following initialization
O
• CONTROL_FILES: Specify the names of the control files in this parameter. If you do not
l &
set the names via this parameter, the Oracle server creates an Oracle-managed control file in
a default control destination. Refer to the SQL CREATE CONTROLFILE command in the
a
SQL Reference manual for specific information.
n
te r
• DB_FILE_NAME_CONVERT: This parameter is used to specify the names of datafiles for
the auxiliary database. It has the format DB_FILE_NAME_CONVERT = 'string1' ,
I n
'string2' where string1 is the pattern of the target database file name and string2
is the pattern of the auxiliary database file name. You can also specify the
l e
DB_FILE_NAME_CONVERT parameter as an option to the DUPLICATE DATABASE
command.
c
r a
• LOG_FILE_NAME_CONVERT: This parameter is used to specify the names of the redo log
files for the auxiliary database. It has the format LOG_FILE_NAME_CONVERT =
O'string1' , 'string2' where string1 is the pattern of the target database file name
and string2 is the pattern of the auxiliary database file name. You can also use the
LOGFILE clause of the DUPLICATE DATABASE command to specify redo log file names.

Specifying Parameters to Control File Naming (continued)
As an alternative to using the initialization parameters to control the naming of the files, you can
use the following techniques to rename the redo log files:
• Use the LOGFILE clause of the DUPLICATE command.
• Set the Oracle Managed Files initialization parameters: DB_CREATE_FILE_DEST,
DB_CREATE_ONLINE_DEST_n, or DB_RECOVERY_FILE_DEST.
You can use the following techniques to specify new names for datafiles:
• Include the SET NEWNAME FOR DATAFILE command within a RUN block to specify new
names for the datafiles.
• Use the CONFIGURE AUXNAME command.
• Specify the DB_FILE_NAME_CONVERT parameter with the DUPLICATE command.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Starting the Instance in NOMOUNT Mode
• Create a server parameter file (SPFILE) from the text

initialization parameter file you used to start the
instance.
• Start the auxiliary instance in NOMOUNT mode.
SQL> create spfile
2 from pfile='$HOME/auxinstance/initAUX.ora';
File created.
SQL> startup nomount pfile='$HOME/auxinstance/initAUX.ora'
ORACLE instance started.
Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes
Variable Size 92276304 bytes
Database Buffers 188743680 bytes
Redo Buffers 2973696 bytes
n l y
e O
Starting the Instance in NOMOUNT Mode
U s
After you have created the text initialization parameter file, invoke SQL*Plus to start the
auxiliary instance in NOMOUNT mode.
A I
After you invoke SQL*Plus, create a server parameter file (SPFILE) from your text initialization
O
parameter file. You can execute the CREATE SPFILE before or after you have started the
l &
instance. You should create the SPFILE in the default location so that you do not need to specify
the PFILE option with the DUPLICATE command. RMAN shuts down the auxiliary instance
n a
and restarts it as part of the duplication process, so you must specify the PFILE option if you do
not use an SPFILE.
te r
I n
c l e
r a
O
Ensuring That Backups and Archived Redo Log
Files Are Available
• Backups of all target database datafiles must be

accessible on the duplicate host.
• Backups can be a combination of full and incremental
backups.
• Archived redo log files needed to recover the duplicate
database must be accessible on the duplicate host.
• Archived redo log files can be:
– Backups on a media manager
– Image copies
– Actual archived redo log files
n l y
e O
Ensuring That Backups and Archived Redo Log Files Are Available
U s
The backups needed to restore the datafiles must be accessible on the duplicate host. You do not
individual datafiles during the duplication process. A I

need a whole database backup. RMAN can use a combination of full and incremental backups of
O
Archived redo logs required to recover the duplicate database to the desired point in time must
l &
also be accessible. The archived redo log files can be backups, image copies, or the actual
archived redo logs. The backups or copies can be transferred to the local disk of the duplicate
n a
database node or mounted across a network by some means such as NFS.
te r
I n
c l e
r a
O
Allocating Auxiliary Channels
• Auxiliary channels specify a connection between

RMAN and an auxiliary database instance.
• If automatic channels are not configured, allocate
auxiliary channels:
– Start RMAN with a connection to the target database, the
auxiliary instance, and recovery catalog if applicable.
– Allocate at least one auxiliary channel within the RUN
block.
$ rman target sys/oracle@trgt auxiliary sys/oracle@aux
RMAN> RUN
{ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
…
n l y
e O
Allocating Auxiliary Channels
U s
If you do not have automatic channels configured, manually allocate at least one auxiliary
A I
channel before issuing the DUPLICATE command. The ALLOCATE AUXILIARY CHANNEL
command must be within the same RUN block as the DUPLICATE command. The channel type
O
specified on the ALLOCATE AUXILIARY CHANNEL command must match the media where
l &
the backups of the target database are located. If the backups reside on disk, you can allocate
more than one channel to reduce the time it takes for the duplication process. For tape backups,
a
you can specify the number of channels that correspond to the number of devices available.
n
te r
I n
c l e
r a
O
Using the RMAN DUPLICATE Command
• Connect to the target database and the auxiliary

instance.
• Specify the same database name that you used in the
DB_NAME initialization parameter.
RMAN> RUN
{ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
…
DUPLICATE TARGET DATABASE to auxdb;
}
n l y
e O
Using the RMAN DUPLICATE command
U s
Invoke RMAN and connect to the target database and auxiliary instance before issuing the
the target database must be mounted or open. A I

DUPLICATE command. The auxiliary instance must be started with the NOMOUNT option and
O
l &
n a
te r
I n
c l e
r a
O
Understanding the RMAN Duplication Operation
When you execute the DUPLICATE command, RMAN

performs the following operations:
• Creates a control file for the duplicate database
• Restores the target datafiles to the duplicate database
• Performs incomplete recovery using all available
incremental backups and archived redo log files
• Shuts down and restarts the auxiliary instance
• Opens the duplicate database with the RESETLOGS
option
• Creates the online redo log files
• Generates a new, unique database identifier (DBID) for
the duplicate database
n l y
e O
Understanding the RMAN Duplication Operation
When you execute the DUPLICATE command, RMAN performs the following operations:
U s
• Creates a control file for the duplicate database
• Restores the target datafiles to the duplicate database A I
O
• Performs incomplete recovery using all available incremental backups and archived redo
log files
l &
• Shuts down and restarts the auxiliary instance
a
• Opens the duplicate database with the RESETLOGS option
n
te r
• Creates the online redo log files
• Generates a new, unique DBID for the duplicate database
I n
c l e
r a
O
Specifying Options for the DUPLICATE Command
You can specify the following options with the DUPLICATE

command:
Option Purpose
SKIP READONLY Exclude read-only tablespaces
SKIP TABLESPACE Exclude named tablespaces
NOFILENAMECHECK Prevent checking of file names
OPEN RESTRICTED Enable RESTRICTED SESSION automatically
n l y
e O
Specifying Options for the DUPLICATE Command
Specify additional options when executing the DUPLICATE command as appropriate.
U s
SKIP READONLY: Use to exclude read-only tablespace datafiles.
A I
O
SKIP TABLESPACE: Use to exclude tablespaces from the target database. You cannot exclude
the SYSTEM tablespace or tablespaces containing undo or rollback segments.
l &
NOFILENAMECHECK: Use to prevent RMAN from checking whether target database datafiles
a
with the same name as duplicate database datafiles are in use. You must specify this option
n
te r
when the target database and duplicate database datafiles and redo log files use the same names.
You would typically use this when you create a duplicate database on a host that has the same
disk configuration, directory structure, and file names as the target database host. If you do not
I n
specify NOFILENAMECHECK in this situation, RMAN returns an error.
l e
OPEN RESTRICTED: Use to enable RESTRICTED SESSION automatically after the database
is opened.
c
r a
O
Using Enterprise Manager to Create a Duplicate
Database
n l y
e O
Using Enterprise Manager to Create a Duplicate Database
U s
You can also use Enterprise Manager to create a duplicate (clone) database. Select Clone
A I
Database in the “Move Database Files” section of the Maintenance page. The Clone Database
Wizard steps you through the process of creating a duplicate database.
O
On the Source Type page, designate the source for the cloning operation. You can select a
&
current database instance or a saved working directory from a previous clone operation.
l
n a
te r
I n
c l e
r a
O
Using Enterprise Manager: Source Working
Directory
n l y
e O
Using Enterprise Manager: Source Working Directory
U s
On the Source Working Directory page, specify the directory on the source host in which the
backup files are to be stored during the clone operation.
A I
You can choose to delete or retain the backup set after the cloning procedure. The Clone
O
Database wizard automatically calculates the amount of temporary disk space required for
&
creating the new backup set and for retaining the backup set for future use.
l
a
On this page, you must also enter the operating host credentials.
n
te r
I n
c l e
r a
O
Using Enterprise Manager: Select Destination
n l y
e O
Using Enterprise Manager: Select Destination
U s
On the Select Destination page, specify the Global Database Name and Instance Name for the
Oracle Home. A I
duplicate database. Provide the host credentials for the destination and select the destination
O
l &
n a
te r
I n
c l e
r a
O
Using Enterprise Manager: Destination Options
n l y
e O
Using Enterprise Manager: Destination Options
U s
On the Destination Options page, specify the location for the database files. Confirm the location
A I
for the Oracle Net configuration files. Specify login information for Enterprise Manager.
After completing this page and clicking Next, the Schedule page is displayed. Confirm the
schedule information and click Next. O
l &
n a
te r
I n
c l e
r a
O
Using Enterprise Manager: Review Page
n l y
e O
Using Enterprise Manager: Review Page
U s
A complete description of the duplicate database is displayed on the Review page. Confirm that
I
all information is correct. Click Submit Job to create the duplicate database.
A
O
l &
n a
te r
I n
c l e
r a
O
Summary

• Describe the ways a duplicate database can be used
• Configure auxiliary database file names
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview

• Configuring an auxiliary instance
• Creating a duplicate database using the DUPLICATE
command
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
n l y
e O
U s
A I
O
l &
na
te r
I n
c le
ra
O
Performing Tablespace Point-in-Time
Recovery
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Determine when to use tablespace point-in-time
recovery (TSPITR)
• Choose the correct TSPITR target time
• Perform basic RMAN tablespace point-in-time recovery
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Tablespace Point-in-Time Recovery (TSPITR)
Concepts
• TSPITR enables you to quickly recover one or more

tablespaces to an earlier time.
• TSPITR does not affect the state of other tablespaces
or objects in the database.
n l y
e O
Tablespace Point-in-Time Recovery (TSPITR) Concepts
U s
RMAN automatic tablespace point-in-time recovery (TSPITR) enables you to quickly recover
the other tablespaces and objects in the database. A I

one or more tablespaces in an Oracle database to an earlier time, without affecting the state of
O
l &
n a
te r
I n
c l e
r a
O
Tablespace Point-in-Time Recovery (TSPITR):
Terminology
• Target time: The point in time or SCN that the

tablespace will be recovered to
• Recovery set: Datafiles that compose the tablespaces
to be recovered
• Auxiliary set: Datafiles required for the TSPITR of the
recovery set that are not part of the recovery set. It
typically includes:
– SYSTEM tablespace
– Rollback or undo segment tablespaces
– Temporary tablespace
• Auxiliary destination: Disk location to store files
n l y
e O
Tablespace Point-in-Time Recovery (TSPITR): Terminology
The following terminology is used when discussing TSPITR:
U s
recovered to during TSPITR A I
• Target time: The point in time or system change number (SCN) that the tablespace will be
O
• Recovery set: Datafiles composing the tablespaces to be recovered
l &
• Auxiliary set: Datafiles required for TSPITR of the recovery set that are not themselves
part of the recovery set. The auxiliary set typically includes:
- A copy of the SYSTEM tablespace
n a
te r
- Datafiles containing rollback or undo segments from the target instance
- In some cases, a temporary tablespace, used during the export of database objects from
I n
the auxiliary instance
• Auxiliary destination: A location on disk that can be used to store any of the auxiliary set
l e
datafiles, control files, and online logs of the auxiliary instance during TSPITR. Files stored
c
in the auxiliary destination can be deleted after TSPITR is complete.
r a
O
Tablespace Point-in-Time Recovery: Architecture
RMAN
Control file Auxiliary instance
Restore
Datafile
Restore backups
Recover
1 Archived
redo log files Recovered tablespace
Target database
2
n l y
e O
U s
In the diagram, the following tablespace point-in-time recovery (TSPITR) entities are shown:
• Target database: Contains the tablespace to be recovered
• Control file: Provides the RMAN backup information A I
O
• Backup sets: Come from the target database and are the source of the reconstructed
tablespace
l &
• Archived redo logs: Come from the target database and are the source of the reconstructed
tablespace
n a
perform the recovery
te r
• Auxiliary instance: Is the Oracle database instance used during the recovery process to
I n
RMAN performs the following steps during tablespace point-in-time recovery (TSPITR):
1. Restores a backup control file from a point in time before the target time to the auxiliary
l e
instance. It restores the datafiles for the recovery set to the target database and the datafiles
c
for the auxiliary set to the auxiliary instance.
r a
2. Recovers the restored datafiles to the specified point in time
O
RMAN
5
Import metadata
Export
file
Recovered
tablespace
Control file
Auxiliary instance
Target database
4 3
Export
Point to recovered tablespace metadata
n l y
e O
Tablespace Point-in-Time Recovery Architecture (continued)
U s
3. Exports the dictionary metadata about objects in the recovered tablespace to the target
database
A I
4. Issues SWITCH commands on the target database so that the target database control file
O
points to the datafiles in the recovery set that were recovered on the auxiliary instance
the recovered objects to be accessed

l &
5. Imports the dictionary metadata from the auxiliary instance to the target instance, allowing
n a
te r
I n
c l e
r a
O
Understanding When to Use TSPITR
• TSPITR can be used in the following situations:

– To recover data lost after an erroneous TRUNCATE TABLE
statement
– To recover from logical corruption of a table
– To undo the effects of a batch job or DML statements
that have affected only a part of the database
– To recover a logical schema to a different point from the
rest of the physical database
• TSPITR cannot be used to:
– Recover a dropped tablespace
– Recover a renamed tablespace to a point before it was
renamed
n l y
e O
Understanding When to Use TSPITR
RMAN TSPITR can be used to:
U s
• Recover data lost after an erroneous TRUNCATE TABLE statement
• Recover from logical corruption of a table A I
O
• Undo the effects of an incorrect batch job or another DML statement that has affected only
a subset of the database
l &
• Recover a logical schema to a different point in time than other parts of the physical
database
n a
te r
I n
c l e
r a
O
Preparing for TSPITR
Perform the following steps to prepare for TSPITR:

• Determine the correct target time.
• Determine what is needed in the recovery set.
• Identify and preserve objects that will be lost after
TSPITR.
n l y
e O
Preparing for TSPITR
U s
Before performing TSPITR, you need to determine the correct target time for your recovery.
A I
You need to determine whether you need additional tablespaces in your recovery set. You
should evaluate what objects will be lost as a result of the TSPITR operation and determine how
you want to preserve those objects.
O
&
Each of these steps is discussed in more detail in this lesson.
l
n a
te r
I n
c l e
r a
O
Determining the Correct Target Time
• You cannot perform TSPITR a second time unless you

are using a recovery catalog.
• After you perform TSPITR and bring the tablespace
online, you cannot use a backup from an earlier time.
• Use the following methods to determine the correct
target time:
– Flashback Query
– Flashback Transaction Query
– Flashback Version Query
n l y
e O
Determining the Correct Target Time
U s
It is extremely important that you choose the right target time or SCN for TSPITR. After you
A I
bring a tablespace online after TSPITR, you cannot use any backup from a time earlier than the
moment you brought the tablespace online. In practice, this means that you cannot make a
O
second attempt at TSPITR if you choose the wrong target time the first time, unless you are
TSPITR operations to different target times.

l &
using a recovery catalog. If you have a recovery catalog, however, you can perform repeated
n a
The current control file does not contain a record of an older incarnation of the recovered
te r
tablespace if you do not use a recovery catalog. Recovery with a current control file that
involves the tablespace cannot use a backup taken prior to the time when you brought the
I n
tablespace online. However, you can perform incomplete recovery of the whole database to any
time prior to or equal to the time when you brought the tablespace online if you can restore a
l e
backup control file from before that time.
c
r a
You can use Oracle Flashback Query, Oracle Flashback Transaction Query, and Oracle
Flashback Version Query to investigate changes to your database and to help determine the
O
correct target time for TSPITR.

Determining the Tablespaces for the Recovery
Set
• Use the TS_PITR_CHECK view to identify relationships

that span recovery set boundaries.
• If objects in the tablespace that you are recovering
have relationships with objects in other tablespaces,
you can:
– Add the tablespace that contains the related objects to
the recovery set
– Suspend the relationship for the duration of TSPITR
– Remove the relationship
n l y
e O
Determining the Recovery Set
U s
If you are unsure whether you have accounted for all objects that have relationships with the
A I
objects in the tablespaces you are performing the TSPITR operation for, you can use the
TS_PITR_CHECK view to identify any additional objects. When you query this view,
O
information about any objects that will prevent you from proceeding with TSPITR is displayed.
column of the TS_PITR_CHECK view.

l &
The reason why tablespace point-in-time recovery cannot proceed is displayed in the REASON
n a
As an example, if you are planning to perform TSPITR for the USERS and EXAMPLE
te r
tablespaces, execute the following query to determine whether there are any relationships with
objects in other tablespaces that are not accounted for:
I n
SELECT * FROM SYS.TS_PITR_CHECK
WHERE (TS1_NAME IN ('USERS','EXAMPLE')
c l e
AND TS2_NAME NOT IN ('USERS','EXAMPLE'))
OR (TS1_NAME NOT IN ('USERS','EXAMPLE')
r a AND TS2_NAME IN ('USERS','EXAMPLE'));
O
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for additional
examples using the TS_PITR_CHECK view.

Identifying Objects That Will Be Lost
• Objects created in the tablespace after the target

recovery time are lost.
• Query TS_PITR_OBJECTS_TO_BE_DROPPED to
determine which objects will be lost following TSPITR.
• Use Export prior to TSPITR and Import following
TSPTIR to preserve and re-create the lost objects.
n l y
e O
Identifying Objects That Will be Lost
Query the TS_PITR_OBJECTS_TO_BE_DROPPED view to determine whether there are any
U s
A I
objects that will be lost as a result of performing tablespace point-in-time recovery.
As an example, you are performing TSPITR for the USERS and EXAMPLE tablespaces to the
O
target time of April 3, 2006 at 8:30:00 a.m. Issue the following query to determine whether there
&
are any objects that will be lost following your TSPITR:
l
a
SELECT OWNER, NAME, TABLESPACE_NAME,
r n
TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
te
WHERE TABLESPACE_NAME IN ('USERS','EXAMPLE')
n
AND CREATION_TIME >
I
TO_DATE('2006-APR-03:08:30:00','YY-MON-DD:HH24:MI:SS')
c l e
ORDER BY TABLESPACE_NAME, CREATION_TIME;
r a
O
Performing Basic RMAN TSPITR
• Fully automated TSPITR:

– Specify an auxiliary destination.
– RMAN manages all aspects of TSPITR.
– This is the recommended method.
• Customized TSPITR with an automatic auxiliary
instance:
– This is based on fully automated TSPITR.
– Customize location of files.
– Specify initialization parameters.
– Specify channel configurations.
• TSPITR using your own auxiliary instance:
– Configure and manage the auxiliary instance.
n l y
e O
Performing Basic RMAN TSPITR
You have the following options when performing TSPITR:
U s
A I
• Fully automated TSPITR: Specify an auxiliary destination and RMAN manages all
aspects of the TSPITR operation. This is the simplest way to perform TSPITR, and is
O
recommended unless you specifically need more control over the location of recovery set
l &
files after TSPITR or auxiliary set files during TSPITR, or control over the channel
configurations or some other aspect of your auxiliary instance.
a
• Customized TSPITR with an automatic auxiliary instance: TSPITR is based on the
n
te r
behavior of fully automated TSPITR, possibly still using an auxiliary destination. You can
customize one or more aspects of the behavior, such as the location of auxiliary set or
I n
recovery set files. You can specify initialization parameters or channel configurations for
the auxiliary instance created and managed by RMAN.
l e
• TSPITR with your own auxiliary instance: Set up, start, stop, and clean up the auxiliary
c
instance used in TSPITR. In addition, you can manage the TSPITR process using some of
r a
the methods available in customized TSPITR with an automatic auxiliary instance.
O
Performing Fully Automated TSPITR
• Configure channels required for TSPITR on the target

instance.
• Specify the auxiliary destination using the AUXILIARY
DESTINATION option .
RMAN> CONNECT TARGET
RMAN> RECOVER TABLESPACE users, example
> UNTIL TIME '2006-03-31:08:00:00'
> AUXILIARY DESTINATION
> '/u01/app/oracle/oradata/aux';
• Back up the recovered tablespaces and bring them

online.
n l y
e O
Performing Fully Automated TSPITR
U s
In addition to the preparation requirements discussed earlier in the lesson, when you perform
fully automated TSPITR, you must:
A
• Configure any channels required for TSPITR on the target instance
I
O
• Specify a destination for RMAN to use for the auxiliary set of datafiles and other auxiliary
instance files
l &
After TSPITR has completed, back up the recovered tablespaces and bring them online. You
n a
cannot use backups of any tablespaces that participate in TSPITR taken prior to TSPITR after
you perform TSPITR.
te r
I n
c l e
r a
O
Using Enterprise Manager to Perform TSPITR
n l y
e O
Using Enterprise Manager to Perform TSPITR
U s
You can also use Enterprise Manager to perform TSPITR. Select Perform Recovery in the High
A I
Availability section on the Maintenance page. In the Object Level Recovery section, select
Tablespaces in the Object Type menu and click Perform Object Level Recovery. You are
stepped through the TSPITR process.
O
l &
n a
te r
I n
c l e
r a
O
Understanding TSPITR Processing
RMAN performs the following steps:

1. Creates the auxiliary instance, starts it, and connects
to it
2. Takes the tablespaces that will be recovered offline
3. Restores a backup control file from a point in time
before the target time to the auxiliary instance
4. Restores the datafiles from the recovery set to the
target database and the auxiliary set to the auxiliary
instance
5. Recovers the restored datafiles to the specified time
6. Opens the auxiliary database with the RESETLOGS
option
n l y
e O
U s
The steps that RMAN carries out to perform TSPITR are listed on this page and the next.
A I
O
l &
n a
te r
I n
c l e
r a
O
7. Exports the dictionary metadata about objects in the

recovered tablespaces to the target database
8. Shuts down the auxiliary instance
9. Imports the dictionary metadata from the auxiliary
instance to the target instance
10. Deletes all auxiliary set files
n l y
e O
Understanding TSPITR Processing (continued)
U s
After RMAN completes the last step, the TSPITR process is complete. The recovery set datafiles
are returned to the state they were in at the specified target time.
A I
O
l &
n a
te r
I n
c l e
r a
O
Performing Customized RMAN TSPITR with an
RMAN-Managed Auxiliary Instance
• Rename or relocate your recovery set datafiles.

• Specify a location other than the auxiliary destination
for some or all of the auxiliary set datafiles.
• Create image copy backups of your datafiles in
advance of TSPITR.
• Use a different channel configuration for the auxiliary
instance.
• Specify different initialization parameters for your
RMAN-managed auxiliary instance.
n l y
e O
Performing Customized RMAN TSPITR with an RMAN-Managed Auxiliary Instance
U s
If you want to customize RMAN TSPITR, you can use an RMAN-managed auxiliary instance
and make the following changes:
A I
• Rename the recovery set datafiles using SET NEWNAME so that they are not restored and
recovered in their original locations.
O
l &
• Control the location of your auxiliary set datafiles by specifying new names for individual
files with SET NEWNAME and using DB_FILE_NAME_CONVERT to provide rules for
a
converting datafile names in the target database to datafile names for the auxiliary database.
n
te r
• Use existing image copies of the recovery set and auxiliary set datafiles on disk rather than
restoring them from backup for faster RMAN TSPITR performance.
I n
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for additional
information.
c l e
r a
O
Performing RMAN TSPITR Using Your Own
Auxiliary Instance
• Not recommended, but supported

• Perform the following steps:
1. Create an Oracle password file for the auxiliary instance.
2. Create an initialization parameter file for the auxiliary
instance.
3. Verify Oracle Net connectivity to the auxiliary instance.
5. Connect the RMAN client to the target and auxiliary
instances.
6. Execute the RECOVER TABLESPACE command.
n l y
e O
Performing RMAN TSPITR Using Your Own Auxiliary Instance
U
Oracle recommends that you allow RMAN to manage the creation and destruction of the
s
instance is supported. A I
auxiliary instance used during RMAN TSPITR. However, creating and using your own auxiliary
O
Perform the following steps to create an Oracle instance suitable for use as an auxiliary instance:
l &
1. Create an Oracle password file for the auxiliary instance using the orapwd utility.
2. Create a text initialization parameter file for the auxiliary instance.
n a
3. Verify Oracle Net connectivity to the auxiliary instance using a valid net service name.
te r
To perform TSPITR, complete the following steps:
I n
2. Connect the RMAN client to target and auxiliary instances.
3. Execute the RECOVER TABLESPACE command.
c l e
Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for a detailed
example.
r a
O
Troubleshooting RMAN TSPITR
• Filename conflicts: Ensure that there are no name

conflicts when using SET NEWNAME, CONFIGURE
AUXNAME, and DB_FILE_NAME_CONVERT.
• Insufficient sort space during Export: Increase the sort
space.
• RMAN cannot identify tablespaces with undo
segments: Use the UNDO TABLESPACE clause.
• Restarting a manual auxiliary instance after TSPITR
failure: Shut down and restart in NOMOUNT mode.
n l y
e O
Troubleshooting RMAN TSPITR
File name conflicts: If your use of SET NEWNAME, CONFIGURE AUXNAME, and
U s
A I
DB_FILE_NAME_CONVERT cause multiple files in the auxiliary or recovery sets to have the
same name, you receive an error during TSPITR. To correct the problem, specify different
values for these parameters to eliminate the duplicate name.
O
l &
Insufficient sort space during Export: When RMAN exports the metadata about recovered
objects from the auxiliary instance, it uses space in the temporary tablespace for sorting. If there
n a
is insufficient space in the temporary tablespace for the sorting operation, you need to increase
te r
the amount of sort space available. Edit the recover.bsq file, found in
$ORACLE_HOME/rdbms/admin, to remove the comment characters from the following lines
in the file:
I n
sql clone "create tablespace aux_tspitr_tmp
l e
datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K";
c
r a
O
Troubleshooting RMAN TSPITR (continued)
RMAN cannot identify tablespaces with undo segments: During TSPITR, RMAN needs
information about which tablespaces had undo segments at the TSPITR target time. This
information is usually available in the recovery catalog, if one is used. If there is no recovery
catalog, or if the information is not found in the recovery catalog, RMAN proceeds assuming
that the set of tablespaces with undo segments at the target time is the same as the set of
tablespaces with undo segments at the present time. If this assumption is not correct, the TSPITR
operation fails and an error is reported. To prevent this from happening, provide a list of
tablespaces with undo segments at the target time in the UNDO TABLESPACE clause.
Restarting manual auxiliary instance after TSPITR failure: If you are managing your own
auxiliary instance and there is a failure in TSPITR, then before you can retry TSPITR, you must
shut down the auxiliary instance, correct the problem, and put the auxiliary instance back in
NOMOUNT mode.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c l e
r a
O
Summary

• Determine when to use tablespace point-in-time
recovery
• Choose the correct target
• Perform basic RMAN tablespace point-in-time recovery
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Practice Overview
This practice covers using RMAN to perform TSPITR.
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Using the RMAN Recovery Catalog
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
ra
O
Objectives

• Create the recovery catalog
• Manage the recovery catalog
• Resynchronize the recovery catalog
• Use stored scripts
n l y
e O
U s
A I
O
l &
n a
te r
I n
c le
r a
O
RMAN Repository Data Storage:
Comparison of Options
Control file: Recovery catalog:

• Simpler administration • Replicates control file data
• Default • Has room for more data
• Can service many targets
• Can store RMAN scripts
Metadata
Backup set list
Image copy list
.
.
.
n l y
e O
RMAN Repository Data Storage: Comparison of Options
U s
The RMAN repository data is always stored in the control file of the target database. But it can
also be stored in a separate database, called a recovery catalog.
A I
A recovery catalog preserves backup information in a separate database, which is useful in the
O
event of a lost control file. This allows you to store a longer history of backups than what is
l &
possible with a control file–based repository. A single recovery catalog is able to store
information for multiple target databases. The recovery catalog can also hold RMAN stored
n a
scripts, which are sequences of RMAN commands for common backup tasks. Centralized
files.
te r
storage of scripts in the recovery catalog can be more convenient than working with command
I n
Using a separate recovery catalog database is not recommended for small installations where
administration of a separate recovery catalog database would be burdensome.
c l e
r a
O
Storing Information in the Recovery Catalog
Recovery
Manager
(RMAN)
Database structure
Archived redo logs
Target database Backup sets Recovery catalog
control file Datafile copies database
n l y
e O
Storing Information in the Recovery Catalog
U s
RMAN propagates information about the database structure, archived redo logs, backup sets,
A I
and datafile copies into the recovery catalog from the target database’s control file after any
operation that updates the repository, and also before certain operations.
O
l &
n a
te r
I n
c l e
r a
O
Reasons to Use a Recovery Catalog
• Stores more historical information than the control file

• Provides backup history needed for a recovery that
goes further back in time than the history in the control
file
• Enables you to use RMAN stored scripts
• Enables you to create customized reports for all
registered targets
• Enables you to use the KEEP FOREVER clause of the
BACKUP command
n l y
e O
Reasons to Use a Recovery Catalog
U s
Although you can use the control file as the sole repository for RMAN, it has finite space for
A I
records of backup activities. When you use a recovery catalog, you can store a much longer
history of backups. This enables you to perform a recovery that goes back further in time than
the history in the control file.
O
&
If you want to use RMAN stored scripts, you must use a recovery catalog.
l
n a
When you use a recovery catalog, the backup and recovery information for all registered
targets is contained in one place allowing you to create customized reports by connecting as
te r
the recovery catalog owner and querying the various RC_ views. If you do not use a recovery
catalog, you must connect to each target database instance separately and query the V$ views
I n
for the RMAN information in the target control file.
c l e
You can use the BACKUP ... KEEP command to create a backup that is retained for a
different period of time from that specified by the configured retention policy. The KEEP
r a
FOREVER clause specifies that the backup or copy never expires and requires the use of a
recovery catalog so that the backup records can be maintained indefinitely.
O
Creating the Recovery Catalog: Three Steps
Configure the Create the

Create the
recovery catalog recovery catalog
recovery catalog.
database. owner.
n l y
e O
Creating the Recovery Catalog: Three Steps
Perform the following three steps to create a recovery catalog:
U s
2. Create the recovery catalog owner. A I
1. Configure the database in which you will store the recovery catalog.
3. Create the recovery catalog.

O
l &
n a
te r
I n
c l e
r a
O
Configuring the Recovery Catalog Database
• Allocate space for the recovery catalog. Consider:

– The number of databases supported by the recovery
catalog
– Number of archived redo log files and backups recorded
– Use of RMAN stored scripts
• Space is needed for default tablespace for recovery
catalog owner schema.
• Create a tablespace for the recovery catalog.
n l y
e O
Configuring the Recovery Catalog Database
U s
Determine in which database you will install the recovery catalog schema. Be sure to consider
your backup and recovery procedures for this database.
A I
The amount of space required by the recovery catalog schema depends upon the number of
O
databases monitored by the catalog. The space increases as the number of archived redo log
l &
files and backups for each database increases. If you use RMAN stored scripts, space must be
allocated for those scripts. The typical space requirement is 15 MB for each database
n
registered in the recovery catalog. a
te r
I n
c l e
r a
O
Creating the Recovery Catalog Owner
1. Create the recovery catalog

owner.
2. Grant the
RECOVERY_CATALOG_OWNER
role.
SQL> CREATE USER rcowner IDENTIFIED BY rcpass

2 TEMPORARY TABLESPACE temp
3 DEFAULT TABLESPACE tools
4 QUOTA UNLIMITED ON tools;
SQL> GRANT recovery_catalog_owner TO rcowner;
n l y
e O
Creating the Recovery Catalog Owner
U s
Create a user to serve as the recovery catalog owner. Set the default tablespace for this user to
A I
the tablespace you created for the recovery catalog. Be sure to provide UNLIMITED quota on
this tablespace for the user. After you have created the user, grant the
O
RECOVERY_CATALOG_OWNER role to the user. The RECOVERY_CATALOG_OWNER role
l &
provides privileges for the owner of the recovery catalog. The role includes the following
system privileges: ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK,
a
CREATE PROCEDURE, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM,
n
te r
CREATE TABLE, CREATE TRIGGER, CREATE TYPE, and CREATE VIEW.
You can use SQL commands or Enterprise Manager to create the user and grant the role.
I n
c l e
r a
O
Creating the Recovery Catalog
1. Connect to the recovery catalog database as the

catalog owner:
$ rman
RMAN> CONNECT CATALOG username/password@net_service_name
2. Execute the CREATE CATALOG command:
RMAN> CREATE CATALOG;
n l y
e O
Creating the Recovery Catalog
U s
After creating the catalog owner, use the RMAN CREATE CATALOG command to create the
catalog tables in the default tablespace of the catalog owner.
A I
O
l &
n a
te r
I n
c l e
r a
O
Managing Target Database Records in the
Recovery Catalog
• Registering a database in the recovery catalog

• Cataloging additional backup files
• Unregistering a target database from the recovery
catalog
n l y
e O
Managing Target Database Records in the Recovery Catalog
U s
Although most information is automatically propagated from the control file to the recovery
records in the recovery catalog. A I

catalog, there are a few operations you may need to perform to maintain target database
O
l &
n a
te r
I n
c l e
r a
O
Registering a Database in the Recovery Catalog
RMAN performs the following actions:

• Creates rows in the recovery catalog tables for the
target database
• Copies data from the target database control file to the
recovery catalog tables
• Synchronizes the recovery catalog with the control file
$ rman TARGET / CATALOG

username/password@net_service_name
RMAN> REGISTER DATABASE;
n l y
e O
Registering a Database in the Recovery Catalog
U s
After creating the recovery catalog, you must register the target databases in the recovery
A I
catalog. Perform the following steps to register your target database:
1. Invoke RMAN and connect to the recovery catalog database and to the target database as
shown in the following example:
O
l &
% rman TARGET / CATALOG rman/rman@reccatdb
2. Ensure that the target database is mounted or open.
a
3. Register the target database in the recovery catalog by issuing the REGISTER command:
n
r
RMAN> REGISTER DATABASE;
te
I n
c l e
r a
O
Using Enterprise Manager to Register a Database
n l y
e O
U s
Select Recovery Catalog Settings in the Backup/Recovery Settings section of the Maintenance
existing recovery catalog. A I

page. Click Add Recovery Catalog to specify the host, port, and SID of a database with an
O
l &
n a
te r
I n
c l e
r a
O
n l y
e O
U s
After you have defined the recovery catalog database, select “Use Recovery Catalog” on the
I
Recovery Catalog Setting page to register the database in the recovery catalog database.
A
O
l &
n a
te r
I n
c l e
r a
O
Unregistering a Target Database from the
Recovery Catalog
• This removes information about the target database

from the recovery catalog.
• Use this when you no longer want the target database
to be defined in the recovery catalog.
$ rman TARGET / CATALOG

username/password@net_service_name
RMAN> UNREGISTER DATABASE;
n l y
e O
Unregistering a Target Database from the Recovery Catalog
U s
When you unregister a database from the recovery catalog, all RMAN repository records in the
A I
recovery catalog are lost. You can reregister the database. The recovery catalog records for
that database are then based on the contents of the control file at the time of reregistration.
O
Typically, you would unregister a target database only if you no longer want to use the
&
recovery catalog for that database or the database no longer exists.
l
n a
Note: If you have used Enterprise Manager Database Control to register your database, you
must use it again to unregister your database.
te r
I n
c l e
r a
O
Cataloging Additional Backup Files
• CATALOG can be used to catalog existing backup files

that are no longer listed in the control file.
• This enables RMAN to use the files during a restore
operation.
• Use the CATALOG command to add the following types
of backup files to the recovery catalog:
– Control file copies
– Datafile copies
– Backup pieces
– Archived redo log files
RMAN> CATALOG BACKUPPIECE 'file_name';
n l y
e O
Cataloging Additional Backup Files
U s
If you have additional control file copies, datafile copies, backup pieces, or archived redo log
A I
files on disk, you can catalog them in the recovery catalog by using the CATALOG command.
If backups have aged out of the control file, you can catalog them so that RMAN can use them
during a restore operation.
O
&
Examples of cataloging a control file, datafile, archived redo log file, and backup piece follow:
l
a
RMAN> CATALOG CONTROLFILECOPY
n
'/disk1/controlfile_bkup/2006_01_01/control01.ctl';
te r
RMAN> CATALOG DATAFILECOPY
'/disk1/datafile_bkup/2006_01_01/users01.dbf';
I n
RMAN> CATALOG ARCHIVELOG
'/disk1/arch_logs/archive1_731.log',
c l e
'/disk1/arch_logs/archive1_732.log';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
r a
You can catalog all files in the currently enabled Flash Recovery Area as follows:
RMAN> CATALOG RECOVERY AREA NOPROMPT;
O
Use the following command to catalog all valid backups in the specified location:
RMAN> CATALOG START WITH '/tmp/arch_logs';

Oracle Database 10g Backup Recovery Vol - 1

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Oracle Database 10g Backup Recovery Vol - 1

Enviado por

Direitos autorais:

Formatos disponíveis

Oracle Database 10g:

Backup and Recovery

Volume I • Student Guide

Donna Keesling Disclaimer

2 Configuring for Recoverability

r aBenefits of Using a Flash Recovery Area 2-15

Practice Overview 3-38

5 Using Oracle Flashback Technologies

r aFlashback Table: Overview 5-22

O Flashback Table 5-23

6 Using RMAN to Create a Duplicate Database

8 Using the RMAN Recovery Catalog

r aUpgrading the Recovery Catalog 8-25

O Dropping the Recovery Catalog 8-26

11 Installing Oracle Secure Backup

O Backup Settings 12-12

13 Backing Up File-System Files with Oracle Secure Backup

O Managing Devices 16-20

Appendix B: Practice Solutions

Appendix C: Oracle Secure Backup Additional Installation Topics

After completing this lesson, you should be able to:

After completing this course, you should be able to:

Backup and recovery constitutes the strategies and

should loss occur. A I

For performing backup and recovery based on physical

backups, and back up either the whole database or a portion of it. A I

Channel Channel Channel

Oracle Database 10g: Backup and Recovery 1 - 7

• One tool to backup and restore Oracle databases and

The use of a backup to perform recovery is often required

Possible responses to user error include:

• Crash recovery: Automatic recovery after instance

system change number (SCN).

Database at Database with Database with

• Datafiles are restored from a backup.

• Assess service-level criteria, including:

objectives, data availability requirements, and data criticality. A I

In addition to backup and recovery strategies and

available despite failures. A I

the failed component to backup components.

• Computer failure: Fast-start fault recovery, Real

RMAN with flash O

te r blocks; fast failover to an

r a connection failover minutes

O Oracle Streams Online replica database Seconds to 5

Oracle Database 10g: Backup and Recovery 1 - 20

In this lesson, you should have learned how to:

After completing this lesson, you should be able to:

• Operate the database in ARCHIVELOG mode.

• Configure the Flash Recovery Area.

Archived Control file Datafile backups

Perform the following steps to place the database in

Backups can be written to:

• Retention policy: Describes which backups will be kept

– Redundancy: Establishes a fixed number of backups that

r a FROM V$DATAFILE WHERE file#= …) >= 7

Oracle Database 10g: Backup and Recovery 2 - 6

• The Flash Recovery Area provides a centralized

Database area Flash Recovery Area

• The Flash Recovery Area is defined by setting the

Oracle Database 10g: Backup and Recovery 2 - 11

• Configure the retention policy to the minimum value

Oracle Database 10g: Backup and Recovery 2 - 13