D50079GC12 sg1

Computer Pride Limited
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2012, Oracle and/or its affiliatesฺ
ble
fe r a
t r a ns
Oracle Database 11g: o n -
an
Administrations Workshop II
h a ฺ
m ) u i de
o tG
ilฺIc• Student
g m tuden Guide
a
Volume
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta
D50079GC12
Edition 1.2
April 2009
D59862
Authors Copyright © 2009, Oracle. All rights reserved.
James Womack Disclaimer
Tom Best This document contains proprietary information and is protected by copyright and
Donna Keesling other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered in
James Spiller any way. Except where your use constitutes "fair use" under copyright law, you may
not use, share, download, upload, copy, print, display, perform, reproduce, publish,
Maria Billings
license, post, transmit, or distribute this document in whole or in part without the
Gwen Lazenby express authorization of Oracle.
The information contained in this document is subject to change without notice. If you
Technical Contributors find any problems in the document, please report them in writing to: Oracle University,
and Reviewers 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Sharath Bhujani
Restricted Rights Notice
Timothy Chien
Al Flournoy 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
Andy Fortunak applicable:
Gerlinde Frenzen
U.S. GOVERNMENT RIGHTS
ble
Joel Goodman 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
fe r a
Magnus Isaksson license agreement and/or the applicable U.S. Government contract.
an s
Pete Jones
n - t r
no
Trademark Notice
Pierre Labrousse
Jerry Lee s a
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
h a eฺ
names may be trademarks of their respective owners.
)
Hakan Lindfors
m i d
Isabelle Marchand
i l ฺ co nt Gu
Srinivas Putrevu
m a de
Andreas Reinhardt
i @ g S tu
Ira Singer
s y uk this
( M a use
Editors
y u ki se to
Arijit Ghosh as en
M
y Narasimhan
Vijayalakshmi l i c
l e
n Narayan
Sta
Amitha
Atanu Raychaudhuri
Richard Wallis
Graphic Designer
Rajiv Chandrabhanu
Publishers
Pavithran S Adka
Nita Brozowski
Jobi Varghese
Giri Venugopal
Contents
1 Database Architecture and ASM

Objectives 1-2
The Oracle Database 1-3
Oracle Database Architecture: Overview 1-4
Connecting to the Database 1-5
Oracle Database Server Structures 1-6
Oracle Memory Architecture 1-7
Process Architecture 1-9
ble
Process Structures 1-10
fe r a
Database Storage Architecture 1-12
ans
Logical and Physical Database Structures 1-14
n - t r
Tablespaces and Data Files 1-16
a no
SYSTEM and SYSAUX Tablespaces 1-17 a s
) h i d eฺ
m
co nt Gu
Segments, Extents, and Blocks 1-18
i l ฺ
Database Architecture: Summary of Structural Components 1-19
g ma tude
Automatic Storage Management: Review 1-20
k i@ is S
ASM: General Architecture 1-22
u
a sy se th
Creating an ASM Instance 1-23
i (M to u
ASM Instance Initialization Parameters 1-24
k
a syu cense
Starting Up an ASM Instance 1-25
yM li
SYSASM Role 1-26
nle Accessing an ASM Instance 1-27
Sta Using Enterprise Manager to Manage ASM Users 1-28
Shutting Down an ASM Instance 1-29
ASM Storage: Concepts 1-30
ASM Disk Group 1-31
Failure Group 1-33
Disk Group Mirroring 1-34
Disk Group Dynamic Rebalancing 1-35
Managing Disk Groups 1-36
Creating and Dropping Disk Groups 1-37
Adding Disks to Disk Groups 1-38
ASM Disk Group Compatibility 1-39
ASM Disk Group Attributes 1-41
Using Enterprise Manager to Edit Disk Group Attributes 1-42
iii
ASM Fast Mirror Resync Overview 1-43

Using EM to Perform Fast Mirror Resync 1-44
Miscellaneous ALTER Commands 1-45
ASMCMD Utility 1-46
ASM Scalability and Performance 1-48

Summary 1-50
Practice 1 Overview: Database Architecture and ASM 1-51
2 Configuring for Recoverability

Objectives 2-2
Purpose of Backup and Recovery Functionality 2-3
Typical Backup and Recovery Tasks 2-4
Oracle Backup and Recovery Solutions 2-6
Using Recovery Manager 2-7 ble
fe r a
Types of RMAN Commands 2-8
ans
Job Commands: Example 2-9
n - t r
Configuring Your Database for Backup and Recovery Operations 2-10
a no
ARCHIVELOG Mode 2-11
a s
Configuring ARCHIVELOG Mode 2-12 ) h i d eฺ
m
co nt Gu
Configuring Archive Log Destinations 2-14 i
a del ฺ
Guaranteeing Archive Log Success 2-15 m
i @ g S tu
uk
Specifying a Backup Destination 2-17
is
2-18 e th
Specifying a Retention Policysy
( Ma tPolicy:
A Recovery Window iRetention o usExample 2-20
y uk nArea
Using a Flash Recovery
s se 2-21
DefiningM a e
lic Area 2-23
a Flash Recovery
l e y
tan
Defining a Flash Recovery Area Using Enterprise Manager 2-24
S Flash Recovery Area Space Management 2-25
Flash Recovery Area Space Usage 2-27
Monitoring the Flash Recovery Area 2-29
Benefits of Using a Flash Recovery Area 2-30
Summary 2-31
Practice 2 Overview: Configuring for Recoverability 2-32
3 Using the RMAN Recovery Catalog

Objectives 3-2
RMAN Repository Data Storage: Comparison of Options 3-3
Storing Information in the Recovery Catalog 3-4
Reasons to Use a Recovery Catalog 3-5
Creating the Recovery Catalog: Three Steps 3-6
iv
Configuring the Recovery Catalog Database 3-7

Creating the Recovery Catalog Owner 3-8
Creating the Recovery Catalog 3-9
Managing Target Database Records in the Recovery Catalog 3-10
Registering a Database in the Recovery Catalog 3-11

Using Enterprise Manager to Register a Database 3-12
Registering a Duplicated Database 3-15
Changing the DBID of a Database 3-16
Unregistering a Target Database from the Recovery Catalog 3-17
Cataloging Additional Backup Files 3-18
Recovery Catalog Resynchronization: Concepts 3-20
Manually Resynchronizing the Recovery Catalog 3-21
Using RMAN Stored Scripts 3-22
Creating RMAN Stored Scripts 3-23 ble
Executing RMAN Stored Scripts 3-24 fe r a
ans
Displaying RMAN Stored Script Information 3-25
n - t r
Updating and Deleting RMAN Stored Scripts 3-26
a no
Backing Up the Recovery Catalog 3-27
a s
) h d eฺ
Re-Creating an Unrecoverable Recovery Catalog 3-28
i
m
co nt Gu
i l ฺ
Exporting and Importing the Recovery Catalog 3-29
ma tude
Upgrading the Recovery Catalog 3-30
g
u k i@ is S
Dropping the Recovery Catalog 3-31
sy se th
Using a Virtual Private Catalog 3-32
a
k i (M to u
Creating an RMAN Virtual Private Catalog 3-34
a syu cense
Summary 3-36
yM li
Practice 3 Overview: Using the RMAN Recovery Catalog 3-37
nle
Sta 4 Configuring Backup Specifications
Objectives 4-2
Using RMAN to Create Backups 4-3
Backup Destinations 4-4
Configuring Persistent Settings for RMAN 4-5
Using Enterprise Manager to Configure RMAN Settings 4-6
Control File Autobackups 4-7
Managing Persistent Settings 4-9
Configuring Devices for Backup 4-10
Configuring and Allocating Channels for Use in Backups 4-12
Configuring Backup Optimization 4-13
Summary 4-15
Practice 4 Overview: Configuring Backup Specifications 4-16
v
5 Using RMAN to Create Backups

Objectives 5-2
Creating Backup Sets 5-3
Creating Image Copies 5-4
Creating a Whole Database Backup 5-6

Saving Backup Space with Unused Block Compression 5-8
RMAN Backup Types 5-9
Fast Incremental Backup 5-11
Enabling Fast Incremental Backup 5-12
Monitoring Block Change Tracking 5-13
Creating Duplexed Backup Sets 5-14
Creating Duplexed Backup Sets Using CONFIGURE BACKUP COPIES 5-15
Creating Duplexed Backup Sets Using BACKUP COPIES 5-16
Creating Backups of Backup Sets 5-17 ble
fe r a
Backing Up Read-Only Tablespaces 5-18
ans
Archival Backups: Concepts 5-19
n - t r
Creating Archival Backups with EM 5-21
a no
Creating Archival Backups with RMAN 5-22
a s
Managing Archival Database Backups 5-23 ) h i d eฺ
m
co nt Gu
Multisection Backups: Overview 5-24
i l ฺ
ma tude
Creating RMAN Multisection Backups 5-25
g
Compressing Backups 5-26
u k i@ is S
sy se th
Encrypting Backups 5-27
a
k i (M to u
Backing Up Recovery Files 5-29
syu cense
Using a Media Manager 5-30
a
yM li
Performing Proxy Copies 5-32
n le
Creating an Oracle-Suggested Backup 5-33
Sta Managing Backups: Reporting 5-34
Managing Backups: Dynamic Performance Views 5-36
Using Enterprise Manager to View Backup Reports 5-37
Managing Backups: Cross-Checking and Deleting 5-38
Summary 5-39
Practice 5 Overview: Creating Backups 5-40
6 Performing User-Managed Backup and Recovery

Objectives 6-2
Restoring and Recovering 6-3
Causes of File Loss 6-4
Critical Versus Noncritical 6-5
Losing a Tempfile 6-6
Recovering from a Tempfile Loss 6-7
vi
Log Group Status: Review 6-8

Recovering from the Loss of a Redo Log Group 6-9
Clearing a Log File 6-10
Re-Creating Indexes 6-11
Recovering from a Lost Index Tablespace 6-13

Authentication Methods for Database Administrators 6-14
Re-creating a Password Authentication File 6-15
Comparing Complete and Incomplete Recovery 6-17
Complete Recovery Process 6-18
Incomplete Recovery Process 6-19
Types of Backup and Recovery Practices 6-21
Performing a User-Managed Backup of the Database 6-22
The Need for Backup Mode 6-23
Identifying Files to Manually Backup 6-24 ble
Manually Backing Up a NOARCHIVELOG Database 6-25 fe r a
ans
Manually Backing Up an ARCHIVELOG Database 6-26
n - t r
Backing Up the Control File 6-27
a no
s
Performing User-Managed Complete Database Recovery: Overview 6-28
a
) h i d eฺ
Performing Complete Closed Database Recovery: Overview 6-29
m
co nt Gu
l ฺ
Identifying Recovery-Related Files 6-30
i
ma tude
Restoring Recovery-Related Files 6-31
g
u k i@ is S
Applying Redo Data 6-33
sy se th
Performing Complete Open Database Recovery 6-34
a
k i (M to u
Performing User-Managed Incomplete Recovery: Overview 6-36
a syu cense
Choosing an Incomplete Recovery Method 6-37
yM li
Performing User-Managed Incomplete Recovery 6-38
nle Performing User-Managed Incomplete Recovery: Steps 6-40
Sta User-Managed Time-Based Recovery: Example 6-41
User-Managed Cancel-Based Recovery: Example 6-43
Recovering a Read-Only Tablespace 6-45
Recovering NOLOGGING Database Objects 6-46
Recovering from the Loss of All Control File Copies: Overview 6-47
Recovering the Control File to the Default Location 6-48
Summary 6-49
Practice 6 Overview: Performing User-Managed Recovery 6-50
7 Using RMAN to Perform Recovery

Objectives 7-2
Using RMAN RESTORE and RECOVER Commands 7-3
Performing Recovery Using Enterprise Manager 7-4
vii
Performing Complete Recovery: Loss of a Noncritical Data File in ARCHIVELOG

Mode 7-5
Performing Complete Recovery: Loss of a System-Critical Data File in
ARCHIVELOG Mode 7-6
Recovering Image Copies 7-7

Recovering Image Copies: Example 7-8
Performing a Fast Switch to Image Copies 7-10
Using SET NEWNAME for Switching Files 7-11
Performing Restore and Recovery of a Database in NOARCHIVELOG Mode 7-12
Creating Restore Points 7-13
Performing Incomplete Recovery 7-14
Performing Recovery with a Backup Control File 7-16
Restoring the Server Parameter File from the Control File Autobackup 7-17
ble
Restoring the Control File from Autobackup 7-18
fe r a
Using Incremental Backups to Recover a Database in NOARCHIVELOG
ans
Mode 7-20
n - t r
Restoring and Recovering the Database on a New Host 7-21
a no
a s
Preparing to Restore the Database to a New Host 7-22
) h i d eฺ
Restoring the Database to a New Host 7-23 m
co nt Gu
Performing Disaster Recovery 7-27 i l ฺ
Summary 7-29 g ma tude
k i@ is S
Practice 7 Overview: Using RMAN to Perform Recovery 7-30
u
a sy se th
8 Using RMAN to Duplicate i t u
(M a Database
o
k
syu cense
Objectives 8-2
a
Using RMAN
y li a Duplicate Database 8-3
M to Create
l e
nUsing a Duplicate Database 8-4
t a
S Creating a Duplicate Database 8-5
Creating an Initialization Parameter File for the Auxiliary Instance 8-6
Specifying Parameters for Control File Naming 8-7
Starting the Instance in NOMOUNT Mode 8-9
Ensuring That Backups and Archived Redo Log Files Are Available 8-10
Allocating Auxiliary Channels 8-11
Using the RMAN DUPLICATE Command 8-12
Understanding the RMAN Duplication Operation 8-13
Specifying Options for the DUPLICATE Command 8-14
Using EM to Clone a Database 8-15
Cloning a Running Database 8-16
Cloning a Database from a Backup 8-20
viii
Summary 8-21
Practice 8 Overview: Using RMAN to Duplicate a Database 8-22
9 Performing Tablespace Point-in-Time Recovery

Objectives 9-2
Tablespace Point-in-Time Recovery (TSPITR): Concepts 9-3
Tablespace Point-in-Time Recovery (TSPITR): Terminology 9-4
Tablespace Point-in-Time Recovery: Architecture 9-5
When to Use TSPITR 9-7
Preparing for TSPITR 9-8
Determining the Correct Target Time 9-9
Determining the Tablespaces for the Recovery Set 9-10
Identifying Objects That Will Be Lost 9-11
Performing Basic RMAN TSPITR 9-12 ble
Performing Fully Automated TSPITR 9-13 fe r a
ans
Using Enterprise Manager to Perform TSPITR 9-14
n - t r
RMAN TSPITR Processing 9-15
a no
s
Performing RMAN TSPITR with an RMAN-Managed Auxiliary Instance 9-17
a
) h d eฺ
Performing RMAN TSPITR Using Your Own Auxiliary Instance 9-18
i
m
co nt Gu
Troubleshooting RMAN TSPITR 9-19
i l ฺ
Summary 9-20
g ma tude
u k i@ is S
Practice 9 Overview: Performing TSPITR 9-21
a sy se th
10 Monitoring and
i (M u
Tuning RMAN
t o
k
yu 10-2
Objectives se
a s e n
y M l ic of Backup Sets 10-3
Parallelization
nle Monitoring RMAN Sessions 10-5

Sta Monitoring RMAN Job Progress 10-7
Interpreting RMAN Message Output 10-9
Using the DEBUG Option 10-10
Interpreting RMAN Error Stacks 10-11
Tuning RMAN 10-12
RMAN Multiplexing 10-14
Allocating Disk Buffers: Example 10-15
Allocating Tape Buffers 10-16
Comparing Synchronous and Asynchronous I/O 10-18
Monitoring RMAN Job Performance 10-20
Asynchronous I/O Bottlenecks 10-21
Synchronous I/O Bottlenecks 10-22
Tape Backup Speed 10-23
Tape Subsystem Performance Rules 10-24
ix
Controlling Tape Buffer Size with BLKSIZE 10-25

Channel Tuning 10-26
Tuning the BACKUP Command 10-28
Tuning RMAN Backup Performance 10-30
Setting LARGE_POOL_SIZE 10-31

Tuning RMAN Tape Streaming Performance Bottlenecks 10-32
Summary 10-34
Practice 10 Overview: Monitoring and Tuning RMAN 10-35
11 Using Flashback Technology

Objectives 11-2
Flashback Technology 11-3
Flashback Drop and the Recycle Bin 11-4
ble
Recycle Bin 11-5
fe r a
Restoring Tables from the Recycle Bin 11-7
ans
Recycle Bin: Automatic Space Reclamation 11-8
n - t r
Recycle Bin: Manual Space Reclamation 11-9
a no
Bypassing the Recycle Bin 11-10 a s
Querying the Recycle Bin 11-11 ) h i d eฺ
m
co nt Gu
Transactions and Undo 11-12 i l ฺ
ma tude
Guaranteeing Undo Retention 11-13
g
k i@ is S
Preparing Your Database for Flashback 11-14
u
sy se th
Using Flashback Technology to Query Data 11-16
a
k i (M to u
Flashback Query 11-17
syu cense
Flashback Query: Example 11-18
a
yM li
Flashback Version Query 11-19
n le
Using Enterprise Manager to Perform Flashback Version Query 11-20
Sta Flashback Version Query: Considerations 11-21
Flashback Transaction Query 11-22
Using Enterprise Manager to Perform Flashback Transaction Query 11-23
Flashback Transaction Query: Considerations 11-24
Flashback Transaction 11-25
Prerequisites 11-26
Flashing Back a Transaction 11-27
Possible Workflow 11-28
Viewing Data 11-29
Flashback Transaction Wizard 11-30
Choosing Other Back-out Options 11-34
Final Steps Without EM 11-36
x
Summary 11-37
Practice 11 Overview: Performing Flashback Database 11-38
12 Additional Flashback Operations

Objectives 12-2
Flashback Table: Overview 12-3
Flashback Table 12-4
Enabling Row Movement on a Table 12-5
Performing Flashback Table 12-6
Flashback Table: Considerations 12-7
Flashback Database 12-8
Flashback Database Architecture 12-9
Configuring Flashback Database 12-10
Configuring Flashback Database Using EM 12-11 ble
Flashback Database: Examples 12-13 fe r a
ans
Performing Flashback Database Using EM 12-14
n - t r
Flashback Database Considerations 12-17
a no
Monitoring Flashback Database 12-18
a s
) h
Monitoring Flashback Database with EM 12-20 i d eฺ
m
co nt Gu
i l ฺ
Guaranteed Restore Points 12-21
ma tude
Flashback Database and Guaranteed Restore Points 12-22
g
u k i@ is S
Flashback Data Archive 12-24
sy se th
Flashback Data Archive Process 12-25
a
k i (M to u
Flashback Data Archive Scenario 12-26
syu cense
Viewing Flashback Data Archives 12-28
a
yM li
Flashback Data Archive DDL Restrictions 12-29
nle Summary 12-30

Sta Practice 12 Overview: Working with Flashback Database 12-31
13 Diagnosing the Database

Objectives 13-2
Automatic Diagnostic Workflow 13-3
Automatic Diagnostic Repository 13-4
The ADR Command-Line Tool, ADRCI 13-5
The V$DIAG_INFO View 13-6
Location for Diagnostic Traces 13-7
Viewing the Alert Log Using Enterprise Manager 13-8
EM Support Workbench: Overview 13-9
Support Workbench and Oracle Configuration Manager 13-10
EM Support Workbench Roadmap 13-11
Problems and Incidents 13-12
xi
Viewing Critical Error Alerts in Enterprise Manager 13-14

Viewing Problem Details 13-15
Viewing Incident Details 13-16
Creating a Service Request 13-18
Packaging and Uploading Diagnostic Data to Oracle Support 13-19

Tracking the SR 13-20
Implementing Repairs 13-21
Closing Incidents and Problems 13-22
Incident Packaging Configuration 13-23
Custom Packaging: Creating a New Package 13-24
Custom Packaging: Manipulating an Incident Package 13-25
Custom Packaging: Finalizing an Incident Package 13-26
Custom Packaging: Generating a Package 13-27
Custom Packaging: Uploading a Package 13-28 ble
Viewing and Modifying Incident Packages 13-29 fe r a
ans
Health Monitor: Overview 13-30
n - t r
Running Health Checks Manually: EM Example 13-31
a no
s
Running Health Checks Manually: PL/SQL Example 13-32
a
) h
Viewing HM Reports Using the ADRCI Utility 13-33 i d eฺ
m
co nt Gu
SQL Repair Advisor Overview 13-34
i l ฺ
ma tude
Using SQL Repair Advisor from PL/SQL 13-35
g
u k i@ is S
What Is Block Corruption? 13-36
sy se th
Block Corruption Symptoms: ORA-01578 13-37
a
k i (M to u
How to Handle Corruption 13-38
syu cense
Verifying Block Integrity in Real Time: DB_BLOCK_CHECKING 13-39
a
yM li
Block Media Recovery 13-40
le
Prerequisites for Block Media Recovery 13-41
n
Sta The RECOVER...BLOCK Command 13-42
Data Recovery Advisor 13-43
Data Recovery Advisor: RMAN Command-Line Interface 13-44
Listing of Data Failures 13-45
Advising on Repair 13-47
Executing Repairs 13-48
Classifying (and Closing) Failures 13-49
Data Recovery Advisor Views 13-50
Summary 13-51
Practice 13 Overview: Diagnosing the Database 13-52
14 Managing Memory
Objectives 14-2
Memory Management: Overview 14-3
xii
Oracle Memory Structures 14-4

Buffer Cache 14-6
Using Multiple Buffer Pools 14-8
Shared Pool 14-10
Large Pool 14-11

Java Pool 14-12
Redo Log Buffer 14-13
Automatic Shared Memory Management: Overview 14-14
How ASMM Works 14-15
Enabling Automatic Shared Memory Management 14-16
Behavior of Autotuned SGA Parameters 14-17
Behavior of Manually Tuned SGA Parameters 14-18
Using the V$PARAMETER View 14-19
Modifying the SGA_TARGET Parameter 14-20 ble
Disabling ASMM 14-21 fe r a
ans
Manually Resizing Dynamic SGA Parameters 14-22
n - t r
Using the Memory Advisor to Size the SGA 14-23
a no
Program Global Area (PGA) 14-24
a s
)
Automatic PGA Memory Management 14-26 h i d eฺ
m
co nt Gu
PGA Management Resources 14-27
i l ฺ
ma tude
Using the Memory Advisor to Size the PGA 14-28
g
u k i@ is S
Automatic Memory Management: Overview 14-29
sy se th
Oracle Database Memory Parameters 14-30
a
k i (M to u
Automatic Memory Parameter Dependency 14-31
syu cense
Enabling Automatic Memory Management with EM 14-33
a
yM li
Monitor Automatic Memory Management 14-34
nle Monitoring Automatic Memory Management 14-35

Sta Efficient Memory Usage: Guidelines 14-36
Memory Tuning Guidelines for the Library Cache 14-38
Summary 14-40
Practice 14 Overview: Using AMM to Correct a Memory Allocation Problem 14-41
15 Managing Database Performance

Objectives 15-2
Tuning Activities 15-3
Performance Planning 15-4
Instance Tuning 15-6
Performance Tuning Methodology 15-7
Performance Monitoring 15-8
Performance Tuning Data 15-9
Optimizer Statistics Collection 15-10
xiii
Oracle Wait Events 15-12

Instance Statistics 15-13
Monitoring Session Performance 15-15
Displaying Session-Related Statistics 15-16
Displaying Service-Related Statistics 15-17

Troubleshooting and Tuning Views 15-18
Dictionary Views 15-19
Automatic Workload Repository 15-20
SQL Tuning 15-22
SQL Advisors 15-23
Automatic SQL Tuning Results 15-24
Implement Automatic Tuning Recommendations 15-25
SQL Tuning Advisor: Overview 15-26
Using the SQL Tuning Advisor 15-27 ble
SQL Tuning Advisor Options 15-28 fe r a
ans
SQL Tuning Advisor Recommendations 15-29
n - t r
Using the SQL Tuning Advisor: Example 15-30
a no
Duplicate SQL 15-31
a s
SQL Access Advisor: Overview 15-32 ) h i d eฺ
m
co nt Gu
i l ฺ
Typical SQL Access Advisor Session 15-33
Workload Source 15-34
g ma tude
u k i@ is S
Recommendation Options 15-35
sy se th
Reviewing Recommendations 15-37
a
k i (M to u
Database Replay 15-38
syu cense
System Architecture: Capture 15-39
a li
System Architecture: Processing the Workload 15-40
yM
le
System Architecture: Replay 15-41
n
Sta The Big Picture 15-42
Workloads Supported 15-43
Using Enterprise Manager for Workload Capture 15-44
Using Enterprise Manager for Workload Replay 15-45
Summary 15-46
Practice 15 Overview: Monitor Instance Performance 15-47
16 Space Management
Objectives 16-2
Space Management: Overview 16-3
Free Space Management Within Segments 16-4
Types of Segments 16-5
Allocating Extents 16-6
Block Space Management 16-7
xiv
Row Chaining and Migration 16-8

Proactive Tablespace Monitoring 16-9
Thresholds and Resolving Space Problems 16-10
Monitoring Tablespace Space Usage 16-11
Shrinking Segments 16-12

Results of Shrink Operation 16-13
Reclaiming Space Within ASSM Segments 16-14
Segment Advisor: Overview 16-15
Segment Advisor 16-16
Implementing Recommendations 16-17
Automatic Segment Advisor 16-18
Manual Segment Shrink Using EM 16-19
Shrinking Segments Using SQL 16-20
Managing Resumable Space Allocation 16-21 ble
Using Resumable Space Allocation 16-22 fe r a
ans
Resuming Suspended Statements 16-24
n - t r
What Operations Are Resumable? 16-26
a no
Transporting Tablespaces 16-27
a s
) h
Concept: Minimum Compatibility Level 16-28 i d eฺ
m
co nt Gu
i l ฺ
Minimum Compatibility Level 16-29
ma tude
Transportable Tablespace Procedure 16-30
g
u k i@ is S
Determining the Endian Format of a Platform 16-31
sy se th
Transportable Tablespaces with Enterprise Manager 16-33
a
k i (M to u
Transporting Databases 16-36
syu cense
Database Transportation Procedure: Source System Conversion 16-37
a
yM li
Database Transportation Procedure: Target System Conversion 16-38
nle Database Transportation: Considerations 16-39

Sta Summary 16-40
Practice 16 Overview: Managing Storage 16-41
17 Managing Resources
Objectives 17-2
Database Resource Manager: Overview 17-3
Database Resource Manager: Concepts 17-4
Why Use Resource Manager 17-5
Accessing Resource Plans 17-7
Default Maintenance Resource Manager Plan 17-8
Example: DEFAULT_PLAN 17-9
Creating a New Resource Plan 17-10
Creating Consumer Groups 17-11
Assigning Users to Consumer Groups 17-12
xv
Specifying Resource Plan Directives 17-13

Resource Allocation Methods for Resource Plans 17-14
Comparison of EMPHASIS and RATIO 17-15
Active Session Pool Mechanism 17-17
Setting the Active Session Pool 17-18

Specifying Thresholds: Execution Time Limit 17-20
Setting Idle Timeouts 17-21
Resource Consumer Group Mapping 17-22
Activating a Resource Plan 17-24
Database Resource Manager Information 17-25
Monitoring the Resource Manager 17-26
Summary 17-29
Practice 17 Overview: Using the Resource Manager 17-30
ble
18 Automating Tasks with the Scheduler fe r a
ans
Objectives 18-2
n - t r
Simplifying Management Tasks 18-3
a no
A Simple Job 18-4
a s
Key Components and Steps 18-5 ) h i d eฺ
m
co nt Gu
1. Creating a Program 18-6
i l ฺ
ma tude
2. Creating and Using Schedules 18-7
g
u k i@ is S
3. Creating and Running a Job 18-8
sy se th
4. Monitoring a Job 18-9
a
k i (M to u
Using a Time-Based or Event-Based Schedule 18-10
syu cense
Creating a Time-Based Job 18-11
a li
Persistent Lightweight Jobs 18-13
yM
le
Choosing the Right Job 18-14
n
Sta Creating a Single Lightweight Job 18-16
Creating an Event-Based Schedule 18-17
Creating Event-Based Schedules with Enterprise Manager 18-18
Creating an Event-Based Job 18-19
Event-Based Scheduling 18-20
Creating Complex Schedules 18-22
Creating Job Chains 18-23
Example of a Chain 18-25
1. Creating a Chain Object 18-26
2. Defining Chain Steps 18-27
3. Defining Chain Rules 18-28
4. Starting the Chain 18-29
Monitoring Job Chains 18-30
xvi
Summary 18-31
Practice 18 Overview: Automating Tasks with the Scheduler 18-32
19 Administering the Scheduler

Objectives 19-2
Advanced Scheduler Features 19-3
Job Classes 19-4
Creating a Job Class 19-6
Windows 19-7
Creating a Window 19-8
Prioritizing Jobs Within a Window 19-10
Creating an Array of Lightweight Jobs 19-11
Creating Lightweight Jobs 19-12
Viewing Lightweight Jobs in Dictionary 19-14 ble
PL/SQL APIs 19-15 fe r a
ans
Generic Scheduler Data Dictionary Views 19-16
n - t r
Summary 19-18
a no
a s
20 Globalization ) h i d eฺ
m
co nt Gu
Objectives 20-2
i l ฺ
ma tude
Globalization Support Features 20-3
g
What Every DBA Needs to Know
u k i@ 20-4is S
sy 20-5
What Is a Character Set?
a e th
M to20-7
Understanding (Unicode
i us
How Arey k sSets
uCharacter e Used? 20-9
a s
Problems toic e n
Avoid 20-10
y M l
nle Another Sample Problem 20-11
Sta Choosing Your Character Set 20-12
Database Character Sets and National Character Sets 20-13
Obtaining Character Set Information 20-14
Specifying Language-Dependent Behavior 20-15
Specifying Language-Dependent Behavior for the Session 20-16
Language-Dependent and Territory-Dependent Parameters 20-17
Specifying Language-Dependent Behavior 20-19
Linguistic Searching and Sorting 20-20
Using Linguistic Searching and Sorting 20-22
Case-Insensitive and Accent-Insensitive Search and Sort 20-24
Support in SQL and Functions 20-25
Linguistic Index Support 20-26
Customizing Linguistic Searching and Sorting 20-27
Implicit Conversion Between CLOB and NCLOB 20-29
xvii
NLS Data Conversion with Oracle Utilities 20-30

NLS Data Conversion with Data Pump 20-32
Language and Character Set File Scanner (LCSSCAN) 20-33
Setting the Database Time Zone 20-34
Summary 20-35
Practice 20 Overview: Using Globalization Support 20-36
Appendix A
Index
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
xviii
Database Architecture and ASM
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ isAllSrights reserved.
sy se th
Copyright © 2009, Oracle.
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives
After completing this lesson, you should be able to:

• Describe the Oracle Database architecture

• Describe Automatic Storage Management (ASM)
• Set up initialization parameter files for ASM and database
instances
• Start up and shut down ASM instances
• Administer ASM disk groups
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Oracle Database 11g: Administration Workshop II 1 - 2

The Oracle Database
The Oracle Relational Database Management System

(RDBMS) is a database management system that provides an

open, comprehensive, integrated approach to information
management.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
The Oracle Database k i
a s yu ense
A database isM
y lic of data treated as a unit. The purpose of a database is to store and
a collection
e information.
nlrelated
retrieve
t a
S Oracle Database reliably manages a large amount of data in a multiuser environment so
An
that many users can concurrently access the same data. This is accomplished while delivering
high performance. At the same time, the database prevents unauthorized access and provides
efficient solutions for failure recovery.

Oracle Database Architecture: Overview

Instance
SMON PMON Others
SGA Shared pool
Library
Database cache
Redo log
buffer
buffer
cache Data dictionary
cache
PGA
Server
process DBWn CKPT LGWR ARCn
ble
fe r a
ans
n - t r
n o
User
a
sArchived
Control Online )
redoh a eฺ
log files
process
logm i d
co nt Gu
Data files files files
Database i l ฺ
g ma tude
sy se th
a
(M to u
k
Oracle Database Architecture i
a s yu ense
An Oracle database
y M server lic consists of an Oracle database and one or more database
t a nle instance consists of memory structures and background processes. Every time an
instances.The
S
instance is started, a shared memory area called the System Global Area (SGA) is allocated
and the background processes are started.
The database consists of both physical structures and logical structures. Because the physical
and logical structures are separate, the physical storage of data can be managed without
affecting access to logical storage structures.

Connecting to the Database
• Connection: Communication between a user process and

an instance
• Session: Specific connection of a user to an instance
through a user process
ble
Session fe r a
USER
SQL> Select … User
ans
n - t r
a no
a s
) h i d eฺ
Connection o m
c nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Connecting to the Databasei
a s yu ense
M sessionlicare closely related to user process but are very different in meaning.
Connection and
y
t a nle is a communication pathway between a user process and an Oracle Database
A connection
S
instance. A communication pathway is established using available interprocess communication
mechanisms (on a computer that runs both the user process and Oracle Database) or network
software (when different computers run the database application and Oracle Database, and
communicate through a network).
A session represents the state of a current user login to the database instance. For example,
when a user starts SQL*Plus, the user must provide a valid username and password, and then a
session is established for that user. A session lasts from the time the user connects until the
time the user disconnects or exits the database application.
Multiple sessions can be created and exist concurrently for a single Oracle Database user who
is using the same username. For example, a user with the username/password of HR/HR can
connect to the same Oracle Database instance several times.

Oracle Database Server Structures

Instance
Memory structures
SGA Shared pool
Library
Database cache
User Server Redo log
process process buffer
buffer
cache Data dict.
cache
Processes DBWn CKPT LGWR SMON PMON ARCn Others
Database
ble
fe r a
Storage structures an s
n - t r
a no
a s
) h i d eฺ
m
o Control G u Online redo
Data files ilฺc n t
files log files
a e
@ gm Stud
u
Copyright
y k© i2009, Oracle.
t h isAll rights reserved.
s
a use
( M
Database Structures
y u ki se to
After startingM
s cethen Oracle software associates the instance with a specific database.
anainstance,
li
l ey mounting the database. The database is then ready to be opened, which makes it
This isncalled
Sta to authorized users. Multiple instances can execute concurrently on the same
accessible
computer, each accessing its own physical database.
You can look at the Oracle Database architecture as various interrelated structural
components.
An Oracle instance uses memory structures and processes to manage and access the database.
All memory structures exist in the main memory of the computers that constitute the database
server. Processes are jobs that work in the memory of these computers. A process is defined as
a “thread of control” or a mechanism in an operating system that can run a series of steps.

Oracle Memory Architecture

Server Server Background

PGA PGA PGA
process 1 process 2 process
Data Dictionary SGA

Shared
cache
SQL area
Library Other
cache
ble
Redo log Shared pool
fe r a
buffer
Free ans
Database buffer I/O Buffer
memory n - t r
cache
Response a no
Request
a s
Java Streams queue
h queue
)Large pool
i d eฺ
pool pool m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Oracle Memory Structures k i
a s yu ense
M createslicand uses memory structures for various purposes. For example,
Oracle Database
y
memory
t a nlestores program code being run, data shared among users, and private data areas for
S connected user.
each
Two basic memory structures are associated with an instance:
• The System Global Area (SGA) is a group of shared memory structures, known as SGA
components, that contain data and control information for one Oracle Database instance.
The SGA is shared by all server and background processes. Examples of data stored in the
SGA include cached data blocks and shared SQL areas.
• The Program Global Areas (PGAs) are memory regions that contain data and control
information for a server or background process. A PGA is nonshared memory created by
Oracle Database when a server or background process is started. Access to the PGA is
exclusive to the server process. Each server process and background process has its own
PGA.

Oracle Memory Structures (continued)

The SGA is the memory area that contains data and control information for the instance. The
SGA includes the following data structures:
• Database buffer cache: Caches blocks of data retrieved from the database
• Redo log buffer: Caches redo information (used for instance recovery) until it can be
written to the physical redo log files stored on the disk
• Shared pool: Caches various constructs that can be shared among users
• Large pool: Is an optional area that provides large memory allocations for certain large
processes, such as Oracle backup and recovery operations, and I/O server processes
• Java pool: Is used for all session-specific Java code and data within the Java Virtual
Machine (JVM)
• Streams pool: Is used by Oracle Streams to store information required by capture and
apply
When you start the instance by using Enterprise Manager or SQL*Plus, the amount of memory
allocated for the SGA is displayed.
a b le
f
A Program Global Area (PGA) is a memory region that contains data and control information
s er
- r an server
for each server process. An Oracle server process services a client’s requests. tEach
process has its own private PGA that is created when the server process is
n onstarted. Access to
the PGA is exclusive to that server process, and the PGA is read and
s awritten only by the
Oracle code acting on its behalf. a
) h uideฺ
m
o t buffer
G cache, the shared pool,
a ilฺcdatabase
With the dynamic SGA infrastructure, the size of the
n
the large pool, the Java pool, and the Streams
g m de without shutting down the
pool changes
t u
instance.
u k i@ is S
The Oracle database uses initialization
a e th to create and configure memory structures.
sy parameters
i (
For example, the MEMORY_TARGET us
M to parameter specifies the Oracle systemwide usable
u k e
memory, and the Oracle
a e ns tunes memory to the MEMORY_TARGET value, reducing or
sy cdatabase
yM
enlarging the SGA andliPGA components as needed.
n le
Sta

Process Architecture
• User process
– Is started when a database user or a batch process connects
to Oracle Database
• Database processes
– Server process: Connects to the Oracle instance and is
started when a user establishes a session
– Background processes: Are started when an Oracle instance
is started Instance
SGA Shared pool
ble
Library
fe r a
Database
buffer
Redo log cache
t r a ns
cache
buffer
o n
Data
-dictionary
PGA
a n cache
s
haprocesses
User
process
Server
process )
Background i d eฺ
m
o tSMON
CKPT ฺcLGWR G u PMON ARCn Others
DBWn
i l
g ma tuden
sy se th
a
(M to u
Process Architecture k i
a s yu ense
lic Database system can be categorized into two major groups:
The processesMin an Oracle
y
t a nleprocesses that run the application or Oracle tool code.
• User
S• Oracle Database processes that run the Oracle database server code. They include server
processes and background processes.
When a user runs an application program or an Oracle tool such as SQL*Plus, Oracle Database
creates a user process to run the user’s application. Oracle Database also creates a server
process to execute the commands issued by the user process. In addition, the Oracle server
also has a set of background processes for an instance that interact with each other and with
the operating system to manage the memory structures and asynchronously perform I/O to
write data to disk, and perform other required tasks.
The process structure varies for different Oracle Database configurations, depending on the
operating system and the choice of Oracle Database options. The code for connected users can
be configured as a dedicated server or a shared server.
• With dedicated server, for each user, the database application is run by a user process that
is served by a dedicated server process that executes Oracle database server code.
• A shared server eliminates the need for a dedicated server process for each connection. A
dispatcher directs multiple incoming network session requests to a pool of shared server
processes. A shared server process serves any client request.
Process Structures
Server Server Server Server Server

…Server n
processes
SGA
Shared pool
Library
Database
Redo log cache
buffer
buffer SGA
cache Data dict.
cache
ble
fe r a
ans
n - t r
CKPT RECO PMON SMON DBWn LGWR
a no
ARCn Others
s
ha ideฺ background
…Oracle
m Gu)
ฺ c o t
a il e n processes
m
g Stu d
i @ isAll rights reserved.
s y uk© 2009, Oracle.
Copyright
t h
( M a use
Process Structures uki e to
y
as licen s
Server Processes
M
Oraclen l ey creates server processes to handle the requests of user processes connected to
Database
the
a
Stinstance. In some situations when the application and Oracle Database operate on the same
computer, it is possible to combine the user process and corresponding server process into a
single process to reduce system overhead. However, when the application and Oracle Database
operate on different computers, a user process always communicates with Oracle Database
through a separate server process.
Server processes created on behalf of each user’s application can perform one or more of the
following tasks:
• Parsing and running SQL statements issued through the application
• Reading necessary data blocks from data files on disk into the shared database buffers of
the SGA, if the blocks are not already present in the SGA
• Returning results in such a way that the application can process the information
Background Processes
To maximize performance and accommodate many users, a multiprocess Oracle Database
system uses some additional Oracle Database processes called background processes. An
Oracle Database instance can have many background processes.

Process Structures (continued)

The background processes commonly seen in non-RAC non-ASM environments can include
the following:
• Database Writer process (DBWn)
• Log Writer process (LGWR)
• Checkpoint process (CKPT)
• System Monitor process (SMON)

• Process Monitor process (PMON)
• Recoverer process (RECO)
• Job Queue processes
• Archiver processes (ARCn)
• Queue Monitor processes (QMNn)
Other background processes may be found in more advanced configurations such as RAC. See
the V$BGPROCESS view for more information about the background processes.
a b le
Some background processes are created automatically when an instance is started, while others
r
are started as required.
nsfe
n - tra
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
ki this
s y u
( M a u se
y u ki se to
M as licen
le y
n
Sta

Database Storage Architecture

Control files Data files Online redo log files
ble
fe r a
Parameter file Backup files
ns
Archived redo log
files-tra
n on
s a
a
) h uideฺ
m
Password file Alerta lฺcoandentrace
ilog t G files
@ gm Stud
u
Copyright
s
a use
( M to
Oracle Database Storage
y u ki Architecture
s e
The files thatM as licaneOracle
constitute
n database are organized into the following:
l ey files: Contain data about the database itself (that is, physical database structure
• Control
n
Stainformation). These files are critical to the database. Without them, you cannot open data
files to access the data within the database.
• Data files: Contain the user or application data of the database, as well as metadata and
the data dictionary
• Online redo log files: Allow for instance recovery of the database. If the database server
crashes and does not lose any data files, then the instance can recover the database with
the information in these files.
The following additional files are important to the successful running of the database:
• Parameter file: Is used to define how the instance is configured when it starts up
• Password file: Allows sysdba/sysoper/sysasm to connect remotely to the instance
and perform administrative tasks
• Backup files: Are used for database recovery. You typically restore a backup file when a
media failure or user error has damaged or deleted the original file.
• Archived redo log files: Contain an ongoing history of the data changes (redo) that are
generated by the instance. Using these files and a backup of the database, you can recover
a lost data file. That is, archive logs enable the recovery of restored data files.

Oracle Database Storage Architecture (continued)

• Trace files: Each server and background process can write to an associated trace file.
When an internal error is detected by a process, the process dumps information about the
error to its trace file. Some of the information written to a trace file is intended for the
database administrator, whereas other information is for Oracle Support Services.
• Alert log file: These are special trace entries. The alert log of a database is a
chronological log of messages and errors. It is recommended that you review the alert log
periodically.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Logical and Physical Database Structures
Logical Physical
Database
Schema Tablespace Data file
Segment
ble
fe r a
Extent ans
n - t r
a no
Oracle data h a s ฺ
) i
OS d eblock
block m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Logical and Physical k i
u nse Structures
Database
s y
alogical e
The databaseM
y
has l i cstructures and physical structures.
t a nle
Tablespaces
S
A database is divided into logical storage units called tablespaces, which group related logical
structures together. For example, tablespaces commonly group all of an application’s objects
to simplify some administrative operations. You may have a tablespace for application data
and an additional one for application indexes.
Databases, Tablespaces, and Data Files
The relationship among databases, tablespaces, and data files is illustrated in the slide. Each
database is logically divided into one or more tablespaces. One or more data files are explicitly
created for each tablespace to physically store the data of all logical structures in a tablespace.
If it is a TEMPORARY tablespace, then instead of a data file, the tablespace has a temporary
file.

Logical and Physical Database Structures (continued)

Schemas
A schema is a collection of database objects that are owned by a database user. Schema
objects are the logical structures that directly refer to the database’s data. Schema objects
include such structures as tables, views, sequences, stored procedures, synonyms, indexes,
clusters, and database links. In general, schema objects include everything that your
application creates in the database.

Data Blocks
At the finest level of granularity, an Oracle database’s data is stored in data blocks. One data
block corresponds to a specific number of bytes of physical database space on the disk. A
database uses and allocates free database space in Oracle data blocks.
Extents
The next level of logical database space is called an extent. An extent is a specific number of
contiguous data blocks (obtained in a single allocation) that are used to store a specific type of
a b le
information.
s fer
Segments
- t r an
The level of logical database storage above an extent is called a segment. n oAnsegment is a set of
s
extents allocated for a certain logical structure. The types of segments a include the following:
a
• Data segments: Each nonclustered, non-index-organized m deaฺ data segment with
) htableuihas
o tand G partitioned tables where
a ilฺc tables,
the exception of external tables, global temporary
n
each table has one or more segments. All g m de data is stored in the extents of its
of the table’s
t u
data segment. For a partitioned table,
k s S has a data segment. Each cluster has a
i@each ipartition
u
sy table
data segment. The data of every h
intthe cluster is stored in the cluster’s data segment.
a s e
uan index segment that stores all of its data. For a
• Index segments: Each
k i (M
index has
t o
partitioned index,
a s se has an index segment.
yueachenpartition
• Undo segments:
y M lic UNDO tablespace is created per database instance that contains
One
t a nle undo segments to temporarily store undo information. The information in an

numerous
S undo segment is used to generate read-consistent database information and, during
database recovery, to roll back uncommitted transactions for users.
• Temporary segments: Temporary segments are created by the Oracle database when a
SQL statement needs a temporary work area to complete execution. When the statement
finishes execution, the temporary segment’s extents are returned to the instance for future
use. Specify a default temporary tablespace for every user or a default temporary
tablespace, which is used databasewide.
The Oracle database dynamically allocates space. When the existing extents of a segment are
full, additional extents are added. Because extents are allocated as needed, the extents of a
segment may or may not be contiguous on the disk.

Tablespaces and Data Files
• Tablespaces consist of one or more data files.

• Data files belong to only one tablespace.
ble
Data file 1 Data file 2 fe r a
ans
n - t r
a no
a s
USERS tablespace
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Tablespaces and Data k i
Files
a s yu ense
A database isM
y lic logical storage units called tablespaces, which can be used to group
divided into
le structures together. Each database is logically divided into one or more
relatednlogical
a
S t
tablespaces. One or more data files are explicitly created for each tablespace to physically
store the data of all logical structures in a tablespace.
Note: You can also create bigfile tablespaces. These tablespaces can have only a single file,
which is often very large. The file may be any size up to maximum that the row ID
architecture will permit. The maximum size is the block size for the tablespace times 2 to the
36th power, or 128 TB for a 32 KB block size. The traditional smallfile tablespaces (which are
the default) usually contain multiple data files, but the files cannot be as large. For more
information about the bigfile tablespaces, see the Database Administrator’s Guide.

SYSTEM and SYSAUX Tablespaces
• The SYSTEM and SYSAUX tablespaces are mandatory

tablespaces.
• They are created at the time of database creation.
• The SYSTEM tablespace is used for core functionality (for
example, data dictionary tables).
• The auxiliary SYSAUX tablespace is used for additional
database components (such as the Enterprise Manager
Repository). e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
k i (M e to u
SYSTEM and SYSAUXuTablespaces
asy must e n s
Each Oracle M
y
database lic contain a SYSTEM tablespace and a SYSAUX tablespace. They are
t a nle created when the database is created. The system default is to create a smallfile
automatically
S
tablespace. You can also create bigfile tablespaces, which enable the Oracle database to
manage ultralarge files.
A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is
always online when the database is open. It stores tables that support the core functionality of
the database, such as the data dictionary tables.
The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX
tablespace stores many database components, and it must be online for the correct functioning
of all database components.
Note: The SYSAUX tablespace may be taken offline to do tablespace recovery, whereas this is
not possible for SYSTEM tablespace. Neither of them may be made read-only.

Segments, Extents, and Blocks
• Segments exist within a tablespace.

• Segments are made up of a collection of extents.

• Extents are a collection of data blocks.
• Data blocks are mapped to disk blocks.
bl e
fe r a
ans
n - t r
a no
Segment Extents Data
h a s ฺ Disk
blocks ) id e blocks
o m G u
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
Segments, Extents,uand
y ki Blockss e
Database objects,
M assuchliascetables
n and indexes, are stored as segments in tablespaces. Each
segment l y
econtains one or more extents. An extent consists of contiguous data blocks, which
t a n
S that each extent can exist only in one data file. Data blocks are the smallest unit of I/O
means
in the database.
When the database requests a set of data blocks from the operating system (OS), the OS maps
this to an actual file system or disk block on the storage device. Because of this, you need not
know the physical address of any of the data in your database. This also means that a data file
can be striped or mirrored on several disks.
The size of the data block is defined by the DB_BLOCK_SIZE parameter. The default size of
8 KB is adequate for most databases. If your database supports a data warehouse application
that has large tables and indexes, then a larger block size may be beneficial.
If your database supports a transactional application where reads and writes are random, then
specifying a smaller block size may be beneficial. The maximum block size depends on your
OS.
You can have tablespaces with a nonstandard block size. For details, see the Database
Administrator’s Guide.

Database Architecture:
Summary of Structural Components
• Memory structures:
– System Global Area (SGA): Database buffer cache, redo

buffer, and various pools
– Program Global Area (PGA)
• Process structures:
– User process and server process
– Background processes: SMON, PMON, DBWn, CKPT,
LGWR, ARCn, and so on e
• Storage structures: r a bl
s fe
– Logical: Database, schema, tablespace, segment, extent, - t r an and
Oracle block n on
s a
– Physical: data files, control files, and redo
h alog files
ฺ
m ) u i de
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to of Structural Components
Database Architecture:
y u ki Summary
s e
In this lesson,M aslearned,
you l i c eatn a high level, about the structural components of Oracle
Database:
n l eymemory, process, and storage structures. More details are covered in the following
Sta
lessons.

Automatic Storage Management:

Review
• Portable and high-performance cluster file system
• Manages Oracle database files

• Data spread across disks
to balance load Application
• Integrated mirroring across
disks Database
• Solves many storage File
management challenges system
ble
Volume
ASM
fe r a
ans
manager
n - t r
o
a n system
Operating
s
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k i
Automatic Storage Management:
u nse Review
s y
a Management e (ASM) provides a vertical integration of the file system and
Automatic Storage
M l i c
l
the volume
n eymanager that is specifically built for the Oracle database files. ASM can provide
Sta
management for single SMP machines, or across multiple nodes of a cluster for Oracle Real
Application Clusters (RAC) support. A single ASM instance can provide support for many
Oracle databases simultaneously.
ASM distributes I/O load across all available resources to optimize performance while
removing the need for manual I/O tuning. ASM helps DBAs to manage a dynamic database
environment by allowing them to increase the database size without having to shut down the
database to adjust the storage allocation.
ASM can maintain redundant copies of data to provide fault tolerance, or it can be built on top
of vendor-supplied reliable storage mechanisms. ASM may use virtual raw volumes provided
in a storage area network (SAN) environment or zero-padded files on a network attached
storage (NAS) filer in addition to using local raw devices. Data management is done by
selecting the desired reliability and performance characteristics for classes of data rather than
with human interaction on a per file basis. ASM capabilities save DBAs’ time by automating
manual storage and thereby increasing their ability to manage larger databases and more of
them with increased efficiency.

Automatic Storage Management: Review (continued)

ASM divides files into allocation units (AUs) and spreads the AUs for each file evenly across
all the disks. ASM uses an index technique to track the placement of each AU. When your
storage capacity changes, ASM does not restripe all of the data, but moves an amount of data
proportional to the amount of storage added or removed to evenly redistribute the files and
maintain a balanced load across the disks. This is done while the database is up.
You can increase the speed of a rebalance operation, or lower it to reduce the impact on the
I/O subsystem. ASM provides mirroring protection without the need to purchase a third-party
Logical Volume Manager. One unique advantage of ASM is that the mirroring is applied on a
file basis, rather than on a volume basis. Therefore, the same disk group can contain a
combination of files protected by mirroring, along with those that are not protected at all.
ASM supports data files, log files, control files, archive logs, temp files, archive log files,
SPFILEs, RMAN backup sets, and other Oracle database file types. ASM supports Real
Application Clusters and eliminates the need for a Cluster Logical Volume Manager or a
Cluster File System.
ra ble
fe
a ns
o n -tr
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
ki this
s y u
( M a u se
y u ki se to
M as licen
ley
n
Sta

ASM: General Architecture

DB instance
SID=SALES
ASM RBAL
DBW0 ASMB
instance
ARB0
FG
SID=+ASM …
RBAL
ARBA
GMON
bl e
fe r a
ans
n - t r
n o
ASM disks ASM disks ASM disks ASM disks ASM disks
s a ASM disks
a
) h uideฺ
m
o t disk G group 2
ASM disk group 1
a ilฺc eASM n
@ gm Stud
u
Copyright
s
a use
( M
ASM: General Architecture
y u ki se to
To use ASM,M youasmustlistart
c ena special instance, called an ASM instance, before you start your
database l y
einstance. ASM instances do not mount databases, instead they manage the metadata
t a n
S to make ASM files available to ordinary database instances. Both ASM instances and
needed
database instances have access to some common set of disks called disk groups. Database
instances access the contents of ASM files directly, communicating with an ASM instance
only to get information about the layout of these files.
An ASM instance starts several background processes specific to ASM. One process
coordinates rebalance activity for disk groups. It is called RBAL. The second one performs the
actual rebalance AU movements. There can be many of these at a time, and they are called
ARB0, ARB1, and so forth. The GMON process, or Group Monitor, is used for partner and
status table, and node membership. An ASM instance also has some of the same background
processes as a database instance, including SMON, PMON, LGWR, DBWR, and CKPT.
Each database instance using ASM has two extra background processes called ASMB and
RBAL. RBAL performs global opens of the disks in the disk groups. At database instance
startup, ASMB connects as a foreground process to the ASM instance. Communication between
the database and the ASM instance is performed via this bridge. This includes physical file
changes such as data file creation and deletion. Over this connection, periodic messages are
exchanged to update statistics and to verify that both instances are healthy.
Creating an ASM Instance

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating an ASM Instance k i
a s yu ense
lic by running the Database Configuration Assistant (DBCA). On
You create anMASM instance
y
t a nle
the first page, select the Configure Automatic Storage Management option, and then follow
S steps. The ASM instance is created and started for you. Then you are guided through the
the
process of defining disk groups for the instance.
As part of the ASM instance creation process, the DBCA automatically creates an entry into
the oratab file. This entry is used for discovery purposes. On the Windows platform where a
services mechanism is used, the DBCA automatically creates an Oracle Service and the
appropriate registry entry to facilitate the discovery of ASM instances. In addition, you are
prompted to run the localconfig script that configures Cluster Synchronization Services
to manage the ASM instance. When an ASM instance is configured, the DBCA creates an
ASM instance parameter file and an ASM instance password file.
If you were to create an ASM-enabled database, the DBCA determines whether an ASM
instance already exists on your host. If ASM instance discovery returns an empty list, the
DBCA creates a new ASM instance.

ASM Instance Initialization Parameters

INSTANCE_TYPE = ASM
DB_UNIQUE_NAME = +ASM
ASM_POWER_LIMIT = 1
ASM_DISKSTRING = '/dev/rdsk/*s2', '/dev/rdsk/c1*'
ASM_DISKGROUPS = dgroupA, dgroupB
SPFILE = '$ORACLE_HOME/dbs/spfile+ASM.ora'
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
ASM Instance Initialization
u nsParameters
e
a s y e
An ASM instance
y lic
M is controlled by a parameter file in the same way as a regular database
t a nleParameters commonly set there include:

instance.
S• INSTANCE_TYPE should be set to ASM for ASM instances. This is the only parameter
that must be defined.
• DB_UNIQUE_NAME specifies the service provider name for which this ASM instance
manages disk groups.
• ASM_POWER_LIMIT controls the speed for a rebalance operation. Values range from 1
through 11, with 11 being the fastest. If omitted, this value defaults to 1.
ASM_DISKSTRING is an operating system–dependent value used by ASM to limit the
set of disks considered for discovery.
• ASM_DISKGROUPS is the list of names of disk groups to be mounted by an ASM
instance at startup, or when the ALTER DISKGROUP ALL MOUNT command is used.
Note: Automatic memory management (see lesson 14) is enabled by default on ASM
instances, even when the MEMORY_TARGET parameter is not explicitly set. This is the only
parameter that you need to set for complete ASM memory management. Oracle Corporation
strongly recommends that you use automatic memory management for ASM.

Starting Up an ASM Instance

$ export ORACLE_SID='+ASM'
$ sqlplus /nolog
SQL> CONNECT / AS sysasm
Connected to an idle instance.
SQL> STARTUP;
Total System Global Area 284565504 bytes
Fixed Size 1299428 bytes
ble
Variable Size 258100252 bytes
fe r a
ASM Cache 25165824 bytes ans
n - t r
ASM diskgroups mounted
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Starting Up an ASMuInstancek i (M e to u
a systartede n s
ASM instances
y M are lic similarly to database instances except that the initialization
parameter
a n le file contains the entry INSTANCE_TYPE=ASM. When this parameter is set to the
t
value
S ASM, it informs the Oracle executable that an ASM instance is starting, not a database
instance. Also, the ORACLE_SID variable must be set to the ASM instance name. When the
ASM instance starts up, the mount stage attempts to mount the disk groups specified by the
ASM_DISKGROUPS initialization parameter rather than mounting a database, as is done with
non-ASM instances.
Other STARTUP clauses have comparable interpretation for ASM instances as they do for
database instances. The list below describes how ASM interprets STARTUP command
parameters.
• FORCE: Issues a SHUTDOWN ABORT to the ASM instance before restarting it.
• MOUNT or OPEN: Mounts the disk groups specified in the ASM_DISKGROUPS
initialization parameter. This is the default if no command parameter is specified.
• NOMOUNT: Starts up the ASM instance without mounting any disk groups.
• RESTRICT: Starts up an instance in restricted mode that enables access only to users
with both the CREATE SESSION and RESTRICTED SESSION system privileges. The
RESTRICT clause can be used in combination with the MOUNT, NOMOUNT, and OPEN
clauses.

SYSASM Role
• SYSASM role to manage ASM instances avoids overlap

between DBAs and storage administrators

SQL> CONNECT / AS SYSASM
SQL> CREATE USER ossysasmusername IDENTIFIED by passwd;
SQL> GRANT SYSASM TO ossysasmusername;
SQL> CONNECT ossysasmusername / passwd AS SYSASM;
SQL> DROP USER ossysasmusername;

ble
fe r a
• For ASM instances, SYSDBA will be deprecated in thera ns
future:
– Oracle Database 11g Release 1 behaves as in n on
10g
-t
s a in ASM
– In future releases SYSDBA privileges restricted
a
h ideฺ
instances m) u o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
SYSASM Role
y u ki se to
The SYSASMM asis specifically
role l i c en intended for performing ASM administration tasks. Using the
SYSASM l y instead of the SYSDBA role improves security by separating ASM
erole
n
Sta
administration from database administration.
In Oracle Database 11g Release 1, the OS group for SYSASM and SYSDBA is the same, and
the default installation group for SYSASM is dba. In a future release, separate groups will
have to be created, and SYSDBA users will be restricted in ASM instances. Currently, as a
member of the dba group you can connect to an ASM instance using the first statement in the
slide. You can also use the combination of CREATE USER and GRANT SYSASM SQL
statements from an ASM instance to create a new SYSASM user. This is possible as long as the
name of the user is an existing OS username. These commands update the password file of
each ASM instance, and do not need the instance to be up and running. Similarly, you can
revoke the SYSASM role from a user using the REVOKE command, and you can drop a user
from the password file using the DROP USER command. The V$PWFILE_USERS view
includes a new column called SYSASM that indicates whether the user can connect with
SYSASM privileges (TRUE) or not (FALSE).
Note: In Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA,
warnings are written in the corresponding alert.log file.

Accessing an ASM Instance
As SYSASM
ASM
or SYSDBA
instance As SYSOPER
All operations Limited

operations
Disk group Disk group

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
Storage system m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Accessing an ASM u k i (M e to u
Instance
a y ens
snot
ASM instances
y M do ic a data dictionary, so the only way to connect to one is by using OS
lhave
a n le that is, SYSASM, SYSDBA, or SYSOPER. To connect remotely, a password file
authentication,
t
must
S be used. Users who connect to the ASM instance with the SYSASM or SYSDBA
privileges have administrative access to all disk groups in the system. The SYSOPER privilege
is supported in ASM instances and limits the set of allowable SQL commands to the minimum
required for basic operation of an already configured system.
The following commands are available to SYSOPER users:
• STARTUP/SHUTDOWN
• ALTER DISKGROUP MOUNT/DISMOUNT
• ALTER DISKGROUP ONLINE/OFFLINE DISK
• ALTER DISKGROUP REBALANCE
• ALTER DISKGROUP CHECK
• SELECT all V$ASM_* views
All other commands, such as CREATE DISKGROUP, ADD/DROP/RESIZE DISK, and so
on, require the SYSASM or SYSDBA privilege and are not allowed with the SYSOPER
privilege.

Using Enterprise Manager to Manage ASM Users

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using Enterprise Managerk i
u nstoeManage ASM Users
s y
a allows eyou to manage the users who access the ASM instance through
Enterprise Manager
M l i c
remote n l ey
connection (using password file authentication). These users are reserved exclusively
t a
S the ASM instance.
for
You have this functionality only when you are connected as the SYSASM user. It is hidden if
you connect as SYSDBA or SYSOPER users.
• When you click the Create button, the Create User page is displayed.
• When you click the Edit button the Edit User page is displayed.
• By clicking the Delete button, you can delete the created users.
Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.

Shutting Down an ASM Instance

Database instance A Database instance B
ASM instance ble

fe r a
ans
3
n - t r
a no
SHUTDOWN NORMAL
h a s ฺ
1 ) i1de
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Shutting Down an ASM k i Instance
a s yu ense
When you attempt
y lic down an ASM instance in the NORMAL, IMMEDIATE, or
M to shut
nle
TRANSACTIONAL
t a
modes, it succeeds only if there are no database instances connected to the
S instance. If there is at least one connected instance, you receive the following error:
ASM
ORA-15097: cannot SHUTDOWN ASM instance with connected RDBMS instance
If you perform a SHUTDOWN ABORT on the ASM instance, it shuts down, and it will require
recovery at the time of the next startup. Any connected database instances will also eventually
shut down, reporting the following error:
ORA-15064: communication failure with ASM instance
In a single–ASM instance configuration, if the ASM instance fails while disk groups are open
for update, then after the ASM instance reinitializes, it reads the disk group’s log and recovers
all transient changes. With multiple ASM instances sharing disk groups, if one ASM instance
fails, another ASM instance automatically recovers transient ASM metadata changes caused
by the failed instance. The failure of a database instance does not affect ASM instances. The
ASM instance should be started automatically whenever the host is rebooted. The ASM
instance is expected to use the automatic startup mechanism supported by the underlying
operating system. Note that file system failure usually crashes a node. As shown in the slide,
the proper way to shutdown instances that are using ASM is to first shut down any instances
that are using the ASM instance. Then the ASM instance can be shut down normally.
ASM Storage: Concepts
ASM
Database
disk group
Tablespace Data file ASM file
Segment ASM disk
File-system ble
Extent
fe r a
file Allocation unit s
or - t r an
raw device n no
Oracle a
sPhysical
block
) h a eฺ
m i d
i l ฺ co nt Gu block
g ma tude
sy se th
a
(M to u
ASM Storage: Concepts k i
a s yu ense
ASM does not
y Meliminatelicany existing database functionality. Existing databases are able to
t a nlase they always have. New files may be created as ASM files, whereas existing ones are
operate
S
administered in the old way or can be migrated to ASM.
The diagram illustrates the relationships between the various storage components inside an
Oracle database. The left and center parts of the diagram show the relationships that exist in
previous releases. The right part of the diagram shows related ASM concepts. However, these
ASM concepts are used only to describe file storage and do not replace any existing concepts
such as segments and tablespaces. With ASM, database files can now be stored as ASM files.
At the top of the new hierarchy, you can find what are called ASM disk groups. Any single
ASM file is contained in only one disk group. However, a disk group may contain files
belonging to several databases, and a single database may use storage from multiple disk
groups. As you can see, one disk group is made up of ASM disks, and each ASM disk belongs
to only one disk group. Also, ASM files are always spread across all the ASM disks in the disk
group. ASM disks are partitioned in allocation units (AUs). An AU is the smallest contiguous
disk space that ASM allocates. ASM does not allow physical blocks to be split across AUs.
When you create a disk group, you can set the ASM AU size to be between 1 MB and 64 MB
in powers of two (such as 1, 2, 4, 8, 16, 32, or 64). Note that the diagram deals only with data
files. However, ASM can be used to store other database file types.

ASM Disk Group
• Is a pool of disks managed as a logical unit

• Partitions total disk space into ASM

uniform sized units instance
• Spreads each file evenly
across all disks
• Uses coarse- or fine-grain striping
on the basis of file type
• Administers disk groups, not files bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu Disk group
i l ฺ
g ma tude
sy se th
a
(M to u
ASM Disk Groups uki
a s y ense
A disk groupM
y lic of disks managed as a logical unit. Storage is added and removed
is a collection
t a nlegroups in units of ASM disks. Every ASM disk has an ASM disk name, which is a
from disk
S common to all nodes in a cluster. The ASM disk name abstraction is required because
name
different hosts can use different names to refer to the same disk.
An ASM file begins with an extent size equal to 1 AU. As the file size increases, the extent
size also increases to 8 AU, and then to 64 AU at a predefined number of extents. Therefore,
the extent map size that defines a file can be smaller by a factor of 8 and 64 depending on the
size of the file. The initial extent size is equal to the AU size, and it increases by the 8 and 64
factors at predefined thresholds. This is automatic for newly created files after the
COMPATIBLE.ASM and COMPATIBLE.RDBMS parameters have been advanced to 11.1.
ASM striping has two primary purposes: to balance loads across all of the disks in a disk group
and to reduce I/O latency. Coarse-grained striping provides load balancing for disk groups
while fine-grained striping reduces latency for certain file types by spreading the load more
widely. To stripe data, ASM separates files into stripes and spreads data evenly across all of
the disks in a disk group. The stripes are equal in size to the effective AU. The coarse-grained
stripe size is always equal to the AU size. The fine-grained stripe size always equals 128 KB;
this provides lower I/O latency for small I/O operations such as redo log writes.

ASM Disk Groups (continued)

Fine striping breaks up medium-sized I/O operations into multiple smaller I/O operations that
execute in parallel. While the number of files and disks increase, you have to manage only a
constant number of disk groups. From a database perspective, disk groups can be specified as
the default location for files created in the database.
Note: Each disk group is self-describing, containing its own file directory and disk directory.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Failure Group
Controller 1 Controller 2 Controller 3

6
ble
a
4
3
fe r
2
ans
1
1
7
7
13
13
1
1
7
7
13
13
1
1
n
7
7
- t r
13
13
o
1 7 13 1 7 13 1 7 13
Failure group 1 Failure group 2 a

Failure
n
h a s group ฺ
3
m ) u i de
o
Disk groupฺA
a il c ent G
@ gm Stud
u
Copyright
s
a use
( M
Failure Group
y u ki se to
A failure group
M aissa setliofcedisks,
n inside one particular disk group, sharing a common resource
l ey needs to be tolerated. An example of a failure group is a string of SCSI disks
whosenfailure
Sta to a common SCSI controller. A failure of the controller leads to all the disks on its
connected
SCSI bus becoming unavailable, although each of the individual disks is still functional.
What constitutes a failure group is site specific. It is largely based upon failure modes that a
site is willing to tolerate. By default, ASM assigns each disk to its own failure group. When
creating a disk group or adding a disk to a disk group, administrators may specify their own
grouping of disks into failure groups. After failure groups are identified, ASM can optimize
file layout to reduce the unavailability of data due to the failure of a shared resource.

Disk Group Mirroring
• Mirror at extent level

• Mix primary and mirror

AUs on each disk
• External redundancy:
Defers to hardware
mirroring
• Normal redundancy:
– Two-way mirroring
ble
– At least two failure groups fe r a
ans
• High redundancy: n - t r
– Three-way mirroring a no
a s
– At least three failure groups ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Disk Group Mirroring k i
a s yu ense
ASM has three
y lic types that support different types of mirroring:
Mdisk group
t a nle redundancy: Do not provide mirroring. Use an external-redundancy disk group
• External
S if you use hardware mirroring or if you can tolerate data loss as the result of a disk failure.
Failure groups are not used with these types of disk groups.
• Normal-redundancy: Support two-way mirroring
• High-redundancy: Provide triple mirroring
ASM does not mirror disks; rather, it mirrors extents. As a result, you need only spare capacity
in your disk group. When a disk fails, ASM automatically reconstructs the contents of the
failed disk on the surviving disks in the disk group by reading the mirrored contents from the
surviving disks. This spreads the I/O hit from a disk failure across several disks.
When ASM allocates a primary AU of a file to one disk in a disk group, it allocates a mirror
copy of that AU to another disk in the disk group. Primary AUs on a given disk can have their
mirror copies on one of several partner disks in the disk group. ASM ensures that a primary
AU and its mirror copy never reside in the same failure group. If you define failure groups for
your disk group, ASM can tolerate the simultaneous failure of multiple disks in a single failure
group.

Disk Group Dynamic Rebalancing
• Automatic online
rebalance whenever
storage configuration
changes
• Moving only the
amount of data
that is proportional to
the storage added
• No need for manual
a b le
I/O tuning s fer
- t r an
• Online migration to on
new storage a n
a s
• Configurable load m ) h uideฺ
co nt G
ailฺ
on system using ASM_POWER_LIMIT
m tude
g
sy se th
a
(M to u
Disk Group Dynamic k i
Rebalancing
a s yu ense
• With ASM,
y lic process is very easy and happens without any intervention from
M the rebalance
t a nleDBA or system administrator. ASM automatically rebalances a disk group whenever
the
S disks are added or dropped. However, rebalancing will be delayed when disk groups are
dropped because of errors.
• By using index techniques to spread extents on the available disks, ASM does not need to
restripe all the data, but instead needs to move only an amount of data that is proportional
to the amount of storage added or removed to evenly redistribute the files and maintain a
balanced I/O load across the disks in a disk group.
• With the I/O balanced whenever files are allocated and whenever the storage
configuration changes, the DBA never needs to search for hot spots in a disk group and
manually move data to restore a balanced I/O load. However, because the database needs
to resync cached ASM metadata, rebalances will have less impact if done in quiet periods.
• It is more efficient to add or drop multiple disks simultaneously so that they are
rebalanced as a single operation. This avoids unnecessary movement of data. With this
technique, it is easy to achieve online migration of your data. All you need to do is add
the new disks and drop the old ones in one operation.
• You can control how much of a load the rebalance operation has on the system by setting
the ASM_POWER_LIMIT parameter. Its range of values is 1 through 11. The lower the
number, the lighter the load; a higher setting has more of a load and finishes sooner.
Managing Disk Groups

CREATE DISKGROUP
ASM DROP DISKGROUP

instance
ble
fe r a
Database
ans
instance n - t r
a no
a s
ALTER DISKGROUP ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Managing Disk Groups k i
a s yu ense
The main goal
y Mof an ASMlic instance is to manage disk groups and protect their data. ASM
t a nlealso communicate file layout to database instances. In this way, database instances
instances
S directly access files stored in disk groups.
can
There are several disk group administrative commands. They all require the SYSASM or
SYSDBA privilege and must be issued from an ASM instance.
You can add new disk groups. You can also modify existing disk groups to add new disks,
remove existing ones, and perform many other operations. You can remove existing disk
groups.

Creating and Dropping Disk Groups

CREATE DISKGROUP dgroupA NORMAL REDUNDANCY

FAILGROUP controller1 DISK
'/devices/A1' NAME diskA1 SIZE 120G FORCE,
'/devices/A2',
'/devices/A3'
FAILGROUP controller2 DISK
'/devices/B1',
'/devices/B2',
ble
'/devices/B3';
fe r a
ans
n - t r
DROP DISKGROUP dgroupA INCLUDING CONTENTS;
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating and Dropping k i
u nseGroups
Disk
s y
a disklidiscovery
e
Assume that M
y
ASM c identified the following disks in the /devices directory:
A1, A2,
a n leA3, B1, B2, and B3. Also, assume that disks A1, A2, and A3 are on a separate SCSI
S t
controller from disks B1, B2, and B3. The first example in the slide illustrates how to
configure a disk group called DGROUPA with two failure groups: CONTROLLER1 and
CONTROLLER2.
The example also uses the default redundancy characteristic, NORMAL REDUNDANCY, for the
disk group. You can optionally provide a disk name and size for the disk. If you do not supply
this information, ASM creates a default name and attempts to determine the size of the disk. If
the size cannot be determined, an error is returned. FORCE indicates that a specified disk
should be added to the specified disk group even though the disk is already formatted as a
member of an ASM disk group. Using the FORCE option for a disk that is not formatted as a
member of an ASM disk group returns an error.
As shown by the second statement in the slide, you can delete a disk group along with all its
files. To avoid accidental deletions, the INCLUDING CONTENTS option must be specified if
the disk group still contains any files besides internal ASM metadata. The disk group must be
mounted in order for it to be dropped. After ensuring that none of the disk group files are open,
the group and all its drives are removed from the disk group. Then the header of each disk is
overwritten to eliminate the ASM formatting information.
Adding Disks to Disk Groups

ALTER DISKGROUP dgroupA ADD DISK

'/dev/rdsk/c0t4d0s2' NAME A5,
'/dev/rdsk/c0t7d0s2' NAME A8;
ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';
ble
fe r a
Disk formatting
ans
n - t r
a no
a s
) h i d eฺ
Disk group rebalancing m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Adding Disks to Disk k i
Groups
a s yu ense
This exampleM
y
shows howlic to add disks to a disk group. You execute an ALTER DISKGROUP
ADD DISK
a n le command to add the disks. The first statement adds four new disks to the
S t
DGROUPA disk group.
The second statement demonstrates the interactions of discovery strings. Consider the
following configuration:
/devices/A1 is a member of disk group DGROUPA.
/devices/A4 is a candidate disk.
The second command adds A4 to the DGROUPA disk group. It ignores the other disks, even
though they match the discovery string, because they are already part of the DGROUPA disk
group. The diagram shows that, when you add a disk to a disk group, the ASM instance
ensures that the disk is addressable and usable. The disk is then formatted and rebalanced. The
rebalance process is time consuming because it moves extents from all files onto the new disk.
Note: Rebalancing does not block any database operations. The main impact that a rebalance
process has is on the I/O load on the system. The higher the power of the rebalance, the more
I/O load it puts on the system. Thus less I/O bandwidth is available for database I/Os.

ASM Disk Group Compatibility
• Compatibility of each disk group is separately controllable:

– ASM compatibility controls ASM metadata on-disk structure

– RDBMS compatibility controls minimum consumer client level
– Useful with heterogeneous environments
• Setting disk group compatibility is irreversible.
DB ASM disk ASM

ble
instance group instance
fe r a
tra ns
COMPATIBLE >= COMPATIBLE.RDBMS
<= o n -
an
COMPATIBLE.ASM <= COMPATIBLE
s
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k i
ASM Disk Group Compatibility
a s yu ense
y ic
There are twoMkinds oflcompatibility applicable to ASM disk groups; dealing with the
t a nledata structures that describe a disk group, and the capabilities of the clients
persistent
S
(consumers of disk groups). These attributes are called ASM compatibility and RDBMS
compatibility, respectively. The compatibility of each disk group is independently controllable.
This is required to enable heterogeneous environments with disk groups from both Oracle
Database 10g and Oracle Database 11g. These two compatibility settings are attributes of each
ASM disk group:
• RDBMS compatibility refers to the minimum compatible version of the RDBMS instance
that would allow the instance to mount the disk group. This compatibility dictates the
format of messages that are exchanged between the ASM and database (RDBMS)
instances. An ASM instance has the capability to support different RDBMS clients
running at different compatibility settings. The database compatible version setting of
each instance must be greater than or equal to the RDBMS compatibility of all disk
groups used by that database. Database instances are typically run from a different Oracle
home than the ASM instance. This implies that the database instance may be running a
different software version than the ASM instance. When a database instance first connects
to an ASM instance, it negotiates the highest version that they both can support.

ASM Disk Group Compatibility (continued)

The compatibility parameter setting of the database, software version of the database, and
the RDBMS compatibility setting of a disk group determine whether a database instance
can mount a given disk group.
• ASM compatibility refers to the persistent compatibility setting controlling the format of
data structures for ASM metadata on disk. The ASM compatibility level of a disk group
must always be greater than or equal to the RDBMS compatibility level of the same disk
group. ASM compatibility is concerned only with the format of the ASM metadata. The
format of the file contents is up to the database instance. For example, the ASM
compatibility of a disk group can be set to 11.0 while its RDBMS compatibility could be
10.1. This implies that the disk group can be managed only by ASM software whose
software version is 11.0 or higher, whereas any database client whose software version is
higher than or equal to 10.1 can use that disk group.
The compatibility of a disk group needs to be advanced only when there is a change to either
persistent disk structures or protocol messaging. However, advancing disk group compatibility
a b le
s fer
is an irreversible operation. You can set the disk group compatibility by using either the
CREATE DISKGROUP or ALTER DISKGROUP commands.
-tr an
on (database
Note: In addition to the disk group compatibilities, the compatible parameter
n
a to the database or ASM
compatible version) determines the features that are enabled; it applies
s
a
instance depending on the instance_type parameter. For example:
m i deฺ it to 10.1 would
) h uSetting
a i l ฺco n11gt G
preclude use of any features introduced in Oracle Database (disk online/offline, variable
extents, and so on).
g Stu m de
i @
s y uk this
( M a use
y u ki se to
M as licen
ley
n
Sta

ASM Disk Group Attributes
Name Property Values Description

au_size C 1|2|4|8|16|32|64MB Size of allocation units in the disk group
compatible.rdbms AC Valid database version Format of messages exchanged between DB

and ASM
compatible.asm AC Valid ASM instance version Format of ASM metadata structures on disk
disk_repair_time AC 0 M to 232 D Length of time before removing a disk once

OFFLINE
template.tname. A UNPROTECT|MIRROR|HIGH Redundancy of specified template
redundancy
template.tname. A COARSE|FINE Striping attribute of specified template
stripe ble
fe r a
an
C: CREATEs
n - t r
A: ALTER
CREATE DISKGROUP DATA NORMAL REDUNDANCY a no

a s
DISK '/dev/raw/raw1','/dev/raw/raw2'
) h i d eฺ
ATTRIBUTE 'compatible.asm'='11.1'; m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
ASM Disk Group Attributes k i
a s yu ense
Whenever you
y Mcreate orlicalter an ASM disk group, you have the ability to change its attributes
using n
a lenew ATTRIBUTE clause of the CREATE DISKGROUP and ALTER DISKGROUP
the
S t
commands. These attributes are briefly summarized in the table given in the slide:
• ASM enables the use of different allocation unit (AU) sizes that you specify when you
create a disk group. The AU can be 1, 2, 4, 8, 16, 32, or 64 MB in size.
• RDBMS compatibility: See the slide “ASM Disk Group Compatibility” for more
information.
• ASM compatibility: See the slide “ASM Disk Group Compatibility” for more
information.
• You can specify the DISK_REPAIR_TIME in units of minute (M), hour (H), or day (D).
If you omit the unit, then the default is H. If you omit this attribute, then the default is
3.6H. You can override this attribute with an ALTER DISKGROUP ... DISK
OFFLINE statement.
• You can also specify the redundancy attribute of the specified template.
• You can also specify the striping attribute of the specified template.
Note: For each defined disk group, you can look at all defined attributes through the
V$ASM_ATTRIBUTE fixed view.

Using Enterprise Manager to

Edit Disk Group Attributes
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Using Enterprise Manager i
u nstoeEdit Disk Group Attributes
s y
a provides e a simple way to store and retrieve environment settings related to
Enterprise Manager
M l i c
l ey
disk groups.
n
Stacan set the compatible attributes from both the create disk group page and the edit disk
You
group advanced attributes page. The disk_repair_time attribute is added to only edit the
disk group advanced attributes page.
Note: For pre-11g ASM instances, the default ASM compatibility and the client compatibility
are each 10.1. For 11g ASM instances, the default ASM compatibility is 10.1 and the database
compatibility is 10.1.

ASM Fast Mirror Resync Overview

1 ASM redundancy is used 2 Disk access failure
Secondary
Primary
extent
extent
Oracle Database 11g
ble
fe r a
ans
n - t r
a no
a s
4 Disk again accessible: h i d eฺ
)time < uDISK_REPAIR_TIME
3 Failure
o m
ilฺc ent G
Only need to resync modified extents
a
@ gm Stud
u
Copyright
s
a use
( M to
ASM Fast Mirror Resync
y u ki Overview
s e
ASM fast mirror
s csignificantly
aresync en reduces the time required to resynchronize a transient
y M l i
lea disk. When a disk goes offline following a transient failure, ASM tracks the extents
failurenof
a
t
S are modified during the outage. When the transient failure is repaired, ASM can quickly
that
resynchronize only the ASM disk extents that have been affected during the outage.
This feature assumes that the content of the affected ASM disks has not been damaged or
modified.
When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set
the DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this
attribute determines the duration of a disk outage that ASM tolerates while still being able to
resynchronize after you complete the repair.
Note: The tracking mechanism uses one bit for each modified allocation unit. This ensures that
the tracking mechanism very efficient.

Using EM to Perform Fast Mirror Resync

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using EM to Perform k i
u nMirror
Fast e Resync
s y
a l(EM), s
e when you offline an ASM disk, you are asked to confirm the
In EnterpriseMManager i c
l
operation.
n eyOn the Confirmation page, you can override the default Disk Repair Time.
Sta you can View by failure group and choose a particular failure group to offline.
Similarly,
When finished, you can online the disk using Enterprise Manager.

Miscellaneous ALTER Commands
Remove a disk from dgroupA:

ALTER DISKGROUP dgroupA DROP DISK A5;
Add and drop a disk in a single command:
ALTER DISKGROUP dgroupA

DROP DISK A6
ADD FAILGROUP fred
ble
DISK '/dev/rdsk/c0t8d0s2' NAME A9;
fe r a
ans
Cancel a disk drop operation: n - t r
a no
ALTER DISKGROUP dgroupA UNDROP DISKS;) ha
s
i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Miscellaneous ALTER k i
Commands
a s yu ense
The first statement
y M in thelicslide shows how to remove one of the disks from the DGROUPA disk
le second statement shows how you can add and drop a disk in a single command.
group.nThe
a
t
S big advantage in this case is that rebalancing is not started until the command completes.
The
The third statement shows how to cancel a disk drop operation. The UNDROP command
operates only on pending drops of disks; it has no effect on drops that have completed.
The following statement rebalances the DGROUPB disk group, if necessary:
ALTER DISKGROUP dgroupB REBALANCE POWER 5;
This command is generally not necessary because it is automatically done as disks are added,
dropped, or resized. However, it is useful if you want to use the POWER clause to override the
default speed defined by the initialization parameter ASM_POWER_LIMIT. You can change
the power level of an ongoing rebalance operation by reentering the command with a new
level. A power level of zero causes rebalancing to halt until the command is either implicitly
or explicitly reinvoked. The following statement dismounts DGROUPA:
ALTER DISKGROUP dgroupA DISMOUNT;
The MOUNT and DISMOUNT options allow you to make one or more disk groups available or
unavailable to the database instances. The ability to manually unmount and mount is useful in
a clustered ASM environment supporting a single instance, when that instance is failed over to
a different node.
ASMCMD Utility
SQL> CREATE TABLESPACE tbsasm DATAFILE '+DGROUP1' SIZE 100M;

Tablespace created.
SQL> CREATE TABLESPACE hrapps DATAFILE '+DGROUP1' SIZE 10M;

Tablespace created.
$ export ORACLE_SID=+ASM
$ asmcmd
ble
ASMCMD> ls -l DGROUP1/ORCL/DATAFILE
fe r a
Type Redund Striped Time Sys Name
ans
DATAFILE MIRROR COARSE OCT 05 21:00:00 Y
n - t r
HRAPPS.257.570923611
DATAFILE MIRROR COARSE OCT 05 21:00:00 Y no
TBSASM.256.570922917
a
a s
eฺ
ASMCMD>
) h i d
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
ASMCMD Utility k i
a s yu ense
ASMCMD isM
y lic utility that you can use to view and manipulate files and
a command-line
t a nle within ASM disk groups. ASMCMD can list the contents of disk groups, perform
directories
S
searches, create and remove directories and aliases, display space utilization, and more.
ASMCMD works with ASM files, directories, and aliases.
Every file created in ASM gets a system-generated file name, otherwise known as a fully
qualified file name. This is the same as a complete path name in a local file system. As in
other file systems, an ASM directory is a container for files, and an ASM directory can be part
of a tree structure of other directories. The fully qualified file name represents a hierarchy of
directories in which the plus sign (+) represent the root directory.
ASMCMD> ls -l +DGROUP1/ORCL/DATAFILE
Type Redund Striped Time Sys Name
DATAFILE MIRROR COARSE OCT 05 21:00:00 Y HRAPPS.257.570923611
You can create your own directories as subdirectories of the system-generated
directories using the ASMCMD mkdir command:
ASMCMD> mkdir +dgroup1/sample/mydir

ASMCMD Utility
User created directories
Templates
Disk group compatibility md_backup
Disk group name full

Disk names and failure groups
repair/remap $ asmcmd help md_restore nodg
newdg
lsdsk
ble
fe r a
ans
ASMCMD> md_backup –b /tmp/dgbackup070222 –g admdsk1 –g asmdsk2
n - t r
no
ASMCMD> md_restore –t full –g asmdsk1 –i backup_file
ASMCMD> lsdsk -k DATA *_0001
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
ASMCMD Utility (continued)k i
a s yu ense
• ASMCMD
y lic ASM metadata backup and restore functionality. This provides
M can perform
t a nle
the ability to re-create a preexisting ASM disk group with the exact same template and
S alias directory structure.
• The lsdsk command lists ASM disk information. This command can run in two modes:
connected and non-connected. In connected mode, ASMCMD uses the V$ and GV$ views
to retrieve disk information. In non-connected mode, ASMCMD scans disk headers to
retrieve disk information, using an ASM disk string to restrict the discovery set. The
connected mode is always attempted first.
• Bad block repair is a new feature that runs automatically on normal- or high-redundancy
disk groups. When a normal read from an ASM disk group fails with an I/O error, ASM
attempts to repair that block by reading from the mirror copy and write to it and by
relocating it if the copy failed to produce a good read. This whole process happens
automatically only on blocks that are read. It is possible that some blocks and extents on
an ASM disk group are seldom read. One prime example is the secondary extents. The
ASMCMD’s repair command is designed to trigger a read on these extents, so the
resulting failure in I/O can start the automatic block repair process. One can use the
ASMCMD’s repair interface if the storage array returns an error on a physical block, then
the ASMCMD repair can initiate a read on that block to trigger the repair.

ASM Scalability and Performance
• Extent size grows automatically according to file size.

• ASM support variable extents size to:

– Raise maximum possible file size
– Reduce memory utilization in shared pool
• ASM imposes the following limits:
– 63 disk groups in a storage system
– 10,000 ASM disks in a storage system
– 4 petabyte maximum storage for each ASM disk
a b le
– 40 exabyte maximum storage for each storage system sfe
r
– 1 million files for each disk group - t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
k i (M e to u
ASM Scalability anduPerformance
a syExtentse n s
ASM Variable
y M Size lic an automated feature that enables ASM to support larger file
is
t a nle improving memory usage efficiency. An ASM file begins with an extent equal to
size while
S AU. As the file size increases, the extent size also increases to 8 AU and then to 64 AU at
one
a predefined number of extents. The size of the extent map that defines a file can be smaller by
a factor of 8 and 64 depending on the file size. The initial extent size is equal to the allocation
unit size and it increases by a factor of 8 and 64 at predefined thresholds.
Fewer extent pointers are needed to describe the file and less memory is required to manage
the extent maps in the shared pool, which would have been prohibitive in large file
configurations. Extent size can vary both across files and within files.
Variable size extents also enable you to deploy Oracle databases using ASM storage that are
several hundred TB even several PB in size. The management of variable size extents is
completely automated and does not require manual administration.
However, external fragmentation may occur when a large number of non-contiguous small
data extents have been allocated and freed, and no additional contiguous large extents are
available. A defragmentation operation is integrated as part of the rebalance operation. So, as a
DBA, you always have the possibility to defragment your disk group by executing a rebalance
operation.

ASM Scalability and Performance (continued)

ASM imposes the following limits:
• 63 disk groups in a storage system
• 10,000 ASM disks in a storage system
• 4 petabyte maximum storage for each ASM disk
• 40 exabyte maximum storage for each storage system
• 1 million files for each disk group

• Maximum files sizes depending on the redundancy type of the disk groups used: 140 PB
for external redundancy (value currently greater than possible database file size), 42 PB
for normal redundancy, and 15 PB for high redundancy
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

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

• Describe the Oracle Database architecture

• Describe Automatic Storage Management (ASM)
• Set up initialization parameter files for ASM and database
instances
• Start up and shut down ASM instances
• Administer ASM disk groups
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Practice 1 Overview:
Database Architecture and ASM
This practice covers the following topics:
• Creating and starting an ASM instance

• Creating and using ASM disk groups
• Managing an ASM instance
• Dynamic disk group rebalancing
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
Configuring for Recoverability
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Invoke RMAN and set and list simple configurations

• Configure your database in ARCHIVELOG mode
• Configure multiple archive log file destinations to increase
availability
• Specify a retention policy
• Configure the Flash Recovery Area
• Describe the benefits of using the Flash Recovery Area ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Purpose of Backup and Recovery Functionality
Backup and recovery functionality is needed for the following:

• Data protection
– Media failure
– User errors
– Application errors
• Data preservation
• Data transfer
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
(M toFunctionality
Purpose of Backup and k i
Recovery
a s yu ense
You need to beM
y ic when there are problems introduced into your database. When you
able to recover
l
t a nleerrors.
take backups
application
of your database, you protect against problems such as media failure, user errors, and
Media errors cause data problems by failing at the hardware level; a bad controller
S
or disk drive can introduce either subtle or obvious errors. Users can also cause data errors, simply by
issuing commands that should not be issued. Those same types of errors can be caused by an
application with a bug.
Backup also provides for the preservation of data. You may want to create a copy of the database as
of a specifically meaningful point in time and store it for a long term. This could be for possible
future restoration, or it might be simply to meet compliance regulations.
You can also use backup and recovery tools to move data to other databases—even in other
locations. A backup of the database is an efficient way to do this: back up the database and restore it
at another location.

Typical Backup and Recovery Tasks
To be able to recover from data loss problems with minimal

down time, you should be prepared to do the following:

• Configure the database for recoverability.
• Define a backup schedule.
• Plan and test different types of failure scenarios.
• Monitor and troubleshoot the backup and recovery
environment.
• Restore data from backups. a b le
• Recover transactions to a desired point in time. s fer
an -tr
o n
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
isAll rights reserved.
s y u
Copyright
t h
( M a use
Typical Backup and Recovery
u ki seTasks to
y
asrecovery enplan is important for a database that you cannot afford to lose. The
A robust backupM and l i c
l ey the following tasks:
plan includes
n
S a
• tConfiguration: The backup and recovery environment needs to be configured for your
environment. This includes setting, for example, the destination for backups, how old a backup
should be before it is deleted, and encryption.
• Scheduling: Backups can be scheduled so that you do not have to manually start them. This is
useful, because the best time to take a backup is often during off hours.
• Testing: You should plan and carry out test scenarios where data is damaged or lost, and you
use a backup you have taken to recover. This should be a regular practice so you know you are
successfully backing up what you need to.
• Monitoring: Performing backups require resources and this can affect other operations in the
database. You should monitor backup and recovery tasks and ensure they are running efficiently.
• Restoration: When you need to rely on a backup, you have to restore data from it. This brings
the files into the database, and usually puts the state of the database into a point in the past.

Typical Backup and Recovery Tasks (continued)

• Recovery: If, after restoring files from a backup, you need to bring the database back into a
point in time closer (or equal to) the present, then you need to perform recovery. This is the
process of applying redo data to the restored data.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Oracle Backup and Recovery Solutions
These Oracle utilities and features provide the tools necessary

to maintain a recoverable system:

• Recovery Manager (RMAN)
– Incremental backups
– Block media recovery
– Unused block compression
– Binary compression
– Backup encryption e
r a bl
• Data Pump s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M Solutions u
Oracle Backup and Recovery k i t o
a s yu ense
The following M
y ic and recovery solutions:
are major lbackup
t a nlefeatures
• Recovery
major
Manager: A command-line tool for performing backup and recovery. Some of the
available when using RMAN are:
S - Incremental backups: A type of backup in which only data blocks that have changed since
the last incremental backup are written to the backup
- Block media recovery: A method of recovering specific blocks of data, as opposed to
entire tables (with Data Pump) or data files (with RMAN)
- Unused block compression: A space-saving method by which blocks that have never been
used are not written to the backup
- Binary compression: A space-saving feature in which backup files are compressed using
well-known algorithms (comparable to utilities such as zip on Linux)
- Backup encryption: A security device for protecting backups you make
• Data Pump: A command-line tool for exporting and importing table data from and to OS files

Using Recovery Manager
$ rman target /
RMAN> BACKUP DATABASE;

Starting backup at 10-JUN-07
.
.
RMAN> LIST BACKUP;
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ------- ----------- ------------ ---------------
1 Full 1.06G DISK 00:01:49 10-JUN-07
.
.
RMAN> DELETE OBSOLETE;
ble
.
fe r a
.
ans
Do you really want to delete the above objects (enter YES or NO)? YES
deleted archived log n - t r
.
a no
.
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using Recovery Manager k i
a s yu ense
Invoke RMANM
y ic system command line, and optionally provide command-line options.
at the operating
l
a nle are
The following
• ttarget: The
the most commonly used options:
connect-string for the target database
S
• catalog: The connect-string for a recovery catalog
• nocatalog: Specifies there is no recovery catalog. This is the default.
• cmdfile: The name of an input command file
• log: The name of the output message log file
The RMAN invocation shown in the slide simply connects to the local database, as the target.
Here is an example of an RMAN invocation that connects to the local database using OS
authentication, and specifies a command file to be run and a log file to receive a transcript of the
RMAN commands that belong to the session:
$ rman target / cmdfile=~/fullbu.rman log=~/fullbu.log
At the RMAN prompt, you can submit RMAN commands to manage your backup environment and
create backups in many different ways, depending on your needs. Shown in the slide are commands
to list the existing backups (LIST BACKUP) and delete any obsolete backups (DELETE
OBSOLETE). The specifics of what these and other commands do are covered throughout this course.
Note: Refer to the Oracle Database Backup and Recovery User’s Guide for more information about
how to invoke RMAN. Refer to the Oracle Database Backup and Recovery Reference for the
complete list of RMAN commands and their options.
Types of RMAN Commands
RMAN commands are of the following types:

• Stand-alone command:
– Is executed individually at the RMAN prompt
– Cannot appear as subcommands within RUN
• Job command:
– Must be within the braces of a RUN command
– Is executed as a group
Some commands can be executed as either a stand-alone or a able
job command. s fer
n tra
n -
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Types of RMAN Commands k i
a s yu ense
You can issue M
y ic of RMAN commands: stand-alone and job commands.
two basic ltypes
t a nle commands are executed at the RMAN prompt and are generally self-contained. Some of
Stand-alone
Sstand-alone commands are:
the
• CHANGE
• CONNECT
• CREATE CATALOG, RESYNC CATALOG
• CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT
Job commands are usually grouped and executed sequentially inside a command block. If any
command within the block fails, RMAN ceases processing; no further commands within the block
are executed. The effects of any already executed commands still remain, though; they are not
undone in any way.
An example of a command that can be run only as a job command is ALLOCATE CHANNEL. The
channel is allocated only for the execution of the job, so it cannot be issued as a stand-alone
command. There are some commands that can be issued either at the prompt or within a RUN
command block, such as BACKUP DATABASE. If you issue stand-alone commands, RMAN allocates
any needed channels by using the automatic channel allocation feature.
You can execute stand-alone and job commands in interactive mode or batch mode.

Job Commands: Example
Job commands appear inside a RUN command block:

RMAN> RUN
2> {
3> ALLOCATE CHANNEL c1 DEVICE TYPE DISK
4> FORMAT "/disk2/%U";
5> BACKUP AS BACKUPSET DATABASE;
6> SQL 'alter system archive log current';
7> }
ble
fe r a
ans
n - t r
Execution of entire block starts
when this line is entered. a no
h a s ฺ
)Deallocated
i d eafter
c o m G u the
ฺ
ail den t
RUN block completes
m
g Stu
Copyright
t h
( M a use
Job Commands: Example
y u ki se to
Unlike stand-alone
M ascommands,
l i c enjob commands must appear within the braces of a RUN command.
Commands
n l eyplaced inside a RUN block as shown in the slide are run as a single unit of commands.
Staconfigurations made within the run block apply within the scope of the block and override any
Any
previously made settings. The following are examples of job commands, which must appear inside a
RUN block:
• ALLOCATE CHANNEL
• SWITCH
RMAN executes the job commands inside a RUN command block sequentially. If any command
within the block fails, then RMAN ceases processing; no further commands within the block are
executed. In effect, the RUN command defines a unit of command execution. When the last command
within a RUN block completes, the Oracle database releases any server-side resources such as
input/output (I/O) buffers or I/O slave processes allocated within the block.

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.

ble
fe r a
ans
n - t r
a no
a s
h eฺ
) Dataufileidbackups
Archived Control file
backupsฺco
m G
redo log files
a il n t
g m tude
sy se th
a
(Mfor Backup u
Configuring Your Database k
u nsei t o and Recovery Operations
s y
ayour databasee in ARCHIVELOG mode, you have more recovery options after a
When you operate
y M l i c
data loss,le
including point-in-time recovery of the database or some tablespaces.
t a n
ItS
is recommended that you take advantage of the Flash Recovery Area to store as many 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 and
guaranteed restore points, require the use of a Flash Recovery Area.
Both of the features are covered in detail later in this lesson.

ARCHIVELOG Mode
bl e
fe r a
ans
Archiver
n - t r
(ARCn)
a no
a s Archived
Online redo
log files ) h i d eฺ log files
m
co nt Gu
redo
i l ฺ
g ma tude
sy se th
a
(M to u
ARCHIVELOG Mode uki
a s y ense
As modifications
y M icthe database are made, the redo data is written out to the online redo log
to datalin
a le file is specified as being written to at a given time. When it is full, the Archiver process
file. A given
ncopies
S t
(ARCn) the online log file to another location that serves as an archive of that file, which can
be preserved for as long as you need it. This provides more opportunities for recovery, because you
can save, back up, and restore all of the archive redo logs ever generated.
Because the online redo log files are reused in a circular fashion, there is a protocol for controlling
when one is allowed to be reused. In ARCHIVELOG mode, the database only begins writing to an
online redo log file if it has been archived. This ensures that every redo log file has a chance to be
archived.

Configuring ARCHIVELOG Mode
To place the database in ARCHIVELOG mode, perform the

following steps:
• Using Enterprise Manager
– Select the “ARCHIVELOG Mode” check box.
– Click Apply. The database can be set to ARCHIVELOG mode
only from the MOUNT state.
– Click Yes when asked whether you want to restart the
database.
bl e
• Using SQL commands fe r a
– Mount the database. an s
- t r
non
– Issue the ALTER DATABASE ARCHIVELOG command.
a
a s
– Open the database.
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Configuring ARCHIVELOG
y u ki Mode s e
M asin ARCHIVELOG
Placing the database
l i c en mode prevents redo logs from being overwritten until they
y
have beenlearchived.
tan Manager, do this by navigating to Availability > Recovery Settings and selecting the
InSEnterprise
ARCHIVELOG Mode check box. The database must be restarted after making this change.
To issue the SQL command to put the database in ARCHIVELOG mode, the database must be in
MOUNT mode. In order to get to the MOUNT state, the database must be in the SHUTDOWN state; if the
database is currently open, you must shut it down, and then mount it. The following shows the
commands to shut down an open database, put it in ARCHIVELOG mode, and then open it:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
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.

Configuring ARCHIVELOG Mode (continued)

In ARCHIVELOG mode, recovery is possible until the time of the last commit. Most production
databases are operated in ARCHIVELOG mode.
Note: Back up your database after switching to ARCHIVELOG mode because your database is
recoverable only from the first backup taken in that mode.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Configuring Archive Log Destinations
• Local and remote destinations:

Online redo
LOG_ARCHIVE_DEST_n Archived
log files
redo log files
Archived
redo log files
• Local-only destinations:
ble
fe r a
ans
n - t r
Online redo
LOG_ARCHIVE_DEST n o
log files s a
LOG_ARCHIVE_DUPLEX_DEST
) ha ideฺ
Archived
c o m Gu
redo log files
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Configuring Archive Log u e to
ki Destinations
y
as youliccan s
enchoose from, for specifying where archive log files are to be written:
There are two M
models
• Locall y remote destinations: Specify local and remote destinations by setting the set of
eand
a n
StLOG_ARCHIVE_DEST_n initialization parameters. There are ten of these, so n can be 1
through 10. In order to specify a local storage location, supply a local directory name for the
value of one of these variables, supplying the "LOCATION=" string. For example, to specify the
/disk3/arch directory, set one of these variables as follows:
LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk3/arch'
If you want to specify a remote location for a standby database, use the SERVICE
keyword in the value, as in the following example, where standyby1 is the network service
name for the standby database instance:
LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'
• Local-only destinations: Another option for specifying destinations supports only local disk
locations. Set the LOG_ARCHIVE_DEST and the LOG_ARCHIVE_DUPLEX_DEST parameters
to local disk directories. Thus, you can have up to two archive log file locations. For example:
LOG_ARCHIVE_DEST = '/disk1/arch'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/arch‘
Oracle recommends that you use the LOG_ARCHIVE_DEST_n method, because this allows the
most flexibility in type of destinations, and also number of destinations.

Guaranteeing Archive Log Success

1 3
Online redo
log files Standby1
2
ble
fe r a
ans
n - t r
LOG_ARCHIVE_MIN_SUCCEED_DEST = 2
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Guaranteeing ArchiveuLog k i (M t
Success o
a s y ense
If you have specified
y M more
l icthan one destination for archive log files, you should specify a minimum
number of
this t a nlethe
using
them that are required to succeed in order for the archive to be considered successful. Do
LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter. Set it to the number
S
of destinations that must succeed in receiving the archived log file. The online log file is not reused
until this number is met.
In the example in the slide, there are three destinations specified: two are local, and one is remote.
LOG_ARCHIVE_MIN_SUCCEED_DEST is set to 2, which means as long as at least two of the
destinations succeed, the online redo log file can be overwritten. The example shows that destination
1 has failed. That does not stop the database, because two of them succeeded.
You can use this parameter with either of the models described in the previous slide. If you use it
with the LOG_ARCHIVE_DEST_n model, then this parameter can have values ranging from 1
through 10. If you use it with the LOG_ARCHIVE_DEST model, then the values can be 1 or 2,
because you can specify only two destinations in that case.

Guaranteeing Archive Log Success (continued)

Specifying MANDATORY and OPTIONAL
When you define a destination, you can specify that it is a mandatory one. Do this by specifying the
MANDATORY or OPTIONAL keyword after the location specification. Here is an example:
LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk3/arch MANDATORY'
The default is OPTIONAL.
A mandatory destination is given special consideration. If any mandatory destination fails, then
Oracle Database considers the archiving of the log to have not succeeded, and the online redo log file
is not allowed to be overwritten. In this case, it ignores the LOG_ARCHIVE_MIN_SUCCEED_DEST
parameter.
Any destination specified by LOG_ARCHIVE_DEST is mandatory. Any destination declared by
LOG_ARCHIVE_DUPLEX_DEST is optional if LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 and
mandatory if LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Specifying a Backup Destination
Backups can be written to:

• Disk directory
• Tape, using Oracle Secure Backup
• Media Management Library
– Tape
– Disk or tape, using proxy copy
• Flash Recovery Area: Disk area set aside for backup and
recovery and flashback database purposes ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Specifying a Backup u k i (M e to u
Destination
ns disk directory, a Media Management Library (MML), or the
asy tolica edesignated
Backups can beMwritten
l ey Area. Specifying a disk directory or the Flash Recovery Area means that backups go
Flash Recovery
n
toS ta media. Typically, backups are regularly moved offline to tape via the media
hard-disk
management interface in order to maintain disk space availability. Any disk directory can be
specified as the destination of a backup provided that it already exists. A media management library
can be used to copy files to tape devices, or to carry out proxy copies. A proxy copy is where the
MML is requested to make a copy of a file to a disk or tape device. The MML must be able to
provide the proxy copy service for this to work.
If you set up a Flash Recovery Area, many backup and recovery tasks are simplified for you. The
Oracle database automatically names files for you, and deletes obsolete files when there is space
pressure. More information about configuring a Flash Recovery Area is provided later in this lesson.
To specify that backups are to be written to disk, use this command:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
Subsequently, when backups are made, if the FORMAT keyword is used (that specifies a disk
directory location for the backup), then the backup is written there. If there is a Flash Recovery Area
configured, then it goes there; otherwise, backups are written to a platform-specific default location.
To specify that a tape device is to be used, use this command:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;

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
Backup Recovery
window SYSDATE
bl e
– Redundancy: Establishes a fixed number of backups that fe r a
s
must be kept ran n -t
o
s an
Backup 1 Backuph2a eฺ SYSDATE
m ) i d
• Retention policies are mutually exclusive. i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Specifying a Retention k i
Policy
a s yu ense
A retention policy
y lic which
M describes backups will be kept and for how long. You can set the value of
n l e
the retention policy by using the RMAN CONFIGURE command or Enterprise Manager.
Sta Window Retention Policy
Recovery
The best practice is to establish a period of time during which it will be possible to discover logical
errors and fix the affected objects by doing a point-in-time recovery to just before the error occurred.
This period of time is called the recovery window. This policy is specified in number of days. For
each data file, there must always exist at least one backup that satisfies the following condition:
SYSDATE – backup_checkpoint_time >= recovery_window
You can use the following command syntax to configure a recovery window retention policy:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <days>
DAYS;
where <days> is the size of the recovery window.
If you are not using a recovery catalog, then 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 are using a
recovery catalog, then make sure CONTROL_FILE_RECORD_KEEP_TIME is greater than the time
period between catalog resynchronizations. Resynchronizations happen when you:
• Create a backup. In this case the synchronization is done implicitly.
• Execute the RESYNC CATALOG command
Specifying a Retention Policy (continued)

Recovery catalogs are covered in more detail in the lesson titled “Using the RMAN Recovery
Catalog.”
Redundancy Retention Policy
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 file has been backed up.
You can use the following command to reconfigure a redundancy retention policy:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY <copies>;
where <copies> is the number of copies that are required for policy satisfaction.
Disabling the Retention Policy
You may want to disable the retention policy totally. If you have a separate system, outside of
b
RMAN, that backs up your disk backups to tape, you may want to do this. If you disable the retention
a le
policy, then RMAN never considers a backup obsolete. Because RMAN does not have to decide
s fer
when to remove a backup from disk (because another utility is managing that), RMAN
- t r andoes not need
n maintained for as
to be configured for making that decision. In this case, records of each backupoare
n
long as is specified by the CONTROL_FILE_RECORD_KEEP_TIME initialization
s a parameter.
Disable the retention policy by using this command: )h a eฺ
RMAN> CONFIGURE RETENTION POLICY TO NONE; o m u id
G
lฺc ent policy that you have defined.
Note: You can specify that a backup is an exceptionatoi the retention
This is called an archival backup, which is @ gmin S
covered thetu
d
lesson titled “Using RMAN to Create
Backups.” y u ki this
a s se
( M u
y u ki se to
M as licen
n l ey
Sta

A Recovery Window
Retention Policy: Example
Log 100 Log 200 Log 300 Log 400 Log 500
Backup A Backup B Backup C
Now
ble
fe r a
Backup Obsolete Recovery window of 7 days s
- t r an
Backup Not Obsolete n no
s a
Backup B and archive logs 201 through 500 ) h a
are eฺ
required to
m u i d
o
satisfy this retention policy.
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
i ( M to
Specifying a Recovery
y u kWindow s eRetention Policy: Example
s n
a in thelicslide
The retention policy e shows that it requires the ability to recover to any time within the
last sevenle
M
y Some of the backups and logs are obsolete, because they are not needed to recover to
days.
aStime
n
tawithin the seven-day window. This retention policy is configured thus:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Given the backups and archived log files available, the only data needed to recover to a point inside
the recovery window is Backup B and logs 201 through 500. Note that Backup A is not needed
because there is a later backup (B) that is still before the recovery window. Also, Backup C is not
sufficient as the only backup to retain because it would not satisfy a need to recover to points in time
at the beginning of the recovery window. The last backup that was taken before the beginning of the
recovery window, including all logs since that backup, is what is necessary.

Using a Flash Recovery Area
• Permanent items:
– Multiplexed copies of the

current control file
– Multiplexed copies of online redo logs
• Transient items: Database
– Archived redo logs
– Data file copies
– Control file copies e
r a bl
– Control file autobackups
s fe
– Backup pieces - t r an
non
– Flashback logs a
a s
) h i d eฺ
m Gu Recovery Area
co nt Flash
i l ฺ
g ma tude
sy se th
a
(M to u
Using a Flash Recovery k i
Area
a s yu ense
The Flash Recovery
M Arealicis a unified storage location for all recovery-related files and activities in
an Oraclele y
are t a
part
nofdatabase.
the Flash
All files that are needed to completely recover a database from a media failure
Recovery Area. The recovery-related files are of two types: permanent and
S
transient. Permanent files are actively being used by the instance. Transient files are needed only in
the event of some type of recovery operation.
Permanent Items
• Control file: Depending on the setting of several initialization parameters, a copy of the control
file is created in the Flash Recovery Area location when you create a new database or control
file. For details see the “Semantics” section of the CREATE CONTROLFILE command in the
Oracle Database SQL Language Reference.
• Multiplexed copies of online redo log files: A mirrored copy from each redo log group can be
here. When you create a database, you can specify the location of the online redo log files using
the LOGFILE clause. If you do not include that clause, then the locations are set according to
the values of the following initialization parameters:
- DB_CREATE_ONLINE_LOG_DEST_n: If one or more of these variables is set, then these
are the only locations used.
- DB_CREATE_FILE_DEST: If this is set, then this is the primary file location.
- DB_RECOVERY_FILE_DEST: If this is set, in addition to DB_CREATE_FILE_DEST,
then this location is used as the mirror.

Using a Flash Recovery Area (continued)

For more details on how these variables affect the location of the online redo logs, see the LOGFILE
clause of the CREATE DATABASE statement in the Oracle Database SQL Language Reference.
Transient Items
• 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
Archiver background process creates archived redo log files in the Flash Recovery Area and in
other configured LOG_ARCHIVE_DEST_n locations. If no LOG_ARCHIVE_DEST_n
locations are defined, the default location for archived redo log files is in the Flash Recovery
Area.
• Flashback logs: Flashback logs are generated when Flashback Database is enabled.
• Control file autobackups: The default location for control file autobackups created by RMAN
and autobackups generated by the Oracle database server is the Flash Recovery Area.
• Data file copies: The BACKUP AS COPY command creates image data file copies in the Flash
Recovery Area.
• RMAN files: The Flash Recovery Area is the default location that is used by RMAN for ble
backups and restoration of the archive log content from tape for a recovery operation.fera
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Defining a Flash Recovery Area
• The Flash Recovery Area is defined by setting both of the

following initialization parameters:

– DB_RECOVERY_FILE_DEST_SIZE: Sets the disk limit
– DB_RECOVERY_FILE_DEST: Sets the location for the Flash
Recovery Area
• These parameters are dynamic.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Defining a Flash Recovery k i Area t o
a s yu ense
Use the following
y lic parameters to define
M mandatory the Flash Recovery Area:
n l e
• DB_RECOVERY_FILE_DEST_SIZE: You must define a disk limit, which is the amount of
a that the Flash Recovery Area is permitted to use. Setting a limit allows the remaining disk
Stspace
space not dedicated to the Flash Recovery Area to be used for other purposes. A basic
recommendation for the size of the disk limit is the sum of the database size, the size of
incremental backups, and the size of all archive log files that have not been copied to tape. The
minimum size of the Flash Recovery Area should be at least large enough to contain archived
redo log files that have not been copied to tape. The sizing of the Flash Recovery Area is
dependent on the backup strategy and other options that are implemented. Flashback database
set points, and multilevel incremental backups all have an effect on the size of the Flash
Recovery Area.
• DB_RECOVERY_FILE_DEST: A Flash Recovery Area specification contains a location, which
is a valid destination to create files.

Defining a Flash Recovery Area

Using Enterprise Manager
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Defining a Flash Recovery k
u nsei Area t o
s y
a Manager e Grid Control and Database Control to easily define the Flash
You can use Enterprise
M l i c
y On the Database Control home page, navigate to Availability > Recovery Settings in
RecoveryleArea.
the ta n
Backup/Recovery Settings region. You can define the Flash Recovery Area location and its size
S
on the Recovery Settings page.
You must set the size of the Flash Recovery Area when specifying its location.

Flash Recovery Area Space Management
Space 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
1 Recovery Area. disk are
Deleted.
2
3 Space pressure
4 occurs.
Warning issued ble

to user fe r a
1 ans
RMAN updates
n - t r
list of files that 2
a no
may be deleted. Backup files a s
to be deleted ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Flash Recovery Area u k i (MManagement
Space t o
a s y ense
Each time RMAN
y lica file
Mis creates in the Flash Recovery Area, the list of files that are no longer
n e
required lon disk updated. Based on the value of DB_REOVERY_FILE_DEST_SIZE, when the
taRecovery Area experiences space pressure or is low on free space because there are no files
Flash
S
that can be deleted from the Flash Recovery Area, you are warned of the danger of running out of
space. The Oracle database server and 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 allocate enough space to hold the recovery files, including backups that are waiting to be
backed up to tape. Files that are obsolete or have been backed up to tape are likely candidates for
deletion to provide free space.
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 deleted from
the Flash Recovery Area, notification is written into the alert log.
Note: When the Flash Recovery Area’s used space is at 85%, a warning alert is issued, and when
used space is at 97%, a critical alert is issued. These are internal settings and cannot be changed.
A sample alert log output follows:
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 additional 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.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Flash Recovery Area u k
Spacei (MUsaget o
a s y ense
To avoid running
y M l ic in the Flash Recovery Area, perform the following steps as needed or
out of space
e
anlRMAN to delete unnecessary files from the Flash Recovery Area.
appropriate:
•StUse
• 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.
• Change the RMAN archived log deletion policy.
• Add disk space and increase the value of the DB_RECOVERY_FILE_DEST_SIZE database
initialization parameter if you frequently run out of space.
Enterprise Manager does not report the amount of space used by the Flash Recovery Area on the disk
or the amount of space used in the Flash Recovery Area directory tree, but it does report the sizes of
the file that RMAN believes are in the directory. So do not put any files in this area that are not
managed by RMAN.
If you remove any file from this area with a tool other than RMAN, use RMAN to remove the file
entries from the catalog. 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 as follows:
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

Flash Recovery Area Space Usage (continued)

If you use a backup solution other than RMAN, you still have to use RMAN to remove the files from
the Flash Recovery Area. After the archived redo log files have been backed up and 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.
You can also use the Manage Backups page of Enterprise Manager to manage backups. On that page,
you can perform a cross-check operation and also delete expired and obsolete backups.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Monitoring the Flash Recovery Area

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Monitoring the Flash u k
Recovery to u
i (M eArea
Real-time Flash a sy cArea
Recovery e nsmetrics can be viewed through Enterprise Manager Database
li scroll down to the Related Links section and select All Metrics. Scan the
ytheMHome page,
l
Control. One
list tanclick Recovery Area.
Sand
The displayed page shows the Recovery Area Free Space (%) metric, which indicates the percentage
of the recovery that is free space. Click the percentage number to see the graph of recovery area
usage.

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
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to Area u
Benefits of Using a Flashk i Recovery
a s yu ense
Using a Flash Recovery
y M l ic for all recovery-related files simplifies the ongoing administration of
Area
t a nle
your database.
S Corporation recommends the use of the Flash Recovery Area for all recovery-related files.
Oracle

Summary

• Invoke RMAN and set and list simple configurations

• Configure your database in ARCHIVELOG mode
• Configure multiple archive log file destinations to increase
availability
• Specify a retention policy
• Configure the Flash Recovery Area
• Describe the benefits of using the Flash Recovery Area ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Configuring for Recoverability
• Placing the database in ARCHIVELOG mode

• Verifying that the Flash Recovery Area is configured
• Using RMAN to connect to the target database
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using the RMAN Recovery Catalog
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Contrast the usage of a recovery catalog with that of the

control file for the RMAN repository
• Create and configure a recovery catalog
• Register a database in the recovery catalog
• Synchronize the recovery catalog
• Use RMAN stored scripts
• Back up the recovery catalog a b le
s fer
• Create a virtual private catalog ran n -t
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

RMAN Repository Data Storage:

Comparison of Options
Control file: Recovery catalog:
• Simpler administration • Replicates control file data

• Default • Services many targets
• Stores RMAN scripts
Metadata e
Backup set list r a bl
s fe
Image copy list
- t r an
. n
no
. s a
) h a eฺ
. m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M tComparisonu
RMAN Repository Data k
u nse i
Storage: o of Options
s y
a data eis always stored in the control file of the target database. But it can also,
The RMAN repository
M l i c
l eybe stored in a separate database called a recovery catalog.
additionally,
n
AS ta catalog preserves backup information in a separate database, which is useful in the event
recovery
of a lost control file. This allows you to store a longer history of backups than what is 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 scripts, which are sequences of
RMAN commands.
If you have very simple backup management requirements, Oracle recommends that you use the
control file option rather than a recovery catalog. Having a recovery catalog means you need to
manage and back up another database. Therefore, use a recovery catalog only if you can take
advantage of the benefits it offers, such as longer backup retention.

Storing Information in the Recovery Catalog
Recovery
Manager
(RMAN)
Database structure
Archived redo logs e
Backup sets Recovery catalog r a bl
Target database
database n s fe
control file Data file copies
n - tra
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
Storing Information inuthe k i (Recovery
e Catalog
s y
ainformation n s
e about the database structure, archived redo logs, backup sets, and
RMAN propagatesM l i c
l ey into the recovery catalog from the target database’s control file after any operation
data file copies
n
a the repository, and also before certain operations.
Stupdates
that

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 ble
fe r a
• Allows you to list the data files and tablespaces that arenors
were in the target database at a given time t r a
n- no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(MCatalog u
Reasons to Use a Recovery k i t o
a s yu ense
Although you can
y M l c file as the sole repository for RMAN, it has finite space for records
use theicontrol
of backupleactivities. When you use a recovery catalog, you can store a much longer history of
n
Sta This enables you to perform a recovery that goes back further in time than the history in the
backups.
control file.
If you want to use RMAN stored scripts, you must use a recovery catalog.
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 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 for the RMAN
information in the target control file.
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 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.
The REPORT SCHEMA command lists the tablespaces and data files in the target database. If you add
the option of AT [time|scn|logseq], you can see that information at some time in the past.
You can use the AT option only if you are using a recovery catalog.

Creating the Recovery Catalog: Three Steps

ble
Configure the Create the fe r a
recovery catalog recovery catalog
Create the
t r
recovery catalog. a ns
database. owner. - on
a n
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
i ( M to Steps
Creating the Recovery
y u kCatalog:s e Three
ascatalog,
To create a recovery
M l i c n
eperform the following three steps:
y
2. t a nle the the
1. Configure
Create
database in which you want to store the recovery catalog.
recovery catalog owner.
S3. Create the recovery catalog.

Configuring the Recovery Catalog Database
• Allocate space for the recovery catalog. Consider:

– Number of databases supported by the recovery catalog

– Number of archived redo log files and backups recorded
– Use of RMAN stored scripts
• Create a tablespace for the recovery catalog, which
becomes the default tablespace for the recovery catalog
owner.
ble
fe r a
SQL> CREATE TABLESPACE rcat_ts DATAFILE SIZE 15M;
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(Catalog
Configuring the Recovery k i
u nse Database
s y
a inlicwhiche you will install the recovery catalog schema. Be sure to consider
Determine the M database
l
your backup
n eyand recovery procedures for this database. Backing up the recovery catalog is covered
Stain this lesson.
later
The amount of space required by the recovery catalog schema depends on the number of databases
monitored by the catalog. The space increases as the number of archived redo log 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 registered in the recovery catalog.

Creating the Recovery Catalog Owner
• Create the recovery catalog owner.

• Grant the RECOVERY_CATALOG_OWNER role.
SQL> CREATE USER rcowner IDENTIFIED BY rcpass a b le

2 TEMPORARY TABLESPACE temp s fer
3 DEFAULT TABLESPACE rcat_ts - t r an
4 QUOTA UNLIMITED ON rcat_ts; n on
SQL> sa
GRANT recovery_catalog_owner TO rcowner;
ha ideฺ
m Gu)
ฺ c o t
a il e n
@ gm Stud
u
Copyright
s
a use
i ( M to
Creating the Recovery
y u kCatalog s eOwner
as as lthe
Create a user toMserve i c n
erecovery catalog owner. Set the default tablespace for this user to the
tablespace
l e y
you created for the recovery catalog. Be sure to provide UNLIMITED quota on this
n
Sta for the user. After you have created the user, grant the RECOVERY_CATALOG_OWNER
tablespace
role to the user. The RECOVERY_CATALOG_OWNER role provides privileges for the owner of the
recovery catalog. The role includes the following system privileges: ALTER SESSION, CREATE
CLUSTER, CREATE DATABASE LINK, CREATE PROCEDURE, CREATE SEQUENCE, CREATE
SESSION, CREATE SYNONYM, 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.

Creating the Recovery Catalog
• Connect to the recovery catalog database as the catalog

owner:
$ rman
RMAN> CONNECT CATALOG username/password@net_service_name
• Execute the CREATE CATALOG command:
RMAN> CREATE CATALOG;

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating the Recovery k i
Catalog
u nse
After creating M a s y e use the RMAN CREATE CATALOG command to create the catalog
the catalogiowner,
l c
eydefault tablespace of the catalog owner.
tables in lthe
n
StaAs with any database, if the ORACLE_SID environment variable is set to the SID for the
Note:
recovery catalog database, then there is no need to supply the net_service_name in the
CONNECT statement.

Managing Target Database Records in the

Recovery Catalog
• Registering a target database in the recovery catalog
• Cataloging additional backup files

• Unregistering a target database from the recovery catalog
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Managing Target Database k i t o
u nse in the Recovery Catalog
Records
s y
a lice
Although mostM information is automatically propagated from the control file to the recovery catalog,
y
there are laefew operations you may need to perform to maintain target database records in the
n
Sta catalog.
recovery

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

ble
username/password@net_service_name fe r a
RMAN> REGISTER DATABASE; ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(the
Registering a Database k i
u nsRecovery
in e Catalog
s y
thearecovery
After creating M i c e
catalog, you must register the target databases in the recovery catalog. To
y l
1. t a nle RMAN
register your
Invoke
target database, perform the following steps:
and connect to the recovery catalog database and to the target database as shown
S in the following example:
% rman TARGET / CATALOG rman/rman@reccatdb
2. Ensure that the target database is mounted or open.
3. Issue the REGISTER command to register the target database in the recovery catalog:
RMAN> REGISTER DATABASE;

Using Enterprise Manager to Register a Database
To register a database with a recovery catalog, perform the

following steps in Enterprise Manager (EM):

1. Run EM against the target database, and navigate to the
Recovery Catalog Settings page.
2. Add the recovery catalog to the configuration, if not already
listed there.
3. Specify that the target database is to use the recovery
catalog chosen in the list. e
r a bl
fe ns
The EM method of registration also causes t r a
- EM to
n o n
use the recovery catalog for backup a and
recovery–related operations.) ha deฺ
s
o m u i
ilฺc ent G
a
@ gm Stud
u
Copyright
s
a use
( M to a Database
y u ki tosRegister
e
as with
To register a database
M l i c n
aerecovery catalog in EM, you must first add the recovery catalog to the
e y
t a
recovery
nlcatalog
EM configuration. Running EM on the target database, you then select that recovery catalog to be the
for the target database.
S
If you use RMAN to register the database, and do not perform the steps in the slide, then any backup
and recovery operations performed using EM will not use the recovery catalog. So, if you plan to use
EM, perform the registration steps described here even if you have executed the RMAN REGISTER
DATABASE command.

Run EM on the
target database.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(to
Using Enterprise Managerk i
u nsRegister
e a Database (continued)
s y
ahomelipage,
e navigate to Availability > Recovery Catalog Settings. Click Add
From the Database
M c
y to specify the host, port, and SID of a database with an existing recovery catalog.
Recoveryle
Catalog
n
StaIf no recovery catalogs have been added yet, you see a message to that affect in the Recovery
Note:
Catalog drop-down list. It is possible that you see several to choose from, if they have already been
added.


bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(to
Using Enterprise Manager k i
u nsRegister e a Database (continued)
s y
a the e
After you haveM
y
defined
l i crecovery catalog database, select “Use Recovery Catalog” on the
Recoveryle
t
click a n Catalog
OK, the
Setting page to register the database in the recovery catalog database. When you
database is registered with the catalog.
S

Registering a Duplicated Database
• If you duplicate a database, and attempt to register it in the

same recovery catalog, you may receive an error:

$ rman TARGET / CATALOG username/password@clone_service_name
RMAN> REGISTER DATABASE;
starting full resync of recovery catalog
full resync complete
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of register command on default channel at 08/13/2007
23:20:0 4
RMAN-20002: target database already registered in recovery catalog
bl e
• This is because the database ID (DBID) of the duplicated s fe r a
database is the same as the original database’s DBID:
- t r an
SQL> select dbid from v$database;
n no
s a
) h a eฺ
DBID
m i d
co nt Gu
----------
1157170067 i l ฺ
g ma tude
sy se th
a
(M to u
Registering a Duplicated k i Database
a s yu ense
It is common to M duplicateic
an existing database, and then proceed to register it in the same recovery
y l
a le the original database is registered. If you do this, and the database ID (DBID) still
catalog where
nthe
S t
matches original, you will receive an error saying that the database is already registered in the
catalog. There cannot be two databases with the same DBID registered in the same recovery catalog.
To correct this, you can use the DBNEWID utility to change the DBID of the duplicate database, as
described in the following slide.

Changing the DBID of a Database
Use the DBNEWID utility to change the DBID:

• TARGET is the connection string for the database to be

changed.
• Optionally, specify the NEWNAME parameter to also give the
database a new name.
• The database must be in MOUNT state.
$ nid TARGET=user/password@svc_name [DBNAME=new_dbname]

ble
fe r a
Considerations: an s
- t r
• Previous backups and archive logs are unusable.
n on
s a
a
• Database must be opened with the RESETLOGS
)h ฺ
eoption.
o m u id
• You should back up the database ilฺcafterenchanging
t G the DBID.
a
@ gm Stud
u
Copyright
s
a use
i ( M to
Changing the DBID ofuakDatabase e
y s
asutilitylictoechange
n the DBID and/or the database name for a database. This solves
Use the DBNEWIDM
l
the problem
n eywith needing to register a duplicated database in the same recovery catalog as the source
copy
S taof the database. The syntax for the utility is shown in the slide. This changes the DBID, after it
prompts you for confirmation. After you have done this, you must realize that the database must be
reopened using the RESETLOGS option, and that any backups or archive redo log files that belong
to the database are now unusable. You should take a backup of the database after this operation.
Note: If you want to change only the database name and not the DBID, then use the SETNAME
parameter. See details about this utility in the Oracle Database Utilities documentation.

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;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M tfrom u
Unregistering a Target k i
Database
u nse o the Recovery Catalog
s y
a a databasee from the recovery catalog, all RMAN repository records in the
When you unregister
M l i c
ey are lost. You can reregister the database. The recovery catalog records for that
recovery lcatalog
n
Sta are then based on the contents of the control file at the time of re-registration.
database
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.
Note: If you have used Enterprise Manager Database Control to register your database, you must use
it again to unregister your database.

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
– Data file copies e
r a bl
– Backup pieces
s fe
– Archived redo log files - t r an
n
no
s a
RMAN> CATALOG BACKUPPIECE 'file_name'; ) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
k
Cataloging AdditionaluBackupi (M eFilesto u
a sycontrol
e n s
If you have additional
y ic in thecopies,
Mcatalog lthem file data file copies, backup pieces, or archived redo log files
n l e
on disk, you can recovery catalog by using the CATALOG command. If backups
Staaged out of the control file, you can catalog them so that RMAN can use them during a restore
have
operation.
Examples of cataloging a control file, data file, archived redo log file, and backup piece follow:
RMAN> CATALOG CONTROLFILECOPY
'/disk1/controlfile_bkup/2006_01_01/control01.ctl';
RMAN> CATALOG DATAFILECOPY
'/disk1/datafile_bkup/2006_01_01/users01.dbf';
RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.log',
'/disk1/arch_logs/archive1_732.log';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
You can catalog all files in the currently enabled Flash Recovery Area as follows:
RMAN> CATALOG RECOVERY AREA NOPROMPT;
START WITH Option
Use the START WITH option to catalog all files found in the directory tree specified. Provide a
prefix that indicates the directory and possibly a file prefix to look for. You cannot use wildcards;
this is only a prefix.

Cataloging Additional Backup Files (continued)

All types of backup files that are found in the specified directory and subdirectories are catalogued.
Suppose you have several backup files in the /tmp/arch_logs directory. The following
command catalogs all of them:
RMAN> CATALOG START WITH '/tmp/arch_logs/';
Suppose you want to be sure to catalog only those files in the /tmp directory whose file names start
with the string bset. The following accomplishes that:

RMAN> CATALOG START WITH '/tmp/bset';
This command also catalogs any backup files that are found in directory trees that begin with
/tmp/bset.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Recovery Catalog Resynchronization: Concepts
Partial: Archived redo logs

Backup sets
Data file copies
Target database Recovery catalog

control file e
r a bl
s fe
- t r an
n
no
Full: s a
) h a
Partial + database structure
eฺ
Control file m i d
snapshot i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u Concepts
k i
Recovery Catalog Resynchronization:
a s yu ense
When RMAN M
y l c
performs airesynchronization, it compares the recovery catalog to either the current
t a nleofthattheistarget
control file
information
database or a backup control file and updates the recovery catalog with
missing or changed.
S
There are two types of resynchronization: partial and full. For partial resynchronization, RMAN
compares the control file to the recovery catalog and updates the recovery catalog with any metadata
concerning backups, archived redo logs, data file copies, and so on. For a full synchronization,
RMAN first creates a control file snapshot, which is simply a temporary copy of the control file. It
uses the snapshot to make the comparison to the recovery catalog. It compares and updates all the
data that a partial resynchronization does, but it also includes any database structure changes. For
example, database schema changes or new tablespaces are included in a full resynchronization.
Note: The database schema includes names and locations of data files, redo log files, archive log
files, undo segments, and other information found in the control file.
If the only changes to the control file are those records that are governed by
CONTROL_FILE_RECORD_KEEP_TIME, then a partial resynchronization is done. Otherwise, a
full resynchronization is done. A full resynchronization is also done when you issue the RESYNC
CATALOG command, which is described in the next slide.

Manually Resynchronizing the Recovery Catalog
Manually resynchronize the recovery catalog in the following

situations:
• After the recovery catalog was unavailable for RMAN to
automatically resynchronize it
• When you perform infrequent backups of your target
database
• After making changes to the physical structure of the target
database e
r a bl
s fe
RMAN> RESYNC CATALOG; - t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
(M a u
Manually Resynchronizing k
u nse i the t o
Recovery Catalog
s y
aresynchronization
e
Perform a manual
y M l i c of the recovery catalog in the following situations:
• If thelerecovery catalog was unavailable when you issued RMAN commands that cause a partial
an
Stresynchronization
• If you perform infrequent backups of your target database because the recovery catalog is not
updated automatically when a redo log switch occurs or when a redo log is archived
• After making any change to the physical structure of the target database
Note: Refer to the Backup and Recovery User’s Guide for detailed information about records that are
updated during resynchronization.

Using RMAN Stored Scripts
• Stored scripts are an alternative to command files stored on

a specific system.
• Stored scripts are available to any RMAN client that can
connect to the target database and recovery catalog.
• Two types of RMAN stored scripts:
– Local: Associated with the target database to which RMAN is
connected when the script is created
– Global: Can be executed against any database registered in le
a b
the recovery catalog er f
t r a ns
n-
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Using RMAN Stored Scripts k i
a s yu ense
You can use RMAN
y M stored
l icscripts as an alternative to command files for managing frequently used
sequencesleof RMAN commands. Unlike command files that are available only on the system on
n
Stathey are stored, a stored script is always available to any RMAN client that can connect to the
which
target database and recovery catalog.
Stored scripts can be defined as global or local. A local stored script is associated with the target
database to which RMAN is connected when the script is created, and can be executed only when
you are connected to that target database. A global stored script can be executed against any database
registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a
target database.

Creating RMAN Stored Scripts
• Creating a local script:

CREATE SCRIPT script_name

{
<RMAN commands>
}
• Creating a global script:

CREATE GLOBAL SCRIPT script_name
{
ble
<RMAN commands>
fe r a
}
ans
n - t r
• Creating a script from a text file: a no
a s
CREATE SCRIPT script_name FROM FILEm'file_name'; ) h i d eฺ
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Creating RMAN Stored k i
Scripts
u nse
Connect to theM a s y
desired target edatabase and the recovery catalog and execute the CREATE SCRIPT
l i c
commandletoycreate a stored script.
n
Sta

Executing RMAN Stored Scripts
• Executing a script:
RUN { EXECUTE SCRIPT

script_name
; }
• Executing a global script:

RUN { EXECUTE GLOBAL SCRIPT
ble
script_name
fe r a
; } ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Executing RMAN Stored k
u nseiScripts
target database e and recovery catalog, and use the EXECUTE SCRIPT command to
l i c
y script. Note that the EXECUTE SCRIPT command requires a RUN block. If an
execute ale
stored
n
Sta command in the script fails, subsequent RMAN commands in the script do not execute.
RMAN
When you execute the script, it uses the automatic channels configured at the time. Use ALLOCATE
CHANNEL commands in the script if you need to override the configured channels as shown in the
following example:
RMAN> RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;
EXECUTE SCRIPT full_backup;
}

Displaying RMAN Stored Script Information
• Displaying a script:
PRINT [GLOBAL] SCRIPT script_name;
• Sending the contents of a script to a file:

PRINT [GLOBAL] SCRIPT script_name
TO FILE 'file_name';
• Displaying the names of defined scripts:

ble
fe r a
LIST [GLOBAL] SCRIPT NAMES;
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M Informationu
Displaying RMAN Stored k
u nsei Script t o
target database e and recovery catalog and use the PRINT SCRIPT command to
l i c
ey script or write it out to a file.
display alstored
n
a LIST SCRIPT NAMES command to display the names of scripts defined in the recovery
Stthe
Use
catalog. This command displays the names of all stored scripts, both global and local, that can be
executed for the target database to which you are currently connected.

Updating and Deleting RMAN Stored Scripts
• Updating a script:
REPLACE [GLOBAL] SCRIPT script_name

{
<RMAN commands> ;
}
• Updating a script from a file:

REPLACE [GLOBAL] SCRIPT script_name
ble
FROM FILE 'file_name';
fe r a
• Deleting a script: ans
n - t r
a no
DELETE SCRIPT script_name;
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M Stored u
Updating and Deleting k i
RMAN
u nse t o Scripts
Connect to theM s
target
y
a database e and recovery catalog and use the REPLACE SCRIPT command to
l i c
l ey scripts. RMAN creates the script if it does not exist.
update stored
n
ta a stored script from the recovery catalog, connect to the catalog and a target database, and
Sdelete
To
use the DELETE SCRIPT command.

Backing Up the Recovery Catalog

Recovery
Manager
(RMAN)
Recovery catalog
ble
fe r a
ans
n - t r
a no
Recovery catalog ) ha
s
i d eฺ
control fileco m G u
i l ฺ t
g ma tuden
sy se th
a
M to u
(Catalog
Backing Up the Recovery k i
a s yu ense
The recovery catalog
M is anicOracle database, so it needs to be backed up as any database should.
y l
l e
Oracle recommends
n using RMAN to back it up and, of course, use the control file as the RMAN
Sta instead of a recovery catalog. Never store a recovery catalog containing the RMAN
repository,
repository for a database in the same database as the target database or on the same disks as the target
database. A recovery catalog is effective only if it is separated from the data that it is designed to
protect.
Configure control file autobackup so that the control file is backed up every time a backup is made of
the recovery catalog. Any time you make a backup in the target database, back up the recovery
catalog right afterward. This protects the record of the latest backup.
Below is a summary of how to configure the backup and recovery environment for your recovery
catalog:
• Run the recovery catalog in ARCHIVELOG mode.
• Set the retention policy to a REDUNDANCY value greater than one.
• Back up the recovery catalog to disk and tape.
• To make the backups, use the BACKUP DATABASE PLUS ARCHIVELOG command.
• Use the control file (NOCATALOG), not another recovery catalog, as the RMAN repository.
• Configure control file autobackup to be ON.

Re-Creating an Unrecoverable Recovery Catalog
To partially re-create the contents of a lost recovery catalog,

use the following commands:

• RESYNC CATALOG command: Updates the recovery catalog
with any RMAN repository information from the control file of
the target database or a control file copy
• CATALOG START WITH command: Recatalogs any
available backups
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M Recovery u
Re-Creating an Unrecoverablek
u nsei t o Catalog
s y
a database e is lost or damaged, and recovery of the recovery catalog database
If the recoveryM catalog
l i c
l
through the
n eynormal Oracle recovery procedures is not possible, then you must
Sta the catalog.
re-create
You can use the following commands to partially repopulate the contents of the recovery catalog:
• RESYNC CATALOG: Use this command to update the recovery catalog with any RMAN
repository information from the control file of the target database or a control file copy. Note
that any metadata from control file records that aged out of the control file is lost.
• CATALOG START WITH... : Use this command to recatalog any available backups.

Exporting and Importing the Recovery Catalog
Use the Export and Import utilities or the Data Pump utilities to:
• Move the recovery catalog from one database to another

• Create a logical backup of the RMAN recovery catalog
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(MRecovery u
Exporting and Importing k i
u nse the t o Catalog
s y
a and lImport
e to move the recovery catalog from one database to another.
You can use Export
M i c
You can
n l ey create an export of the recovery catalog to serve as a logical backup.
also
Sta the following steps to export a recovery catalog from one database and import the catalog
Perform
into a second database:
1. Use one of the Oracle Export utilities to export the catalog data from the database.
2. Create a recovery catalog user on the database you are exporting to and grant the user necessary
privileges.
3. Use the corresponding Import utility to import the catalog data into the schema created in step 2.
You should not execute the CREATE CATALOG command before or after importing the catalog into
the database. The import operation creates the catalog in the second database.
Note: The recovery catalog can be backed up and moved to another database as a transportable
tablespace by using Export and Import or Data Pump, as well as using logical methods.

Upgrading the Recovery Catalog
To upgrade the recovery catalog to the version required by the

RMAN client, use the UPGRADE CATALOG command:
UPGRADE CATALOG;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Upgrading the Recovery k iCatalog
a s yu ense
If you use a version of theic
you mustleupgrade
l recoverythecatalog
y M it by executing
that is older than that required by the RMAN client, then
UPGRADE CATALOG command.
n
StaTo install the new recovery catalog schema, the recovery catalog user must have the CREATE
Note:
TYPE privilege.
You must be connected to the catalog database, and the catalog database must be open. You do not
have to be connected to the target database.
You must enter the UPGRADE command a second time to confirm the upgrade. You receive an error
if the recovery catalog is already at a version greater than that needed by the RMAN executable.
However, RMAN permits the command to be run if the recovery catalog is current, so that the
packages can be re-created if necessary.
RMAN displays all error messages generated during the upgrade in the message log.

Dropping the Recovery Catalog
To drop the recovery catalog schema, use the DROP CATALOG

command:
DROP CATALOG;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Dropping the Recovery k i
Catalog
a s yu ense
If you no longer
y M lic CATALOG
want to maintain a recovery catalog, you can drop the recovery catalog schema from
n l e
the tablespace with the DROP command. Dropping the catalog deletes the recovery
Sta record of backups for all target databases registered in the catalog.
catalog
Note: Execute this command only at the RMAN prompt.
You must be connected to the recovery catalog database through the CATALOG command-line option
or the CONNECT CATALOG command. The catalog database must be open. You do not have to be
connected to the target database.
Enter the command twice to confirm that you want to drop the schema.

Using a Virtual Private Catalog

Virtual Owner of 1
private
catalog 1
bl e
fe r a
ans
Base
n - t r
recovery n o
catalog Virtual Owner a
s of 2ฺ
private h a
catalog 2 m ) u i de
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
i ( M to
Using a Virtual Private
y u kCatalogs e
A recovery catalog
M asis alsolicreferred
en to as a base recovery catalog. If separation of duties is a security
l
requirement
n eyin your database, then it may also be a requirement regarding the data found in your
Sta catalog. To help meet that requirement, you can create a virtual private catalog. A virtual
recovery
recovery catalog essentially separates the recovery catalog into distinct catalogs, but only virtually.
This is done with a set of views and synonyms on the base recovery catalog.
A base recovery catalog can be sliced up into virtual private catalogs that serve specific groups of
databases and users. The catalog owner creates the base catalog, and grants
RECOVERY_CATALOG_OWNER to the owner of the virtual catalog. The catalog owner can either
grant access to a registered database to the virtual catalog owner or grant REGISTER to the virtual
catalog owner. For the former, the virtual catalog owner can then connect to the catalog for a
particular target. For the latter, he or she can register a target database. After the virtual private
catalog is configured, the virtual private catalog owner uses it just like he or she would a base
recovery catalog.
This feature allows a consolidation of RMAN repositories while maintaining a separation of
responsibilities.
Note: For more information about separation of duties, refer to the Oracle Database Vault

Using a Virtual Private Catalog (continued)

The catalog owner can access all the registered database information in the catalog. The catalog
owner can also see a listing of all databases registered, using the following SQL statement:
SELECT DISTINCT db_name FROM DBINC;
The virtual catalog owner can see only those databases to which he or she has been granted access.
Note: The catalog owner or virtual catalog owner can have different usernames than the user with
privileges to perform RMAN operations on the target database. The user performing the backup
operation must have knowledge of both a username with access privileges on the recovery catalog
and a username that has been granted SYSDBA or SYSOPER on the target database. Most RMAN
operations on the target database require either SYSDBA or SYSOPER privileges.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Creating an RMAN Virtual Private Catalog
1. Create an RMAN base catalog:

RMAN> CONNECT CATALOG catowner/oracle@catdb;

RMAN> CREATE CATALOG;
2. Grant RECOVERY_CATALOG_OWNER to VPC owner:
SQL> CONNECT SYS/oracle@catdb AS SYSDBA
SQL> GRANT RECOVERY_CATALOG_OWNER to vpcowner
3. Grant REGISTER to the VPC owner: e

r a bl
RMAN> CONNECT CATALOG catowner/oracle@catdb; s fe
RAMN> GRANT REGISTER DATABASE TO vpcowner; - t r an
n n o
Or, grant CATALOG FOR DATABASE to the a
s VPCฺ owner:
h a
m ) u i de
o
ilฺ ent G
RMAN> GRANT CATALOG FOR DATABASE cprod1 TO vpcowner
a
@ gm Stud
u
Copyright
s
a use
( M toCatalog
Creating an RMAN Virtual
y u ki Private
s e
You create virtual
s cRMAN
aprivate en catalogs for groups of databases and users.
M l i
ey owner creates the base catalog.
1. The lcatalog
n
S a DBA on the catalog database creates the user that will own the virtual private catalog (VPC)
2. tThe
and grants RECOVERY_CATALOG_OWNER to the owner of the virtual catalog.
3. The catalog owner can grant access for previously registered databases to the virtual catalog
owner or grant REGISTER to the virtual catalog owner. The GRANT CATALOG command is:
GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;
The GRANT REGISTER command is:
GRANT REGISTER DATABASE TO vpcowner;
The virtual catalog owner can then connect to the catalog for a particular target or register a
target database. After the VPC is configured, the VPC owner uses it just like a (non-virtual) base
recovery catalog.

Creating an RMAN Virtual Private Catalog
4. Create a virtual catalog for 11g clients:

RMAN> CONNECT CATALOG vpcowner/oracle@catdb;

RMAN> CREATE VIRTUAL CATALOG;
Or, create a virtual catalog for pre-11g clients:

SQL> CONNECT vpcowner/oracle@catdb
SQL> exec catowner.dbms_rcvcat.create_virtual_catalog;
5. REGISTER a database that was not previously cataloged: e

r a bl
RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb; s
n fe
RAMN> REGISTER DATABASE; -tra on
6. Use the virtual catalog: a n
a s
RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb; m ) h uideฺ
o
RAMN> BACKUP DATABASE;
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M toCatalog (continued)
Creating an RMAN Virtual
y u ki Privates e
asprivate
4. Create a virtual
M l i c n
ecatalog.
y target database is an Oracle Database 11g database and the RMAN client is an 11g
ethe
- lIf
n
Sta client, you can use the RMAN command:
CREATE VIRTUAL CATALOG;
- If you plan to use an RMAN version of 10g Release 2 or earlier with this virtual catalog,
then you must execute this stored procedure:
base_catalog_owner.dbms_rcvcat.create_virtual_catalog;
5. Connect to the catalog using the VPC owner login, and use it as a normal catalog.
This feature allows a consolidation of RMAN repositories and maintains a separation of
responsibilities. The catalog owner can access all the registered database information in the
catalog. The catalog owner can see a listing of all databases registered with the SQL*Plus
command:
SELECT DISTINCT db_name FROM DBINC;
The virtual catalog owner can see only the databases that have been granted.

Summary

• Contrast the usage of a recovery catalog with that of the

control file for the RMAN repository
• Create and configure a recovery catalog
• Register a database in the recovery catalog
• Synchronize the recovery catalog
• Use RMAN stored scripts
• Back up the recovery catalog a b le
s fer
• Create a virtual private catalog ran n -t
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

Using the RMAN Recovery Catalog
• Creating a recovery catalog

• Using RMAN stored scripts
• Creating a virtual private catalog
• Backing up a recovery catalog
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
Configuring Backup Specifications
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Use Enterprise Manager to configure backup settings

• Enable control file autobackup
• Allocate channels to use in backing up
• Configure backup optimization
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Create Backups
When creating a backup using RMAN, you can specify:

• Type: Full or incremental

• Files to back up: Entire database, data files, control file,
server parameter file, archived redo log files
• Backup type: Image copy or backup set
• Proxy options: Pass on to the Media Management Library
the responsibility of copying the files
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using RMAN to Create k i
Backups
a s yu ense
A backup is a copy
y M of data
l icfrom your database that can be used to reconstruct that data. The results of
t a n e through RMAN can be either image copies or backup sets.
a backuplcreated
S performing a backup using RMAN, you can specify:
When
• The type of backup to be performed: You can perform backups of the entire database to include
every used data block in the files (a FULL backup) or incremental backups (INCREMENTAL).
If CONFIGURE CONTROLFILE AUTOBACKUP is enabled, RMAN automatically backs up the
control file and the current server parameter file after a BACKUP command is executed.
• What to backup: Valid values for a database backup are DATABASE, DATAFILE,
TABLESPACE, ARCHIVELOG, CURRENT CONTROLFILE, and SPFILE. RMAN has
additional commands that can be used to move backup files to tape.
• Whether an image copy (AS COPY) or backup set (AS BACKUPSET) is created
• The file name format and location for backup pieces (FORMAT)
• Which data files or archived redo logs should be excluded from the backup set (SKIP)
• That the input files should be deleted upon the successful creation of the backup set (DELETE
INPUT)
• Proxy options that specify how the Media Management Library (MML) is to carry out the
copying of the files. The PROXY option of the BACKUP command provides a way for you to
relieve RMAN of having to know how the media that is controlled by the MML works. This
option is covered in the lesson titled “Using RMAN to Create Backups.”

Backup Destinations
Backups can be written to:

• Disk directory
• Media Management Library
– Typically used for disaster recovery, when disk backups are
lost.
– Oracle Secure Backup provides one.
• Flash Recovery Area
– This is the disk area set aside for backup and recovery and
a b le
flashback database purposes.
s fer
– Define the location and the size. - t r an
– Files are automatically named by using Oracle n on
Managed Files.
s a
) ha asdenecessary.
– Files are automatically retained and deleted ฺ
m u i
o G
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
Backup Destinations uki e
y s
as tolica edesignated
n
Backups can beMwritten disk directory, a Media Management Library, or the Flash
Recoveryle y
Area. Specifying a disk directory or the Flash Recovery Area means that backups go to
t a n media.
hard-disk Typically, they are regularly moved offline to tape via the media management
S
interface in order to maintain disk space availability. Any disk directory 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 you. The
Oracle Database server automatically names files for you, and deletes obsolete files when there is
space pressure.
Note: See the Oracle Secure Backup Administrator’s Guide for more information about Oracle
Secure Backup.

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 a b le
– Configure automatic backups of control files s fer
- t r an
– Define the archivelog deletion policy
n on
– Specify the parallelism for a device s a
a
) h uideto ฺ
– Set the encryption and compressionmparameters be used
o
c nt G
for backups ailฺ m tude
g
sy se th
a
(M for u
Configuring Persistent k i
Settings t o RMAN
a s yu ense
To simplify ongoing
y M l icRMAN for backup and recovery, RMAN enables you to set several
use of
persistentle
configuration settings for each target database. These settings control many aspects of
t
RMAN’sa n behavior. You can save persistent configuration information such as channel parameters,
S
parallelism, and the default device type in the RMAN repository. These configuration settings are
always stored in the control file and in the recovery catalog database (if it exists).
These settings have default values, which allow you to use RMAN immediately. However, as you
develop a more advanced backup and recovery strategy, you may have to change these settings to
implement that strategy. You can use the CONFIGURE command to configure persistent settings for
RMAN backup, restore, duplication, and maintenance jobs. These settings are in effect for any
RMAN session until the configuration is cleared or changed.
Note: The configuration settings can be changed in an RMAN job (or session) just for the duration of
the job (or session) with the SET command.

Using Enterprise Manager to Configure

RMAN Settings
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(to
u nsConfigure
e RMAN Settings
s y
a Enterprise e Manager to specify the backup settings for an instance. From the
You can use Oracle
M l i c
y page, navigate to Availability > Backup Settings.
Databasele
Home
n
a Settings property page consists of three tabs:
StBackup
The
• Device: Used to set the disk and tape configuration settings, including the Media Management
Library (MML) settings
• Backup Set (shown in the slide): Used to specify parameters for backup sets and to enter host
credentials
• Policy: Used to set various backup and retention policies before you initiate a backup, 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 incremental backups.
Note: Backup settings provide the default settings for all backups taken. When creating a backup,
some of these settings can be overridden for that specific backup.

Control File Autobackups

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
ble
fe r a
ans
n - t r
a no
a s enable
Best practice: Oracle recommends that ) h you
i d eฺ
control file autobackup. m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Control File Autobackups k i
a s yu ense
To easily recover
M from theicloss of all control file copies, you should configure RMAN to take
y l
automaticlebackups of the control file. The automatic backup of the control file occurs independently
tanbackup of the current control file explicitly requested as part of your backup command. If you
ofSany
are running RMAN in NOCATALOG mode, it is highly recommended that you activate control file
autobackup. Otherwise, if you lose your control file, your database may be unrecoverable.
To configure control file autobackup, modify the backup policy for your database by using Enterprise
Manager or use the following RMAN command:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
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 start up the
database) in one of two circumstances:
• A successful backup is recorded in the RMAN repository.
• A structural change to the database affects the contents of the control file, which, therefore, must
be backed up.

Control File Autobackups (continued)

The control file autobackup file name has a default format of %F for all device types, so that RMAN
can infer 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';
Control file autobackups are stored in the Flash Recovery Area, unless otherwise specified.
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 a b le
file
r
or control file from that autobackup.
nsfe
n - tra
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
ki this
s y u
( M a u se
y u ki se to
M as licen
ley
n
Sta

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 option of the CONFIGURE command to reset

any persistent setting to its default value:
ble
RMAN> CONFIGURE BACKUP OPTIMIZATION CLEAR; fe r a
RMAN> CONFIGURE MAXSETSIZE CLEAR; t r a ns
o n -
n
RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;
a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Managing Persistent u
y ki se to
Settings
Using the RMAN s command,
aSHOW c en you can view the RMAN configuration settings. If SHOW ALL is
M l i
ey connected to a target database, only node-specific configurations and database
executedlwhen
n
Sta
configurations are displayed.
You can return to the default value for any CONFIGURE command by executing the same command
with the CLEAR option.

Configuring Devices for Backup

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
RMAN> CONFIGURE DEVICE TYPE DISK

2> BACKUP TYPE TO COMPRESSED BACKUPSET;
ble
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Configuring Devices u k
for iBackup
a s y e n se
You can configure
M a device
ic to be used by RMAN using the CONFIGURE DEVICE TYPE
y l
t a nle
command.
S
Parallelism
Parallelism is the number of streams of data that can be used to read from and write to the device.
This effectively causes that number of channels to be allocated when the device is used by RMAN.
For example, if a media manager has two tape drives available, then parallelism 2 would allow both
tape drives to be used simultaneously for BACKUP commands using that media manager. Parallelism
for the disk device type is also useful, when you want to spread out a backup over multiple disks.
Specify the parallelism to be used on the device using the PARALLELISM clause, like this:
CONFIGURE DEVICE TYPE <device> PARALLELISM <n>
where <n> is the parallelism value.
Backup Type
The output of the backup can be either a backup set or an image copy. Configure the default for a
device type using the BACKUP TYPE TO clause. Specify BACKUPSET for a backup set and COPY
for an image copy.

Configuring Devices for Backup (continued)

Compression
Specify the COMPRESSED keyword after the BACKUP TYPE TO clause to specify that backups to
this device are to be compressed. Compression results in smaller backup files.
Note: Compression can be applied to backup sets only.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

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: e
r a bl
RMAN> RUN
ns fe
t r a
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK; no
n-
s a
BACKUP DATABASE PLUS ARCHIVELOG; a
h ideฺ
} m) u o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to for Use in Backups
Configuring and Allocating
y u ki Channels
s e
Choose from the
M as licoptions
following en for configuring channels and executing backups:
n l ey automatic channels with the CONFIGURE command, and then issue the BACKUP
• Configure
a
Stcommand at the RMAN prompt or within a RUN block.
• Manually allocate channels with the ALLOCATE CHANNEL command within a RUN block, and
then issue BACKUP commands.

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.
ble
• It can be overridden with the FORCE option.
fe r a
• It is always used for RECOVERY AREA, t r a ns
o n -
DB_RECOVERY_FILE_DEST, and RECOVERY FILES n
BACKUP options. s a
ha ฺ ) i de
o m u
RMAN> CONFIGURE BACKUP OPTIMIZATION
a ilฺc ent G ON;
@ gm Stud
u
Copyright
s
a use
( M
y u ki se to
Configuring Backup Optimization
M as optimization,
If you enable backup
l i c en the BACKUP command skips backing up files when the identical
files havele y been backed up to the specified device type.
already
n
ta determines that a file is identical and it has already been backed up, then it is a candidate
IfSRMAN
to be skipped. However, RMAN performs further checking to determine whether to 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.
Refer to the Oracle Database Backup and Recovery User’s Guide for detailed information about the
criteria that RMAN uses to determine whether a file is identical and the backup optimization
algorithm.
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 optimization
is disabled.
Backup optimization is automatically enabled for the BACKUP RECOVERY AREA |
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;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Summary

• Use Enterprise Manager to configure backup settings

• Enable control file autobackup
• Allocate channels to use in backing up
• Configure backup optimization
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Configuring Backup Specifications
• Configuring RMAN persistent settings

• Configuring control file autobackup
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Create Backups
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Create image file backups

• Create a whole database backup
• Create a full database backup
• Enable fast incremental backup
• Create duplex backup sets
• Back up a backup set
a b le
• Create an archival backup for long-term retention er
s f
• Create a multisection backup
- t r an
• Create a compressed backup n on
s a
• Create an encrypted backup a
) h uideฺ
m
• Report on and maintain backupsilฺco nt G
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Creating Backup Sets

RMAN> BACKUP AS BACKUPSET

2> FORMAT '/BACKUP/df_%d_%s_%p.bus'
3> TABLESPACE hr_data;
Datafile Datafile
1 1
ble
Datafile Datafile
fe r a
2 2
ans
Datafile n - t r
Datafile
3 3 a no
a s
Tablespace ) Backup
h i d eฺ
HR_DATA m
co nt Gu set
i l ฺ
g ma tude
sy se th
a
(M to u
Creating Backup Setsuki
a s y ense
RMAN can store
y M l ic in an RMAN-exclusive format called a backup set. A backup set is a
its backups
collectionleof files called backup pieces, each of which may contain a backup of one or more database
n
Sta
files.
Note: The FORMAT parameter specifies a pattern to use in creating a file name for the backup pieces
created by this command. The FORMAT specification can also be provided through the ALLOCATE
CHANNEL and CONFIGURE commands.

Creating Image Copies

RMAN> BACKUP AS COPY DATAFILE '/ORADATA/users_01_db01.dbf';

RMAN> BACKUP AS COPY ARCHIVELOG LIKE '/arch%';
Copy of data file 3

ble
Data file 3 fe r a
Data file 3
ans
n - t r
n o
Copy of a
archived log
a s
Archived Archived m)
h i d eฺ
log file l ฺ
log ifile co nt Gu
g ma tude
sy se th
a
(M to u
Creating Image Copies k i
a s yu ense
An image copyM
y l c aASsingle
is a cloneiof data file, archived redo log, or control file. An image copy can
be created
n l ewith the BACKUP COPY command or with an operating system command. When you
tathe image copy with the RMAN BACKUP AS COPY command, the server session validates the
create
S
blocks in the file and records the copy information in the control file.
An image copy has the following characteristics:
• An image copy can be written only to disk. When large files are being considered, copying may
take a long time, but restoration time is reduced considerably because the copy is available on
the disk.
• If files are stored on disk, they can be used immediately by using the SWITCH command 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 Oracle
database process copies the file and performs additional actions such as checking for corrupt
blocks and registering the copy in the control file. To speed up the process of copying, you can
use the NOCHECKSUM parameter. By default, RMAN computes a checksum for each block
backed up, and stores it with the backup. When the backup is restored, the checksum is verified.
For more information about the NOCHECKSUM option of the BACKUP command, see the Oracle
Database Backup and Recovery Reference.

Creating Image Copies (continued)

• An 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.
The example in the slide creates the following image copies:
• A copy of the /ORADATA/users01_db01.dbf data file
• A copy of the archived redo log files
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Creating a Whole Database Backup

RMAN> BACKUP DATABASE

PLUS ARCHIVELOG;
ble
fe r a
ans
Control n - t r
Archived log Data file file
a noSPFILE
a s
file copies copies
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(MBackup u
Creating a Whole Database k i t o
a s yu ense
A whole databaseM backupic can be either backup sets or image copies of the entire set of data files and
y l
e the control file. You can optionally include the server parameter file (SPFILE) and
nlredo
must include
t a
archived
S log files. Using Recovery Manager (RMAN) to make an image copy of all the database
files simply requires mounting or opening the database, starting RMAN, and entering the BACKUP
command shown in the slide. Optionally, you can supply the DELETE INPUT option when backing
up archivelog files. That causes RMAN to remove the archivelog files after backing them up. This is
useful especially if you are not using a Flash Recovery Area, which would perform space
management for you, deleting files when space pressure grows. In that case, the command in the
slide would look like this:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
You must have issued the following CONFIGURE commands to make the backup as described
previously:
• CONFIGURE DEFAULT DEVICE TYPE TO disk;
• CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
• CONFIGURE CONTROLFILE AUTOBACKUP ON;
You can also create a backup (either a backup set or image copies) of previous image copies of all
data files and control files in the database by using the following command:
RMAN> BACKUP COPY OF DATABASE;

Creating a Whole Database Backup (continued)

By default, RMAN executes each BACKUP command serially. However, you can parallelize the copy
operation by:
• 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
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Saving Backup Space with

Unused Block Compression
The following blocks may be
skipped during certain types of

backup operations:
Unused
• Unallocated blocks: These are
above the data file’s high-water
mark (HWM). Allocated
HWM
• Unused blocks: These are
blocks that have been allocated Unallocated e
but no longer belong to a r a bl
s fe
segment.
- t r an
Data file n
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a u
Saving Backup Spaceuwith k i (M
Unused
e t o Block Compression
s y
a of backups n s
e occur, RMAN is able to skip some blocks. Unallocated blocks may be
When certain types
M l i c
ey are those that have not been allocated; they are above the HWM. Also, some allocated
skipped. lThey
n
Sta that no longer belong to a segment (are not in use) may be skipped, provided the following is
blocks
true:
• There are no guaranteed restore points defined.
• The data file contains data only for locally managed tablespaces.
• The data file is being backed up to a backup set as part of a full backup or a level 0 incremental.
These backup types are covered in the following slides.
• The backup is going to disk or Oracle Secure Backup is the media manager.

RMAN Backup Types
• A full backup contains all used data Full, or "level 0

incremental backup"
file 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 a b le
backup. s fer
-
Differentialt r an
• A differential level 1 incremental
n onbackup
incremental backup contains s a
a
) h uideฺ
only blocks modified since the m
co nt G
last incremental backup. ailฺ m tude
g
sy se th
a
(M to u
RMAN Backup Typesuki
a s y ense
Full Backups M
y lic
l e
A full backup
n is different from a whole database backup. A full data file backup is a backup that
t a
S every used data block in the file. RMAN copies all blocks into the backup set or image
includes
copy, skipping only those data file blocks that have never been used. For a full image copy, 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
An incremental backup is either a level 0 backup, which includes every block in the data files except
blocks that have never been used, or a level 1 backup, which includes only those blocks that have
been changed since a previous backup was taken. A level 0 incremental backup is 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.
Incremental backups are specified using the INCREMENTAL keyword of the BACKUP command.
You specify INCREMENTAL LEVEL [0 | 1].

RMAN Backup Types (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 data files to backup
sets, even for full backups.
a
A full backup has no effect on subsequent incremental backups, and is not considered part of ranyble
s
incremental backup strategy, although a full image copy backup can be incrementally updated
n fe by
applying incremental backups with the RECOVER command. This is covered in the - a titled
trlesson
“Using RMAN to Perform Recovery.” no n
a
s of a database
h a
Note: It is possible to perform any type of backup (full or incremental)
) Note ualso e ฺ that is in
NOARCHIVELOG mode—if, of course, the database is not open.
o m id that recovery is limited to
the time of the last backup. The database can be recovered
i G
lฺc to ethenlast
t committed transaction only
a
when the database is in ARCHIVELOG mode. m
@ g St ud
i
uk this
s y
a use
( M
y u ki se to
M as licen
le y
n
Sta

Fast Incremental Backup
Implemented by block change tracking, which:

• Maintains a record of what blocks have changed since the

last backup
• Writes this record to a file, as redo is generated
• Is automatically accessed when a backup is done, making
the backup run faster
ble
List of changed
fe r a
1011001010110 Change s
CTWR
blocks
0001110100101 t
tracking
- r an
Redo 1010101110011 on
nfile
generation s a
SGA a
) h uideRedoฺ log
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Fast Incremental Backup
y u ki se to
The goal of anM as licbackup
incremental en is to back up only those data blocks that have changed since a
ey You can use RMAN to create incremental backups of data files, tablespaces, or the
previous lbackup.
n
Stadatabase. When making an incremental backup, RMAN scans each block of the data files to
whole
see which have changed since the last backup. That makes the backup smaller because only changed
blocks are backed up. It also makes recovery faster because fewer blocks need to be restored.
You can perform fast incremental backup by enabling block change tracking. Block change tracking
writes to a file the physical address of each block that is changed. When it is time to perform the
incremental backup, RMAN can look at the block change tracking file, and back up only those
blocks referenced there; it does not have to scan every block to see if it has changed since the last
backup. This makes the incremental backup faster.
The maintenance of the tracking file is fully automatic and does not require your intervention. The
size of the block change tracking file is proportional to the:
• Database size, in bytes
• Number of enabled threads in a RAC environment
• 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

ble
fe r a
ans
ALTER DATABASE n - t r
{ENABLE|DISABLE} BLOCK CHANGE TRACKING a no
[USING FILE '...'] has i )
d eฺ
o m
u
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Enabling Fast Incremental
y u ki Backups e
You enable block
s tracking
achange c en from the Database Control home page. Navigate to Availability >
M l i
l ey > Policy. You do not need to set the block change tracking file destination if the
Backup Settings
n
Sta
DB_CREATE_FILE_DEST initialization parameter is set because the file is created as an Oracle
Managed File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however, specify the
name of the block change tracking file, placing it in any location you choose.
You can also enable or disable this feature by using an ALTER DATABASE command. If the 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 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 refer to the new
location. You can use the following syntax to change the location of the block change tracking file:
ALTER DATABASE RENAME FILE '...' TO '...';
Note: RMAN does not support backup and recovery of the block change tracking file. For this
reason, you should not place it in the Flashback Recovery Area.

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,
a b le
5 avg(blocks)
s fer
5 FROM v$backup_datafile
- t r an
6 WHERE used_change_tracking = 'YES'non
incremental_level > 0 has
a
7 AND
) i d eฺ
8 GROUP BY file#; co m Gu
a ilฺ ent
@ gm Stud
u
Copyright
s
a use
( M to
Monitoring Block Change
y u ki Tracking
s e
The output of the s cen
aV$BLOCK_CHANGE_TRACKING view shows where the block change tracking
y M lofi block change tracking (ENABLED/DISABLED),
n l e
file is located, the status and the size (in bytes) of
the ta
Sfile.
The query on the V$BACKUP_DATAFILE view shows how effective the block change 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 data file during an incremental backup. You can
reduce this ratio by decreasing the time between the incremental backups.
A sample formatted output from the V$BACKUP_DATAFILE query is shown below:
FILE# BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
----- -------------- ----------- ------------------- ----------------
1 56320 4480 7 462
2 3840 2688 70 2408
3 49920 16768 33 4457
4 640 64 10 1
5 19200 256 1 91

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

• CONFIGURE ... BACKUP COPIES

• BACKUP...COPIES
Data file Data file

1 1 Data file
1
Data file
Data file Data file e
2
2
2 r a bl
Data file s fe
Data file 3 Data file
- t r an
3
Backup set 3
o
nset n
Tablespace Backup
a
copy 1 s 2ฺ
hacopy
HR_DATA e ) id
o m G u
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
Creating Duplexed Backup
y u ki Sets s e
RMAN can make M aupsto four
l i c n of a backup set simultaneously, each an exact duplicate of the
ecopies
others. Ale y of a backup set is a copy of each backup piece in the backup set, with each copy
copy
n
Sta a unique copy number (for example, 0tcm8u2s_1_1 and 0tcm8u2s_1_2).
getting
In most cases, the easiest method of duplexing backup sets is to use BACKUP...COPIES or
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. For sbt
channels, if you use a media manager that supports Version 2 of the SBT API, then the media
manager automatically puts each copy onto a separate medium (for example, a separate tape).
Note: The System Backup to Tape (SBT) API is the interface defined for Media Management
Library (MML) developers, so that they can provide MMLs that communicate with RMAN.
Note that it is not possible to duplex backup sets to the Flash Recovery Area, and that duplexing
applies only to backup sets, not image copies. You receive an error if you specify the BACKUP...
COPIES option when creating image copy backups. The CONFIGURE...BACKUP COPIES setting
is ignored for image copy backups.
Duplexed backup sets are typically used for tape backups.

Creating Duplexed Backup Sets Using

CONFIGURE BACKUP COPIES
Two copies of the

backup are made to
two different tapes.
RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES

2> FOR DEVICE TYPE sbt TO 2;
RMAN> CONFIGURE DATAFILE BACKUP COPIES
2> FOR DEVICE TYPE sbt TO 2;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG; a b le
r
RMAN> BACKUP DEVICE TYPE DISK AS COPY DATABASE;nsfe
n - tra
n o
Not affected by the
s a
COPIES configuration
) h a eฺ
m i d
co nt Gu
setting. Only one
copy is made on disk.
i l ฺ
g ma tude
sy se th
(M a u
Creating Duplexed Backup k
u nsei Sets t o
Using CONFIGURE BACKUP COPIES
Use the CONFIGURE s
a ...y eBACKUP COPIES command to specify the number of identical backup
M l i c
l eywant to create on the specified device type. This setting applies to all backups except
sets that you
n
ta file autobackups (because the autobackup of a control file always produces one copy) and
control
S
backup sets when backed up with the BACKUP BACKUPSET command.
Note: You must have automatic channels configured.
To create a duplexed backup set with CONFIGURE BACKUP COPIES, perform the following steps:
1. Configure the number of copies on the desired device type for data files and archived redo log
files.
2. Execute the BACKUP command.
3. Issue a LIST BACKUP command to verify your backup.
Note: The last BACKUP command is not affected by the COPIES configuration setting. It
creates a single copy to disk.

Creating Duplexed Backup Sets Using

BACKUP COPIES
RMAN> BACKUP AS BACKUPSET DEVICE TYPE sbt

2> COPIES 2
3> INCREMENTAL LEVEL 0
4> DATABASE;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Creating Duplexed Backup k i
u nse Sets t o
Using BACKUP COPIES
You can use the s y
a liccommand
e with the COPIES option to override other COPIES or DUPLEX
y M BACKUP
t a nlecreate duplexed backup sets.

settings to
Sduplex a backup with BACKUP COPIES, perform the following steps:
To
1. Specify the number of identical copies with the COPIES option of the BACKUP command.
2. Issue a LIST BACKUP command to verify your backup.

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 ble
3 fe r a
Datafile ans
3 Archived n - t r
redo logs a no
Archived
a s
redo logs ) h i d eฺ
Backuposets Gu m
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
Creating Backups of Backup
y u ki sSets e
as liBACKUPSET
Use the RMANMBACKUP c en command to back up previously created backup sets. Only
l e
backup sets y
that were created on device type DISK can be backed up using RMAN. The backup sets
n
Stbea backed up to any available device type.
can
The BACKUP BACKUPSET command uses the default disk channel to copy backup sets from disk to
disk. To back up from disk to tape, you must either configure or manually allocate a nondisk channel.

Backing Up Read-Only Tablespaces
Considerations for backing up read-only tablespaces:

• Backup optimization causes RMAN to back up read-only

tablespaces only when there does not exist a backup that
satisfies the retention policy.
• If you change the tablespace to read/write, back it up
immediately.
• You can use the SKIP READONLY option of the RMAN
BACKUP command to skip read-only tablespaces or data e
files. r a bl
s fe
- t r an
n
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Backing Up Read-Only k i
Tablespaces
a s yu ense
Because read-only
as you dole
lic areYou
tablespaces
y M tablespaces.
read/write
not being written to, there is no need to continually back them up
can use the SKIP READONLY option of the BACKUP
n
Sta to let RMAN know to not back up read-only tablespaces.
command

Archival Backups: Concepts
Archival backup
Log 250 Log 900
Backup A Backup B Backup S
Now
ble
End of Q1 fe r a
Recovery window of 7 days
s
tra n
o n -
Log nnn and Backup s an
Not needed for retention policy
) ha ideฺ
om tfor
BackuplฺcNeeded G u
retention policy
i
g ma tuden
sy se th
a
(M to u
Archival Backups: Concepts k i
a s yu ense
If you need to M preserve anic
online backup for a specified amount of time, RMAN normally assumes
y l
t a
satisfy
nthislewant
you might to perform point-in-time recovery for any time since that backup to the present. To
scenario, RMAN keeps the archived logs for that time period. However, you may have a
S
requirement to simply keep the specific backup (and what is necessary to keep it consistent and
recoverable) for a specified amount of time—for example, for two years. You do not have the
intention of recovering to a point in time since that backup, but you just want to be able to recover to
the exact time of the backup, and no later. You also want to maintain a retention policy that keeps
your backup area free of clutter, so making it reach back two years is not acceptable. This is a
common need, when meeting business or legal requirements for data retention.
An archival backup solves this problem. If you mark a backup as an archival backup, that attribute
overrides any configured retention policy for the purpose of this backup. You can retain archival
backups such that they are either considered obsolete only after a specific time that you specify, or
never considered obsolete. If you want to specify the latter, you need to use a recovery catalog.
The KEEP clause creates an archival backup that is a snapshot of the database at a point in time.
The only redo logs that are kept are those required to restore this backup to a consistent state. The
RESTORE POINT clause issued after the backup is completed determines the number of redo logs
that are kept (enough to restore the backup to the RESTORE POINT time).

Archival Backups: Concepts (continued)

An archival backup also guarantees that all of the files needed to restore the backup are included.
RMAN includes the data files, archived log files (only those needed to recover an online backup),
and the relevant autobackup files. All these files must go to the same media family (or group of
tapes).
You can also specify a restore point to be created, which has the same SCN as the archival backup.
That essentially gives a meaningful name to the point of time the backup was made.
After an archival backup is created, it is retained for as long as specified. Even if you have a much
smaller retention window and run the DELETE OBSOLETE command, the archival backup remains.
This backup is a snapshot of the database at a point in time, and can be used to restore the database to
another host for testing purposes, for example.
Note: Archival backups cannot be written to the Flash Recovery Area. So if you have one, you must
provide a FORMAT clause to specify a different location.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Creating Archival Backups with EM

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Creating Archival Backups k i with t
EM o
a s yu ense
To create an archival
y M l ic using Enterprise Manager, perform the following steps:
backup
2. t a nleAvailability
1. Select
Follow the steps of
> Schedule Backup > Schedule Customized Backup.
the Schedule Customized Backup wizard until you are on the Settings page.
S3. Click Override Current Settings and then the Policy tab. In the Override Retention Policy
section, you can select to keep a backup for a specified number of days. A restore point is
generated based on the backup job name. You probably also want to specify a different
destination for the backup files; to do this, use the Device tab.

Creating Archival Backups with RMAN
When the database is in the OPEN state, specifying the KEEP

clause causes both data file and archive log backup sets to be
included.
KEEP {FOREVER | UNTIL TIME [=] ' date_string '}
[RESTORE POINT rsname]
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
(M a u
Creating Archival Backups k i with t o
RMAN
a s yu ense
Use the following
y M l c{FOREVER|UNTIL
syntax ito create an archival backup using RMAN:
n l e
BACKUP ... KEEP TIME 'SYSDATE + <n>'} RESTORE POINT
Sta
<restore_point_name>
The UNTIL TIME clause enables you to specify when the archival backup is no longer immune to
the retention policy. You can optionally specify FOREVER, meaning that the backup is an archival
backup until you take some other action to change that.
Optionally, use the RESTORE POINT clause to specify the name of a restore point to be associated
with this backup.

Managing Archival Database Backups

1 Archiving a database backup:

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman/rman@catdb
RMAN> CHANGE BACKUP TAG 'consistent_db_bkup'
2> KEEP FOREVER;
ble
2 Changing the status of a database copy: fe r a
ans
n - t r
no
RMAN> CHANGE COPY OF DATABASE CONTROLFILE NOKEEP;
a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Managing Archival Database
y u ki sBackups
e
M as lchanges
The CHANGE command i c en the exemption status of a backup or copy in relation to the
configured
l y
eretention policy. For example, you can specify CHANGE ... NOKEEP, to make a
n
Sta that is currently exempt from the retention policy eligible for the OBSOLETE status.
backup
The first example changes a consistent backup into an archival backup, which you plan to store
offsite. Because the database is consistent and, therefore, requires no recovery, you do not need to
save archived redo logs with the backup.
The second example specifies that any long-term image copies of data files and control files should
lose their exempt status and so become eligible to be obsolete according to the existing retention
policy. This statement essentially removes the archival attribute from those backup files. If you do
not specify a tag, as in this case, then the CHANGE execution applies to all backups of the type
specified. You should specify a tag to change only the backup files you intend to change.
Note: The RESTORE POINT option is not valid with the CHANGE command, because there is no
way to create the restore point for a time that has already passed (when the backup was created).

Multisection Backups: Overview
Channel 1
Section 1
Channel 2
Section 2
Channel 3
Section 3
Channel 4
Section 4
ble
fe r a
Channel 5 ans
Section 5
n - t r
Channel 6 a no
Section 6 a s
) h i d eฺ
One large data file m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Multisection Backups: k i
Overview
a s yu ense
Oracle data files
M can be upicto 128 TB in size. Normally, the smallest unit of an RMAN backup is an
y l
l
entire file.
n eThis is not practical with such large files. RMAN can optionally break up large files into
Sta and back up and restore these sections independently. You do this by creating multisection
sections
backups, which break up the files generated for the backup set into separate files. This can be done
only with backup sets, not image copies.
Each file section is a contiguous range of blocks of a file. Each file section can be processed
independently, either serially or in parallel. Backing up a file into separate sections can improve the
performance of the backup operation, and it also allows large file backups to be restarted.
A multisection backup job produces a multipiece backup set. Each piece contains one section of the
file. All sections of a multisection backup, except perhaps for the last section, are of the same size.
There are a maximum of 256 sections per file.
Note: You should not apply large values of parallelism to back up a large file that resides on a small
number of disks, as that would defeat the purpose of the parallel operation; multiple simultaneous
accesses to the same disk device would be competing with each other.
This feature is built into RMAN. No installation is required beyond the normal installation of Oracle
Database 11g. COMPATIBLE must be set to at least 11.0, because earlier releases cannot restore
multisection backups.

Creating RMAN Multisection Backups

BACKUP <options> SECTION SIZE <integer> [K | M | G]
VALIDATE DATAFILE <options> SECTION SIZE <integer> [K | M | G]
Example:
RMAN> BACKUP DATAFILE 5 SECTION SIZE = 25M TAG 'section25mb';

backing up blocks 1 through 3200
ble
piece handle=/u01/.../o1_mf_nnndf_SECTION25MB_382dryt4_.bkp
fe r a
tag=SECTION25MB comment=NONE
ans
n - t r
...
a no
backing up blocks 9601 through 12800
a s
) h i d eฺ
m
piece handle=/u01/.../o1_mf_nnndf_SECTION25MB_382dsto8_.bkp u
tag=SECTION25MB comment=NONE ilฺco t G
g ma tuden
sy se th
a
(MBackups u
k
Creating RMAN Multisection
u nsei t o
The BACKUP and a s y e DATAFILE commands accept the following option:
M VALIDATE
l i c
l ey SIZE <integer> [K | M | G]
SECTION
n
a to specify your planned size for each backup section. The option is both a backup
Stthis
Use
command– and backup spec–level option, so that you can apply different section sizes to different
files in the same backup job.
In the example in the slide, a backup of data file 5 is being taken, and the section size is specified as
25 MB. The data file is 100 MB in size, so four sections are created. Note that, as indicated by the
block ranges, block contiguity is maintained as they are written to the section files.
Viewing Metadata About Your Multisection Backup
• The V$BACKUP_SET and RC_BACKUP_SET views have a MULTI_SECTION column, which
indicates whether this is a multisection backup or not.
• The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views have a SECTION_SIZE
column, which specifies the number of blocks in each section of a multisection backup. Zero
means a whole-file backup.

Compressing Backups
RMAN can perform binary compression on any backup set that

is generated.
• It can be performed in addition to unused block
compression.
• By default, RMAN uses the BZIP2 compression algorithm.
• BZIP2 generally differs from ZLIB in the following respects:
– It has a better compression ratio.
– It is slower. ble
fe r a
• No extra steps are required by the DBA to restore a ns
compressed backup. t r a
n- no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Compressing Backups k i
a s yu ense
While unused block
y M l ic decreases the number of blocks that are written to the backup,
compression
t a nle algorithms
binary compression
compression
can be used to algorithmically compact the data that is written. The two available
are ZLIB and BZIP2.
S
ZLIB is optimized for CPU efficiency. BZIP2 is optimized for maximum compression. BZIP2
consumes more CPU resource than ZLIB but usually produces more compact backups. The
COMPATIBLE initialization parameter must be set to 11.0.0 or higher for ZLIB compression, which
requires the Oracle Advanced Compression option.
You do not have to perform any additional steps when restoring a compressed backup. Note,
however, that compression and decompression operations require CPU resources. So both creating
and restoring a compressed backup will, of course, probably take longer and require more system
resources.
When choosing an algorithm, consider your disk space in addition to dynamic system resources such
as CPU and memory.

Encrypting Backups
Password: **********
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Encrypting Backups uki
a s y ense
You can encrypt
y M backupsiin
l c one of three ways:
e
anl encryption: This method of encryption relies on a password. There is no need to
• Transparent encryption: This method uses a wallet, and it is the default mode.
•StPassword
configure a wallet. You must know the password that was used for the backup in order to
restore.
• Dual mode encryption: Both transparent and password encryption are used. In order to restore,
either the transparent mode or the password mode can be used. This type of encryption is useful
if you usually restore your backups to the local site, but sometimes ship the backups to other
sites.
Modify the encryption setting using SET ENCRYPTION. Here is an example of password
encryption:
RMAN> SET ENCRYPTION IDENTIFIED BY mypassword;
RMAN> BACKUP DATAFILE 5;
...
RMAN> SET DECRYPTION IDENTIFIED BY mypassword;

Encrypting Backups (continued)

RMAN can transparently encrypt data written to backup sets and decrypt those backup sets when
they are needed in a RESTORE operation. To create encrypted backups on disk, the database must
use the Advanced Security Option. To create encrypted backups directly on tape, RMAN must use
the Oracle Secure Backup SBT interface, but does not require the Advanced Security Option.
If you want to use transparent encryption, the wallet must be created and the database configured to
use a wallet. This is the same wallet used with Transparent Data Encryption. The wallet must be
created before it can be used for either encrypted backups or TDE.
Add an entry to the SQLNET.ORA file:
ENCRYPTION_WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY =
/oracle/dbsid/admin/pdcs11/wallet)))
Create a simple password-protected wallet with the following command: ble
ALTER SYSTEM SET [ENCRYPTION] KEY IDENTIFIED BY "welcome1";
fe r a
n s
Note: Encryption by Oracle Secure Backup (OSB) can be configured so that all backups
n - t ra are
a
Backup Administrator’s Guide for more information about OSB encryption.
no See the Secure
encrypted by OSB no matter what type of encryption is requested by the client.
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n l e
Sta

Backing Up Recovery Files
• Back up only the files in the Flash Recovery Area:

RMAN> BACKUP RECOVERY AREA
• Back up all recovery files:

RMAN> BACKUP RECOVERY FILES
ble
fe r a
ans
n - t r
a no
a s
Flash Recovery Area
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Backing Up RecoveryuFiles k i (M e to u
astoyback e n s
There are two M ways ic current and data.
up recovery The BACKUP RECOVERY AREA command backs up
y lthe
n l e
all files that are found in any previous Flash Recovery Areas. The BACKUP
S ta
RECOVERY FILES command backs up all recovery files, even if they are not in the Flash Recovery
Area. You gain added protection from loss by using the latter, which would back up, for example,
any copies of control files or data files that are not in the Flash Recovery Area.
By default, backup optimization is in effect for these two commands, even if you have disabled it
using the CONFIGURE command. This means that the only recovery files that this command backs
up are those that are not already backed up. You can force all files to be backed up by using the
FORCE option. Backup optimization is covered in the lesson titled “Configuring Backup
Specifications.”
You cannot specify DEVICE TYPE DISK for either of these commands.
Note: RMAN backs up only database files: data files, redo log files, control files, SPFILES, archive
log files, and backups of these files. Placing an operating system file in the Flash Recovery Area
causes it to be included with a backup of the recovery area.

Using a Media Manager
Server
Recovery session
Manager (channel)
Media
Management
Library
Oracle Secure Or
Backup with
built-in MML Media ble
management fe r a
server software ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using a Media Manager k i
a s yu ense
To use tape storage
y M l ic database backups, RMAN requires Oracle Secure Backup or a media
for your
manager.le
AS tan manager is a utility that loads, labels, and unloads sequential media (such as tape drives) for
media
the purpose of backing up, restoring, and recovering data. The Oracle database server calls Media
Management Library (MML) software routines to back up and restore data files to and from media
that is controlled by the media manager.
Note that the Oracle database server does not need to connect to the MML software when it backs up
to disk.
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
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.

Using a Media Manager (continued)

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
The following Recovery Manager script performs a data file backup to a tape drive controlled by a
media manager:
run {
# Allocating a channel of type 'sbt' for serial device
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
bl e
BACKUP DATAFILE 3;
fe r a
}
t r a ns
When Recovery Manager executes this command, it sends the backup requestoto n -the Oracle database
session performing the backup. The Oracle database session identifies the n channel as a media
a output
s
haand write
management device and requests the media manager to load a tape
) i d eฺthe output.
The media manager labels and keeps track of the tape and m
cothe namesG ofuthe files on each tape. The
i l ฺ t
media manager also handles restore operations. When
g m a you restore
u d en a file, the following steps occur:
1. The Oracle database server requests the
k i @ restoration
i s Soft a particular file.
2. The media manager identifies the
s y utape containing
th the file and reads the tape.
3. The media manager passes a e
us back to the Oracle database session.
i (Mthe
4. The Oracle databasekserver
information
t
writeso the file to disk.
a syu cense
yM li
n l e
Sta

Performing Proxy Copies
Server
Recovery session
Manager (channel)
Media
Management
Library
Media ble
management fe r a
server software ans
n - t r
a no
a s
Storage Area Network m ) h
(SAN) i d eฺ
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Performing Proxy Copies k i
u nse
a s y
Use the PROXYMoption ofitheeRMAN BACKUP command to request a MML to perform the copy of
l c
the files. ley
n
Stamedia management products can completely manage all data movement between Oracle data
Some
files 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. This is
beneficial in that the copying takes place across the SAN instead of the LAN. Also, RMAN is out of
the picture at that point, except for communicating status across the LAN to and from the MML.

Creating an Oracle-Suggested Backup

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M Backup u
k
Creating an Oracle-Suggested i t o
a s yu ense
Enterprise Manager
y M makes
l icit easy for you to set up an Oracle-suggested backup strategy that protects
your datale
far t a
back
nasand
48
provides efficient recoverability to any point in the preceding 24 hours, and possibly as
hours, depending on when the last backup was created. The Oracle-suggested strategy
S
uses the incremental backup and incrementally updated backup features, providing faster
recoverability than is possible when applying database changes from the archived log files.
To establish an Oracle-suggested strategy, navigate to the Maintenance page. In the
Backup/Recovery region, select Schedule Backup. The Backup Strategies section enables you to
select 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, you
might want to consider taking this at a period of least activity. After that, an incremental backup to
disk is taken every day. Optionally, a weekly tape backup can be made, which backs up all recovery-
related files.
Because these backups on disk are retained, you can always perform a full database recovery or a
point-in-time recovery to any time within the past 24 hours, at the minimum. The recovery time
could reach back as far as 48 hours. This is because just before a backup is taken on a given day, the
backup from the beginning of day n–1 still exists.

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 data files that require a
backup
• REPORT OBSOLETE: Identifies files that are no longer b le
r a
needed to satisfy backup retention policies sfe n
n - tra
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
Managing Backups: Reporting
as command
Use the RMANMLIST
l i c en to display information about backup sets, proxy copies, and image
l ey in the repository. Use this command to list:
copies recorded
n
S a
• tBackups and copies that do not have the AVAILABLE status in the RMAN repository
• Backups and copies of data files that are available and can possibly be used in a restore
operation
• Backup sets and copies that contain a backup of a specified list of data files or specified
tablespaces
• Backup sets and copies that contain a backup of any archived logs with a specified name or
range
• 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
• Stored scripts in the recovery catalog
Use the RMAN REPORT command to analyze information in the RMAN repository in more detail.
The REPORT NEED BACKUP command is used to identify all data files 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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Managing Backups: Dynamic Performance Views
Query the following dynamic performance views in the target

database to obtain information about your backups:

• V$BACKUP_SET: Backup sets created
• V$BACKUP_PIECE: Backup pieces that exist
• V$DATAFILE_COPY: Copies of data files on disk
• V$BACKUP_FILES: Information about all files created when
creating backups
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
(M Performance
Managing Backups: Dynamic k i
u nse t o Views
s y
a thatlicprovide
e backup-related information. The most commonly used ones are
There are manyMviews
theyslide.
shown inle
n
taare using a recovery catalog, you can query corresponding views that contain the same
IfS
you
information for each target database registered in the recovery catalog database. The corresponding
views have the same name, except that the “V$” is replaced with “RC_”. Also, they are in the schema
owned by the recovery catalog owner. For example, the corresponding views in the recovery catalog,
showing the information shown in the slide are: RC_BACKUP_SET, RC_BACKUP_PIECE,
RC_DATAFILE_COPY, and RC_BACKUP_FILES.
In order to query the RC_BACKUP_FILES view, you must first execute the following in the
recovery catalog database:
SQL> CALL DBMS_RCVMAN.SETDATABASE(null,null,null,<dbid>);
where <dbid> is the database ID of a target database.

Using Enterprise Manager to View

Backup Reports
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(to
u nsView e Backup Reports
s y
a lReport e page to display lists of backup jobs that are known to the database
You can use the M Backup i c
l
through the
n eyinformation recorded about them in the database control file.
Stacan customize the jobs that appear in the Results table by using the Search fields at the top of
You
the page. The Results table lists basic information about each backup job, such as the Start Time, the
Time Taken, and the Status of the backup job. You can also use the Results table to drill down to
individual, detailed backup job reports by using the link in the Backup Name column.
You can drill down to a Summary of Job page of the backup job by clicking the Status of the job in
the Results table, where you can view the contents of the output log.
Click the Backup Name link, and you can use the Backup Report page to display detailed
information about that backup. The information displayed on this page is derived from the
information recorded in the database control file.
The Backup Report page displays result information in the Result section in various categories, such
as Input Summary, containing rollup information about the files that were 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 data files,
control files, backup sets, backup pieces, and image copies.

Managing Backups: Cross-Checking 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 e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to uand Deleting
k i
Managing Backups: Cross-Checking
u nse
Use the CROSSCHECKa s y commande to ensure that data about backups in the recovery catalog or control
M l i c
l ey
file is synchronized
n with actual files on disk or in the media management catalog. The
S t a
CROSSCHECK command operates only on files that are recorded in the RMAN repository.
The CROSSCHECK command checks only objects marked AVAILABLE or EXPIRED by 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 unable to find to
EXPIRED. It does not delete any files that it is unable to find.
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 data file copies. 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 REDUNDANCY
and RECOVERY WINDOW options as REPORT OBSOLETE.
If you delete backups without using RMAN, you can use the UNCATALOG command to remove the
files from the recovery catalog, or you can use the CROSSCHECK and DELETE EXPIRED
commands.
Refer to the Oracle Database Backup and Recovery Reference for detailed syntax information.

Summary

• Create image file backups

• Create a whole database backup
• Create a full database backup
• Enable fast incremental backup
• Create duplex backup sets
• Back up a backup set
a b le
• Create an archival backup for long-term retention er
s f
• Create a multisection backup
- t r an
• Create a compressed backup n on
s a
• Create an encrypted backup a
) h uideฺ
m
• Report on and maintain backupsilฺco nt G
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Creating Backups
• Taking an archival backup

• Enabling block change tracking
• Recovering from a damaged block
• Reporting on existing backups
• Backing up the control file
• Creating an encrypted backup
a b le
• Creating a compressed backup er
s f
tran
• Using the Media Management Library to take backups
n -
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

Performing User-Managed Backup and

Recovery
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Describe the difference between user-managed and server-

managed backup and recovery
• Manually back up a data file, tablespace, and database
• Back up and recover a control file
• Perform user-managed complete database recovery
• Perform user-managed incomplete database recovery
• Recover from a lost TEMP file ble
fe r a
• Recover from a lost redo log group ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Restoring and Recovering

Restore
ble
fe r a
ans
Redo log
n - t r
Recover a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Restoring and Recovering k i
a s yu ense
The “recovery”
y Mportionliofc backup and recovery tasks includes two major types of activities:
restoring
a n leand recovering. Restoring a file is the process of copying a backup into place to be
t
used
S by the database. This is necessary if, for example, a file is damaged because the physical
disk it is on fails. This is usually due to hardware problems, such as disk write errors, or
controller failure. In that case, a backup of the file needs to be copied onto a new (or repaired)
disk.
Recovering the file entails applying redo such that the state of the file is brought forward in time,
to whatever point you want. That point is usually as close to the time of failure as possible.
In the database industry, these two operations are often referred to, collectively, with the single
term “recovery.”

Causes of File Loss
File loss can be caused by:

• User error
• Application error
• Media failure
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Causes of File Loss uki
a s y ense
Files can be lost
y lic due to:
M or damaged
• User
a n leerror: An administrator may inadvertently delete or copy over a necessary operating
t
S system file.
• Application error: An application or script can also have a logic error in it, as it processes
database files, resulting in a lost or damaged file.
• Media failure: A disk drive or controller may fail fully or partially, and introduce
corruption into files, or even cause a total loss of files.

Critical Versus Noncritical
A noncritical file loss is one where the database can continue to

function.
You fix the problem by taking one of these actions:

• Create a new file. a b le
s fer
• Rebuild the file.
- t r an
• Recover the lost or damaged file. non a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Critical Versus Noncritical
y u ki se to
A noncritical M
s centhe database and most applications can operate without. For
fileais onelithat
example,
n l eifythe database loses one multiplexed redo log file, there are still other redo log file
Sta that can be used to keep the database operating.
copies
Although the loss of a noncritical file does not cause the database to crash, it can impair the
functioning of the database. For example:
• The loss of an index tablespace can cause applications and queries to run much slower, or
even make the application unusable, if the indexes were used to enforce constraints.
• The loss of an online redo log group, as long as it is not the current online log group, can
cause database operations to be suspended (when LGWR next tries to write to the group)
until new log files are generated.
• The loss of a temporary tablespace can prevent users from running queries or creating
indexes until they have been assigned to a new temporary tablespace.

Losing a Tempfile
SQL statements that require temporary space to execute may

fail if one of the tempfiles is missing.
SQL> select * from big_table order by

1,2,3,4,5,6,7,8,9,10,11,12,13;
select * from big_table order by
1,2,3,4,5,6,7,8,9,10,11,12,13
*
ERROR at line 1:
ble
ORA-01565: error in identifying file
fe r a
'/u01/app/oracle/oradata/orcl/temp01.dbf'
ans
ORA-27037: unable to obtain file status
n - t r
Linux Error: 2: No such file or directory
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Losing a Tempfile uki
a s y ense
If a temporaryM
y lic belonging to the temporary tablespace is lost or damaged, the
file (tempfile)
lethat file will not be available. This problem may manifest itself as an error during the
extentsnin
a
S t
execution of SQL statements that require temporary space for sorting.
The SQL statement shown in the slide has a long list of columns to order by, which results in the
need for temporary space. The missing file error is encountered when this statement requiring a
sort is executed.
The Oracle database instance can start up with a missing temporary file. If any of the temporary
files do not exist when the database instance is started, they are created automatically and the
database opens normally. When this happens, a message like the following appears in the alert
log during startup:
Re-creating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf

Recovering from a Tempfile Loss

SYSTEM USERS Redo log Redo log

file 1A file 1B
Parameter
file
SYSAUX INDEX Redo log Redo log
file 2A file 2B
Password
file e
UNDO TEMP Control r a bl
files s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k i
Recovering from a Tempfile
u nsLoss e
a s y e
You can recover
y c tempfile without restarting the database.
M from alilost
t a nle to recover the database when the temp01.dbf data file belonging to the default
For example,
S
temporary tablespace TEMP has been deleted at the operating system (OS) level, add a new data
file, and then drop the one that was deleted:
SQL> ALTER TABLESPACE temp ADD TEMPFILE
'/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M;
Tablespace altered.
SQL> ALTER TABLESPACE temp DROP TEMPFILE

'/u01/app/oracle/oradata/orcl/temp01.dbf';
Tablespace altered.

Log Group Status: Review
A redo log group has a status of one of the

following values at any given time:

• CURRENT: The LGWR process is currently
writing redo data to it.
• ACTIVE: It is no longer being written to,
but it is still required for instance recovery.
• INACTIVE: It is no longer being written to,
and it is no longer required for instance le
a b
recovery. fer s
- t r an
n
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Log Group Status: Review k i
a s yu ense
To deal with the
y c log files, it is important to understand the possible states of redo log
M loss ofliredo
groups.n e log groups cycle through three different states as part of the normal running of the
lRedo
t a
Oracle
S database. They are, in order of the cycle:
• CURRENT: This state means that the redo log group is being written to by LGWR to record
redo data for any transactions going on in the database. The log group remains in this state
until there is a switch to another log group.
• ACTIVE: The redo log group still contains redo data that is required for instance recovery.
This is the status during the time when a checkpoint has not yet executed that would write
out to the data files all data changes that are represented in the redo log group.
• INACTIVE: The checkpoint discussed above has indeed executed, meaning that the redo
log group is no longer needed for instance recovery, and is free to become the next
CURRENT log group.

Recovering from the Loss of a

Redo Log Group
Start
Yes Inactive Current

Fix Group
Done
media? status
No Active
Clear log Perform Perform No Instance

file. No checkpoint. log switch crashed?
Archived?
Back up
database.
ble
Yes
Yes CKPT
fe r a
successful?
Yes
ans
Clear log file.
n - t r
No
a no
Restore andha
s
) i d eฺ
m
co nt Gu
perform cancel-based
i l ฺ
recovery.
g ma tude
sy se th
a
Recovering from theuLoss k to u Log Group
i (Mofea Redo
a y ens
sentire
If you have lost
y M an licredo log group, then all copies of the log files for that group are
unusable
t a nleor gone.
S simplest case is where the redo log group is in the INACTIVE state. That means it is not
The
currently being written to, and it is no longer needed for instance recovery. If the problem is
temporary, or you are able to fix the media, then the database continues to run normally, and the
group is reused when enough log switch events occur. Otherwise, if the media cannot be fixed,
you can clear the log file. When you clear a log file, you are indicating that it can be reused.
If the redo log group in question is ACTIVE, then, even though it is not currently being written
to, it is still needed for instance recovery. If you are able to perform a checkpoint, then the log
file group is no longer needed for instance recovery, and you can proceed as if the group were in
the inactive state.
If the log group is in the CURRENT state, then it is, or was, being actively written to at the time
of the loss. You may even see the LGWR process fail in this case. If this happens, the instance
crashes. Your only option at this point is to restore from backup, perform cancel-based
incomplete recovery, and then open the database with the RESETLOGS option.

Clearing a Log File
Start
Yes
Log file
ALTER DATABASE CLEAR LOGFILE ... archived?
No
Yes
Needed for
data file?
ble
fe r a
No
an s
ALTER DATABASE CLEAR UNARCHIVED LOGFILE ... n - t r
a no
h a s ฺ
) i d eDATAFILE
ALTER DATABASE CLEAR UNARCHIVED LOGFILE ... UNRECOVERABLE m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Clearing a Log File uki
a s y ense
Clear a log file
y M using this
l iccommand:
t a nle ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP <n>
S [UNRECOVERABLE DATAFILE]
When you clear a log file, you are indicating that it can be reused. If the log file has already been
archived, the simplest form of the command can be used. Use the following query to determine
which log groups have been archived:
SQL> SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG;
For example, the following command clears redo log group 3, which has already been archived:
SQL> ALTER DATABASE CLEAR LOFGILE GROUP 3;
If the redo log group has not been archived, then you must specify the UNARCHIVED keyword.
This forces you to acknowledge that it is possible that there are backups that rely on that redo
log for recovery, and you have decided to forgo that recovery opportunity. This may be
satisfactory for you, especially if you take another backup right after you correct the redo log
group problem; you then no longer need that redo log file.
It is possible that the redo log is required to recover a data file that is currently offline.

Re-Creating Indexes
Use options to reduce the time it takes to create the index:

• PARALLEL
• NOLOGGING
SQL> CREATE INDEX rname_idx

2 ON hr.regions (region_name)
3 PARALLEL 4;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Re-Creating Indexesuki
a s y ense
When creating
y lic an index, you can use the following keywords to reduce the
Mor re-creating
creation
a n le
time:
t
S• PARALLEL (NOPARALLEL is the default): Multiple processes can work together
simultaneously to create an index. By dividing the work necessary to create an index among
multiple server processes, the Oracle server can create the index more quickly than if a
single server process created the index sequentially. The table is randomly sampled and a
set of index keys is found that equally divides the index into the same number of pieces as
the specified degree of parallelism. A first set of query processes scans the table, extracts
key, row ID pairs, and sends each pair to a process in a second set of query processes based
on the key. Each process in the second set sorts the keys and builds an index in the usual
fashion. After all index pieces are built, the parallel coordinator concatenates the pieces
(which are ordered) to form the final index.
• NOLOGGING: Using this keyword makes index creation faster because it creates a very
minimal amount of redo log entries as a result of the creation process. This greatly
minimized redo generation also applies to direct path inserts and Direct Loader
(SQL*Loader) inserts. This is a permanent attribute and thus appears in the data dictionary.
It can be updated with the ALTER INDEX NOLOGGING/LOGGING command at any time.

Re-Creating Indexes (continued)

When an index is lost, it may be faster and simpler just to re-create it rather than attempt to
recover it. You can use Data Pump Export with the CONTENT=METADATA_ONLY parameter to
create a dump file containing the SQL commands to re-create the index. You can also use Data
Pump Import with the SQLFILE=<filename> parameter on a previously created dump file.
The Data Pump Export and Import utilities are covered in detail in the Oracle Database 11g:
Administration Workshop I course. Additional information can be found in Oracle Database

Utilities.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Recovering from a Lost Index Tablespace
• A tablespace that contains only indexes may be recovered

without performing a RECOVER task.

• If a data file that belongs to an index-only tablespace is lost,
it may be simpler to re-create the tablespace and re-create
the indexes.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Recovering from a Lost k i
u nseTablespace
Index
s y
a objects, e in that they do not provide any original data, and they are only a
Indexes are computed
y M l i c
different
n l erepresentation of data that already exists. So, in most cases, indexes can be re-created
t a
easily.
S If you have a tablespace that contains only indexes, recovering from a loss of a data file
belonging to that tablespace can be simplified.
When a data file like this is lost, you can perform the following steps:
1. Drop the data file.
2. Drop the tablespace.
3. Re-create the index tablespace.
4. Re-create the indexes that were in the tablespace.

Authentication Methods
for Database Administrators
Remote database Local database

administration administration
Do you Yes Do you want Yes

have a secure to use OS Use OS
connection? authentication? authentication.
ble
fe r a
ans
n - t r
No No
a noUse a
a s password file.
) h i d eฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Authentication Methods u e to Administrators
ki forsDatabase
y
as lyou n to administer your database locally on the same machine on
ewant
Depending onM
y
whether i c
l
whichnthe edatabase resides or to administer many different database servers from a single remote
t a
client,
S you can choose either operating system or password file authentication to authenticate
database administrators:
• If the database has a password file and you have been granted the SYSDBA or SYSOPER
system privilege, then you can be authenticated by a password file.
• If the server is not using a password file, or if you have not been granted SYSDBA or
SYSOPER privileges and are, therefore, not in the password file, you can use operating
system authentication. On most operating systems, authentication for database
administrators involves placing the operating system username of the database
administrator in a special group, generically referred to as OSDBA. Users in that group are
granted SYSDBA privileges. A similar group, OSOPER, is used to grant SYSOPER
privileges to users.
Operating system authentication takes precedence over password file authentication.
Specifically, if you are a member of the OSDBA or OSOPER group for the operating system, and
you connect as SYSDBA or SYSOPER, you will be connected with associated administrative
privileges regardless of the username/password that you specify.

Re-creating a Password
Authentication File
SQL> grant sysdba to admin2;
grant sysdba to admin2

*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled
To recover from the loss of a password file:

1. Re-create the password file by using orapwd.
ble
$ orapwd file=$ORACLE_HOME/dbs/orapworcl password=ora entries=5
fe r a
2. Add users to the password file and assign appropriatet r a ns
privileges to each user. o n -
n a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Re-creating a Password
y u ki Authentication
s e File
s
a provides
The Oracle database c n
e a password utility, orapwd, to create a password file. When you
M l i
ey the SYSDBA privilege, you are connecting as the SYS schema and not the schema
connect lusing
n
Sta with your username. For SYSOPER, you are connected to the PUBLIC schema.
associated
Access to the database using the password file is provided by GRANT commands issued by
privileged users.
Typically, the password file is not included in backups because, in almost all situations, it can be
easily re-created.
It is critically important to the security of your system that you protect your password file and
the environment variables that identify the location of the password file. Any user with access to
these could potentially compromise the security of the connection.
You should not remove or modify the password file if you have a database or instance mounted
using REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE or SHARED. If you do, you will be
unable to reconnect remotely using the password file.
Note: Passwords are case-sensitive, so you must take that into consideration when re-creating
the password file.

Re-creating a Password Authentication File (continued)

Using a Password File
The following are the steps for re-creating the password file:
1. Create the password file by using the password utility orapwd.
orapwd file=filename password=password entries=max_users
where:
- filename is the name of the password file (mandatory).

- password is the password for SYS (optional). You are prompted for the password if
you do not include the password argument.
- Entries is the maximum number of distinct users allowed to connect as SYSDBA or
SYSOPER. If you exceed this number, you must create a new password file. It is safer
to have a larger number. There are no spaces around the “equal to” (=) character.
Example: orapwd file=$ORACLE_HOME/dbs/orapwU15
password=admin entries=5
le
2. Connect to the database by using the password file created in step 1, and grant privilegesbas
a
r
needed.
n sfe
SQL> CONNECT sys/admin AS SYSDBA
n - tra
SQL> grant sysdba to admin2; o
Password File Locations s an
UNIX: $ORACLE_HOME/dbs ) ha ideฺ
c o m Gu
Windows: %ORACLE_HOME%\database a il ฺ n t
gm Stud e
Maintaining the Password File @
byyu
Delete the existing password file s
ki this system commands, and create a new
using operating
M a utility.
password file by using the password
( u se
y u ki se to
M as licen
n l ey
Sta

Comparing Complete and Incomplete Recovery
Recovery can have two kinds of scope:

• 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
ble
Complete
Time of
fe r a
recovery
crash
ans
n - t r
Incomplete
recovery a no
s
Recovery
a
Restore from Missing transactions ) htask eฺ
started
i d
m u time
co nt atGthis
this backup after incomplete recovery
i l ฺ
g ma tude
sy se th
a
(M to u
Comparing Complete k i
u nIncomplete
and e Recovery
s y
a complete s
e recovery, you bring the database to the state where it is fully up-to-
When you perform
M l i c
l ey all committed data modifications to the present time. Incomplete recovery,
date, including
n
Sta brings the database to some point in the past. This means there are missing
however,
transactions; any data modifications done between the recovery destination time and the present
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.

Complete Recovery Process

Archived
log Archived
log Online
Redo log
Changes applied Undo applied
2 4
bl e
fe r a
1 t r a ns
3 5 n -
n o
Restored Data files containing as a
data files committed and uncommitted
m ) h uideฺRecovered
o
ilฺc ent G
transactions data files
a
@ gm Stud
u
Copyright
s
a use
( M
Complete Recovery u
y ki se to
Process
The followingM as describe
steps l i c enwhat takes place during complete recovery:
l ey or missing files are restored from a backup.
1. Damaged
n
S2.taChanges from incremental backups, archived redo log files, and online redo log files are
applied as necessary. The redo log changes are applied to the data files until the current
online log is reached and the most recent transactions have been reentered. Undo blocks are
generated during this entire process. This is referred to as rolling forward or cache recovery.
3. The restored data files may now contain committed and uncommitted changes.
4. The undo blocks are used to roll back any uncommitted changes. This is sometimes referred
to as transaction recovery.
5. The data files are now in a recovered state and are consistent with the other data files in the
database.

Incomplete Recovery Process

Archived
log Archived
X
log Online
X
Redo log
Changes applied to point in time (PIT) Database

opened Undo applied
2
4 5
ble
fe r a
1 3 6 -tra
ns
Data files containing n on
Restored data
s a PIT-recovered
files from as far committed and
h a e ฺ data files
back as necessary uncommitted m) u i d
o
ilฺcto PITnt G
transactions up
g ma tude
sy se th
a
(M to u
Incomplete Recovery k i
Process
a s yu ense
Incomplete recovery,
y c
M orlidatabase point-in-time recovery, uses a backup to produce a noncurrent
version
a n lofethe database. That is, you do not apply all of the redo records generated after the most
t
recent
S backup. Perform this type of recovery only when absolutely necessary. To perform
incomplete recovery, you need:
• A valid offline or online backup of all the data files made before the recovery point
• All archived logs from the time of the backup until the specified time of recovery
The progression taken to perform an incomplete recovery is listed below:
1. Restore the data files from backup: The backup that is used may not be the most recent
one, if your restore point destination is to be not very recent. This entails either copying
files using OS commands or using the RMAN RESTORE command.
2. Use the RECOVER command: Apply redo from the archived redo log files, including as
many as necessary to reach the restore point destination.
3. State of over-recovery: Now the data files contain some committed and some
uncommitted transactions because the redo can contain uncommitted data.
4. Use the ALTER DATABASE OPEN command: The database is opened before undo is
applied. This is to provide higher availability.

Incomplete Recovery Process (continued)

5. Apply undo data: While the redo was being applied, redo supporting the undo data files
was also applied. So the undo is available to be applied to the data files in order to undo any
uncommitted transactions. That is done next.
6. Process complete: The data files are now recovered to the point in time that you chose.
Point-in-time recovery is the only option if you must perform a recovery and discover that you
are missing an archived log containing transactions that occurred sometime between the time of
the backup you are restoring from and the target recovery SCN. Without the missing log, you
have no record of the updates to your data files during that period. Your only choice is to recover
the database from the point in time of the restored backup, as far as the unbroken series of
archived logs permits, and then open the database with the RESETLOGS option. All changes in
or after the missing redo log file are lost.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Types of Backup and Recovery Practices
Types of database backup and recovery are:

• User-managed: Does not use RMAN.

– Uses OS commands to move files around
– Requires DBA to manually maintain backup activity records
• Server-managed: Uses RMAN
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Types of Backup and k i
u nse Practices
Recovery
s y
a lyou ecan use to recover your database. You can use RMAN, and take
There are twoM methods i c
l
advantage
n eyof its automatic recovery capabilities. It can restore the appropriate files and bring the
Sta back to a current state by using very few commands. You can also recover manually.
database
This is called user-managed recovery. User-managed recovery entails moving the files around
using OS commands, and then issuing the recovery commands in SQL*Plus.
Both of these methods use restore and recovery processes.

Performing a User-Managed
Backup of the Database
No Yes
ARCHIVELOG
mode?
Shut down. Put tablespaces into backup mode.
ble
fe r a
an s
n - t r
Copy files.
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing a User-Managed k i
u nseBackup of the Database
s y
You can backM upathe database
l i c e by using OS commands to make copies of the data files. The
l
course of y depends on whether the database is in ARCHIVELOG mode or not. If it is, then
eaction
n
Stacan keep the database open and available by putting each tablespace into backup mode
you
before copying its data files. Otherwise, you have to shut down the database before copying the
data files.

The Need for Backup Mode
A DML statement updates

a database block:
Different parts of the block are

written to at different times:
Copy
Database block data file
while
online ble
fe r a
ans
n - t r
t1 t2
a no t3
a s
) h i d eฺ
If the block is copied at time t2, then m
cothe block
G u fractured.
is
i l ฺ t
g ma tuden
sy se th
a
(M to u
The Need for Backup k i
Mode
a s yu ense
When a blockM
y lic to as part of the execution of a data manipulation language
is being written
a le
(DML)nstatement, there could be several parts of the block affected. Not all of the modifications
t
toSthe block happen at the same time, so there is the possibility of inconsistency in the block at
certain times. Suppose time t2 represents the time between when different parts of the block are
written to. If, at time t2, the block is copied as part of the execution of an OS copy command,
then the block is considered fractured. Also, the OS copy command does not necessarily copy
the file header first, so it must be frozen for the duration of the copy execution.
RMAN has the means to deal with this problem. If a fractured block is read, it keeps rereading it
until it is consistent.
However, if an OS command such as the Linux cp command is copying the data file, the
fractured block is not recognized as such, and the copy of the block is not consistent. In order to
remedy this, put the tablespace, or even the entire database, into what is called backup mode.
The effect of doing this is that additional redo is generated. An image of each block, before it is
modified, is written to the redo log. Then, during recovery of blocks in that data file, the before
image of a fractured block can be used for the basis of recovery and the additional redo data is
applied to it. In order to reduce the overhead associated with maintaining extra redo data, Oracle
recommends putting one tablespace at a time into backup mode, while its data files are being
copied.

Identifying Files to Manually Backup

SQL> select name from v$datafile;
NAME
------------------------------------------------------------------------
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_36mky81f_.dbf
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_36mky81p_.dbf
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_36mky857_.dbf
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_36mky876_.dbf
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_example_36ml2cmh_.dbf
/u01/app/oracle/oradata/ORCL/datafile/survey01.dbf
ble
fe r a
SQL> select name from v$controlfile;
ans
NAME
n - t r
------------------------------------------------------------------------
a no
/u01/app/oracle/oradata/ORCL/controlfile/o1_mf_36ml1f8x_.ctl
a s
) h
/u01/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_36ml1fkk_.ctl
i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
Identifying Files to Manually
u nseBackup
s y
a lirequire e you to know the data file names and locations on disk, so you
User-managedMbackups c
know n l
whateyfiles need to be copied. Identify the data files to be backed up by querying the
Sta
V$DATAFILE view. Identify the control file location by querying the V$CONTROLFILE view.
Only one of the multiplexed control files needs to be backed up, because they are identical.

Manually Backing Up a NOARCHIVELOG Database
• Shut down the database instance:

• Copy the data files to the backup location:

$ cp $ORACLE_BASE/ORCL/datafile/*.dbf \
> /u02/backup/datafile
• Copy the control files to the backup location:

ble
$ cp $ORACLE_BASE/ORCL/controlfile/*.ctl \
fe r a
> /u02/backup/controlfile
ans
n - t r
• Start the instance and open the database: a no
a s
SQL> STARTUP ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u Database
Manually Backing Up k
a i
a s yu enseNOARCHIVELOG
lic whole database backup of a NOARCHIVELOG database by shutting
You can makeMa consistent,
y
down n
a ledatabase and copying all the data files and the control file to a backup directory.
the
S t
Because the action of copying the files is done using OS commands (in this case, the Linux cp
command), the database must be shut down first. This puts it in a consistent state. If your
database is running in NOARCHIVELOG mode, this is your only option. Otherwise, in
ARCHIVELOG mode, you can make inconsistent backups, which allows you to leave the
database running while you take the backup.

Manually Backing Up an ARCHIVELOG Database
SQL> select file_name, tablespace_name from dba_data_files;

• Identify tablespaces
FILE_NAME TABLESPACE_NAME
and their datafiles:

--------------------------------------------- ---------------
/u01/app/oracle/oradata/orcl/users01.dbf USERS
/u01/app/oracle/oradata/orcl/users02.dbf USERS
/u01/app/oracle/oradata/orcl/undotbs1.dbf UNDOTBS1
/u01/app/oracle/oradata/orcl/sysaux01.dbf SYSAUX
/u01/app/oracle/oradata/orcl/system01.dbf SYSTEM
/u01/app/oracle/oradata/orcl/example01.dbf EXAMPLE
For each tablespace:

• Put the tablespace into backup mode:
ble
SQL> ALTER TABLESPACE users BEGIN BACKUP;
fe r a
s
ran
• Copy the data files for that tablespace to the backup-tlocation:
n on
$ cp $ORACLE_HOME/oradata/orcl/users*.dbf /u02/backup/datafile
s a
• Bring the tablespace out of backup mode: a
) h uideฺ
SQL> ALTER TABLESPACE users END BACKUP; ฺco
m G
a il n t
g m tude
sy se th
a
M to u
(ARCHIVELOG
Manually Backing Up kan
u nsei Database
s y
If the databaseMisain ARCHIVELOG
l i c e mode, then you do not necessarily have to shut it down
y
le the files. You end up with an inconsistent backup, but the application of redo
beforencopying
datat a
S recovers it to a consistent state.
Starting Backup Mode: You do have to put each of the data files into backup mode before
copying them, though. Do this using the BEGIN BACKUP clause of the ALTER TABLESPACE
and ALTER DATABASE commands. Here is the syntax for each:
ALTER TABLESPACE <tablespace> BEGIN BACKUP;
ALTER DATABASE BEGIN BACKUP;
The ALTER TABLESPACE command affects only those data files that belong to that
tablespace. ALTER DATABASE affects all data files in the database.
Ending Backup Mode: It is important to bring the data files out of backup mode. You cannot
have any data files in backup mode at the time the database is shut down. If you attempt to shut
down the database in that state, you will receive an error. Also, because backup mode causes
additional redo to be generated, there is extra load on the system. There is no reason to have any
data files in backup mode if you are not actively backing them up.
Note: In addition, you need to archive out the current redo log files, and back them up safely as
well.

Backing Up the Control File
Back up the control file:

• As an image copy, to a specifically named file:

SQL> ALTER DATABASE BACKUP CONTROLFILE TO
2> '/u01/backup/controlfile.bak';
Database altered.
• By generating a script that re-creates it, in a trace file:

ble
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
fe r a
ans
Database altered. n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Backing Up the Control k i File
a s yu ense
You should back
y c file every time you make a structural change to the database.
M up thelicontrol
Use one
a n leof the commands shown in the slide to do this. The first command creates a binary copy
of t
Sthe file. You can optionally supply the REUSE keyword if the backup file already exists and
you want to overwrite it.
The second command makes a plain text version of the control file, which is actually a script
that creates the control file when run. The resulting script is written to the diagnostics trace
directory, such as:
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace
You can also specify a name for the trace file by using the AS 'filename' clause.

Performing User-Managed
Complete Database Recovery: Overview
User-managed complete database recovery:
• Recovers the database to the most recent SCN

• Can be done with the entire database at once, or a data file
or tablespace at a time
• Requires a current or backup control file
• Requires backups of all files to be recovered
• Requires all archive logs up to the present
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing Complete k i
u nse Recovery: Overview
Database
s y
a recovery e brings the database back to its most current state. You can recover
Complete database
y M l i c
l
the entire
n edatabase, or a single tablespace or data file at a time. You must have a current or
t a
backup
S control file in order to perform complete database recovery. You must also have backups
available for all files in need of media recovery or you must have all archived redo log files that
were generated since the data file was added to the database. Refer to the Oracle Database
Backup and Recovery User’s Guide for additional information about re-creating data files when
backups are not available.
You must have all the archive logs available, from the point in time the backups were taken, to
the present. If you do not have all of them, you can recover only to the last point in time when
redo is available. If no archive logs are required, then only online redo logs are applied.
Query the following views:
• V$RECOVER_FILE: To see which files need media recovery
• V$RECOVERY_LOG: To see which archive logs are required to perform recovery

Performing Complete Closed Database

Recovery: Overview
Yes Database
open?
Query for files to recover.
No
Restore needed files

Repair hardware.
Query for needed archive logs.

Restore damaged files and archive logs.
Shut down. Mount database. ble

fe r a
t r a ns
Recover data files. n-
a no
a s
) h
Open i d eฺ
database.
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u nseDatabase Recovery: Overview
Closed
s y
a lice such as damage to a file belonging to the SYSTEM tablespace, the
Under certainM circumstances,
instancel y down automatically. Even if the instance keeps running, and there are problems
eshuts
n
Staother data files, you may decide there is no value is keeping the database running; too many
with
database objects are affected. In that case, shut down the database to perform the recovery.
If the database is still open, you can query the V$RECOVER_FILE view to see which data files
are in need of recovery, and after you restored them, query V$RECOVERY_LOG to see which
archive logs are required. That will tell you which files need to be restored from backup, if any.
Then shut down the database. Look into the media failure to determine the cause of the problem.
Repair the problem so that you can restore the files from backup. For example, you may need to
replace a disk drive.
Now you can perform the recovery using the RECOVER command. Limit the scope of the
recovery to only what is needed, such as data file or tablespace. If needed, recover the entire
database. Then open the database.

Identifying Recovery-Related Files
• Identify data files that need to be recovered:

SQL> SELECT file#, error FROM v$recover_file;
• Identify archive log files that are required to complete

recovery:
SQL> SELECT archive_name FROM v$recovery_log;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Identifying Recovery-Related k i
u nseFiles
s y
If the databaseMisastill open,
l i c equery the files as described below. Otherwise, attempt to start the
instance
n l eandy mount the database to issue the queries.
ta to determine which data files require recovery, query the V$RECOVER_FILE view.
Sorder
In
The ERROR column indicates why the file requires recovery. If this column has any value other
than OFFLINE NORMAL, then it needs recovery. To see the whole picture of which data files
and tablespaces are affected, join V$DATAFILE and V$TABLESPACE in this query. Here is an
example:
SELECT r.FILE#, d.NAME df_name, t.NAME tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;
This tells you the extent of the damage, helping you decide what the objects of the RECOVER
command should be.
The V$RECOVERY_LOG view shows which archive log files are needed to perform the
recovery. If the list shows files that have since been moved off the default archive log location,
then you have to restore them to some location before performing recovery.
After recording the results of these queries, shut down the database.

Restoring Recovery-Related Files

1 Data files
Archive logs
2 /disk1/datafile.dbf /disk2/datafile.dbf bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
3 ONLINE m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Restoring Recovery-Related i
u nseFiles
s y
a whatlidatae files and archive log files are required, restore them to appropriate
After determining
M c
l ey Restore a data file by copying it from the backup location, as in this example:
disk locations.
n
Sta $ cp /disk2/backup/datafile/survey01.dbf \
> $ORACLE_BASE/oradata/ORCL/datafile/survey01.dbf
If any archive logs are needed for recovery, check whether they are still in the default disk
location for archive logs. They may not be, if they have been moved to tape or another disk
drive, for example. If they have been moved, they need to be restored, either to the default
archive log location or to a temporary location. If there is enough space available in the default
location (which is specified by the LOG_ARCHIVE_DEST_1 initialization parameter), then
restore them there. Otherwise, you can put them on some other disk location. When it is time to
restore, you can specify that alternate location to find archive log files.
If you had to move a data file, that fact has to be recorded in the control file. That is done by
executing the ALTER DATABASE RENAME FILE command, as shown in the following
example:
SQL> ALTER DATABASE RENAME FILE
2> '/u01/app/oracle/oradata/ORCL/datafile/survey01.dbf' TO
3> '/newdisk/ORCL/datafile/survey01.dbf';
Note: You must start the instance and mount the database before executing the ALTER
DATABASE RENAME FILE command.
Restoring Recovery-Related Files (continued)

If you have not yet done so, mount the database and bring all the data files online. You can
check the status of each data file by querying the V$DATAFILE view. Bring the data files
online by using a command like the following:
SQL> ALTER DATABASE DATAFILE \
2 > '/newdisk/ORCL/datafile/survey01.dbf' ONLINE;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Applying Redo Data
1. Apply redo data using the RECOVER command:

SQL> RECOVER AUTOMATIC FROM '/u01/arch_temp' DATABASE;
Apply each redo log

Alternate location for
without prompting.
restored archive log files
ble
Could be DATABASE, fe r a
TABLESPACE, or DATAFILE
ans
n - t r
a no
2. Open the database: a s
) h i d eฺ
SQL> ALTER DATABASE OPEN; m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Applying Redo Datauki
a s y ense
Now the dataM
y c restored to some point in the past. The archive log files have also
files havelibeen
a n le either to their default location or to some other location, for the purpose of this
been restored:
S t
recovery only. You are ready to perform the actual recovery step, which means the redo is
applied and the data files are brought up to the latest SCN. Do that using the SQL*Plus
RECOVER command.
If you do not specify the AUTOMATIC option, then you are prompted for each redo log file that
is about to be applied. That gives you more control over the recovery process. Typically,
AUTOMATIC is used for full recovery.
If the archive log files have been restored to some disk location other than the default for the
database, then you must specify the FROM clause. Supply the directory where the files are stored,
and the recovery process will look there for the files.
Finally, open the database. It is now fully recovered.

Performing Complete Open Database Recovery
Query for files to recover.

Take tablespace(s) with damaged data files offline.
Query for needed archive logs. Diagnose media problem.
Yes Can bring

Done data files
online?
No
a b le
Restore damaged files and archive logs. r
n s fe
n - tra
Recover data files.
a no
a s
) h i d eฺ
Bring tablespaces online. m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u nsDatabase
Open e Recovery
s y
a lwhile e the database is open, the database continues to function. When an
If media failure
M occurs i c
y to write to one of these data files, the data file is taken offline automatically. A
attempt
n isemade
l
Sta against one of these data files does not cause it to go offline, but it does result in an error
query
being returned to the user that issued the query.
As with the closed database recovery, you first need to query for the files and archive logs that
need to be recovered. Then, take all tablespaces that contain damaged data files offline. Use a
command such as the following to do this:
SQL> ALTER TABLESPACE survey OFFLINE TEMPORARY;
Using the TEMPORARY option causes Oracle to perform a checkpoint on any online data files
belonging to the tablespace. Checkpointed data files do not require recovery when they are
brought back online, because they are up-to-date for the latest SCN of any transactions that
would have affected them. This is the more desirable option, although the data files must be
available at the time this command is run. It is possible that the problem was temporary, and you
are able to bring the tablespaces online with no errors.

Performing Complete Open Database Recovery (continued)

Inspect the media to determine the cause of the problem. You can use the DBVERIFY utility for
this. If the files are permanently damaged, then proceed to restore and recover as described for
the closed database recovery earlier in this lesson. After the restore and recovery steps are
complete, bring all the tablespaces online again.
Note: For more information about the DBVERIFY utility, see the Backup and Recovery User’s
Guide.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Incomplete Recovery: Overview
Recover the database to a past point in time in the following
situations:
• You want the database to be in the state that existed before
a user error or an administrative error occurred.
• The database contains corrupt blocks after you tried block
media recovery.
• You are unable to perform complete database recovery
because some of the redo log files are missing. le
a b
• You want to create a test database that is in the state at sfer
some time in the past. - t r an
n o n
• One or more unarchived redo log files and a data
a file are
a s
lost. ) h deฺ m u i
o G
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
y u ki Incomplete
s e Recovery: Overview
An incomplete
s n
a liciseone that does not bring the database back to the most recent SCN that
recovery
M
l ey For some reason, as listed in the slide, you need to recover that database only up
was transacted.
n
toSata
point in the past, not to the present. The processing that occurs when performing incomplete
recovery differs from the processing for complete recovery, basically, in the amount of redo that
is applied.

Choosing an Incomplete Recovery Method
Indicate when to stop applying redo data by:

• Specifying a time at which to stop

• Specifying an SCN at which to stop
• Issuing a CANCEL command while the recovery is executing
Time = August 23, 2007 01:00 AM

CANCEL
ble
SCN = 1200 fe r a
ans
n - t r
a no
Applying redo data ) ha
s
i d eฺ Now
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Choosing an Incomplete k i
u Recovery e Method
s y
aincomplete n s
e recovery, decide which method you want to use for specifying
As you plan your
M l i c
when n ey applying redo data. You stop the recovery process by specifying one of the
tolstop
Sta
following:
• A time: The time in the logs at which recovery should stop. This can be automated so that
the process does not prompt you for each file name.
• An SCN: The system change number at which recovery should stop. This can be automated
so that the process does not prompt you for each file name.
• CANCEL: Specify the CANCEL keyword when the recovery process prompts for the next
redo log file name. You cannot automate this process because you must specify CANCEL to
terminate the recovery operation.

Incomplete Recovery
• Recover a database until time:
SQL> RECOVER DATABASE UNTIL

2 TIME '2005-12-14:12:10:03';
• Recover a database until cancel:

SQL> RECOVER DATABASE UNTIL CANCEL;
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Performing User-Managed i
u nIncomplete
e Recovery
s y s
a liciseused to perform incomplete recovery:
The followingMcommand
n l eyRECOVER [AUTOMATIC] DATABASE option
Sta are the meanings of the options:
Following
• AUTOMATIC: Automatically applies archived and redo log files
• option: UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS'
UNTIL CANCEL
UNTIL CHANGE <integer>
USING BACKUP CONTROLFILE
Cancel-Based Incomplete Recovery
Cancel-based incomplete recovery is very much like closed database complete recovery. The
difference is how you execute the RECOVER command; specify the UNTIL CANCEL clause.
This clause causes the recovery process to prompt you with the suggested name for each redo
log file to be applied. So, as the recovery proceeds, you are prompted with an archived or online
redo log file name, and, for each one, you can either accept it or change it. When you reach the
point where you want the recovery to stop, enter CANCEL instead of accepting the file name.
This stops the recovery.
After this is done, you have to open the database with the RESETLOGS option. The database is
in another instantiation now, so the redo log sequence numbers need to be reset.

Performing User-Managed Incomplete Recovery (continued)

After opening the database, check the alert log for messages. This is how you find out if the
recovery was successful.
Time- and Change-Based Incomplete Recovery
Both time- and change-based incomplete recovery are like the cancel-based recovery, except
that different criteria are used to specify when to stop the recovery. Time-based recovery uses a
time specified on the command line of the RECOVER command, to know when to stop. Change-
based recovery uses an SCN, specified on the command line.
As with all incomplete recoveries, the database must then be opened using the RESETLOGS
option.
Note: To apply redo log files automatically during recovery, you can use the SQL*Plus SET
AUTORECOVERY ON command, enter AUTO at the recovery prompt, or use the RECOVER
AUTOMATIC command.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Incomplete Recovery: Steps
To perform user-managed incomplete recovery, follow these
steps:
1. Shut down the database.
2. Restore data files.
3. Mount the database.
4. Recover the database.
5. Open the database with the RESETLOGS option.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing User-Managed k i
u nIncomplete e Recovery: Steps
s y
a is open, s
eshut it down by using the NORMAL, IMMEDIATE, or
1. If the database
M l i c
l ey
TRANSACTIONAL
n option.
t a
S2. Restore all data files from backup. You must use a backup taken before the time you plan to
recover to. You may also need to restore archived logs. If there is enough space available,
restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE
LOG START TO <LOCATION> command or the SET LOGSOURCE <LOCATION>
command to change the location. If you perform incomplete recovery to a point when the
database structure is different than the current, you also need to restore the control file.
4. Recover the database by using the RECOVER DATABASE command.
5. To synchronize data files with control files and redo logs, open the database by using the
RESETLOGS option.

User-Managed Time-Based Recovery: Example
This is the scenario:

• A job ran in error, and its effects must be undone.

• This happened 15 minutes ago, and there has been little
database activity since then.
• You decide to perform incomplete recovery to restore the
database back to its state as of 15 minutes ago.
bl e
fe r a
$ cp /BACKUP/*.dbf /u01/db01/ORADATA
n s
SQL> STARTUP MOUNT
n - tra
SQL> no
RECOVER DATABASE UNTIL TIME '2005-11-28:11:44:00';
a
SQL> ALTER DATABASE OPEN RESETLOGS; as ) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to Example
User-Managed Time-Based
y u ki sRecovery:
e
The followingM
s cscenario
isaa typical en employing UNTIL TIME recovery. Assume the following
l i
facts: nley
S• taThe current time is 12:00 PM on November 28, 2005.
• A job was run incorrectly, and many tables in several schemas were affected.
• This happened at approximately 11:45 AM.
• Database activity is minimal because most staff are currently in a meeting. The state of the
database before the job ran must be restored.
Because the approximate time of the error is known and the database structure has not changed
since 11:44 AM, you can use the UNTIL TIME method:
1. If the database is open, shut it down by using the NORMAL, IMMEDIATE, or
TRANSACTIONAL option.
2. Restore all data files from backup (the most recent if possible). You may also need to
restore archived logs. If there is enough space available, restore to the
LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START
TO <LOCATION> command or the SET LOGSOURCE <LOCATION> command to
change the location.

User-Managed Time-Based Recovery: Example (continued)

4. Recover the database:
SQL> recover database until time '2005-11-28:11:44:00'
ORA-00279: change 148448 … 11/27/05 17:04:20 needed for
thread ...
Media recovery complete.
5. To synchronize data files with control files and redo logs, open the database by using the
RESETLOGS option:
SQL> alter database open resetlogs;
SQL> archive log list
...
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
When recovery is successful, notify users that the database is available for use, and any data
entered after the recovery time (11:44 AM) will need to be reentered.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

User-Managed Cancel-Based Recovery: Example
The scenario is the same as the one for the time-based

example, except for these findings:

• Redo logs are not multiplexed.
• One of the online redo logs is missing.
• The missing redo log is not archived.
• The redo log contained information from 11:34 AM.
• Twenty-six minutes of data are lost.
• Users can reenter their data manually. ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
User-Managed Cancel-Based i
u nseRecovery: Example
s y
a lithe edirectory for the redo log files, you notice that redo log
After searching
M through c
l
log2a.rdo
n ey cannot be located and has not been archived. Therefore, you cannot recover past
Stapoint.
this
Querying V$ARCHIVED_LOG confirms the absence of archived log sequence 48
(log2a.rdo):
SQL> SELECT * FROM v$archived_log;
RECID STAMP ... FIRST_CHANGE# FIRST_TIME
----- --------- ... ------------- ----------
1 318531466 ... 88330 05-11-15:12:43
47 319512880 ... 309067 05-11-28:11:26

User-Managed Cancel-Based Recovery: Example
Recover the database as follows:

• Shut down the database.

• Restore all data files from the most recent backup.
• Mount the database.
• Execute RECOVER DATABASE UNTIL CANCEL.
• Execute ALTER DATABASE OPEN RESETLOGS to open the
database.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
User-Managed Cancel-Based i
u nseRecovery: Example (continued)
s y
a licerecovery are the same as for time-based recovery, except for the
The steps for M
cancel-based
RECOVER
n l eyDATABASE step. When the RECOVER DATABASE UNTIL CANCEL command is
Sta it recovers the database until it cannot find a log file. When you are prompted for the
executed,
name of the missing archived redo log file, enter CANCEL; the recovery stops at that point in
time.

Recovering a Read-Only Tablespace
Special user-managed backup and recovery considerations for

a read-only tablespace:
• You do not have to put it in backup mode in order to make a
copy of its data files.
• You do not have to take the tablespace or data file offline
before making a copy of it.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Recovering a Read-Only k i
u Tablespace
a s y e n se
Because read-only
y lic are not being written to, there are special considerations to take
M tablespaces
a n le which can make the recovery process faster and more efficient. You do not have to
into account,
putt
S a read-only tablespace into backup mode or take it offline before copying it to the backup
location. Simply copy it.
When restoring a read-only tablespace, take the tablespace offline, restore the data files
belonging to the tablespace, and then bring the tablespace back online.
Consider the following scenario, where a read-only tablespace is changed to be read/write:
1. Make a backup of a read-only tablespace.
2. Make the tablespace read-write.
3. Recover the tablespace.
The backup you made in step 1 can still be used to recover this tablespace, even though, since
the backup was made, the tablespace was made read-write, and has even possibly been written
to. In this case, the tablespace requires recovery, after the files are stored from such a backup.

Recovering NOLOGGING Database Objects

Redo log
ble
fe r a
SQL> CREATE TABLE sales_copy NOLOGGING; ans
SQL> INSERT /*+ APPEND */ INTO sales_copy n - t r
2 SELECT * FROM sales_history; a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to Objectsu
Recovering NOLOGGING k i Database
a s yu ense
Take advantage
y l ic
M of the efficiencies of the NOLOGGING attribute of tables and indexes if you can.
When you
a n le create a table as NOLOGGING, minimal redo data is written to the redo stream to
t
support
S the creation of the object. This is useful for making large inserts go faster.
In the example in the slide, the SALES_COPY table is created as a NOLOGGING table. As a
result, when an insert is done with the APPEND hint, no redo is generated for that particular
insert statement. As a result, you cannot recover this transaction on the SALES_HISTORY table.
If that is a problem, it is important that you make a backup of whatever tables you populate in
this way, right afterward. Then you are able to go to the more recent backup of the table.
If you perform media recovery, and there are NOLOGGING objects involved, they will be
marked logically corrupt during the recovery process. In this case, drop the NOLOGGING objects
and re-create them.

Recovering from the Loss of

All Control File Copies: Overview
Current Backup
Available Restore backup control file, Restore backup control file,

perform complete recovery, perform complete recovery,
OPEN RESETLOGS OPEN RESETLOGS
Unavailable Re-create control file, OPEN Restore backup control file,

RESETLOGS perform incomplete recovery,
OPEN RESETLOGS
bl e
fe r a
Online log status
tra
Data file-status
ns
n on
s a
a
) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Recovering from theuLoss
y ki ofseAlltoControl File Copies: Overview
Even though you
s copies
ahave c enof the control file stored in different locations, there is still the
M l i
l eythat you will, at some point, have to recover from losing all of those copies. If you
possibility
n
Stalost all copies of the current control file, and have a backup control file, your course of
have
action depends on the status of the online log files and the data files. The chart in the slide shows
what to do in each of the situations shown.
Online Logs Available
If the online logs are available and contain redo necessary for recovery, and the data files are
current, then you can restore a backup control file, perform complete recovery, and open the
database with the RESETLOGS option. You must specify the file names of the online redo logs
during recovery. If the data files are not current, perform the same procedure.
Online Logs Not Available
If the online logs are not available, and the data files are current, then re-create the control file
and open RESETLOGS. However, if the data files are not current, restore a backup control file,
perform incomplete recovery, and open RESETLOGS.

Recovering the Control File

to the Default Location
No
Database
Repair hardware.
open?
Yes Restore control file.
SHUTDOWN ABORT
STARTUP MOUNT Open database
using
RESETLOGS.
Start database recovery. ble
fe r a
ans
No
n - t r
no
Archivelog
missing?
s a
) h a eฺ online log.
m i d
l ฺ o t Gu
cYes
Specify
i
g ma tuden
sy se th
a
(M to u
Recovering the Control k i
u nstoe the Default Location
File
s y
a the e
If you need toM
y
recover l i c control file, and the default location is still a valid one, follow the
a n le in the slide. The database must be shut down first. Then repair any hardware, so that
steps shown
the t
S default location is able to remain as a valid one. Restore the control file to the default
location. Do this using a command such as this, which copies the backup control file to the
default location:
% cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
% cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf
Mount the database, and start the recovery process. You must specify that a backup control file
is being used.
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
If, during the recovery process, you are prompted for a missing redo log, it probably means that
the missing redo log is an online redo log file. When prompted, supply the name of the online
redo log file. After the recovery completes, open the database, specifying the RESETLOGS
option.

Summary

• Describe the difference between user-managed and server-

managed backup and recovery
• Manually back up a data file, tablespace, and database
• Back up and recover a control file
• Perform user-managed complete database recovery
• Perform user-managed incomplete database recovery
• Recover from a lost TEMP file ble
fe r a
• Recover from a lost redo log group ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Performing User-Managed Recovery
• Backing up a NOARCHIVELOG database

• Recovering from lost control files
• Recovering from the loss of a redo log group
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Perform Recovery
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives
After completing this lesson, you should be able to use RMAN

to:
• Perform complete recovery when a critical or noncritical data
file is lost
• Recover using incrementally updated backups
• Switch to image copies for fast recovery
• Restore a database onto a new host
• Recover using a backup control file ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN RESTORE and RECOVER Commands
• RESTORE command: Restores database files from backup

• RECOVER command: Recovers restored files by applying

changes recorded in incremental backups and redo log files
RMAN> SQL 'ALTER TABLESPACE inv_tbs OFFLINE IMMEDIATE';

RMAN> RESTORE TABLESPACE inv_tbs;
RMAN> RECOVER TABLESPACE inv_tbs;
ble
RMAN> SQL 'ALTER TABLESPACE inv_tbs ONLINE';
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(MRECOVER u
Using RMAN RESTORE k
u nsei
and t o Commands
s y
a contents eof an entire database or a part of it from a backup typically involves
Reconstructing
M the l i c
l eyretrieving a copy of the data file from a backup, and reapplying changes to the file
two phases:
n
Stathe backup from the archived and online redo logs, to bring the database to the desired
since
SCN (usually the most recent one).
The RESTORE command retrieves the data file 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
archived redo logs required during the recovery operation. If backups are stored on a media
manager, channels must be configured or allocated for use in accessing backups stored there.
The RECOVER command takes the restored copy of the data file and applies to it the changes
recorded in the incremental backups and database’s redo logs.
Refer to the Oracle Database Backup and Recovery User’s Guide for additional information and
examples using the RESTORE and RECOVER commands.

Performing Recovery Using Enterprise Manager
The Enterprise Manager Recovery Wizard creates and runs an

RMAN script to perform the recovery.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing Recovery k i
u nsEnterprise
Using e Manager
s y
a complete e or incomplete recovery by using the Recovery Wizard available
You can also M perform l i c
throughn l ey
Enterprise Manager. On the Availability page, click Perform Recovery in the
t a
Backup/Recovery
S section.
Note: An automated method of detecting the need for recovery, and carrying out that recovery
makes use of the Data Recovery Advisor, which is covered in the lesson titled “Diagnosing the
Database.”

Performing Complete Recovery: Loss of a

Noncritical Data File in ARCHIVELOG Mode
If a data file is lost or corrupted, and that file does not belong to
the SYSTEM or UNDO tablespace, then restore and recover the

missing data file.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toLoss u
Recovery:
u nse of a Noncritical Data File in ARCHIVELOG
Mode s y
a lice
y M
With the
n l edatabase in ARCHIVELOG mode, the loss of any data file not belonging to the
S t a
SYSTEM or UNDO tablespaces affects only those objects that are in the missing file.
To restore and recover the missing data file using Enterprise Manager, perform the following
steps:
1. Click Perform Recovery on the Availability properties page.
2. Select “Datafiles” as Recovery Scope and “Restore datafiles” as Operation Type.
3. Add all data files that need recovery.
4. Specify from what backup the files are to be restored.
5. Determine whether you want to restore the files to the default location or (if a disk or
controller is missing) to a new location.
6. Submit the RMAN job to restore and recover the missing files.
Because the database is in ARCHIVELOG mode, recovery up to the time of the last commit is
possible and users are not required to reenter any data.

Performing Complete Recovery: Loss of a

System-Critical Data File in ARCHIVELOG Mode
If a data file 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 shut the instance
down.
3. Restore and recover the missing data file.
4. Open the database. bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toLoss u
Recovery:
u nse of a System-Critical Data File in ARCHIVELOG
Mode s y
a lice
y M
Data files
n l ebelonging to the SYSTEM tablespace or containing UNDO data are considered system
t a
critical.
S A loss of one of these files requires the database to be restored from the MOUNT state
(unlike other data files that may be restored with the database open).
Perform the following steps for complete recovery:
1. If the instance is not already shut down, shut it down.
3. Click Perform Recovery on the Maintenance properties page.
4. Select “Datafiles” as the recovery type, and then select “Restore to current time.”
5. Add all data files that need recovery.
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.
7. Submit the RMAN job to restore and recover the missing files.
8. Open the database. Users are not required to reenter data because the recovery is up to the
time of the last commit.
Note: This kind of recovery situation is detected by the Data Recovery Advisor, which is
covered in the lesson titled “Diagnosing the Database.”

Recovering Image Copies
RMAN can recover image copies by using incremental

backups:
• 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. e
r a bl
RMAN> RECOVER COPY OF
s fe
an
2> DATAFILE {n|'file_name'}
n - t r
Incremental a no
a s
deฺ
backup files h
m )Imageucopy
i
o G file
a ilฺc enoft data
@ gm Stud
u
Copyright
s
a use
( M
Recovering Image Copies
y u ki se to
You can use RMAN
M as to lapply
i c enincremental backups to data file image copies. With this recovery
method,
n l eyouy use RMAN to recover a copy of a data file—that is, you roll forward (recover) the
Sta copy to the specified point in time by applying the incremental backups to the image
image
copy. The image copy is updated with all changes up through the SCN at which the incremental
backup was taken. RMAN uses the resulting updated data file 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
of the database every day. The following are the benefits of applying incremental backups to
data file image copies:
• You reduce the time required for media recovery (using archive logs) because you need to
apply archive logs only since the last incremental backup.
• You do not need to perform a full image copy after the incremental restoration.
If the recovery process fails during the application of the incremental backup file, you simply
restart the recovery process. RMAN automatically determines the required incremental backup
files to apply, from before the image data file copy until the time at which you want to stop the
recovery process. If there is more than one version of an image copy recorded in the RMAN
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.

Recovering Image Copies: Example
If you run these commands daily:

RMAN> recover copy of database with tag 'daily_inc';

RMAN> backup incremental level 1 for recover of copy
2> with tag 'daily_inc' database;
This is the result:

RECOVER BACKUP
ble
Day 1 Nothing Create image copies
fe r a
ans
Day 2 Nothing r
Create incremental level 1
n - t
Day 3 and Recover copies based on a no
Create incremental level 1
a s
onward incremental
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Recovery Image Copies: k i
u Example
a s y e n se
If you run theM
y
commands licshown in the slide daily, you get continuously updated image copies of
le data files at any time.
all thendatabase
a
t
S chart shows what happens for each run. Note that this algorithm requires some priming; the
The
strategy does not come to fruition until after day 3.
Day 1
The RECOVER command does nothing. There exist no image copies to recover yet. The
BACKUP command creates the image copies.
Day 2
The RECOVER command, again, does nothing. This is because there is no incremental backup
yet. The BACKUP command creates the incremental backup, now that baseline image copies
have been created on day 1.
Day 3
The RECOVER command applies the changes from the incremental backup, to the image copies.
The BACKUP command takes another incremental backup, which will be used to recover the
image copies on day 4. The cycle continues like this.

Recovery Image Copies: Example (continued)

It is important to use tags when implementing this kind of backup strategy. They serve to link
these particular incremental backups to the image copies that are made. Without the tag, the
most recent, and possibly the incorrect, incremental backup would be used to recover the image
copies.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Performing a Fast Switch to Image Copies
Perform fast recovery by Optionally, do the following

performing the following to put the files back into

steps: their original location:
1. Take data files offline. 5. Create an image copy of
2. Use the SWITCH TO ... the data file in the
COPY command to switch original location.
to image copies. 6. Take data files offline.
3. Recover data files. 7. SWITCH TO ... COPY e
r a bl
4. Bring data files online. 8. Recover data files. s fe
9. Bring data files - t r an
online.
Now the data files are recovered n no
and usable in their new location. s a
) h a eฺ
m i d
SQL> SWITCH DATAFILE 'filename' TO COPY;
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Performing a Fast Switch k i
u ntosImage e Copies
s y
a copies eof data files for fast recovery by performing the following steps:
You can use image
M l i c
y data file offline.
1. Take
n l ethe
S2.taUse the SWITCH TO ... COPY command to point to the image copy of the files.
3. Recover the data files.
4. Bring the data files online.
At this point, the database is usable, and the data files are recovered. But, if you want to put the
data files back into their original location, proceed with the following steps:
5. Create an image copy of the data files in the original location using the BACKUP AS COPY
command.
6. Take the data files offline.
7. Switch to the copy you made in step 5 using the SWITCH TO COPY command.
8. Recover the data files.
9. Bring the data files online.
You can recover data files, tablespaces, tempfiles, or the entire database with this command. The
files being switched to must be image copies.

Using SET NEWNAME for Switching Files
For RUN blocks, you can use the SET NEWNAME command to
prepare for SWITCH commands.

RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE DISK;
ALLOCATE CHANNEL dev2 DEVICE TYPE sbt;
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
SET NEWNAME FOR DATAFILE
'/disk1/oradata/prod/users01.dbf'
ble
TO '/disk2/users01.dbf';
fe r a
RESTORE TABLESPACE users;
ans
SWITCH DATAFILE ALL;
n - t r
RECOVER TABLESPACE users; a no
a s
SQL "ALTER TABLESPACE users ONLINE";
) h i d eฺ
} m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to uFiles
Using SET NEWNAMEufor k i Switching
a s y ense
The SET NEWNAME
y M commandl ic can be used only inside a RUN block. It prepares a name
mappinglefor subsequent operations. In the example in the slide, the SET NEWNAME command
t a
defines
n
S the location where a restore operation of that data file will be written. When the
RESTORE command executes, the users01.dbf data file is restored to
/disk2/users01.dbf. It is written there, but the control file is still not pointing to that
location. The SWITCH command causes the control file to be updated with the new location.

Performing Restore and Recovery of a Database

in NOARCHIVELOG Mode
• If the database is in NOARCHIVELOG mode, and any data file
is lost, perform the following tasks:

– Shut down the instance if it is not already down.
– Restore the entire database, including all data and control
files, from the backup.
– Open the database.
• Users must reenter all changes made since the last backup.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
Performing Restore u k
and i (Recovery
e of a Database in NOARCHIVELOG Mode
s y
a filelicfrom n s
e a database in NOARCHIVELOG mode requires complete
The loss of anyM data
l
restoration
n eyof the database, including control files and all data files. If the lost data file belongs
toSata
read-only tablespace, you need to restore only that file.
With the database in NOARCHIVELOG mode, recovery is possible only up to the time of the last
backup. So users must reenter all changes made since that backup.
For this type of recovery, use the RESTORE and RECOVER commands, or perform the following
tasks in Enterprise Manager:
1. Shut down the instance if it is not already down.
2. Click Perform Recovery on the Maintenance properties page.
3. Select Whole Database as the type of recovery.

Creating Restore Points
A restore point provides a name to a point in time:

• Now:
SQL> CREATE RESTORE POINT before_mods;
• Some time in the past:

SQL> CREATE RESTORE POINT end_q1 AS OF SCN 100;
bl e
fe r a
ans
Timeline n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating Restore Points k i
a s yu ense
You can giveMa name toliacparticular point in time, or an SCN number. This is useful for future
y
t a nlewhen performing point-in-time recovery or flashback operations.
reference,
S first example in the slide creates a restore point that represents the present point in time. If
The
you were about to apply an update of an application or data in the database, and you wanted to
refer back to this state of the database, you could use the BEFORE_MODS restore point.
The second example in the slide creates a restore point representing a past SCN, 100. This
restore point can be used in the same ways as the previous one.
Normally, restore points are maintained in the database for at least as long as specified by the
CONTROL_FILE_RECORD_KEEP_TIME initialization parameter. However, you can use the
PRESERVE option when creating a restore point, which causes the restore point to be saved
until you explicitly delete it.
Restore point usage with point-in-time recovery is covered later in this lesson. Using restore
points with Flashback technology is covered in the lesson titled “Additional Flashback
Operations.”

Performing Incomplete Recovery
Perform server-managed incomplete recovery by doing the

following:
1. Determine the target point of the restore: SCN, time,
restore point, or log sequence number.
2. Set the NLS environment variables appropriately.
4. Prepare and run a RUN block, using the SET UNTIL,
RESTORE, and RECOVER commands. b le
r a
5. Open the database in READONLY mode, and verify thatnsfe
the recovery point is what you wanted. n - tra
o
6. Open the database using RESETLOGS. s a n
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Performing Incomplete u kiRecovery
e to
y s
s cen incomplete recovery using the following steps. The database
aserver-managed
You can performM li mode.
e
must be lin yARCHIVELOG
n
S1.taDetermine the restore target. This can be in terms of a date and time, an SCN, restore point,
or log sequence number. For example, if you know that some bad transactions were
submitted at 3:00 PM yesterday, then you can choose 2:59 PM yesterday as the target
restore point time.
2. Set the National Language Support (NLS) OS environment variables, so that the time
constants you provide to RMAN are formatted correctly. These are some example settings:
$ export NLS_LANG = american_america.us7ascii
$ export NLS_DATE_FORMAT = "yyyy-mm-dd:hh24:mi:ss"
3. Mount the database. If it is open, you have to shut it down first, as in this example:
RMAN> shutdown immediate
RMAN> startup mount

Performing Incomplete Recovery (continued)

4. Create a RUN block and run it. The RECOVER and RESTORE commands should be in the
same RUN block so that the UNTIL setting applies to both. For example, if you choose to
recover to a particular SCN, the RESTORE command needs to know that value so it restores
files from backups that are sufficiently old—that is, backups that are from before that SCN.
Here is an example of a RUN block:
RUN
{
SET UNTIL TIME '2007-08-14:21:59:00';
RESTORE DATABASE;
RECOVER DATABASE;
}
5. As soon as you open the database for read/write, you have committed to the restore you just
performed. So, first, open the database READ ONLY, and view some data, to check whether
the recovery did what you expected.
RMAN> SQL 'ALTER DATABASE OPEN READ ONLY';
a b le
6. If satisfied with the results of the recovery, open the database with the RESETLOGS
s feroption,
as shown:
- t r an
RMAN> ALTER DATABASE OPEN RESETLOGS;
n on
s a
a
) h uideฺ
o m
a ilฺc ent G
@ gm Stud
y u ki this
a s se
( M u
y u ki se to
M as licen
n l ey
Sta

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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing Recovery k i
u nasBackup
with e Control File
a s y e the current control file, you must restore and mount a backup
If you have lost
M all copies
l i c of
l eybefore performing recovery. Your recovery operation may be to recover lost data
controlnfile
Staor it may be to simply recover the control file. If you are using a recovery catalog, the
files
process is identical to recovery with a current control file because RMAN can use the recovery
catalog to obtain RMAN metadata.

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
ble
fe r a
ans
n - t r
Server a no
a s
parameter ) h i d eฺ
file Database m
co nt Gu
i l ฺ
g ma tude
sy se th
a
k
Restoring the ServeruParameter i (M e toFileu from the Control File Autobackup
If you have lost a
the
ns file, you can restore it from the autobackup. The procedure
syserverceparameter
M
yrestoring li
is similar
n l eto the control file from autobackup. If the autobackup is not in the flash
t a
recovery
S area, set the DBID for your database. Issue the RESTORE SPFILE FROM
AUTOBACKUP command.
If you are restoring the SPFILE to a nondefault location, specify the command as follows:
RESTORE SPFILE TO <file_name> FROM AUTOBACKUP
If you are restoring the server parameter file from the Flash Recovery Area, specify the
command as follows:
RMAN> run {
2> restore spfile from autobackup
3> recovery area = '<flash recovery area destination>'
4> db_name = '<db_name>';
5> }

Restoring the Control File from Autobackup
Recovery
Manager
(RMAN) Flash Recovery
Area
Control
file
Database ble
fe r a
tra ns
RMAN> STARTUP NOMOUNT;
n -
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
a no
RMAN> ALTER DATABASE MOUNT;
a s
RMAN> RECOVER DATABASE; ) h i d eฺ
m u
RMAN> lฺco t G
ALTER DATABASE OPEN RESETLOGS;
ai den
m
g Stu
Copyright
t h
( M a use
Restoring the Control u i from
kFile e o
tAutobackup
y
as a recovery s
en catalog, you should have autobackup of the control file
If you are notM
using l i c
l eyso that you are able to quickly restore the control file if needed. The commands used
configured,
n
for a
Strestoring your control file are the same, whether or not you are using a Flash Recovery Area.
However, if you are using a Flash Recovery Area, RMAN implicitly cross-checks backups and
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.
Use the commands shown in the slide to recover from lost control files. First, start the instance
in NOMOUNT mode. It cannot be mounted because there is no control file. Restore the control
file from backup. Now that there is a control file, you can mount the database. You must now
recover the database, because you now have a backup control file that contains information
about an older version of the database. After recovering the database, you can open it. You must
specify RESETLOGS because the new control file represents a different instantiation of the
database.
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
must cross-check the backups on tape.

Restoring the Control File from Autobackup (continued)

To restore the control file from an autobackup, the database must be in a NOMOUNT state. If the
autobackup is not in the flash recovery area, you must set the database identifier (DBID) before
issuing the RESTORE CONTROLFILE FROM AUTOBACKUP command, as shown in the
following example:
RMAN> SHUTDOWN ABORT;
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: le b
RMAN> RESTORE CONTROLFILE; fe ra
The instance must be in the NOMOUNT state when you perform this operation, and ns
traRMAN must
n -
be connected to the recovery catalog. The restored control file is writtenntooall locations listed in
the CONTROL_FILES initialization parameter. s a
a
) hcommand etoฺ restore the control
Use the RESTORE CONTROLFILE... TO <destination> m i d
file to a nondefault location. i l ฺ co nt Gu
g maand need
If you have also lost the SPFILE for the database t u deto restore it from the autobackup, the
k i@file from
procedure is similar to restoring the control i s Sautobackup. You must first set the DBID
u
syRESTORE t h
for your database, and then usea
M(
the
use SPFILE FROM AUTOBACKUP command.
After you have started the
u k i instance
e o the restored server parameter file, RMAN can restore
twith
the control file from y en s
as theliautobackup. After you restore and mount the control file, you have the
y M
backup information
c
necessary to restore and recover the database.
n l e
S tarestoring
After the control files of your database from backup, you must perform complete
media recovery and then open your database with the RESETLOGS option.

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 NOMOUNT;

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE NOREDO;
ble
ALTER DATABASE OPEN RESETLOGS;
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to Recoveru
Using Incremental Backups k
u nsei t o a Database in NOARCHIVELOG Mode
s y
alimitedlicrecovery
e
You can perform
M of a NOARCHIVELOG mode database by using incremental
y
backups.
t a nleThe incremental backups must be consistent backups.
IfSyou have taken incremental backups, RMAN will use your level 0 and level 1 backups to
restore and recover the database.
You must specify the NOREDO option on the RECOVER DATABASE command if the online redo
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
incremental backups. If the online redo log files are not available, RMAN issues an error
message.
If the current online redo log files contain all changes since the last incremental backup, you can
issue the RECOVER DATABASE command without the NOREDO option and the changes will be
applied.
Note: You need to restore the control file only if it is not current.

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>
ble
fe r a
ans
n - t r
Server Server o
parameter file an
parameter file
s
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Restoring and Recovering k i
u nthe e Database on a New Host
s y
a described s
e on the following pages to perform test restores. You can also use it
Use the procedure
y M l i c
to moven l ea production database to a new host.
t a
S database identifier (DBID) for the restored test database is the same as the DBID of the
The
original database. If you are using a recovery catalog and connect to the test database and the
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.
You should create a duplicate database using the RMAN DUPLICATE command if your goal is
to create a new copy of your target database for ongoing use on a new host. The duplicate
database is assigned a new DBID that allows it to be registered in the same recovery catalog as
the original target database. Refer to the lesson titled “Using RMAN to Duplicate a Database”
for detailed information about the DUPLICATE command.

Preparing to Restore the Database to a New Host
To prepare to restore a database, perform the following steps:

• Record the database identifier (DBID) of your source

database.
• Copy the source database initialization parameter file to the
new host.
• Ensure that source backups, including the control file
autobackup, are accessible on the restore host.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
Preparing to Restoreuthe k i (Database
e to a New Host
s y n s
alistedliincethe slide to prepare for the restore of the database to a new host.
Perform the steps
M
Ifle
Note: n
y
you are performing a test restore, do not connect to the recovery catalog when restoring
a files. If you connect to the recovery catalog, RMAN records information about the
Stdata
the
restored data files in the recovery catalog and considers the restored database as the current
target 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, then export the
catalog and import it into a different schema or database. Use the copied recovery catalog for the
test restore.

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. Restore the server parameter file from the backup sets. a b le
6. Shut down the instance. s fer
- t r an
7. Edit the restored initialization parameter file. non
8. Start the instance in NOMOUNT mode. as a ฺ
m ) h uide
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M toHost
Restoring the Database
y u ki to asNew e
Perform the steps
s on
alisted c n page and the next on the restore host to restore the database.
ethis
M l i
l ey the ORACLE_SID environment variable as shown in the following example:
1. Configure
n
Sta $ setenv ORACLE_SID orcl
2. Start RMAN and connect to the target instance. Do not connect to the recovery catalog as
shown in the following example:
$ rman TARGET /
3. Set the database identifier (DBID). You can find the DBID of your source database by
querying the DBID column in V$DATABASE.
RMAN> SET DBID 1090770270;
4. Start the instance in NOMOUNT mode:
RMAN> STARTUP NOMOUNT
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.
startup failed: ORA-01078: failure in processing system
parameters

Restoring the Database to a New Host (continued)

5. Restore the server parameter file from the backup sets and shut down the instance as shown
in the example:
RESTORE SPFILE TO PFILE '?/oradata/test/initorcl.ora' FROM
AUTOBACKUP;
6. Shut down the instance:
SHUTDOWN IMMEDIATE;
7. Edit the restored initialization parameter file to change any location-specific parameters,
such as those ending in _DEST, to reflect the new directory structure.
8. Start the instance in NOMOUNT mode using your edited text initialization parameter file.
RMAN> STARTUP NOMOUNT
> PFILE='?/oradata/test/initorcl.ora';
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Restoring the Database to a New Host
9. Create a RUN block to:

– Restore the control file

– Mount the database
10. Create the RMAN recovery script to restore and recover
the database.
11. Execute the RMAN script.
12. Open the database with the RESETLOGS option.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Restoring the Database k i
u nasNew
to e Host (continued)
s y
a block erestore the control file from an autobackup and mount the database
9. Create aM RUN l i cto
as
n l ey in the example:
shown
Sta RUN
{
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}
10. Query V$DATAFILE on your new host to determine the database file names as recorded
in the control file. Create the RMAN recovery script to restore and recover the database,
including the following steps as appropriate:
a. Use the SET NEWNAME command to specify the path on your new host for each of
the data files that is restored to a different destination than on the original host.
b. Use the SQL ALTER DATABASE RENAME FILE command to specify the path for
the online redo log files.
c. Include the SET UNTIL command to limit recovery to the end of the archived redo
log files.
d. Include the SWITCH command so that the control file recognizes the new path names
as the correct names for the data files.

Restoring the Database to a New Host (continued)

An example of a recovery script follows:
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'' ";
ble
SET UNTIL SCN 4545727;
fe r a
RESTORE DATABASE;
ans
SWITCH DATAFILE ALL;
n - t r
RECOVER DATABASE;
a no
}
a s
11. Execute the recovery script. ) h i d eฺ
12. Open the database with the RESETLOGS option:co m G u
i l ฺ t
ma tuden
RMAN> ALTER DATABASE OPEN RESETLOGS;
g
After you have completed your test, youi@
k can shut down
i s S the test database instance and delete the
test database with all its files. sy u t h
a s e
k i (M to u
a syu cense
yM li
n l e
Sta

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 data files
– Corresponding archived redo logs files e
r a bl
– At least one control file autobackup
s fe
- t r an
nno
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
k
Performing DisasteruRecovery i (M e to u
Disaster recoverya sy cethensrestoration and recovery of the target database after the loss of the
includes
M li
entire n l ey database, all current control files, all online redo log files, all parameter files, and
target
the a
Strecovery catalog database (if applicable).
To perform disaster recovery, the following backups are required as a minimum:
• Backups of data files
• Corresponding archived redo logs generated after the time of the backup
• At least one autobackup of the control file
Note: Refer to the Oracle Data Guard Concepts and Administration manual for information
about how Oracle Data Guard can provide complete disaster protection.

Performing Disaster Recovery
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 data files.
• Recover the data files.
ble
• Open the database with the RESETLOGS option. r a
s fe
- t r an
n
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
k
Performing DisasteruRecovery to u
i (M e (continued)
a e n s
syfor performing
The basic procedure
y M lic disaster recovery is outlined in the slide. After you have
mounted
t a nlethe database, follow the steps for performing recovery with a backup control file.
S

Summary
In this lesson, you should have learned how to use RMAN to do

the following:
• Perform complete recovery when a critical or noncritical data
file is lost
• Recover using incrementally updated backups
• Switch to image copies for fast recovery
• Restore a database onto a new host
e
• Recover using a backup control file abl fer
a n s
n -tr
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

Using RMAN to Perform Recovery
• Recovering image copies

• Performing fast recovery
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Duplicate a Database
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• List the purposes of creating a duplicate database

• List the methods of duplicating a database
• Duplicate a database using RMAN
• Use an RMAN backup to duplicate a database
• Duplicate a database based on a running instance
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Create a Duplicate Database
Use the RMAN DUPLICATE command to create a duplicate

database using target database backups.
Data file backups
ble
fe r a
an s
Archived
n - t r
redo log files
a no
Auxiliary instance
a s
Target database ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using RMAN to Create k i
u Duplicate
a e Database
s y
a islaiccopyn s
e of the target database (or a subset of the target database) with a
A duplicate database
M
l ey database identifier (DBID). The target database site and duplicate database site can
new, unique
n
be tathe same host or separate hosts. The duplicate database is created using backups and
Son
archived redo log files from the target database.

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
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
Using a Duplicate Database
a s yu ense
M islaiccopy of your target database. You can operate it independently of the
A duplicate database
y
target n
a le to:
database
t
S• Test backup and recovery procedures
• Recover objects that were inadvertently dropped from the target database by creating an
export containing the objects in the duplicate database and importing them into the
production database

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. a b le
7. Allocate auxiliary channels if needed. s fer
- t r an
8. Execute the DUPLICATE command. on
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
ki se to
Creating a DuplicateuDatabase
y
The basic steps
M ascreating
to l i c eanduplicate database are outlined in the slide. More detail is provided
in the n l ey for some of the steps.
lesson
Sta

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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating an Initialization k i
u Parameter e File for the Auxiliary Instance
s y n s
aa text linitialization
e
You must create
y M i c parameter file for the auxiliary instance. The text
a n le parameter file must reside on the same host as the RMAN client that you use to
initialization
t
execute
S the DUPLICATE command.
Take note of the requirements for each of the following parameters:
• 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
ensure that the name of the duplicate database differs from the other names in its Oracle
home. Be sure to use the same database name that you set for this parameter when you
execute the DUPLICATE command.
• 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
auxiliary database as set in the initialization parameter file for the target database. If the
parameter is not set in the initialization parameter file for the target database, do not set it in
the auxiliary instance initialization parameter file.
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 for 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',
ble
'/u01/app/oracle/oradata/aux/control02.ctl',
fe r a
'/u01/app/oracle/oradata/aux/control03.ctl'
ans
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
n - t r
'/u01/app/oracle/oradata/aux'
a no
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
a s
'/u01/app/oracle/oradata/aux' ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Specifying Parameters k i
u nControl
for e File Naming
s y s
anameslicfore the required database files when you execute the DUPLICATE
RMAN generates
M
l
command.
n eyYou can control the naming of the files by specifying the following initialization
Sta in the auxiliary instance initialization parameter file:
parameters
• CONTROL_FILES: Specify the names of the control files in this parameter. If you do not
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
SQL Reference manual for specific information.
• DB_FILE_NAME_CONVERT: This parameter is used to specify the names of data files for
the auxiliary database. It has the format DB_FILE_NAME_CONVERT = '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 specify the
DB_FILE_NAME_CONVERT parameter as an option to the DUPLICATE DATABASE
command.
• 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 =
'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 for 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 data files:
• Include the SET NEWNAME FOR DATAFILE command within a RUN block to specify new
names for the data files.
• Use the CONFIGURE AUXNAME command.
• Specify the DB_FILE_NAME_CONVERT parameter with the DUPLICATE command.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Starting the Instance in NOMOUNT Mode
• Start the auxiliary instance in NOMOUNT mode.

• Create a server parameter file (SPFILE) from the text

initialization parameter file you used to start the instance.
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
ble
Database Buffers 188743680 bytes
fe r a
Redo Buffers 2973696 bytes
ans
SQL> create spfile n - t r
2 from pfile='$HOME/auxinstance/initAUX.ora';
a no
a s
) h i d eฺ
File created. m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toMode u
Starting the Instanceuin k i NOMOUNT
a s y ense
After you have
y ic text initialization parameter file, invoke SQL*Plus to start the
Mcreated lthe
auxiliaryleinstance in NOMOUNT mode.
n
Stayou invoke SQL*Plus, create a server parameter file (SPFILE) from your text initialization
After
parameter file. You can execute the CREATE SPFILE before or after you have started the
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
and restarts it as part of the duplication process, so you must specify the PFILE option if you do
not use an SPFILE.

Ensuring That Backups and Archived Redo Log

Files Are Available
• Backups of all target database data files 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
ble
– Image copies fe r a
ans
– Actual archived redo log files
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Ensuring That Backups k i
u nsArchived
and e Redo Log Files Are Available
s y
a to lrestore
e the data files must be accessible on the duplicate host. You do not
The backups needed
M i c
l ey database backup. RMAN can use a combination of full and incremental backups of
need anwhole
Sta data files during the duplication process.
individual
Archived redo logs required to recover the duplicate database to the desired point in time must
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
database node or mounted across a network by some means such as network file system (NFS).

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
instance, 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 rab
le
RMAN> RUN n s fe
{ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE
n - traDISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICEno
TYPE DISK;
a
… as ) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Allocating Auxiliary u
y ki se to
Channels
If you do not M asautomatic
have l i c enchannels configured, manually allocate at least one auxiliary
ey issuing the DUPLICATE command. The ALLOCATE AUXILIARY CHANNEL
channel lbefore
n
Sta must be within the same RUN block as the DUPLICATE command. The channel type
command
specified on the ALLOCATE AUXILIARY CHANNEL command must match the media where
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,
you can specify the number of channels that correspond to the number of devices available.

Using the RMAN DUPLICATE Command
• Connect to the target database instance 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;
a b le
} fer s
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M command u
Using the RMAN DUPLICATEk i t o
a s yu ense
Invoke RMAN
y ic to the target database and auxiliary instance before issuing the
Mand connect
l
DUPLICATE
a n le command. The auxiliary instance must be started with the NOMOUNT option and
the t
S target database must be mounted or open.

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 data files 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 bl e
fe r a
• Creates the online redo log files
t r a ns
n
• Generates a new, unique database identifier (DBID)
o -for the
duplicate database s an
a ) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to Operation
Understanding the RMAN
y u ki Duplication
s e
M asthe DUPLICATE
When you execute l i c en command, RMAN performs the following operations:
y
le a control file for the duplicate database
• Creates
t a n
S• Restores the target data files 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 DBID for the duplicate database

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 ble

fe r a
OPEN RESTRICTED Enable RESTRICTED SESSION automatically
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(MDUPLICATE u
Specifying Options for k
u nseithe t o Command
s y
a options ewhen executing the DUPLICATE command as appropriate.
Specify additional
M l i c
SKIPn l ey
READONLY: Use to exclude read-only tablespace data files.
t a
S TABLESPACE: Use to exclude tablespaces from the target database. You cannot exclude
SKIP
the SYSTEM tablespace or tablespaces containing undo or rollback segments.
NOFILENAMECHECK: Use to prevent RMAN from checking whether target database data files
with the same name as duplicate database data files are in use. You must specify this option
when the target database and duplicate database data files 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
specify NOFILENAMECHECK in this situation, RMAN returns an error.
OPEN RESTRICTED: Use to enable RESTRICTED SESSION automatically after the database
is opened.

Using EM to Clone a Database

Or
Running instance
ble
Staging Clone
fe r a
area
Or database
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
Existing backup
i l ฺ
g ma tude
sy se th
a
k i (M e to u
Using EM to Clone auDatabase
s
sy cenManager
useaEnterprise
You can also M li (EM) to create a duplicate (clone) database. You can
y
le the following venues for the clone operation:
choosenfrom
t a
S• Running instance: You can specify a running instance to be cloned.
• Staging area: A disk area specified on the source and destination hosts. A backup is created
and stored here, then put in the destination staging area, and read from on that destination
host to create the clone database.
• Existing backup: If you already have a backup that reflects the database in the state you
want it cloned, you can use that.

Cloning a Running Database
Clone a database using one of

these sources:
• Open database in
ARCHIVELOG mode
• Open database in
NOARCHIVELOG mode
• Existing database backup
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Cloning a Running Database i
a s yu ense
To start the clone
y lic in EM, select Data Movement > Clone Database. The Clone
M operation
t a nleWizard steps you through the process of creating a duplicate database.
Database
S the Source Type page, designate the source for the cloning operation. You can select a
On
current database instance or a saved working directory from a previous clone operation. You can
alternatively point to a backup of a database.
If you select a running database, the next page of the clone wizard prompts you to specify the
source database. This must be an open database, and may be either in ARCHIVELOG or
NOARCHIVELOG mode. If it is in NOARCHIVELOG mode, then be aware that the source
database is restarted during the clone operation.


ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Cloning a Running Database k i
u nse(continued)
s y
aof the wizarde prompts you for information about the destination database.
The second step
M l i c
Providen l eyfollowing:
the
S• taHost name: Name of server to host the new database
• Oracle Home location: Directory for Oracle home of the new database
• OS login credentials: Owner of the Oracle software, usually oracle
• Database name: The global name and the instance name
• Storage method to use: Choices are File System, ASM, and Raw devices.


ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Cloning a Running Database k i
u nse(continued)
s y
The third stepM ofathe wizard
l i c easks for the details about the file layout for the destination database.
l ey how much space is needed to create the database.
It alsonreports
Sta


From
source
database
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Cloning a Running Database i
u nse(continued)
s y
a thelilocation
e of the network configuration files in the source database. This
In step four, specify
M c
l ey where you find such files as tnsnames.ora and listener.ora.
is the directory
n
Stafifth step is where you can specify EM configuration for the new database, and any
The
postcloning scripts to be run on the new database.
In the last step, the clone wizard simply prompts you to confirm the parameters and run time for
the clone job to run.

Cloning a Database from a Backup

Existing
backup
location
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Cloning a Database u k
fromi (aMBackup
t o
a s y ense
If you chose to
y ic based on a backup, choose that option when presented with the
Mcreate alclone
le options. Then indicate the directory where a backup currently exists.
sourcentype
a
S t

Summary

• List the purposes of creating a duplicate database

• List the methods of duplicating a database
• Duplicate a database using RMAN
• Use an RMAN backup to duplicate a database
• Duplicate a database based on a running instance
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Using RMAN to Duplicate a Database
This practice covers cloning a database by using an RMAN

backup.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Performing Tablespace
Point-in-Time Recovery
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• List what operations occur when you perform tablespace

point-in-time recovery (TSPITR)
• Define the terminology used with TSPITR
• Identify the circumstances where TSPITR is a good solution
• Determine the correct target time for the point-in-time
recovery
• Identify those situations where TSPITR cannot be used, and able
how to work around them s fer
- t r an
• Perform automated TSPITR on
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Tablespace Point-in-Time k i
u nRecoverye (TSPITR): Concepts
s y
a tablespace s
e point-in-time recovery (TSPITR) enables you to quickly recover
RMAN automaticM l i c
l ey tablespaces in an Oracle database to an earlier time, without affecting the state of
one ornmore
a tablespaces and objects in the database.
Stother
the

Tablespace Point-in-Time Recovery (TSPITR):

Terminology
• Target time: The point in time or SCN that the tablespace will
be recovered to
• Recovery set: Data files that compose the tablespaces to be
recovered
• Auxiliary set: Data files required for the TSPITR of the
recovery set that are not part of the recovery set. It typically
includes:
– SYSTEM tablespace e
– Undo segment tablespaces r a bl
s fe
– Temporary tablespace - t r an
o n
an
• Auxiliary destination: Disk location to store files
s
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Tablespace Point-in-Timek i
u nRecoverye (TSPITR): Terminology
s y s
a liceis used when discussing TSPITR:
The followingM terminology
l
• Target
n ey time: The point in time or system change number (SCN) that the tablespace will be
Starecovered to during TSPITR
• Recovery set: Data files composing the tablespaces to be recovered
• Auxiliary set: Data files 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
- Data files containing undo segments from the target instance
- In some cases, a temporary tablespace, used during the export of database objects from
the auxiliary instance
• Auxiliary destination: A location on disk that can be used to store any of the auxiliary set
data files, control files, and online logs of the auxiliary instance during TSPITR. Files
stored in the auxiliary destination can be deleted after TSPITR is complete.

Tablespace Point-in-Time Recovery: Architecture

RMAN
Control file Auxiliary instance
Data file
Restore
ble
backups fe r a
Restore
an s
Recover n - t r
1 Archived no
redo log files a
sRecovered tablespace
) h a e ฺ
Target database
2
o m u id
ilฺc ent G
a
@ gm Stud
u
Copyright
s
a use
( M to Architecture
Tablespace Point-in-Time
y u ki Recovery:
s e
In the diagram,M asfollowing
the l i c enTSPITR entities are shown:
l
• Target
n ey database: Contains the tablespace to be recovered
S• taControl file: Provides backup information to RMAN
• Backup sets: Come from the target database and are the source of the reconstructed
tablespace
• Archived redo logs: Come from the target database and are the source of the reconstructed
tablespace
• Auxiliary instance: Is the Oracle database instance used during the recovery process to
perform the recovery
RMAN performs the following steps during tablespace point-in-time recovery:
1. Restores a backup control file from a point in time before the target time to the auxiliary
instance. It restores the data files for the recovery set to the target database and the data files
for the auxiliary set to the auxiliary instance.
2. Recovers the restored data files to the specified point in time

Tablespace Point-in-Time Recovery: Architecture

RMAN
5
Import metadata
bl e
Control file fe r a
t r a ns
Export
o n
Auxiliary- file
an
Recovered instance
tablespace
Target database s
ha ide3ฺ
4 m Gu) Export
Point to recovered tablespace ฺco
ail den t metadata
m
g Stu
Copyright
t h
( M a use
Tablespace Point-in-Timeu ki Recoverye to Architecture (continued)
y
s cemetadata
adictionary n s
3. Exports the
M l i about objects in the recovered tablespace to the target
le y
database
t a n
S4. Issues SWITCH commands on the target database so that the target database control file
points to the data files in the recovery set that were recovered on the auxiliary instance
5. Imports the dictionary metadata from the auxiliary instance to the target instance, allowing
the recovered objects to be accessed

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
ble
• TSPITR cannot be used to: r a
– Recover a dropped tablespace ns fe
- t r a
– Recover a renamed tablespace to a point before o
it n
was
renamed s an
a ) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
When to Use TSPITRuki e
y
s be used
acan s
ento:
RMAN TSPITR M l i c
l
• Recover
n ey data lost after an erroneous TRUNCATE TABLE statement
S• taRecover from logical corruption of a table
• Undo the effects of an incorrect batch job or another data manipulation language (DML)
statement that has affected only a subset of the database
• Recover a logical schema to a different point in time than other parts of the physical
database

Preparing for TSPITR
To prepare for TSPITR, perform the following steps:

• Determine the correct target time.

• Determine what is needed in the recovery set.
• Identify and preserve objects that will be lost after TSPITR.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Preparing for TSPITR k i
a s yu ense
Before performing
y M TSPITR,lic you need to determine the correct target time for your recovery.
You need
a n leto determine whether you need additional tablespaces in your recovery set. You
t
should
S evaluate what objects will be lost as a result of the TSPITR operation and determine how
you want to preserve those objects.
Each of these steps is discussed in more detail in this lesson.

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 e
r a bl
– Flashback Version Query
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Determining the Correct k i
u Target e Time
s y
a licthat n s
e you choose the right target time or SCN for TSPITR. After you
It is extremelyMimportant
performn l ey and bring a tablespace online, you cannot use any backup from a time earlier
TSPITR
Stathe moment you brought the tablespace online. In practice, this means that you cannot make
than
a second attempt at TSPITR if you choose the wrong target time the first time, unless you are
using a recovery catalog. However, if you have a recovery catalog, you can perform repeated
TSPITR operations to different target times.
The current control file does not contain a record of an older incarnation of the recovered
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
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
backup control file from before that time.
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
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 e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k
Determining the Tablespaces i
u nsefor the Recovery Set
s y
awhether e have accounted for all objects that have relationships with the
If you are unsure
M l i c you
y tablespaces you are performing the TSPITR operation for, you can use the
l
objectsninethe
Sta
TS_PITR_CHECK view to identify any additional objects. When you query this view,
information about any objects that will prevent you from proceeding with TSPITR is displayed.
The reason why tablespace point-in-time recovery cannot proceed is displayed in the REASON
column of the TS_PITR_CHECK view.
As an example, if you are planning to perform TSPITR for the USERS and EXAMPLE
tablespaces, execute the following query to determine whether there are any relationships with
objects in other tablespaces that are not accounted for:
SELECT * FROM SYS.TS_PITR_CHECK
WHERE (TS1_NAME IN ('USERS','EXAMPLE')
AND TS2_NAME NOT IN ('USERS','EXAMPLE'))
OR (TS1_NAME NOT IN ('USERS','EXAMPLE')
AND TS2_NAME IN ('USERS','EXAMPLE'));
Refer to the Oracle Database Backup and Recovery 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.
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Identifying Objects That k i
u Will ebe Lost
s y
a lice n s
Query the TS_PITR_OBJECTS_TO_BE_DROPPED
M view to determine whether there are any
y
le will be lost as a result of performing tablespace point-in-time recovery.
objectsnthat
t a
S an example, you are performing TSPITR for the USERS and EXAMPLE tablespaces to the
As
target time of April 3, 2006 at 8:30:00 AM. Issue the following query to determine whether there
are any objects that will be lost following your TSPITR:
SELECT OWNER, NAME, TABLESPACE_NAME,
TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','EXAMPLE')
AND CREATION_TIME >
TO_DATE('2006-APR-03:08:30:00','YY-MON-DD:HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

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 the location of files.
– Specify initialization parameters. bl e
– Specify channel configurations. fe r a
ans
• TSPITR using your own auxiliary instance n - t r
no
sa
– Configure and manage the auxiliary instance.
ha ideฺ
m Gu)
ฺ c o t
a il e n
@ gm Stud
u
Copyright
s
a use
( M to
Performing Basic RMAN
y u ki TSPITR
s e
You have theM as lioptions
following c en when performing TSPITR:
l
• Fully
n eyautomated TSPITR: Specify an auxiliary destination, and RMAN manages all
Staaspects of the TSPITR operation. This is the simplest way to perform TSPITR, and is
recommended unless you specifically need more control over the location of recovery set
files after TSPITR or auxiliary set files during TSPITR, or control over the channel
configurations or some other aspect of your auxiliary instance.
• Customized TSPITR with an automatic auxiliary instance: TSPITR is based on the
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
recovery set files. You can specify initialization parameters or channel configurations for
the auxiliary instance created and managed by RMAN.
• TSPITR with your own auxiliary instance: Set up, start, stop, and clean up the auxiliary
instance used in TSPITR. In addition, you can manage the TSPITR process by using some
of the methods available in customized TSPITR with an automatic auxiliary instance.

Performing Fully Automated TSPITR
1. Configure channels required for TSPITR on the target

instance.
2. Specify the auxiliary destination using the AUXILIARY
DESTINATION option.
RMAN> CONNECT TARGET
RMAN> RECOVER TABLESPACE users, example
> UNTIL TIME '2007-06-29:08:00:00'
> AUXILIARY DESTINATION
> '/u01/app/oracle/oradata/aux'; ble
fe r a
ans
3. Back up the recovered tablespaces and bring them online.
-tr
o n
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Performing Fully Automated
u to
ki seTSPITR
y
s cenrequirements discussed earlier in the lesson, when you perform
theapreparation
In addition toM li
l e y TSPITR,
fully automated you must:
t a n
S• Configure any channels required for TSPITR on the target instance
• Specify a destination for RMAN to use for the auxiliary set of data files and other auxiliary
instance files
After TSPITR has completed, back up the recovered tablespaces and bring them online. You
cannot use backups of any tablespaces that participate in TSPITR taken prior to TSPITR after
you perform TSPITR.
Note: This time format assumes that NLS_DATE_FORMAT is set to 'yyyy-mm-
dd:hh24:mi:ss' and NLS_LANG is set to AMERICAN_AMERICA.WE8MSWIN1252.

Using Enterprise Manager to Perform TSPITR

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u ntosePerform TSPITR
s y
You can also MuseaEnterprise
l i c e Manager to perform TSPITR. Navigate to Availability > Perform
l
Recovery.
n eyIn the User Directed Recovery section, select Tablespaces from the Recovery Scope
Sta menu.
drop-down
There are three operations you can perform, for tablespaces:
• Recover to current time or a previous point in time: Restores the data files for the
tablespace, if needed. This operation then uses redo to recover to the time you specify:
either the current time or a time in the past. This is the combination of the following two
operations.
• Restore tablespaces: Only restore the data files for the tablespace. No recovery is
performed.
• Recover from previously restored tablespaces: Perform recovery (redo application) only,
of the tablespace’s data files.

RMAN 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 data files from the recovery set and the
auxiliary set to the auxiliary instance
5. Recovers the restored data files to the specified time a b le
6. Opens the auxiliary database with the RESETLOGS option s fer
n tra
n -
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
RMAN TSPITR Processing k i
a s yu ense
The steps thatM
y lic out to perform TSPITR are listed in this slide and the next.
RMAN carries
t a nle
S

RMAN TSPITR Processing
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
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
RMAN TSPITR Processing k i
u n(continued)
a s y e se
After RMANM completeslic
the last step, the TSPITR process is complete. The recovery set data
e y
t a nlreturned
files are to the state they were in at the specified target time.
S

Performing RMAN TSPITR with an RMAN-

Managed Auxiliary Instance
• Rename or relocate your recovery set data files.
• Specify a location other than the auxiliary destination for

some or all of the auxiliary set data files.
• Create image copy backups of your data files in advance of
TSPITR.
• Use a different channel configuration for the auxiliary
instance.
• Specify different initialization parameters for your RMAN-
a b le
r
managed auxiliary instance. sfe n
n - tra
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Performing RMAN TSPITR u ki withe o RMAN-Managed Auxiliary Instance
tan
y
as licRMAN s
en TSPITR, you can use an RMAN-managed auxiliary instance
If you want toM customize
and make l y following changes:
ethe
n
S• taRename the recovery set data files using SET NEWNAME so that they are not restored and
recovered in their original locations.
• Control the location of your auxiliary set data files by specifying new names for individual
files with SET NEWNAME and using DB_FILE_NAME_CONVERT to provide rules for
converting data file names in the target database to data file names for the auxiliary
database.
• Use existing image copies of the recovery set and auxiliary set data files on disk rather than
restoring them from backup for faster RMAN TSPITR performance.
Note: Refer to the Oracle Database Backup and Recovery User’s Guide for additional
information.

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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Performing RMAN TSPITR k i
u nUsing e Your Own Auxiliary Instance
s y
a thatlicyou s
e allow RMAN to manage the creation and destruction of the
Oracle recommends
M
auxiliaryl y
einstance used during RMAN TSPITR. However, creating and using your own auxiliary
t a n
instance
S is supported.
To create an Oracle instance suitable for use as an auxiliary instance, perform the following
steps:
1. Create an Oracle password file for the auxiliary instance by using the orapwd utility.
2. Create a text initialization parameter file for the auxiliary instance.
3. Verify Oracle Net connectivity to the auxiliary instance using a valid net service name.
To perform TSPITR, complete the following steps:
5. Connect the RMAN client to target and auxiliary instances.
6. Execute the RECOVER TABLESPACE command.
Refer to the Oracle Database Backup and Recovery User’s Guide for a detailed example.

Troubleshooting RMAN TSPITR
• File name conflicts: Ensure that there are no name conflicts

when using SET NEWNAME, CONFIGURE AUXNAME, and

DB_FILE_NAME_CONVERT.
• 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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Troubleshooting RMAN k i TSPITR
a s yu ense
File name conflicts:
y M If yourl ic use of SET NEWNAME, CONFIGURE AUXNAME, and
le
DB_FILE_NAME_CONVERT
a n cause multiple files in the auxiliary or recovery sets to have the
t
same
S name, you receive an error during TSPITR. To correct the problem, specify different
values for these parameters to eliminate the duplicate name.
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.

Summary

• List what operations occur when you perform tablespace

point-in-time recovery (TSPITR)
• Define the terminology used with TSPITR
• Identify the circumstances where TSPITR is a good solution
• Determine the correct target time for the point-in-time
recovery
• Identify those situations where TSPITR cannot be used, and able
how to work around them s fer
- t r an
• Perform automated TSPITR on
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
y u ki se to
M as licen
le y
n
Sta

Performing TSPITR
This practice covers the following topic:
• Performing TSPITR
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
Monitoring and Tuning RMAN
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Monitor the progress of RMAN jobs

• Configure RMAN appropriately for asynchronous I/O
• Configure RMAN multiplexing so as to keep tape drives
streaming efficiently
• Evaluate the balance between speed of backup versus
speed of recovery
• Explain the effect of the following parameters on RMAN a b le
performance: MAXPIECESIZE, FILESPERSET, s fer
MAXOPENFILES - t r an
n on
• Explain how the RMAN BACKUP DURATIONs option a can
a eฺ
cause backups to either execute faster)orh takeidlonger,
o m u
ilฺc nt G
(freeing up resources for other processing)
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Parallelization of Backup Sets
For performance, allocate multiple channels and assign files to

specific channels.
Data file Data file Data file

1 4 5 Channel
MML Backup
piece 1
Data file Data file Data file

Channel e
2 3 9
r a bl
MML Backup n2sfe
t
piece
- r a
Data file Data file Data file n on
Channel s a
6 7 8
) ha ideฺ
c o m Gu
MML Backup
ฺ
ail den t Piece 3
m
g Stu
Copyright
t h
( M a use
Parallelization of Backup
u ki Sets e to
y
asparallel n s
ebackups
You can configure
y M l i c by setting the PARALLELISM option of the CONFIGURE
command
a n leto greater than 1 or by manually allocating multiple channels. RMAN parallelizes its
S t
operation and writes multiple backup sets in parallel. The server sessions divide the work of
backing up the specified files.
Example
RMAN> RUN {
2> ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
5> BACKUP
6> INCREMENTAL LEVEL = 0
7> (DATAFILE 1,4,5 CHANNEL c1)
8> (DATAFILE 2,3,9 CHANNEL c2)
9> (DATAFILE 6,7,8 CHANNEL c3);
10> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
11> }

Parallelization of Backup Sets (continued)

When backing up data files, you can specify the files to be backed up by either their path name
or their file number. For example, the following two commands perform the same action:
BACKUP DEVICE TYPE sbt DATAFILE '/home/oracle/system01.dbf';
BACKUP DEVICE TYPE sbt DATAFILE 1;
When you create multiple backup sets and allocate multiple channels, RMAN automatically
parallelizes its operation and writes multiple backup sets in parallel. The allocated server
sessions share the work of backing up the specified data files, control files, and archived redo
logs. You cannot stripe a single backup set across multiple channels.
Parallelization of backup sets is achieved by:
• Configuring PARALLELISM to greater than 1 or allocating multiple channels
• Specifying many files to back up
Example
• There are nine files that need to be backed up (data files 1 through 9).
• Assign the data files to a backup set so that each set has approximately the same numberbof
a le
data blocks to back up (for efficiency).
s fer
- Data files 1, 4, and 5 are assigned to backup set 1.
- t r an
n on
s a
Note: You can also use the FILESPERSET parameter to limit a
) hthe numbereฺ of data files that are
m u i d
included in a backup set.
ail den ฺco t G
m
g Stu
i @
s y uk this
( M a use
y u ki se to
M as licen
le y
n
Sta

Monitoring RMAN Sessions
• Query V$SESSION and V$PROCESS to identify the

relationship between server sessions and RMAN channels.

• If you are monitoring multiple sessions, use the SET
COMMAND ID command to correlate a process with a
channel during a backup.
SQL> COLUMN CLIENT_INFO FORMAT a30

ble
SQL> COLUMN SID FORMAT 999
fe r a
SQL> COLUMN SPID FORMAT 9999
ans
SQL> SELECT s.sid, p.spid, s.client_info
n - t r
o
an
2 FROM v$process p, v$session s
3 WHERE p.addr = s.paddr a s
4 AND CLIENT_INFO LIKE 'rman%'; ) h i d eฺ
Gu c o m
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Monitoring RMAN Sessions
y u ki se to
asserverlicsessions
To identify which
M en correspond to which RMAN channels, you can query
l
V$SESSION
n ey and V$PROCESS. The SPID column of V$PROCESS identifies the operating
Sta ID number for the process or the thread. On UNIX, the SPID column shows the process
system
ID. On Windows, the SPID column shows the thread ID. There are two basic methods for
obtaining this information, depending on whether you have multiple RMAN sessions active
concurrently. When only one RMAN session is active, execute the following query on the target
database while the RMAN job is running:
SQL> COLUMN CLIENT_INFO FORMAT a30
SQL> COLUMN SID FORMAT 999
SQL> COLUMN SPID FORMAT 9999
SQL> SELECT s.sid, p.spid, s.client_info
2 FROM v$process p, v$session s
3 WHERE p.addr = s.paddr
4 AND CLIENT_INFO LIKE 'rman%';
SID SPID CLIENT_INFO
---- ------------ ------------------------------
15 2714 rman channel=ORA_SBT_TAPE_1
13 2715 rman channel=ORA_SBT_TAPE_2

Monitoring RMAN Sessions (continued)

When multiple RMAN sessions are running, it helps to correlate a process with a channel during
a backup by using the SET COMMAND ID command as shown below:
1. In each session, set the command ID to a different value and then back up the desired
object. For example, enter the following in session 1:
RUN
{
SET COMMAND ID TO 'sess1';
BACKUP DATABASE;
}
Set the command ID to a string such as sess2 in the job running in session 2:
RUN
{
SET COMMAND ID TO 'sess2';
BACKUP DATABASE;
ble
}
fe r a
2. Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS
t r a ns views
while the RMAN job is being executed. For example, enter: n-
no
s a
SELECT SID, SPID, CLIENT_INFO
) h a eฺ
FROM V$PROCESS p, V$SESSION s
m i d
WHERE p.ADDR = s.PADDR
i l ฺ co nt Gu
AND CLIENT_INFO LIKE '%id=sess%';
g ma tude
u i@ isin S
kcommand
If you run the SET COMMAND y
a s ID
e th the RMAN job, then the CLIENT_INFO
column is displayed in(the
i M following
t o usformat:
id=command_id,rman
s y uk nsechannel=channel_id
For example,
M a the following
l i c e shows a sample output:
n l eySID SPID
Sta ---- ------------
CLIENT_INFO
------------------------------
11 8358 id=sess1
15 8638 id=sess2
14 8374 id=sess1,rman channel=c1
9 8642 id=sess2,rman channel=c1

Monitoring RMAN Job Progress
Monitor the progress of backup and restore operations by

querying V$SESSION_LONGOPS.
SQL> SELECT OPNAME, CONTEXT, SOFAR, TOTALWORK,

2 ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
3 FROM V$SESSION_LONGOPS
4 WHERE OPNAME LIKE 'RMAN%'
5 AND OPNAME NOT LIKE '%aggregate%'
6 AND TOTALWORK != 0
ble
7 AND SOFAR <> TOTALWORK;
fe r a
SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE -tra
ns
n
--- ------- ------- ------- --------- ----------on
13 75 1 9470 15360 as a 61.65
12 81 1 15871 28160) h deฺ
i56.36 m Gu
ฺ c o t
a il e n
@ gm Stud
u
Copyright
s
a use
i ( M to
Monitoring RMAN Job
y u kProgress
s e
as oflibackups,
Monitor the progress
M c en copies, and restores by querying the V$SESSION_LONGOPS
l
view. RMAN
n ey uses detail and aggregate rows in V$SESSION_LONGOPS. Detail rows describe
a that are being processed by one job step. Aggregate rows describe the files that are
Stfiles
the
processed by all job steps in an RMAN command. A job step is the creation or restoration of one
backup set or data file copy. The detail rows are updated with every buffer that is read or written
during the backup step, so their granularity of update is small. The aggregate rows are updated
when each job step is completed, so their granularity of update is large.
Note: Set the STATISTICS_LEVEL parameter to TYPICAL (the default value) or ALL to
populate the V$SESSION_LONGOPS view.
The relevant columns in V$SESSION_LONGOPS for RMAN include:
• OPNAME: A text description of the row. Detail rows include RMAN:datafile copy,
RMAN:full datafile backup, and RMAN:full datafile restore.
• CONTEXT: For backup output rows, the value of this column is 2. For all the other rows
except proxy copy (which does not update this column), the value is 1.

Monitoring RMAN Job Progress (continued)

• SOFAR: For image copies, the number of blocks that have been read; for backup input
rows, the number of blocks that have been read from the files that are being backed up; for
backup output rows, the number of blocks that have been written to the backup piece; for
restores, the number of blocks that have been processed to the files that are being restored in
this one job step; and for proxy copies, the number of files that have been copied
• TOTALWORK: For image copies, the total number of blocks in the file; for backup input
rows, the total number of blocks to be read from all files that are processed in this job step;
for backup output rows, the value is 0 because RMAN does not know how many blocks it
will write into any backup piece; for restores, the total number of blocks in all files restored
in this job step; and for proxy copies, the total number of files to be copied in this job step
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Interpreting RMAN Message Output
RMAN troubleshooting information can be found in:

• RMAN command output

• RMAN trace file
• Alert log
• Oracle server trace file
• sbtio.log file
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Interpreting RMAN Messagek i
u nseOutput
s y
a output e contains actions that are relevant to the RMAN job as well as error
The RMAN command
M l i c
y are generated by RMAN, the server, and the media vendor. RMAN error
l
messages
n ethat
Sta have an RMAN-nnnn prefix. The output is displayed to the terminal (standard output)
messages
but can be written to a file by defining the LOG option or by shell redirection.
The RMAN trace file contains the DEBUG output and is used only when the TRACE command
option is used.
The alert log contains a chronological log of errors, nondefault initialization parameter settings,
and administration operations. Because it records values for overwritten control file records, it
can be useful for RMAN maintenance when operating without a recovery catalog.
The Oracle trace file contains detailed output that is generated by Oracle server processes. This
file is created when an ORA-600 or ORA-3113 (following an ORA-7445) error message
occurs, whenever RMAN cannot allocate a channel, and when the Media Management Library
fails to load. It can be found in USER_DUMP_DEST.
The sbtio.log file contains vendor-specific information that is written by the media
management software and can be found in USER_DUMP_DEST. Note that this log does not
contain Oracle server or RMAN errors.

Using the DEBUG Option
• The DEBUG option is used to:

– View the PL/SQL that is generated

– Determine precisely where an RMAN command is hanging or
faulting
• The DEBUG option is specified at the RMAN prompt or within
a run block.
• The DEBUG option creates an enormous amount of output,
so redirect the output to a trace file: e
r a bl
s fe
tran
$ rman target / catalog rman/rman debug trace trace.log
n -
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Using the DEBUG Option
y u ki se to
The DEBUG option
M asdisplays
l i c enall SQL statements that are executed during RMAN compilations
and the
n l ey of these executions. Any information that is generated by the recovery catalog
results
Sta packages is also displayed. In the following example, the DEBUG output is written
PL/SQL
during the backup of data file 3, but not data file 4:
RMAN> run {
debug on;
allocate channel c1 type disk;
backup datafile 3;
debug off;
backup datafile 4; }
Remember that the DEBUG output can be voluminous, so make sure that you have adequate disk
space for the trace file. This simple backup session that does not generate any errors creates a
trace file that is almost half a megabyte in size:
$ rman target / catalog rman/rman debug trace sample.log
RMAN> backup database;
RMAN> host "ls –l sample.log";
-rw-r--r-- 1 user02 dba 576270 Apr 6 10:38
sample.log
host command complete

Interpreting RMAN Error Stacks
• Read the stack from bottom to top.

• Look for Additional information.

• RMAN-03009 identifies the failed command.
RMAN-00571: ===========================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS =======
RMAN-00571: ===========================================
RMAN-03009: failure of backup command on c1 channel at
09/04/2001 13:18:19
ORA-19506: failed to create sequential file,
ble
name="07d36ecp_1_1", parms=""
fe r a
ORA-27007: failed to open file ans
SVR4 Error: 2: No such file or directory n - t r
Additional information: 7005 a no
a s
Additional information: 1
) h i d eฺ
ORA-19511: Error from media manager layer,error text: m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Interpreting RMAN Error k i
u Stacks
a s y e n se
Because of the
y Mamount loficdata that RMAN logs, you may find it difficult to identify the useful
messages
a n lein the RMAN error stack. Note the following tips and suggestions:
t
S• Because many of the messages in the error stack are not meaningful for troubleshooting, try
to identify the one or two errors that are most important.
• Check for a line that says Additional information followed by an integer. This line
indicates a media management error. The integer that follows refers to code that is
explained in the text of the error message.
• Read the messages from bottom to top because this is the order in which RMAN issues the
messages. The last one or two errors that are displayed in the stack are often informative.
• Look for the RMAN-03002 or RMAN-03009 message immediately following the banner.
The RMAN-03009 is the same as RMAN-03002 but includes the channel ID. If the failure
is related to an RMAN command, then these messages indicate which command failed. The
syntax errors generate an RMAN-00558 error.

Tuning RMAN
• RMAN BACKUP and RESTORE operations perform the

following tasks:
– Read or write data.
– Process data by copying and validating blocks.
• The slowest of these tasks is referred to as a bottleneck, for
any particular process.
• Tuning RMAN requires that the bottlenecks be identified and
addressed. le
a b
• Performance of backup versus recovery operations can be s fer
n
balanced to suit your needs. -tra on
a n
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Tuning RMAN
y u ki se to
RMAN backup M as restore
and l i c n
eoperations perform the following distinct tasks:
y
le or writing input data
• Reading
t a n
S• Processing data by validating and copying blocks from the input to the output buffers
The slowest of these tasks is called a bottleneck. RMAN tuning involves identifying the
bottleneck (or bottlenecks) and attempting to make it more efficient by using RMAN commands,
initialization parameter settings, or adjustments to the physical media. The key to tuning RMAN
is in understanding the input/output (I/O). The backup and restore jobs of RMAN use two types
of I/O buffers: disk and tertiary storage (usually tape). When performing a backup, RMAN reads
input files by using disk buffers and writes the output backup file by using either the disk or the
tape buffer. When performing restores, RMAN reverses these roles. I/O can be synchronous and
asynchronous. Synchronous devices perform only one I/O task at a time. Therefore, you can
easily determine how much time the backup jobs require. In contrast to synchronous I/O (SIO),
asynchronous I/O (AIO) can perform more than one task at a time. To tune RMAN effectively,
you must thoroughly understand the concepts of synchronous and asynchronous I/O, disk and
tape buffers, and channel architecture. With an understanding of these concepts, you can use
fixed views to monitor bottlenecks.

Tuning RMAN (continued)

You may be able to take advantage of some backup and recovery features that allow you to
balance the performance of backup operations versus recovery operations. For example, if you
require shorter recovery time, then you may want to perform image copy recovery on a regular
basis. That takes more resources to prepare for recovery, but would lessen the amount of time
needed to perform the recovery.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

RMAN Multiplexing
• For reads:
Multiplexing Level Allocation Rule
Level <= 4 1 MB buffers are allocated so that the total buffer size
for all input files is 16 MB.
4 < Level <= 8 512 KB are allocated so that the total buffer size for all
files is less than 16 MB.
Level > 8 RMAN allocates four 128 KB disk buffers per channel
for each file, so that the total size is 512 KB per channel ble
for each file. fe r a
ans
n - t r
no of
• For writes, each channel allocates four output buffers
a
1 MB each. has ฺ ) i de
o m u
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
RMAN Multiplexing uki e
y
s cetypes
adifferent s
n of buffers for I/O: disk and tape. RMAN multiplexing
RMAN uses twoM l i
l
determines
n eyhow RMAN allocates disk buffers. RMAN multiplexing is the number of files in a
Sta read simultaneously and then written to the same backup piece. The degree of
backup
multiplexing depends on the FILESPERSET parameter of the BACKUP command as well as the
MAXOPENFILES parameter of the CONFIGURE CHANNEL command or ALLOCATE
CHANNEL command. Note: RMAN multiplexing is set at the channel level.
For example, assume that you back up two data files with one channel. You set FILESPERSET
to 3 and MAXOPENFILES to 8. In this case, the number of files in each backup set is 2 (the
lesser of FILESPERSET and the files read by each channel) and the level of multiplexing is 2
(the lesser of MAXOPENFILES and the number of files in each backup set). When RMAN backs
up from disk, it uses the algorithm that is described in the table shown in the slide.
For writing, each channel allocates four output buffers of size 1 MB each.
These buffers are allocated from the PGA unless DBWR_IO_SLAVES is set to a nonzero value.
Note: For best recovery performance, do not set FILESPERSET to a value greater than 8.

Allocating Disk Buffers: Example

Data files Input disk buffers
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB
1 MB 1 MB
Channel
FILESPERSET = 4
bl e
1 MB 1 MB
MAXOPENFILES = 4
fe r a
1 MB 1 MB ans
n - t r
a no
a s
1 MB 1 MB
) h i d eฺ
1 MB 1 MB m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Allocating Disk Buffers: k i
u Example
a s y e n se
In the example
y Mshown inlicthe slide, one channel is backing up four data files. MAXOPENFILES is
e FILESPERSET is set to 4. The level of multiplexing is 4 in this example. The total
set to 4 land
n
sizet a
S of the buffers for each data file is 4 MB. To calculate the total size of the buffers that are
allocated in a backup set, multiply the total bytes for each data file by the number of data files
that are being concurrently accessed by the channel, and then multiply this number by the
number of channels.
Assume that you use one channel to back up four data files, and use the settings that are shown
in the slide. In this case, multiply as follows to obtain the total size of the buffers that are
allocated for the backup:
4 MB per data file  1 channel  4 data files per channel = 16 MB
Set the MAXOPENFILES parameter so that the number of files that are read simultaneously is
just enough to use the output device fully. This consideration is important when the output
device is a tape.

Allocating Tape Buffers
• If BACKUP_TAPE_IO_SLAVES is TRUE, tape buffers are

allocated from the SGA; it uses the large pool, if one is

allocated.
Channel Tape buffers

256 KB 256 KB
256 KB 256 KB
ble
fe r a
t r a ns
• If BACKUP_TAPE_IO_SLAVES is FALSE, tape buffers o n - are
allocated from the PGA. s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Allocating Tape Buffers
y u ki se to
If you make aM as tolica etape
backup
n device, the Oracle server allocates four buffers per channel for
the tape
n l ey (or reads if doing a restore). The Oracle server allocates these buffers only if the
writers
Sta is a System Backup to Tape (SBT) channel. Typically, each tape buffer is 256 KB. To
channel
calculate the total size of buffers that are used during a backup or restore, multiply the buffer
size by four, and then multiply this product by the number of channels.
As illustrated in the example shown in the slide, assume that you use one tape channel and each
buffer is 256 KB. In this case, the total size of buffers that are used during a backup is as
follows:
256 KB per buffer  4 buffers per channel  1 channel = 1,024 KB
RMAN allocates the tape buffers in the System Global Area (SGA) or the Program Global Area
(PGA), depending on whether I/O slaves are used. If the BACKUP_TAPE_IO_SLAVES
initialization parameter is set to TRUE, RMAN allocates tape buffers from the shared pool or the
large pool if the LARGE_POOL_SIZE initialization parameter is set. If you set the parameter to
FALSE, RMAN allocates the buffers from the PGA. If you use I/O slaves, set the
LARGE_POOL_SIZE initialization parameter to set aside SGA memory that is dedicated to
holding these large memory allocations. By doing this, the RMAN I/O buffers do not compete
with the library cache for shared pool memory.

Allocating Tape Buffers (continued)

Oracle recommends that you set the BACKUP_TAPE_IO_SLAVES initialization parameter to
TRUE. In most circumstances, this will provide the best performance of backups to tape. Also,
this setting is required in order to perform duplexed backups. Duplexed backups are covered in
the lesson titled “Using RMAN to Create Backups.”
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Comparing Synchronous and Asynchronous I/O
Synchronous I/O
1 Server process 2 Server process waits;

writes data to buffer. tape process writes data.
Server 0100100
process 0100100
Tape ble
Server process buffers fe r a
4 writes data to
ra ns
new buffer. 3 Tape processn-t
no
signals finish.
a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Comparing Synchronous
y u ki and s eAsynchronous I/O
When RMANM
s
a or lwrites
reads c n
e data, the I/O is either synchronous or asynchronous. When the I/O
i
l ey a server process can perform only one task at a time. When it is asynchronous, a
is synchronous,
n
Sta process can begin an I/O and then perform other tasks while waiting for the I/O to
server
complete. It can also begin multiple I/O operations before waiting for the first to complete.
You can set initialization parameters that determine the type of I/O. If you set
BACKUP_TAPE_IO_SLAVES to TRUE, the tape I/O is asynchronous. Otherwise, the I/O is
synchronous.
The example in the slide shows synchronous I/O in a backup to tape. The following steps occur
in a synchronous transfer:
1. A server process writes blocks to a tape buffer.
2. The tape process writes data to tape. The server process is idle while the media manager
copies data from the Oracle buffers to the media manager’s internal buffers.
3. The tape process relays to the server process that it has completed writing.
4. The server process can initiate a new task.

Comparing Synchronous and Asynchronous I/O
Asynchronous I/O
1 Server process 2 Tape process writes data.

writes data to buffer.
Server 0100100
process 0100100 0100100
Tape ble
buffers fe r a
ans
n - t r
a no
3 Server process writes to new a s
buffer while step 2 completes. ) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Comparing Synchronous k i
u nand eAsynchronous I/O (continued)
s y s
asystemslicsupport
e native asynchronous I/O and Oracle can take advantage of this
Many operating
M
l ey it is available. It is recommended that you always set
featurenwhenever
Sta
BACKUP_TAPE_IO_SLAVES to TRUE when the platform supports it. On operating systems
that do not support native asynchronous I/O, Oracle can simulate it by using special I/O slave
processes that are dedicated to performing I/O on behalf of another process. You can control
disk I/O slaves by setting the DBWR_IO_SLAVES parameter to a nonzero value. Oracle
allocates four backup disk I/O slaves for any nonzero value of DBWR_IO_SLAVES.
The example in the slide illustrates asynchronous I/O in a backup to tape. The steps that occur in
an asynchronous exchange are detailed below:
1. A server process writes blocks to a tape buffer.
2. The tape process writes data to the tape. While the tape process is writing, other server
processes are free to process more input blocks and fill more output buffers.
3. The spawned server process writes to the tape buffers while the initial tape process writes to
the tape.

Monitoring RMAN Job Performance
• The following views can be used to monitor backup and

restore performance:
– V$BACKUP_SYNC_IO
– V$BACKUP_ASYNC_IO
• The following rows exist for a backup or restore:
– One row for each data file
– One aggregate data file row
– One row for each backup piece e
r a bl
• Whether or not I/O is synchronous depends on how the s
n fe
controlling process views it. -tra on
a n
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
i ( M to
Monitoring RMAN Job
y u kPerformance
s e
The maximum M as lspeed
backup i c enis limited by the available hardware. It is not possible to back up
l
any faster y the aggregate tape bandwidth. One exception to this is if there are many empty
ethan
n
Sta in the data files that need not be backed up.
blocks
One of the components of the backup system will be a bottleneck—which one depends on the
relative speeds of the disk, tape drive, and any other transport components such as the network.
As an example, if the bottleneck is the tape drive, and the tape is streaming, then the backup
cannot possibly proceed any faster.
Note: If you have synchronous I/O and have set the BACKUP_DISK_IO_SLAVES
initialization parameter to TRUE, I/O is displayed in V$BACKUP_ASYNC_IO.

Asynchronous I/O Bottlenecks
• Use V$BACKUP_ASYNC_IO to monitor asynchronous I/O.

• The file that has the largest ratio of LONG_WAITS to

IO_COUNT is probably the bottleneck.
– IO_COUNT: Number of I/Os performed on the file
– LONG_WAITS: Number of times the backup/restore process
told the OS to wait until I/O was complete
• Wait times should be zero to avoid bottlenecks.
– SHORT_WAIT_TIME_TOTAL e
– LONG_WAIT_TIME_TOTAL r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k i
Asynchronous I/O Bottlenecks
a s yu ense
y M lic
You can use V$BACKUP_ASYNC_IO to monitor asynchronous I/O. The LONG_WAITS column
lenumber of times the backup or restore process directed the operating system to wait
showsnthe
a
t
until
S an I/O was complete. The SHORT_WAITS column shows the number of times the
backup/restore process made an operating system call to poll for I/O completion in a
nonblocking mode. On some platforms, the asynchronous I/O implementation may cause the
calling process to wait for the I/O to complete while performing a nonblocking poll for I/O.
The simplest way to identify the bottleneck is to query V$BACKUP_ASYNC_IO for the data file
that has the largest ratio for LONG_WAITS divided by IO_COUNT.

Synchronous I/O Bottlenecks
• Synchronous I/O is considered to be a bottleneck.

• Query the DISCRETE_BYTES_PER_SECOND column from

V$BACKUP_SYNC_IO to view the I/O rate.
– Compare this rate with the device’s maximum rate.
– If the rate is lower than what the device specifies, this is a
tuning opportunity.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Synchronous I/O Bottlenecksi
a s yu ense
When using synchronous
y M licI/O, it can easily be determined how much time the backup jobs
le devices perform only one I/O task at a time. Oracle I/O uses a polling
requirenbecause
a
S t
mechanism rather than an interrupt mechanism to determine when each I/O request completes.
Because the backup or restore process is not immediately notified of I/O completion by the
operating system, you cannot determine the duration of each I/O.
Use V$BACKUP_SYNC_IO to determine the source of backup or restore bottlenecks and to
determine the progress of backup jobs. V$BACKUP_SYNC_IO contains rows when the I/O is
synchronous to the process (or thread, on some platforms) that is performing the backup.

Tape Backup Speed
The following factors affect the speed of the backup to tape:

• Native transfer rate

• Tape compression
• Tape streaming
• Physical tape block size
• Network speed
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Tape Backup Speeduki
a s y ense
The tape native
y c is the write speed without compression. This speed represents the
Mtransferlirate
a n le of the backup rate. The upper limit of your backup performance should be the
upper limit
S t
aggregate transfer rate of all the tape drives. If the backup is performing at that rate, and an
excessive amount of CPU is not being used, then tuning RMAN does not help.
Tape compression greatly affects backup performance. If the tape has good compression, then
the sustained backup rate is faster. For example, if the compression ratio is 2:1 and the native
transfer rate of the tape drive is 6 MB per second, then the resulting backup speed is 12 MB per
second.
Almost all tape drives currently in the market are fixed-speed, streaming tape drives—that is,
these drives can write data only at one speed. As a result, when they run out of data to write to
tape, they must slow down and stop. For example, when the drive’s buffer empties, the tape is
moving so quickly that it actually overshoots and must rewind past the point where it stopped
writing.
The physical tape block size can affect the backup performance. The block size is the amount of
data that is written by the media management software to a tape in one write operation. The
common rule is that a larger tape block size leads to a faster backup. The physical tape block
size is controlled by the media management software.
If the tape device is attached as a network device, then the network speed may affect tape access
speed also
Tape Subsystem Performance Rules
• Increasing the number of tape drives or the speed of tape

drives provides for faster backup and restore.

• Allocate one channel per physical device:
– If more channels than physical drives are used, then the
backup sets will be intermingled.
– This is similar to multiplexing data files.
• If the tape drive is not streaming, then increase the number
of files that are multiplexed. le
a b
• Back up the files that are likely to be restored together in s er
the
f
same backup set. - t r an
• Use a smaller value for FILESPERSET optionatonmake on
a s
restores faster. ) h eฺ id
o m G u
a ilฺc ent
@ gm Stud
u
Copyright
s
a use
( M to
Tape Subsystem Performance
y u ki se Rules
You can speed M asthe backup
up l i c enand restore processes by buying more tape drives, faster tape
l
drives,nor y a combination of the two. It is a waste of system resources to allocate more
eideally
Staone channel per tape drive. If more channels than physical drives are used, then the backup
than
sets will be intermingled. This can adversely affect the time it takes to restore selected files.
If a tape drive is not streaming, increasing the number of files multiplexed together may help.
Remember that if a small subset of files in a backup set must be restored, the restore will take
longer if many files are multiplexed into the backup set. Put just enough files into each backup
set to keep the tape drives streaming. It is better to store files that are likely to be restored
together in the same backup set.
If you specify a smaller value for the FILESPERSET option when making your backup, then
the restore times are likely to be less, with the possible disadvantage of the backup taking longer.

Controlling Tape Buffer Size with BLKSIZE

• Adjust the size of the tape buffer to keep the tape streaming.
• Use the BLKSIZE option of PARMS to set the desired buffer
size:
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE
2> PARMS="BLKSIZE=1048576 ";
• Set BLKSIZE to 1 MB to correspond to the buffer size.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M with u
Controlling Tape Buffer k i Size t o
a s yu ense BLKSIZE
If the tape is not
y lic but the problem is not due to an incremental backup or by the
M streaming,
backing n e of empty files, then try adjusting the block size of the tape buffer. You can change
lup
the t a
S size of each tape buffer by using the PARMS parameter of the ALLOCATE CHANNEL or
CONFIGURE CHANNEL command. If the BLKSIZE parameter for PARMS is supported on your
platform, then you can set it to the desired size of each buffer. For example, configure an SBT
channel as follows:
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT
> PARMS="BLKSIZE=1048576";

Channel Tuning
Use the CONFIGURE CHANNEL and ALLOCATE CHANNEL

commands to:
• Limit the size of backup pieces
• Prevent RMAN from consuming too much disk bandwidth
• Determine the level of multiplexing for each channel
• Configure multiple disks, thus spreading the I/O activity
across multiple devices.
• Configure multiple channels on the SBT device, allowing you able
to assign different data files to each one. s fer
n tra
n -
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Channel Tuning k i
a s yu ense
You can set various
y M channel l ic limit parameters that apply to operations that are performed by the
allocatedleserver session in the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands.
n
StaMAXPIECESIZE parameter specifies the maximum size of a backup piece. Use this
The
parameter to make RMAN create multiple backup pieces in a backup set. RMAN creates each
backup piece with a size that is no larger than the value that has been specified in the parameter.
The RATE parameter specifies the bytes per second that RMAN reads on the channel. This
parameter is useful in preventing RMAN from consuming excessive disk bandwidth and
degrading online transaction processing (OLTP) performance. For example, if each disk drive
delivers 3 MB per second and you set RATE=1500K, some disk bandwidth will still be
available to the online system.
The MAXOPENFILES parameter determines the maximum number of input files that a backup
or copy can have open at a given time. If not set manually, the value defaults to 8. The level of
RMAN multiplexing is partially determined by MAXOPENFILES. The level of multiplexing in
turn determines how RMAN allocates disk buffers. Multiplexing is the number of input files that
are simultaneously read from and then written into the same backup piece.

Channel Tuning (continued)

If you configure multiple channels for an SBT device, then you can specifically spread data files
across those channels. Here is an example:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;

BACKUP (DATAFILE 1,2,5 CHANNEL c1)
(DATAFILE 4,6 CHANNEL c2)
(DATAFILE 3,7,8 CHANNEL c3);
BACKUP DATABASE NOT BACKED UP;
}
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Tuning the BACKUP Command
• MAXPIECESIZE limits the size of each backup piece.

• FILESPERSET prevents RMAN from reading from too many

disks at once.
• MAXOPENFILES may inhibit streaming to tape if not set high
enough.
• BACKUP DURATION decreases the amount of load on the
system that the backup operation causes.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Tuning the BACKUP Commandi
a s yu ense
The MAXPIECESIZE
y M ic
lparameter specifies the maximum size of each backup piece created on
t a nle
the channel.
S FILESPERSET parameter specifies the maximum number of files to place in a backup set.
The
If you allocate only one channel, then you can use this parameter to make RMAN create
multiple backup sets. For example, if you have 50 input data files and two channels, you can set
FILESPERSET=5 to create 10 backup sets. This strategy can prevent you from splitting a
backup set among multiple tapes.
The MAXOPENFILES parameter setting depends on your disk subsystem characteristics. If you
use ASM, then set it to 1 or 2. Otherwise, if your data is not striped, then you may want to set
this higher. To gain performance, increase either the number of files per backup set, or this
parameter. If you are not using ASM or striping of any kind, then try increasing
MAXOPENFILES.

Tuning the BACKUP Command (continued)

The BACKUP DURATION option of the BACKUP command can be used in different ways. If
you specify a shorter duration than needed for the backup to complete, then you can use this to
keep the backup activity inside a specific time window. In specific cases, the partial backup that
does complete is not lost.
Also, this option has two modifiers:
• MINIMIZE TIME: The backup runs as fast as possible.

• MINIMIZE LOAD: The backup attempts to use the full amount of time available in the
window. This reduces load on the system.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Tuning RMAN Backup Performance
To tune RMAN backup performance, follow these steps :

1. Remove RATE settings from configured and allocated

channels.
2. Set DBWR_IO_SLAVES if you use synchronous disk I/O.
3. Set LARGE_POOL_SIZE.
4. Tune RMAN tape streaming performance bottlenecks.
5. Query V$ views to identify bottlenecks.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Tuning RMAN Backup k i
Performance
a s yu ense
Mof stepsltoicobtain the best backup performance:
Follow this set
y
a n le RATE settings from configured and allocated channels. The RATE parameter is
1. Remove
t
S used to set the maximum number of bytes (default), kilobytes (K), megabytes (M), or
gigabytes (G) that RMAN reads each second on the channel. It sets an upper limit for bytes
read so that RMAN does not consume too much disk bandwidth and degrade performance.
If your backup is not streaming to tape, ensure that the RATE parameter is not set on the
ALLOCATE CHANNEL or CONFIGURE CHANNEL command.
2. Set DBWR_IO_SLAVES if you use synchronous disk I/O. If your disk does not support
asynchronous I/O, then try setting the DBWR_IO_SLAVES initialization parameter to a
nonzero value. Any nonzero value for DBWR_IO_SLAVES causes a fixed number (four) of
disk I/O slaves to be used for backup and restore, simulating asynchronous I/O. If I/O slaves
are used, I/O buffers are obtained from the SGA. The large pool is used if configured.
Otherwise, the shared pool is used.
Note: By setting DBWR_IO_SLAVES, the database writer processes will use slaves as well.
You may need to increase the value of the PROCESSES initialization parameter.
3. Set LARGE_POOL_SIZE as described on the next page.
4. Tune RMAN tape streaming performance bottlenecks as described later in the lesson.
5. Use V$ views as described earlier in the lesson.

Setting LARGE_POOL_SIZE
• If LARGE_POOL_SIZE is not set, the Oracle server tries to

get memory from the shared pool.

• If LARGE_POOL_SIZE is not big enough, the server does not
allocate buffers from the shared pool.
• If the server cannot get enough memory, it allocates buffers
from the local process memory.
• The Oracle server writes a message to the alert log
indicating that synchronous I/O is used for this backup. e
r a bl
s fe
an
ksfqxcre: failure to allocate shared memory means trsync
-
I/O will be used whenever async I/O to file not
n on
supported natively sa ha ideฺ
m Gu)
ฺ c o t
a il e n
@ gm Stud
u
Copyright
s
a use
( M
Setting LARGE_POOL_SIZE
y u ki se to
The requests for
s cenmemory allocations from the shared pool are small, usually under
acontiguous
M li
y It is possible
5 KB inn l e
size. that a request for a large contiguous memory allocation can fail or
t a
require
S significant memory housekeeping to release the required amount of contiguous memory.
The large pool may be able to satisfy the memory request. The large pool does not have a least
recently used list, so Oracle does not attempt to age memory out of the large pool.
Use the LARGE_POOL_SIZE initialization parameter to configure the large pool. Query
V$SGASTAT.POOL to see in which pool (shared pool or large pool) the memory for an object
resides. The suggested value for LARGE_POOL_SIZE is calculated as:
#_of_allocated_channels * (16 MB + (4*size_of_tape_buffer ))
For backups to disk, the tape buffer is obviously 0, so set LARGE_POOL_SIZE to 16 MB. For
tape backups, the size of a single tape buffer is defined by the RMAN channel parameter
BLKSIZE, which defaults to 256 KB. Assume a case in which you are backing up to two tape
drives. If the tape buffer size is 256 KB, then set LARGE_POOL_SIZE to 18 MB. If you
increase BLKSIZE to 512 KB, then increase LARGE_POOL_SIZE to 20 MB.
Note: The large pool is used only for disk buffers when DBWR_IO_SLAVES > 0 and for tape
buffers when BACKUP_TAPE_IO_SLAVES = TRUE. If you are using Automatic Shared
Memory Management, the large pool is sized automatically in response to system workload.

Tuning RMAN Tape Streaming

Performance Bottlenecks
• Use BACKUP... VALIDATE to determine whether tape
streaming or disk I/O is the bottleneck.

• Use multiplexing to improve tape streaming with disk
bottlenecks.
• Use incremental backups to improve backup performance
with tape bottlenecks.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Tuning RMAN Tape u k
Streaming to u
i (M e Performance Bottlenecks
s y n s
a libottlenecks
e
To identify and
y M remedy c that affect RMAN’s performance on tape backups, perform
a n le actions :
the following
t
S• Use BACKUP... VALIDATE to determine whether tape streaming or disk I/O is the
bottleneck in a given backup job. Compare the time required to run backup tasks with the
time required to run BACKUP VALIDATE of the same tasks. BACKUP VALIDATE of a
backup to tape performs the same disk reads as a real backup but performs no tape I/O. If
the time required for the BACKUP VALIDATE to tape is significantly less than the time
required for a real backup to tape, then writing to tape is the likely bottleneck.
• Use multiplexing to improve tape streaming with disk bottlenecks. In some situations when
RMAN is performing a backup to tape, it may not be able to send data blocks to the tape
drive fast enough to support streaming. For example, during an incremental backup, RMAN
backs up only blocks changed since a previous data file backup as part of the same strategy.
If you do not enable change tracking, RMAN must scan entire data files for changed blocks,
and fill output buffers as it finds such blocks. If there are not many changed blocks, RMAN
may not fill output buffers fast enough to keep the tape drive streaming. You can improve
performance by increasing the degree of multiplexing used for backups. This increases the
rate at which RMAN fills tape buffers, which makes it more likely that buffers are sent to
the media manager fast enough to maintain streaming.

Tuning RMAN Tape Streaming Performance Bottlenecks (continued)

• Use incremental backups to improve backup performance with tape bottlenecks. If writing
to tape is the source of a bottleneck for your backups, consider using incremental backups
as part of your backup strategy. Incremental level 1 backups write only the changed blocks
from data files to tape, so that any bottleneck on writing to tape has less impact on your
overall backup strategy. In particular, if tape drives are not locally attached to the node
running the database being backed up, then incremental backups can be faster.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Summary

• Monitor the progress of RMAN jobs

• Configure RMAN appropriately for asynchronous I/O
• Configure RMAN multiplexing so as to keep tape drives
streaming efficiently
• Evaluate the balance between speed of backup versus
speed of recovery
• Explain the effect of the following parameters on RMAN a b le
performance: MAXPIECESIZE, FILESPERSET, s fer
MAXOPENFILES - t r an
n on
• Explain how the RMAN BACKUP DURATIONs option a can
a eฺ
cause backups to either execute faster)orh takeidlonger
o m u
ilฺc nt G
(freeing up resources for other processing)
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Monitoring and Tuning RMAN
• Monitoring RMAN jobs

• Using EM to monitor RMAN
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
Using Flashback Technology
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Query the recycle bin

• Restore dropped tables from the recycle bin
• Perform Flashback Query
• Use Flashback Version Query
• Use Flashback Transaction Query
• Use Flashback Transaction
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Flashback Technology
Object Scenario Examples Flashback Depends Affects
Level Technology On Data
Database Truncate table; Undesired Database Flashback TRUE

multitable changes made logs
Table Drop table Drop Recycle bin TRUE
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 ble
row fe r a
t r a ns
Keep historical
transaction data
Data Archive Undo data
n- TRUE
no
s a
a
Transaction Investigate and back out Transaction hUndo/redo
suspect transactions m deฺ TRUE
) fromuiArchive
o G
a ilฺc ent logs
@ gm Stud
u
Copyright
s
a use
( M
Flashback Technology
y u ki se to
as litechnology
You can use Flashback
M c en when a logical corruption occurs in the Oracle database
y
and you
t a nle
need to recover data quickly and easily. As with human errors, it is difficult to identify
S objects and rows that are affected by an erroneous transaction. With Flashback technology,
the
you can diagnose how errors are introduced into the database, and then repair the damage. You
can view the transactions that have contributed to specific row modifications, view the entire
set of versions of a given row during a specific time period, or just view data as it appeared at
a specific time in the past. The table in the slide shows typical uses of Flashback technology.
Flashback Database depends on the flashback logs to perform flashback. Flashback Drop uses
the recycle bin. All other techniques use undo data.
Not all flashback features modify the database. Some are simply methods to query other
versions of data; these are tools to investigate a problem and aid in recovery. The results of
flashback queries help you do one of two things:
• Determine the type of database-modifying flashback operation to perform to fix the
problem.
• Feed the result set of these queries into an INSERT, UPDATE, or DELETE statement that
enables you to easily repair the erroneous data.
Flashback Data Archive enables you to use the preceding logical flashback features to access
data from far back in the past. Flashback Database and Flashback Data Archive are covered in
the lesson titled “Additional Flashback Operations.”
Flashback Drop and the Recycle Bin
RECYCLEBIN=ON
DROP TABLE employees; FLASHBACK TABLE

employees ble
TO BEFORE DROP; fe r a
Mistake was ans
made. n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
Flashback Drop anduthe k i (Recycle
e Bin
s y
a licTABLEe n s
Using the FLASHBACK
M command, you can undo the effects of a DROP TABLE
y
t a nlewithout having to use point-in-time recovery.
statement
S The RECYCLEBIN initialization parameter is used to control whether the Flashback
Note:
Drop capability is turned ON or OFF. If the parameter is set to OFF, then dropped tables do not
go into 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.

Recycle Bin
BIN$zbjrBdpw==$0 EMPLOYEES
BIN$zbjra9wy==$0 EMPLOYEES_PK
Recycle
bin
4
DBA_FREE_SPACE
EMPLOYEES BIN$zbjrBdpw==$0
3
l e
EMPLOYEES_PK
Objects are: rab
BIN$zbjra9wy==$0
fe
n s
– Renamed tra n -
o
– Not moved
s an
1
2 ) ha ideฺ
c o m Gu
DROP TABLE employees;
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Recycle Bin
y u ki se to
as binlicenabled,
Without the recycle
M en when you drop a table, the space associated with the table
l ey
and itsndependent objects is immediately reclaimable (that is, it can be used for other objects).
S t a
If the recycle bin is enabled, when you drop a table, then the space associated with the table
and its dependent objects is not immediately reclaimable, even though it does appear in
DBA_FREE_SPACE. Instead, the dropped objects are referenced in the recycle bin and still
belong to their owner. The space used by recycle bin objects is never automatically reclaimed
unless there is space pressure. This enables you to recover recycle bin objects for the
maximum possible duration.
When a dropped table is “moved” to the recycle bin, the table and its associated objects and
constraints are renamed using system-generated names. The renaming convention is as
follows:
BIN$unique_id$version
where unique_id is a 26-character globally unique identifier for this object making the
recycle bin name unique across all databases and version is a version number assigned by
the database.

Recycle Bin (continued)
The recycle bin itself is a data dictionary table that maintains the relationships between the
original names of dropped objects and their system-generated names. You can query the
recycle bin by using the DBA_RECYCLEBIN view. The diagram in the previous slide
illustrates this behavior:
1. You have created a table called EMPLOYEES in your tablespace.
2. You drop the EMPLOYEES table.
3. The extents occupied by EMPLOYEES are now considered as free space.

4. EMPLOYEES is renamed and the new name is recorded into the recycle bin.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

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
– When using original names, the restored table is last in, first
out (LIFO)
• Rename the original name if that name is currently used.
ble
fe r a
ans
FLASHBACK TABLE <table_name> TO BEFORE DROP
n - t r
[RENAME TO <new_name>];
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Restoring Tables from k i
u nsRecycle
the e Bin
s y
a TABLE e ... TO BEFORE DROP command to recover a table and all of
Use the FLASHBACK
M l i c
l eydependent objects from the recycle bin. You can specify either the original name
its possible
n
ta table or the system-generated name assigned to the object when it was dropped.
ofSthe
If you specify the original name, and if the recycle bin contains more than one object of that
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 the
system-generated name of the table that you want to retrieve, or issue additional FLASHBACK
TABLE ... TO BEFORE DROP statements until you retrieve the table you want.
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.
Note: When you flash back a dropped table, the recovered indexes, triggers, and constraints
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
recovered indexes, triggers, and constraints to more usable names.

Recycle Bin: Automatic

Space Reclamation
Recycle bin
BIN$zbjrBdpw==$0
BIN$zbjra9wy==$0 BIN$zbjrBdpw==$0
BIN$zbjra9wy==$0
ble
fe r a
ans
DBA_FREE_SPACE - RECYCLEBIN 1
n - t r
a no
a s
) h
Autoextendi d e3ฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Recycle Bin: Automatic k i
u Space e Reclamation
s y
a used n s
eby recycle bin objects is not reclaimed, you can recover those
As long as theMspace l i c
l
objectsnbyeyusing Flashback Drop. The following are recycle bin object reclamation policies:
S• taManual cleanup when you explicitly issue a PURGE command
• Automatic cleanup under space pressure: While objects are in the recycle bin, their
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:
1. Free space not corresponding to recycle bin objects
2. Free space corresponding to recycle bin objects. In this case, recycle bin objects are
automatically purged from the recycle bin using a first in, first out (FIFO) algorithm.
3. Free space automatically allocated if the tablespace is auto-extensible. Suppose that
you create a new table inside the TBS1 tablespace. If there is free space allocated to
this tablespace that does not correspond to a recycle bin object, this free space is used
as a first step. If this is not enough, free space is used that corresponds to recycle bin
objects that reside inside TBS1. If the free space of some recycle bin objects is used,
these objects are purged automatically from the recycle bin. At this time, you can no
longer recover these objects by using the Flashback Drop feature. As a last resort, the
TBS1 tablespace is extended (if possible) if the space requirement is not yet satisfied.

Recycle Bin: Manual Space Reclamation
PURGE {TABLE <table_name>|INDEX <index_name>}

PURGE TABLESPACE <ts_name> [USER <user_name>]
PURGE [USER_|DBA_]RECYCLEBIN
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Recycle Bin: ManualuSpacek i (M Reclamation
t o
a s y ense
Use the PURGE
y M commandlic to permanently remove objects from the recycle bin. When an
objectnisle
purged from the recycle bin, the object and dependent objects are permanently
S t a
removed from the database. As a consequence, objects purged from the recycle bin are no
longer recoverable by using Flashback Drop. The following are possible uses of PURGE:
• PURGE TABLE purges the specified table.
• PURGE INDEX purges the specified index.
• PURGE TABLESPACE purges all the objects residing in the specified tablespace. In
addition, objects residing in other tablespaces may get purged if they are dependent.
• PURGE RECYCLEBIN purges all the objects that belong to the current user.
RECYCLEBIN and USER_RECYCLEBIN are synonymous.
• PURGE DBA_RECYCLEBIN purges all the objects. You must have enough system
privileges or the SYSDBA system privilege to issue this command.
Tables can also be purged from the recycle bin using Enterprise Manager. On the Schema
folder tab, click Tables, then select the schema the dropped object resided in and click the
Recycle Bin button. Select the table from the results list and click the Purge button.
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] ;

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Bypassing the Recycle k i Bin
a s yu ense
You can use the
y ic PURGE command to permanently drop a table and its
M DROPlTABLE
t a nle objects from the database. When you use this command, the corresponding objects
dependent
S not moved to the recycle bin. This command provides the same functionality that the
are
DROP TABLE command provided in previous releases.
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 bin
belonging to the tablespace are purged. When you issue the same command without the
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, these
objects are purged.
When you issue the DROP USER ... CASCADE command, the user and all the objects owned
by the user are permanently dropped from the database. Any objects in the recycle bin
belonging to the dropped user are purged.

Querying the Recycle Bin
SELECT owner, original_name, object_name,

type, ts_name, droptime, related, space

FROM dba_recyclebin
WHERE can_undrop = 'YES';
SQL> SELECT original_name, object_name, ts_name, droptime

FROM user_recyclebin WHERE can_undrop = 'YES';
ORIGINAL_NAME OBJECT_NAME TS_NAM DROPTIME

------------- ----------------------- ------ -------------------
ble
EMPLOYEES2 BIN$NE4Rk64w...gbpQ==$0 USERS 2007-07-02:15:45:13
fe r a
ans
n - t r
SQL> SHOW RECYCLEBIN
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Querying the Recycle k i
Bin
a s yu ense
You can viewM
y lic that you have dropped by querying user_recyclebin or
all the objects
nle
RECYCLEBIN.
t a
It has a synonym RECYCLEBIN, for ease of use.
S dba_recyclebin view shows you all the objects that have been dropped by all users
The
and that are still in the recycle bin.
You can also use the SQL*Plus SHOW RECYCLEBIN command. This command shows you
only those objects that can be “undropped.”
The examples show how to extract important information from the recycle bin:
• original_name is the name of the object before it is dropped.
• object_name is the system-generated name of the object after it is dropped.
• type is the object’s type.
• ts_name is the name of the tablespace to which the object belongs.
• droptime is the date at which the object was dropped.
• related is the object identifier of the dropped object.
• space is the number of blocks currently used by the object.
You can also see the content of the recycle bin by using Database Control.
Note: For detailed information about the DBA_RECYCLEBIN view, see the Oracle Database
Reference guide.

Transactions and Undo

Original data
in
buffer cache
Undo “old” data

ble
in undo tablespace fe r a
ans
n - t r
DML operations
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Transactions and Undo k i
a s yu ense
When a transaction
y lic it is assigned to an undo segment. Throughout the life of the
M starts,
t a nle when data is changed, the original “old” values are copied into the undo segment.
transaction,
S can see which transactions are assigned to which undo segments by checking the
You
V$TRANSACTION dynamic performance view.
Undo segments are specialized segments that are automatically created by the instance as
needed to support transactions. Like all segments, undo segments are made up of extents,
which, in turn, consist of data blocks. Undo segments automatically grow and shrink as
needed, acting as a circular storage buffer for their assigned transactions.
Transactions fill extents in their undo segments until a transaction is completed or all space is
consumed. If an extent fills up and more space is needed, the transaction acquires that space
from the next extent in the segment. After all extents have been consumed, the transaction
either wraps around back into the first extent or requests a new extent to be allocated to the
undo segment.
Note: Parallel DML operations can actually cause a transaction to use more than one undo
segment. To learn more about parallel DML execution, see the Oracle Database

Guaranteeing Undo Retention

Retention guarantee:
15 minutes
Undo data in
undo
ble
tablespace
fe r a
ans
n - t r
o
SELECT statements a nthat generates
A transaction
s
running 15 minutes or less more
) h aundo than
e ฺ what there
are always satisfied. m is space i d
u for will fail.
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
ki se to
Guaranteeing UndouRetention
y
s ceisnto overwrite committed transactions that have not yet expired
abehavior
The default undo
M li
rather n l
thaneyto allow an active transaction to fail because of lack of undo space. In case of
Sta transactions have precedence over queries.
conflict,
This behavior can be changed by guaranteeing retention. With guaranteed retention, undo
retention settings are enforced even if they cause transactions to fail. (So in case of conflict,
queries have precedence over transactions.)
RETENTION GUARANTEE is a tablespace attribute rather than an initialization parameter.
This attribute can be changed using either SQL command-line statements or Enterprise
Manager. The syntax to change an undo tablespace to guarantee retention is:
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
To return a guaranteed undo tablespace to its normal setting, use the following command:
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
You can set Undo Retention Guarantee in Enterprise Manager. Navigate to the Automatic
Undo Management page. Click the current setting for Retention Guarantee (General/Undo
Retention Settings) to modify it.

Preparing Your Database for Flashback
• Creating an undo tablespace

• Enabling Automatic Undo Management

• Specifying versus guaranteeing undo retention
Default database initialization parameters:

– UNDO_MANAGEMENT='AUTO'
– UNDO_TABLESPACE='UNDOTBS1'
– UNDO_RETENTION=900 ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Preparing Your Database k i
u nfor eFlashback
s y
a features s
e for an application, you must perform these tasks:
To enable flashback
M l i c
l eyan undo tablespace with enough space to keep the required data for flashback
• Create
n
Staoperations.
The more often users update the data, the more space is required. The database
administrator usually calculates the space requirement. If you are uncertain about your
space requirements, you can start with an automatically extensible undo tablespace,
observe it through one business cycle (for example, 1 or 2 days), collect undo block
information with the V$UNDO_STAT view, calculate your space requirements, and use
them to create an appropriately sized fixed undo tablespace. (The calculation formula is in
the Oracle Database Administrator’s Guide.)
• By default, Automatic Undo Management is enabled. If needed, enable Automatic Undo
Management, as explained in the Oracle Database Administrator’s Guide.
• For a fixed-size undo tablespace, the Oracle database automatically tunes the system to
give the undo tablespace the best possible undo retention.
• For an automatically extensible undo tablespace (default), the Oracle database retains
undo data to satisfy at a minimum, the retention periods needed by the longest-running
query and the threshold of undo retention, specified by the UNDO_RETENTION
parameter.

Preparing Your Database for Flashback (continued)
You can query V$UNDOSTAT.TUNED_UNDORETENTION to determine the amount of time
for which undo is retained for the current undo tablespace. Setting the UNDO_RETENTION
parameter does not guarantee, that unexpired undo data is not overwritten. If the system needs
more space, the Oracle database can overwrite unexpired undo with more recently generated
undo data.
• Specify the RETENTION GUARANTEE clause for the undo tablespace to ensure that
unexpired undo data is not discarded.

• Grant flashback privileges to users, roles, or applications that need to use flashback
features.
To satisfy long retention requirements, create a flashback data archive.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Using Flashback Technology to Query Data
• Flashback Query
– Query all data at a specified point in time.

• Flashback Version Query
– See all versions of a row between two times.
– See the transactions that changed the row.
• Flashback Transaction Query
– See all changes made
by a transaction. Time
ble
fe r a
ans
n - t r
Tx3
a no
Tx2 a s
) h i d eฺ Flashback
Tx1 o m
c nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Using Flashback Technology i
u nseto Query Data
s y
a provides e the capability to query past versions of schema objects, query
Flashback technology
M l i c
y and perform change analysis. Every transaction logically generates a new
l
historical
n edata,
Sta of the database. With Flashback technology, you can navigate through these versions
version
to find an error and its cause:
• Flashback Query: Query all data as it existed at a specific point in time.
• Flashback Version Query: See all versions of rows between two times and the
transactions that changed the row.
• Flashback Transaction Query: See all changes made by a transaction.

Flashback Query
Use to query all data at a specified point in time.
employees Unwanted employees

updates
T1 T2 ble
fe r a
ans
n - t r
SELECT employee_id, salary FROM employees
n o
AS OF TIMESTAMP <T1> s a
h a ฺ
WHERE employee_id = 200 ) ide o m Gu
il ฺ c n t
a e
@ gm Stud
u
Copyright
s
a use
( M to
Flashback Query uki e
y
as Query s
n you can perform queries as of a certain time. By using the
efeature,
With the Flashback
M l i c
l ey of the SELECT statement, you can specify the time stamp for which to view the
AS OFnclause
StaThis is useful for analyzing a data discrepancy.
data.
Note: TIMESTAMP and SCN are valid options for the AS OF clause.

Flashback Query: Example

employees employees employees
salary = 4,400 salary = 4,840 salary = 4,400
11:00 11:10
UPDATE employees
a b le
SET salary = s fer
(SELECT salary FROM employees
- t r an
AS OF TIMESTAMP TO_TIMESTAMP n on
s a
('2005-05-04 11:00:00', 'yyyy-mm-dd hh24:mi:ss')
WHERE employee_id = 200)
a
) h uideฺ
m
WHERE employee_id = 200 ฺco G
a il n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Flashback Query: Example
y u ki se to
If a raise has M aserroneously
been l i c en given to a particular employee recently, you can update the
l ey assigning the salary provided by a subquery that returns the flashed-back value.
salarynagain,
Sta

Flashback Version Query

Tx0 Tx1 Tx2
employees employees employees
200
t1 t2
SELECT versions_xid, salary FROM employees
ble
VERSIONS BETWEEN TIMESTAMP <t1> and <t2> fe r a
ans
WHERE employee_id = 200;
n - t r
a no
a s
Tx0 Tx1 ) h
Tx2
i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Version Query k i
a s yu ense
With Flashback
y c can perform queries on the database as of a certain time span or
M Query,liyou
range nofle
user-specified system change numbers (SCNs). The Flashback Version Query feature
t a
enables
S you to use the VERSIONS clause to retrieve all the versions of the rows that exist
between two points in time or two SCNs.
The rows returned by Flashback Version Query represent a history of changes for the rows
across transactions. Flashback Version Query retrieves only committed occurrences of the
rows. Uncommitted row versions within a transaction are not shown. The rows returned also
include deleted and subsequently reinserted versions of the rows.
You can use Flashback Version Query to retrieve row history. It provides you with a way to
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
LogMiner or to perform a Flashback Transaction Query, as described later in this lesson.
Note: VERSIONS_XID is a pseudocolumn that returns the transaction identifier of the
corresponding version of a row.

Using Enterprise Manager to Perform

Flashback Version Query
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Version Query k i
u nUsing e Enterprise Manager
s y
a Flashback s
e Version Query by using Enterprise Manager (EM).
You can also Mperform l i c
On the n l ey
Availability page, select Perform Recovery.
t a
S the Perform Recovery page, select Tables as Object Type and Flashback Existing Tables as
On
Operation Type. Click Perform Object Level Recovery. On the “Perform Object Level
Recovery: Point-in-Time” page, select “Evaluate row changes and transactions to decide on a
point in time,” and specify the name of the target table.
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.

Flashback Version 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.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k
Flashback Version Query:i
u nConsiderations
a s y e se
The VERSIONS
y c be used to query the following types of tables:
M clauselicannot
t a nle tables
• External
S• Temporary tables
• Fixed tables
You cannot use the VERSIONS clause to query a view. However, a view definition can use the
VERSIONS clause.
The VERSIONS clause in a SELECT statement cannot produce versions of rows across the
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.
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
the same.

Flashback Transaction Query

FLASHBACK_TRANSACTION_QUERY
DBA
Erroneous
Undo e
DML
SQL r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
User
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Flashback Transaction k i Query
a s yu ense
Flashback Transaction
y M ic is a diagnostic tool that you can use to view changes made to the
lQuery
t a nleat the transaction level. This enables you to diagnose problems in your database and
database
S analysis and audits of transactions.
perform
You can use the FLASHBACK_TRANSACTION_QUERY view to determine all the necessary
SQL statements that can be used to undo the changes made either by a specific transaction or
during a specific period of time.

Using Enterprise Manager to Perform

Flashback Transaction Query
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u nstoePerform Flashback Transaction Query
s y
a in conjunction
e
This feature isMused
y l i c with the Flashback Version Query feature with the help of
t a nle Recovery Wizard. On the “Perform Object Level Recovery: Choose SCN” page,
the Perform
S the corresponding Transaction ID link in the Flashback Version Query Result region.
click
In the example in the slide, a Flashback Version Query is performed on the JOBS table to
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
that in addition to the JOBS table update, there was also an update to the EMPLOYEES table in
that transaction.

Flashback Transaction Query:

Considerations
• DDL commands are seen as dictionary updates.
• Flashback Transaction Query on a transaction underlying a

DDL command displays the data dictionary changes.
• Dropped objects appear as object numbers.
• Dropped users appear as user identifiers.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Transaction k i
u nse Considerations
Query:
s y
a DDL eoperations are nothing but a series of space management operations
Within the database,
M l i c
l ey to the data dictionary. Flashback Transaction Query on a transaction underlying a
and changes
n
Stacommand displays the changes made to the data dictionary.
DDL
When Flashback Transaction Query involves tables that have been dropped from the database,
the table names are not reflected. Instead, object numbers are used.
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.
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.

Flashback Transaction
• Setting up Flashback Transaction prerequisites

• Stepping through a possible workflow

• Using the Flashback Transaction Wizard
• Querying transactions with and without dependencies
• Choosing back-out options and flashing back transactions
• Reviewing the results
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
a s yu ense
With Flashback
y lic you can reverse a transaction and dependant transactions. Oracle
M Transaction,
t a nledetermines the dependencies between transactions and, in effect, creates a
Database
S
compensating transaction that reverses the unwanted changes. The database rewinds to a state
as if the transaction, and any transactions that could be dependent on it, never occurred.
You can use the Flashback Transaction functionality from within Enterprise Manager or with
PL/SQL packages.

Prerequisites
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Prerequisites k i
a s yu ense
In order to use
y lic
Mthis functionality, supplemental logging must be enabled and the correct
a n leestablished. For example, the HR user in the HR schema decides to use Flashback
privileges
S t
Transaction for the REGIONS table. The SYSDBA performs the following setup steps in
SQL*Plus:
alter database add supplemental log data;
alter database add supplemental log data (primary key) columns;
grant execute on dbms_flashback to hr;
grant select any transaction to hr;

Flashing Back a Transaction
• You can flash back a transaction with Enterprise Manager or

from the command line.

• EM uses the Flashback Transaction Wizard, which calls the
DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure
with the NOCASCADE option.
• If the PL/SQL call finishes successfully, it means that the
transaction does not have any dependencies and a single
transaction is backed out successfully. e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
k i
Flashing Back a Transaction
a s yu ense
Security privileges
yM lic
l e
n back or back-out a transaction—that is, to create a compensating transaction—you
To flash
t a
S have the SELECT, FLASHBACK, and DML privileges on all affected tables.
must
Conditions of Use
• Transaction back-out is not supported across conflicting DDL.
• Transaction back-out inherits data type support from LogMiner. See the Oracle Database
11g documentation for supported data types.
Recommendation
• When you discover the need for transaction back-out, performance is better if you start
the back-out operation sooner. Large redo logs and high transaction rates result in slower
transaction back-out operations.
• Provide a transaction name for the back-out operation to facilitate later auditing. If you do
not provide a transaction name, it will be automatically generated for you.

Possible Workflow
1. Viewing data in a table

2. Discovering a logical problem

3. Using Flashback Transaction
1. Performing a query
2. Selecting a transaction
3. Flashing back a transaction (with no conflicts)
4. Choosing other back-out options (if conflicts exists)
4. Reviewing Flashback Transaction results ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Possible Workflow uki
a s y ense
Assume that several
y lic
M transactions occurred as indicated below:
connect
t a nle hr/hr
S
INSERT INTO hr.regions VALUES (5,'Pole');
COMMIT;
UPDATE hr.regions SET region_name='Poles' WHERE region_id = 5;
UPDATE hr.regions SET region_name='North and South Poles' WHERE
region_id = 5;
COMMIT;
INSERT INTO hr.countries VALUES ('TT','Test Country',5);
COMMIT;
connect sys/<password> as sysdba
ALTER SYSTEM ARCHIVE LOG CURRENT;

Viewing Data
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing Data k i
a s yu ense
To view the data
y lic in Enterprise Manager, go to the Schema folder and select Tables
M in a table
under n
a le objects.
Database
t
S viewing the content of the HR.REGIONS table, you discover a logical problem. Region
While
5 is misnamed. You decide to immediately address this issue.

Flashback Transaction Wizard

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Transaction k i Wizard
a s yu ense
In Enterprise M
y c HR.REGIONS under Table, select Flashback Transaction from
Manager,liselect
t a nle drop-down list, and then click Go. This invokes the Flashback Transaction Wizard
the Actions
S your selected table. The Flashback Transaction: Perform Query page is displayed.
for
Select the appropriate time range and add query parameters. (The more specific you can be,
the shorter is the search of the Flashback Transaction Wizard.)
Without Enterprise Manager, use the DBMS_FLASHBACK.TRANSACTION_BACKOUT
procedure, which is described in the PL/SQL Packages and Types Reference. Essentially, you
take an array of transaction IDs as the starting point of your dependency search. For example:
CREATE TYPE XID_ARRAY AS VARRAY(100) OF RAW(8);
CREATE OR REPLACE PROCEDURE TRANSACTION_BACKOUT(
numberOfXIDs NUMBER, -- number of transactions passed as input
xids XID_ARRAY, -- the list of transaction ids
options NUMBER default NOCASCADE, -- back out dependent
txn timeHint TIMESTAMP default MINTIME -- time hint on the txn
start
);


ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u nse (continued)
Wizard
s y
a lice Select Transaction page displays the transactions according to
The FlashbackM Transaction:
l ey entered specifications. First, display the transaction details to confirm that you
your previously
n
are a
Stflashing back the correct transaction. Then select the offending transaction and continue
with the wizard.

1
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
u nse (continued)
Wizard
s y
a liceWizard now generates the undo script and flashes back the
The Flashback MTransaction
l eybut it gives you control to COMMIT this flashback. Before you commit the
transaction,
n
Sta
transaction, you can use the Execute SQL area at the bottom of the Flashback Transaction:
Review page, to view what the result of your COMMIT will be.


ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Finishing Up k i
a s yu ense
On the Flashback
y lic Review page click the Show Undo SQL Script button to view
M Transaction:
t a nle
the compensating SQL commands. Click Finish to commit your compensating transaction.
S

Choosing Other Back-out Options

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Choosing Other Back-out k i
u nOptions
a s y e se
y M lic
The TRANSACTION_BACKOUT procedure checks dependencies, such as:
t a nle
• Write-after-write (WAW)
S• Primary and unique constraints
A transaction can have a WAW dependency, which means a transaction updates or deletes a
row that has been inserted or updated by a dependent transaction. This can occur, for example,
in a master/detail relationship of primary (or unique) and mandatory foreign key constraints.
To understand the difference between the NONCONFLICT_ONLY and the
NOCASCADE_FORCE options, assume that the T1 transaction changes rows R1, R2, and R3
and the T2 transaction changes rows R1, R3, and R4. In this scenario, both transactions update
row R1, so it is a “conflicting” row. The T2 transaction has a WAW dependency on the T1
transaction. With the NONCONFLICT_ONLY option, R2 and R3 are backed out, because there
is no conflict and it is assumed that you know best, what to do with the R1 row. With the
NOCASCADE_FORCE option, all three rows (R1, R2, and R3) are backed out.
Note: This screenshot is not part of the workflow example, but shows additional details of a
more complex situation.

Choosing Other Back-out Options

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Choosing Other Back-outk i
u nOptions
e (continued)
s y s
a liceWizard works as follows:
The Flashback MTransaction
If the n l ey
DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure with the NOCASCADE
S t a
option fails (because there are dependent transactions), you can change the recovery options.
• With the Nonconflict Only option, nonconflicting rows within a transaction are backed
out, which implies that database consistency is maintained (although the transaction
atomicity is broken for the sake of data repair).
• If you want to forcibly back out the given transactions, without paying attention to the
dependent transactions, use the Nocascade Force option. The server simply executes the
compensating DML commands for the given transactions in reverse order of their commit
times. If no constraints break, you can proceed to commit the changes, or else roll back.
• To initiate the complete removal of the given transactions and all their dependents in a
post-order fashion, use the Cascade option.
Note: This screenshot is not part of the workflow example, but shows additional details of a
more complex situation.

Final Steps Without EM
After choosing your back-out option, the dependency report is

generated in the DBA_FLASHBACK_TXN_STATE and

DBA_FLASHBACK_TXN_REPORT views.
• Review the dependency report that shows all transactions
which were backed out.
• Commit the changes to make them permanent.
• Roll back to discard the changes.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Final Steps WithoutuEM k i (M e to u
a sy cens
The DBA_FLASHBACK_TXN_STATE view contains the current state of a transaction:
y M li
whether
t a nleit is alive in the system or effectively backed out. This table is atomically maintained
S the compensating transaction. For each compensating transaction, there could be multiple
with
rows, where each row provides the dependency relationship between the transactions that have
been compensated by the compensating transaction.
The DBA_FLASHBACK_TXN_REPORT view provides detailed information about all
compensating transactions that have been committed in the database. Each row in this view is
associated with one compensating transaction.
For a detailed description of these tables, see the Oracle Database Reference.

Summary

• Query the recycle bin

• Restore dropped tables from the recycle bin
• Perform Flashback Query
• Use Flashback Version Query
• Use Flashback Transaction Query
• Use Flashback Transaction
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Performing Flashback Database
• Recycle bin activities

• Flashback Query
• Flashback Transaction
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Additional Flashback Operations
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Enable row movement on a table

• Perform Flashback Table operations
• Configure Flashback Database
• Perform Flashback Database operations
• Monitor Flashback Database
• Set up and use a Flashback Data Archive
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Flashback Table: Overview
• Flashback Table recovers tables to a specific point in time.

• Flashback Table is an in-place operation.

• The database stays online.
ble
fe r a
ans
n - t r
a no
Erroneous a s
Flashed
DMLs User ) h i d eฺ back
tables
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Flashback Table Overview
y u ki se to
s you
Using FlashbackaTable, c encan recover a set of tables to a specific point in time without having
M l i
to perform
n l eytraditional point-in-time recovery operations.
ta
ASFlashback Table operation is done in-place, while the database is online, by rolling back 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 back
successfully, or the entire transaction is rolled back.
Note: You can use Flashback Versions Query and Flashback Transaction Query to determine the
appropriate flashback time.

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.
• You require the FLASHBACK ANY TABLE or the
FLASHBACK object privilege on the specific table.
• SELECT, INSERT, DELETE, and ALTER privileges on the
table to be flashed back are required. le
a b
• You must enable row movement on the table that you aresfer
n
performing the flashback operation on. -tra on
a n
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Flashback Table
y u ki se to
With Flashback a s you
Table, c n recover a table or tables to a specific point in time without
ecan
M l i
restoringleaybackup. When you use this feature, the data in tables and their associated objects
n
Sta constraints, triggers, and so on) is restored. The data used to satisfy a Flashback Table
(indexes,
request is retrieved from the undo tablespace. You can use Flashback Versions Query and
Flashback Transaction Query to determine the appropriate flashback time.
Flashback Table provides a way for users to easily and quickly recover from accidental
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 Flashback Table
feature. In addition, you must grant the SELECT, INSERT, DELETE, and ALTER object
privileges to the user.
You can use Enterprise Manager to flash back a table. The wizard guides you through the
process.
Note: Enabling row movement is described on the next page.

Enabling Row Movement on a Table

ble
fe r a
ans
n - t r
no
ALTER TABLE employees ENABLE ROW MOVEMENT;
a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Enabling Row Movement
y u ki onsea Table
s movement
You must enablearow c en on a table to be able to flash back the table. When you enable
M l i
n l ey the Oracle server can move a row in the table.
row movement,
Sta Enterprise Manager, you can enable row movement on a table by performing the
Using
following steps:
1. Select Tables in the Database Objects region of the Schema property page. Enter the
schema name to search for the table, and click Go.
2. Click the table name of the table for which you want to enable row movement. You are now
on the View Table page.
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.
5. Set Enable Row Movement to Yes, and click Apply. The update confirmation message is
displayed.

Performing Flashback Table

ble
fe r a
ans
n - t r
n o
FLASHBACK TABLE hr.departments TO TIMESTAMP s a
) h a eฺ
TO_TIMESTAMP('2007-04-05 21:00:00',
m i d
'YYYY-MM-DD HH24:MI:SS');
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Performing Flashback k i
Table
a syu Manager
You can use Enterprise e n seto flash back a table by performing the following steps:
1. Select yPerform lic in the Backup/Recovery region on the Availability property page.
M Recovery
n l e
S2.taIn the Object Level Recovery region, select Tables from the Object Type drop-down list.
3. Select Flashback Existing Tables as Operation Type. Click Recover. The “Perform Object
Level Recovery: Point-in-time” page is displayed.
4. Select “Flashback to a timestamp” or “Flashback to a known SCN” and then specify a 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.
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 a
consistent flashback. Click Next.
7. The “Perform Object Level Recovery: Review” page appears. Review the information and
click Submit. The Confirmation page appears.
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 ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
Flashback Table: Considerations
a syu cenTABLE
• The entire FLASHBACK
se statement is executed within a single transaction. All or
none y the
of
li tables are flashed back.
M specified
n l e
S• taFlashback Table acquires exclusive data manipulation language (DML) locks on all the
tables that are specified in the statement over the period of time when the operation is in
progress.
• Statistics of impacted objects are not flashed back.
• All existing indexes are maintained. Dropped indexes are not re-created. Dependent on-
commit materialized views are also maintained automatically.
• Tables specified in the FLASHBACK TABLE statement are flashed back, provided that 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 just
before the FLASHBACK TABLE statement invocation.
• You cannot perform Flashback Table to a particular time that is older than the time of the
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
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
The Flashback Database operation:

• Works like a rewind button for the database

• Can be used in cases of logical data corruptions made by
users
ble
fe r a
a n s
Errors are The "Press the rewind button" - t r The
generated. database is (FLASHBACK DATABASE). on database is
corrupted. a n "rewound."
s ha ideฺ
m Gu)
ฺ c o t
a il e n
@ gm Stud
u
Copyright
s
a use
Flashback Databaseuki
( M to
y
s ceyou s e
n can quickly bring your database to an earlier point in time by
With Flashback a Database,
undoingle
M l i
allythe changes that have taken place since that time. This operation is fast because you
n
S a need to restore backups. You can use this feature to undo changes that have resulted in
do tnot
logical data corruptions.
When you use Flashback Database, Oracle Database uses past block images to back out changes
to the database. During normal database operation, Oracle Database occasionally logs these
block images in flashback logs. Flashback logs are written sequentially and are not archived.
Oracle Database automatically creates, deletes, and resizes flashback logs in the Flash Recovery
Area. You need to be aware of flashback logs only for monitoring performance and deciding
how much disk space to allocate to the Flash Recovery Area for flashback logs.
The time it takes to rewind a database with Flashback Database is proportional to how far back
in time you need to go and the amount of database activity after the target time. The time it
would take to restore and recover the whole database could be much longer. The before images
in the flashback logs are used only to restore the database to a point in the past, and forward
recovery is used to bring the database to a consistent state at some time in the past. Oracle
Database returns data files to the previous point in time, but not auxiliary files, such as
initialization parameter files. Flashback Database can also be used to compliment Data Guard
and Recovery Advisor, and for synchronizing clone databases.

Flashback Database Architecture
SGA
Not every Redo log

Flashback
change! buffer
Buffer cache
buffer LGWR
Every
change
Log block
before
images
periodically.
ble
Flashback RVWR
Redo
fe r a
logs logs
ans
Do forward
n - t r
1
Back out changes media recovery.
2 n
o
to database using
s a
before images.
) h a eฺ
m i d
…
i l ฺ co nt Gu …
g ma tude
sy se th
a
k i (M e to u
Flashback DatabaseuArchitecture
When you enable a Flashback
s
sy cenDatabase, the RVWR (Flashback Writer) background process is
M l i
n l ey background process sequentially writes Flashback Database data from the flashback
started. This
ta to the Flashback Database logs, which are circularly reused. Subsequently, when a
buffer
S
FLASHBACK DATABASE command is issued, the flashback logs are used to restore to the
blocks’ before 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
workload. Because queries do not need to log any flashback data, the more write-intensive the
workload, the higher the overhead of turning on Flashback Database.

Configuring Flashback Database

1. Configure the 2. Set the retention 3. Enable Flashback

flash recovery area. target. Database.
bl e
SQL> SHUTDOWN IMMEDIATE;
fe r a
SQL> STARTUP MOUNT EXCLUSIVE;
n s
SQL> ALTER SYSTEM SET
n - tra
2 no
DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
a
SQL> ALTER DATABASE FLASHBACK ON;
h a s ฺ
SQL> ALTER DATABASE OPEN; ) ide o m Gu
il ฺ c n t
a e
@ gm Stud
u
Copyright
s
a use
( M to
Configuring Flashback
y u kiDatabase
s e
You can configure
M asFlashback
l i c enDatabase as follows:
n l ey the Flash Recovery Area.
1. Configure
S2.taSet the retention target with the DB_FLASHBACK_RETENTION_TARGET initialization
parameter. You can specify an upper limit, in minutes, on how far back you want to be able
to flash back the database. The example uses 2,880 minutes, which is equivalent to two
days. 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.
3. Enable Flashback Database with the following command:
ALTER DATABASE FLASHBACK ON;
Before you can issue the command to enable Flashback Database, the database must be
configured for archiving and started in MOUNT EXCLUSIVE mode.
You can determine whether Flashback Database is enabled with the following query:
SELECT flashback_on FROM v$database;
You can disable Flashback Database with the ALTER DATABASE FLASHBACK OFF
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.

Configuring Flashback Database Using EM
Make sure that the database is in ARCHIVELOG mode.

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toUsing u
Configuring Flashback k
u nse iDatabase EM
s y
a Manager
Log in to Enterprise e (EM). On the Availability page, select Recovery Settings in the
M l i c
n l ey
Backup/Recovery region. Make sure that your database is in ARCHIVELOG mode. If not, select
Sta
ARCHIVELOG Mode and then click Continue. You will need to shut down and restart the
instance for your changes to take effect.

Configuring Flashback Database Using EM
Enable flashback logging and specify the Flash Recovery Area.

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toUsing u
Configuring Flashback k
u nseiDatabase EM (continued)
s y
a that
When you are certain ethe database is in ARCHIVELOG mode, return to the Recovery
M l i c
ey and scroll down to the Flash Recovery Area region to observe the new settings.
Settingslpage
n
Sta the Flash Recovery Area and archiving are configured,
When
USE_DB_RECOVERY_FILE_DEST is configured for archive log destination 10. Enable
flashback logging by selecting Enable Flashback Logging. You can also set the flashback
retention time, and you can view important information regarding your flashback database
window.
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 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: archived redo log
files, control files, backups created by Recovery Manager (RMAN), flashback logs, and the
change tracking file. By allocating a storage location and unifying recovery-related files within a
specific area, the Oracle database server relieves the database administrator from having to
manage the disk files created by these components. The default location for the Flash Recovery
Area is $ORACLE_BASE/flash_recovery_area. If you would like 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('2007-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 ble

fe r a
2 TO TIMESTAMP(SYSDATE-1/24);
ans
n - t r
SQL> FLASHBACK DATABASE TO SCN 53943;
a no
a s
SQL> FLASHBACK DATABASE TO RESTORE POINT h
) b4_load;
i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Database: k i
Examples
You can use the a RMAN e nse DATABASE command to execute the Flashback Database
syu cFLASHBACK
operation.
i
yYouMcan uselSEQUENCE and THREAD to specify a redo log sequence number and
n l e
ta as a lower limit. RMAN selects only files that can be used to flash back to, but not
thread
S
including, the specified sequence number.
Alternatively, you can use the SQL FLASHBACK DATABASE 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 specify
TO TIMESTAMP, you must provide a time stamp value. You can also specify a restore point
name.
Note: The database must be mounted in exclusive mode to issue the FLASHBACK DATABASE
command and opened read-only to review changes. The database must be opened read/write
with the RESETLOGS option when finished.

Performing Flashback Database Using EM

Selecting object and operation type:
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toUsing u
Performing Flashback k
u nsei
Database EM
s
On the Availability
y
a page, e Perform Recovery. From the Recovery Scope drop-down list,
choose
M l i c
n l ey Database. Next, select “Recover to the current time or a previous point-in-time” as
select Whole
Sta Type. Finally, provide the operating system credentials for a database user (that is,
Operation
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.

Launching the Recovery Wizard:

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toUsing u
Performing Flashback k
u nsei
Database EM (continued)
s y
a operation
After the recovery e type has been chosen, the Recovery Wizard is launched. You are
M l i c
y the database will be shut down and restarted in MOUNT mode. This operation takes
informedlethat
n
Sta minutes and you will be informed of the delay. After waiting an appropriate amount of
several
time, you must click Refresh to continue with the operation.


ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M toUsing u
Performing Flashback k i
Database
u nse EM (continued)
s y
a islicnow
The Recovery Wizard e started. At this stage, the database is shut down and started in
M
ey Click Refresh.
MOUNT lmode.
n
Stadisplays the Perform Recovery: Point-in-time page. On this page, select the “Recover to a
This
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
recovery using flashback or regular recovery. Choose the corresponding option, and then click
Next. Next in the sequence is the Perform Whole Database Recovery: Review page that is
shown in the slide. Click Submit to flash back the database.

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
• The opposite of “flash back” is “recover.”
• You cannot use Flashback Database in the following
situations: e
– The control file has been restored or re-created. r a bl
ns fe
– A tablespace has been dropped. - t r a
o n
– A data file has been reduced in size. an s
• Use the TO BEFORE RESETLOGS clause) tohaflashi d ฺ to
eback
m u
lฺco t G
before the last RESETLOGS operation.
ai den
m
g Stu
Copyright
t h
( M a use
ki se to
Flashback DatabaseuConsiderations
y
asyoulicannot
In situations where
M c en use the Flashback Database feature, you should use an
incomplete
n l eyrecovery operation to return the database to a specific time. After the Flashback
Sta operation is complete, you can open the database in read-only mode to verify that the
Database
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. So, to undo a Flashback Database operation, you should
recover the database forward.
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 offline,
but it is not flashed back. Flashback Database cannot flash back a data file to a time 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 beginning
the Flashback Database operation. This is applicable for files that are shrunk rather than
expanded. You can use Flashback Database with data files that you have configured for
automatic extension. You can flash back to just before the last RESETLOGS operation by
supplying the TO BEFORE RESETLOGS clause in the FLASHBACK DATABASE command.
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 ble
fe r a
3 FROM V$FLASHBACK_DATABASE_LOG;
ans
n - t r
• Monitor logging in the Flashback Database logs:no
s a
SQL> SELECT * h a eฺ
2 FROM m)
V$FLASHBACK_DATABASE_STAT; u i d
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
i ( M to
Monitoring Flashback
y u kDatabase
s e
asyou tolicmonitor
It is important for
M en space usage of the Flash Recovery Area so that you know how
well youle y meeting your retention target. Use the V$FLASHBACK_DATABASE_LOG view to
are
n
Sta the Flashback Database retention target:
monitor
• ESTIMATED_FLASHBACK_SIZE uses previously logged flashback data to provide an
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 the
instance was started, or during the most recent time interval equal to the flashback retention
target, whichever is shorter.
• FLASHBACK_SIZE gives you the current size, in bytes, of the flashback data.
• OLDEST_FLASHBACK_SCN and OLDEST_FLASHBACK_TIME display the approximate
lowest SCN and time to which you can flash back your database. CURRENT_SCN in
V$DATABASE gives you the current database SCN.
Use the V$FLASHBACK_DATABASE_STAT view to monitor the overhead of logging flashback
data in the Flashback Database logs. This view contains 24 hours of information, with each row
representing a one-hour time interval. You can use this view to determine rate changes in the
flashback data generation.
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;

Monitoring Flashback Database (continued)

BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA EST_FB_SZE
--------- --------- -------------- ---------- ---------- ----------
12-FEB-07 12-FEB-07 16384 0 24576 0
12-FEB-07 12-FEB-07 6594560 7471104 1533440 815923200
12-FEB-07 12-FEB-07 17235968 12361728 5150720 839467008
12-FEB-07 12-FEB-07 311648256 37249024 10272768 855195648
Based on 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
a b le
• SPACE_LIMIT: Disk limit specified in the DB_RECOVERY_FILE_DEST_SIZE
s fer
parameter
- t r an
• SPACE_USED: Space used by Flash Recovery Area files (in bytes) on
• SPACE_RECLAIMABLE: Amount of space that can be reclaimed
n deleting obsolete,
a by
s
ha ideฺ algorithm
redundant, and other low-priority files through the space) management
• NUMBER_OF_FILES: Number of files
ilฺ ent com Gu
a
m tud
SQL> SELECT name, space_limit AS gquota, S
k @
i AS used,
i s
2 space_used u h
sy sASe treclaimable,
3 a
space_reclaimable
(M to u AS files
4
k i
number_of_files
a syu cense
5 FROM v$recovery_file_dest ;
M li
NAME nley QUOTA USED RECLAIMABLE FILES
S t a
------------------------ ---------- ---------- ----------- -----
/u01/flash_recovery_area 5368709120 2509807104 203386880 226

Monitoring Flashback Database with EM

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M towith u
Monitoring Flashback k i
Database
u nse EM
s y
a Database
Most of the Flashback e statistics mentioned on the preceding pages can be viewed from
M l i c
n l ey Settings page. These metrics include the current space used by all flashback logs,
the Recovery
S a SCN, and the time of the lowest SCN in the flashback data.
thetlowest

Guaranteed Restore Points
A guaranteed restore point ensures that you can perform a

FLASHBACK DATABASE command to that SCN at any time.
bl e
fe r a
SQL> CREATE RESTORE POINT before_upgrade
t r a ns
2 GUARANTEE FLASHBACK DATABASE; on-
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Guaranteed RestoreuPoints
y ki se to
M as points,
Like normal restore
l i c n
eguaranteed restore points can be used as aliases for SCNs in recovery
operations.
n l eyA principal difference is that guaranteed restore points never age out of the control
S a must be explicitly dropped. However, they also provide specific functionality related to
filetand
the use of the Flashback Database feature.
Creating a guaranteed restore point at a particular SCN enforces the requirement that you can
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
guaranteed restore point enforces the retention of flashback logs required for Flashback
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 or
weeks ago, as long as there is enough disk space in the Flash Recovery Area to store the needed
logs. As with normal restore points, guaranteed restore points can be used to specify a point in
time for RECOVER DATABASE operations.
Note: Limitations that apply to Flashback Database also apply to guaranteed restore points. For
example, shrinking a data file or dropping a tablespace can prevent flashing back the affected
data files to the guaranteed restore point.

Flashback Database and

Guaranteed Restore Points
To use guaranteed restore points, the database must satisfy
the following prerequisites:

• The COMPATIBLE initialization parameter must be set to
10.2 or greater.
• The database must be running in ARCHIVELOG mode.
• FLASHBACK DATABASE requires the use of archived redo
logs starting from around the time of the restore point.
• A Flash Recovery Area must be configured. ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u Restore Points
Flashback Databaseuand k i (Guaranteed
a
To support the use e serestore points, the database must satisfy the following
sofy guaranteed
n
yM
prerequisites:
lic
n l e
S• taThe COMPATIBLE initialization parameter must be set to 10.2 or greater.
• The database must be running in ARCHIVELOG mode.
• To rewind your database to a guaranteed restore point, the FLASHBACK DATABASE
command requires the use of archived redo logs starting from around the time of the restore
point.
• A Flash Recovery Area must be configured. Guaranteed restore points use a mechanism
similar to flashback logging. As with flashback logging, the Oracle database must store the
required logs in the Flash Recovery Area.
• If Flashback Database is not enabled, then the database must be mounted, not open, when
creating the first guaranteed restore point (or if all previously created guaranteed restore
points have been dropped).
Logging for Flashback Database and guaranteed restore points involves capturing images of data
file blocks before changes are applied. The FLASHBACK DATABASE command can use these
images to return the data files to their previous state. The chief differences between normal
flashback logging and logging for guaranteed restore points are related to when blocks are
logged and whether the logs can be deleted in response to space pressure in the Flash Recovery
Area. These differences affect space usage for logs and database performance.
Flashback Database and Guaranteed Restore Points (continued)

If you enable Flashback Database and define one or more guaranteed restore points, then the
database performs normal flashback logging. In this case, the recovery area retains the flashback
logs required to flash back to any arbitrary time between the present and the earliest currently
defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if
they are required to satisfy the guarantee.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Flashback Data Archive

Original
data in
buffer cache
DML operations
Background process collects and writes

original data to a Flashback Data Archive.
ble
fe r a
ans
n - t r
Historical
table data a no
a s
) h i d eฺ
m
co nt Gu
ฺ
Flashback Data lArchive
i
g ma tude
sy se th
a
(M to u
Flashback Data Archive k i e
a syu callow
Flashback Data Archives e nsyou to automatically track and archive the data in tables enabled
M l i
n l ey Data Archive. This ensures that flashback queries obtain SQL-level access to the
for Flashback
Sta of database objects without getting a snapshot-too-old error.
versions
A Flashback Data Archive provides the ability to track and store all transactional changes to a
“tracked” table over its lifetime. It is no longer necessary to build this intelligence into your
application. Flashback Data Archives are useful for compliance, audit reports, data analysis, and
decision support systems. The Flashback Data Archive background process starts with the
database.
A Flashback Data Archive consists of one or more tablespaces. You can have multiple
Flashback Data Archives. They are configured with retention duration. Based on your retention
duration requirements, you should create different Flashback Data Archives, for example, one
for all records that must be kept for two years, another for all records that must be kept for five
years. The database will automatically purge all historical information on the day after the
retention period expires.

Flashback Data Archive Process
1. Create the Flashback Data Archive.

2. Specify the default Flashback Data Archive.

3. Enable the Flashback Data Archive.
4. View Flashback Data Archive data.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Flashback Data Archive k i Process
a
The first step is to n se Data Archive. Second, you can specify a default Flashback
yu aeFlashback
screate
Data ArchiveyM lic
for the system. A Flashback Data Archive is configured with retention time. Data
n l e
Sta in the Flashback Data Archive is retained for the retention time.
archived
Third, you can enable flashback archiving (and then disable it again) for a table. While flashback
archiving is enabled for a table, some DDL statements are not allowed on that table. By default,
flashback archiving is off for any table.
Last, you can examine the Flashback Data Archives. There are static data dictionary views that
you can query for information about Flashback Data Archives.

Flashback Data Archive Scenario
Using Flashback Data Archive to access historical data:

-- create the Flashback Data Archive

CREATE FLASHBACK ARCHIVE DEFAULT fla1 1
TABLESPACE tbs1 QUOTA 10G RETENTION 5 YEAR;
-- Specify the default Flashback Data Archive

ALTER FLASHBACK ARCHIVE fla1 SET DEFAULT; 2
ble
-- Enable Flashback Data Archive
fe r a
ALTER TABLE inventory FLASHBACK ARCHIVE;
ans3
ALTER TABLE stock_data FLASHBACK ARCHIVE;
n - t r
a no
SELECT product_number, product_name, count FROM
h a s inventory
ฺ AS
OF TIMESTAMP TO_TIMESTAMP ('2007-01-01) 00:00:00',
m u i de 'YYYY-MM-
o
ilฺc ent G
DD HH24:MI:SS');
a
@ gm Stud
u
Copyright
s
a use
( M to
y u ki Scenario
s e
as liData
You create a Flashback
M c enArchive with the CREATE FLASHBACK ARCHIVE statement.
y optionally specify the default Flashback Data Archive for the system.
• Youlecan
n
S• taYou need to provide the name of the Flashback Data Archive.
• You need to provide the name of the first tablespace of the Flashback Data Archive.
• You can identify the maximum amount of space that the Flashback Data Archive can use in
the tablespace. The default is unlimited. Unless your space quota on the first tablespace is
unlimited, you must specify this value, or else an ORA-55621 will ensue.
• You need to provide the retention time (number of days that Flashback Data Archive data
for the table is guaranteed to be stored).
In the first example shown in the slide, a default Flashback Data Archive named fla1 is created
that uses up to 10 GB of the tbs1 tablespace, whose data will be retained for five years. In the
second example, the default Flashback Data Archive is specified. By default, the system has no
Flashback Data Archive. You can set it in one of two ways:
• Specify the name of an existing Flashback Data Archive in the SET DEFAULT clause of
the ALTER FLASHBACK ARCHIVE statement.
• Include DEFAULT in the CREATE FLASHBACK ARCHIVE statement when you create a
Flashback Data Archive.
In the third example, Flashback Data Archive is enabled. If Automatic Undo Management is
disabled, you receive an ORA-55614 if you try to modify the table.
Flashback Data Archive Scenario
Optionally, adding space:

ALTER FLASHBACK ARCHIVE fla1

ADD TABLESPACE tbs3 QUOTA 5G; 4
Optionally, changing retention time:

ALTER FLASHBACK ARCHIVE fla1 MODIFY RETENTION 2 YEAR; 5
Optionally, purging data:

ALTER FLASHBACK ARCHIVE fla1 PURGE BEFORE TIMESTAMP
6
ble
(SYSTIMESTAMP - INTERVAL '1' day);
fe r a
ans
Optionally, dropping a Flashback Data Archive: - t r
n no
DROP FLASHBACK ARCHIVE fla1;
s a 7
a
) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to (continued)
y u ki Scenario
s e
M as archiving
To enable flashback
l i c en for a table, include the FLASHBACK ARCHIVE clause in either
the CREATE
n l ey TABLE or ALTER TABLE statement. In the FLASHBACK ARCHIVE clause, you
canta
S specify the Flashback Data Archive where the historical data for the table will be stored. The
default is the default Flashback Data Archive for the system. To disable flashback archiving for
a table, specify NO FLASHBACK ARCHIVE in the ALTER TABLE statement.
The last statement shown in the previous slide shows how to retrieve the inventory of all items at
the beginning of the year 2007. Continuing the previous examples:
• Example 4 adds up to 5 GB of the tbs3 tablespace to the fla1 Flashback Data Archive.
• Example 5 changes the retention time for the fla1 Flashback Data Archive to two years.
• Example 6 purges all historical data older than one day from the fla1 Flashback Data
Archive. Normally, purging is done automatically, on the day after your retention time
expires. You can also override this for ad hoc clean-up.
• Example 7 drops the fla1 Flashback Data Archive and historical data, but not its
tablespaces. With the ALTER FLASHBACK ARCHIVE command, you can:
- Change the retention time of a Flashback Data Archive
- Purge some or all of its data
- Add, modify, and remove tablespaces
Note: Removing all tablespaces of a Flashback Data Archive causes an error.

Viewing Flashback Data Archives
Viewing the results:

View Name (DBA/USER) Description
*_FLASHBACK_ARCHIVE Displays information about Flashback

Data Archives
*_FLASHBACK_ARCHIVE_TS Displays tablespaces of Flashback Data

Archives
*_FLASHBACK_ARCHIVE_TABLES Displays information about tables that are

enabled for flashback archiving ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(Archives
Viewing Flashback Data k i e
You can use the a syu cdata
dynamic e nsdictionary views to view tracked tables and Flashback Data
M l i
n ey
Archivelmetadata. To access the USER_FLASHBACK_* views, you must have table ownership
Sta To inspect the DBA_FLASHBACK_* views, you need SYSDBA privileges.
privileges.

Flashback Data Archive DDL Restrictions
Using any of the following DDL statements on a table enabled

for Flashback Data Archive causes the error ORA-55610:

• ALTER TABLE statement that does any of the following:
– Drops, renames, or modifies a column
– Performs partition or subpartition operations
– Converts a LONG column to a LOB column
– Includes an UPGRADE TABLE clause, with or without an
INCLUDING DATA clause e
• DROP TABLE statement r a bl
s fe
• RENAME TABLE statement - t r an
nno
• TRUNCATE TABLE statement a
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Guidelines k
u nsei
syDBMS_FLASHBACK.ENABLE
• You can useathe c e and DBMS_FLASHBACK.DISABLE
M l i
n l ey to enable and disable the Flashback Data Archives.
procedures
S• taUse Flashback Query, Flashback Version Query, or Flashback Transaction Query for SQL
code that you write, for convenience.
• To obtain an SCN to use later with a flashback feature, you can use the
DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER function.
• To compute or retrieve a past time to use in a query, use a function return value as a time-
stamp or SCN argument. For example, add or subtract an INTERVAL value to the value of
the SYSTIMESTAMP function.
• To ensure database consistency, always perform a COMMIT or ROLLBACK operation before
querying past data.
• Remember that all flashback processing uses the current session settings, such as national
language and character set, not the settings that were in effect at the time being queried.
• To query past data at a precise time, use an SCN. If you use a time stamp, the actual time
queried might be up to 3 seconds earlier than the time you specify. Oracle Database uses
SCNs internally and maps them to time stamps at a granularity of 3 seconds.
• You cannot retrieve past data from a dynamic performance (V$) view. A query on such a
view always returns current data. However, you can perform queries on past data in static
data dictionary views, such as *_TABLES.
Summary

• Enable row movement on a table

• Perform Flashback Table operations
• Configure Flashback Database
• Perform Flashback Database operations
• Monitor Flashback Database
• Set up and use a Flashback Data Archive
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Working with Flashback Database
• Performing Flashback Database to undo unwanted

transactions
• Monitoring the Flashback Database retention
• Determining the size of the flashback logs
• Creating a Flashback Data Archive
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta
Diagnosing the Database
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Set up Automatic Diagnostic Repository

• Use and monitor Support Workbench
• Run health checks
• Identify the causes of database corruption:
– Hardware
– Software
• Detect and repair database corruption ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Automatic Diagnostic Workflow

Automatic
Critical Diagnostic
error Repository
DBA
Alert DBA
Auto-incident creation
1 2 Targeted health checks
First failure capture Assisted SR filling
No Known
ble
DBA bug?
fe r a
ans
- t
nYes r
EM Support
a no
Workbench:
EM Support Workbench: as
4
Package incident info
Apply patch/Datam ) h uideฺ DBA
repair
o
ilฺc ent G3
Data repair
a
@ gm Stud
u
Copyright
s
a use
i ( M to
Automatic Diagnostic
y u kWorkflow
s e
as licetracing
An always-on,Min-memory
n facility enables database components to capture diagnostic
l
data upon y failure for critical errors. A special repository, called Automatic Diagnostic
efirst
n
Sta
Repository, is automatically maintained to hold diagnostic information about critical error
events. This information can be used to create incident packages to be sent to Oracle Support
Services for investigation.
Here is a typical workflow for a diagnostic session:
1. Incident causes an alert to be raised in Enterprise Manager (EM).
2. The DBA can view the alert via the EM Alert page.
3. The DBA can drill down to incident and problem details.
4. The DBA or Oracle Support Services can decide or ask for that information to be packaged
and sent to Oracle Support Services via MetaLink. The DBA can add files to the data to be
packaged automatically.

Automatic Diagnostic Repository

DIAGNOSTIC_DEST
Support Workbench
$ORACLE_BASE BACKGROUND_DUMP_DEST
CORE_DUMP_DEST
USER_DUMP_DEST
$ORACLE_HOME/log
ADR
Base
diag
rdbms
DB
Name
ADR
SID metadata
ble
Home
fe r a
ans
alert cdump incpkg incident hm trace (others)
n - t r
a no
incdir_1 … incdir_n
h a s ฺ
ADRCI ) i d eV$DIAG_INFO
log.xml m
co nt Gu
i l ฺ alert_SID.log
g ma tude
sy se th
a
(M to u
Automatic Diagnostic k i
u nse (ADR)
Repository
s y
a licrepository
e
The ADR is aM file-based for database diagnostic data such as traces, incident dumps
y
le the alert log, Health Monitor reports, core dumps, and more. It has a unified
and packages,
t a n
directory structure across multiple instances and multiple products stored outside of any
S
database. It is, therefore, available for problem diagnosis when the database is down. Beginning
with Oracle Database 11g R1, the database, Automatic Storage Management (ASM), Cluster
Ready Services (CRS), and other Oracle products or components store all diagnostic data in the
ADR. Each instance of each product stores diagnostic data underneath its own ADR home
directory. For example, in a Real Application Clusters environment with shared storage and
ASM, each database instance and each ASM instance have a home directory within the ADR.
ADR’s unified directory structure, consistent diagnostic data formats across products and
instances, and a unified set of tools enable customers and Oracle Support to correlate and
analyze diagnostic data across multiple instances.
The ADR root directory is known as the ADR base. Its location is set by the
DIAGNOSTIC_DEST initialization parameter. If this parameter is omitted or left null, the
database sets DIAGNOSTIC_DEST upon startup as follows: If environment variable
ORACLE_BASE is set, DIAGNOSTIC_DEST is set to $ORACLE_BASE. If environment
variable ORACLE_BASE is not set, DIAGNOSTIC_DEST is set to $ORACLE_HOME/log.

The ADR Command-Line Tool, ADRCI
• ADRCI provides interaction with ADR from an operating

system prompt.
• Using ADRCI, you can view diagnostic data within the
Automatic Diagnostic Repository.
$ adrci
ADRCI: Release 11.1.0.5.0 - On Sat Jul 7 08:01:40 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ADR base = "/u01/app/oracle"
ble
ADRCI> show incident
fe r a
ADR Home = /u01/app/oracle/product/11.1.0/db_1/log/diag/rdbms/orcl/orcl:
ans
**************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME n - t r
no
----------- ------------------------------------ ------------------------
a
1681
a s
ORA-600_dbgris01:1,_addr=0xa9876541 17-JAN-07 09.17.44.843125…
1682
) h d eฺ
ORA-600_dbgris01:12,_addr=0xa9876542 18-JAN-07 09.18.59.434775…
i
2 incident info records fetched m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
ADRCI: The ADR Command-Line
u nse Tool
s y
a licetool that is part of the database fault diagnosability infrastructure.
ADRCI is a command-line
M
ADRCI n l ey you to:
enables
S• taView diagnostic data within the Automatic Diagnostic Repository (ADR)
• Package incident and problem information into a zip file for transmission to Oracle Support
ADRCI has a rich command set, and can be used in interactive mode or within scripts. In
addition, ADRCI can execute scripts of ADRCI commands in the same way that SQL*Plus
executes scripts of SQL and PL/SQL commands.
There is no need to log in to ADRCI, because the data in the ADR is not intended to be secure.
ADR data is secured only by operating system permissions on the ADR directories.
The easiest way to package and otherwise manage diagnostic data is with Support Workbench of
Oracle Enterprise Manager. ADRCI provides a command-line alternative to most of the
functionality of Support Workbench, and adds capabilities such as listing and querying trace
files. The example in the slide shows you an ADRCI session where you are listing all open
incidents stored in ADR.
Note: For more information about ADRCI, refer to the Oracle Database Utilities guide.

The V$DIAG_INFO View
SQL> SELECT * FROM V$DIAG_INFO;

NAME VALUE
------------------- -------------------------------------------------
Diag Enabled TRUE
ADR Base /u01/app/oracle
ADR Home /u01/app/oracle/diag/rdbms/orcl/orcl
Diag Trace /u01/app/oracle/diag/rdbms/orcl/orcl/trace
Diag Alert /u01/app/oracle/diag/rdbms/orcl/orcl/alert
Diag Incident /u01/app/oracle/diag/rdbms/orcl/orcl/incident
Diag Cdump /u01/app/oracle/diag/rdbms/orcl/orcl/cdump
Health Monitor /u01/app/oracle/diag/rdbms/orcl/orcl/hm
ble
Default Trace File /u01/app/oracle/diag/.../trace/orcl_ora_11424.trc
fe r a
Active Problem Count 3
ans
Active Incident Count 8
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
V$DIAG_INFO
a s yu ense
The V$DIAG_INFO
y M view lic lists all important ADR locations:
• ADR
a n leBase: Path of the ADR base
t
S• ADR Home: Path of the ADR home for the current database instance
• Diag Trace: Location of the text alert log and background/foreground process trace files
• Diag Alert: Location of an XML version of the alert log
• Diag Incident: Incident logs are written here.
• Diag Cdump: Diagnostic core files are written to this directory.
• Health Monitor: Location of logs from Health Monitor runs
• Default Trace File: Path to the trace file for your session. SQL trace files are written here.

Location for Diagnostic Traces
Diag Data Previous Location ADR Location

Foreground USER_DUMP_DEST ADR_HOME/trace

process traces
Background BACKGROUND_DUMP_DEST ADR_HOME/trace

process traces
Alert log data BACKGROUND_DUMP_DEST ADR_HOME/alert

ADR_HOME/trace
Core dumps CORE_DUMP_DEST ADR_HOME/cdump
ble
Incident dumps USER|BACKGROUND_DUMP_DEST ADR_HOME/incident/incdir_n fe r a
n s
n - tra
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Location for Diagnostic k i Traces
a s yu ense
The table in the
y lic the different classes of trace data and dumps that reside both in
Mslide compares
a le
OraclenDatabase 10g and Oracle Database 11g.
t
S Oracle Database 11g, there is no distinction between foreground and background traces
With
files. Both types of files go into the ADR_HOME/trace directory.
All nonincident traces are stored inside the trace subdirectory. This is the main difference
compared with previous releases where critical error information is dumped into the
corresponding process trace files instead of incident dumps. Incident dumps are placed in files
separated from the normal process trace files starting with Oracle Database 11g.
The main difference between a trace and a dump is that a trace is more of a continuous output
such as when SQL tracing is turned on, and a dump is a one-time output in response to an event
such as an incident. Also, a core is a binary memory dump that is port specific.
Note: In the slide, ADR_HOME represents the path
/u01/app/oracle/diag/rdbms/orcl/orcl, assuming an instance name of orcl.
However, there is no official environment variable called ADR_HOME.

Viewing the Alert Log Using Enterprise Manager

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing the Alert Log k i
u nsEnterprise
Using e Manager
s y
aalert llog ewith a text editor, with Enterprise Manager, or with the ADRCI
You can viewM the i c
l
utility.nToeyview the alert log with Enterprise Manager:
S1.taAccess the Database Home page in Enterprise Manager.
2. Under Related Links, click Alert Log Contents. The View Alert Log Contents page appears.
3. Select the number of entries to view, and then click Go.

EM Support Workbench: Overview
• Support Workbench guides you through the process of

handling problems.
• You can perform the following tasks with Support
Workbench:
– View details on problems and incidents
– Run heath checks
– Generate additional diagnostic data
– Run advisors to help resolve problems le
a b
– Create and track service requests through MetaLink
s fer
– Generate incident packages - t r an
– Close problems when resolved n on
a s
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
EM Support Workbench: k i
u Overview
a s y e n se
Support Workbench
y M is an licEnterprise Manager wizard that helps you through the process of
handling
a n lecritical errors. It displays incident notifications, presents incident details, and enables
yout
S to select incidents for further processing. Further processing includes running additional
health checks, invoking the incident packaging service (IPS) to package all diagnostic data about
the incidents, adding SQL test cases and selected user files to the package, filing a service
request (SR) with Oracle Support, shipping the packaged incident information to Oracle
Support, and tracking the SR through its life cycle.
You can perform the following tasks with Support Workbench:
• View details about problems and incidents.
• Manually run health checks to gather additional diagnostic data for a problem.
• Generate additional dumps and SQL test cases to add to the diagnostic data for a problem.
• Run advisors to help resolve problems.
• Create and track a service request through MetaLink, and add the service request number to
the problem data.
• Collect all diagnostic data relating to one or more problems into an incident package and
then upload the incident package to Oracle Support Services.
• Close the problem when the problem is resolved.

Support Workbench and

Oracle Configuration Manager
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Oracle Configuration k i
Manager
a s yu ense
Enterprise Manager
y M Support lic Workbench uses Oracle Configuration Manager to upload the
physical
a n lefiles generated by IPS to MetaLink. If Oracle Configuration Manager is not installed or
S t
properly configured, the upload may fail. In this case, a message is displayed with a path to the
incident package zip file and a request that you upload the file to Oracle Support manually. You
can upload manually with MetaLink.
During the database installation, the Oracle Universal Installer has a special Oracle
Configuration Manager Registration screen as shown in the slide. On that screen, you need to
select the Enable Oracle Configuration Manager check box and accept the license agreement
before you can enter your Customer Identification Number (CSI), your MetaLink account
username, and your country code.
If you do not configure Oracle Configuration Manager, you will still be able to manually upload
incident packages to MetaLink.
Note: For more information about Oracle Configuration Manager, see the “Oracle Configuration
Manager Installation and Administration Guide,” available at the following URL:
http://www.oracle.com/technology/documentation/oem.html

EM Support Workbench Roadmap
View critical
1 error alerts in
Enterprise Manager
7 Close incidents View problem

2
details
Gather additional
6 Track the SR and 3 diagnostic
implement repairs
information
ble
fe r a
ans
n - t r
Package and upload 4
Create a
a no
diagnostic data
a s
service request
to Oracle Support
) h i d eฺ
5 m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
EM Support Workbench k i
u Roadmap
a s y e n se
M in thelicslide is a summary of the tasks that you complete to investigate, report,
The graphic given
y
le cases, resolve a problem using Enterprise Manager Support Workbench:
and innsome
a
t
S1. Start by accessing the Database Home page in Enterprise Manager, and reviewing critical
error alerts. Select an alert for which to view details.
2. Examine the problem details and view a list of all incidents that were recorded for the
problem. Display findings from any health checks that were automatically run.
3. Optionally, run additional health checks and invoke the SQL Test Case Builder, which
gathers all required data related to a SQL problem and packages the information in a way
that enables the problem to be reproduced at Oracle Support.
4. Create a service request with MetaLink and optionally record the service request number
with the problem information.
5. Invoke a wizard that automatically packages all gathered diagnostic data for a problem and
uploads the data to Oracle Support. Optionally, edit the data to remove sensitive
information before uploading.
6. Optionally, maintain an activity log for the service request in Support Workbench. Run
Oracle advisors to help repair SQL failures or corrupted data.
7. Set the status for one, some, or all incidents for the problem to Closed.

Problems and Incidents
Problem ID
Critical
Problem
Error
Problem
Aut Key Incident Status
o ma
tica Collecting
Flood lly
control Automatic
Ready
Incident transition
Tracking
l ly Incident ID
nua Data-Purged
Ma
DBA Closed
Traces
ble
ADR
MMON Auto-purge
fe r a
ans
n - t r
Noncritical
a no
error
a s
Package to be
) h i d eฺ
sent to
Oracle Support m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Problems and Incidents k i
a s yu ense
To facilitate diagnosis
y M lic resolution of critical errors, the fault diagnosability infrastructure
and
introduces
a n le two concepts for Oracle Database—problems and incidents:
t
S• A problem is a critical error in the database. Problems are tracked in the ADR. Each
problem is identified by a unique problem ID and has a problem key, which is a set of
attributes that describe the problem. The problem key includes the ORA error number, error
parameter values, and other information. Here is a possible list of critical errors:
- All internal errors – ORA-60x errors
- All system access violations – (SEGV, SIGBUS)
- ORA-4020 (Deadlock on library object), ORA-8103 (Object no longer exists), ORA-
1410 (Invalid ROWID), ORA-1578 (Data block corrupted), ORA-29740 (Node
eviction), ORA-255 (Database is not mounted), ORA-376 (File cannot be read at this
time), ORA-4030 (Out of process memory), ORA-4031 (Unable to allocate more bytes
of shared memory), ORA-355 (The change numbers are out of order), ORA-356
(Inconsistent lengths in change description), ORA-353 (Log corruption), ORA-7445
(Operating System exception).
• An incident is a single occurrence of a problem. When a problem occurs multiple times, as
is often the case, an incident is created for each occurrence. Incidents are tracked in the
ADR. Each incident is identified by a numeric incident ID, which is unique within an ADR
home.
Problems and Incidents (continued)

When an incident occurs, the database makes an entry in the alert log, gathers diagnostic data
about the incident (a stack trace, the process state dump, and other dumps of important data
structures), tags the diagnostic data with the incident ID, and stores the data in an ADR
subdirectory created for that incident. Each incident has a problem key and is mapped to a single
problem. Two incidents are considered to have the same root cause if their problem keys match.
Large amounts of diagnostic information can be created very quickly if a large number of
sessions stumble across the same critical error. Having the diagnostic information for more than
a small number of the incidents is not required. That is why ADR provides flood control so that
only a certain number of incidents under the same problem can be dumped in a given time
interval. Note that flood controlled incidents still generate incidents; they only skip the dump
actions. By default only five dumps per hour for a given problem are allowed.
You can view a problem as a set of incidents that are perceived to have the same symptoms. The
main reason to introduce this concept is to make it easier for users to manage errors on their
systems. For example, a symptom that occurs 20 times should only be reported to Oracle once. e
Mostly, you will manage problems instead of incidents using IPS to package a problem torbe a bl
sent to Oracle Support. Most commonly incidents are automatically created when ancritical s fe error
occurred. However, you are also allowed to create an incident manually, vianthe - a provided
trGUI
by the EM Support Workbench. Manual incident creation is mostly donenwhen o you want to
a
s theฺ Oracle code.
report problems that are not accompanied by critical errors raisedainside
h
) in the i de A retention policy
As time goes by, more and more incidents will be accumulated m
o tG u ADR.
allows you to specify how long to keep the diagnostic a ilฺcdata.eADR
n incidents are controlled by two
different policies: m
g Stu d
• The incident metadata retentionu i @
k controls
policy is how long the metadata is kept around. This
s y t h
( M u se
policy has a default settingaof one year.
• The incident files and
u ki dumps e to
retention policy controls how long generated dump files are
y
s policy
kept around.aThis s
enhas a default setting of one month.
You can e M
change l i c
y these setting using the Incident Package Configuration link on the EM Support
n l
S ta
Workbench page. Inside the RDBMS component, MMON is responsible for purging
automatically expired ADR data.
The Status of an incident reflects the state of the incident. If an incident has been in either the
Collection or the Ready state for over twice its retention length, the incident automatically
moves to the Closed state. You can manually purged incident files.
For simplicity, problem metadata is internally maintained by ADR. Problems are automatically
created when the first incident (of the problem key) occurs. The Problem metadata is removed.

Viewing Critical Error Alerts in

Enterprise Manager
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing Critical Error k i
u nsin
Alerts e Enterprise Manager
s y
a oflicinvestigating
e
You begin theMprocess problems (critical errors) by reviewing critical error alerts
le y
on thenDatabase Home page. To view critical error alerts, access the Database Home page in
t a
Enterprise
S Manager. From the Home page, you can look at the Diagnostic Summary section
where you can click the Active Incidents link if there are incidents. You can also use the Alerts
section and look for critical alerts flagged as Incidents.
When you click the Active Incidents link, you end up on the Support Workbench page from
where you can retrieve details about all problems and corresponding incidents. From there, you
can also retrieve all Health Monitor checker run and created packages.
Note: The tasks described in this section are all Enterprise Manager based. You can also
accomplish all of these tasks with the ADRCI command-line utility and PL/SQL package
procedures. See Oracle Database Utilities for more information about the ADRCI utility.

Viewing Problem Details

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing Problem Details k i
a s yu ense
On the Problems
y M subpagelicon the Support Workbench page, click the ID of the problem you want
t a nle This takes you to the corresponding Problem Details page.
to investigate.
S this page, you can see all incidents that are related to your problem. You can associate your
On
problem with a MetaLink service request and bug number. In the Investigate and Resolve
section of the page, you have a Self Service subpage that has direct links to the operation you
can perform on this problem. In the same section, the Oracle Support subpage has direct links to
MetaLink.
The Activity Log subpage shows you the system-generated operations that have occurred on
your problem so far. This subpage allows you to add your own comments while investigating
your problem.
On the Incidents subpage, you can click a related incident ID to access the corresponding
Incident Details page.

Viewing Incident Details

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing Incident Details k i
a s yu ense
On the Incident
y ic the Dump Files subpage appears and lists all corresponding dump
MDetailslpage,
files. You
a n lecan then click the eyeglasses icon for a particular dump file to visualize the file
t
content
S with its various sections.

Viewing Incident Details

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing Incident Details k i
u (continued)
a s y e n se
On the Incident
y ic click Checker Findings to view the Checker Findings subpage.
MDetailslpage,
This page
a n ledisplays findings from any health checks that were automatically run when the critical
t
error
S was detected. Most of the time, you have the possibility to select one or more findings, and
invoke an advisor to fix the issue.

Creating a Service Request

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Creating a Service Requestk i
a s yu ense
Before you can
y Mpackagelicand upload diagnostic information for the problem to Oracle Support,
you must
a n lecreate a service request. To create a service request, you need to go to MetaLink first.
S t
MetaLink can be accessed directly from the Problem Details page when you click the “Go to
Metalink” button in the Investigate and Resolve section of the page. On MetaLink, log in and
create a service request in the usual manner.
When done, you can enter that service request for your problem. This is entirely optional and is
for your reference only.
In the Summary section, click the Edit button that is adjacent to the SR# label, and in the
window that opens, enter the SR#, and then click OK.

Packaging and Uploading Diagnostic Data to

Oracle Support
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Packaging and Uploadingk i
u nDiagnostic
e Data to Oracle Support
s y
a provides s
e two methods for creating and uploading an incident package: the
Support Workbench
M l i c
l ey method and the Advanced Packaging method. The example in the slide shows
QuicknPackaging
Stahow to use Quick Packaging.
you
Quick Packaging is a more automated method with a minimum of steps. You select a single
problem, provide an incident package name and description, and then schedule the incident
package upload, either immediately or at a specified date and time. Support Workbench
automatically places diagnostic data related to the problem into the incident package, finalizes
the incident package, creates the zip file, and then uploads the file. With this method, you do not
have the opportunity to add, edit, or remove incident package files or add other diagnostic data
such as SQL test cases. To package and upload diagnostic data to Oracle Support:
1. On the Problem Details page, in the Investigate and Resolve section, click Quick Package.
The Create New Package page of the Quick Packaging wizard appears.
2. Enter a package name and description.
3. Enter the service request number to identify your problem.
4. Click Next, and then proceed with the remaining pages of the Quick Packaging wizard.
Click Submit on the Review page to upload the package.

Tracking the SR
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Tracking the SR k i
a s yu ense
After uploading
y lic information to Oracle Support, you might perform various activities
M diagnostic
to track e service request and implement repairs. Among these activities are the following:
nlthe
t a
S an Oracle bug number to the problem information. To do so, on the Problem Details page,
Add
click the Edit button that is adjacent to the Bug# label. This is for your reference only.
Add comments to the problem activity log. To do so, complete the following steps:
1. Access the Problem Details page for the problem.
2. Click Activity Log to display the Activity Log subpage.
3. In the Comment field, enter a comment, and then click Add Comment. Your comment is
recorded in the activity log.
Respond to a request by Oracle Support to provide additional diagnostics. Your Oracle Support
representative might provide instructions for gathering and uploading additional diagnostics.

Implementing Repairs
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Implementing Repairs k i
a s yu ense
On the Incident
y ic you can run an Oracle advisor to implement repairs. Access the
MDetailslpage,
suggested
a n leadvisor in one of the following ways:
t
S• In the Self-Service tab of the Investigate and Resolve section of the Problem Details page
• On the Checker Findings subpage of the Incident Details page as shown in the slide
The advisors that help you repair critical errors are:
• Data Recovery Advisor: Corrupted blocks, corrupted or missing files, and other data
failures
• SQL Repair Advisor: SQL statement failures

Closing Incidents and Problems

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Closing Incidents and k i
Problems
a s yu ense
When a particular
y lic is no longer of interest, you can close it. By default, closed incidents
M incident
a le
are notndisplayed on the Problem Details page. All incidents, whether closed or not, are purged
t
after
S 30 days. You can disable purging for an incident on the Incident Details page.
To close incidents:
1. Access the Support Workbench home page.
2. Select the desired problem, and then click View. The Problem Details page appears.
3. Select the incidents to close and then click Close. A confirmation page appears.
4. Click Yes on the Confirmation page to close your incident.

Incident Packaging Configuration

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
Incident Packaging Configuration
a s yu ense
M you canlicconfigure various aspects of retention rules and packaging generation.
As already seen,
y
Usingn
a le Workbench, you can access the Incident Packaging Configuration page from the
Support
t
Related
S Links section of the Support Workbench page by clicking the Incident Package
Configuration link. Here are the parameters you can change:
• Incident Metadata Retention Period: Metadata is basically information about the data.
For incidents, the metadata includes the incident time, ID, size, problem, and so forth. Data
is the actual contents of an incident, such as traces.
• Cutoff Age for Incident Inclusion: This value includes incidents for packaging that are in
the range to now. If the cutoff date is 90, for instance, the system includes only the incidents
that are within the last 90 days.
• Leading Incidents Count: For every problem included in a package, the system selects a
certain number of incidents from the problem from the beginning and the end. For example,
if the problem has 30 incidents, and the leading incident count is 5 and the trailing incident
count is 4, the system includes the first five incidents and the last four incidents.
• Trailing Incidents Count: See above.
• Correlation Time Proximity: This parameter is the exact time interval that defines
“happened at the same time.” One criterion for correlation is time correlation: find the
incidents that happened at the same time as the incidents in a problem.
• Time Window: Number of hours in the time window for including incidents in a package
Custom Packaging: Creating a New Package

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Custom Packaging: u k
Creating
o uPackage
i (M ea tNew
a sisya more
e n s
Custom Packaging
y M lic manual method than Quick Packaging, but gives you greater
le the incident package contents. You can create a new incident package with one or
controlnover
a
t
more
S problems, or you can add one or more problems to an existing incident package. You can
then perform a variety of operations on the new or updated incident package, including:
• Adding or removing problems or incidents
• Adding, editing, or removing trace files in the incident package
• Adding or removing external files of any type
• Adding other diagnostic data such as SQL test cases
• Manually finalizing the incident package and then viewing package contents to determine
whether you must edit or remove sensitive data or remove files to reduce incident package
size.
With the Custom Packaging method, you create the zip file and request upload to Oracle Support
as two separate steps. To package and upload a problem with Custom Packaging:
1. In the Problems subpage at the bottom of the Support Workbench home page, select the
first problem that you want to package, and then click Package.
2. Next, select the Custom Packaging option, and click Continue.
3. The Custom Packaging: Select Package page appears. To create a new incident package,
select the Create New Package option, enter an incident package name and description, and
then click OK.
Custom Packaging: Manipulating an Incident

Package
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Custom Packaging: u k i (M e to an
Manipulating Incident Package
s y
a Package, n s
eyou get the confirmation that your new package has been created.
On the Customize
y M l i c
n
This pagel edisplays the incidents that are contained in the incident package, plus a selection of
S t a
packaging tasks to choose from. You run these tasks against the new incident package or the
updated existing incident package.
As you can see from the slide, you can exclude/include incidents or files as well as many other
possible tasks.

Custom Packaging: Finalizing an

Incident Package
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Custom Packaging: u k i (M e an
Finalizing to Incident Package
s y
a package n s
e is used to add correlated files from other components, such as
Finalizing an M
incident l i c
l ey to the package. Recent trace files and log files are also included in the package.
HealthnMonitor,
Stacan finalize a package by clicking the Finish Contents Preparation link in the Packaging
You
Tasks section as shown in the slide. A confirmation page is displayed that lists all files that will
be part of the physical package.

Custom Packaging: Generating a Package

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Custom Packaging: u k
Generate
ou
i (M eatPackage
a y ens
spackage
After your incident
y M lic has been finalized, you can generate the package file. You need to
go back
t a nltoe the corresponding package page and click Generate Upload File.
S Generate Upload File page appears. There, select the Full or Incremental option to generate
The
a full incident package zip file or an incremental incident package zip file.
For a full incident package zip file, all the contents of the incident package (original contents
and all correlated data) are always added to the zip file.
For an incremental incident package zip file, only the diagnostic information that is new or
modified since the last time that you created a zip file for the same incident package is added to
the zip file.
When done, select the Schedule and click Submit. If you scheduled the generation immediately,
a Processing page appears until packaging is finished. This is followed by the Confirmation page
where you can click OK.
Note: The Incremental option is unavailable if a physical file was never created for the incident
package.

Custom Packaging: Uploading a Package

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Custom Packaging: u k i (M e taoPackage
Uploading
a y ens
sthe
After you generate
y M lic package, you can go back to the Customize Package page from
physical
le can click the View/Send Uploaded Files link in the Packaging Tasks section.
wherenyou
a
t
S takes you to the View/Send Upload Files page from where you can select your package,
This
and click the “Send to Oracle” button.
The “Send to Oracle” page appears. Here, you can enter the service request number for your
problem, and choose a Schedule. You can then click Submit.

Viewing and Modifying Incident Packages

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Viewing and Modifying k i
u nse Packages
Incident
s y
ais created, eyou always have the possibility to modify it through customization.
After a package
M l i c
n l ey go to the Support Workbench page and click the Packages tab. This takes you to
For example,
the
a
StPackages subpage. On this page, you can select a package and delete it, or click the package
link to go to the Package Details page. There, you can click Customize to go to the Customize
Package page from where you can manipulate your package by adding/removing problem,
incidents, or files.

Health Monitor: Overview

Critical
error ADRCI
V$HM_RUN
DBMS_HM EM
Re hm
ac
ti v (reports)
e
ADR
Health
al HM Monitor
a nu S_
M M
DB
or V$HM_CHECK
EM
DBA Logical Block Check Undo Segment Check
ble
Table Row Check Data Block Check
fe r a
Transaction Check
ans
Table Check
Redo Check - t r
Database Cross Check
n
a no
Table-Index Row Mismatch
a s
) i d eฺ
Database Dictionary Check
h
m
co nt Gu
Table-Index Cross Check
i l ฺ
g ma tude
sy se th
a
(M to u
Health Monitor: Overview k i
a s yu ense
The Oracle database
y lic a framework called Health Monitor for running diagnostic checks
M includes
on various
a n le components of the database. Health Monitor checks examine various components of
the t
S database, including files, memory, transaction integrity, metadata, and process usage. These
checks generate reports of their findings as well as recommendations for resolving problems.
The fault diagnosability infrastructure can run Health Monitor checks automatically in response
to critical errors or the DBA, can manually run Health Monitor health checks using either the
DBMS_HM PL/SQL package or the Enterprise Manager interface.
For a complete description of all possible checks that Health Monitor can run, look at
V$HM_CHECK. These health checks fall into one of two categories:
• DB-online: These checks can be run while the database is open (that is, in OPEN mode).
• DB-offline: In addition to being “runnable” while the database is open, these checks can
also be run when the instance is available and the database itself is closed (NOMOUNT
mode).
After a checker has run, it generates a report containing information about the checker’s
findings, including the priorities (low, high, or critical), descriptions of the findings and their
consequences, and basic statistics about the execution. Health Monitor generates reports in XML
and stores the reports in ADR. You can view these reports using either V$HM_RUN, DBMS_HM,
ADRCI, or Enterprise Manager.

Running Health Checks Manually: EM Example

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to uEM Example
Running Health Checks k i Manually:
a s yu ense
Enterprise Manager
y lic an interface for running Health Monitor checkers. You can find
M provides
a n le in the Checkers tab on the Advisor Central page. The page lists each checker type,
this interface
andt
S you can run a checker by clicking it and then OK on the corresponding checker page after
you entered the parameters for the run. This is illustrated in the slide, where you run the Data
Block Checker manually.
After a check is completed, you can view the corresponding checker run details by selecting the
checker run from the Results table and click Details. Checker runs can be reactive or manual.
On the Findings subpage, you can see the various findings and corresponding recommendations
extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION.
If you click View XML Report on the Runs subpage, you can view the run report in XML
format. Viewing the XML report in Enterprise Manager generates the report for the first time if
it is not yet generated in your ADR. You can then view the report using ADRCI without needing
to generate it.

Running Health Checks Manually:

PL/SQL Example
SQL> exec dbms_hm.run_check('Database Dictionary Check',
'mycheck',0,'TABLE_NAME=tab$');
SQL> set long 100000

SQL> select dbms_hm.get_run_report('mycheck') from dual;
DBMS_HM.GET_RUN_REPORT('mycheck')
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="US-ASCII"?>
<HM-REPORT REPORT_ID="mycheck"><TITLE>HM Report: mycheck</TITLE>
<RUN_INFO>
<CHECK_NAME>Database Dictionary Check</CHECK_NAME>
<RUN_ID>21</RUN_ID><RUN_NAME>mycheck</RUN_NAME>
<RUN_MODE>MANUAL</RUN_MODE><RUN_STATUS>COMPLETED</RUN_STATUS> …
ble
</RUN_INFO>
fe r a
<RUN_PARAMETERS><RUN_PARAMETER>TABLE_NAME=tab$</RUN_PARAMETER> … </RUN_PARAMETERS>
ans
<RUN-FINDINGS><FINDING>
n - t r
<FINDING_NAME>Dictionary Inconsistency</FINDING_NAME><FINDING_ID>22</FINDING_ID>
<FINDING_TYPE>FAILURE</FINDING_TYPE><FINDING_STATUS>OPEN</FINDING_STATUS>
a no
<FINDING_PRIORITY>CRITICAL</FINDING_PRIORITY> …
a s
<FINDING_CREATION_TIME>…</FINDING_CREATION_TIME>
) h i d eฺ
m
co nt Gu
<FINDING_MESSAGE>…invalid column number 7 on Object tab$ Failed</FINDING_MESSAGE>
l ฺ
<FINDING_MESSAGE>Damaged … Object SH.JFVTEST is referenced </FINDING_MESSAGE> …
i
g ma tude
sy se th
a
(M to u
Running Health Checks k i
u nse PL/SQL Example
Manually:
s y
aDBMS_HM.RUN_CHECK
e
You can use the
y M l i c procedure for running a health check. To call
RUN_CHECK,
a n le supply the name of the check found in V$HM_CHECK, the name for the run (this
t
isSjust a label used to retrieve reports later), and the corresponding set of input parameters for
controlling its execution. You can view these parameters using the V$HM_CHECK_PARAM.
In the slide example, you want to run a Database Dictionary Check for TAB$ table, considered
an important core dictionary object. You call this run MYCHECK, and you do not want to set any
timeout for this check.
When executed, you execute the DBMS_HM.GET_RUN_REPORT function to get the report
extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION. The output
clearly shows you that a critical error was found in TAB$. This table contains an entry for a table
with an invalid number of columns. Furthermore, the report gives you the name of the damaged
table in TAB$.
When you call the GET_RUN_REPORT function, it generates the XML report file in the HM
directory of your ADR. In the example, the file is called HMREPORT_mycheck.hm.
Note: Refer to the Oracle Database PL/SQL Packages and Types Reference for more
information about DBMS_HM.

Viewing HM Reports Using the ADRCI Utility
adrci>>show hm_run
…
----------------------------------------------------------
RUN_ID 11081
RUN_NAME HM_RUN_11081
CHECK_NAME Database Cross Check
NAME_ID 2
MODE 2
START_TIME 2007-04-13 03:20:31.161396 -07:00
RESUME_TIME
END_TIME 2007-04-13 03:20:37.903984 -07:00
MODIFIED_TIME 2007-04-17 01:16:37.106344 -07:00
TIMEOUT 0
FLAGS 0
STATUS 5
ble
SRC_INCIDENT_ID 0
fe r a
NUM_INCIDENTS 0
ans
ERR_NUMBER
REPORT_FILE
0
n - t r
…
a no
adrci>>create report hm_run HM_RUN_11081
a s
Adrci>>show report hm_run HM_RUN_11081
) h i d eฺ
…
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
Viewing HM ReportsuUsing k i (Mthee t o
ADRCI Utility
s y n s
a viewlicHealth
e Monitor checker reports using the ADRCI utility. To do that,
You can create
M and
l eyoperating system environment variables such as ORACLE_HOME are set properly,
ensure that
n
Stathen enter the following command at the operating system command prompt: adrci.
and
The utility starts and displays its prompt as shown in the slide. Optionally, you can change the
current ADR home. Use the SHOW HOMES command to list all ADR homes, and the SET
HOMEPATH command to change the current ADR home.
You can then enter the SHOW HM_RUN command to list all the checker runs registered in the
ADR repository and visible from V$HM_RUN. Locate the checker run for which you want to
create a report and note the checker run name using the corresponding RUN_NAME field. The
REPORT_FILE field contains a file name if a report already exists for this checker run.
Otherwise, you can generate the report using the CREATE REPORT HM_RUN command as
shown in the slide. To view the report, use the SHOW REPORT HM_RUN command.

SQL Repair Advisor Overview
SQL Generate
statement Execute Statement incident in ADR
crashes
automatically
Trace files
DBA run DBA gets

SQL Repair Advisor
SQL Repair Advisor alerted

DBA
investigates
DBA accept Statement

executes
SQL patch successfullybl e
fe
againr a
Execute
ans
n - t r
a no
a s
SQL patch
SQL statement )
h i d eฺ
generated
patched
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
k
SQL Repair AdvisoruOverview i (M e to u
You run the SQL a sy cAdvisor
Repair e ns after a SQL statement fails with a critical error that generates a
M
yADR. li
problemn l e
in The advisor analyzes the statement and in many cases recommends a patch to
t a
repair
S the statement. If you implement the recommendation, the applied SQL patch circumvents
the failure by causing the query optimizer to choose an alternate execution plan for future
executions. This is done without changing the SQL statement itself.
Note: In case no workaround is found by the SQL Repair Advisor, you are still able to package
the incident files and send the corresponding diagnostic data to Oracle Support.

Using SQL Repair Advisor from PL/SQL
declare
rep_out clob;
t_id varchar2(50);
begin
t_id := dbms_sqldiag.create_diagnosis_task(
sql_text => 'delete from t t1 where t1.a = ''a'' and rowid <> (select max(rowid)
from t t2 where t1.a= t2.a and t1.b = t2.b and t1.d=t2.d)',
task_name => 'sqldiag_bug_5869490',
problem_type => DBMS_SQLDIAG.PROBLEM_TYPE_COMPILATION_ERROR);
dbms_sqltune.set_tuning_task_parameter(t_id,'_SQLDIAG_FINDING_MODE',
dbms_sqldiag.SQLDIAG_FINDINGS_FILTER_PLANS);
dbms_sqldiag.execute_diagnosis_task (t_id);
rep_out := dbms_sqldiag.report_diagnosis_task (t_id, DBMS_SQLDIAG.TYPE_TEXT);
ble
dbms_output.put_line ('Report : ' || rep_out);
fe r a
end;
/
ans
n - t r
execute dbms_sqldiag.accept_sql_patch(task_name => 'sqldiag_bug_5869490', a no
a s
) h
task_owner => 'SCOTT', replace => TRUE);
i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using SQL Repair Advisor k i
u nfrom e PL/SQL Example
s y
a about s
ean incident SQL failure, you can execute a SQL Repair Advisor task
After you getM
y
alerted l i c
using ntheleDBMS_SQLDIAG.CREATE_DIGNOSIS_TASK function like illustrated on the slide.
Yout a
S need to specify the SQL statement for which you want the analysis to be done, as well as a
task name and a problem type you want to analyze (possible values are
PROBLEM_TYPE_COMPILATION_ERROR, and
PROBLEM_TYPE_EXECUTION_ERROR).
You can then give the created task parameters using the
DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER procedure.
Once you are ready, you can then execute the task using the
DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASK procedure.
Finally, you can get the task report using the DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASK
function.
In the above example, it is assumed that the report asks you to implement a SQL Patch to fix the
problem. You can then use the DBMS_SQLDIAG.ACCEPT_SQL_PATCH procedure to
implement the SQL Patch.

What Is Block Corruption?
• Whenever a block is read or written, a consistency check is

performed.
– Block version
– DBA (data block address) value in cache as compared to the
DBA value in the block buffer
– Block-checksum, if enabled
• A corrupt block is identified as being one of the following:
– Media corrupt e
– Logically (or software) corrupt r a bl
s fe
- t r an
n
no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
What Is Block Corruption? k i
a s yu ense
M block lisica block that is not in a recognized Oracle format, or whose contents
A corrupted data
y
a le
are notninternally consistent. Typically, corruptions are caused by faulty hardware or operating
t
system
S problems. The Oracle database identifies corrupt blocks as either “logically corrupt” or
“media corrupt.” If it is logically corrupt, then there is an Oracle internal error. Logically corrupt
blocks are marked corrupt by the Oracle database after it detects the inconsistency. If it is media
corrupt, then the block format is not correct; the information in the block does not make any
sense after being read from disk.
You can repair a media corrupt block by recovering the block or dropping the database object
that contains the corrupt block, or both. If media corruption is due to faulty hardware, the
problem will not be completely resolved until the hardware fault is corrected.

Block Corruption Symptoms: ORA-01578
The error ORA-01578: "ORACLE data block corrupted

(file # %s, block # %s)":

• Is generated when a corrupted data block is found
• Always returns the relative file number and block number
• Is returned to the session that issued the query being
performed when the corruption was discovered
• Appears in the alert.log file
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M ORA-01578 u
k
Block Corruption Symptoms: i t o
a s yu ense
Usually, the ORA-01578
y M lic error is the result of a hardware problem. If the ORA-01578 error is
a le
alwaysnreturned with the same arguments, it is most likely a media corrupt block.
t
IfSthe arguments change each time, there may be a hardware problem, and you should have the
memory and page space checked, and the I/O subsystem checked for bad controllers.
Note: ORA-01578 returns the relative file number, but the accompanying ORA-01110 error
displays the absolute file number.

How to Handle Corruption
• Check the alert log and operating system log file.

• Use available diagnostic tools to find out the type of

corruption.
• Determine whether the error persists by running checks
multiple times.
• Recover data from the corrupted object if necessary.
• Resolve any hardware issues:
– Memory boards ble
fe r a
– Disk controllers s
– Disks - t r an
n n o
• Recover or restore data from the corrupt object s a
if necessary. ) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
How to Handle Corruption k i
a s yu ense
Always try toM
y lic the error is permanent. Run the ANALYZE command multiple
find out whether
times nor,leif possible, perform a shutdown and a startup and try again to perform the operation
t
that a
S failed earlier. Find out whether there are more corruptions. If you encounter one, there may
be other corrupted blocks, as well.
Hardware failures should be addressed immediately. When you encounter hardware problems,
the vendor should be contacted and the machine should be checked and fixed before continuing.
A full hardware diagnostics session should be run.
Many types of hardware failures are possible:
• Faulty I/O hardware or firmware
• Operating system I/O or caching problem
• Memory or paging problems
• Disk repair utilities

Verifying Block Integrity in Real Time:

DB_BLOCK_CHECKING
The DB_BLOCK_CHECKING initialization parameter:
• Controls the degree of self-consistency checks performed on

each block as it is processed
• Can prevent memory and data corruption
• Can be set by using the ALTER SESSION or ALTER
SYSTEM DEFERRED command
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a u
(inMRealtoTime:
Verifying Block Integrityk i
u nse DB_BLOCK_CHECKING
s y
a licblock e checking by setting the DB_BLOCK_CHECKING initialization
You can enable M database
l
parameter
n eyto TRUE. This checks data and index blocks for internal consistency whenever they
are a
Stmodified. DB_BLOCK_CHECKING is a dynamic parameter, modifiable by the ALTER
SYSTEM SET statement. Block checking is always enabled for the system tablespace. Block
checking typically causes 1% to 10% overhead, depending on workload. The more updates or
inserts being executed, the more expensive it is to turn on block checking. The four possible
values for DB_BLOCK_CHECKING are:
• OFF: No block checking is performed in any tablespaces except for SYSTEM.
• LOW: Basic block header checks are performed after block contents change in memory (for
example, after UPDATE or INSERT statements and on-disk reads).
• MEDIUM: All LOW checks are performed. Semantic block checking for all non-index-
organized table blocks is performed.
• FULL: All LOW and MEDIUM checks. Semantic checks on index blocks are performed.
You should set DB_BLOCK_CHECKING to FULL if the performance overhead is acceptable.
The default value is FALSE, which, for backward compatibility, is equivalent to OFF. Even if
this is turned off, block checking for the SYSTEM tablespace is always turned on.

Block Media Recovery
Block media recovery:

• Lowers the mean time to recover (MTTR)

• Increases availability during media recovery
– The data file remains online during recovery
– Only blocks being recovered are inaccessible
• Is invoked using the RMAN RECOVER...BLOCK command
– Restores blocks using flashback logs and full or level 0
backups ble
fe r a
– Media recovery is performed using redo logs s
• The V$DATABASE_BLOCK_CORRUPTION - t r an
n no
view displays blocks marked corrupt a
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Block Media Recovery k i
a s yu ense
In most cases,M
y lic marks a block as media corrupt and then writes it to disk when the
the database
a n le is first encountered. No subsequent read of the block will be successful until the
corruption
t
block
S is recovered. You can only perform block recovery on blocks that are marked corrupt or
fail a corruption check. Block media recovery is performed using the RMAN
RECOVER...BLOCK command. By default, RMAN searches the flashback logs for good
copies of the blocks, and then searches for the blocks in full or level 0 incremental backups.
When RMAN finds good copies, it restores them and performs media recovery on the blocks.
Block media recovery can only use redo logs for media recovery, not incremental backups.
The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by database
components such as RMAN commands, ANALYZE, dbv, SQL queries, and so on. The
following types of corruption result in rows added to this view:
• Physical/Media corruption: The database does not recognize the block: the checksum is
invalid, the block contains all zeros, or the block header is fractured. Physical corruption
checking is enabled by default.
• Logical corruption: The block has a valid checksum, the header and footer match, but the
contents are inconsistent. Block media recovery cannot repair logical block corruption.
Logical corruption checking is disabled by default. You can turn it on by specifying the
CHECK LOGICAL option of the BACKUP, RESTORE, RECOVER, and VALIDATE commands.

Prerequisites for Block Media Recovery
• The target database must be in ARCHIVELOG mode.

• The backups of the data files containing the corrupt blocks

must be full or level 0 backups.
– Proxy copies must be restored to a non-default location
before they can be used.
• RMAN can use only archived redo logs for the recovery.
• The corrupted data block can be restored from Flashback
Logs if available. e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Prerequisites for Block k i
u nseRecovery
Media
s y
a liceapply to the RECOVER ... BLOCK command:
The followingM prerequisites
• The l y database must run in ARCHIVELOG mode and be open or mounted with a
etarget
n
Stacurrent control file.
• The backups of the data files containing the corrupt blocks must be full or level 0 backups
and not proxy copies. If only proxy copy backups exist, then you can restore them to a non-
default location on disk, in which case RMAN considers them data file copies and searches
them for blocks during block media recovery.
• RMAN can use only archived redo logs for the recovery. RMAN cannot use level 1
incremental backups. Block media recovery cannot survive a missing or inaccessible
archived redo log, although it can sometimes survive missing redo records.
• Flashback Database must be enabled on the target database for RMAN to search the
flashback logs for good copies of corrupt blocks. If flashback logging is enabled and
contains older, uncorrupted versions of the corrupt blocks, then RMAN can use these
blocks, possibly speeding up the recovery.

The RECOVER...BLOCK Command
The RMAN RECOVER...BLOCK command:

• Identifies the backups containing the blocks to recover

• Reads the backups and accumulates requested blocks into
in-memory buffers
• Manages the block media recovery session by reading the
archive logs from backup if necessary
RECOVER DATAFILE 6 BLOCK 3; Recover a single block
ble
RECOVER Recover multiple blocks
fe r a
DATAFILE 2 BLOCK 43 in multiple data files ans
DATAFILE 2 BLOCK 79
o n -tr
DATAFILE 6 BLOCK 183;
s an
Recover m ) hablocks
i d eฺlogged in
co nt Gu
RECOVER CORRUPTION LIST; all
i l ฺ
V$DATABASE_BLOCK_CORRUPTION
g ma tude
sy se th
a
(M to u
Recovering Individual k i
Blocks
a s yu ense
Before block M
y lic take place, you must identify the corrupt blocks. Typically, block
recovery can
a n le is reported in the following locations:

corruption
t
S• Results of the LIST FAILURE, VALIDATE, or BACKUP ... VALIDATE command
• The V$DATABASE_BLOCK_CORRUPTION view
• Error messages in standard output
• The alert log and user trace files (identified in the V$DIAG_INFO view)
• Results of the SQL ANALYZE TABLE and ANALYZE INDEX commands
• Results of the DBVERIFY utility
For example, you may discover the following messages in a user trace file:
ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/orcl/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/orcl/undotbs01.dbf'
One the blocks have been identified, run the RECOVER ... BLOCK command at the RMAN
prompt, specifying the file and block numbers for the corrupted blocks.
RECOVER
DATAFILE 7 BLOCK 3
DATAFILE 2 BLOCK 235;

Data Recovery Advisor
• Fast detection, analysis, and repair of failures

• Minimizing down-time and run-time failures

• Minimizing disruptions for users
• User interfaces:
– EM GUI interface
(several paths)
– RMAN command-line
• Supported database configurations: ble
fe r a
– Single instance
t r a ns
– Not RAC o n -
a nand repair of
– Supporting failover to standby, but not analysis
s
standby databases ) ha ideฺ
m co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
Functionality of the u k
Data i (Recovery
e Advisor
s y
a Advisor n s
e automatically gathers data failure information when an error is
The Data Recovery
M l i c
l ey In addition, it can proactively check for failures. In this mode, it can potentially
encountered.
n
Sta and analyze data failures before a database process discovers the corruption and signals an
detect
error. (Note that repairs are always under human control.)
Data failures can be very serious. For example, if your current log files are missing, you cannot
start your database. Some data failures (like block corruptions in data files) are not catastrophic,
in that they do not take the database down or prevent you from starting the Oracle instance. The
Data Recovery Advisor handles both cases: the one when you cannot start up the database
(because some required database files are missing, inconsistent, or corrupted) and the one when
file corruptions are discovered during run time.

Data Recovery Advisor:

RMAN Command-Line Interface
RMAN Command Action

LIST FAILURE Lists previously executed failure assessment
ADVISE FAILURE Displays recommended repair option
REPAIR FAILURE Repairs and closes failures (after ADVISE in the same
RMAN session)
CHANGE FAILURE Changes or closes one or more failures bl e

fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Data Recovery Advisor: k i
u nse Command-Line Interface
RMAN
s y
If you suspectM oraknow lthat
i c ea database failure has occurred, then use the LIST FAILURE
commandn l etoy obtain information about these failures. You can list all or a subset of failures and
Sta output in various ways. Failures are uniquely identified by failure numbers. Note that
restrict
these numbers are not consecutive, so gaps between failure numbers have no significance.
The ADVISE FAILURE command displays a recommended repair option for the specified
failures. It prints a summary of the input failure and implicitly closes all open failures that are
already fixed. The default behavior when no option is used is to advise on all the CRITICAL
and HIGH priority failures that are recorded in the ADR.
The REPAIR FAILURE command is used after an ADVISE FAILURE command within the
same RMAN session. By default, the command uses the single, recommended repair option of
the last ADVISE FAILURE execution in the current session. If none exists, the REPAIR
FAILURE command initiates an implicit ADVISE FAILURE command. After completing the
repair, the command closes the failure.
The CHANGE FAILURE command changes failure priority or closes one or more failures. You
can only change a failure priority of HIGH or LOW priorities. Open failures are closed implicitly
when a failure is repaired. However, you can also explicitly close a failure.

Listing of Data Failures
The RMAN LIST FAILURE command lists previously

executed failure assessment.
• Including newly diagnosed failures

• Removing closed failures (by default)
LIST FAILURE
[ ALL | CRITICAL | HIGH | LOW | CLOSED |
failnum[,failnum,…] ]
[ EXCLUDE FAILURE failnum[,failnum,…] ][ DETAIL ]
bl e
RMAN> LIST FAILURE;
fe r a
ans
List of Database Failures
========================= n - t r
a no
has ideฺ
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ) -------
21-JUN-07 omOne orumore non-system
ilฺc edatafiles t G are missing
142 HIGH OPEN
a n
@ gm Stud
u
Copyright
s
a use
( M
Listing of Data Failures
y u ki se to
The RMAN LIST M asFAILURE
l i c encommand lists failures. If the target instance uses a recovery
y be in STARTED mode, otherwise it must be in MOUNTED mode. The LIST
catalog,litecan
n
Sta command lists the results of previously executed assessments. Repeatedly executing
FAILURE
the LIST FAILURE command revalidates all existing failures. If the database diagnoses new
ones (between command executions), they are displayed. If a user manually fixes failures, or if
transient failures disappear, then the Data Recovery Advisor removes these failures from the
LIST FAILURE output.
To learn more about the syntax:
• failnum: Number of the failure to display repair options for
• ALL: List failures of all priorities.
• CRITICAL: List failures of CRITICAL priority and OPEN status. These failures require
immediate attention, because the make the whole database unavailable.
• HIGH: List failures of HIGH priority and OPEN status. These failures make a database
partly unavailable or unrecoverable; so they should be repaired quickly (for example,
missing archived redo logs).
• LOW: List failures of LOW priority and OPEN status. Failures of a low priority can wait, until
more important failures are fixed.
• CLOSED: List only closed failures.

Listing of Data Failures (continued)

• EXCLUDE FAILURE: Exclude the specified list of failure numbers from the list.
• DETAIL: List failures by expanding the consolidated failure. For example, if there are
multiple block corruptions in a file, the DETAIL option lists each one of them.
See the Oracle Database Backup and Recovery Reference for details on command syntax.
Example of Listing Data Failures

[oracle1@stbbv06 orcl]$ rman
Recovery Manager: Release 11.1.0.5.0 - Beta on Thu Jun 21 13:33:52 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN> connect target sys/oracle@orcl

connected to target database: ORCL (DBID=1153427045)
RMAN> LIST FAILURE DETAIL;

ble
=========================
fe r a
ans
n - t r
no
---------- -------- --------- ------------- -------
142 HIGH OPEN 21-JUN-07
a
One or more non-system
s
datafiles are missing
) h a eฺ
List of child failures for parent failure ID 142
m i d
Failure ID Priority Status
ฺ co nt Gu
Time Detected Summary
i l
306 HIGH OPEN g ma tude
---------- -------- --------- ------------- -------
21-JUN-07 Datafile 5:
u k i@ is S
'/u01/app/oracle/oradata/orcl/example01.dbf' is missing
a sy se th
Impact: Some objects in tablespace EXAMPLE might be unavailable
300 HIGH
k i (M to u
OPEN 21-JUN-07 Datafile 4:
syu cense
'/u01/app/oracle/oradata/orcl/users01.dbf' is missing
a
Impact: Some objects in tablespace USERS might be unavailable
li
le yM
n RMAN>
Sta

Advising on Repair
RMAN ADVISE FAILURE command:

• Syntax:
ADVISE FAILURE
[ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] ]
[ EXCLUDE FAILURE failnum [,failnum,…] ]
• Displays summary of input failure list, including warning

• Displays manual check list
ble
• Generating repair script (for automatic or manual repair)
fe r a
tra ns
. . .
n -
Repair script:
a no
a s
/u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2979
128860.hm ) h i d eฺ
m
o t Gu
RMAN> ilฺc
g ma tuden
sy se th
a
(M to u
Advising on Repair uki
a s y ense
The RMAN ADVISE
y M l ic
FAILURE command displays a recommended repair option for the
specifiedlefailures. The ADVISE FAILURE command prints a summary of the input failure. The
n
Sta implicitly closes all open failures that are already fixed.
command
The default behavior (when no option is used) is to advise on all the CRITICAL and HIGH
priority failures that are recorded in the Automatic Diagnostic Repository. If a new failure has
been recorded in the ADR since the last LIST FAILURE command, this command includes a
WARNING before advising on all CRITICAL and HIGH failures.
Two general repair options are implemented: no-data-loss and data-loss repairs.
When the Data Recovery Advisor generates an automated repair option, it generates a script that
shows you how RMAN plans to repair the failure. If you do not want the Data Recovery Advisor
to automatically repair the failure, then you can use this script as a starting point for your manual
repair. The OS location of the script is printed at the end of the command output. You can
examine this script, customize it (if needed), and also execute it manually, if, for example, your
audit trail requirements recommend such an action.

Executing Repairs
RMAN REPAIR FAILURE command:

• Follows the ADVISE FAILURE command

• Repairs specified failure
• Closes repaired failure
Syntax: Example:
REPAIR FAILURE RMAN> repair failure; ble

fe r a
[PREVIEW]
ans
n - t r
[NOPROMPT]
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Executing Repairs uki
a s y ense
This command
y Mshould belicused after an ADVISE FAILURE command in the same RMAN
session.
n e default (with no option), the command uses the single, recommended repair option
lBy
of t a
Sthe last ADVISE FAILURE execution in the current session. If none exists, the REPAIR
FAILURE command initiates an implicit ADVISE FAILURE command.
By default, you are asked to confirm the command execution, because you may be requesting
substantial changes, which take time to complete. During execution of a repair, the output of the
command indicates what phase of the repair is being executed.
After completing the repair, the command closes the failure.
You cannot run multiple concurrent repair sessions. However, concurrent REPAIR …
PREVIEW sessions are allowed.
• PREVIEW means: Do not execute the repair(s); instead, display the previously generated
RMAN script with all repair actions and comments.
• NOPROMPT: Do not ask for confirmation.

Classifying (and Closing) Failures
RMAN CHANGE FAILURE command:

• Changes failure priority (except for CRITICAL)

• Closes one or more failures
Example:
RMAN> change failure 5 priority low;
=========================
a b le
---------- -------- --------- ------------- -------
s fer
5 HIGH OPEN 20-DEC-06 one ortra n
more
on -
datafiles are missing
a n
h a s
Do you really want to change the above failures
ฺ (enter
YES or NO)? yes ) id e
o m G u
ilฺc nt
changed 1 failures to LOW priority
g ma tude
sy se th
a
(M to u
Classifying (and Closing) k i
u nFailures
a s y e se
This command
y Mis used tolicchange failure priority or close one or more failures.
Syntax:
t a nle
S CHANGE FAILURE
{ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] }
[ EXCLUDE FAILURE failnum[,failnum,…] ]
{ PRIORITY {CRITICAL | HIGH | LOW} |
CLOSE } – change status of the failure(s) to closed
[ NOPROMPT ] – do not ask user for a confirmation
A failure priority can be changed only from HIGH to LOW and from LOW to HIGH. It is an error
to change the priority level of CRITICAL. (One reason why you may want to change a failure
from HIGH to LOW is to avoid seeing it on the default output list of the LIST FAILURE
command. For example, if a block corruption has HIGH priority, you may want to temporarily
change it to LOW if the block is in a little-used tablespace.)
Open failures are closed implicitly when a failure is repaired. However, you can also explicitly
close a failure. This involves a reevaluation of all other open failures, because some of them
might become irrelevant as the result of the failure closure.
By default, the command asks the user to confirm a requested change.

Data Recovery Advisor Views
Querying dynamic data dictionary views:

• V$IR_FAILURE: Listing all failures, including closed ones

(result of the LIST FAILURE command)
• V$IR_MANUAL_CHECKLIST: Listing of manual advice (result
of the ADVISE FAILURE command)
• V$IR_REPAIR: Listing of repairs (result of the ADVISE
FAILURE command)
• V$IR_FAILURE_SET: Cross-reference of failure and advise ble
identifiers fe ra
s n
n - tra
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Data Recovery Advisor
u kiViews e to
A usage example:
y
asAssume s
n you need to display all failures that were detected on June 21,
ethat
2007. ley
M l i c
n SELECT * FROM v$ir_failure
Sta WHERE trunc (time_detected) = '21-JUN-2007';
(Output formatted to fit page)
FAILURE_ID PARENT_ID CHILD_COUNT CLASS_NAME TIME_DETE MODIFIED
DESCRIPTION
IMPACTS PRIORITY STATUS
142 0 0 PERSISTENT_DATA 21-JUN-07 21-JUN-07
One or more non-system datafiles are missing
See impact for individual child failures HIGH CLOSED
Datafile 4: '/u01/app/oracle/oradata/orcl/users01.dbf' is missing
Some objects in tablespace USERS might be unavailable HIGH CLOSED
Datafile 5: '/u01/app/oracle/oradata/orcl/example01.dbf' is missing
Some objects in tablespace EXAMPLE might be unavailable HIGH CLOSED
See the Oracle Database Reference for details of the dynamic data dictionary views that the
Data Recovery Advisor uses.

Summary

• Set up Automatic Diagnostic Repository

• Use and monitor Support Workbench
• Run health checks
• Identify the causes of database corruption:
– Hardware
– Software
• Detect and repair database corruption ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Practice 13 Overview: Diagnosing the Database

• Discovering corruptions
• Identifying the location of the corruption
• Employing Support Workbench
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Managing Memory
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta
Objectives

• Describe the memory components in the SGA

• Implement Automatic Memory Management
• Manually configure SGA parameters
• Configure automatic PGA memory management
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Memory Management: Overview
DBAs must consider memory management to be a crucial part

of their job because:

• There is a finite amount of memory available
• Allocating more memory to serve certain types of functions
can improve overall performance
• Automatically tuned memory allocation is often the
appropriate configuration, but specific environments or even
short-term conditions may require further attention e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Memory Management: k i
Overview
a s yu ense
Because thereM
y c
is a finiteliamount of memory available on a database server and thus, on an
a le
Oraclendatabase instance, you must pay attention to how memory is allocated. If too much
S t
memory is allowed to be used by a particular area that does not need it, then there is the
possibility that there are other functional areas unnecessarily doing without enough memory to
perform optimally. With the ability to have memory allocation automatically determined and
maintained for you, the task is simplified greatly. But even automatically tuned memory needs
to be monitored for optimization and may need to be manually configured to some extent.

Oracle Memory Structures

Server Server Back-

process PGA process PGA ground PGA
1 2 process
SGA
Keep buffer
Shared pool Streams pool Large pool cache
Recycle ble
fe r a
buffer cache
Database Redo t r a ns
Java pool
buffer cache buffer o n
nK block
- size
s a n caches
buffer
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Oracle Memory Structures
y u ki se to
The basic memory
M asstructures
l i c enassociated with an Oracle instance include:
l ey Global Area (SGA): Shared by all server and background processes. Examples of
• System
n
Stadata stored in the SGA include cached data blocks and shared SQL areas.
• Program Global Area (PGA): Private to each server and background process; there is one
PGA for each process.
The SGA is a shared memory area that contains data and control information for the instance,
including the following:
• Database buffer cache: Caches blocks of data retrieved from disk
• Redo log buffer: Caches redo information until it can be written to disk
• Shared pool: Caches various constructs that can be shared among users
• Large pool: Optional area used for buffering large I/O requests in support of parallel query,
shared server, Oracle XA, and certain types of backup operations
• Java pool: Holds session-specific Java code and data within the Java Virtual Machine
(JVM)
• Streams pool: Used by Oracle Streams
• Keep buffer cache: Holds data that is kept in the buffer cache as long as possible
• Recycle buffer cache: Holds data that is quickly aged out of the buffer cache
• nK block size buffer caches: Caches data blocks that are of a different size than the default
database block size; used to support transportable tablespaces
Oracle Memory Structures (continued)

The size of the database buffer cache, shared pool, large pool, streams pool, and Java pool can
be adjusted automatically to meet present needs. Also, those memory buffers, along with the
keep buffer cache, the recycle buffer cache, and the nK block size buffer caches, can be changed
without shutting down the instance.
The Oracle database provides alerts and advisors to identify memory-sizing problems and to
help you determine appropriate values for memory parameters.

A Program Global Area (PGA) is a memory region that contains data and control information
for each server process. A server process is a process that services a client’s requests. Each
server process has its own private PGA that is created when the server process is started. Access
to it is exclusive to that server process.
The amount of PGA memory used and the contents of the PGA depend on whether the instance
is configured in shared server mode. Generally, the PGA contains the following:
• Private SQL area: Contains data such as bind information and run-time memory
structures. Each session that issues a SQL statement has a private SQL area.
a b le
• Session memory: Memory allocated to hold session variables and other information
s ferrelated
to the session
n - tran
o
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
ki this
s y u
( M a u se
y u ki se to
M as licen
ley
n
Sta

Buffer Cache
SGA
Server LRU Checkpoint

lists queue DB buffer cache
. .
. .
. .
. .
a b le
DB_BLOCK_SIZE
e r
DB_CACHE_SIZE a n sf
o n -tr
DB_RECYCLE_CACHE_SIZE
n
DBWn sa
DB_KEEP_CACHE_SIZE
ha ideฺ
m Gu)
ฺ c o t
Data files
a il e n
@ gm Stud
u
Copyright
s
a use
( M
Buffer Cache
y u ki se to
asthe buffer
You can configure
M l i c encache by specifying a value for the DB_CACHE_SIZE parameter.
l
The buffer
n eycache holds copies of the data blocks from the data files having a block size of
Sta
DB_BLOCK_SIZE. The buffer cache is a part of the SGA; so all users can share these blocks.
The server processes read data from the data files into the buffer cache. To improve
performance, the server process sometimes reads multiple blocks in a single read operation. The
DBWn process writes data from the buffer cache into the data files. To improve performance,
DBWn writes multiple blocks in a single write operation.
At any given time, the buffer cache may hold multiple copies of a single database block. Only
one current copy of the block exists, but to satisfy queries, server processes may need to
construct read-consistent copies from past image information. This is called a consistent read
(CR) block.
The least recently used (LRU) list reflects the usage of buffers. The buffers are sorted on the
basis of a combination of how recently and how often they have been referenced. Thus, buffers
that are most frequently and recently used are found at the most recently used end. Incoming
blocks are copied to a buffer from the least recently used end, which is then assigned to the
middle of the list, as a starting point. From here, the buffer works its way up or down the list,
depending on usage.

Buffer Cache (continued)

Buffers in the buffer cache can be in one of four states:
• Pinned: The block is either currently being read into the cache or being written to. Other
sessions wait to access the block.
• Clean: The buffer is now unpinned and is a candidate for immediate aging out if the current
contents (data block) are not referenced again. Either the contents are in sync with disk or
the buffer contains a CR snapshot of a block.

• Free/unused: The buffer is empty because the instance just started. This state is very
similar to the clean state, except that the buffer has not been used.
• Dirty: The buffer is no longer pinned but the contents (data block) have changed and must
be flushed to disk by DBWn before it can be aged out.
Server processes use the buffers in the buffer cache, but the DBWn process makes buffers in the
cache available by writing changed buffers back to the data files. The checkpoint queue lists the
buffers that are to be written out to disk.
Then Oracle database supports multiple block sizes in the same database. The standard block le
size is used for the SYSTEM tablespace. You specify the standard block size by setting the r a b
e
sf and the
initialization parameter DB_BLOCK_SIZE. Legitimate values are from 2 KB to a 32nKB,
n
default is 8 KB. The cache sizes of nonstandard block size buffers are specified
o -trby the following
parameters:
s an
• DB_2K_CACHE_SIZE
) ha ideฺ
c o m Gu
a il ฺ n t
• DB_16K_CACHE_SIZE gm Stud e
@
sy uki his t
The DB_nK_CACHE_SIZEM parameters e be used to size the cache for the standard block
a uscannot
(
ki se to is nK, it is illegal to set DB_nK_CACHE_SIZE. The
size. If the value of DB_BLOCK_SIZE
y u
s the standard
size of the cacheafor
M l i c en block size is always determined from the value of
n l ey
DB_CACHE_SIZE.
t
Eacha
S buffer cache has a limited size, so typically not all the data on disk can fit in the cache.
When the cache is full, subsequent cache misses cause the Oracle database to write dirty data
already in the cache to disk to make room for the new data. (If a buffer is not dirty, it does not
need to be written to disk before a new block can be read into the buffer.) Subsequent access to
any data that was written to disk results in additional cache misses.
The size of the cache affects the likelihood that a request for data will result in a cache hit. If the
cache is large, it is more likely to contain the data that is requested. Increasing the size of a
cache increases the percentage of data requests that result in cache hits.

Using Multiple Buffer Pools

SGA
DB buffer caches
Recycle pool
Keep pool
ble
fe r a
ans
n - t r
Default pool a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using Multiple Buffer k i
Pools
a s yu ense
The database M
y lic (DBA) may be able to improve the performance of the database
administrator
le by creating multiple buffer pools. You assign objects to a buffer pool depending on
bufferncache
a
howt
S the objects are accessed. There are three buffer pools:
• Keep: This pool is used to retain objects in memory that are likely to be reused. Keeping
these objects in memory reduces I/O operations. Buffers are kept in this pool by ensuring
that the pool is sized larger than the total size of the segments assigned to the pool. This
means that buffers do not have to be aged out. The keep pool is configured by specifying a
value for the DB_KEEP_CACHE_SIZE parameter.
• Recycle: This pool is used for blocks in memory that have little chance of being reused.
The recycle pool is sized smaller than the total size of the segments assigned to the pool.
This means that blocks read into the pool will often have to age out a buffer. The recycle
pool is configured by specifying a value for the DB_RECYCLE_CACHE_SIZE parameter.
• Default: This pool always exists. It is equivalent to the buffer cache of an instance without
a keep pool or a recycle pool and is configured with the DB_CACHE_SIZE parameter.
Note: The memory in the keep or recycle pool is not a subset of the default buffer pool.

Using Multiple Buffer Pools

CREATE INDEX cust_idx …

STORAGE (BUFFER_POOL KEEP …);
ALTER TABLE oe.customers

STORAGE (BUFFER_POOL RECYCLE);
ALTER INDEX oe.cust_lname_ix

STORAGE (BUFFER_POOL KEEP);
bl e
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using Multiple Buffer k i
u ns(continued)
Pools e
a s y e
The BUFFER_POOL
y M clausel ic is used to define the default buffer pool for an object. It is part of
a n le clause and is valid for CREATE and ALTER table, cluster, and index statements.
the STORAGE
Thet
S blocks from an object without an explicitly set buffer pool go into the default buffer pool.
The syntax is BUFFER_POOL [KEEP | RECYCLE | DEFAULT].
When the default buffer pool of an object is changed using the ALTER statement, blocks that are
already cached remain in their current buffers until they are flushed out by the normal cache
management activity. Blocks read from disk are placed into the newly specified buffer pool for
the segment.
Because buffer pools are assigned to a segment, objects with multiple segments can have blocks
in multiple buffer pools. For example, an index-organized table can have different pools defined
on both the index and the overflow segment.

Shared Pool
• Size is specified by using SHARED_POOL_SIZE.

• Library cache contains statement text, parsed code, and
execution plan.
• Data dictionary cache contains definitions for tables,
columns, and privileges from the data dictionary tables.
• The User Global Area (UGA) contains session information if
using Oracle shared server.
Shared pool
Shared pool
Library cache ble
fe r a
n s
Shared n - a
Data dictionarytrcache
pool
a no
h a s
Result cache
ฺ
) id e
o m G u
a ilฺc ent UGA
@ gm Stud
u
Copyright
s
a use
( M
Shared Pool
y u ki se to
You can specify
M athes sizelicofethe
n shared pool with the SHARED_POOL_SIZE initialization
l
parameter.
n eyThe shared pool is a memory area that stores information shared by multiple sessions.
ta different types of data, as shown in the graphic in the slide.
ItScontains
Library cache: The library cache contains shared SQL and PL/SQL areas—the fully parsed or
compiled representations of PL/SQL blocks and SQL statements. PL/SQL blocks include:
• Procedures and functions
• Packages
• Triggers
• Anonymous PL/SQL blocks
Data dictionary cache: The data dictionary cache holds definitions of dictionary objects in
memory.
Result cache: The result cache comprises the SQL query result cache and PL/SQL function
result cache. This cache is used to store results of SQL queries or PL/SQL functions to speed up
their future execution.
User Global Area: The UGA contains the session information for the Oracle shared server. The
UGA is located in the shared pool when using a shared server session and if the large pool is not
configured.

Large Pool
• Can be configured as a separate memory area in the SGA

• Is sized by the LARGE_POOL_SIZE parameter
• Is used to store data in memory for:

– UGA
– Backup and restore operations
– Parallel query messaging
Shared pool Large pool

Redo log Database Library cache
buffer buffer cache UGA Backup
ble
fe r a
ans
Dictionary cache
n - t r
no
Session
a
a s
m ) h uideฺ Parallel
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Large Pool
y u ki se to
Existence of M
s cen
theaLargeliPool
l y must be explicitly configured. The memory of the large pool does not come out
epool
n
The large
ta shared pool, but directly out of the SGA, thus adding to the amount of shared memory that
Sthe
of
the Oracle server needs for an instance at startup.
Advantages of the Large Pool
The large pool is used to provide large allocations of session memory for:
• I/O server processes
• Backup and restore operations
• Oracle shared server processes and the Oracle XA interface (used where transactions
interact with more than one database)
By allocating session memory from the large pool for the Oracle shared server, the shared pool
has less fragmentation that would come from having large objects frequently allocated and
deallocated in it. Segregating large objects out of the shared pool results in more efficient shared
pool usage, which means more of its memory is available to service new requests, and to retain
existing data if needed.

Java Pool
• Can be configured as a separate memory area in the SGA

• Is sized by the JAVA_POOL_SIZE parameter

• Is used to store data in memory for all session-specific Java
code and data within the JVM
Shared pool
Redo log Database Library cache Large pool
buffer buffer cache
bl e
fe r a
t r a ns
Dictionary cache -
Java pool
o n
s an
) ha ideฺ
c o m Gu
a il ฺ n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
Java Pool
y u ki se to
The Java poolM
s ceinn the SGA that is used for all session-specific Java code and data
isaa structure
li
l
withinntheeyJava engine.
Sta Pool
Shared
Shared pool memory is used by the class loader within the JVM. The class loader uses about
8 KB of memory per loaded class. The shared pool is also used when compiling Java source
code in the database or when using Java resource objects in the database. Shared pool memory is
also consumed when you create call specifications and as the system tracks dynamically loaded
Java classes at run time.
Java Pool
The Oracle JVM memory manager allocates all other Java states during run-time execution from
the Java pool, including the shared in-memory representation of Java method and class
definitions, as well as the Java objects migrated to session space at end-of-call.
Java pool memory is used in different ways, depending on whether the Oracle database server is
using shared servers or not.
For more information about Java pool memory usage, refer to the Oracle Database Java
Developer’s Guide.

Redo Log Buffer
Shared pool
Redo log Database
buffer buffer cache Library cache
Dictionary cache
ble
Server
LGWR ARCn fe r a
process
ans
Control files
n - t r
SQL> UPDATE employees a no
a s
2 SET salary=salary*1.1
) h i d eฺ Archived
3 WHERE employee_id=736; Datao m Gulog files log files
c files ntRedo
i l ฺ
g ma tude
sy se th
a
(M to u
Redo Log Buffer k i
a s yu ense
The Oracle server
y lic copy redo entries from the user’s memory space to the redo log
M processes
leeach DML or DDL statement. The redo entries contain the information necessary to
buffernfor
a
S t
reconstruct or redo changes made to the database by DML and DDL operations. They are used
for database recovery and take up continuous sequential space in the buffer.
The redo log buffer is a circular buffer; the server processes can copy new entries over the
entries in the redo log buffer that have already been written to disk. The LGWR process normally
writes fast enough to ensure that space is always available in the buffer for new entries. The
LGWR process writes the redo log buffer to the active online redo log file (or members of the
active group) on disk. The LGWR process copies to disk all redo entries that have been entered
into the buffer since the last time LGWR wrote to disk.
What Causes LGWR to Write?
LGWR writes out the redo data from the redo log buffer:
• When a user process commits a transaction
• Every three seconds, or when the redo log buffer is one-third full
• When a DBWn process writes modified buffers to disk, if the corresponding redo log data
has not already been written to disk

Automatic Shared Memory Management:

Overview
• Automatically adapts to workload changes
• Maximizes memory utilization

• Helps eliminate out-of-memory errors
Buffer cache
Buffer cache
Example: Large pool

Large pool e
r a bl
s fe
Shared pool Shared pool
- t r an
Java pool no n
Java a
pool
ha pool s
Streams pool Streams eฺ ) id
o m G u
Online users
a ilฺc ent Batch jobs
@ gm Stud
u
Copyright
s
a use
( M to
Automatic Shared Memory
y u ki sManagement:
e Overview
Automatic Shared
s
a Memory c n
eManagement (ASMM) simplifies SGA memory management. You
M l i
l
specify the
n eytotal amount of SGA memory available to an instance using the SGA_TARGET
Sta
initialization parameter and Oracle Database automatically distributes this memory among the
various SGA components to ensure the most effective memory utilization.
For example, in a system that runs large online transactional processing (OLTP) jobs during the
day (requiring a large buffer cache) and runs parallel batch jobs at night (requiring a large value
for the large pool), you would have to simultaneously configure both the buffer cache and the
large pool to accommodate your peak requirements.
With ASMM, when the OLTP job runs, the buffer cache grabs most of the memory to allow for
good I/O performance. When the data analysis and reporting batch job starts up later, the
memory is automatically migrated to the large pool so that it can be used by parallel query
operations without producing memory overflow errors.
The Oracle Database remembers the sizes of the automatically tuned components across instance
shutdowns if you are using a server parameter file (SPFILE). As a result, the system does need
to learn the characteristics of the workload again each time an instance is started. It can begin
with information from the past instance and continue evaluating workload where it left off at the
last shutdown.

How ASMM Works
• ASMM is based on workload information that MMON captures

in the background.
• MMON uses memory advisors.
• Memory is moved to where it is needed the most by MMAN.
• If an SPFILE is used (which is recommended):
– Component sizes are saved across shutdowns
– Saved values are used to bootstrap component sizes
– There is no need to relearn optimal values ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
How ASMM Works uki
a s y ense
The Automatic
y ic
MShared lMemory Management feature uses the SGA memory broker that is
a n le by two background processes: Manageability Monitor (MMON) and Memory

implemented
S t
Manager (MMAN). Statistics and memory advisory data are periodically captured in memory by
MMON. MMAN coordinates the sizing of the memory components according to MMON decisions.
The SGA memory broker keeps track of the sizes of the components and pending resize
operations.
The SGA memory broker observes the system and workload in order to determine the ideal
distribution of memory. It performs this check every few minutes so that memory can always be
present where needed. In the absence of Automatic Shared Memory Management, components
had to be sized to anticipate their individual worst-case memory requirements.
On the basis of workload information, Automatic Shared Memory Management:
• Captures statistics periodically in the background
• Uses memory advisors
• Performs what-if analysis to determine the best distribution of the memory
• Moves memory to where it is most needed
• Saves component sizes across shutdown if an SPFILE is used (the sizes can be resurrected
from before the last shutdown)

Enabling Automatic Shared Memory Management
To enable ASMM from manual shared memory management:

1. Get a value for SGA_TARGET:

SELECT ((SELECT SUM(value) FROM V$SGA) - (SELECT CURRENT_SIZE
FROM V$SGA_DYNAMIC_FREE_MEMORY)) "SGA_TARGET" FROM DUAL;
2. Use that value to set SGA_TARGET.

3. Set the values of the automatically sized SGA components
to 0.
To switch to ASMM from Automatic Memory Management: a b le
s fer
an
1. Set the MEMORY_TARGET initialization parameter to r0.
o n -t
2. Set the values of the automatically sized SGAncomponents
to 0. s a
a
) h uideฺ
o m
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to Management
Enabling Automaticu
y ki sMemory
Shared e
The procedureMfor asenabling
l i c n
eASMM differs depending on whether you are changing to ASMM
from manual
l e y shared memory management or from automatic memory management. To change
n
S1.taRun thefrom
to ASMM manual shared memory management:
following query to obtain a value for SGA_TARGET:
SELECT ((SELECT SUM(value) FROM V$SGA) - (SELECT CURRENT_SIZE
FROM V$SGA_DYNAMIC_FREE_MEMORY)) “SGA_TARGET” FROM DUAL;
2. Set the value of SGA_TARGET:
ALTER SYSTEM SET SGA_TARGET=value [SCOPE={SPFILE|MEMORY|BOTH}]
where value is the value computed in step 1 or is some value between the sum of all SGA
component sizes and SGA_MAX_SIZE.
3. Set the values of the automatically sized SGA components to 0. Do this by editing the text
initialization parameter file or by issuing ALTER SYSTEM statements. Restart the instance
if required.
To change to ASMM from automatic memory management:
1. Set the MEMORY_TARGET initialization parameter to 0.
ALTER SYSTEM SET MEMORY_TARGET = 0;
The database sets SGA_TARGET based on current SGA memory allocation.
2. Set the values of the automatically sized SGA components to 0. Restart the instance when
finished.
Note: Automatic Memory Management is discussed later in this lesson.
Behavior of Autotuned
SGA Parameters
• When SGA_TARGET is not set or is set to 0:
– Autotuned parameters specify the actual size of those

components
– SHARED_POOL_SIZE may need to be increased
SELECT SUM(bytes)/1024/1024 size_mb
FROM v$sgastat WHERE pool = 'shared pool';
• When SGA_TARGET is set to a nonzero value:
– Default value of autotuned parameters is 0 e
– The specified value is used as a minimum size r a bl
ns fe
SELECT component, current_size/1024/1024 size_mb -tra
FROM v$sga_dynamic_components; non a
a s
m ) h uideฺ
o
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M to
Behavior of Autotuned
y u kiSGAsParameters
e
When SGA_TARGET
M as islinot
c enset or is equal to 0, autotuned SGA parameters specify the actual
l ey components. When Automatic Shared Memory Management is enabled, you can
size ofnthose
Staspecify values for the autotuned SGA parameters, but the values carry a different meaning.
still
If you set any of the autotuned parameters to a nonzero value, the specified value is used as a
lower bound by the autotuning algorithm. For example, if SGA_TARGET is set to 8 GB and
SHARED_POOL_SIZE is set to 1 GB, the Automatic Shared Memory Management algorithm
does not shrink the shared pool to below 1 GB. Use the second query given in the slide to
determine the actual size of the autotuned components in the SGA.

Behavior of Manually Tuned

SGA Parameters
• Some components are not autotuned.
– DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE

– Nonstandard block size buffer caches, DB_nK_CACHE_SIZE
– LOG_BUFFER
• These components must be manually configured using
database parameters.
• The memory used by these components reduces the amount
of memory available for autotuning the SGA. e
r a bl
s fe
- t r an
no n
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Behavior of Manually k i
u nseSGA Parameters
Tuned
s y
a thelicmanually
e
When using ASMM,
M tuned SGA parameters are:
le y
• DB_KEEP_CACHE_SIZE
t a n
S• DB_RECYCLE_CACHE_SIZE
• DB_nK_CACHE_SIZE (n = 2, 4, 8, 16, 32)
• LOG_BUFFER
If you want to use memory components that are not automatically sized, you must configure the
appropriate parameters. The values specified for these parameters precisely control the sizes of
the memory components.
When SGA_TARGET is set, the total size of manual SGA size parameters is subtracted from the
SGA_TARGET value, and the balance is given to the autotuned SGA components.
For example, if SGA_TARGET is set to 8 GB and DB_RECYCLE_CACHE_SIZE is set to 1 GB,
then the total size of the five autotuned components (shared pool, Java pool, default buffer
cache, Streams pool, and large pool) is limited to 7 GB. The 7 GB size includes the fixed SGA
and log buffer, and only after memory has been allocated to them is the rest of the memory
divided between the autotuned components. The size of the recycle cache is 1 GB, as specified
by the parameter.

Using the V$PARAMETER View

SGA_TARGET = 8G
DB_CACHE_SIZE = 0
JAVA_POOL_SIZE = 0
LARGE_POOL_SIZE = 0
SHARED_POOL_SIZE = 0
STREAMS_POOL_SIZE = 0
ble
fe r a
ans
SELECT name, value, isdefault
n - t r
FROM v$parameter
a no
WHERE name LIKE '%size';
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
M to u
(View
Using the V$PARAMETER k i
a s yu ense
When you specify
y ic value for SGA_TARGET and do not specify a value for an
M a nonzero
l
autotuned
a n leSGA parameter, the value of the autotuned SGA parameters in the V$PARAMETER
t
view
S is 0, and the value of the ISDEFAULT column is TRUE.
If you have specified a value for any of the autotuned SGA parameters, the value that is
displayed when you query V$PARAMETER is the value that you specified for the parameter.

Modifying the SGA_TARGET Parameter
• The SGA_TARGET initialization parameter:

– Is dynamic
– Can be increased up to SGA_MAX_SIZE
– Can be reduced until all components reach their minimum
size
• A change in the value of SGA_TARGET affects only
automatically sized components.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(MParameter u
Modifying the SGA_TARGETk i t o
a s yu ense
SGA_TARGET
y l ic parameter and can be changed through Database Control or with
Mis a dynamic
t a nle SYSTEM command.
the ALTER
S
SGA_MAX_SIZE is the maximum amount of memory that can be allocated to the SGA. It
cannot be changed without restarting the database. SGA_TARGET can be increased up to the
value of SGA_MAX_SIZE. It can be reduced until any one of the autotuned components reaches
its minimum size: either a user-specified minimum or an internally determined minimum.
• If you increase the value of SGA_TARGET, the additional memory is distributed according
to the autotuning policy across the autotuned components.
• If you reduce the value of SGA_TARGET, the memory is taken away by the autotuning
policy from one or more of the autotuned components.
Suppose that SGA_MAX_SIZE is set to 10 GB and SGA_TARGET is set to 8 GB. If
DB_KEEP_CACHE_SIZE is set to 1 GB and you increase SGA_TARGET to 9 GB, then the
additional 1 GB is distributed only among the components controlled by SGA_TARGET. The
value of DB_KEEP_CACHE_SIZE is not affected. Likewise, if SGA_TARGET is reduced to
7 GB, then the 1 GB is taken from only those components that are controlled by SGA_TARGET.
This decrease does not affect the settings of manually controlled parameters such as
DB_KEEP_CACHE_SIZE.

Disabling ASMM
• Setting SGA_TARGET to 0 disables autotuning.

• Autotuned parameters are set to their current sizes.

• The SGA size as a whole is unaffected.
SGA size = 8 GB SGA size = 8 GB
Parameters:
sga_target = 0
a b le
Parameters: db_cache_size = 5G
s fer
sga_target = 8G
shared_pool_size = - t r an
2G
shared_pool_size = 1G
large_pool_sizen on= 512M
s a
Original values a
h ideฺ= 256M
java_pool_size
)
om u
streams_pool_size = 256M
a ilฺc ent G
@ gm Stud
u
Copyright
s
a use
( M
Disabling ASMM
y u ki se to
as choose
You can dynamically
M l i c ento disable Automatic Shared Memory Management by setting
l
SGA_TARGET
n ey to 0. In this case, the values of all the autotuned parameters are set to the current
Staof the corresponding components, even if the user had earlier specified a different nonzero
sizes
value for an autotuned parameter.
In the example in the slide, the value of SGA_TARGET is 8 GB and the value of
SHARED_POOL_SIZE is 1 GB. If the system has internally adjusted the size of the shared pool
component to 2 GB, then setting SGA_TARGET to 0 results in SHARED_POOL_SIZE being set
to 2 GB, thereby overriding the original user-specified value.

Manually Resizing
Dynamic SGA Parameters
• For autotuned parameters, manual resizing:
– Results in immediate component resize if the new value is

greater than the current size
– Changes the minimum size if the new value is smaller than
the current size
• Resizing manually tuned parameters affects only the tunable
portion of the SGA.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Manually Resizing Dynamic k i
u nsSGA e Parameters
s y
a parameter e is resized and SGA_TARGET is set, the resizing results in an
When an autotuned
M l i c
l
immediate
n eychange to the size of the component only if the new value is larger than the current
Staof the component. For example, if you set SGA_TARGET to 8 GB and set
size
SHARED_POOL_SIZE to 2 GB, ensure that the shared pool has at least 2 GB at all times to
accommodate the necessary memory allocations. After this, adjusting the value of
SHARED_POOL_SIZE to 1 GB has no immediate effect on the size of the shared pool. It allows
the automatic memory-tuning algorithm to later reduce the shared pool size to 1 GB if it needs
to. Alternatively, if the size of the shared pool is 1 GB to begin with, then adjusting the value of
SHARED_POOL_SIZE to 2 GB results in the shared pool component growing immediately to a
size of 2 GB. The memory used in this resize operation is taken away from one or more
autotuned components, and the sizes of the manual components are not affected.
Parameters for manually sized components can be dynamically altered as well, but the
difference is that the value of the parameter specifies the precise size of that component
immediately. Therefore, if the size of a manual component is increased, extra memory is taken
away from one or more automatically sized components. If the size of a manual component is
decreased, the memory that is released is given to the automatically sized components.

Using the Memory Advisor to

Size the SGA
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using the Memory Advisor k i
u nstoeSize the SGA
s y
a Advisor, eyou can tune the size of your memory structures. If ASMM is
With the MemoryM l i c
y can use this to tune the total size of the SGA. If ASMM is disabled, you can use
enabled,
n l eyou
Staadvisor to tune the different components of the SGA.
this
You can invoke the memory advisors by performing the following steps:
1. Click the Server folder tab from the database home pages.
2. Click Memory Advisors under the Database Configuration. The Memory Advisors page is
displayed. This page provides a breakdown of memory usage for the SGA.
3. Click Advice next to the Total SGA Size field to invoke the advisor.

Program Global Area (PGA)

PGA
Server Private Cursor
PGA Session Work
process
SQL and SQL
memory area
areas area
Dedicated
connections
ble
Shared
PGA fe r a
server Shared pool
t r a ns
or PGA n-
Shared server large pool a no
a s
connections
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Program Global Area k i
(PGA)
a s yu ense
The Program M
y
Global Area
l ic (PGA) is a memory region that contains data and control information
le process. It is nonshared memory created by the Oracle server when a server process
for a server
tan Access to it is exclusive to that server process. The total PGA memory allocated by all
isSstarted.
server processes attached to an Oracle instance is also referred to as the aggregated PGA
memory allocated by the instance.
Part of the PGA can be located in the SGA when using shared servers.
PGA memory typically contains the following:
Private SQL Area
A private SQL area contains data such as bind information and run-time memory structures. This
information is specific to each session’s invocation of the SQL statement; bind variables hold
different values, and the state of the cursor is different, among other things. Each session that
issues a SQL statement has a private SQL area. Each user that submits the same SQL statement
has his or her own private SQL area that uses a single shared SQL area. Thus, many private SQL
areas can be associated with the same shared SQL area. The location of a private SQL area
depends on the type of connection established for a session. If a session is connected through a
dedicated server, private SQL areas are located in the server process’s PGA. However, if a
session is connected through a shared server, part of the private SQL area is kept in the SGA.

Program Global Area (PGA) (continued)

Cursor and SQL Areas
The application developer of an Oracle Pro*C program or Oracle Call Interface (OCI) program
can explicitly open cursors or handles to specific private SQL areas, and use them as a named
resource throughout the execution of the program. Recursive cursors that the database issues
implicitly for some SQL statements also use shared SQL areas.
Work Area
For complex queries (for example, decision support queries), a big portion of the PGA is
dedicated to work areas allocated by memory-intensive operators, such as:
• Sort-based operators, such as ORDER BY, GROUP BY, ROLLUP, and window functions
• Hash-join
• Bitmap merge
• Bitmap create
• Write buffers used by bulk load operations
A sort operator uses a work area (the sort area) to perform the in-memory sort of a set of rows.
a b le
f
Similarly, a hash-join operator uses a work area (the hash area) to build a hash table from
s erits left
input. - t r an
The size of a work area can be controlled and tuned. Generally, bigger n onareas can
work
s
significantly improve the performance of a particular operator atathe
a higher memory
cost of
consumption. m ) h uideฺ
o
Session Memory a ilฺc ent G
Session memory is the memory allocatedi@ to hold S tud variables (logon information) and
gma session’s
other information related to the session.
y h is server, the session memory is shared and
uk For atshared
s
not private. Ma use
i ( e to
u k
a sy cens
yM li
n le
Sta

Automatic PGA Memory Management
• Dynamically adjusts the amount of PGA memory dedicated

to work areas, on the basis of the

PGA_AGGREGATE_TARGET parameter
• Helps maximize the performance of all the memory-intensive
SQL operations
• Is enabled by default
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Automatic PGA Memory k i
u Management
a s y e n se
By default, Oracle
y M Databaselic automatically and globally manages the total amount of memory
dedicated
a n leto the instance PGA. You can control this amount by setting the initialization
S t
parameter PGA_AGGREGATE_TARGET. Oracle Database then tries to ensure that the total
amount of PGA memory allocated across all database server processes and background
processes never exceeds this target.
If you create your database with DBCA, you can specify a value for the total instance PGA.
DBCA then sets the PGA_AGGREGATE_TARGET initialization parameters in the server
parameter file (SPFILE) that it creates. If you do not specify the total instance PGA, DBCA
chooses a reasonable default.
When running in automatic PGA memory management mode, sizing of work areas for all
sessions becomes automatic and the *_AREA_SIZE parameters (such as SORT_AREA_SIZE)
are ignored by all sessions running in that mode. At any given time, the total amount of PGA
memory available to active work areas in the instance is automatically derived from the
PGA_AGGREGATE_TARGET initialization parameter. This amount is set to the value of
PGA_AGGREGATE_TARGET minus the amount of PGA memory allocated by other
components of the system (for example, PGA memory allocated by sessions). The resulting
PGA memory is then assigned to individual active work areas on the basis of their specific
memory requirements.

PGA Management Resources
• Statistics to manage the PGA_AGGREGATE_TARGET

initialization parameter, such as PGA cache hit percentage

• Statistics on allocation and use of work area memory can be
viewed in the following dynamic performance views:
– V$SYSSTAT
– V$SESSTAT
– V$PGASTAT
– V$SQL_WORKAREA e
– r a bl
V$SQL_WORKAREA_ACTIVE
s fe
• Views to assist in sizing the PGA work area are: - t r an
no n
– V$PGA_TARGET_ADVICE a
a s
– V$PGA_TARGET_ADVICE_HISTOGRAM/
) h i d eฺ
m Gu
ฺco
V$SQL_WORKAREA_HISTOGRAM
a il n t
gm Stud e
@
k© i2009, Oracle.
s y u
Copyright
t h
( M a use
PGA Management Resources
y u ki se to
When configuring
M asa newlicinstance,
en it is difficult to know precisely the appropriate setting for
l ey
PGA_AGGREGATE_TARGET.
n You can determine this setting in three stages:
t a
S1. Make the first estimate for PGA_AGGREGATE_TARGET, based on convention. By default,
the Oracle database sets this to 20% of the SGA size. However, this initial setting may be
too low for a large DSS system.
2. Run a representative workload on the instance and monitor performance, using PGA
statistics collected by Oracle, to see whether the maximum PGA size is underconfigured or
overconfigured.
3. Tune PGA_AGGREGATE_TARGET, using Oracle PGA advice statistics.
The following three columns in the V$PROCESS view report the PGA memory allocated and
used by an Oracle Database process:
• PGA_USED_MEM
• PGA_ALLOCATED_MEM
• PGA_MAX_MEM

Using the Memory Advisor

to Size the PGA
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Using the Memory Advisork i
u nstoeSize the PGA
s y
a can ebe used to get advice on the size of the PGA. To do this, click the
The Memory M Advisor l i c
y then click Advice. In this example, the graph shows that raising the Aggregate
l
PGA tab,
n eand
StaTarget from 80 MB to approximately 140 MB will raise the cache hit percentage from 60%
PGA
to close to 100%.

Automatic Memory Management: Overview
With Automatic Memory Management, the database can size

the SGA and PGA automatically according to your workload.

11g 11g
350 MB 350 MB
Memory Memory
Max Target Max Target
300 MB
Memory Target
250 MB
Memory Target
ble
ALTER SYSTEM SET fe r a
ans
MEMORY_TARGET=300M;
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
Automatic Memory Management:
u nse Overview
s y
a Managemente
Automatic Memory
y M l i c (AMM) allows the Oracle Database to manage SGA memory
a n le PGA memory sizing automatically. To do so (on most platforms), you set only a
and instance
t
target
S memory size initialization parameter (MEMORY_TARGET) and a maximum memory size
initialization parameter (MEMORY_MAX_TARGET), and the database dynamically exchanges
memory between the SGA and the instance PGA as needed to meet processing demands. With
this memory management method, the database also dynamically tunes the sizes of the
individual SGA components and the sizes of the individual PGAs.
Because the target memory initialization parameter is dynamic, you can change the target
memory size at any time without restarting the database. The maximum memory size serves as
an upper limit so that you cannot accidentally set the target memory size too high. Because
certain SGA components either cannot easily shrink or must remain at a minimum size, the
database also prevents you from setting the target memory size too low.
This indirect memory transfer relies on the operating system (OS) mechanism of freeing shared
memory. After memory is released to the OS, the other components can allocate memory by
requesting memory from the OS.
Currently, Automatic Memory Management is implemented on Linux, Solaris, HPUX, AIX, and
Windows.

Oracle Database Memory Parameters
MEMORY_MAX_TARGET
SGA_MAX_SIZE
MEMORY_TARGET
SGA_TARGET PGA_AGGREGATE_TARGET
SHARED_POOL_SIZE Others
DB_CACHE_SIZE
LARGE_POOL_SIZE
ble
JAVA_POOL_SIZE
fe r a
STREAMS_POOL_SIZE
ans
n - t r
DB_KEEP_CACHE_SIZE LOG_BUFFER
a no
DB_RECYCLE_CACHE_SIZE
a s
DB_nK_CACHE_SIZE ) h i d eฺ
m u
ฺco t G
RESULT_CACHE_MAX_SIZE
ail den
m
g Stu
Copyright
t h
( M a use
Oracle Database Memory u ki Sizing
e toParameters
y
asslidelishowss
en you the memory initialization parameters hierarchy. Although
The graphic inMthe c
you haveletoyset only MEMORY_TARGET to trigger Automatic Memory Management, you still
n
Stathe possibility to set lower bound values for various caches. Therefore, if the child
have
parameters are user set, they will be the minimum values below which the Oracle database
server will not autotune that component.

Automatic Memory Parameter Dependency

N Y Y
MT>0 MMT=0 MMT=MT
N
MT=0 MMT>0
Y
ST>0 & PAT>0 ST+PAT<=MT<=MMT
Y
MT can be N
Minimum possible values
MT=0 dynamically
changed later. Y
ST>0 & PAT=0 PAT=MT-ST
SGA & PGA N

Y
ST>0 are separately
Y
autotuned ST=0 & PAT>0 ST=min(MT-PAT,SMS)
bl e
N
fe r a
Only PGA N ans
is auto tuned
n - t r
SGA and PGA cannot
ST=60%MT
PAT=40%MT a no
a s
grow and shrink automatically.
) h i d eฺ
m u and shrink automatically.
o PGAtcanGgrow
cand
Both SGA
i l ฺ
g ma tuden
sy se th
a
(M to u
Automatic Memory Parameter k i
u nse Dependency
s y
The flowchartM inathe slide
l i c e
describes the relationships between the various memory sizing
y
le Legend: On the graphic use the following to translate abbreviations to the
parameters.
t a n
parameters’ names:
S
• MT = MEMORY_TARGET
• MMT = MEMORY_MAX_TARGET
• ST = SGA_TARGET
• PAT = PGA_AGGREGATE_TARGET
• SMS = SGA_MAX_SIZE
If MEMORY_TARGET is set to a nonzero value:

• If SGA_TARGET and PGA_AGGREGATE_TARGET are set, they are considered to be the
minimum values for the sizes of SGA and the PGA, respectively. MEMORY_TARGET can
take values from SGA_TARGET + PGA_AGGREGATE_TARGET to MEMORY_MAX_SIZE.
• If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, you still autotune both
parameters. PGA_AGGREGATE_TARGET is initialized to a value of (MEMORY_TARGET-
SGA_TARGET).
• If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not set, you still autotune both
parameters. SGA_TARGET is initialized to a value of min(MEMORY_TARGET-
PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will autotune
subcomponents.
Automatic Memory Parameter Dependency (continued)

• If neither is set, they are autotuned without any minimum or default values. The total server
memory is distributed in a fixed ratio to the SGA and PGA during initialization. The policy
is to give 60% for SGA and 40% for PGA at startup.
If MEMORY_TARGET is not set or is set to 0 explicitly (default value is 0):
• If SGA_TARGET is set, the database autotunes only the sizes of the subcomponents of the
SGA. PGA is autotuned independent of whether it is explicitly set or not. However, the
whole SGA(SGA_TARGET) and the PGA (PGA_AGGREGATE_TARGET) are not
autotuned, that is, do not grow or shrink automatically. If neither SGA_TARGET nor
PGA_AGGREGATE_TARGET is set, you follow the same policy as you have today; PGA is
autotuned, SGA is not autotuned, and parameters for some of the subcomponents need to be
set explicitly (for SGA_TARGET).
• If only MEMORY_MAX_TARGET is set, MEMORY_TARGET defaults to 0 in a manual setup
using text initialization file. Autotuning defaults to 10g R2 behavior for SGA and PGA.
• If SGA_MAX_SIZE is not user set, it is set internally to MEMORY_MAX_TARGET if the e
user sets MEMORY_MAX_TARGET (independent of SGA_TARGET being user set). rab
l
s e
fand
In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET
tra n
include a value for MEMORY_TARGET, the database automatically sets n -
MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit a nothe line for
MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, h a s the ฺMEMORY_TARGET
parameter defaults to 0. After startup, you can dynamically m )
change u i de to a
ฺ c o t G MEMORY_TARGET
l ofeMEMORY_MAX_TARGET.
nonzero value, provided that it does not exceed the aivalue n
@ gm Stud
y u ki this
a s se
( M u
y u ki se to
M as licen
le y
n
Sta

Enabling Automatic Memory Management

with EM
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
Enabling Automaticu k
Memory to u
i (M eManagement with EM
s y n s
a liceMemory Management using Enterprise Manager (EM) as shown in
You can enableMAutomatic
l
the slide.
n ey
Stathe Database Home page, click the Server tab. On the Server page, click the Memory
From
Advisors link in the Database Configuration section. This takes you to the Memory Advisors
page. On this page, you can click the Enable button to enable Automatic Memory Management.
The value in the “Total Memory Size for Automatic Memory Management” text box is set by
default to current SGA + PGA size. You can set it to anything more than this but less than the
value in “Maximum Memory Size” box.
Note: On the Memory Advisors page, you can also specify the Maximum Memory Size. If you
change this field, you will be prompted to restart your database for your change to take effect.

Monitor Automatic Memory Management

ble
fe r a
2 ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Monitor Automatic Memory k i
u nsManagement
e
a s y e
After Automatic
y M Memory licManagement is enabled, you can see the graphical representation of
a n le of your memory size components in the Allocation History section of the Memory
the history
S t
Advisors page. The top portion in the first histogram is tunable PGA only and the lower portion
is all of SGA. The top portion in the second histogram is the shared pool size and the lower
portion corresponds to buffer cache.
On this page, you can also access the memory target advisor by clicking the Advice button. This
advisor gives you the possible DB time improvement for various total memory sizes.
Note: You can also look at the memory target advisor using the
V$MEMORY_TARGET_ADVISOR view.

Monitoring Automatic Memory Management
If you want to monitor the decisions made by Automatic

Memory Management via a command line:

• V$MEMORY_DYNAMIC_COMPONENTS has the current status
of all memory components
• V$MEMORY_RESIZE_OPS has a circular history buffer of the
last 800 memory resize requests
• V$MEMORY_TARGET_ADVICE provides tuning advice for the
MEMORY_TARGET initialization parameter e
r a bl
s fe
- t r an
n no
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
sy se th
a
(M to u
Monitoring Automatic k i
u nse Management
Memory
s y
a liceview V$MEMORY_DYNAMIC_COMPONENTS shows the current sizes
The dynamic M performance
l ey
of all dynamically
n tuned memory components, including the total sizes of the SGA and instance
t
PGA. a
S The V$MEMORY_TARGET_ADVICE view provides tuning advice for the MEMORY_
TARGET initialization parameter.
When viewing the V$MEMORY_TARGET_ADVICE view, the row with the
MEMORY_SIZE_FACTOR of 1 shows the current size of memory, as set by the
MEMORY_TARGET initialization parameter, and the amount of DB time required to complete the
current workload. In previous and subsequent rows, the results show a number of alternative
MEMORY_TARGET sizes. For each alternative size, the database shows the size factor (the
multiple of the current size), and the estimated DB time to complete the current workload if the
MEMORY_TARGET parameter were changed to the alternative size. Notice that for a total
memory size smaller than the current MEMORY_TARGET size, estimated DB time increases.

Efficient Memory Usage: Guidelines
• Try to fit the SGA into physical memory.

• Tune for a high buffer cache hit ratio, with the following
caveats:
– Even valid and necessary full table scans lower it.
– It is possible that unnecessary repeated reads of the same
blocks are artificially raising it.
• Use the Memory Advisors.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Efficient Memory Usage: k i
u Guidelines
a s y e n se
If possible, it M
y icthe SGA into physical memory, which provides the fastest access.
is best to lfit
a n le the operating system may provide additional virtual memory, that memory, by its
Even though
t
nature,
S can often be swapped out to disk. On some platforms, you can use the LOCK_SGA
initialization parameter to lock the SGA into physical memory. This parameter cannot be used in
conjunction with AMM or ASMM.
When a SQL statement executes, data blocks are requested for reading or writing, or both. This
is considered a logical I/O. As the block is requested, the block is checked to see whether it
already exists in memory. If it is not in memory, it is read from the disk, which is called a
physical I/O. The number of times the block is found already in memory compared to the total
number of logical I/Os is referred to as the buffer cache hit ratio. A higher ratio is usually better
because that means more blocks are being found in memory without incurring disk I/O.
It is not uncommon to have a buffer cache hit ratio above 99% but that does not always mean the
system is well tuned. If there is a query that is executed more often than necessary, and it
constantly requests the same blocks over and over again, the ratio is raised. If it is an inefficient
or unnecessary query, then it artificially inflates the ratio. This is because it should not execute
in that manner or that often in the first place.

Efficient Memory Usage: Guidelines (continued)

Also, consider the fact that large full table scans (a full reading of the entire table) can lower this
ratio because the entire table may be read from the disk; the scan may not take advantage of the
fact that some of the blocks may be in the buffer cache. So, if there are some necessary large full
table scans in your application, your well-tuned database may always have a low database buffer
cache hit ratio.
Use Enterprise Manager Memory Advisors. They can help you size the SGA on the basis of the
activity in your particular database.
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Memory Tuning Guidelines

for the Library Cache
• Establish formatting conventions for developers so that SQL
statements match in the cache.

• Use bind variables.
• Eliminate unnecessary duplicate SQL.
• Consider using CURSOR_SHARING.
• Use PL/SQL when possible.
• Cache sequence numbers.
• Pin objects in the library cache. ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
Memory Tuning Guidelines k i
u nsfor e the Library Cache
s y
a whichlicisea part of the shared pool, is where the Oracle database stores all the
The library cache,
M
l
SQL, Java
n eycode, PL/SQL procedures and packages, and control structures such as locks and
Sta cache handles. The code goes into this central location so that it can be shared among all
library
users. The benefit of sharing is that all users can take advantage of any work that is already done
on behalf of SQL. Therefore, tasks such as parsing the statement and determining the data access
path (also known as the “explain plan”) are done only once per statement, no matter how many
times the statement is executed, and no matter how many users execute it. A library cache that is
too small does not have room for all the statements being executed and, therefore, you cannot
take advantage of this sharing of work for some statements. A library cache that is too large
causes a burden on the system just to manage its contents.
A library cache may end up being filled with what appear to be different statements when, in
fact, they are copies of the same statement. A common cause of this is having slightly different
formatting for each statement. There is no match if the string does not compare exactly. Another
cause is the use of literals instead of bind variables. If the only difference between two
statements is literal values, then, in most cases, each of those statement executions and the
overall system would benefit from replacing those literals with bind variables.

Memory Tuning Guidelines for the Library Cache (continued)

The CURSOR_SHARING initialization parameter can be set to have the system automatically
replace literals with bind variables when statements otherwise match. You should typically take
advantage of this setting as a temporary measure until the application is corrected to use bind
variables where appropriate. As with all of these guidelines, the use of this variable can have
other side effects, which you should investigate.
Rather than having the same SQL statement issued from several different places in an
application, put the statement or statements into a stored procedure by using PL/SQL. Then just
call the procedure. This guarantees that the SQL statement is shared because it exists only in one
location. Also, the SQL is already parsed and has an explain plan because it is in an already
compiled stored procedure.
Sequence numbers can be cached. Therefore, if there are some sequences with high activity,
determine a good setting for the cache size and take advantage of it.
You can use the DBMS_SHARED_POOL package to pin objects in the library cache. This
reduces the chance of reloading and recompiling objects. Refer to the PL/SQL Packages andble
Types Reference document for more information about how to use that package. fera
s
- t r an
no n
s a
) h a eฺ
m i d
i l ฺ co nt Gu
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
n le
Sta

Summary

• Describe the memory components in the SGA

• Implement Automatic Memory Management
• Manually configure SGA parameters
• Use automatic PGA memory management
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

Practice 14 Overview: Using AMM to Correct a

Memory Allocation Problem
• Diagnosing a memory allocation problem

• Enabling and implementing Automatic Memory Management
ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
sy se th
a
(M to u
k i
a syu cense
yM li
nle
Sta

ble
fe r a
ans
n - t r
a no
a s
) h i d eฺ
m
co nt Gu
i l ฺ
g ma tude
u k i@ is S
a sy se th
k i (M to u
a syu cense
yM li
nle
Sta

D50079GC12 sg1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D50079GC12 sg1

Uploaded by

Copyright:

Available Formats

Computer Pride Limited

Authors Copyright © 2009, Oracle. All rights reserved.

James Womack Disclaimer

1 Database Architecture and ASM

ASM Fast Mirror Resync Overview 1-43

ASM Scalability and Performance 1-48

2 Configuring for Recoverability

3 Using the RMAN Recovery Catalog

Configuring the Recovery Catalog Database 3-7

Registering a Database in the Recovery Catalog 3-11

5 Using RMAN to Create Backups

Creating a Whole Database Backup 5-6

6 Performing User-Managed Backup and Recovery

Log Group Status: Review 6-8

Recovering from a Lost Index Tablespace 6-13

7 Using RMAN to Perform Recovery

Performing Complete Recovery: Loss of a Noncritical Data File in ARCHIVELOG

Recovering Image Copies 7-7

9 Performing Tablespace Point-in-Time Recovery

nle Monitoring RMAN Sessions 10-5

Controlling Tape Buffer Size with BLKSIZE 10-25

Setting LARGE_POOL_SIZE 10-31

11 Using Flashback Technology

12 Additional Flashback Operations

nle Summary 12-30

13 Diagnosing the Database

Viewing Critical Error Alerts in Enterprise Manager 13-14

Packaging and Uploading Diagnostic Data to Oracle Support 13-19

Oracle Memory Structures 14-4

Large Pool 14-11

nle Monitoring Automatic Memory Management 14-35

15 Managing Database Performance

Oracle Wait Events 15-12

Displaying Service-Related Statistics 15-17

Row Chaining and Migration 16-8

Shrinking Segments 16-12

nle Database Transportation: Considerations 16-39

Specifying Resource Plan Directives 17-13

Setting the Active Session Pool 17-18

19 Administering the Scheduler

NLS Data Conversion with Oracle Utilities 20-30

Database Architecture and ASM

After completing this lesson, you should be able to:

• Describe the Oracle Database architecture

Oracle Database 11g: Administration Workshop II 1 - 2

The Oracle Database

The Oracle Relational Database Management System

(RDBMS) is a database management system that provides an

Oracle Database 11g: Administration Workshop II 1 - 3

Oracle Database Architecture: Overview

SGA Shared pool

Oracle Database 11g: Administration Workshop II 1 - 4

Connecting to the Database

• Connection: Communication between a user process and

Oracle Database 11g: Administration Workshop II 1 - 5

Oracle Database Server Structures

Processes DBWn CKPT LGWR SMON PMON ARCn Others

Oracle Database 11g: Administration Workshop II 1 - 6

Oracle Memory Architecture

Server Server Background

Data Dictionary SGA

Oracle Database 11g: Administration Workshop II 1 - 7

Oracle Memory Structures (continued)