Backup And Recovery User's Guide RMAN 04 PDF 18c Users E83709 02
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 909
| Download | |
| Open PDF In Browser | View PDF |
Oracle® Database
Backup and Recovery User's Guide
18c
E83709-02
April 2018
Oracle Database Backup and Recovery User's Guide, 18c
E83709-02
Copyright © 2003, 2018, Oracle and/or its affiliates. All rights reserved.
Primary Author: Padmaja Potineni
Contributors: K. Weill, L. Ashdown, T. Bednar, A. Beldalker, T. Chien, M. Dilman, S. Fogel, R. Guzman, S.
Haisley, W. Hu, A. Hwang, A. Joshi, V. Krishnaswamy, J. W. Lee, V. Moore, M. Olagappan, V. Panteleenko,
S. Ranganathan, F. Sanchez, V. Srihari, M. Susairaj, M. Stewart, S. Wertheimer, W. Yang, R. Zijlstra
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,
license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.
Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agencyspecific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the
programs, including any operating system, integrated software, any programs installed on the hardware,
and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be
responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
Preface
Audience
xxxiv
Documentation Accessibility
xxxiv
Related Documentation
xxxiv
Conventions
xxxv
Changes in This Release for Backup and Recovery User's Guide
Changes in Oracle Database Release 18c, Version 18.1
xxxvi
Changes in Oracle Database 12c Release 2 (12.2.0.1)
xxxvii
Changes in Oracle Database 12c Release 1 (12.1.0.2)
xl
Changes in Oracle Database 12c Release 1 (12.1.0.1)
xl
Part I
1
Overview of Backup and Recovery
Introduction to Backup and Recovery
1.1
Purpose of Backup and Recovery
1-1
1.1.1
About Data Protection
1-2
1.1.2
About Failures that Require Database Recovery
1-3
1.1.3
About Data Archival
1-4
1.1.4
About Data Transfer
1-4
1.2
Oracle Backup and Recovery Solutions
1-5
1.3
Comparison of Oracle Backup Techniques
1-5
1.4
About Oracle Flashback Technology
1-6
1.4.1
Logical Flashback Features
1-7
1.4.2
Flashback Database
1-8
1.5
About Data Recovery Advisor
1-9
1.6
RMAN and Oracle Enterprise Manager Cloud Control
1-9
1.6.1
About Oracle Enterprise Manager Cloud Control
1-10
1.6.2
Accessing the Database Home Page Using Cloud Control
1-10
1.6.3
Performing Backup and Recovery Tasks with Cloud Control
1-11
iii
1.7
About Zero Data Loss Recovery Appliance
1.7.1
1.8
2
Backup and Recovery Documentation Roadmap
1-12
1-12
1.8.1
Recovery Manager Documentation Roadmap
1-14
1.8.2
User-Managed Backup and Recovery Documentation Roadmap
1-14
Getting Started with RMAN
2.1
Overview of the RMAN Environment
2-1
2.2
Starting RMAN and Connecting to a Database: Quick Start
2-2
2.3
Showing the Default RMAN Configuration
2-4
2.4
Backing Up a Database: Quick Start
2-4
2.5
2.6
2.7
2.4.1
About Typical RMAN Backup Options
2-5
2.4.2
Backing Up a Database in ARCHIVELOG Mode
2-6
2.4.3
Backing Up a Database in NOARCHIVELOG Mode
2-6
2.4.4
Making Incremental Backups: Quick Start
2-7
2.4.5
Making Incrementally Updated Backups
2-8
2.4.6
Validating Database Files and Backups: Quick Start
2-9
2.4.7
Scripting RMAN Operations
Reporting on RMAN Operations: Quick Start
2-10
2-10
2.5.1
Listing Backups: Quick Start
2-11
2.5.2
Reporting on Database Files and Backups: Quick Start
2-12
Maintaining RMAN Backups
2-13
2.6.1
Cross-checking Backups: Quick Start
2-13
2.6.2
Deleting Obsolete Backups: Quick Start
2-13
Diagnosing and Repairing Failures with Data Recovery Advisor: Quick Start
2-14
2.7.1
Listing Failures and Determining Repair Options
2-14
2.7.2
Repairing Failures: Quick Start
2-16
2.8
Rewinding a Database with Flashback Database: Quick Start
2-16
2.9
Restoring and Recovering Database Files: Quick Start
2-17
Part II
3
Using RMAN with Recovery Appliance
1-11
2.9.1
Preparing to Restore and Recover Database Files: Quick Start
2-18
2.9.2
Recovering the Whole Database: Quick Start
2-18
2.9.3
Recovering Tablespaces: Quick Start
2-19
2.9.4
Recovering Individual Data Blocks: Quick Start
2-20
Starting and Configuring RMAN and Flashback Database
Recovery Manager Architecture
3.1
About the RMAN Environment
3-1
3.2
About RMAN Command-Line Client
3-3
iv
3.3
About RMAN Channels
3.3.1
About RMAN Channels and Devices
3-4
3.3.2
About RMAN Automatic and Manual Channels
3-5
3.4
About the RMAN Repository
3-5
3.5
About Media Management Using RMAN
3-6
3.5.1
About RMAN Interaction with a Media Manager
3-7
3.5.2
About RMAN and Oracle Secure Backup
3-7
3.5.3
About the Backup Solutions Program
3-7
3.6
About the Fast Recovery Area
3-8
3.7
About RMAN in a Data Guard Environment
3-8
3.8
3.7.1
About RMAN Configuration in a Data Guard Environment
3-9
3.7.2
About RMAN File Management in a Data Guard Environment
3-9
3.7.2.1
About Interchangeability of Backups in a Data Guard Environment
3.7.2.2
About Association of Backups in a Data Guard Environment
3-10
3.7.2.3
About Accessibility of Backups in a Data Guard Environment
3-10
About RMAN in a Recovery Appliance Environment
3.8.1
4
3-3
Creating RMAN Backups to Recovery Appliance
3-9
3-11
3-11
Starting and Interacting with the RMAN Client
4.1
Starting and Exiting RMAN
4-1
4.2
Making Database Connections with RMAN
4-2
4.2.1
About RMAN Database Connection Types
4-2
4.2.2
About Authentication for RMAN Database Connections
4-2
4.2.2.1
Authentication Using the Operating System
4-3
4.2.2.2
Authentication Using a Password File
4-4
4.2.3
Making Database Connections from the RMAN Prompt
4-5
4.2.4
Making RMAN Database Connections from the Operating System
Command Line
4-6
Making RMAN Connections to a CDB
4-7
4.2.5
4.2.5.1
About Performing Operations on CDBs and PDBs
4-7
4.2.5.2
Restrictions When Connected to a PDB
4-8
4.2.5.3
Connecting as Target to the Root
4-9
4.2.5.4
Connecting as Target to a PDB
4-9
4.2.6
Making RMAN Database Connections Within Command Files
4-10
4.2.7
Connecting RMAN to an Auxiliary Database
4-11
4.2.8
Diagnosing RMAN Connection Problems
4-12
4.2.8.1
Diagnosing Target and Auxiliary Database Connection Problems
4-12
4.2.8.2
Diagnosing Recovery Catalog Connection Problems
4-12
4.3
Specifying the Location of RMAN Output
4-12
4.4
Setting Globalization Support Environment Variables for RMAN
4-13
4.5
Entering RMAN Commands
4-13
v
4.6
4.5.1
Entering RMAN Commands at the RMAN Prompt
4-14
4.5.2
Using Command Files with RMAN
4-14
4.5.3
Entering Comments in RMAN Command Files
4-15
4.5.4
Using Substitution Variables in Command Files
4-15
4.5.5
Checking RMAN Syntax
4-16
4.5.5.1
Checking RMAN Syntax at the Command Line
4-17
4.5.5.2
Checking RMAN Syntax in Command Files
4-17
Using the RMAN Pipe Interface
4.6.1
4.6.2
5
4-18
Executing Multiple RMAN Commands in Succession Through a Pipe:
Example
4-19
Executing RMAN Commands in a Single Job Through a Pipe: Example
4-20
Configuring the RMAN Environment
5.1
About Configuring the Environment for RMAN Backups
5.1.1
Showing and Clearing Persistent RMAN Configurations
5-2
5.1.2
Configuring the Default Device for Backups: Disk or SBT
5-3
5.1.3
Configuring the Default Type for Backups: Backup Sets or Copies
5-4
5.1.4
Configuring Channels
5-5
5.1.4.1
About Channel Configuration
5-5
5.1.4.2
Configuring Channels for Disk
5-5
5.1.4.3
Configuring Parallel Channels for Disk and SBT Devices
5-6
5.1.4.4
Manually Overriding Configured Channels
5-7
5.1.5
5.2
Configuring Control File and Server Parameter File Autobackups
5.1.5.1
Configuring the Control File Autobackup Format
5.1.5.2
Overriding the Configured Control File Autobackup Format
Configuring RMAN to Make Backups to a Media Manager
5-8
5-8
5-10
5-10
5.2.1
Prerequisites for Using a Media Manager with RMAN
5-11
5.2.2
Determining the Location of the Media Management Library
5-11
5.2.3
Configuring Media Management Software for RMAN Backups
5-13
5.2.4
Testing Whether the Media Manager Library Is Integrated Correctly
5-13
5.2.4.1
Testing ALLOCATE CHANNEL on the Media Manager
5-13
5.2.4.2
Testing Backup and Restore Operations on the Media Manager
5-14
5.2.5
5.3
5-1
Configuring SBT Channels for Use with a Media Manager
5-15
5.2.5.1
About Media Manager Backup Piece Names
5-16
5.2.5.2
Configuring Automatic SBT Channels
5-17
Configuring RMAN to Make Backups to Recovery Appliance
5-17
5.3.1
Prerequisites for Using Recovery Appliance
5-18
5.3.2
Steps to Configure RMAN for Backups to Recovery Appliance
5-18
5.3.3
Determining the Location of the Recovery Appliance Backup Module
5-19
5.3.4
Specifying Recovery Appliance Configuration Settings for RMAN
Backups
5-19
vi
5.4
Configuring the Fast Recovery Area
5.4.1
Overview of Files in the Fast Recovery Area
5.4.1.1
5.4.1.2
5.4.2
5-23
5.4.2.2
Considerations When Setting the Location of the Fast Recovery
Area
5-25
Setting the Fast Recovery Area Location and Initial Size
5-25
5.4.3
Disabling the Fast Recovery Area
5-27
5.4.4
Configuring Locations for Control Files and Redo Logs
5-28
5.4.4.1
Configuring Online Redo Log Locations
5-28
5.4.4.2
Configuring Control File Locations
5-28
5.4.4.3
Configuring Archived Redo Log Locations
5-29
Configuring RMAN File Creation in the Fast Recovery Area
Configuring the Backup Retention Policy
5-30
5-30
5.5.1
Configuring a Redundancy-Based Retention Policy
5-31
5.5.2
Configuring a Recovery Window-Based Retention Policy
5-31
5.5.3
Disabling the Retention Policy
5-32
Backup Optimization and the CONFIGURE command
5-32
5.6.1
Overview of Backup Optimization
5-33
5.6.2
Effect of Retention Policies on Backup Optimization for SBT Backups
5-34
5.6.3
About Backup Optimization for SBT Backups with Recovery
Window Retention Policy
5-35
About Backup Optimization for SBT Backups With Redundancy
Retention Policy
5-35
Configuring Backup Optimization
Configuring an Archived Redo Log Deletion Policy
5.7.1
About Archived Redo Log Deletion Policies
5-36
5-37
5-37
5.7.1.1
When the Archived Redo Log Deletion Policy Is Disabled
5-37
5.7.1.2
When the Archived Redo Log Deletion Policy Is Enabled
5-38
5.7.2
6
5-22
5-24
5.6.2.2
5.8
How Oracle Manages Disk Space in the Fast Recovery Area
Considerations When Setting the Size of the Fast Recovery Area
5.6.2.1
5.7
5-22
5.4.2.1
5.4.5
5.6
5-20
Fast Recovery Area with Oracle Managed Files and Automatic
Storage Management
Enabling the Fast Recovery Area
5.4.2.3
5.5
5-20
Enabling an Archived Redo Log Deletion Policy
Configuring RMAN in a Data Guard Environment
5-38
5-39
Configuring the RMAN Environment: Advanced Topics
6.1
Configuring Advanced Channel Options
6-1
6.1.1
About Channel Control Options
6-1
6.1.2
Configuring Specific Channel Parameters
6-2
6.1.2.1
Configuring Specific Channels: Examples
6-3
6.1.2.2
Relationship Between CONFIGURE CHANNEL and Parallelism
Setting
6-3
vii
6.2
Configuring Advanced Backup Options
6.2.1
Configuring the Maximum Size of Backup Sets
6-4
6.2.2
Configuring the Maximum Size of Backup Pieces
6-5
6.2.3
Configuring Backup Duplexing
6-5
6.2.4
Configuring Tablespaces for Exclusion from Whole Database Backups
6-6
6.2.5
Configuring Compression Options
6-7
6.2.5.1
About RMAN Precompression Block Processing
6-7
6.2.5.2
About RMAN Supported Compression Levels
6-8
6.2.6
7
6-4
Configuring Backup Encryption
6-9
6.2.6.1
About Backup Encryption
6-10
6.2.6.2
Configuring RMAN Backup Encryption Modes
6-13
6.2.6.3
Configuring the Backup Encryption Algorithm
6-14
6.3
Configuring Auxiliary Instance Data File Names
6-14
6.4
Configuring the Snapshot Control File Location
6-15
6.4.1
Viewing the Configured Location of the Snapshot Control File
6-15
6.4.2
Setting the Location of the Snapshot Control File
6-15
6.5
Configuring RMAN for Use with a Shared Server
6-16
6.6
Enabling Lost Write Detection
6-17
6.7
Enabling Shadow Lost Write Protection
6-18
Using Flashback Database and Restore Points
7.1
Overview of Flashback Database, Restore Points and Guaranteed Restore
Points
7.1.1
About Flashback Database
7-2
7.1.2
About Flashback Database Window
7-3
7.1.3
Limitations of Flashback Database
7-3
7.1.4
About Normal Restore Points
7-4
7.1.5
About Guaranteed Restore Points
7-5
7.1.5.1
7.1.6
7.2
7-1
Guaranteed Restore Points versus Storage Snapshots
Overview of Restore Points in a Multitenant Environment
7-6
7-6
7.1.6.1
About CDB Restore Points
7-7
7.1.6.2
About Restore Points in PDBs
7-7
7.1.6.3
About the Namespace for PDB Restore Points
7-8
About Logging for Flashback Database and Guaranteed Restore Points
7-9
7.2.1
Guaranteed Restore Points and Fast Recovery Area Space Usage
7.2.2
About Logging for Guaranteed Restore Points with Flashback Logging
Disabled
7-10
About Logging for Flashback Database with Guaranteed Restore Points
Defined
7-11
7.2.3
7-9
7.3
Prerequisites for Flashback Database and Restore Points
7-11
7.4
Using Normal and Guaranteed Restore Points
7-12
viii
7.5
Part III
8
7.4.1
Creating Normal and Guaranteed Restore Points in non-CDBs
7-12
7.4.2
Creating CDB Restore Points
7-13
7.4.3
Creating PDB Restore Points
7-14
7.4.4
Listing Restore Points Using the LIST Command
7-15
7.4.5
Listing Restore Points Using the V$RESTORE_POINT View
7-16
7.4.6
Dropping Restore Points
7-17
Using Flashback Database
7-18
7.5.1
Enabling Flashback Database
7-18
7.5.2
Disabling Flashback Database Logging
7-19
7.5.3
Configuring the Environment for Optimal Flashback Database
Performance
7-20
7.5.4
Monitoring the Effect of Flashback Database on Performance
7-20
7.5.5
About Flashback Writer (RVWR) Behavior with I/O Errors
7-21
Backing Up and Archiving Data
RMAN Backup Concepts
8.1
About Consistent and Inconsistent RMAN Backups
8-1
8.1.1
About Consistent RMAN Backups
8-2
8.1.2
About Inconsistent RMAN Backups
8-2
8.2
About Online Backups and Backup Mode
8-2
8.3
About Backup Sets
8-3
8.3.1
About Backup Sets and Backup Pieces
8-4
8.3.2
About RMAN Block Compression for Backup Sets
8-4
8.3.2.1
About Unused Block Compression
8-5
8.3.2.2
About Null Block Compression
8-5
8.3.3
About Binary Compression for RMAN Backup Sets
8-5
8.3.4
About RMAN Backup Undo Optimization
8-6
8.3.5
About Encryption for RMAN Backup Sets
8-6
8.3.6
About File Names for RMAN Backup Pieces
8-6
8.3.7
About Number and Size of RMAN Backup Pieces
8-7
8.3.8
About Number and Size of RMAN Backup Sets
8-8
8.3.9
About Multiplexed RMAN Backup Sets
8-8
8.3.10
8.4
About RMAN Proxy Copies
About RMAN Image Copies
8-10
8-11
8.4.1
About RMAN-Created Image Copies
8-11
8.4.2
About User-Managed Image Copies
8-12
8.5
About Sparse Backups
8-13
8.6
About Preplugin Backups
8-14
8.7
About Multiple Copies of RMAN Backups
8-14
ix
8.7.1
About Duplexed Backup Sets
8-14
8.7.2
About Backups of RMAN Backups
8-15
8.8
8.7.2.1
Backups of Backup Sets
8-15
8.7.2.2
Backups of Image Copies
8-16
About RMAN Control File and Server Parameter File Autobackups
8.8.1
When RMAN Performs Control File Autobackups
8-17
8.8.2
How RMAN Performs Control File Autobackups
8-18
8.9
About RMAN Incremental Backups
8.9.1
About Multilevel Incremental Backups
8-18
8-19
8.9.1.1
About Differential Incremental Backups
8-19
8.9.1.2
About Cumulative Incremental Backups
8-20
8.9.2
About Block Change Tracking
8-21
8.9.3
About the Incremental Backup Algorithm
8-22
8.9.4
About Recovery with Incremental Backups
8-23
8.9.5
About the Incremental-Forever Backup Strategy for Recovery Appliance
8-23
8.10
9
8-17
About Backup Retention Policies
8-23
8.10.1
About the Recovery Window
8-25
8.10.2
About Backup Redundancy
8-27
8.10.3
About Batch Deletes of Obsolete Backups
8-27
8.10.4
About Backup Retention Policy and Fast Recovery Area Deletion
Rules
8-28
Backing Up the Database
9.1
9.2
Overview of RMAN Backups
9.1.1
Purpose of RMAN Backups
9-1
9.1.2
Basic Concepts of RMAN Backups
9-2
Specifying Backup Output Options
9-2
9.2.1
Specifying the Device Type for an RMAN Backup
9-3
9.2.2
Specifying Backup Set or Copy for an RMAN Backup to Disk
9-3
9.2.3
Specifying a Format for RMAN Backups
9-4
9.2.3.1
9.2.4
9.3
9-1
Specifying Multiple Formats for Disk Backups
Specifying Tags for an RMAN Backup
9-5
9-5
9.2.4.1
About Backup Tags
9-5
9.2.4.2
Specifying Tags for Backup Sets and Image Copies
9-6
9.2.5
Making Compressed Backups
9-7
9.2.6
Specifying Multisection Incremental Backups
9-8
9.2.7
Making Multisection Backups Using Image Copies
9-9
Backing Up Database Files with RMAN
9-10
9.3.1
Backing Up a Whole Database with RMAN
9-10
9.3.2
Backing Up Tablespaces and Data Files with RMAN
9-11
9.3.3
Backing Up Control Files with RMAN
9-12
x
9.4
9.5
9.6
9.7
9.3.3.1
About Manual Backups of the Control File
9-13
9.3.3.2
Making a Manual Backup of the Control File
9-13
9.3.4
Backing Up Server Parameter Files with RMAN
9-15
9.3.5
Backing Up a Database in NOARCHIVELOG Mode
9-15
9.3.6
Creating a Preplugin Backup of the Whole Database
9-16
Backing Up CDBs and PDBs
9.4.1
About Backing Up CDBs and PDBs
9-17
9.4.2
Backing Up a Whole CDB
9-18
9.4.3
Backing Up the Root with RMAN
9-19
9.4.4
Backing Up the Root with Oracle Enterprise Manager Cloud Control
9-19
9.4.5
Backing Up PDBs with RMAN
9-19
9.4.6
Creating Preplugin Backups of PDBs Using RMAN
9-20
9.4.7
Backing Up PDBs with Oracle Enterprise Manager Cloud Control
9-22
9.4.8
Backing Up Tablespaces and Data Files in a PDB
9-22
9.4.9
Example: Creating a Preplugin Backup of a PDB with RMAN
9-23
Backing Up Application Containers
9-24
9.5.1
About Backing Up Application Containers
9-24
9.5.2
Backing Up the Application Root
9-25
9.5.3
Backing Up the Application Root and its Application PDBs
9-25
9.5.4
Backing Up Application PDBs
9-26
Backing Up Sparse Databases with RMAN
9-26
9.6.1
Backing Up a Sparse Database with RMAN
9-27
9.6.2
Backing Up Sparse Tablespaces and Data Files with RMAN
9-28
9.6.3
Backing Up a Sparse CDB with RMAN
9-29
9.6.4
Backing Up a Sparse PDB with RMAN
9-30
Backing Up Archived Redo Logs with RMAN
9-31
9.7.1
9.8
9-17
About Backups of Archived Redo Logs for non-CDBs
9-31
9.7.1.1
About Archived Redo Log Failover
9-31
9.7.1.2
About Online Redo Log Switching
9-32
9.7.2
About Backup of Archived Redo Logs in CDBs
9-33
9.7.3
Backing Up Archived Redo Log Files in non-CDBs
9-33
9.7.4
Backing Up Only Archived Redo Logs That Need Backups in non-CDBs
9-34
9.7.5
Backing Up Archived Redo Logs in CDBs
9-35
9.7.6
Deleting Archived Redo Logs After Backups in non-CDBs
9-36
9.7.7
Deleting Archived Redo Logs After Backups in CDBs
9-37
Making and Updating RMAN Incremental Backups
9-37
9.8.1
Purpose of RMAN Incremental Backups
9-37
9.8.2
Planning an Incremental Backup Strategy
9-38
9.8.3
Making Incremental Backups
9-39
9.8.3.1
9.8.4
Making Incremental Backups of a VSS Snapshot
Incrementally Updating Backups
9-40
9-40
xi
9.8.4.1
Incrementally Updating Backups: Basic Example
9-41
9.8.4.2
Incrementally Updated Backups: Advanced Example
9-43
9.8.5
9.9
Using Block Change Tracking to Improve Incremental Backup
Performance
9.8.5.1
About Block Change Tracking
9-44
9.8.5.2
Enabling and Disabling Block Change Tracking
9-46
9.8.5.3
Disabling Block Change Tracking
9-46
9.8.5.4
Checking Whether Change Tracking Is Enabled
9-47
9.8.5.5
Changing the Location of the Block Change Tracking File
9-47
Making Database Backups for Long-Term Storage
9-48
9.9.1
Purpose of Archival Backups
9-48
9.9.2
Basic Concepts of Archival Backups
9-49
9.9.3
Making an Archival Backup for Long-Term Storage
9-50
9.9.3.1
9.9.4
9.10
Making an Archival Backup
Making a Temporary Archival Backup
Backing Up RMAN Backups
9.10.1
10
9-44
About Backups of RMAN Backups
9-50
9-51
9-52
9-52
9.10.1.1
About Multiple Copies of RMAN Backup Sets
9-52
9.10.1.2
Viewing the Effect of a Backup Retention Policy on Backups of
Backups
9-53
9.10.2
Backing Up Backup Sets with RMAN
9-54
9.10.3
Backing Up Image Copy Backups with RMAN
9-55
Backing Up the Database: Advanced Topics
10.1
Limiting the Size of RMAN Backup Sets
10-1
10.1.1
About Backup Set Size
10-2
10.1.2
Limiting the Size of Backup Sets with BACKUP ... MAXSETSIZE
10-2
10.1.3
Dividing the Backup of a Large Data File into Sections
10-3
10.2
Using Backup Optimization to Skip Files
10-4
10.2.1
Optimizing a Daily Archived Log Backup to a Single Tape: Scenario
10-5
10.2.2
Optimizing a Daily Archived Log Backup to Multiple Media Families:
Scenario
10-5
Creating a Weekly Secondary Backup of Archived Logs: Example
10-6
10.2.3
10.3
Skipping Offline, Read-Only, and Inaccessible Files
10-7
10.4
Duplexing Backup Sets
10-8
10.4.1
Duplexing Backup Sets with CONFIGURE BACKUP COPIES
10-8
10.4.2
Duplexing Backup Sets with BACKUP ... COPIES
10-9
10.5
Making Split Mirror Backups with RMAN
10-10
10.6
Encrypting RMAN Backups
10-11
10.6.1
About RMAN Backup Encryption Settings
10-11
10.6.2
Making Transparent-Mode Encrypted Backups
10-13
xii
10.6.3
Making Password-Mode Encrypted Backups
10-13
10.6.4
Making Dual-Mode Encrypted Backups
10-14
10.7
10-14
10.7.1
About Restartable Backups
10-14
10.7.2
Restarting a Backup After It Partially Completes
10-15
10.8
Managing Backup Windows
10-16
10.8.1
About Backup Windows
10-16
10.8.2
Specifying a Backup Duration
10-16
10.8.3
Permitting Partial Backups in a Backup Window
10-17
10.8.4
Minimizing Backup Load and Duration
10-17
Part IV
11
Restarting RMAN Backups
Managing RMAN Backups
Reporting on RMAN Operations
11.1
Overview of RMAN Reporting
11-1
11.1.1
Purpose of RMAN Reporting
11-1
11.1.2
Basic Concepts of RMAN Reporting
11-1
11.1.3
Reporting in a Data Guard Environment
11-3
11.2
Listing Backups and Recovery-Related Objects
11-3
11.2.1
About the LIST Command
11-4
11.2.2
Listing All Backups and Copies
11-6
11.2.3
Listing Selected Backups and Copies
11-8
11.2.4
Listing Preplugin Backups
11-9
11.2.5
Listing Database Incarnations
11.3
Reporting on Backups and Database Schema
11-10
11-11
11.3.1
About Reports of RMAN Backups
11-11
11.3.2
Reporting on Files Needing a Backup Under a Retention Policy
11-12
11.3.2.1
11.3.2.2
11.3.2.3
Using RMAN REPORT NEED BACKUP with Different Retention
Policies
11-13
Using RMAN REPORT NEED BACKUP with Tablespaces and
Data Files
11-13
Using REPORT NEED BACKUP with Backups on Tape or Disk
Only
11-13
11.3.3
Reporting on Data Files Affected by Unrecoverable Operations
11-14
11.3.4
Reporting on Obsolete Backups
11-14
11.3.5
Reporting on the Database Schema
11-15
11.4
Reporting in CDBs and PDBs
11-16
11.4.1
Reporting in CDBs
11-17
11.4.2
Reporting in PDBs
11-17
11.4.2.1
Listing Backups of Dropped PDBs
11-18
xiii
11.5
Using V$ Views to Query Backup Metadata
11.5.1
Querying Details of Past and Current RMAN Jobs
11-18
11.5.2
Determining the Encryption Status of Backup Pieces
11-20
11.6
Querying Recovery Catalog Views
11.6.1
12
11-18
About Recovery Catalog Views
11-21
11-21
11.6.1.1
About Unique Identifiers for Registered Databases
11-22
11.6.1.2
About Unique Identifiers in a Data Guard Environment
11-22
11.6.2
Querying Catalog Views for the Target DB_KEY or DBID Values
11-23
11.6.3
Querying RC_BACKUP_FILES
11-24
Maintaining RMAN Backups and Repository Records
12.1
Overview of RMAN Backup and Repository Maintenance
12-1
12.1.1
Purpose of Backup and Repository Maintenance
12-1
12.1.2
Basic Concepts of Backup and Repository Maintenance
12-2
12.1.2.1
About Maintenance Commands and RMAN Repository Metadata
12-2
12.1.2.2
12.2
About Maintenance Commands in a Data Guard Environment
Maintaining the Control File Repository
12.2.1
About Control File Records
12.2.1.1
About Fast Recovery Area and Control File Records
12-2
12-4
12-4
12-5
12.2.2
Preventing the Loss of Control File Records
12-6
12.2.3
Protecting the Control File
12-6
12.3
Maintaining the Fast Recovery Area
12-7
12.3.1
Deletion Rules for the Fast Recovery Area
12-7
12.3.2
Monitoring Fast Recovery Area Space Usage
12-8
12.3.3
Managing Space for Flashback Logs in the Fast Recovery Area
12-9
12.3.4
Responding to a Full Fast Recovery Area
12-10
12.3.5
Changing the Fast Recovery Area to a New Location
12-11
12.3.6
Disabling the Fast Recovery Area
12-11
12.3.7
Responding to an Instance Crash During File Creation
12-12
12.4
Updating the RMAN Repository
12.4.1
Crosschecking the RMAN Repository
12-12
12-12
12.4.1.1
About RMAN Crosschecks
12-12
12.4.1.2
Crosschecking All Backups and Copies
12-14
12.4.1.3
Crosschecking Specific Backup Sets and Copies
12-15
12.4.1.4
Crosschecking Preplugin Backups
12-15
12.4.2
Changing the Repository Status of Backups and Copies
12-16
12.4.2.1
Updating a Backup to Status AVAILABLE or UNAVAILABLE
12-16
12.4.2.2
Changing the Status of an Archival Backup
12-17
12.4.2.3
Changing the Status of Backups for Dropped PDBs
12-18
12.4.2.4
Changing the Status of Preplugin Backups
12-18
xiv
12.4.3
About Cataloging Operations
12-19
12.4.3.2
Cataloging User-Managed Data File Copies
12-20
12.4.3.3
Cataloging Backup Pieces
12-20
12.4.3.4
Cataloging All Files in a Disk Location
12-21
12.4.3.5
Cataloging Preplugin Archived Redo Logs
12-22
Removing Records from the RMAN Repository
12-22
12.4.4.1
About Uncataloging Operations in the RMAN Repository
12-22
12.4.4.2
Removing Records for Files Deleted with Operating System
Utilities
12-23
Deleting RMAN Backups and Archived Redo Logs
12.5.1
Overview of Deleting RMAN Backups
12-23
12-23
12.5.1.1
About RMAN Deletion Commands
12-24
12.5.1.2
About Deletion of Archived Redo Logs
12-25
12.5.2
Deleting All Backups and Copies
12-26
12.5.3
Deleting Specified Backups and Copies
12-26
12.5.3.1
Deleting Specified Files with BACKUP ... DELETE
12-28
12.5.4
Deleting Expired RMAN Backups and Copies
12-28
12.5.5
Deleting Obsolete RMAN Backups Based on Retention Policies
12-28
12.5.5.1
DELETE OBSOLETE Behavior When KEEP UNTIL TIME
Expires
12-29
12.5.6
Deleting Backups of Dropped PDBs
12-29
12.5.7
Deleting Preplugin Backups
12-29
12.6
13
12-19
12.4.3.1
12.4.4
12.5
Adding Backup Records to the RMAN Repository
Dropping a Database
12-30
Managing a Recovery Catalog
13.1
Overview of the RMAN Recovery Catalog
13-1
13.1.1
Purpose of the RMAN Recovery Catalog
13-1
13.1.2
Basic Concepts for the RMAN Recovery Catalog
13-2
13.1.2.1
About Database Registration in an RMAN Recovery Catalog
13-2
13.1.2.2
About Centralization of Metadata in a Base RMAN Recovery
Catalog
13-3
13.1.2.3
About RMAN Recovery Catalog Resynchronization
13-3
13.1.2.4
About Stored Scripts
13-3
13.1.2.5
Recovery Catalog in a Data Guard Environment
13-4
13.1.3
13.2
Basic Steps of Managing a Recovery Catalog
Creating a Recovery Catalog
13.2.1
Configuring the Recovery Catalog Database
13-4
13-5
13-5
13.2.1.1
Planning the Size of the Recovery Catalog Schema
13-6
13.2.1.2
Allocating Disk Space for the Recovery Catalog Database
13-6
13.2.2
Creating the Recovery Catalog Schema Owner
13-7
xv
13.2.3
13.3
Executing the CREATE CATALOG Command
Registering a Database in the Recovery Catalog
13.3.1
About Registration of a Database in the Recovery Catalog
13.3.1.1
13.3.2
About Standby Database Registration
Registering a Database with the REGISTER DATABASE Command
13-8
13-9
13-9
13-9
13-10
13.4
Cataloging Backups in the Recovery Catalog
13-11
13.5
Creating and Managing Virtual Private Catalogs
13-12
13.5.1
Overview of Virtual Private Catalogs
13-12
13.5.2
About Using the VPD Model for Virtual Private Catalogs
13-12
13.5.3
Creating Virtual Private Catalogs
13-13
13.5.4
Registering a Database with a Virtual Private Catalog
13-15
13.5.5
Revoking Privileges from a Virtual Private Catalog Owner
13-15
13.5.6
Upgrading Virtual Private Catalogs
13-16
13.6
Protecting the Recovery Catalog
13.6.1
13-17
13.6.1.1
Backing Up the Recovery Catalog Frequently
13-17
13.6.1.2
Choosing the Appropriate Technique for Physical Backups
13-17
13.6.1.3
Separating the Recovery Catalog from the Target Database
13-18
13.6.1.4
Exporting the Recovery Catalog Data for Logical Backups
13-19
13.6.2
13.7
Backing Up the Recovery Catalog
13-17
Recovering the Recovery Catalog
Managing Stored Scripts
13-19
13-20
13.7.1
About Stored Scripts
13-20
13.7.2
Creating Stored Scripts
13-21
13.7.3
Replacing Stored Scripts
13-22
13.7.4
Executing Stored Scripts
13-22
13.7.5
Creating and Executing Dynamic Stored Scripts
13-23
13.7.6
Printing Stored Scripts
13-24
13.7.7
Listing Stored Script Names
13-25
13.7.8
Deleting Stored Scripts
13-26
13.7.9
Executing a Stored Script at RMAN Startup
13-26
13.8
Maintaining a Recovery Catalog
13-27
13.8.1
About Recovery Catalog Maintenance
13-27
13.8.2
Resynchronizing the Recovery Catalog
13-27
13.8.2.1
About Resynchronization of the Recovery Catalog
13-27
13.8.2.2
Deciding When to Resynchronize the Recovery Catalog
13-28
13.8.2.3
Manually Resynchronizing the Recovery Catalog
13-31
13.8.3
Updating the Recovery Catalog After Changing a DB_UNIQUE_NAME
13.8.4
Unregistering a Target Database from the Recovery Catalog
13.8.4.1
13.8.4.2
13-31
13-32
Unregistering a Target Database When Not in a Data Guard
Environment
13-32
Unregistering a Standby Database
13-33
xvi
13.8.4.3
13-34
13.8.5
Resetting the Database Incarnation in the Recovery Catalog
13-35
13.8.6
Upgrading the Recovery Catalog
13-36
13.8.6.1
About Recovery Catalog Upgrades
13-37
13.8.6.2
Determining the Schema Version of the Recovery Catalog
13-37
13.8.6.3
Using the UPGRADE CATALOG Command
13-38
13.8.7
13.9
Part V
14
Unregistering a Target Database in a Recovery Appliance
Environment
Importing and Moving a Recovery Catalog
13-39
13.8.7.1
About Recovery Catalog Imports
13-40
13.8.7.2
About Importing Recovery Catalogs in a Recovery Appliance
Environment
13-40
13.8.7.3
Prerequisites for Importing a Recovery Catalog
13-40
13.8.7.4
Importing a Recovery Catalog
13-41
13.8.7.5
Moving a Recovery Catalog
13-42
Dropping a Recovery Catalog
13-42
Diagnosing and Responding to Failures
RMAN Data Repair Concepts
14.1
Overview of RMAN Data Repair
14.1.1
14-1
14.1.1.1
About User Errors
14-1
14.1.1.2
About Application Errors
14-1
14.1.1.3
About Media Failures
14-1
14.1.2
14.2
About Problems Requiring Data Repair
14-1
About RMAN Data Repair Techniques
About RMAN Restore Operations
14-1
14-3
14.2.1
About RMAN Backup Selection
14-3
14.2.2
About RMAN Restore Failover
14-4
14.2.3
About RMAN Restore of Encrypted Backups
14-4
14.2.4
About RMAN Restore Operations and ASM
14-5
14.2.5
About RMAN Restore Optimization
14-6
14.3
About RMAN Media Recovery
14-6
14.3.1
About Selection of Incremental Backups and Archived Redo Logs
14-7
14.3.2
About Database Incarnations
14-7
14.3.2.1
About RMAN OPEN RESETLOGS Operations
14-7
14.3.2.2
Relationship Among Database Incarnations
14-8
14.3.2.3
About Incarnations of PDBs
14-10
14.3.2.4
About Orphaned Backups
14-10
14.3.2.5
About Orphaned PDB Backups
14-10
xvii
15
Diagnosing and Repairing Failures with Data Recovery Advisor
15.1
15-1
15.1.1
Purpose of Data Recovery Advisor
15-1
15.1.2
Basic Concepts of Data Recovery Advisor
15-2
15.1.2.1
User Interfaces to Data Recovery Advisor
15-2
15.1.2.2
About Data Integrity Checks
15-2
15.1.2.3
About Failures
15-3
15.1.2.4
About Manual Actions and Automatic Repair Options
15-5
15.1.2.5
About Supported Database Configurations for Data Recovery
Advisor
15-6
15.1.3
Basic Steps of Diagnosing and Repairing Failures
15-7
15.1.4
Diagnosing and Repairing Failures in CDBs
15-8
15.2
Listing Failures
15-8
15.2.1
Listing All Failures
15-8
15.2.2
Listing a Subset of Failures
15-9
15.3
Checking for Block Corruptions by Validating the Database
15-10
15.4
Determining Repair Options
15-12
15.4.1
Determining Repair Options for All Failures
15-12
15.4.2
Determining Repair Options for a Subset of Failures
15-14
15.5
Repairing Failures
15-15
15.5.1
About Repairing Failures
15-15
15.5.2
Repairing a Failure
15-16
15.6
16
Overview of Data Recovery Advisor
Changing Failure Status and Priority
15-17
Validating Database Files and Backups
16.1
Overview of RMAN Validation
16-1
16.1.1
Purpose of RMAN Validation
16-1
16.1.2
Basic Concepts of RMAN Validation
16-1
16.1.2.1
About Checksums and Corrupt Blocks
16-2
16.1.2.2
About Physical and Logical Block Corruption
16-2
16.1.2.3
About Limits for Corrupt Blocks in RMAN Backups
16-3
16.1.2.4
About Detecting Block Corruption
16-3
16.2
Checking for Block Corruption with the VALIDATE Command
16-4
16.3
Validating Database Files with BACKUP VALIDATE
16-6
16.4
Validating Backups Before Restoring Them
16-8
16.5
Validating CDBs and PDBs
16-9
16.5.1
Validating a Whole CDB
16-9
16.5.2
Validating PDBs
16-9
xviii
17
Performing Complete Database Recovery
17.1
Overview of Complete Database Recovery
17-1
17.1.1
Purpose of Complete Database Recovery
17-1
17.1.2
Scope of This Chapter
17-1
17.1.3
About Real-time Redo Transport for Recovery Appliance
17-2
17.2
Preparing for Complete Database Recovery
17.2.1
Identifying the Database Files to Restore or Recover
17-3
17-3
17.2.1.1
Identifying a Lost Control File
17-3
17.2.1.2
Identifying Data Files Requiring Media Recovery
17-4
17.2.2
Determining the DBID of the Database
17-6
17.2.3
Previewing Backups Used in Restore Operations
17-7
17.2.3.1
Recalling Off-site Backups
17.2.4
Validating Backups Before Restoring Them
17.2.5
Restoring Archived Redo Logs Needed for Recovery
17-9
17-10
17.2.5.1
Restoring Archived Redo Logs to a New Location
17-10
17.2.5.2
Restoring Archived Redo Logs to Multiple Locations
17-11
Providing the Password Required to Decrypt Encrypted Backups
17-11
17.2.6
17.3
17-8
Performing Complete Database Recovery
17.3.1
About Complete Database Recovery
17.3.1.1
About Restoring Data Files to a Nondefault Location
17-12
17-12
17-13
17.3.2
Performing Complete Recovery of the Whole Database
17-13
17.3.3
Performing Complete Recovery of a Tablespace
17-16
17.3.4
Performing Complete Recovery After Switching to a Copy
17-18
17.4
17.3.4.1
Performing Recovery After Switching to a Data File Copy
17-19
17.3.4.2
Performing Complete Recovery After Switching to a Database
Copy
17-20
Performing Complete Recovery of CDBs
17-20
17.4.1
Performing Complete Recovery of a Whole CDB
17-21
17.4.2
Performing Complete Recovery of the Root
17-22
17.4.3
Performing Complete Recovery of PDBs with RMAN
17-23
17.4.4
Performing Complete Recovery of PDBs with Cloud Control
17-25
17.4.5
Performing Complete Recovery Using Preplugin Backups
17-26
17.4.5.1
About Complete Recovery of PDBs Using PrePlugin Backups
17-26
17.4.5.2
Performing Complete Recovery of PDBs Using Preplugin
Backups
17-27
Example: Performing Complete Recovery of PDBs Using
Preplugin Backups
17-28
17.4.5.3
17.4.6
17.4.7
17.4.8
Performing Complete Recovery of Tablespaces or Data Files in a PDB
with RMAN
17-29
Performing Complete Recovery of Tablespaces in a PDB with Cloud
Control
17-31
Performing Complete Recovering of CDBs After Switching to a Copy
17-32
xix
17.5
Performing Complete Recovery of Application Containers
17.5.1
Performing Complete Recovery of the Application Root
17-33
17.5.2
Performing Complete Recovery of the Application Root and Application
PDBs
17-34
Performing Complete Recovery of Application PDBs
17-35
Performing Complete Recovery of Sparse Databases with RMAN
17-36
17.5.3
17.6
18
17-32
17.6.1
Performing Complete Recovery of a Sparse Database
17-36
17.6.2
Performing Complete Recovery of a Sparse CDB
17-37
17.6.3
Performing Recovery of a Sparse PDB with RMAN
17-37
Performing Flashback and Database Point-in-Time Recovery
18.1
Overview of Oracle Flashback Technology and Database Point-in-Time
Recovery
18-1
18.1.1
Purpose of Flashback and Database Point-in-Time Recovery
18-1
18.1.2
Basic Concepts of Point-in-Time Recovery and Flashback Features
18-1
18.1.2.1
Basic Concepts of Database Point-in-Time Recovery for nonCDBs
18-2
18.1.2.2
Basic Concepts of Point-in-Time Recovery for PDBs
18-3
18.1.2.3
Basic Concepts of Flashback Technology
18-3
18.1.3
18.2
Basic Concepts of Performing Flashback Database for CDBs and
PDBs
18-5
18.1.3.1
About Flashback Database and PITR for PDBs
18-6
18.1.3.2
About Undo and Flashback Database Operations for PDBs
18-7
18.1.3.3
About Managing Redo Corruption in CDBs
18-7
Rewinding a Table with Flashback Table
18-8
18.2.1
Prerequisites for Flashback Table
18-8
18.2.2
Performing a Flashback Table Operation
18-9
18.2.2.1
18.3
Keeping Triggers Enabled During Flashback Table
Rewinding a DROP TABLE Operation with Flashback Drop
18-11
18-11
18.3.1
About Flashback Drop
18-12
18.3.2
Prerequisites of Flashback Drop
18-12
18.3.3
Performing a Flashback Drop Operation
18-13
18.3.3.1
18.4
Retrieving Objects Using Flashback Drop When Multiple Objects
Share the Same Original Name
Rewinding a Database with Flashback Database
18-15
18-16
18.4.1
Prerequisites of Flashback Database
18-17
18.4.2
Performing a Flashback Database Operation
18-17
18.4.3
Performing a Flashback Database Operation for a Whole CDB
18-21
18.4.4
Performing a Flashback Database Operation for PDBs
18-24
18.4.5
Monitoring Flashback Database
18-25
18.5
Performing Database Point-in-Time Recovery
18.5.1
Prerequisites of Database Point-in-Time Recovery
18-26
18-26
xx
18.5.2
Performing Database Point-in-Time Recovery
18-27
18.5.3
Performing Point-in-Time Recovery of CDBs and PDBs
18-29
18.5.3.1
Performing Point-in-Time Recovery of a Whole CDB
18-30
18.5.3.2
Performing Point-in-Time Recovery of PDBs
18-31
18.5.4
Performing Point-in-Time Recovery of Application PDBs
18-33
18.5.5
Performing Point-in-Time Recovery of Sparse Databases
18-34
18.6
Flashback and Database Point-in-Time Recovery Scenarios
18.6.1
Rewinding an OPEN RESETLOGS Operation with Flashback
Database
18.6.1.1
18.6.2
18.6.3
19
18-36
18-37
Rewinding the Database to an SCN in an Abandoned Incarnation
Branch
18-37
Recovering the Database to an Ancestor Incarnation
18-39
Performing Block Media Recovery
19.1
Overview of Block Media Recovery
19-1
19.1.1
Purpose of Block Media Recovery
19-1
19.1.2
Basic Concepts of Block Media Recovery
19-2
19.1.2.1
About Block Recovery and Standby Databases
19-2
19.1.2.2
About Identifying Corrupt Blocks
19-3
19.1.2.3
About Missing Redo During Block Recovery
19-4
19.2
Prerequisites for Block Media Recovery
19-5
19.3
Recovering Individual Blocks
19-5
19.3.1
19.3.2
19.4
20
About Undoing an OPEN RESETLOGS on Standby Databases
with Flashback Database
18-36
Recovering Individual Blocks Using the RECOVER...BLOCK
Command
19-6
Example: Recovering Individual Blocks Using the Data Recovery
Advisor
19-6
Recovering All Blocks in V$DATABASE_BLOCK_CORRUPTION
19-8
Performing RMAN Recovery: Advanced Scenarios
20.1
Recovering a NOARCHIVELOG Database with Incremental Backups
20-1
20.2
Restoring the Server Parameter File
20-2
20.2.1
Restoring the Server Parameter File from a Control File Autobackup
20-4
20.2.2
Creating an Initialization Parameter File with RMAN
20-4
20.3
Performing Recovery with a Backup Control File
20.3.1
About Recovery with a Backup Control File
20-5
20-5
20.3.1.1
About Control File Locations During RMAN Restore
20-6
20.3.1.2
About RMAN Recovery With and Without a Recovery Catalog
20-6
20.3.1.3
About RMAN Recovery When Using a Fast Recovery Area
20-7
xxi
20.3.2
20.4
Performing Recovery with a Backup Control File and No Recovery
Catalog
Performing Disaster Recovery
20-10
20.4.1
Prerequisites of Disaster Recovery
20-10
20.4.2
Recovering the Database After a Disaster
20-10
20.5
Restoring a Database on a New Host
20-12
20.5.1
Preparing to Restore a Database on a New Host
20-13
20.5.2
Restoring Disk Backups to a New Host
20-14
20.5.3
Testing the Restore of a Database on a New Host
20-15
20.6
Restoring Backups Created Using Older Versions of RMAN
20-19
20.7
Restoring and Recovering Files Over the Network
20-22
20.7.1
About Restoring Files Over the Network
20-22
20.7.2
About Recovering Files Over the Network
20-23
20.7.3
Scenarios for Restoring and Recovering Files Over the Network
20-23
20.7.4
Restoring Data Files Over the Network
20-24
20.7.5
Rolling Forward a Physical Standby Database Using the RECOVER
Command
20-24
20.7.5.1
21
20-8
Steps to Refresh a Physical Standby Database with Changes
Made to the Primary Database
20-25
Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)
21.1
Overview of RMAN TSPITR
21-1
21.1.1
Purpose of RMAN TSPITR
21-1
21.1.2
Basic Concepts of RMAN TSPITR
21-2
21.2
21.1.2.1
Common Terms for RMAN TSPITR
21-2
21.1.2.2
Modes of RMAN TSPITR
21-3
21.1.2.3
How RMAN TSPITR Works With an RMAN-Managed Auxiliary
Database
21-4
TSPITR Restrictions, Special Cases, and Limitations
21-5
21.2.1
Limitations of TSPITR
21-6
21.2.2
About Special Considerations When Not Using a Recovery Catalog
21-6
21.3
Planning and Preparing for TSPITR
21-7
21.3.1
Selecting the Right Target Time for TSPITR
21-7
21.3.2
Determining the Recovery Set
21-8
21.3.2.1
21.3.3
Identify and Resolve Dependencies on the Primary Database
Identifying and Preserving Objects That Are Lost After TSPITR
21-8
21-9
21.4
Performing Fully Automated RMAN TSPITR
21-10
21.5
Overriding Defaults for RMAN TSPITR with an RMAN-Managed Auxiliary
Database
21-12
21.5.1
Renaming TSPITR Recovery Set Data Files with SET NEWNAME
21-12
21.5.2
Naming TSPITR Auxiliary Set Data Files
21-13
xxii
21.5.2.1
21.5.2.2
21.5.2.3
21.5.3
Using SET NEWNAME to Name Auxiliary Set Data Files During
TSPITR
21-15
Using DB_FILE_NAME_CONVERT to Name Auxiliary Set Data
Files During TSPITR
21-16
21-17
21.5.3.1
Using SET NEWNAME with Recovery Set Image Copies
21-18
21.5.3.2
Using SET NEWNAME and CONFIGURE AUXNAME with
Auxiliary Set Image Copies
21-18
Performing TSPITR with CONFIGURE AUXNAME and Image
Copies: Scenario
21-19
21.5.4
Customizing Initialization Parameters for the Automatic Auxiliary
Database in TSPITR
21.5.4.1
21-20
Specifying the Auxiliary Database Control File Location in
TSPITR
21-21
21.5.4.2
Specifying the Auxiliary Database Archived Logs in TSPITR
21-21
21.5.4.3
Specifying the Auxiliary Database Online Log Location in
TSPITR
21-21
Performing RMAN TSPITR Using Your Own Auxiliary Database
21.6.1
Preparing Your Own Auxiliary Database for RMAN TSPITR
21.6.1.1
21.6.1.2
21.6.1.3
21.6.2
21.6.2.2
21.6.3
21-22
21-22
Step 1: Create an Oracle Password File for the Auxiliary
Database
21-23
Step 2: Create an Initialization Parameter File for the Auxiliary
Database
21-23
Step 3: Check Oracle Net Connectivity to the Auxiliary Database
Preparing RMAN Commands for TSPITR with Your Own Auxiliary
Database
21.6.2.1
21-25
21-25
Planning Channels for TSPITR with Your Own Auxiliary
Database
21-26
Planning Data File Names with Your Own Auxiliary Database:
SET NEWNAME
21-26
Executing TSPITR with Your Own Auxiliary Database
21-26
21.6.3.1
Step 1: Start the Auxiliary Database in NOMOUNT Mode
21-27
21.6.3.2
Step 2: Connect the RMAN Client to Target and Auxiliary
Databases
21-27
Step 3: Execute the RECOVER TABLESPACE Command
21-27
21.6.3.3
21.6.4
21.7
21-14
Using Image Copies for Faster RMAN TSPITR Performance
21.5.3.3
21.6
Considerations When Renaming OMF Auxiliary Set Files in
TSPITR
Performing TSPITR with Your Own Auxiliary Database: Scenario
Troubleshooting RMAN TSPITR
21-28
21-29
21.7.1
Troubleshooting File Name Conflicts During TSPITR
21-30
21.7.2
Troubleshooting the Identification of Tablespaces with Undo Segments
During TSPITR
21-30
Troubleshooting the Restart of a Manual Auxiliary Database After
TSPITR Failure
21-30
21.7.3
xxiii
22
Recovering Tables and Table Partitions
22.1
Overview of Recovering Tables and Table Partitions
22.1.1
Purpose of Recovering Tables and Table Partitions from RMAN
Backups
22-1
22.1.2
RMAN Backups Required to Recover Tables and Table Partitions
22-2
22.1.3
Basic Concepts of Recovering Tables and Table Partitions from RMAN
Backups
22-2
22.1.3.1
Steps Performed By RMAN to Recover Tables and Table
Partitions
22-3
About the Location of Auxiliary Database Files During RMAN
Table Recovery
22-4
About the Data Pump Export Dump File Used During RMAN
Table Recovery
22-5
About Importing Recovered Tables and Table Partitions into the
Target Database
22-5
About Renaming Recovered Tables and Table Partitions During
RMAN Recovery
22-5
About Recovering Tables and Partitions Into a New Schema
22-6
Limitations of Recovering Tables and Table Partitions from RMAN
Backups
22-7
22.1.3.2
22.1.3.3
22.1.3.4
22.1.3.5
22.1.3.6
22.1.4
22.2
Preparing to Recover Tables and Table Partitions
22.2.1
22.2.2
22-7
Prerequisites for Recovering Tables and Table Partitions from RMAN
Backups
22-8
Determining the Point-in-time to Which Tables and Table Partitions
Must be Recovered
22-8
22.3
Recovering Tables and Table Partitions
22.4
Recovering Tables and Table Partitions in PDBs
22-10
22.5
Examples: Recovering Tables and Table Partitions From RMAN Backups
22-11
22-9
22.5.1
Example: Recovering Tables to a Specified Point in Time
22-11
22.5.2
Example: Recovering Table Partitions to a Specified Log Sequence
Number
22-12
Example: Recovering a Table into a New Schema
22-12
22.5.3
Part VI
23
22-1
Tuning and Troubleshooting
Tuning RMAN Performance
23.1
Purpose of RMAN Performance Tuning
23-1
23.2
Basic Concepts of RMAN Performance Tuning
23-1
23.2.1
Read Phase
23-3
23.2.1.1
Allocation of Input Disk Buffers
23-4
23.2.1.2
Synchronous and Asynchronous Disk I/O
23-5
23.2.1.3
Disk I/O Slaves
23-5
xxiv
23.2.1.4
23-6
23.2.2
Copy Phase
23-6
23.2.3
Write Phase for System Backup Tape (SBT)
23-7
23.2.3.1
RMAN Component of the Write Phase for SBT
23.2.3.2
Media Manager Component of the Write Phase for SBT
23.2.4
23.3
Write Phase for Disk
Using V$ Views to Diagnose RMAN Performance Problems
23-7
23-10
23-11
23-12
23.3.1
Monitoring RMAN Job Progress with V$SESSION_LONGOPS
23-12
23.3.2
Identifying Bottlenecks with V$BACKUP_SYNC_IO and
V$BACKUP_ASYNC_IO
23-14
23.4
23.3.2.1
Identifying Bottlenecks with Synchronous I/O
23-15
23.3.2.2
Identifying Bottlenecks with Asynchronous I/O
23-15
Tuning RMAN Backup Performance
23-16
23.4.1
Removing the RATE Parameter from Channel Settings
23-16
23.4.2
Setting DBWR_IO_SLAVES to Simulate Asynchronous I/O
23-17
23.4.3
Setting LARGE_POOL_SIZE to Resolve Shared Memory Issues
23-17
23.4.4
Tuning the Read, Write, and Copy Phases
23-18
23.4.4.1
24
RATE Channel Parameter
Using Backup Validation To Distinguish Between Read and
Write Bottlenecks
23-18
23.4.4.2
Tuning the Read Phase
23-19
23.4.4.3
Tuning the Copy and Write Phases
23-20
Troubleshooting RMAN Operations
24.1
Interpreting RMAN Message Output
24-1
24.1.1
Identifying Types of RMAN Message Output
24-1
24.1.2
Troubleshooting Long-Running RMAN Operations
24-2
24.1.3
Recognizing RMAN Error Message Stacks
24-3
24.1.4
Identifying RMAN Error Codes
24-3
24.1.4.1
RMAN Error Message Numbers
24-4
24.1.4.2
ORA-19511: Media Manager Errors
24-5
24.1.5
24-7
24.1.5.1
Interpreting RMAN Errors: Example
24-7
24.1.5.2
Interpreting Server Errors: Example
24-8
24.1.5.3
Interpreting SBT 2.0 Media Management Errors: Example
24-8
24.1.5.4
Interpreting SBT 1.1 Media Management Errors: Example
24-9
24.1.6
24.2
Interpreting RMAN Error Stacks
Identifying RMAN Return Codes
24-9
Using V$ Views for RMAN Troubleshooting
24-10
24.2.1
Monitoring RMAN Interaction with the Media Manager
24-10
24.2.2
Correlating Server Sessions with RMAN Channels
24-11
24.2.2.1
Matching Server Sessions with Channels When One RMAN
Session Is Active
24-12
xxv
24.2.2.2
24.3
Testing the Media Management API
24-12
24-14
24.3.1
Obtaining the sbttest Utility
24-14
24.3.2
Obtaining Online Documentation for the sbttest Utility
24-14
24.3.3
Using the sbttest Utility
24-15
24.4
Terminating an RMAN Command
24-16
24.4.1
Terminating the Session with ALTER SYSTEM KILL SESSION
24-16
24.4.2
Terminating the Session at the Operating System Level
24-17
24.4.3
Terminating an RMAN Session That Is Not Responding in the Media
Manager
24-17
Part VII
25
Matching Server Sessions with Channels in Multiple RMAN
Sessions
24.4.3.1
Components of an RMAN Session
24-17
24.4.3.2
Process Behavior During a Suspended Job
24-18
24.4.3.3
Terminating an RMAN Session: Basic Steps
24-18
Transferring Data with RMAN
Duplicating Databases
25.1
Overview of RMAN Database Duplication
25-1
25.1.1
Purpose of Database Duplication
25-1
25.1.2
Basic Concepts of Database Duplication
25-2
25.1.2.1
Initialization Parameters for the Auxiliary Instance
25-3
25.1.2.2
About Parallelizing Backup Set Creation During Active Database
Duplication
25-5
About Encrypting Backup Sets During Active Database
Duplication
25-5
About Compressing Backup Sets During Active Database
Duplication
25-5
25.1.2.3
25.1.2.4
25.1.3
Types of Database Duplication
25-6
25.1.3.1
Overview of Backup-Based Duplication
25-6
25.1.3.2
Techniques for Performing Backup-Based Duplication
25-7
25.1.3.3
Overview of Active Database Duplication
25-9
25.1.3.4
Techniques for Performing Active Database Duplication
25-10
25.1.3.5
Factors that Determine Whether Backup Sets or Image Copies
Are Used for Active Database Duplication
25-12
25.1.4
How RMAN Duplicates a Database
25-12
25.1.5
Contents of a Duplicate Database
25-13
25.1.5.1
About Duplicating a Subset of the Source Database
25-13
25.1.6
About the Destination Host for Database Duplication
25-14
25.1.7
About Duplicate Database File Names
25-15
25.1.8
About Duplicating a Database to a Past Point-in-Time
25-15
xxvi
25.1.9
25.2
Prerequisites for Duplicating a Database
Planning to Duplicate a Database
25-15
25-16
25.2.1
Choosing a Duplication Technique
25-16
25.2.2
Choosing a Strategy for Naming Duplicate Database Files
25-17
25.2.2.1
25.2.2.2
25.2.2.3
Using the Same Names for Database Files in the Source
Database and Duplicate Database
25-17
Using Different Names for the Database Files in the Source
Database and Duplicate Database
25-18
Methods of Generating Database File Names for the Duplicate
Database
25-18
25.2.3
Installing the Oracle Database Software on the Destination Host
25-20
25.2.4
Deciding the State of the Duplicate Database
25-21
25.2.5
Making Backups Accessible to the Duplicate Instance
25-21
25.3
25.2.5.1
Making SBT Backups Accessible to the Auxiliary Instance
25-22
25.2.5.2
Making Disk Backups Accessible to the Auxiliary Instance
25-22
Preparing the Auxiliary Instance
25-24
25.3.1
Creating Directories for the Duplicate Database
25-24
25.3.2
Creating an Initialization Parameter File for the Auxiliary Instance
25-24
25.3.2.1
25.3.2.2
Steps to Create an Initialization Parameter File for the Auxiliary
Instance
25-25
Copying the Server Parameter File from the Source Database
25-27
25.3.3
Creating a Password File for the Auxiliary Instance
25-27
25.3.4
Establishing Oracle Net Connectivity Between the Source Database
and Auxiliary Instance
25-28
25.3.5
Starting the Auxiliary Instance
25-29
25.3.6
Making the Oracle Keystore Available to the Destination Host
25-30
25.4
Duplicating a Database
25-31
25.4.1
Duplicating the Whole Database
25-31
25.4.2
Duplicating a Subset of the Source Database Tablespaces
25-32
25.4.3
Duplicating an Oracle RAC Database
25-34
25.4.4
Duplicating Sparse Databases
25-34
25.4.5
Configuring RMAN Channels for Use in Duplication
25-35
25.4.5.1
Configuring Channels for Backup-based Duplication
25-36
25.4.5.2
Configuring Channels for Active Database Duplication
25-37
25.4.6
Placing the Source Database in a Proper State
25-37
25.4.7
Starting RMAN and Connecting to Databases
25-38
25.4.8
Using the DUPLICATE Command to Duplicate Databases
25-39
25.5
Duplicating CDBs and PDBs
25-40
25.5.1
Duplicating CDBs
25-40
25.5.2
Duplicating Sparse CDBs
25-41
25.5.3
Duplicating PDBs
25-42
25.5.3.1
About Duplicating PDBs
25-43
xxvii
25.5.3.2
Restrictions on Duplicating a PDB to an Existing CDB
25-44
25.5.3.3
Duplicating a PDB to an Existing CDB
25-45
25.5.3.4
Duplicating a PDB to a New CDB
25-46
25.5.3.5
Duplicating Sparse PDBs
25-47
25.5.4
25-48
25.6
Duplicating Databases to Oracle Cloud
25-49
25.7
Duplicating an Oracle Cloud Database as an On-premise Database
25-50
25.8
Restarting DUPLICATE After a Failure
25-52
25.9
Examples: Duplicating Databases
25-53
25.9.1
25.9.2
25.9.3
25.9.4
25.9.5
25.9.6
25.9.7
25.9.8
25.9.9
25.10
26
Duplicating Tablespaces Within a PDB to a New CDB
Example: Duplicating a Database to a Remote ASM Host by Using
Active Database Duplication with Backup Sets
25-53
Example: Duplicating a Database to a Remote Host by Using Active
Database Duplication with Image Copies
25-55
Example: Duplicating a Database to a Remote Host by Using Backupbased Duplication without a Target Connection or Recovery Catalog
25-57
Example: Duplicating a Database to a Remote Host by Using BackupBased Duplication with a Recovery Catalog
25-59
Example: Duplicating a Database to a Remote Host by Using Backupbased Duplication with a Target Connection
25-61
Example: Duplicating a Database to the Local Host by Using Active
Database Duplication
25-63
Example: Duplicating PDBs to a New CDB by Using Active Database
Duplication
25-64
Example: Duplicating a PDB to an Existing CDB by Using Active
Duplication
25-66
Example: Performing Backup-based Duplication by Using Encrypted
Backups
25-67
Example: Script to Duplicate a Database Using Backup-based Duplication
25-69
Duplicating Databases: Advanced Topics
26.1
Specifying Alternative Names for Duplicate Database Files
26.1.1
Specifying Non-OMF or Non-ASM Alternative Names for Duplicate
Database Files
26.1.1.1
26.1.1.2
26.1.2
26-1
26-1
Using the SET NEWNAME Command to Name File System
Data Files and Temp Files
26-2
Using the CONFIGURE AUXNAME Command to Name File
System Data Files and OMF or ASM Target Data Files
26-5
Specifying OMF or ASM Alternative Names for Duplicate Database
Files
26-5
26.1.2.1
Settings and Restrictions for OMF Initialization Parameters
26-6
26.1.2.2
Setting Initialization Parameters for ASM
26-7
26.1.2.3
Examples: Duplicating Databases to ASM
26-7
26.1.2.4
Using the SET NEWNAME Command to Create OMF or ASM
Files
26-8
xxviii
26.1.2.5
26.1.2.6
26.2
27
Using the DB_FILE_NAME_CONVERT Parameter to Generate
Names for Non-OMF or ASM Data Files
Using the LOG_FILE_NAME_CONVERT Parameter to Generate
Names for Non-OMF or ASM Log Files
Making Disk Backups Accessible Without Shared Disk
26-9
26-10
26-10
Creating Transportable Tablespace Sets
27.1
Overview of Creating Transportable Tablespace Sets
27-1
27.1.1
Purpose of Creating Transportable Tablespace Sets
27-1
27.1.2
Basic Concepts of Transportable Tablespace Sets
27-2
27.1.3
Basic Steps of Creating Transportable Tablespace Sets
27-4
27.2
Customizing Initialization Parameters for the Auxiliary Instance
27.2.1
27-5
About Setting Initialization Parameters for the RMAN Auxiliary Instance
27-5
27.2.2
Setting the Location of the Auxiliary Instance Parameter File
27.3
Creating a Transportable Tablespace Set
27-7
27.4
Troubleshooting the Creation of Transportable Tablespace Sets
27-9
27.5
Transportable Tablespace Set Scenarios
27-9
27.5.1
Creating a Transportable Tablespace Set at a Specified Time or SCN
27.5.2
Specifying Locations for Data Pump Files
27-10
27.5.3
Specifying Auxiliary File Locations with Transportable Tablespaces
27-11
27-9
27.5.3.1
Using SET NEWNAME for Auxiliary Data Files
27-12
27.5.3.2
Using CONFIGURE AUXNAME for Auxiliary Data Files
27-12
27.5.3.3
Using AUXILIARY DESTINATION to Specify a Location for
Auxiliary Files
27-13
Using Initialization Parameters to Name Auxiliary Files
27-13
27.5.3.4
28
27-6
Transporting Data Across Platforms
28.1
About Cross-Platform Data Transport
28-1
28.1.1
Purpose of Cross-Platform Data Transport
28-1
28.1.2
Methods of Transporting Data Across Platforms
28-2
28.1.3
Platforms that Support Cross-Platform Data Transport
28-2
28.2
Overview of Cross-Platform Data Transport Using Image Copies
28.2.1
28.2.2
28-3
Overview of Tablespace and Data File Conversion Using Image
Copies
28-3
Overview of Database Conversion Using Image Copies
28-4
28.3
Performing Cross-Platform Tablespace Conversion with Image Copies
28-5
28.4
Performing Cross-Platform Data File Conversion with Image Copies
28-7
28.4.1
About Renaming Output Files During RMAN Cross-Platform Data File
Conversion
28-7
xxix
28.4.2
28.5
Performing Tablespace Transportation on the Destination Host Using
RMAN CONVERT DATAFILE
Performing Cross-Platform Database Conversion with Image Copies
28-8
28-10
28.5.1
Checking the Database Before Cross-Platform Database Conversion
28-10
28.5.2
Converting Data Files on the Source Host When Transporting a
Database
28-13
Converting Data Files on the Destination Host When Transporting a
Database
28-16
28.5.3
28.5.3.1
28.5.3.2
28.6
Performing Preliminary Data File Conversion Steps on the
Source Host
28-16
Running the Conversion Scripts on the Destination Host
28-18
Overview of Cross-Platform Data Transport Using Backup Sets
28.6.1
28-20
Basic Terms Used in Cross-Platform Data Transport Using Backup
Sets
28-22
About Backing Up Data on the Source Database for Cross-Platform
Data Transport
28-23
About the Data Pump Export Dump File Used for Cross-Platform
Tablespace Transport
28-24
About Restoring Data on the Destination Host During Cross-Platform
Data Transport
28-24
28.6.5
About Selecting Objects to Be Restored from Cross-Platform Backups
28-25
28.6.6
About Names and Locations for Restored Objects on the Destination
Database
28-26
About Importing the Data Pump Export Dump File Created During
Cross-Platform Tablespace Transport
28-26
28.6.2
28.6.3
28.6.4
28.6.7
28.7
Performing Cross-Platform Database Transport with Backup Sets
28.7.1
28.8
Performing Cross-Platform Transport of Read-Only Tablespaces Using
Backup Sets
28.8.1
28.9
28.10
Steps to Transport a Database to a Different Platform Using Backup
Sets
Steps to Transport Read-Only Tablespaces to a Different Platform
Using Backup Sets
28-28
28-30
28-31
Overview of Cross-Platform Transport of Tablespaces Using Inconsistent
Backups
28-34
Performing Cross-Platform Transport of Tablespaces Using Inconsistent
Backups
28-35
28.10.1
Steps to Transport Inconsistent Tablespaces to a Different Platform
28.10.1.1
28.10.1.2
28.10.1.3
28.10.2
28.11
28-27
28-36
Creating Files Required to Transport Tablespaces to a Different
Platform
28-37
Transferring Files Created on the Source Host to the
Destination Host
28-37
Restoring Tablespaces and Plugging them in to the Destination
Database
28-38
Example: Performing Cross-Platform Inconsistent Tablespace
Transport Using Backup Sets
Performing Cross-Platform Transport of Data Files Over the Network
28-39
28-42
xxx
28.12
Performing Cross-Platform Data Transport in CDBs and PDBs
28.12.1
About Cross-Platform Transport of PDBs
28-43
28.12.2
Performing Cross-Platform Transport of a Whole CDB
28-44
28.12.3
Performing Cross-Platform Transport of a Closed PDB
28-45
28.12.4
Performing Cross-Platform Transport of a PDB Using Inconsistent
Backups
28-46
Performing Cross-Platform Transport of Tablespaces in a PDB
28-49
28.12.5
28.12.5.1
Part VIII
29
28-43
Example: Transporting a Tablespace in a PDB
28-49
Performing User-Managed Backup and Recovery
Making User-Managed Database Backups
29.1
Querying V$ Views to Obtain Backup Information
29-1
29.1.1
Listing Database Files Before a Backup
29-1
29.1.2
Determining Data File Status for Online Tablespace Backups
29-2
29.2
Making User-Managed Backups of the Whole Database
29-3
29.3
Making User-Managed Backups of CDBs and PDBs
29-4
29.4
Making User-Managed Backups of Tablespaces and Data Files
29-5
29.4.1
Making User-Managed Backups of Offline Tablespaces and Data Files
29-5
29.4.2
Making User-Managed Backups of Online Tablespaces and Data Files
29-6
29.4.2.1
29.4.2.2
29.4.2.3
29.4.2.4
29.5
29-7
Making Multiple User-Managed Backups of Online Read/Write
Tablespaces
29-8
Ending a Backup After an Instance Failure or SHUTDOWN
ABORT
29-9
Making User-Managed Backups of Read-Only Tablespaces
29-12
Making User-Managed Backups of Tablespaces in CDBs
29.5.1
29.5.2
29.6
Making User-Managed Backups of Online Read/Write
Tablespaces
29-13
Making User-Managed Backups of Offline Tablespaces and Data Files
in CDBs
29-13
Making User-Managed Backups of Online Tablespaces in CDBs and
PDBs
29-14
Making User-Managed Backups of the Control File
29-14
29.6.1
Backing Up the Control File to a Binary File
29-15
29.6.2
Backing Up the Control File to a Trace File
29-15
29.7
Making User-Managed Backups of Archived Redo Logs
29-16
29.8
Making User-Managed Backups in SUSPEND Mode
29-16
29.8.1
About the Suspend/Resume Feature
29-16
29.8.2
Making Backups in a Suspended Database
29-17
29.9
Making User-Managed Backups to Raw Devices
29.9.1
Backing Up to Raw Devices on Linux and UNIX
29-19
29-19
xxxi
29.9.1.1
29.9.2
30
Backing Up with the dd Utility on Linux and UNIX: Examples
Backing Up to Raw Devices on Windows
29-20
29-21
29.9.2.1
Backing Up with OCOPY: Example
29-21
29.9.2.2
Specifying the -b and -r Options for OCOPY: Example
29-22
29.10
Making Backups with Third-Party Snapshot Technologies
29-22
29.11
Verifying User-Managed Data File Backups
29-23
29.11.1
Testing the Restoration of Data File Backups
29-23
29.11.2
Running the DBVERIFY Utility
29-24
Performing User-Managed Database Flashback and Recovery
30.1
Performing Flashback Database with SQL*Plus
30-1
30.1.1
Performing Flashback Database of non-CDBs with SQL*Plus
30-2
30.1.2
Performing Flashback Database of CDBs with SQL*Plus
30-3
30.1.3
Performing Flashback Database of PDBs with SQL*Plus
30-4
30.2
Overview of User-Managed Media Recovery
30-5
30.2.1
About User-Managed Restore and Recovery
30-5
30.2.2
Automatic Recovery with the RECOVER Command
30-7
30.2.2.1
Automatic Recovery with SET AUTORECOVERY
30-7
30.2.2.2
Automatic Recovery with the AUTOMATIC Option of the
RECOVER Command
30-8
30.2.3
Recovery When Archived Logs Are in the Default Location
30-8
30.2.4
Recovery When Archived Logs Are in a Nondefault Location
30-9
30.2.4.1
Resetting the Archived Log Destination
30-9
30.2.4.2
Overriding the Archived Log Destination
30-10
30.2.5
Recovery Using Storage Snapshot Optimization
30-10
30.2.6
Recovery Cancellation During User-Managed Recovery
30-11
30.2.7
Parallel Media Recovery
30-12
30.3
Performing Complete Database Recovery Using SQL*Plus
30-12
30.3.1
Performing Closed Database Recovery
30-13
30.3.2
Performing Open Database Recovery
30-17
30.3.3
Performing Crash and Instance Recovery of CDBs
30-19
30.4
Performing Incomplete Database Recovery
30-20
30.4.1
Performing Cancel-Based Incomplete Recovery
30-21
30.4.2
Performing Time-Based or Change-Based Incomplete Recovery
30-23
30.5
Recovering a Database in NOARCHIVELOG Mode
30-24
30.6
Troubleshooting Media Recovery
30-25
30.6.1
About User-Managed Media Recovery Problems
30-26
30.6.2
Investigating the Media Recovery Problem: Phase 1
30-28
30.6.3
Trying to Fix the Recovery Problem Without Corrupting Blocks: Phase
2
30-28
xxxii
30.6.4
31
Deciding Whether to Allow Recovery to Mark as Corrupt Blocks: Phase
3
30-30
30.6.5
Allowing Recovery to Corrupt Blocks: Phase 4
30-31
30.6.6
Performing Trial Recovery
30-32
30.6.6.1
How Trial Recovery Works
30-32
30.6.6.2
Executing the RECOVER... TEST Statement
30-33
Performing User-Managed Recovery: Advanced Scenarios
31.1
Responding to the Loss of a Subset of the Current Control Files
31-1
31.1.1
Copying a Multiplexed Control File to a Default Location
31-1
31.1.2
Copying a Multiplexed Control File to a Nondefault Location
31-2
31.2
Recovering After the Loss of All Current Control Files
31-2
31.2.1
Recovering with a Backup Control File in the Default Location
31-3
31.2.2
Recovering with a Backup Control File in a Nondefault Location
31-4
31.2.3
Recovering Through an Added Data File with a Backup Control File
31-6
31.2.4
Recovering Read-Only Tablespaces with a Backup Control File
31-7
31.3
Re-Creating a Control File
31.3.1
Recovering Through a RESETLOGS with a Created Control File
31.3.2
Recovery of Read-Only Files with a Re-Created Control File
31-7
31-9
31-10
31.4
Re-Creating Data Files When Backups Are Unavailable
31-10
31.5
Recovering NOLOGGING Tables and Indexes
31-11
31.6
Recovering Transportable Tablespaces
31-12
31.7
Recovering After the Loss of Online Redo Log Files
31-13
31.7.1
31.7.2
Recovering After Losing a Member of a Multiplexed Online Redo Log
Group
31-13
Recovering After Losing All Members of an Online Redo Log Group
31-14
31.7.2.1
Losing an Inactive Online Redo Log Group
31-15
31.7.2.2
Losing an Active Online Redo Log Group
31-17
31.7.2.3
Loss of Multiple Redo Log Groups
31-18
31.8
Recovering from a Dropped Table Without Using Flashback Features
31-18
31.9
Dropping a Database with SQL*Plus
31-19
Glossary
Index
xxxiii
Preface
Preface
This preface contains the following topics:
•
Audience
•
Documentation Accessibility
•
Related Documentation
•
Conventions
Audience
Backup and Recovery User's Guide is intended for database administrators who
perform the following tasks:
•
Back up, restore, and recover Oracle databases
•
Perform maintenance on backups of database files
•
Transfer data between a file system and Oracle Automatic Storage Management
or between platforms when installing Oracle Database
To use this document, you must know the following:
•
Relational database concepts and basic database administration as described in
Oracle Database Concepts and the Oracle Database Administrator's Guide
•
The operating system environment under which you run the database
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/
lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.
Related Documentation
For more information about backup and recovery, see these Oracle resources:
•
Oracle Database Backup and Recovery Reference
xxxiv
Preface
•
Oracle Database Utilities
•
Oracle Automatic Storage Management Administrator's Guide
You can access information about the Backup Solutions Program (BSP) at
http://www.oracle.com/technetwork/database/features/availability/bsp-088814.html
Many books in the documentation set use the sample schemas of the seed database,
which is installed by default when you install Oracle Database. Refer to Oracle
Database Sample Schemas for information about how these schemas were created
and how you can use them yourself.
Conventions
The following text conventions are used in this document:
Convention
Meaning
boldface
Boldface type indicates graphical user interface elements
associated with an action, or terms defined in text or the
glossary.
italic
Italic type indicates book titles, emphasis, or placeholder
variables for which you supply particular values.
monospace
Monospace type indicates commands within a paragraph,
URLs, code in examples, text that appears on the screen, or
text that you enter.
xxxv
Changes in This Release for Backup and Recovery User's Guide
Changes in This Release for Backup and
Recovery User's Guide
This preface contains:
•
Changes in Oracle Database Release 18c, Version 18.1
•
Changes in Oracle Database 12c Release 2 (12.2.0.1)
•
Changes in Oracle Database 12c Release 1 (12.1.0.2)
•
Changes in Oracle Database 12c Release 1 (12.1.0.1)
Changes in Oracle Database Release 18c, Version 18.1
The following are changes in Oracle Database Backup and Recovery User’s Guide for
Oracle Database release 18c, version 18.1.
New Features
•
Duplicate PDBs into an existing CDB
The DUPLICATE command can be used to duplicate a PDB to an existing CDB.
See Also:
•
–
About Duplicating PDBs
–
Duplicating a PDB to an Existing CDB
Duplicate databases to Oracle Cloud
An on-premise Oracle database can be duplicated to Oracle Cloud Infrastructure
Classic. Similarly, you can duplicate an Oracle database in Oracle Cloud
Infrastructure Classic as an on-premise database.
See Also:
•
–
Duplicating Databases to Oracle Cloud
–
Duplicating an Oracle Cloud Database as an On-premise Database
Roll forward a physical standby
Improvements to the functionality for rolling forward a standby database result in a
simplified procedure for performing this task.
xxxvi
Changes in This Release for Backup and Recovery User's Guide
See Also:
Steps to Refresh a Physical Standby Database with Changes Made to
the Primary Database
•
RMAN backups usable after migration
RMAN backups of a non-CDB or PDB that were created before the non-CDB or
PDB was migrated and plugged in to a different CDB can be used for recovery
operations in the new CDB.
See Also:
•
–
Creating a Preplugin Backup of the Whole Database
–
Creating Preplugin Backups of PDBs Using RMAN
–
Performing Complete Recovery of PDBs Using Preplugin Backups
Shadow lost write protection
Data loss is minimized by fast detection and immediate response to data block lost
rewrites.
See Also:
Enabling Shadow Lost Write Protection
Changes in Oracle Database 12c Release 2 (12.2.0.1)
The following are changes in the Oracle Database Backup and Recovery User’s Guide
for Oracle Database 12c Release 2 (12.2.0.1).
New Features
•
Support for restore points in PDBs
You can create a PDB restore point, which is a restore point that is specific to a
single pluggable database (PDB). Creating a PDB restore point for a particular
PDB ensures that there are no name conflicts with restore points defined for other
PDBs in the multitenant container database (CDB).
xxxvii
Changes in This Release for Backup and Recovery User's Guide
See:
•
–
Overview of Restore Points in a Multitenant Environment
–
Creating CDB Restore Points
–
Creating PDB Restore Points
–
Listing Restore Points Using the V$RESTORE_POINT View
Flashback Database support for PDBs
You can perform a Flashback Database operation for a single PDB without
impacting other PDBs in the multitenant container database (CDB). This enables
you to rewind only the specified PDB, instead of the entire CDB, to a previous
point in time. A Flashback Database operation on a particular PDB does not
impact other PDBs in the CDB.
In Oracle Database 12c Release 1 (12.1), to perform a flashback database
operation for a CDB across PDB point-in-time recovery (PITR), you had to make
all data files in the PDB for which PITR was performed offline. This restriction is
now removed. You can perform a flashback database operation on a CDB across
PDB PITR or PDB flashback with COMPATIBLE set to 12.2 or higher.
See:
•
–
Basic Concepts of Performing Flashback Database for CDBs and
PDBs
–
Performing a Flashback Database Operation for a Whole CDB
–
Performing a Flashback Database Operation for PDBs
–
Performing Flashback Database with SQL*Plus
Enhancements to recovering tables and table partitions
Before performing table recovery, RMAN checks if there is sufficient space on the
target host to create the auxiliary instance that is used during recovery. You can
also recover tables and table partitions into a schema that is different from the
source schema in which they originally existed.
See:
•
–
Steps Performed By RMAN to Recover Tables and Table Partitions
–
About Recovering Tables and Partitions Into a New Schema
–
Example: Recovering a Table into a New Schema
Enhancements to cross-platform transport
xxxviii
Changes in This Release for Backup and Recovery User's Guide
You can perform cross-platform transport of a PDB into a new CDB. Encrypted
tablespaces can be transported across platforms. You can also restore and
recover files across platforms and over the network.
See:
•
–
Performing Cross-Platform Transport of a Closed PDB
–
Performing Cross-Platform Transport of a PDB Using Inconsistent
Backups
–
Steps to Transport Read-Only Tablespaces to a Different Platform
Using Backup Sets
–
Steps to Transport Inconsistent Tablespaces to a Different Platform
–
Performing Cross-Platform Transport of Data Files Over the Network
Enhancements to database duplication
You can use the DUPLICATE command to create an Oracle Data Guard far sync
instance.
See Duplicating the Whole Database.
•
Backup and recovery support for application containers
You can use RMAN to perform backup, complete recovery, and point-in-time
recovery of application containers. This includes the application root and one or
more application PDBs.
See:
•
–
Backing Up Application Containers
–
Performing Complete Recovery of Application Containers
–
Performing Point-in-Time Recovery of Application PDBs
Backup and Recovery of Sparse Databases
RMAN enables you to perform backup, recovery, and backup-based duplication
for sparse databases with the COMPATIBLE initialization parameter set to 12.2 or
higher. You can also backup and recover individual sparse data files, tablespaces,
CDBs, and PDBs.
xxxix
Changes in This Release for Backup and Recovery User's Guide
See:
–
About Sparse Backups
–
Backing Up Sparse Databases with RMAN
–
Performing Complete Recovery of Sparse Databases
–
Performing Point-in-Time Recovery of Sparse Databases
–
Duplicating Sparse Databases
Changes in Oracle Database 12c Release 1 (12.1.0.2)
The following are changes in Backup and Recovery User's Guide for Oracle Database
12c Release 1 (12.1.0.2).
New Features
The following are the new features in this release:
•
Oracle Virtual Private Database (VPD) for RMAN virtual private catalog
The RMAN recovery catalog is created and managed using VPD. This provides
better performance and scalability when a large number of virtual private catalogs
are created.
See:
"Creating and Managing Virtual Private Catalogs"
Changes in Oracle Database 12c Release 1 (12.1.0.1)
The following are changes in Backup and Recovery User's Guide for Oracle Database
12c Release 1 (12.1.0.1).
New Features
The following are new features in this release:
•
Support for multitenant container databases and pluggable databases
RMAN provides backup and recovery of multitenant container databases (CDBs),
which are introduced in Oracle Database 12c Release 1 (12.1). This support
includes backup and point-in-time recovery of specified pluggable databases
(PDBs).
xl
Changes in This Release for Backup and Recovery User's Guide
See:
•
–
"Backing Up CDBs and PDBs"
–
"Performing Point-in-Time Recovery of CDBs and PDBs"
–
"Performing Crash and Instance Recovery of CDBs"
SYSBACKUP Privilege
The SYSBACKUP administrative privilege encompasses the permissions required for
backup and recovery, including the ability to connect to a closed database. System
administrators can grant SYSBACKUP instead of SYSDBA to users who perform backup
and recovery, thus reducing the proliferation of the SYSDBA privilege. In contrast to
SYSDBA, SYSBACKUP does not include data access privileges such as SELECT ANY
TABLE.
See:
"Making Database Connections with RMAN"
•
Storage Snapshot Optimization
Storage Snapshot Optimization enables you to use third-party technologies to take
a storage snapshot of your database without putting the database in BACKUP mode.
You can then use the snapshot to recover all or part of the database.
See:
•
–
"Making Backups with Third-Party Snapshot Technologies"
–
"Recovery Using Storage Snapshot Optimization"
SQL Interface Improvements
You can now issue most SQL commands in RMAN without preceding the
command with the SQL keyword. For a few commands that exist in both RMAN
and SQL and have very different uses, you can specify the SQL keyword to
eliminate ambiguity. You no longer need to enclose the SQL command in quotes,
which greatly simplifies the syntax when the SQL command itself requires
quotation marks. The SQL ALTER command replaces the RMAN command.
The new RMAN DESCRIBE command provides the functionality of the SQL*Plus
DESCRIBE command.
See:
Oracle Database Backup and Recovery Reference
•
Multisection Backup Improvements
xli
Changes in This Release for Backup and Recovery User's Guide
RMAN provides multisection backup support for incremental backups and image
copies. Wherever possible, unused block compression and Block Change
Tracking are used in conjunction with multisection incremental backups. This
improves backup and restore performance.
See:
•
–
"Specifying Multisection Incremental Backups"
–
"Making Multisection Backups Using Image Copies"
Restoring and Recovering Files Over a Network
You can now restore or recover a database, data files, tablespaces, or control files
by using backup sets from a physical standby database. RMAN transfers the
backup sets, over the network, to the destination host. This is useful in a Data
Guard environment when you want to synchronize the standby and primary
databases.
See:
"Restoring and Recovering Files Over the Network"
•
Active Database Duplication Improvements
RMAN can now perform active database duplication using backup sets. When
sufficient auxiliary channels are allocated, the auxiliary instance connects to the
target instance and retrieves the backup sets over the network, thus reducing the
processing load on the target instance. Unused block compression can be used
during the duplication process, thus reducing the size of backups transported over
the network. You can specify the binary compression level to be used. You can
also encrypt backups and use multisection backups while performing active
database duplication.
See:
"About Active Database Duplication with RMAN"
•
Cross-Platform Backup and Restore Improvements
You can transport data across platforms by using full and incremental backup sets.
Incremental backups can reduce overall application downtime during crossplatform data migration.
See:
Transporting Data Across Platforms
•
Recovering Tables and Table Partitions from RMAN Backups
xlii
Changes in This Release for Backup and Recovery User's Guide
RMAN can recover tables and table partitions to a specified point in time from
previously-created RMAN backups.
See:
Recovering Tables and Table Partitions from RMAN Backups
•
Unified auditing and RMAN
Unified auditing consolidates all the Oracle Database audit records into one single
audit trail. To use unified auditing, you must first upgrade your database to Oracle
Database 12c Release 1 (12.1) and then migrate your database to use unified
auditing.
See:
•
–
Oracle Database Upgrade Guide for details about migrating your
database to use unified auditing
–
Oracle Database Security Guide for details about how to locate
RMAN unified auditing information
DUPLICATE enhancements
You can specify that the duplicate database must not be opened using RESETLOGS
after it is created. You may prefer not to open the duplicate database if you want to
change the initialization parameters of the duplicate database or if opening the
duplicate database may start services in the duplicate database that will conflict
with the source database.
See:
"Specifying the State of the Duplicate Database"
xliii
Part I
Overview of Backup and Recovery
The chapters in this part introduce backup and recovery and explain how to devise a
backup and recovery strategy:
•
Introduction to Backup and Recovery
•
Getting Started with RMAN
1
Introduction to Backup and Recovery
This chapter explains Oracle Database backup and recovery and summarizes the
Oracle solutions. This chapter contains the following topics:
•
Purpose of Backup and Recovery
•
Oracle Backup and Recovery Solutions
•
About Oracle Flashback Technology
•
About Data Recovery Advisor
•
RMAN and Oracle Enterprise Manager Cloud Control
•
About Zero Data Loss Recovery Appliance
•
Backup and Recovery Documentation Roadmap
Note:
To get started with Recovery Manager (RMAN) right away, proceed to
Getting Started with RMAN.
1.1 Purpose of Backup and Recovery
As a backup administrator, your principal duty is to devise, implement, and manage a
backup and recovery strategy.
In general, the purpose of a backup and recovery strategy is to protect the database
against data loss and reconstruct the database after data loss. Typically, backup
administration tasks include the following:
•
Planning and testing responses to different kinds of failures
•
Configuring the database environment for backup and recovery
•
Setting up a backup schedule
•
Monitoring the backup and recovery environment
•
Troubleshooting backup problems
•
Recovering from data loss if the need arises
As a backup administrator, you may also be asked to perform other duties that are
related to backup and recovery:
•
Data archival, which involves creating a database copy for long-term storage
•
Data transfer, which involves moving data from one database or one host to
another
The purpose of this manual is to explain how to perform the preceding tasks.
1-1
Chapter 1
Purpose of Backup and Recovery
1.1.1 About Data Protection
As a backup administrator, your primary job is making and monitoring backups for data
protection.
A backup is a copy of data of a database that you can use to reconstruct data. A
backup can be either a physical backup or a logical backup.
Physical backups are copies of the physical files used in storing and recovering a
database. These files include data files, control files, and archived redo logs.
Ultimately, every physical backup is a copy of files that store database information to
another location, whether on disk or on offline storage media such as tape.
Logical backups contain logical data such as tables and stored procedures. You can
use Oracle Data Pump to export logical data to binary files, which you can later import
into the database. The Data Pump command-line clients expdp and impdp use the
DBMS_DATAPUMP and DBMS_METADATA PL/SQL packages.
Physical backups are the foundation of any sound backup and recovery strategy.
Logical backups are a useful supplement to physical backups in many circumstances
but are not sufficient protection against data loss without physical backups.
Unless otherwise specified, the term backup as used in the backup and recovery
documentation refers to a physical backup. Backing up a database is the act of making
a physical backup. The focus in the backup and recovery documentation set is almost
exclusively on physical backups.
Most of this manual focuses on RMAN-based backup and recovery. The most
noteworthy are the following:
•
Incremental backups
An incremental backup stores only blocks changed since a previous backup. Thus,
they provide more compact backups and faster recovery, thereby reducing the
need to apply redo during data file media recovery. If you enable block change
tracking, then you can improve performance by avoiding full scans of every input
data file. You use the BACKUP INCREMENTAL command to perform incremental
backups.
•
Block media recovery
You can repair a data file with only a small number of corrupt data blocks without
taking it offline or restoring it from backup. You use the RECOVER BLOCK command to
perform block media recovery.
•
Binary compression
A binary compression mechanism integrated into Oracle Database reduces the
size of backups.
•
Encrypted backups
RMAN uses backup encryption capabilities integrated into Oracle Database to
store backup sets in an encrypted format. 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.
•
Automated database duplication
1-2
Chapter 1
Purpose of Backup and Recovery
Easily create a copy of your database, supporting various storage configurations,
including direct duplication between ASM databases.
•
Cross-platform data conversion
Whether you use RMAN or user-managed methods, you can supplement physical
backups with logical backups of schema objects made with Data Pump Export utility.
You can later use Data Pump Import to re-create data after restore and recovery.
Logical backups are mostly beyond the scope of the backup and recovery
documentation.
See Also:
•
Backing Up the Database
•
Performing User-Managed Backup and Recovery
1.1.2 About Failures that Require Database Recovery
Although several problems can halt the normal operation of an Oracle Database or
affect database I/O operations, not all of them require DBA intervention.
The following problems typically require DBA intervention and data recovery: media
failure, user errors, and application errors. Other failures may require DBA intervention
without causing data loss or requiring recovery from backup. For example, you may
need to restart the database after an instance failure or allocate more disk space after
statement failure because of a full data file.
Media Failures
A media failure is a physical problem with a disk that causes a failure of a read from or
write to a disk file that is required to run the database. Any database file can be
vulnerable to a media failure. The appropriate recovery technique following a media
failure depends on the files affected and the types of backup available.
One particularly important aspect of backup and recovery is developing a disaster
recovery strategy to protect against catastrophic data loss, for example, the loss of an
entire database host.
User Errors
User errors occur when, either due to an error in application logic or a manual mistake,
data in a database is changed or deleted incorrectly. User errors are estimated to be
the greatest single cause of database downtime.
Data loss due to user error can be either localized or widespread. An example of
localized damage is deleting the wrong person from the employees table. This type of
damage requires surgical detection and repair. An example of widespread damage is
a batch job that deletes the company orders for the current month. In this case, drastic
action is required to avoid a extensive database downtime.
While user training and careful management of privileges can prevent most user
errors, your backup strategy determines how gracefully you recover the lost data when
user error does cause data loss.
1-3
Chapter 1
Purpose of Backup and Recovery
Application Errors
Sometimes a software malfunction can corrupt data blocks. In a physical corruption,
which is also called a media corruption, the database does not recognize the block at
all: the checksum is invalid, the block contains all zeros, or the header and footer of
the block do not match. If the corruption is not extensive, then you can often repair it
easily with block media recovery.
See Also:
Oracle Database Utilities to learn how to use Data Pump
1.1.3 About Data Archival
Data archival, although related to data protection, serves a different purpose. An
archival backup is exempted from the normal backup and recovery strategy. These
backups are typically archived onto separate storage media and retained for long
periods.
For example, you may need to preserve a copy of a database as it existed at the end
of a business quarter. This backup is not part of the disaster recovery strategy. The
media to which these backups are written are often unavailable after the backup is
complete. You may send the tape into fire storage or ship a portable hard drive to a
testing facility. RMAN provides a convenient way to create a backup and exempt it
from your backup retention policy. This type of backup is known as an archival backup.
See Also:
Making Database Backups for Long-Term Storage
1.1.4 About Data Transfer
RMAN backups can be used to transport databases and tablespaces across different
platforms.
In some situations you may need to take a backup of a database or database
component and move it to another location. For example, you can use Recovery
Manager (RMAN) to create a database copy, create a tablespace copy that can be
imported into another database, or move an entire database from one platform to
another. These tasks are not strictly speaking part of a backup and recovery strategy,
but they do require the use of database backups, and so may be included in the duties
of a backup administrator.
See Also:
The chapters in Transferring Data with RMAN
1-4
Chapter 1
Oracle Backup and Recovery Solutions
1.2 Oracle Backup and Recovery Solutions
Oracle provides multiple solutions for performing backup and recovery.
The following solutions are available when implementing a backup and recovery
strategy:
•
Recovery Manager (RMAN)
Recovery Manager is fully integrated with the Oracle Database to perform a range
of backup and recovery activities, including maintaining an RMAN repository of
historical data about backups. You can access RMAN through the command line
or through Oracle Enterprise Manager.
•
Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) provides a graphical
front end and scheduling facilities for RMAN. You enter job parameters, specify a
job schedule, and Cloud Control runs RMAN to conduct the backup and recovery
operations.
•
Zero Data Loss Recovery Appliance (Recovery Appliance)
Recovery Appliance is a cloud-scale Engineered System that provides data
protection for all Oracle Databases in the enterprise. Integrated with RMAN and
Cloud Control, the Recovery Appliance provides a single repository for backups of
multiple databases as described in "About Zero Data Loss Recovery Appliance".
•
User-managed backup and recovery
In this solution, you perform backup and recovery with a mixture of host operating
system commands and SQL*Plus recovery commands. You are responsible for
determining all aspects of when and how backups and recovery are done.
These solutions are supported by Oracle and are fully documented, but RMAN is the
preferred solution for database backup and recovery. RMAN provides a common
interface for backup tasks across different host operating systems, and offers several
backup techniques not available through user-managed methods.
See Also:
"RMAN and Oracle Enterprise Manager Cloud Control"
1.3 Comparison of Oracle Backup Techniques
You can use multiple techniques to create backups of the Oracle Database. This
section compares the Recovery Manager (RMAN), user-managed backups, and Data
Pump techniques.
Table 1-1 summarizes the features of the different backup techniques.
1-5
Chapter 1
About Oracle Flashback Technology
Table 1-1
Feature Comparison of Backup Techniques
Feature
Recovery Manager
User-Managed
Data Pump
Export
Closed database
backups
Supported. Requires instance to be
mounted.
Supported.
Not supported.
Open database
backups
Supported. No need to use
BEGIN/END BACKUP statements.
Supported. Must use BEGIN/END
BACKUP statements.
Requires rollback
or undo
segments to
generate
consistent
backups.
Incremental
backups
Supported.
Not supported.
Not supported.
Corrupt block
detection
Supported. Identifies corrupt blocks
and logs in
V$DATABASE_BLOCK_CORRUPTION.
Not supported.
Supported.
Identifies corrupt
blocks in the
export log.
Automatic
specification of
files to include in
a backup
Supported. Establishes the name
Not supported. Files to be backed up Not applicable.
and locations of all files to be backed must be located and copied
up (whole database, tablespaces,
manually.
data files, control files, and so on).
Backup
repository
Supported. Backups are recorded in
the control file, which is the main
repository of RMAN metadata.
Additionally, you can store this
metadata in a recovery catalog,
which is a schema in a different
database.
Not supported. DBA must keep own
records of backups.
Backups to a
media manager
Supported. Interfaces with a media
management software. RMAN also
supports proxy copy, a feature that
enables a media manager to
manage completely the transfer of
data between disk and backup
media.
Supported. Backup to tape is manual Not supported.
or controlled by a media manager.
Backup of
initialization
parameter file
Supported.
Supported.
Not supported.
Backup of
password and
networking files
Not supported.
Supported.
Not supported.
Platformindependent
language for
backups
Supported.
Not supported.
Supported.
Not supported.
1.4 About Oracle Flashback Technology
Oracle Flashback technology provides a set of features that complements your
physical backup and recovery strategy.
1-6
Chapter 1
About Oracle Flashback Technology
Oracle Flashback Technology provides an additional layer of data protection.
Specifically, you can use the various features of Oracle Flashback to view past states
of data and rewind your database without restoring backups or performing point-intime recovery. In general, flashback features are more efficient and less disruptive
than media recovery in most situations in which they apply.
Oracle Flashback Technology enables you to use the following functionality:
•
Logical Flashback Features
•
Flashback Database
1.4.1 Logical Flashback Features
The logical-level flashback features of Oracle Database do not depend on RMAN and
are available whether or not RMAN is part of your backup strategy.
Most of the flashback features of Oracle operate at the logical level, enabling you to
view and manipulate database objects. Except for Oracle Flashback Drop, the logical
flashback features rely on undo data, which are records of the effects of each
database update and the values overwritten in the update.
Oracle Database includes the following logical flashback features:
•
Oracle Flashback Query
You can specify a target time and run queries against a database, viewing results
as they would appear at the target time. To recover from an unwanted change like
an update to a table, you could choose a target time before the error and run a
query to retrieve the contents of the lost rows. Oracle Database Development
Guide explains how to use this feature.
•
Oracle Flashback Version Query
You can view all versions of all rows that ever existed in one or more tables in a
specified time interval. You can also retrieve metadata about the differing versions
of the rows, including start and end time, operation, and transaction ID of the
transaction that created the version. You can use this feature to recover lost data
values and to audit changes to the tables queried. Oracle Database Development
Guide explains how to use this feature.
•
Oracle Flashback Transaction Query
You can view changes made by a single transaction, or by all the transactions
during a specific time period. Oracle Database Development Guide explains how
to use this feature.
•
Oracle Flashback Transaction
You can reverse a transaction. Oracle Database determines the dependencies
between transactions and in effect creates a 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, had never
happened. Oracle Database Development Guide explains how to use this feature.
•
Oracle Flashback Table
You can recover a table or set of tables to a specified point in time earlier without
taking any part of the database offline. In many cases, Flashback Table eliminates
the need to perform more complicated point-in-time recovery operations.
Flashback Table restores tables while automatically maintaining associated
1-7
Chapter 1
About Oracle Flashback Technology
attributes such as current indexes, triggers, and constraints, and in this way
enabling you to avoid finding and restoring database-specific properties.
"Rewinding a Table with Flashback Table" explains how to use this feature.
•
Oracle Flashback Drop
You can reverse the effects of a DROP TABLE statement. "Rewinding a DROP
TABLE Operation with Flashback Drop" explains how to use this feature.
A flashback data archive enables you to use some logical flashback features to access
data from far back in the past. A flashback data archive consists of one or more
tablespaces or parts of tablespaces. When you create a flashback data archive, you
specify the name, retention period, and tablespace. You can also specify a default
flashback data archive. The database automatically purges old historical data the day
after the retention period expires.
You can turn flashback archiving on and off for individual tables. By default, flashback
archiving is turned off for every table.
See Also:
•
Performing Flashback and Database Point-in-Time Recovery to learn
how to perform Flashback Table and Flashback Drop
•
Oracle Database Development Guide for more information on the logical
flashback features
1.4.2 Flashback Database
Flashback Database enables you to revert an Oracle Database to a previous point in
time.
At the physical level, Oracle Flashback Database provides a more efficient data
protection alternative to database point-in-time recovery (DBPITR). If the current data
files have unwanted changes, then you can use the RMAN command FLASHBACK
DATABASE to revert the data files to their contents at a past time. The end product is
much like the result of a DBPITR, but is generally much faster because it does not
require restoring data files from backup and requires less redo than media recovery.
Flashback Database uses flashback logs to access past versions of data blocks and
some information from archived redo logs. Flashback Database requires that you
configure a fast recovery area for a database because the flashback logs can only be
stored there. Flashback logging is not enabled by default. Space used for flashback
logs is managed automatically by the database and balanced against space required
for other files in the fast recovery area.
Oracle Database also supports restore points along with Flashback Database and
backup and recovery. A restore point is an alias corresponding to a system change
number (SCN). You can create a restore point at any time if you anticipate needing to
return part or all of a database to its contents at that time. A guaranteed restore point
ensures that you can use Flashback Database to return a database to the time of the
restore point.
1-8
Chapter 1
About Data Recovery Advisor
See Also:
"Rewinding a Database with Flashback Database" to learn how to perform
Flashback Database with the FLASHBACK DATABASE command
1.5 About Data Recovery Advisor
The Data Recovery Advisor provides a single point of entry for Oracle backup and
recovery solutions. It is a tool that automatically diagnoses persistent data failures,
presents appropriate repair options, and executes repairs at your request.
You can use the Data Recovery Advisor through Oracle Enterprise Manager or
through the RMAN command-line client.
A database failure usually manifests itself as a set of symptoms: error messages,
alerts, trace files and dumps, and failed data integrity checks. Data Recovery Advisor
automatically diagnoses and informs you of these failures. For Data Recovery Advisor,
a failure is a persistent data corruption that can be directly mapped to a set of repair
actions. Each failure has a status of open or closed. Each failure also has a priority of
critical, high, or low.
Failures are detected by data integrity checks, which are diagnostic procedures
executed to assess the health of the database or its components. If a data integrity
check reveals a failure, then Data Recovery Advisor automatically assesses the effect
of a set of failures and maps it to a set of repair options. Usually, Data Recovery
Advisor presents both automated and manual repair options.
Data Recovery Advisor determines the best automated repair option and its effect on
the database. The repair option may include repairs such as data file restore and
recovery, media recovery, Flashback Database, and so on. Before presenting an
automated repair option, Data Recovery Advisor validates it for the specific
environment and the availability of media components required to complete the
proposed repair.
If you choose an automated repair option, then RMAN coordinates sessions on the
Oracle Database to perform the repair for you. The Data Recovery Advisor tool verifies
the repair success and closes the appropriate failures.
See Also:
Diagnosing and Repairing Failures with Data Recovery Advisor, to learn how
to use Data Recovery Advisor
1.6 RMAN and Oracle Enterprise Manager Cloud Control
RMAN functionality can also be accessed using Oracle Enterprise Manager Cloud
Control.
This section contains:
•
About Oracle Enterprise Manager Cloud Control
1-9
Chapter 1
RMAN and Oracle Enterprise Manager Cloud Control
•
Accessing the Database Home Page Using Cloud Control
•
Performing Backup and Recovery Tasks with Cloud Control
1.6.1 About Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) is a browser-based
management interface for Oracle Database.
Cloud Control provides a graphical front end and scheduling facilities for RMAN. You
enter job parameters, specify a job schedule, and Cloud Control runs RMAN at the
designated time or designated repeat interval to conduct the backup and recovery
operations. Cloud Control provides access to RMAN through a set of wizards. These
wizards lead you through a variety of recovery procedures based on an analysis of
your database, your available backups, and your data recovery objectives.
By using Cloud Control, you can perform the simpler restore and recovery scenarios
outlined in this documentation. You can also use more sophisticated restore and
recovery techniques such as point-in-time recovery and Oracle Flashback operations,
which allow for efficient repair of media failures and user errors. Using Cloud Control is
often simpler than the RMAN command-line client.
To use Cloud Control, you start by accessing the Database Home page as described
in Accessing the Database Home Page Using Cloud Control.
Performing Backup and Recovery Tasks with Cloud Control describes how to use
Cloud Control for backup and recovery.
1.6.2 Accessing the Database Home Page Using Cloud Control
The Database Home page is the main database management page in Oracle
Enterprise Manager Cloud Control (Cloud Control).
After you log in to Cloud Control, you go to the Database Home page for the target
database for backup and recovery tasks.
To access the Database Home page in Cloud Control:
1.
Start Cloud Control.
The URL for accessing Cloud Control has the following syntax:
http://hostname.domain:portnumber/em
Obtain the URL from your Oracle Enterprise Manager administrator or your
database administrator.
2.
On the Welcome page, enter your Cloud Control user name and password, and
then click Login.
3.
From the Targets menu, select Databases.
4.
On the Databases page, if not already selected, select Search List to display a list
of the available target databases.
5.
Select the target database that you want to modify by clicking the database name.
The home page for the target database appears. The first time that you interact
with the database (for example, by selecting from the menu options), the Database
Login page appears.
1-10
Chapter 1
About Zero Data Loss Recovery Appliance
6.
On the login page for the target database, log in as a user with the appropriate
privileges. For example, to log in as user SYS with the SYSDBA privilege:
•
User Name: Enter SYS.
•
Password: Enter the SYS user's password.
•
Connect As: From the list, select Sysdba Role.
1.6.3 Performing Backup and Recovery Tasks with Cloud Control
You can perform a variety of both simple and advanced backup and recovery tasks
with Oracle Enterprise Manager Cloud Control (Cloud Control).
To perform backup and recovery tasks with Cloud Control:
1.
Access the Database Home page for the target database as described in
Accessing the Database Home Page Using Cloud Control.
2.
From the Availability menu, select Backup and Recovery, and then select an
option.
1.7 About Zero Data Loss Recovery Appliance
Zero Data Loss Recovery Appliance (Recovery Appliance) is a cloud-scale
Engineered System that is designed to protect all the Oracle Databases in your
enterprise. It achieves significant efficiencies in performance and manageability of
backups by offloading most Oracle Database backup and restore processing to a
centralized Recovery Appliance.
Recovery Appliance stores and manages backups of multiple databases on a unified
disk pool, using an incremental-forever backup strategy described in "About the
Incremental-Forever Backup Strategy for Recovery Appliance". It continually
compresses, deduplicates, and validates backups at the Oracle block level, while
quickly creating full virtual backups on demand.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for information about the advantages of Recovery Appliance
Multiple client databases—known as protected databases—share a single, centrallymanaged Recovery Appliance catalog that resides on the Recovery Appliance. All
protected databases that send backups to Recovery Appliance must use this catalog.
Virtual private catalog technology enforces separation of duties among the protected
database DBAs and the Recovery Appliance administrator.
Real-time redo transport minimizes the window of potential data loss that exists
between successive archived log backups. Redo data from the protected database is
written directly to the recovery appliance as it is generated.
Recovery Appliance is integrated with Cloud Control and RMAN. An accompanying
media management library is used for communication between RMAN and Recovery
Appliance. Cloud Control enables administrators to centrally manage and monitor the
data protection of all protected databases in the enterprise.
1-11
Chapter 1
Backup and Recovery Documentation Roadmap
Oracle Secure Backup, the tape management component of Recovery Appliance, is
preinstalled on Recovery Appliance. For disaster recovery, Recovery Appliance can
replicate backups to other Recovery Appliances. A single Recovery Appliance can
service multiple protected databases of different versions and from different platforms.
See Also:
•
Zero Data Loss Recovery Appliance Administrator's Guide
•
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide
1.7.1 Using RMAN with Recovery Appliance
You can use most RMAN commands to back up to and recover from Zero Data Loss
Recovery Appliance (Recovery Appliance).
To make backups to Recovery Appliance, you must first set the required configuration
parameters and allocate one or more SBT channels.
See Also:
•
About RMAN in a Recovery Appliance Environment
•
About Real-time Redo Transport for Recovery Appliance
•
About the Incremental-Forever Backup Strategy for Recovery Appliance
•
Configuring RMAN to Make Backups to Recovery Appliance
•
Zero Data Loss Recovery Appliance Protected Databases Configuration
Guide for information about RMAN commands with modified behavior in
Recovery Appliance
1.8 Backup and Recovery Documentation Roadmap
The backup and recovery documentation roadmap is divided into two main paths:
RMAN and user-managed backup and recovery. Optional paths are shown as splitting
off and then rejoining each main path.
Figure 1-1 illustrates the recommended way to navigate the backup and recovery
documentation. You can either implement your backup and recovery strategy with
RMAN, which is recommended, or with user-managed tools.
1-12
Chapter 1
Backup and Recovery Documentation Roadmap
Figure 1-1
Backup and Recovery Documentation Roadmap
Backup and Recovery Concepts
(in Database Concepts)
Introduction to
Backup and Recovery
RMAN
Path
Getting Started
User-Managed
Path
Starting RMAN
Backing Up the Database
Configuring the
RMAN Environment
Performing Database
Flashback and Recovery
Performing Database
Recovery: Advanced
Managing the
Recovery Catalog
Backing Up the Database
End
Reporting on RMAN
Operations
Maintaining RMAN
Backups
Using the Data
Recovery Advisor
Performing Flashback
and DBPITR
Performing Complete
Database Recovery
Performing Block
Media Recovery
Performing Advanced
RMAN Recovery
Tuning RMAN
Performance
End
If you are new to Oracle Database and want to learn about backup recovery, then the
best entry point is the discussion of basic backup and recovery principles in Oracle
Database Concepts.
1-13
Chapter 1
Backup and Recovery Documentation Roadmap
1.8.1 Recovery Manager Documentation Roadmap
This section provides a roadmap for navigating the backup and recovery
documentation when using RMAN as your principal backup and recovery solution.
Begin by reading "Getting Started with RMAN". This brief chapter, which explains the
most basic RMAN techniques, may be adequate for your purposes. For a more
comprehensive explanation of how to implement a backup and recovery strategy with
RMAN, read the chapters in the following order (optional chapters are not listed):
1.
Read " Starting and Interacting with the RMAN Client".
This chapter explains how to start the RMAN client and connect to databases.
2.
Read " Configuring the RMAN Environment".
This chapter explains how to perform basic tasks such as configuring a fast
recovery area, backup retention policy, and archived redo log deletion policy.
3.
Read " Backing Up the Database".
This chapter explains how to implement a basic backup strategy.
4.
Read "Reporting on RMAN Operations".
This chapter explains how to monitor RMAN backup and recovery operations.
Specifically, the chapter explains how to use the reporting commands (LIST,
REPORT, and SHOW) and the relevant V$ and recovery catalog views.
5.
Read " Maintaining RMAN Backups and Repository Records".
This chapter explains how to verify the existence of backups, change the
repository status of backups, delete backups, and perform other maintenance
tasks.
6.
Read " Diagnosing and Repairing Failures with Data Recovery Advisor".
This chapter explains how to use the Data Recovery Advisor tool. You can use it
to list failures, obtain advice about to respond to these failures, and in some cases
automatically repair the failures.
7.
Read " Performing Flashback and Database Point-in-Time Recovery".
This chapter explains how to use the FLASHBACK DATABASE command and perform
point-in-time recovery with the RECOVER DATABASE command.
8.
Read " Performing Complete Database Recovery".
This chapter explains how to recover individual tablespaces or the database.
1.8.2 User-Managed Backup and Recovery Documentation Roadmap
This section provides a roadmap for navigating the backup and recovery
documentation when you do not use RMAN as your principal backup and recovery
solution.
In this case, you must use third-party tools to make your backups and SQL or
SQL*Plus commands to perform recovery. Read the chapters in the following order:
1.
Read Making User-Managed Database Backups.
This chapter explains how to make backups with third-party tools.
1-14
Chapter 1
Backup and Recovery Documentation Roadmap
2.
Read Performing User-Managed Database Flashback and Recovery.
This chapter explains how to use the SQL statement FLASHBACK DATABASE and to
perform recovery with the SQL*Plus RECOVER command.
3.
Read Performing User-Managed Recovery: Advanced Scenarios.
This chapter explains various recovery scenarios.
1-15
2
Getting Started with RMAN
This chapter is intended for new users who want to start using RMAN right away
without first reading the more detailed chapters in this book. This chapter provides the
briefest possible digest of the most important RMAN concepts and tasks. It is not a
substitute for the rest of the backup and recovery documentation set.
This chapter contains the following topics:
•
Overview of the RMAN Environment
•
Starting RMAN and Connecting to a Database
•
Showing the Default RMAN Configuration
•
Backing Up a Database
•
Reporting on RMAN Operations
•
Maintaining RMAN Backups
•
Diagnosing and Repairing Failures with Data Recovery Advisor
•
Rewinding a Database with Flashback Database
•
Restoring and Recovering Database Files
2.1 Overview of the RMAN Environment
Recovery Manager (RMAN) is an Oracle Database client that performs backup and
recovery tasks on your databases and automates administration of your backup
strategies. It greatly simplifies backing up, restoring, and recovering database files.
The RMAN environment consists of the utilities and databases that play a role in
backing up your data. At a minimum, the environment for RMAN must include the
following components:
•
A target database
An Oracle Database to which RMAN is connected with the TARGET keyword. A
target database is a database on which RMAN is performing backup and recovery
operations. RMAN always maintains metadata about its operations on a database
in the control file of the database. The RMAN metadata is known as the RMAN
repository.
•
The RMAN client
An Oracle Database executable that interprets commands, directs server sessions
to execute those commands, and records its activity in the target database control
file. The RMAN executable is automatically installed with the database and is
typically located in the same directory as the other database executables. For
example, the RMAN client on Linux is located in $ORACLE_HOME/bin.
Some environments use the following optional components:
•
A fast recovery area
2-1
Chapter 2
Starting RMAN and Connecting to a Database: Quick Start
A disk location in which the database can store and manage files related to
backup and recovery. You set the fast recovery area location and size with the
DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters.
•
A media management software
An application required for RMAN to interact with sequential media devices such
as tape libraries. A media manager controls these devices during backup and
recovery, managing the loading, labeling, and unloading of media. Media
management devices are sometimes called SBT (system backup to tape) devices.
•
A recovery catalog
A separate database schema used to record RMAN activity against one or more
target databases. A recovery catalog preserves RMAN repository metadata if the
control file is lost, making it much easier to restore and recover following the loss
of the control file. The database may overwrite older records in the control file, but
RMAN maintains records forever in the catalog unless the records are deleted by
the user.
This chapter explains how to use RMAN in the most basic configuration, which is
without a recovery catalog or media manager.
See Also:
•
Recovery Manager Architecture for a more detailed overview of the
RMAN environment
•
Oracle Database Backup and Recovery Reference for BACKUP command
syntax and semantics
2.2 Starting RMAN and Connecting to a Database: Quick
Start
Before you perform any operations using RMAN, you must connect to a target
database.
The RMAN client is started by issuing the rman command at the command prompt of
your operating system. RMAN displays a prompt for your commands as shown in the
following example:
% rman
RMAN>
RMAN connections to a database are specified and authenticated in the same way as
SQL*Plus connections to a database. The only difference is that RMAN connections to
a target or auxiliary database require either the SYSDBA or SYSBACKUP privilege. Any user
can be granted this privilege.
2-2
Chapter 2
Starting RMAN and Connecting to a Database: Quick Start
Caution:
Good security practice requires that you not enter passwords in plain text on
the command line. Enter passwords in RMAN only when requested by an
RMAN prompt. See Oracle Database Security Guide to learn about
password protection.
You can connect to a database with command-line options or by using the CONNECT
TARGET command. The following example starts RMAN and then connects to a target
database through Oracle Net as user sbu, which is created with the SYSBACKUP privilege.
RMAN prompts for a password.
% rman
RMAN> CONNECT TARGET "sbu@prod AS SYSBACKUP"
target database Password: password
connected to target database: PROD (DBID=39525561)
When using the multitenant architecture, you can connect to the root or to a specified
pluggable database (PDB) as described in "Making RMAN Connections to a CDB".
To quit the RMAN client, enter EXIT at the RMAN prompt:
RMAN> EXIT
Syntax of Common RMAN Command-line Options
RMAN
[ TARGET connectStringSpec
| { CATALOG connectStringSpec }
| LOG ['] filename ['] [ APPEND ]
.
.
.
]...
connectStringSpec::=
['] [userid] [/ [password]] [@net_service_name] [']
The following example appends the output from an RMAN session to a text file
at /tmp/msglog.log
% rman TARGET / LOG /tmp/msglog.log APPEND
See Also:
Starting and Interacting with the RMAN Client, to learn more about starting
and using the RMAN client
2-3
Chapter 2
Showing the Default RMAN Configuration
2.3 Showing the Default RMAN Configuration
The RMAN backup and recovery environment is preconfigured for each target
database. The configuration is persistent and applies to all subsequent operations on
this target database, even if you exit and restart RMAN.
RMAN configuration settings can specify backup devices, set up connections to those
devices (known as channels), set policies affecting backup strategy, and more.
To show the current configuration for a database:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the SHOW ALL command.
For example, enter the command at the RMAN prompt as follows:
RMAN> SHOW ALL;
The output lists the CONFIGURE commands to re-create this configuration.
See Also:
Configuring the RMAN Environment, and Configuring the RMAN
Environment: Advanced Topics, to learn how to configure the RMAN
environment
2.4 Backing Up a Database: Quick Start
Use the BACKUP command to back up files. RMAN backs up data to the configured
default device for the type of backup requested.
By default, RMAN creates backups on disk. If a fast recovery area is enabled, and if
you do not specify the FORMAT parameter (see Table 2-1), then RMAN creates backups
in the recovery area and automatically gives them unique names.
By default, RMAN creates backup sets rather than image copies. A backup set
consists of one or more backup pieces, which are physical files written in a format that
only RMAN can access. A multiplexed backup set contains the blocks from multiple
input files. RMAN can write backup sets to disk or tape.
If you specify BACKUP AS COPY, then RMAN copies each file as an image copy, which is a
bit-for-bit copy of a database file created on disk. Image copies are identical to copies
created with operating system commands like cp on Linux or COPY on Windows, but are
recorded in the RMAN repository and so are usable by RMAN. You can use RMAN to
make image copies while the database is open.
The following sections describe backing up databases in different modes:
•
About Typical RMAN Backup Options
•
Backing Up a Database in ARCHIVELOG Mode
•
Backing Up a Database in NOARCHIVELOG Mode
2-4
Chapter 2
Backing Up a Database: Quick Start
•
Making Incremental Backups
•
Making Incrementally Updated Backups
•
Scripting RMAN Operations
See Also:
•
RMAN Backup Concepts, to learn concepts relating to RMAN backups
•
Backing Up the Database, to learn how to back up database files with
RMAN
•
Oracle Database Backup and Recovery Reference for BACKUP command
syntax and semantics
2.4.1 About Typical RMAN Backup Options
The BACKUP command includes a host of options, parameters, and clauses that control
backup output.
Table 2-1 lists some typical backup options.
Table 2-1
Common Backup Options
Option
Description
Example
FORMAT
Specifies a location and name for backup
BACKUP
pieces and copies. You must use substitution
FORMAT 'AL_
variables to generate unique file names.
%d/%t/%s/%p'
The most common substitution variable is %U,
ARCHIVELOG LIKE
which generates a unique name. Others include '%arc_dest%';
%d for the DB_NAME, %t for the backup set time
stamp, %s for the backup set number, and %p for
the backup piece number.
TAG
Specifies a user-defined string as a label for the
BACKUP
backup. If you do not specify a tag, then RMAN
TAG
assigns a default tag with the date and time.
'weekly_full_db_bkup
Tags are always stored in the RMAN repository
'
in uppercase.
DATABASE
MAXSETSIZE 10M;
See Also:
•
"Specifying Backup Output Options"
•
Oracle Database Backup and Recovery Reference for information about
the format options
2-5
Chapter 2
Backing Up a Database: Quick Start
2.4.2 Backing Up a Database in ARCHIVELOG Mode
If a database runs in ARCHIVELOG mode, then you can back up the database while it is
open.
A backup is called an inconsistent backup if it contains changes after its checkpoint. If
you have the archived redo logs needed to recover the backup, open database
backups are as effective for data protection as consistent backups.
To back up the database and archived redo logs while the database is open:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the BACKUP DATABASE command.
For example, enter the following command at the RMAN prompt to back up the
database and all archived redo log files to the default backup device:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
2.4.3 Backing Up a Database in NOARCHIVELOG Mode
If a database runs in NOARCHIVELOG mode, then the only valid database backup is a
consistent backup.
For the backup to be consistent, the database must be mounted after a consistent
shutdown. Recovery is not specifically required after restoring the backup, but you
would lose any transactions made after the backup. You can recover with archived
logs from a consistent backup to minimize data loss.
To make a consistent database backup:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Shut down the database consistently and then mount it.
For example, enter the following commands to guarantee that the database is in a
consistent state for a backup:
RMAN>
RMAN>
RMAN>
RMAN>
3.
SHUTDOWN IMMEDIATE;
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Run the BACKUP DATABASE command.
For example, enter the following command at the RMAN prompt to back up the
database to the default backup device:
RMAN> BACKUP DATABASE;
The following variation of the command creates image copy backups of all data
files in the database:
RMAN> BACKUP AS COPY DATABASE;
4.
Open the database and resume normal operations.
The following command opens the database:
2-6
Chapter 2
Backing Up a Database: Quick Start
RMAN> ALTER DATABASE OPEN;
2.4.4 Making Incremental Backups: Quick Start
Incremental backups capture block-level changes to a database made after a previous
incremental backup.
If you specify BACKUP INCREMENTAL, then RMAN creates an incremental backup of a
database. Incremental backups are generally smaller and faster to make than full
database backups. Recovery with incremental backups is faster than using redo logs
alone.
The starting point for an incremental backup strategy is a level 0 incremental backup,
which backs up all blocks in the database. An incremental backup at level 0 is identical
in content to a full backup, however, unlike a full backup the level 0 backup is
considered a part of the incremental backup strategy.
A level 1 incremental backup contains only blocks changed after a previous
incremental backup. If no level 0 backup exists in either the current or parent database
incarnation when you run a level 1 backup, then RMAN makes a level 0 backup
automatically.
Note:
You cannot make incremental backups when a NOARCHIVELOG database is
open, although you can make incremental backups when the database is
mounted after a consistent shutdown.
A level 1 backup can be a cumulative incremental backup, which includes all blocks
changed since the most recent level 0 backup, or a differential incremental backup,
which includes only blocks changed since the most recent incremental backup.
Incremental backups are differential by default.
During a restore operation, RMAN will first restore a level 0 backup, then automatically
apply incremental backups and redo logs as needed. This will re-apply the changes
that were made to the database since the start of the backup.
To make incremental backups of the database:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the BACKUP INCREMENTAL command.
The following example creates a level 0 incremental backup to serve as a base for
an incremental backup strategy:
BACKUP INCREMENTAL LEVEL 0 DATABASE;
The following example creates a level 1 cumulative incremental backup:
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
The following example creates a level 1 differential incremental backup:
BACKUP INCREMENTAL LEVEL 1 DATABASE;
2-7
Chapter 2
Backing Up a Database: Quick Start
See Also:
"About RMAN Incremental Backups" for a more detailed conceptual overview
of incremental backups and "Making and Updating RMAN Incremental
Backups"
2.4.5 Making Incrementally Updated Backups
Incrementally updated backups enable you to implement an efficient incremental
forever backup strategy.
The RMAN incrementally updated backup feature has the following main features:
•
The strategy requires a level 0 data file copy as a base. This copy has either a
system-defined or user-defined tag.
•
Periodically, level 1 differential backups are created with the same tag as the level
0 data file copy. The BACKUP FOR RECOVER OF COPY command specifies that an
incremental backup contains only blocks changed since the most recent
incremental backup with the same tag.
•
Periodically, the incremental backups are applied to the level 0 data file copy.
Because the data file copy has been updated with more recent changes, it now
requires less media recovery.
Table 2-2 explains which options to use with FOR RECOVER OF COPY to implement an
incrementally updated backup strategy.
Table 2-2
FOR RECOVER OF COPY Options
BACKUP
Option
Description
Example
FOR RECOVER
OF COPY WITH
TAG
'tag_name'
Use TAG to identify the tag of the data file copy serving as basis
for the backup strategy. RMAN automatically assigns the same
tag to every level 1 backup of this copy.
FOR RECOVER
OF COPY
DATAFILECOPY
FORMAT
'format'
Specifies where RMAN creates the data file copy if a copy does
BACKUP
not exist. If you add a new data file to the database, then you do
INCREMENTAL LEVEL 1
not need to change your script, because RMAN automatically
FOR RECOVER OF COPY
creates the level 0 copy required by the incremental backup
DATAFILECOPY FORMAT
routine.
'/disk2/df1.cpy'
DATABASE;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY
If no level 0 data file copy with the specified tag exists in either
WITH TAG 'incr_update'
the current or parent database incarnation, then RMAN creates a
DATABASE;
level 0 data file copy with the specified tag.
To implement an incrementally updated backup strategy:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the RECOVER COPY and BACKUP INCREMENTAL commands.
The following script, run on a regular basis, is all that is required to implement a
strategy based on incrementally updated backups.
2-8
Chapter 2
Backing Up a Database: Quick Start
RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
See Also:
"Incrementally Updating Backups"
2.4.6 Validating Database Files and Backups: Quick Start
RMAN validation checks a backup to determine whether it can be restored. Validation
also checks for corrupt blocks and missing files.
Use the VALIDATE command to confirm that all database files exist, are in their correct
location, and are free of physical corruption. The CHECK LOGICAL option also checks for
logical block corruption.
To validate database files:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the BACKUP VALIDATE ... command for the desired files.
For example, enter the following commands to validate all database files and
archived redo log files for physical and logical corruption:
BACKUP VALIDATE CHECK LOGICAL
DATABASE ARCHIVELOG ALL;
You can also use the VALIDATE command to check individual data blocks, as shown
in the following example:
VALIDATE DATAFILE 4 BLOCK 10 TO 13;
You can also validate backup sets, as shown in the following example:
VALIDATE BACKUPSET 3;
You specify backup sets by primary key, which is shown in the output of the LIST
BACKUP command.
See Also:
•
Validating Database Files and Backups
•
Oracle Database Backup and Recovery Reference for VALIDATE
command syntax and semantics
2-9
Chapter 2
Reporting on RMAN Operations: Quick Start
2.4.7 Scripting RMAN Operations
RMAN supports the use of command files to manage recurring tasks such as weekly
backups.
A command file is a client-side text file containing RMAN commands, exactly as you
enter them at the RMAN prompt. You can use any file extension.
Stored scripts are an alternative to command files that allow scripts to be available to
any RMAN client that can connect to the target database and its recovery catalog.
To create and run a command file:
1.
Use a text editor to create a command file.
For example, create a command file with the following contents:
# my_command_file.txt
CONNECT TARGET /
BACKUP DATABASE PLUS ARCHIVELOG;
LIST BACKUP;
EXIT;
2.
Start RMAN and then execute the contents of a command file by running the @
command at the RMAN prompt:
@/my_dir/my_command_file.txt
# runs specified command file
You can also start RMAN with a command file to run, as shown here:
% rman @/my_dir/my_command_file.txt
See Also:
•
"Using Command Files with RMAN" to learn more about command files
•
"Using Substitution Variables in Command Files" to learn how to use
substitution variables in command files and pass parameters at run time
2.5 Reporting on RMAN Operations: Quick Start
RMAN can use the information stored in the RMAN repository to generate reports on
backup activities.
Use the RMAN LIST and REPORT commands for reporting on backup operations. Use
the SHOW ALL command to display the current RMAN configuration. In addition, RMAN
provides a comprehensive set of views for generating custom reports.
This section contains the following topics:
•
Listing Backups
•
Reporting on Database Files and Backups
2-10
Chapter 2
Reporting on RMAN Operations: Quick Start
2.5.1 Listing Backups: Quick Start
The LIST BACKUP and LIST COPY commands display information about backups and data
file copies listed in the repository.
For backups, you can control the format of LIST output with the options in Table 2-3
and Table 2-4.
Table 2-3
Option
LIST Options for Backups
Example
Explanation
BY BACKUP LIST BACKUP OF DATABASE BY
BACKUP
Organizes the output by backup set. This is
the default mode of presentation.
BY FILE
LIST BACKUP BY FILE
Lists the backups according to which file was
backed up.
SUMMARY
LIST BACKUP SUMMARY
Displays summary output.
For both backups and copies you have additional options shown in Table 2-4.
Table 2-4
Additional LIST Options
Option
Example
Explanation
EXPIRED
LIST EXPIRED COPY
Lists backups that are recorded in the RMAN
repository but that were not present at the
expected location on disk or tape during the last
CROSSCHECK command. An expired backup may
have been deleted by an operating system utility.
RECOVERAB LIST BACKUP
LE
RECOVERABLE
Lists data file backups or copies that have status
AVAILABLE in the RMAN repository and that can
be restored and recovered.
To list backups and copies:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the LIST command at the RMAN prompt.
You can display specific objects, as in the following examples:
LIST
LIST
LIST
LIST
BACKUP OF DATABASE;
COPY OF DATAFILE 1, 2;
BACKUP OF ARCHIVELOG FROM SEQUENCE 10;
BACKUPSET OF DATAFILE 1;
2-11
Chapter 2
Reporting on RMAN Operations: Quick Start
See Also:
•
"Listing Backups and Recovery-Related Objects" to learn more about the
LIST command
•
Oracle Database Backup and Recovery Reference for LIST command
syntax
2.5.2 Reporting on Database Files and Backups: Quick Start
The REPORT command performs more complex reporting analysis than the LIST
command.
Table 2-5 displays some of the main options of the REPORT command.
Table 2-5
Option
REPORT Options
Example
Explanation
NEED BACKUP REPORT NEED BACKUP
DATABASE
Shows which files need backing up under current
retention policy. Use optional REDUNDANCY and
RECOVERY WINDOW parameters to specify different
criteria.
OBSOLETE
REPORT OBSOLETE
Lists backups that are obsolete under the configured
backup retention policy. Use the optional REDUNDANCY
and RECOVERY WINDOW parameters to override the
default.
SCHEMA
REPORT SCHEMA
Reports the tablespaces and data files in the
database at the current time (default) or a different
time.
UNRECOVERA REPORT UNRECOVERABLE
BLE
Lists all data files for which an unrecoverable
operation has been performed against an object in
the data file since the last backup of the data file.
To generate reports of database files and backups:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the REPORT command at the RMAN prompt.
The following example reports backups that are obsolete according to the currently
configured backup retention policy:
REPORT OBSOLETE;
The following example reports the data files and temp files in the database:
REPORT SCHEMA;
2-12
Chapter 2
Maintaining RMAN Backups
See Also:
"Reporting on Backups and Database Schema" to learn how to use the
REPORT command for RMAN reporting
2.6 Maintaining RMAN Backups
RMAN repository metadata is always stored in the control file of the target database.
The RMAN maintenance commands use this metadata when managing backups.
This section contains the following topics:
•
Cross-checking Backups
•
Deleting Obsolete Backups
2.6.1 Cross-checking Backups: Quick Start
Use the CROSSCHECK command to synchronize the logical records of RMAN backups
and copies with the files on storage media.
If a backup is on disk, then CROSSCHECK determines whether the header of the file is
valid. If a backup is on tape, then RMAN queries the RMAN repository for the names
and locations of the backup pieces. It is a good idea to crosscheck backups and
copies before deleting them.
To crosscheck all backups and copies on disk:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the CROSSCHECK command, as shown in the following example:
CROSSCHECK BACKUP;
CROSSCHECK COPY;
See Also:
"Crosschecking the RMAN Repository" to learn how to crosscheck RMAN
backups
2.6.2 Deleting Obsolete Backups: Quick Start
The DELETE command removes RMAN backups and copies from disk and tape,
updates the status of the files to DELETED in the control file repository, and removes the
records from the recovery catalog (if you use a catalog).
If you run RMAN interactively, and if you do not specify the NOPROMPT option, then
DELETE displays a list of files and prompts for confirmation before deleting any file in the
list. The DELETE OBSOLETE command is particular useful because RMAN deletes
backups and data file copies recorded in the RMAN repository that are obsolete, that
2-13
Chapter 2
Diagnosing and Repairing Failures with Data Recovery Advisor: Quick Start
is, no longer needed. You can use options on the DELETE command to specify what is
obsolete or use the configured backup retention policy.
To delete obsolete backups and copies:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Run the DELETE OBSOLETE command, as shown in the following example:
DELETE OBSOLETE;
See Also:
"Deleting RMAN Backups and Archived Redo Logs" to learn how to use the
DELETE command
2.7 Diagnosing and Repairing Failures with Data Recovery
Advisor: Quick Start
Data Recovery Advisor is an Oracle Database tool that provides an infrastructure for
diagnosing persistent data failures, presenting repair options to the user, and executes
repairs at the user’s request.
This section contains the following topics:
•
Listing Failures and Determining Repair Options
•
Repairing Failures
See Also:
"Overview of Data Recovery Advisor"
2.7.1 Listing Failures and Determining Repair Options
A failure is a persistent data corruption detected by the Health Monitor. Examples
include physical and logical data block corruptions and missing data files.
Each failure has a failure priority and failure status. The priority can be CRITICAL, HIGH,
or LOW. The status can be OPEN or CLOSED.
You can run the LIST FAILURE command to show all known failures. If failures exist,
then run the ADVISE FAILURE command in the same session to determine repair options.
The ADVISE FAILURE output shows both manual and automated repair options. First try
to fix the problem manually. If you cannot fix the problem manually, then review the
automated repair section.
An automated repair option describes a server-managed repair for one or more
failures. Repairs are consolidated when possible so that a single repair can fix multiple
2-14
Chapter 2
Diagnosing and Repairing Failures with Data Recovery Advisor: Quick Start
failures. The repair option indicates which repair is performed and whether data is lost
by performing the repair operation.
See Also:
"Listing Failures" and "Determining Repair Options"
Listing Failures and Determining Repair Options illustrates the commands to list
failures and determine repair options. The output indicates the file name of a repair
script containing RMAN commands. If you do not want to use Data Recovery Advisor
to repair the failure automatically, then you can use the script as the basis of your own
recovery strategy.
Example 2-1
LIST FAILURE and ADVISE FAILURE
RMAN> LIST FAILURE;
Database Role: PRIMARY
List of Database Failures
=========================
Failure ID
---------142
101
Priority
-------HIGH
HIGH
Status
--------OPEN
OPEN
Time Detected
------------23-APR-13
23-APR-13
Summary
------One or more non-system datafiles are missing
Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks
Time Detected
------------23-APR-13
23-APR-13
Summary
------One or more non-system datafiles are missing
Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks
RMAN> ADVISE FAILURE;
Database Role: PRIMARY
List of Database Failures
=========================
Failure ID
---------142
101
Priority
-------HIGH
HIGH
Status
--------OPEN
OPEN
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
------ -----------------1
Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm
2-15
Chapter 2
Rewinding a Database with Flashback Database: Quick Start
2.7.2 Repairing Failures: Quick Start
Use the RMAN REPAIR FAILURE command to repair failures that were detected.
After running LIST FAILURE and ADVISE FAILURE in an RMAN session, you can run
REPAIR FAILURE to execute a repair option. If you execute REPAIR FAILURE with no other
command options, then RMAN uses the first repair option of the most recent ADVISE
FAILURE command in the current session. Alternatively, specify the repair option
number obtained from the most recent ADVISE FAILURE command. The following
example illustrates how to repair the failures identified in Example 2-1.
RMAN> REPAIR FAILURE;
By default, REPAIR FAILURE prompts for confirmation before it begins executing. After
executing a repair, Data Recovery Advisor reevaluates all existing failures on the
possibility that they may also have been fixed. Data Recovery Advisor always verifies
that failures are still relevant and automatically closes fixed failures. If a repair fails to
complete because of an error, then the error triggers a new assessment and reevaluation of existing failures and repairs.
See Also:
"Repairing Failures"
2.8 Rewinding a Database with Flashback Database: Quick
Start
You can use the Oracle Flashback Database to rewind the whole database to a past
time. Unlike media recovery, you do not need to restore data files to return the
database to a past state.
To use the RMAN FLASHBACK DATABASE command, your database must have been
previously configured to generate flashback logs. This configuration task is described
in "About Flashback Database". Flashback Database works by rewinding changes to
the data files that exist at the moment that you run the command. You cannot use the
flashback database to repair media failures or missing data files.
The database must be mounted when you issue FLASHBACK DATABASE. You can
flashback to any time within the flashback database window. If you have previously
created a restore point, that is a convenience, but not required.
To rewind a database with Flashback Database:
1.
Start RMAN and connect to a target database as described in "Starting RMAN and
Connecting to a Database".
2.
Ensure that the database is in a mounted state.
The following commands shut down and then mount the database:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
2-16
Chapter 2
Restoring and Recovering Database Files: Quick Start
3.
Run the FLASHBACK DATABASE command.
The following examples illustrate different forms of the command:
FLASHBACK DATABASE TO SCN 861150;
FLASHBACK DATABASE
TO RESTORE POINT BEFORE_CHANGES;
FLASHBACK DATABASE
TO TIMESTAMP TO_DATE(04-DEC-2009 03:30:00','DD-MON-YYYY HH24:MI:SS');
4.
After performing the Flashback Database, open the database read-only in
SQL*Plus and run some queries to verify the database contents.
Open the database read-only as follows:
ALTER DATABASE OPEN READ ONLY;
5.
If satisfied with the results, then issue the following sequence of commands to shut
down and then open the database:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN RESETLOGS;
See Also:
"Rewinding a Database with Flashback Database"
2.9 Restoring and Recovering Database Files: Quick Start
Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical
database files.
Restoring data files is retrieving them from backups as needed for a recovery
operation. Media recovery is the application of changes from redo logs and
incremental backups to a restored data file to bring the data file forward to a desired
SCN or point in time.
This section contains the following topics:
•
Preparing to Restore and Recover Database Files
•
Recovering the Whole Database
•
Recovering Tablespaces
•
Recovering Individual Data Blocks
See Also:
Performing Complete Database Recovery
2-17
Chapter 2
Restoring and Recovering Database Files: Quick Start
2.9.1 Preparing to Restore and Recover Database Files: Quick Start
To recover the database because a media failure damages database files, then first
ensure that you have the necessary backups.
You can use the RESTORE ... PREVIEW command to report, but not restore, the backups
that RMAN can use to restore to the specified time. RMAN queries the metadata and
does not actually read the backup files. The database can be open when you run this
command.
To preview a database restore and recovery:
1.
Start RMAN and connect to the target database as described in "Starting RMAN
and Connecting to a Database".
2.
Optionally, list the current tablespaces and data files, as shown in the following
command:
RMAN> REPORT SCHEMA;
3.
Run the RESTORE DATABASE command with the PREVIEW option.
The following command specifies SUMMARY so that the backup metadata is not
displayed in verbose mode (sample output included):
RMAN> RESTORE DATABASE PREVIEW SUMMARY;
Starting restore at 21-MAY-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=80 device type=DISK
List of Backups
===============
Key
TY LV S Device Type
------- -- -- - ----------11
B F A DISK
13
B F A DISK
using channel ORA_DISK_1
Completion Time
--------------18-MAY-13
18-MAY-13
#Pieces
------1
1
#Copies
------2
2
Compressed
---------NO
NO
Tag
--TAG20070518T181114
TAG20070518T181114
List of Archived Log Copies for database with db_unique_name PROD
=====================================================================
Key
Thrd Seq
S Low Time
------- ---- ------- - --------47
1
18
A 18-MAY-13
Name: /disk1/oracle/dbs/db1r_60ffa882_1_18_0622902157.arc
Media recovery start SCN is 586534
Recovery must be done beyond SCN 587194 to clear datafile fuzziness
validation succeeded for backup piece
Finished restore at 21-MAY-13
2.9.2 Recovering the Whole Database: Quick Start
Use the RESTORE DATABASE and RECOVER DATABASE commands to recover the whole
database.
You must have previously made backups of all needed files. This scenario assumes
that you can restore all data files to their original locations. If the original locations are
inaccessible, then use the SET NEWNAME command as described in "About Restoring
Data Files to a Nondefault Location".
2-18
Chapter 2
Restoring and Recovering Database Files: Quick Start
To recover the whole database:
1.
Prepare for recovery as explained in "Preparing to Restore and Recover Database
Files".
2.
Place the database in a mounted state.
The following example terminates the database instance (if it is started) and
mounts the database:
RMAN> STARTUP FORCE MOUNT;
3.
Restore the database.
The following example uses the preconfigured disk channel to restore the
database:
RMAN> RESTORE DATABASE;
4.
Recover the database, as shown in the following example:
RMAN> RECOVER DATABASE;
5.
Open the database, as shown in the following example:
RMAN> ALTER DATABASE OPEN;
2.9.3 Recovering Tablespaces: Quick Start
Use the RESTORE TABLESPACE and RECOVER TABLESPACE commands on individual
tablespaces when the database is open. In this case, you must take the tablespace
that needs recovery offline, restore and then recover the tablespace, and bring the
recovered tablespace online.
If you cannot restore a data file to its original location, then use the RMAN SET NEWNAME
command within a RUN block to specify the new file name and location. Afterward, use
a SWITCH DATAFILE ALL command, which is equivalent to using the SQL statement ALTER
DATABASE RENAME FILE, to update the control file to reflect the new names for all data
files for which a SET NEWNAME has been issued in the RUN command.
Unlike user-managed media recovery, you do not place an online tablespace in
backup mode. RMAN does not require extra logging or backup mode because it
knows the format of data blocks.
To recover an individual tablespace when the database is open:
1.
Prepare for recovery as explained in "Preparing to Restore and Recover Database
Files".
2.
Take the tablespace to be recovered offline.
The following example takes the USERS tablespace offline:
RMAN> ALTER TABLESPACE users OFFLINE;
3.
Restore and recover the tablespace.
The following RUN command, which you execute at the RMAN prompt, sets a new
name for the data file in the USERS tablespace:
RUN
{
SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf'
2-19
Chapter 2
Restoring and Recovering Database Files: Quick Start
TO '/disk2/users01.dbf';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL; # update control file with new file names
RECOVER TABLESPACE users;
}
4.
Bring the tablespace online, as shown in the following example:
RMAN> ALTER TABLESPACE users ONLINE;
You can also use RESTORE DATAFILE and RECOVER DATAFILE for recovery at the data file
level.
See Also:
•
"Performing Complete Recovery of a Tablespace"
•
"About Online Backups and Backup Mode"
2.9.4 Recovering Individual Data Blocks: Quick Start
RMAN can recover individual corrupted data file blocks.
When RMAN performs a complete scan of a file for a backup, any corrupted blocks
are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption is usually reported in alert logs,
trace files, or results of SQL queries.
To recover data blocks:
1.
Start RMAN and connect to the target database as described in "Starting RMAN
and Connecting to a Database".
2.
Obtain the block numbers of the corrupted blocks if you do not have this
information.
RMAN> SELECT NAME, VALUE FROM V$DIAG_INFO;
3.
Run the RECOVER command to repair the blocks.
The following RMAN command recovers all corrupted blocks:
RMAN> RECOVER CORRUPTION LIST;
You can also recover individual blocks, as shown in the following example:
RMAN> RECOVER DATAFILE 1 BLOCK 233, 235 DATAFILE 2 BLOCK 100 TO 200;
See Also:
Performing Block Media Recovery
2-20
Part II
Starting and Configuring RMAN and
Flashback Database
The chapters in this part explain the basic components of the RMAN environment and
how to configure it. This part contains the following chapters:
•
Recovery Manager Architecture
•
Starting and Interacting with the RMAN Client
•
Configuring the RMAN Environment
•
Configuring the RMAN Environment: Advanced Topics
•
Using Flashback Database and Restore Points
3
Recovery Manager Architecture
This chapter describes the Recovery Manager (RMAN) interface and the basic
components of the RMAN environment. This chapter contains the following topics:
•
About the RMAN Environment
•
About RMAN Command-Line Client
•
About RMAN Channels
•
About the RMAN Repository
•
About Media Management Using RMAN
•
About the Fast Recovery Area
•
About RMAN in a Data Guard Environment
•
About RMAN in a Recovery Appliance Environment
3.1 About the RMAN Environment
The Recovery Manager environment consists of the various applications and
databases that play a role in a backup and recovery strategy.
Table 3-1 lists some components in a typical RMAN environment.
Table 3-1
Components of the RMAN Environment
Component
Description
RMAN client
The client application that manages backup and recovery
operations for a target database. The RMAN client can use
Oracle Net to connect to a target database, so it can be
located on any host that is connected to the target host
through Oracle Net.
target database
A database containing the control files, data files, and optional
archived redo logs that RMAN backs up or restores. RMAN
uses the target database control file to gather metadata about
the target database and to store information about its own
operations. The work of backup and recovery is performed by
server sessions running on the target database.
recovery catalog database
A database containing a recovery catalog, which contains
metadata that RMAN uses to perform backup and recovery.
You can create one recovery catalog that contains the RMAN
metadata for multiple target databases. Unless you are using
RMAN with a physical standby database, a recovery catalog is
optional when using RMAN because RMAN stores its
metadata in the control file of each target database.
3-1
Chapter 3
About the RMAN Environment
Table 3-1
(Cont.) Components of the RMAN Environment
Component
Description
recovery catalog schema
The user within the recovery catalog database that owns the
metadata tables maintained by RMAN. RMAN periodically
propagates metadata from the target database control file into
the recovery catalog.
physical standby database
A copy of the primary database that is updated with redo
generated by the primary database. You can fail over to the
standby database if the primary database becomes
inaccessible.
RMAN can create, back up, or recover a standby database.
Backups that you make at a physical standby database are
usable at the primary database or another physical standby
database for the same production database. The recovery
catalog is required when you use RMAN to back up a physical
standby database.
Note: A logical standby database is treated as a separate
database by RMAN because it has a different DBID from its
primary database.
See Also: Oracle Data Guard Concepts and Administration to
learn how to use RMAN in a Data Guard environment
fast recovery area
A disk location that you can use to store recovery-related files
such as control file and online redo log copies, archived redo
logs, flashback logs, and RMAN backups. Oracle Database
and RMAN manage the files in the fast recovery area
automatically.
media management software
A vendor-specific application that enables RMAN to back up to
a storage system such as tape
media management catalog
A vendor-specific repository of metadata about a media
management application
Oracle Enterprise Manager
A browser-based interface to the database, including backup
and recovery through RMAN
The only required components in an RMAN environment are a target database and
RMAN client, but most real-world configurations are more complicated. For example,
you use an RMAN client connecting to multiple media managers and multiple target
databases, all accessed through Enterprise Manager.
Figure 3-1 illustrates components in a possible RMAN environment. The figure shows
that the primary database, standby database, and recovery catalog databases all
reside on different computers. The primary and standby database hosts use a locally
attached tape drive. The RMAN client and Enterprise Manager console run on a
separate computer.
3-2
Chapter 3
About RMAN Command-Line Client
Figure 3-1
Sample RMAN Environment
Tape Drive
Tape Drive
Media
Management
Subsystem
Media
Management
Subsystem
Flash
Recovery
Area
Target
Database
Control
File
Duplicate
or
Standby
Database
Auxiliary
Instance
Recovery
Catalog
Recovery
Catalog
Schema
Enterprise
Manager
RMAN
Executable
See Also:
Oracle Database Net Services Administrator's Guide to learn about Oracle
Net
3.2 About RMAN Command-Line Client
Use the RMAN command-line client to enter commands that you can use to manage
all aspects of backup and recovery operations.
RMAN uses a command language interpreter that can execute commands in
interactive or batch mode.
3.3 About RMAN Channels
An RMAN channel represents one stream of data to a device, and corresponds to one
database server session. During a backup or restore operation, the channel reads
data from the input device, processes it, and writes it to the output device.
The RMAN client directs database server sessions to perform all backup and recovery
tasks. What constitutes a session depends on the operating system. For example, on
3-3
Chapter 3
About RMAN Channels
Linux, a server session corresponds to a server process, whereas on Windows it
corresponds to a thread within the database service. The RMAN client itself does not
perform backup, restore, or recovery operations.
Most RMAN commands are executed by channels, which must be either configured to
persist across RMAN sessions, or manually allocated in each RMAN session. As
illustrated in Figure 3-2, a channel establishes a connection from the RMAN client to a
target or auxiliary database instance by starting a server session on the instance.
Figure 3-2
Channel Allocation
Disk
Server
session
channel ch1
Recovery Manager
Oracle
Target
Recovery
database
Catalog
See Also:
"Basic Concepts of RMAN Performance Tuning for a low-level description of
how channels work"
3.3.1 About RMAN Channels and Devices
The RMAN-supported device types are DISK and SBT (system backup to tape).
An SBT device is controlled by a third-party media management software. Typically,
SBT devices are tape libraries and tape drives.
If you use a DISK channel for a backup, then the channel creates the backup on disk
in the file name space of the target database instance creating the backup. You can
make a backup on any device that can store a data file. RMAN does not call a media
manager when making DISK backups.
To create backups on non-disk media, you must use media management software
such as Oracle Secure Backup and allocate channels supported by this software.
RMAN contacts the media manager whenever the channel type allocated is not DISK.
How and when the SBT channels cause the media manager to allocate resources is
vendor-specific. Some media managers allocate resources when you issue the
command; others do not allocate resources until you open a file for reading or writing.
3-4
Chapter 3
About the RMAN Repository
See Also:
"Configuring the Default Device for Backups: Disk or SBT"
3.3.2 About RMAN Automatic and Manual Channels
RMAN can use automatic channels or manual channels for backup and recover
operations.
You can use the CONFIGURE CHANNEL command to configure channels for use with disk
or tape across RMAN sessions. This technique is known as automatic channel
allocation. RMAN comes preconfigured with one DISK channel that you can use for
backups to disk.
When you run a command that can use automatic channels, RMAN automatically
allocates the channels with the options that you specified in the CONFIGURE command.
For the BACKUP command, RMAN allocates only the type of channel required to back up
to the specified media. For the RESTORE command and RMAN maintenance commands,
RMAN allocates all necessary channels for the device types required to execute the
command. RMAN determines the names for automatic channels.
You can also manually allocate channels. Each manually allocated channel uses a
separate connection to the database. When you manually allocate a channel, you give
it a user-defined name such as dev1 or ch2.
The number of channels available for use with a device when you run a command
determines whether RMAN reads from or write to this device in parallel while
performing the command. When the work is done in parallel, the backup of the files is
done by multiple channels. Each channel may back up multiple files, but unless a
multisection backup is performed, no file is backed up by more than one channel.
See Also:
•
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL
syntax
•
Oracle Database Backup and Recovery Reference on ALLOCATE CHANNEL
FOR MAINTENANCE
•
"Configuring Channels for Disk" and "Configuring SBT Channels for Use
with a Media Manager"
3.4 About the RMAN Repository
The RMAN repository is a collection of metadata about the target databases that
RMAN uses for backup, recovery, and maintenance.
RMAN always stores its metadata in the control file. The version of this metadata in
the control file is the authoritative record of RMAN backups of your database. This is
one reason why protecting your control file is an important part of your backup
strategy. RMAN can conduct all necessary backup and recovery operations using just
3-5
Chapter 3
About Media Management Using RMAN
the control file to store the RMAN repository information, and maintains all records
necessary to meet your configured retention policy.
You can also create a recovery catalog, which is a repository of RMAN metadata
stored in an Oracle Database schema. The control file has limited space for records of
backup activities, whereas a recovery catalog can store a much longer history. You
can simplify backup and recovery administration by creating a single recovery catalog
that contains the RMAN metadata for all of your databases.
The owner of a recovery catalog can grant or revoke restricted access to the catalog to
other database users. Each restricted user has full read/write access to his own
metadata, which is called a virtual private catalog. When one or more virtual private
catalogs exist in a database, the database contains just one set of catalog tables.
These tables are owned by the base recovery catalog owner. The owner of the base
recovery catalog controls which databases each virtual private catalog user can
access.
Some RMAN features only function when you use a recovery catalog. For example,
you can create a stored script in the recovery catalog and use this script to execute
RMAN jobs. Other RMAN commands are specifically related to managing the recovery
catalog and so are not available (and not needed) if RMAN is not connected to a
recovery catalog.
The recovery catalog is maintained solely by RMAN. A target database instance never
accesses the catalog directly. RMAN propagates information about the database
structure, archived redo logs, backup sets, and data file copies into the recovery
catalog from the target database control file after any operation that updates the
repository, and also before certain operations.
See Also:
Maintaining RMAN Backups and Repository Records and Managing a
Recovery Catalog
3.5 About Media Management Using RMAN
The Oracle Media Management Layer (MML) API lets third-party vendors build media
management software that works with RMAN to allow backups to sequential media
devices such as tape drives.
Media management software handles loading, unloading, and labeling of sequential
media such as tapes. You must install media management software to use RMAN with
sequential media devices.
When backing up or restoring, the RMAN client connects to a target database instance
and directs the instance to send requests to its media manager. No direct
communication occurs between the RMAN client and the media manager.
This section contains the following topics:
•
About RMAN Interaction with a Media Manager
•
About RMAN and Oracle Secure Backup
•
About the Backup Solutions Program
3-6
Chapter 3
About Media Management Using RMAN
3.5.1 About RMAN Interaction with a Media Manager
Before performing backup or restore to a media manager, you must allocate one or
more channels to handle the communication with the media manager. You can also
configure default channels for the media manager. The default channels are used for
all backup and recovery tasks that employ the media manager and for which you have
not explicitly allocated channels.
RMAN does not issue specific commands to load, label, or unload tapes. When
backing up, RMAN gives the media manager a stream of bytes and associates a
unique name with this stream. When RMAN must restore the backup, it asks the
media manager to retrieve the byte stream. All details of how and where that stream is
stored are handled entirely by the media manager. For example, the media manager
labels and keeps track of the tape and names of files on each tape, and automatically
loads and unloads tapes, or signals an operator to do so.
Some media managers support proxy copy functionality, in which they handle the
entire data movement between data files and the backup devices. These products
may use technologies such as high-speed connections between storage and media
subsystems to reduce the load on the primary database server. RMAN provides a list
of files requiring backup or restore to the media manager, which in turn makes all
decisions regarding how and when to move the data.
See Also:
"Configuring SBT Channels for Use with a Media Manager"
3.5.2 About RMAN and Oracle Secure Backup
Oracle Secure Backup is a media manager that provides reliable and secure data
protection through file system backup to tape. All major tape drives and tape libraries
in SAN, Gigabit Ethernet, and SCSI environments are supported.
Although Oracle Secure Backup has no specialized knowledge of database backup
and recovery algorithms, it can serve as a media management layer for RMAN
through the SBT interface. In this capacity, Oracle Secure Backup provides the same
services for RMAN as other supported third-party SBT libraries. Oracle Secure Backup
has some features, however, that are not available in other media managers.
See Also:
Oracle Secure Backup Administrator's Guide to learn how to use Oracle
Secure Backup
3.5.3 About the Backup Solutions Program
The Oracle Backup Solutions Program (BSP), part of the Oracle PartnerNetwork, is a
group of media manager vendors whose products are compliant with Oracle's MML
3-7
Chapter 3
About the Fast Recovery Area
specification. Several products may be available for your platform from media
management vendors.
For more information, contact your Oracle representative for a list of available
products, contact individual vendors to ask them if they participate, or access the
Backup Solutions Program website at:
http://www.oracle.com/technetwork/database/features/availability/bsp-088814.html
Oracle does not certify media manager vendors for compatibility with RMAN.
Questions about availability, version compatibility, and functionality can only be
answered by the media manager vendor, not Oracle.
3.6 About the Fast Recovery Area
The fast recovery area is an optional disk location that can be used to store recoveryrelated files.
The components that create different backup and recovery-related files have no
knowledge of each other or of the size of the file systems where they store their data.
With automatic disk-based backup and recovery, you can create a fast recovery area
(also called the recovery area), which automates management of backup-related files.
A fast recovery area minimizes the need to manually manage disk space for backuprelated files and balance the use of space among the different types of files. In this
way, a fast recovery area simplifies the ongoing administration of your database.
Oracle recommends that you enable a recovery area to simplify backup management.
When you create a recovery area, you choose a location on disk and set an upper
bound for storage space. You also set a backup retention policy that governs how long
backup files are needed for recovery. The database manages the storage used for
backups, archived redo logs, and other recovery-related files for the database within
this space. Files no longer needed are eligible for deletion when RMAN must reclaim
space for new files.
See Also:
"Configuring the Fast Recovery Area" to learn about the fast recovery area
and how to configure it
3.7 About RMAN in a Data Guard Environment
Data Guard maintains standby databases as transactionally consistent copies of
production database. A standby database can be either a physical standby database
or a logical standby database.
A database in a Data Guard environment is uniquely identified by the DB_UNIQUE_NAME
parameter in the initialization parameter file. For RMAN to work correctly in a Data
Guard environment, the DB_UNIQUE_NAME must be unique across all the databases with
the same DBID.
When using RMAN in a Data Guard environment, a recovery catalog is required. The
recovery catalog can store the metadata for all primary and standby databases.
3-8
Chapter 3
About RMAN in a Data Guard Environment
This section contains the following topics:
•
About RMAN Configuration in a Data Guard Environment
•
About RMAN File Management in a Data Guard Environment
See Also:
Oracle Data Guard Concepts and Administration to learn how to use RMAN
in a Data Guard environment
3.7.1 About RMAN Configuration in a Data Guard Environment
To simplify ongoing use of RMAN for backup and recovery, you can set some
persistent configuration settings for each primary and physical standby database in a
Data Guard environment. These settings control many aspects of RMAN behavior. For
example, you can configure the backup retention policy, default destinations for
backups to tape or disk, or default backup device type.
You can use the CONFIGURE command with the FOR DB_UNIQUE_NAME clause to create a
persistent configuration for a database in a Data Guard environment without
connecting to the standby database or primary database as TARGET. For example, you
connect RMAN to the recovery catalog, run the SET DBID command, and then can
create a configuration for a physical standby database before its creation so that the
RMAN configuration applies when the database is created.
RMAN updates the control file of the database when connected to it as TARGET during a
recovery catalog resynchronization. If you use FOR DB_UNIQUE_NAME for a database
without being connected as TARGET to this database, however, then RMAN changes
configurations in the recovery catalog only.
See Also:
"Configuring RMAN in a Data Guard Environment"
3.7.2 About RMAN File Management in a Data Guard Environment
RMAN uses a recovery catalog to track file names for all database files in a Data
Guard environment.
The catalog also records where the online redo log files, standby redo log files, temp
files, archived redo log files, backup sets, and image copies are created.
3.7.2.1 About Interchangeability of Backups in a Data Guard Environment
RMAN commands use the recovery catalog metadata to function transparently across
different physical databases in the Data Guard environment. For example, you can
back up a tablespace on a physical standby database and restore and recover it on
the primary database. Similarly, you can back up a tablespace on a primary database
and restore and recover it on a physical standby database.
3-9
Chapter 3
About RMAN in a Data Guard Environment
Backups of standby control files and nonstandby control files are interchangeable. For
example, you can restore a standby control file on a primary database and a primary
control file on a physical standby database. This interchangeability means that you can
offload control file backups to one database in a Data Guard environment. RMAN
automatically updates the file names for database files during restore and recovery at
the databases.
Note:
Backups of logical standby databases are not usable at the primary
database.
3.7.2.2 About Association of Backups in a Data Guard Environment
The recovery catalog tracks the files in the Data Guard environment by associating
every database file or backup file with a DB_UNIQUE_NAME. The database that creates a
file is associated with the file.
For example, if RMAN backs up the database with the unique name of standby1, then
standby1 is associated with this backup. A backup remains associated with the
database that created it unless you use the CHANGE ...RESET DB_UNIQUE_NAME command
to associate the backup with a different database.
3.7.2.3 About Accessibility of Backups in a Data Guard Environment
The accessibility of a backup is different from its association. In a Data Guard
environment, the recovery catalog considers disk backups as accessible only to the
database with which they are associated, whereas tape backups created on one
database are accessible to all databases.
If a backup file is not associated with any database, then the row describing it in the
recovery catalog view shows null for the SITE_KEY column. By default, RMAN
associates a file whose SITE_KEY is null with the database to which they are connected
as TARGET.
RMAN commands such as BACKUP, RESTORE, and CROSSCHECK work on any accessible
backup. For example, for a RECOVER COPY operation, RMAN considers only image
copies that are associated with the database as eligible to be recovered. RMAN
considers the incremental backups on disk and tape as eligible to recover the image
copies. In a database recovery, RMAN considers only the disk backups associated
with the database and all files on tape as eligible to be restored.
To illustrate the differences in backup accessibility, assume that databases prod and
standby1 reside on different hosts. RMAN backs up data file 1 on prod to /prmhost/
disk1/df1.dbf on the production host and also to tape. RMAN backs up data file 1 on
standby1 to /sbyhost/disk2/df1.dbf on the standby host and also to tape. If RMAN is
connected to database prod, then you cannot use RMAN commands to perform
operations with the /sbyhost/disk2/df1.dbf backup located on the standby host.
However, RMAN does consider the tape backup made on standby1 as eligible to be
restored.
3-10
Chapter 3
About RMAN in a Recovery Appliance Environment
Note:
You can transfer a backup from a standby host to a primary host or vice
versa, connect as TARGET to the database on this host, and then use the
CATALOG command to catalog the backup. After a file is cataloged by the
target database, the file is associated with the target database.
See Also:
•
Oracle Data Guard Concepts and Administration to learn how to perform
RMAN backup and recovery in a Data Guard environment
•
"About Maintenance Commands in a Data Guard Environment"
•
Managing a Recovery Catalog to learn how to manage a recovery
catalog in a Data Guard environment
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
3.8 About RMAN in a Recovery Appliance Environment
RMAN is fully-integrated with Zero Data Loss Recovery Appliance (Recovery
Appliance) and RMAN commands can be used to back up protected databases to
Recovery Appliance.
See Also:
Creating RMAN Backups to Recovery Appliance
3.8.1 Creating RMAN Backups to Recovery Appliance
Recovery Appliance provides a centralized remote repository for backups of all target
databases in the enterprise. Backups and backup metadata for all target databases is
managed by a central recovery catalog (the Recovery Appliance catalog) on Recovery
Appliance.
Before you use Recovery Appliance to manage backups of your target database, you
must perform some configuration steps both on the Recovery Appliance and on the
target database.
To back up a target database to Recovery Appliance:
1.
Ensure that the target database meets the requirements for protected databases
in Recovery Appliance environments.
3-11
Chapter 3
About RMAN in a Recovery Appliance Environment
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for
information about the supported Oracle Database releases
2.
Install the Recovery Appliance backup module on the target database. This
backup module is a shared library that is used by the target database to transfer
backups to Recovery Appliance.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for the steps to install the Recovery Appliance backup module
3.
Enroll the target database as a protected database with the Recovery Appliance.
This step includes creating a protection policy, configuring a Recovery Appliance
database user that will be used by protected databases to authenticate with
Recovery Appliance, and registering the protected database with the Recovery
Appliance catalog.
See Also:
4.
•
Zero Data Loss Recovery Appliance Administrator's Guide for the
enrolment steps on the Recovery Appliance
•
Zero Data Loss Recovery Appliance Protected Database
Configuration Guide for the enrolment steps on the protected
database
(Optional) Configure backup and recovery settings for the target database. These
settings will be used when you perform backup and recovery operations with
Recovery Appliance.
The CONFIGURE command is used to configure backup and recovery settings for
protected databases.
See Also:
5.
•
Configuring the RMAN Environment
•
Zero Data Loss Recovery Appliance Protected Database
Configuration Guide for information about configuring settings in a
Recovery Appliance environment
Start RMAN and connect as TARGET to the protected database and as CATALOG to
the Recovery Appliance catalog.
3-12
Chapter 3
About RMAN in a Recovery Appliance Environment
The connection to the target database must be as a user with the SYSDBA or
SYSBACKUP privilege. The connection to the Recovery Appliance is as the Recovery
Appliance user that has privileges required to perform backup and recovery
operations for the protected database.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for information about creating connections using RMAN
6.
Allocate one or more RMAN SBT channels that point to the Recovery Appliance
backup module. These channels are used to transfer data to the Recovery
Appliance.
See Also:
"Configuring RMAN to Make Backups to Recovery Appliance"
7.
Back up the target database to Recovery Appliance. You use the regular RMAN
commands to back up the database to Recovery Appliance.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for the steps to back up protected databases
3-13
4
Starting and Interacting with the
RMAN Client
This chapter explains how to start the RMAN command-line interface and make
database connections. This chapter contains the following topics:
•
Starting and Exiting RMAN
•
Making Database Connections with RMAN
•
Specifying the Location of RMAN Output
•
Setting Globalization Support Environment Variables for RMAN
•
Entering RMAN Commands
•
Using the RMAN Pipe Interface
4.1 Starting and Exiting RMAN
The RMAN executable is automatically installed with the database and is typically
located in the same directory as the other database executables. For example, the
RMAN client on Linux is located in $ORACLE_HOME/bin.
You have the following basic options for starting RMAN:
•
Start the RMAN executable at the operating system command line without
specifying any connection options, as in the following example:
% rman
See "Making Database Connections from the RMAN Prompt".
•
Start the RMAN executable at the operating system command line, as in the
following examples:
% rman TARGET /
% rman TARGET sbu@prod NOCATALOG
See "Making RMAN Database Connections from the Operating System Command
Line".
To quit RMAN and terminate the program, enter EXIT or QUIT at the RMAN prompt:
RMAN> EXIT
See Also:
Oracle Database Backup and Recovery Reference for RMAN command-line
syntax
4-1
Chapter 4
Making Database Connections with RMAN
4.2 Making Database Connections with RMAN
You can create database connections from the RMAN client or the operating system
command line. These database connection can be authenticated using a password file
or with operating system authentication.
This section contains the following topics:
•
About RMAN Database Connection Types
•
About Authentication for RMAN Database Connections
•
Making Database Connections from the RMAN Prompt
•
Making RMAN Database Connections from the Operating System Command Line
•
Connecting RMAN to an Auxiliary Database
•
Making RMAN Connections to a CDB
•
Making RMAN Database Connections Within Command Files
•
Diagnosing RMAN Connection Problems
4.2.1 About RMAN Database Connection Types
To perform useful work, the RMAN client must connect to a database.
Table 4-1 describes the types of database connections that you can make with RMAN.
Table 4-1
Overview of RMAN Database Connections
Type of Database
Connection
Keyword
Description
target database
TARGET
A database to be backed up or recovered by RMAN
recovery catalog
database
CATALOG
A database that provides an optional backup store for
the RMAN repository in addition to the control file.
auxiliary instance or
auxiliary database
AUXILIARY
A physical standby database, or a database instance
created for performing a specific task such as
creating a duplicate database, transporting
tablespaces, or performing tablespace point-in-time
recovery (TSPITR).
For many tasks that use an auxiliary database,
RMAN creates an automatic auxiliary instance for use
during the task, connects to it, performs the task, and
then destroys it when the task is completed. You do
not give any explicit command to connect to
automatic auxiliary instances.
4.2.2 About Authentication for RMAN Database Connections
Users connecting with RMAN to a target or auxiliary database require either the SYSDBA
or SYSBACKUP system privilege.
These privileges are not required when connecting to the recovery catalog. You must
grant the RECOVERY_CATALOG_OWNER role to the catalog schema owner. Users can also
4-2
Chapter 4
Making Database Connections with RMAN
connect to the recovery catalog using the VPC credentials that have been created by
the recovery catalog owner.
The same authentication options that are available with SQL*Plus are available with
RMAN. The most common ways to authenticate with the target and auxiliary
databases are:
•
Operating system authentication
The prerequisites for connecting using operating system authentication are
described in "Authentication Using the Operating System".
•
Password file authentication
The prerequisites for connecting using password file authentication are described
in "Authentication Using a Password File".
Neither of these methods requires the database to be open. Operating system
authentication is used only to connect locally. Password file authentication can be
used to connect locally or remotely.
See Also:
•
•
Oracle Database Administrator’s Guide to learn about database
connection options when using SQL*Plus
Oracle Database Security Guide for details about the SYSDBA and
SYSBACKUP system privileges
4.2.2.1 Authentication Using the Operating System
RMAN connections to a target or auxiliary database can be made using operating
system authentication.
The following are the prerequisites for connecting to a database using operating
system authentication (OS authentication):
•
You must set the ORACLE_SID environment variable, specifying the system identifier
(SID) for the database.
For example, to set the SID to prod in some UNIX shells, you enter:
% ORACLE_SID=prod; export ORACLE_SID
•
You must be a member of the OSDBA operating system group to connect with the
SYSDBA privilege or the OSBACKUPDBA operating system group to connect with
the SYSBACKUP privilege.
On UNIX and Linux, the OSDBA group is typically named dba, and the
OSBACKUPDBA group is typically named backupdba. These names are assigned
during database installation.
The following examples illustrate how to connect to a target database with operating
system authentication.
4-3
Chapter 4
Making Database Connections with RMAN
See Also:
Oracle Database Administrator's Guide for a discussion of operating system
groups
Example 4-1
OS Authentication with the SYSDBA Privilege - Explicit
% rman target '"/ as sysdba"'
Example 4-2
OS Authentication with the SYSBACKUP Privilege - Explicit
% rman target '"/ as sysbackup"'
Example 4-3
OS Authentication with the SYSDBA Privilege - Implicit
rman target /
If neither AS SYSBACKUP nor AS SYSDBA is specified in the connection string, then the
default used is AS SYSDBA.
4.2.2.2 Authentication Using a Password File
Use a password file for either local or remote access. If a database uses a password
file to authenticate administrative users, then RMAN can connect using a password.
The database must use a password file for you to connect remotely using a net service
name.
Caution:
Good security practice requires that passwords not be entered in plain text
on the command line. Enter passwords in RMAN only when requested by an
RMAN prompt. See Oracle Database Security Guide to learn about
password protection.
The database creates an entry in the password file when you grant the SYSDBA or
SYSBACKUP privilege to a user. You can then connect to the target or auxiliary database
as this user even if the database is not open.
To support connecting through the password file with the SYSBACKUP privilege, the
password file must be created in or upgraded to the format for Oracle Database 12c
Release 1 (12.1) or later.
If neither AS SYSBACKUP nor AS SYSDBA is specified in the connection string, then the
default used is AS SYSDBA. In this case, no enclosing quotes are required.
See Also:
Oracle Database Administrator's Guide to learn about password files
4-4
Chapter 4
Making Database Connections with RMAN
Example 4-4
Password File Authentication as SYSDBA - Explicit
In this example, the sdba user has been granted the SYSDBA privilege:
% rman target '"sdba@prod1 as sysdba"'
target database Password: password
connected to target database: PROD1 (DBID=39525561)
Example 4-5
Password File Authentication as SYSBACKUP - Explicit
In this example, the sbu user is granted the SYSBACKUP privilege in the target database:
% rman target '"sbu@prod1 as sysbackup"'
target database Password: password
connected to target database: PROD1 (DBID=39525561)
Example 4-6
Password File Authentication as SYSDBA - Implicit
% rman target sbu@prod1
target database Password: password
connected to target database: PROD1 (DBID=39525561)
4.2.3 Making Database Connections from the RMAN Prompt
If you start RMAN without a connect string on the operating system command line,
then you must issue a CONNECT TARGET command at the RMAN prompt to connect to a
target database.
To make a database connection from the RMAN prompt:
1.
On the operating system command line, start the RMAN client without making a
database connection.
% rman
RMAN>
2.
At the RMAN prompt, enter one or more CONNECT commands.
Example 4-7
Connecting With OS Authentication - Implicit
RMAN> connect target /
Because no system privilege is specified, ASSYSDBA is assumed.
Example 4-8
Connecting with OS Authentication - Explicit
RMAN> connect target "/ as sysdba"
When including a system privilege, the enclosing quotation marks (single or double)
are required.
Example 4-9
Connecting with Password File Authentication
RMAN> connect target "sbu@prod AS SYSBACKUP"
target database Password: password
connected to target database: PROD (DBID=39525561)
4-5
Chapter 4
Making Database Connections with RMAN
Example 4-10
Connecting to Target and a Recovery Catalog
In this example, the target connection uses operating system authentication, and the
recovery catalog database connection uses a net service name and password file
authentication. The recovery catalog owner is user rco. RMAN prompts for the
password of the recovery catalog user.
RMAN> connect target /
RMAN> connect catalog rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
See Also:
Oracle Database Backup and Recovery Reference to learn about the CONNECT
command
4.2.4 Making RMAN Database Connections from the Operating
System Command Line
To connect to a target database from the operating system command line, enter the
rman command followed by the connection information. You can begin executing
commands after the RMAN prompt is displayed.
Use the CATALOG keyword to connect to a recovery catalog. You can also start RMAN
without specifying NOCATALOG or CATALOG. If you do not specify NOCATALOG on the
command line, and if you do not specify CONNECT CATALOG after RMAN has started, then
RMAN defaults to NOCATALOG mode the first time that you run a command that requires
the use of the RMAN repository.
Note:
After you have executed a command that uses the RMAN repository in
NOCATALOG mode, you must exit and restart RMAN to be able to connect to a
recovery catalog.
If you connect to the target database on the operating system command line, then you
can begin executing commands after the RMAN prompt is displayed.
Example 4-11
Connecting to a Target Database from the System Prompt
This example illustrates a connection to a target database that uses operating system
authentication. The NOCATALOG option indicates that a recovery catalog is not used in
the session.
% rman TARGET / NOCATALOG
connected to target database: PROD (DBID=39525561)
using target database control file instead of recovery catalog
4-6
Chapter 4
Making Database Connections with RMAN
RMAN>
Example 4-12 Connecting to a Target Database from the System Prompt by
Using Net Service Names
This example illustrates a connection to a target database that uses a net service
name and password file authentication. RMAN prompts for the password.
% rman TARGET sbu@prod NOCATALOG
target database Password: password
connected to target database: PROD (DBID=39525561)
RMAN>
Example 4-13
Prompt
Connecting to Target and a Recovery Catalog from the System
This example illustrates a connection that uses Oracle Net authentication for the target
and recovery catalog databases. In both cases RMAN prompts for a password.
% rman TARGET sbu@prod CATALOG rco@catdb
target database Password: password
connected to target database: PROD (DBID=39525561)
recovery catalog database Password: password
connected to recovery catalog database
RMAN>
4.2.5 Making RMAN Connections to a CDB
You can connect the RMAN client to multitenant container databases (CDBs) and
pluggable databases (PDBs).
This section contains the following topics:
•
About Performing Operations on CDBs and PDBs
•
Restrictions When Connected to a PDB
•
Connecting as Target to the Root
•
Connecting as Target to a PDB
4.2.5.1 About Performing Operations on CDBs and PDBs
You can perform RMAN operations on a whole CDB, the root only, or one or more
PDBs.
Make RMAN connections to CDBs according to the following rules:
•
To perform operations on the whole CDB (for example, to back up the whole CDB)
you connect as target to the root.
•
To perform operations on the root only (for example, to back up the root) you
connect as target to the root.
•
To perform operations on a single PDB, you can connect as target either to the
root or directly to the PDB.
4-7
Chapter 4
Making Database Connections with RMAN
•
–
If you connect to the root, you must use the PLUGGABLE DATABASE syntax in your
RMAN commands. For example, to back up a PDB, you use the BACKUP
PLUGGABLE DATABASE command.
–
If instead you connect directly to a PDB, you can use the same commands
that you would use when connecting to a non-CDB. For example, to back up a
PDB, you would use the BACKUP DATABASE command.
To perform operations on two or more PDBs with a single command, you connect
as target to the root.
For example, to back up both the sales and hr PDBs, you connect to the root and
submit the following command:
BACKUP PLUGGABLE DATABASE sales, hr;
Note:
If you connect as target to a CDB with operating system authentication, you
are connected to the root.
4.2.5.2 Restrictions When Connected to a PDB
Certain restrictions apply when you connect directly to a pluggable database (PDB):
The following operations are not available when you connect as target directly to a
PDB:
•
Back up archived logs
•
Delete archived logs
•
Delete archived log backups
•
Restore archived logs (RMAN does restore archived logs when required during
media recovery.)
•
Point-in-time recovery (PITR) when using shared undo mode
•
TSPITR
•
Table recovery
•
Duplicate database
•
Flashback operations when using shared undo mode
•
Running Data Recovery Advisor
•
Report/delete obsolete
•
Register database
•
Import catalog
•
Reset database
•
Configuring the RMAN environment (using the CONFIGURE command)
4-8
Chapter 4
Making Database Connections with RMAN
Note:
When you connect as TARGET to a PDB, you cannot connect to a recovery
catalog.
4.2.5.3 Connecting as Target to the Root
There are several ways to connect as target to the root.
The three most common ways are as follows:
•
Connecting locally as a common user, as shown in Example 4-14
•
Connecting with operating system authentication, as shown in Example 4-15
•
Connecting as a common user through Oracle Net Services, using a net service
name, as shown in Example 4-16
In all cases, you must connect as a user with the SYSDBA or SYSBACKUP privilege.
Example 4-14
Connecting Locally to the Root
This example connects locally to the root using the SYS user, which is a common user.
The connection is established using the SYSDBA privilege.
rman target sys
target database Password: password
connected to target database: CDB (DBID=659628168)
Example 4-15
Connecting to the Root with Operating System Authentication
This example connects locally to the root using operating system authentication. The
connection is established as the SYS user with SYSDBA privilege.
rman target /
connected to target database: CDB (DBID=659628168)
Example 4-16
Connecting to the Root with a Net Service Name
This example assumes that there is a sales net service name that resolves to a
database service for the root, and that there is a common user named c##bkuser that
has the SYSBACKUP privilege.
rman target c##bkuser@sales
target database Password: password
connected to target database: CDB (DBID=659628168)
4.2.5.4 Connecting as Target to a PDB
You can connect to a PDB either from the RMAN prompt or the operating system
command line.
To connect as target to a PDB, you must:
•
Connect with a net service name that resolves to a database service for that PDB.
4-9
Chapter 4
Making Database Connections with RMAN
•
Connect as a local user or common user with the SYSDBA privilege.
Example 4-17
Connecting As Target to a PDB
This example illustrates a connection to a PDB. It assumes the following
•
You want to perform RMAN operations on a PDB named hrpdb.
•
The net service name hrpdb resolves to a database service for the hrpdb PDB.
•
The local user hrbkup was created in the hrpdb PDB and granted the SYSDBA
privilege.
rman target hrbkup@hrpdb
target database Password: password
connected to target database: CDB (DBID=659628168)
4.2.6 Making RMAN Database Connections Within Command Files
You can make a database connection by creating an RMAN command file containing
a CONNECT command..
If you create an RMAN command file that uses a CONNECT command with database
level credentials (user name and password), then anyone with read access to this file
can learn the password. There is no secure way to incorporate a CONNECT string with a
password into a command file.
If you create an RMAN command file that uses a CONNECT command, then RMAN does
not echo the connect string when you run the command file with the @ command. This
behavior prevents connect strings from appearing in any log files that contain RMAN
output. For example, suppose that you create a command file listbkup.rman as
follows:
cat > listbkup.rman << EOF
CONNECT TARGET /
LIST BACKUP;
EOF
You execute this script by running RMAN with the @ command line option as follows:
% rman @listbkup.rman
When the command file executes, RMAN replaces the connection string with an
asterisk, as shown in the following output:
RMAN> CONNECT TARGET *
2> LIST BACKUP;
3>
connected to target database: RDBMS (DBID=771530996)
using target database control file instead of recovery catalog
List of Backup Sets
===================
. . .
4-10
Chapter 4
Making Database Connections with RMAN
4.2.7 Connecting RMAN to an Auxiliary Database
To use the DUPLICATE command, you must connect to an auxiliary instance. Performing
tablespace point-in-time recovery (TSPITR) may also require a connection to an
auxiliary instance.
The form of an auxiliary connection is identical to a target database connection, except
that you use the AUXILIARY keyword instead of the TARGET keyword.
Note:
When you use the DUPLICATE ... FROM ACTIVE DATABASE command, a net
service name is required. See "Creating an Initialization Parameter File for
the Auxiliary Instance" for more details.
See Also:
•
Duplicating a Database for more details on using the DUPLICATE
command
•
Performing RMAN Tablespace Point-in-Time Recovery (TSPITR) for
more details on performing TSPITR
Example 4-18
Prompt
Connecting to Target and Auxiliary Databases from the RMAN
This example illustrates a connection to a target database using operating system
authentication, and the auxiliary database connection uses a net service name and
password file authentication.
% rman
RMAN> CONNECT TARGET /
RMAN> CONNECT AUXILIARY sbu@aux
auxiliary database Password: password
connected to auxiliary database: AUX (DBID=30472568)
Example 4-19
Prompt
Connecting to Target and Auxiliary Databases from the System
This example illustrates a connection to a target database and an auxiliary database
from the system prompt. The target connection uses operating system authentication
and the auxiliary connection uses a net service name and password file authentication.
% rman target / auxiliary sbu@aux
auxiliary database Password: password
connected to auxiliary database: AUX (DBID=30472568)
4-11
Chapter 4
Specifying the Location of RMAN Output
4.2.8 Diagnosing RMAN Connection Problems
When you are diagnosing errors that RMAN encounters in connecting to the target,
catalog and auxiliary databases, consider using SQL*Plus to connect to the databases
directly. This action can reveal underlying problems with the connection information or
the databases.
This section contains the following topics:
•
Diagnosing Target and Auxiliary Database Connection Problems
•
Diagnosing Recovery Catalog Connection Problems
4.2.8.1 Diagnosing Target and Auxiliary Database Connection Problems
RMAN connects to target and auxiliary databases using the SYSDBA or SYSBACKUP
privilege. Thus, when you use SQL*Plus to diagnose connection problems to the
target or auxiliary databases, request a SYSDBA or SYSBACKUP connection to reproduce
RMAN behavior.
For example, suppose that the following RMAN command encountered connection
errors:
RMAN> CONNECT TARGET /
You reproduce the preceding connection attempt with the SQL*Plus command as
follows:
SQL> CONNECT / AS SYSBACKUP
4.2.8.2 Diagnosing Recovery Catalog Connection Problems
Use SQL*Plus to diagnose recovery catalog connection problems.
When RMAN connects to the recovery catalog database, it does not use the SYSDBA or
SYSBACKUP privilege. When you use SQL*Plus to diagnose connection problems to the
recovery catalog database, you must enter the database connect string exactly as it
was entered into RMAN. Do not specify AS SYSBACKUP or AS SYSDBA.
4.3 Specifying the Location of RMAN Output
By default, RMAN writes command output to standard output. To redirect output to a
log file, enter the LOG parameter on the command line when you start RMAN.
The following example writes RMAN command output to the file rman.log:
% rman LOG /tmp/rman.log
In this case, RMAN displays command input but does not display the RMAN output.
The easiest way to send RMAN output both to a log file and to standard output is to
use the Linux tee command or its equivalent. For example, the following technique
enables both input and output to be visible in the RMAN command-line interface:
% rman | tee rman.log
RMAN>
4-12
Chapter 4
Setting Globalization Support Environment Variables for RMAN
See Also:
Oracle Database Backup and Recovery Reference to learn about RMAN
command-line options
4.4 Setting Globalization Support Environment Variables for
RMAN
Before invoking RMAN, it may be useful to set the NLS_DATE_FORMAT and NLS_LANG
environment variables. These variables determine the format used for the time
parameters in RMAN commands such as RESTORE, RECOVER, and REPORT.
The following example shows typical language and date format settings:
NLS_LANG=american
NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
If you are going to use RMAN to connect to an unmounted database and mount the
database later while RMAN is still connected, then set the NLS_LANG environment
variable so that it also specifies the character set used by the database.
A database that is not mounted assumes the default character set, which is US7ASCII. If
your character set is different from the default, then RMAN returns errors after the
database is mounted. For example, if the character set is WE8DEC, then to avoid errors,
you can set the NLS_LANG variable as follows:
NLS_LANG=american_america.we8dec
For the environment variable NLS_DATE_FORMAT to be applied and override the defaults
set for the server in the server initialization file, the environment variable NLS_LANG must
also be set.
See Also:
•
Oracle Database Reference for more information about the NLS_LANG and
NLS_DATE_FORMAT parameters
•
Oracle Database Globalization Support Guide
4.5 Entering RMAN Commands
You can enter RMAN commands either directly from the RMAN prompt or read them
in from a text file.
This section contains the following topics:
•
Entering RMAN Commands at the RMAN Prompt
•
Using Command Files with RMAN
•
Entering Comments in RMAN Command Files
4-13
Chapter 4
Entering RMAN Commands
•
Using Substitution Variables in Command Files
•
Checking RMAN Syntax
4.5.1 Entering RMAN Commands at the RMAN Prompt
When the RMAN client is ready for your commands, it displays the command prompt
The following is an example of the RMAN command prompt:
RMAN>
Enter commands for RMAN to execute. For example:
RMAN> CONNECT TARGET
RMAN> BACKUP DATABASE;
Most RMAN commands take several parameters and must end with a semicolon.
Some commands, such as STARTUP, SHUTDOWN, and CONNECT, can be used with or without
a semicolon.
When you enter a line of text that is not a complete command, RMAN prompts for
continuation input with a line number. For example:
RMAN> BACKUP DATABASE
2> INCLUDE CURRENT
3> CONTROLFILE
4> ;
4.5.2 Using Command Files with RMAN
For repetitive tasks, you can create a text file containing RMAN commands, and start
the RMAN client with the @ argument, followed by a file name.
For example, create a text file cmdfile1 in the current directory containing one line of
text as shown here:
BACKUP DATABASE PLUS ARCHIVELOG;
You can run this command file from the command line as shown in this example, and
the command contained in it is executed:
% rman TARGET / @cmdfile1
After the command completes, RMAN exits.
You can also use the @ command at the RMAN command prompt to execute the
contents of a command file during an RMAN session. RMAN reads the file and
executes the commands in it. For example:
RMAN> @cmdfile1
After the command file contents have been executed, RMAN displays the following
message:
RMAN> **end-of-file**
Unlike the case where a command file is executed from the operating system
command line, RMAN does not exit.
4-14
Chapter 4
Entering RMAN Commands
See Also:
Oracle Database Backup and Recovery Reference for RMAN command-line
syntax
4.5.3 Entering Comments in RMAN Command Files
The comment character in RMAN is a pound sign (#). All text from the pound sign to
the end of the line is ignored.
For example, the contents of the following command file back up the database and
archived redo log files and include comments:
# Command file name: mybackup.rman
# The following command backs up the database
BACKUP DATABASE;
# The following command backs up the archived redo logs
BACKUP ARCHIVELOG ALL;
The following example shows how you can break a single RMAN command across
multiple lines:
RMAN> BACKUP # this is a comment
2> SPFILE;
4.5.4 Using Substitution Variables in Command Files
When running a command file, you can specify one or more values in a USING clause
for use in substitution variables in a command file. In this way, you can make your
command files dynamic.
As in SQL*Plus, &1 indicates where to place the first value, &2 where to place the
second value, and so on. The substitution variable syntax is &integer followed by an
optional period, for example, &1.3. The optional period is part of the variable and
replaced with the value, thus enabling the substitution text to be immediately followed
by another integer. For example, if you pass the value mybackup to a command file
containing the variable &1.3, then the result of the substitution is mybackup3.
The following procedure explains how to create and use a dynamic shell script that
calls a command file containing substitution variables.
To create and use a dynamic shell script:
1.
Create an RMAN command file that uses substitution variables.
The following example shows the contents of a command file named
quarterly_backup.cmd, which is run every quarter. The script uses substitution
variables for the name of the tape set, for a string in the FORMAT specification, and
for the name of the restore point to be created.
# quarterly_backup.cmd
CONNECT TARGET /
RUN
{
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
4-15
Chapter 4
Entering RMAN Commands
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP DATABASE
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3;
}
EXIT;
2.
Create a shell script that you can use to run the RMAN command file created in
the previous step.
The following example creates a shell script named runbackup.sh. The example
creates shell variables for the format and restore point name and accepts the
values for these variables as command-line arguments to the script.
#!/bin/tcsh
# name: runbackup.sh
# usage: use the tag name and number of copies as arguments
set media_family = $argv[1]
set format = $argv[2]set restore_point = $argv[3]
rman @'/disk1/scripts/quarterly_backup.cmd'
USING $media_family $format $restore_point
3.
Execute the shell script created in the previous step, specifying the desired
arguments on the command line.
The following example runs the runbackup.sh shell script and passes it
archival_backup as the media family name, bck0906 as the format string, and FY06Q3
as the restore point name.
% runbackup.sh archival_backup bck0906 FY06Q3
See Also:
Oracle Database Backup and Recovery Reference for @ syntax
4.5.5 Checking RMAN Syntax
You can test RMAN commands for syntactic correctness without executing them. Use
the command-line argument CHECKSYNTAX to start the RMAN client in a mode in which it
only parses the commands that you enter and returns an RMAN-00558 error for
commands that are not legal RMAN syntax.
You can check the syntax of RMAN commands either at the command line or in
command files.
See Also:
Oracle Database Backup and Recovery Reference to learn about the
CHECKSYNTAX command-line option
4-16
Chapter 4
Entering RMAN Commands
4.5.5.1 Checking RMAN Syntax at the Command Line
You can check the syntax of RMAN commands interactively without actually executing
the commands.
To check RMAN syntax at the command line:
1.
Start RMAN with the CHECKSYNTAX parameter:
% rman CHECKSYNTAX
2.
Enter the RMAN commands to be tested.
The following example shows a sample interactive session, with user-entered text in
bold.
RMAN> run [ backup database; ]
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01006: error signaled during parse
RMAN-02001: unrecognized punctuation symbol "["
RMAN> run { backup database; }
The command has no syntax errors
RMAN>
4.5.5.2 Checking RMAN Syntax in Command Files
To test commands in a command file, start RMAN with the CHECKSYNTAX parameter and
use the @ command to name the command file to be passed.
To test commands in a command file:
1.
Use a text editor to create a command file.
Assume that you create the /tmp/goodcmdfile with the following contents:
# command file with legal syntax
RESTORE DATABASE;
RECOVER DATABASE;
Assume that you create another command file, /tmp/badcmdfile, with the following
contents:
# command file with bad syntax commands
RESTORE DATABASE
RECOVER DATABASE
2.
Run the command file from the RMAN prompt in the following format, where
filename is the name of the command file:
% rman CHECKSYNTAX @filename
Example 4-20
Checking the Syntax of a Command File with Correct Syntax
This example shows the output when you run /tmp/goodcmdfile with CHECKSYNTAX:
4-17
Chapter 4
Using the RMAN Pipe Interface
RMAN> # command file with legal syntax
2> restore database;
3> recover database;
4>
The cmdfile has no syntax errors
Recovery Manager complete.
Example 4-21
Checking the Syntax of a Command File with Bad Syntax
This example shows the output when you run /tmp/badcmdfile with CHECKSYNTAX:
RMAN> #command file with syntax error
2> restore database
3> recover
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found "recover": expecting one of: "archivelog,
channel, check, controlfile, clone, database, datafile, device,
from, force, high, (, preview, ;, skip, spfile, standby, tablespace,
until, validate"
RMAN-01007: at line 3 column 1 file: /tmp/badcmdfile
Example 4-22 Checking the Syntax of a Command File that Contains
Substitution Variables
You make your command files dynamic by including substitution variables. When you
check the syntax of a command file that contains substitution variables, RMAN
prompts you to enter values. This example illustrates what happens if you enter invalid
values when checking the syntax of a dynamic command file. The text in bold
indicates text entered at the prompt.
RMAN> CONNECT TARGET *
2> BACKUP TAG
Enter value for 1: mybackup
abc COPIES
Enter value for 2: mybackup
abc
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "integer"
RMAN-01008: the bad identifier was: mybackup
RMAN-01007: at line 2 column 25 file: /tmp/whole_db.cmd
RMAN indicates a syntax error because the string mybackup is not a valid argument for
COPIES.
4.6 Using the RMAN Pipe Interface
The RMAN pipe interface is an alternative method for issuing commands to RMAN
and receiving the output from those commands. Using this interface, it is possible to
write a portable programmatic interface to RMAN.
With the pipe interface, RMAN obtains commands and sends output by using the
DBMS_PIPE PL/SQL package instead of the operating system shell. The pipe interface is
4-18
Chapter 4
Using the RMAN Pipe Interface
invoked by using the PIPE command-line parameter for the RMAN client. RMAN uses
two private pipes: one for receiving commands and the other for sending output. The
names of the pipes are derived from the value of the PIPE parameter. For example, you
can invoke RMAN with the following command:
% rman PIPE abc TARGET /
RMAN opens the two pipes in the target database: ORA$RMAN_ABC_IN, which RMAN uses
to receive user commands, and ORA$RMAN_ABC_OUT, which RMAN uses to send all output
back to RMAN. All messages on both the input and output pipes are of type VARCHAR2.
RMAN does not permit the pipe interface to be used with public pipes, because they
are a potential security problem. With a public pipe, any user who knows the name of
the pipe can send commands to RMAN and intercept its output.
If the pipes are not initialized, then RMAN creates them as private pipes. If you want to
put commands on the input pipe before starting RMAN, you must first create the pipe
by calling DBMS_PIPE.CREATE_PIPE. Whenever a pipe is not explicitly created as a private
pipe, the first access to the pipe automatically creates it as a public pipe, and RMAN
returns an error if it is told to use a public pipe.
Note:
If multiple RMAN sessions can run against the target database, then you
must use unique pipe names for each RMAN session. The
DBMS_PIPE.UNIQUE_SESSION_NAME function is one method that you can use to
generate unique pipe names.
This section contains the following topics:
•
Executing Multiple RMAN Commands in Succession Through a Pipe: Example
•
Executing RMAN Commands in a Single Job Through a Pipe: Example
4.6.1 Executing Multiple RMAN Commands in Succession Through a
Pipe: Example
This example assumes that the application controlling RMAN wants to run multiple
commands in succession. After each command is sent down the pipe and executed
and the output returned, RMAN pauses and waits for the next command.
To execute RMAN commands through a pipe:
1.
Start RMAN by connecting to a target database (required) and specifying the PIPE
option. For example, enter:
% rman PIPE abc TARGET /
You can also specify the TIMEOUT option, which forces RMAN to exit automatically if
it does not receive any input from the input pipe in the specified number of
seconds. For example, enter:
% rman PIPE abc TARGET / TIMEOUT 60
4-19
Chapter 4
Using the RMAN Pipe Interface
2.
Connect to the target database and put the desired commands on the input pipe
by using DBMS_PIPE.PACK_MESSAGE and DBMS_PIPE.SEND_MESSAGE. In pipe mode, RMAN
issues message RMAN-00572 when it is ready to accept input instead of displaying
the standard RMAN prompt.
3.
Read the RMAN output from the output pipe by using DBMS_PIPE.RECEIVE_MESSAGE
and DBMS_PIPE.UNPACK_MESSAGE.
4.
Repeat Steps 2 and 3 to execute further commands with the same RMAN instance
that was started in Step 1.
5.
If you used the TIMEOUT option when starting RMAN, then RMAN terminates
automatically after not receiving any input for the specified length of time. To force
RMAN to terminate immediately, send the EXIT command.
4.6.2 Executing RMAN Commands in a Single Job Through a Pipe:
Example
This example assumes that the application controlling RMAN wants to run one or more
commands as a single job. After running the commands that are on the pipe, RMAN
exits.
To execute RMAN commands in a single job through a pipe:
1.
After connecting to the target database, create a pipe (if it does not already exist
under the name ORA$RMAN_pipe_IN).
2.
Put the desired commands on the input pipe. In pipe mode, RMAN issues
message RMAN-00572 when it is ready to accept input instead of displaying the
standard RMAN prompt.
3.
Start RMAN with the PIPE option, and specify TIMEOUT 0. For example, enter:
% rman PIPE abc TARGET / TIMEOUT 0
4.
RMAN reads the commands that were put on the pipe and executes them by using
DBMS_PIPE.PACK_MESSAGE and DBMS_PIPE.SEND_MESSAGE. When it has exhausted the
input pipe, RMAN exits immediately.
5.
Read RMAN output from the output pipe by using DBMS_PIPE.RECEIVE_MESSAGE and
DBMS_PIPE.UNPACK_MESSAGE.
See Also:
Oracle Database PL/SQL Packages and Types Reference for
documentation on the DBMS_PIPE package
4-20
5
Configuring the RMAN Environment
This chapter explains the most basic tasks involved in configuring RMAN. This chapter
contains the following topics:
•
About Configuring the Environment for RMAN Backups
•
Configuring RMAN to Make Backups to a Media Manager
•
Configuring RMAN to Make Backups to Recovery Appliance
•
Configuring the Fast Recovery Area
•
Configuring the Backup Retention Policy
•
Backup Optimization and the CONFIGURE command
•
Configuring an Archived Redo Log Deletion Policy
•
Configuring RMAN in a Data Guard Environment
See Also:
•
Configuring the RMAN Environment: Advanced Topics to learn about
configuration options not covered in this chapter, including backup
compression and encryption
•
Appendix C in the Oracle Database Backup and Recovery Reference for
information about configuring RMAN for the Oracle Secure Backup
(OSB) Cloud Module.
5.1 About Configuring the Environment for RMAN Backups
RMAN provides sensible defaults for most parameters required to perform basic
backup and recovery. You can modify the value of default parameters or override
these values for a particular session.
When implementing an RMAN-based backup strategy, you can use RMAN more
effectively if you understand the most common configurations.
To simplify ongoing use of RMAN, you can set several persistent configuration settings
for each target database. These settings control many aspects of RMAN behavior. For
example, you can configure the backup retention policy, default destinations for
backups, default backup device type, and so on. You can use the SHOW and CONFIGURE
commands to view and change RMAN configurations.
This section explains what an RMAN configuration is and how you can use the
CONFIGURE command to change RMAN default behavior for your backup and recovery
environment. This section also introduces the major settings available to you and their
more common values.
5-1
Chapter 5
About Configuring the Environment for RMAN Backups
Note:
If you plan to back up to tape, refer to Configuring RMAN to Make Backups
to a Media Manager.
See Also:
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
5.1.1 Showing and Clearing Persistent RMAN Configurations
You can use the SHOW command to display the current value of RMAN configured
settings for the target database. You can also view whether these commands are
currently set to their default values.
To view or change your CONFIGURE command settings:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Run the RMAN SHOW command.
For example, run SHOW ALL as shown in the following example (sample output
included). The output includes both parameters that you have changed and those
that are set to the default. The configuration is displayed as the series of RMAN
commands required to re-create the configuration. You can save the output in a
text file and use this command file to re-create the configuration on the same or a
different database.
SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; #
default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED
BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR
LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default
5-2
Chapter 5
About Configuring the Environment for RMAN Backups
You can also use the SHOW command with the name of a particular configuration.
For example, you can view the retention policy and default device type as follows:
SHOW RETENTION POLICY;
SHOW DEFAULT DEVICE TYPE;
3.
Optionally, use the CONFIGURE ... CLEAR command to return any configuration to its
default value, as shown in the following examples:
CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
See Also:
Oracle Database Backup and Recovery Reference for SHOW syntax
5.1.2 Configuring the Default Device for Backups: Disk or SBT
Backups for which no destination device type is specified are directed to the
configured default device. RMAN is preconfigured to use disk as the default device
type. No additional configuration is necessary.
You may need to change the default device type from disk to tape, or change it back
from tape to disk. Table 5-1 shows the commands that configure the default device.
Table 5-1
Commands to Configure the Default Device Type
Command
Explanation
CONFIGURE DEFAULT DEVICE
TYPE TO DISK
Specifies that backups go to disk by default.
If a recovery area is enabled, then the backup location defaults
to the fast recovery area. Otherwise, the backup location
defaults to an operating system-specific directory on disk.
When backing up to disk, the logical block size of the database
file must be an even multiple of the physical block size of the
destination device. For example, a device of type DISK with a
block size of 2 kilobytes can only be used as a destination for
backups of database files with logical block sizes of 2 KB, 4
KB, 6 KB, and so on. Most disk drives have physical block
sizes of 512 bytes, so this limitation rarely affects backup to
disk drives. Nevertheless, you can encounter this limitation
when backing up to a writable DVD or a device that has a
larger physical block size.
CONFIGURE DEFAULT DEVICE
TYPE TO sbt
Specifies that backups go to tape by default.
"Configuring RMAN to Make Backups to a Media Manager"
explains how to set up RMAN for use with a media manager.
When RMAN can communicate with the media manager, you
can configure RMAN to make backups to tape and specify
SBT as the default device type.
You can always override the default device by using the DEVICE TYPE clause of the
BACKUP command, as shown in the following examples:
5-3
Chapter 5
About Configuring the Environment for RMAN Backups
BACKUP DEVICE TYPE sbt DATABASE;
BACKUP DEVICE TYPE DISK DATABASE;
To change the configured default device type:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Run the SHOW ALL command to show the currently configured default device.
3.
Run the CONFIGURE DEFAULT DEVICE TYPE command, specifying either TO DISK or TO
sbt.
See Also:
Oracle Database Backup and Recovery Reference for more details on using
the BACKUP command with the DEVICE TYPE clause
5.1.3 Configuring the Default Type for Backups: Backup Sets or
Copies
The BACKUP command can create either backup sets or image copies. For disk, you can
configure RMAN to create either backup sets or image copies as its default backup
type with the CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO command.
Note:
Because RMAN can write an image copy only to disk, the backup type for
tape can only be a backup set.
The default backup type for disk is an uncompressed backup set.
RMAN can create backup sets using binary compression. You can configure RMAN to
use compressed backup sets by default on a device type by specifying the COMPRESSED
option in the BACKUP TYPE TO ... BACKUPSET clause. To disable compression, use the
CONFIGURE DEVICE TYPE command with arguments specifying your other desired
settings, but omit the COMPRESSED keyword.
To configure the default type of backup:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Configure backup sets or image copies as the default backup type.
The following examples configure the backup type for disk backups to copies and
backup sets:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed
The following examples configure compression for backup sets:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
5-4
Chapter 5
About Configuring the Environment for RMAN Backups
See Also:
•
About Backup Sets
•
Making Compressed Backups
5.1.4 Configuring Channels
An RMAN channel is a connection to a database server session. RMAN uses
channels to perform most tasks.
This section contains the following topics:
•
About Channel Configuration
•
Configuring Channels for Disk
•
Configuring Parallel Channels for Disk and SBT Devices
•
Manually Overriding Configured Channels
5.1.4.1 About Channel Configuration
Use the CONFIGURE CHANNEL command to configure options for disk or SBT channels.
You can configure generic channel settings for a device type, that is, a template that is
used for any channels created based on configured settings for that device.
Note:
This section explains configuration of disk channels. To learn how to
configure channels for tape, see Configuring SBT Channels for Use with a
Media Manager.
CONFIGURE CHANNEL takes the same options used to specify one-time options with the
ALLOCATE CHANNEL command.
If you use CONFIGURE CHANNEL to specify generic channel settings for a device, any
previous settings are discarded, even if the settings are not in conflict. For example,
after the second CONFIGURE CHANNEL command, which specifies only the FORMAT for
configured disk channels, the MAXPIECESIZE for the disk channel is returned to its
default value:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;
5.1.4.2 Configuring Channels for Disk
By default, RMAN allocates one disk channel for all operations. You can specify
different options for this channel, for example, a new default location for backups.
5-5
Chapter 5
About Configuring the Environment for RMAN Backups
Example 5-1
Configuring a Nondefault Backup Location
This example configures RMAN to write disk backups to the /disk1 directory and
specifies a nondefault format for the relative file name.
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p';
RMAN automatically replaces the format specifier %t with a four byte time stamp, %s
with the backup set number, and %p with the backup piece number.
Note:
When you configure an explicit format for disk channels, RMAN does not
create backups by default in the fast recovery area. In this case, you lose the
disk space management capabilities of the fast recovery area.
Example 5-2
Configuring an ASM Disk Location
This example demonstrates how to configure an ASM disk location.
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';
See Also:
Backing Up Database Files with RMAN to learn how to make backups
5.1.4.3 Configuring Parallel Channels for Disk and SBT Devices
The number of channels available for a device type when you run a command
determines whether RMAN reads or writes in parallel. As a rule, the number of
channels used in executing a command should match the number of devices
accessed.
For tape backups, allocate one channel for each tape drive. For disk backups, allocate
one channel for each physical disk, unless you can optimize the backup for your disk
subsystem architecture with multiple channels. Failing to allocate the right number of
channels adversely affects RMAN performance during I/O operations.
You can configure channel parallelism settings, binary compression for backup sets,
and other options for an SBT device with CONFIGURE DEVICE TYPE sbt. You set the
configuration for the device type independently of the channel configuration.
Example 5-3
Configuring Parallelism for an SBT Device
This example changes the SBT device (sample output included) so that RMAN can
back up to a media manager using two tape drives in parallel. Each configured SBT
channel backs up approximately half the total data.
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
5-6
Chapter 5
About Configuring the Environment for RMAN Backups
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored
Example 5-4
Configuring the Backup Type for an SBT Device
This example changes the default backup type for the SBT device to an
uncompressed backup set (sample output included).
The CONFIGURE DEVICE TYPE commands used in this example only affect parallelism and
backup type and do not affect the values of settings not specified. In Example 5-3, the
default backup type of compressed backup set was not changed by changing the
parallelism setting. In this example, the ability to use multiple tape drives in parallel is
not affected by changing the default backup type.
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2;
new RMAN configuration parameters are successfully stored
See Also:
•
Specifying Multiple Formats for Disk Backups to learn how to make disk
backups in parallel
•
Oracle Database Backup and Recovery Reference for reference material
on the CHANNEL parameter of the BACKUP command
•
Oracle Real Application Clusters Administration and Deployment Guide
for information about taking advantage of parallel operations in an Oracle
Real Application Clusters (Oracle RAC) configuration
5.1.4.4 Manually Overriding Configured Channels
If you manually allocate a channel during a job, then RMAN disregards any configured
channel settings.
To manually override configured channels:
•
Assume that the default device type is SBT. Run the following command to
override the default configuration.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP TABLESPACE users;
}
In this case, RMAN uses only the disk channel that you manually allocated within
the RUN command, overriding any defaults set by using CONFIGURE DEVICE TYPE,
CONFIGURE DEFAULT DEVICE, or CONFIGURE CHANNEL settings.
5-7
Chapter 5
About Configuring the Environment for RMAN Backups
See Also:
•
About RMAN Channels to learn about configured and allocated channels
•
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL
syntax
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
5.1.5 Configuring Control File and Server Parameter File Autobackups
You can configure RMAN to automatically back up the control file and server
parameter file. The autobackup occurs whenever a backup record is added.
If the database runs in ARCHIVELOG mode, then an autobackup is also taken whenever
the database structure metadata in the control file changes. A control file autobackup
enables RMAN to recover the database even if the current control file, recovery
catalog, and server parameter file are lost.
Because the file name for the autobackup follows a well-known format, RMAN can
search for it without access to a repository and then restore the server parameter file.
After you have started the instance with the restored server parameter file, RMAN can
restore the control file from an autobackup. After you mount the control file, the RMAN
repository is available, and RMAN can restore the data files and find the archived redo
logs.
To enable the autobackup feature:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
To disable the autobackup feature:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
By default, control file autobackups are turned on for CDBs and standalone databases
that have the COMPATIBLE initialization parameter set to 12.2 or higher.
See Also:
•
About RMAN Control File and Server Parameter File Autobackups
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
5.1.5.1 Configuring the Control File Autobackup Format
By default, the format of the autobackup file for all configured devices is the
substitution variable %F in the FORMAT clause.
The %F variable format translates into c-IIIIIIIIII-YYYYMMDD-QQ, with the placeholders
defined as follows:
•
IIIIIIIIII stands for the DBID.
5-8
Chapter 5
About Configuring the Environment for RMAN Backups
•
YYYYMMDD is a time stamp of the day the backup is generated.
•
QQ is the hexadecimal sequence that starts with 00 and has a maximum of FF.
To change the default format for the autobackup file:
•
Use the following command, where deviceSpecifier is any valid device type, and
'string' must contain the substitution variable %F (and no other substitution
variables) and is a valid handle for the specified device:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE deviceSpecifier TO 'string';
For example, you can run the following command to specify a nondefault file name
for the control file autobackup. In the file name, ? stands for ORACLE_HOME.
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '?/oradata/cf_%F';
The following example configures the autobackup to write to an Automatic Storage
Management disk group:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '+dgroup1/%F';
Note:
The valid formats for control file autobackups are: %D, %I, %M, %Y, %F, %T, %d,
and %n. If you use formats other than these, you may not be able to restore
the control file autobackup.
To clear control file autobackup formats for a device:
•
, Use the following commands:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR;
If you have set up a fast recovery area for the database, then you can direct control file
autobackups to the fast recovery area by clearing the control file autobackup format for
disk.
Note:
All files in the fast recovery area are maintained by Oracle Database and
associated file names are maintained in the Oracle Managed Files (OMF)
format.
5-9
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
5.1.5.2 Overriding the Configured Control File Autobackup Format
The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within
a RUN command or at the RMAN prompt, overrides the configured autobackup format in
the current session only.
The order of precedence is:
1.
SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block)
2.
SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt)
3.
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
The following example shows how the two forms of SET CONTROLFILE AUTOBACKUP FORMAT
interact:
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F';
BACKUP AS COPY DATABASE;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck';
BACKUP AS BACKUPSET
DEVICE TYPE DISK
DATABASE;
}
The first SET CONTROLFILE AUTOBACKUP FORMAT controls the name of the control file
autobackup until the RMAN client exits, overriding any configured control file
autobackup format. The SET CONTROFILE AUTOBACKUP FORMAT in the RUN block overrides
the SET CONTROLFILE AUTOBACKUP FORMAT outside the RUN block for the duration of the RUN
block.
5.2 Configuring RMAN to Make Backups to a Media
Manager
On most platforms, to back up to and restore from sequential media such as tape you
must integrate a media management software with your Oracle database. You can use
Oracle Secure Backup, which supports both database and file system backups to
tape, as your media manager.
Note:
You can also use a third-party media manager. This section describes the
generic steps for configuring RMAN for use with a third-party media
manager. The actual steps depend on the media management product that
you install and the platform on which you run the database. If you opt to use
RMAN with a media manager other than Oracle Secure Backup, then you
must obtain all product-specific information from the vendor.
To configure RMAN for use with a media manager:
5-10
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
1.
Ensure that the prerequisites for using a media manager are met as described in
"Prerequisites for Using a Media Manager with RMAN"
2.
Determine the location of the media management library used to communicate
with the sequential media as described in "Determining the Location of the Media
Management Library"
3.
Configure the media management software as described in "Configuring Media
Management Software for RMAN Backups"
4.
Check if RMAN can create backups using the media manager as described in
"Testing Whether the Media Manager Library Is Integrated Correctly"
5.
Configure an RMAN channel that can be used as a default for all tape backups as
described in "Configuring SBT Channels for Use with a Media Manager"
See Also:
•
About Media Management Using RMAN for an overview of media
management software and its implications for RMAN
•
Oracle Secure Backup Administrator's Guide to learn how to set up
RMAN for use specifically with Oracle Secure Backup
5.2.1 Prerequisites for Using a Media Manager with RMAN
Before you can begin using RMAN with a third-party media manager, you must install
the media manager and ensure that RMAN can communicate with it. Refer to the
media management vendor's software documentation for instructions.
In general, you begin by installing and configuring the media management software on
the target host or production network. Ensure that you can make non-RMAN backups
of Hi operating system files on the target database host. This step makes later
troubleshooting much easier by confirming that the basic integration of the media
manager with the target host has been successful. Refer to your media management
documentation to learn how to back up files to the media manager without using
RMAN.
Then, obtain and install the third-party media management module for integration with
the database server. This module contains the media management library that the
Oracle database loads and uses when accessing the media manager. It is generally a
third-party product that must be purchased separately. Contact your media
management vendor for details.
5.2.2 Determining the Location of the Media Management Library
Before attempting to use RMAN with a media manager, determine the location of the
media management library.
When allocating or configuring a channel for RMAN to use to communicate with a
media manager, you must specify the SBT_LIBRARY parameter in an ALLOCATE CHANNEL or
CONFIGURE CHANNEL command. The SBT_LIBRARY parameter specifies the path to the
library.
5-11
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
When RMAN allocates channels to communicate with a media manager, it attempts to
load the library indicated by the SBT_LIBRARY parameter. If you do not provide a value
for the SBT_LIBRARY parameter in an allocated or preconfigured channel, then RMAN
looks in a platform-specific and secured default location.
On Linux and UNIX, the SBT library is loaded from:
/opt/oracle/extapi/[32,64]/{SBT}/{VENDOR}/{VERSION}/libobk.so
The SBT library file name extension name varies according to platform:
•
.so, .sl on HP-UX,
•
.a on AIX,
On Windows, the SBT library is loaded from:
%SYSTEM_DRIVE%\oracle\extapi\[32,64]\{SBT}\{VENDOR}\{VERSION}\orasbt.dll
If RMAN cannot use the secured default location or if you are using Oracle Database
11g or earlier, then RMAN loads the SBT library from the location designated by the
environment variables PATH or LIBPATH.
In some cases, your organization may have security or regulatory compliance
requirements that prohibit the use of environment variables PATH or LIBPATH to
designate a library directory. To disable this behavior, set the PARMS string to
SBT_SECURE=1.
Note:
The default media management library file is not part of the standard
database installation. It is present only if you install third-party media
management software.
See Also:
Your operating system-specific database documentation and the
documentation supplied by your media vendor for instructions on how to
achieve media manager integration on your platform
Example: Configuring the Media Management Library Location
The following example shows the channel syntax, where pathname is the absolute file
name of the library:
CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=pathname';
5-12
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
5.2.3 Configuring Media Management Software for RMAN Backups
After installing the media management software, perform the configuration required by
your vendor so that the software can accept RMAN backups.
Depending on the type of media management software that you installed, you may
have to define media pools, configure users and classes, and so on. Consult your
media management vendor documentation for the appropriate RMAN settings. The
PARMS parameter sends instructions to the media manager. If PARMS values are needed
for the ALLOCATE CHANNEL or the CONFIGURE CHANNEL command, or if a FORMAT string is
recommended for the BACKUP or CONFIGURE command, then refer to the vendor
documentation for this information.
Example 5-5
PARMS Setting for Oracle Secure Backup
This example shows a PARMS setting for Oracle Secure Backup. This PARMS settings
instructs the media manager to back up to a family of tapes called datafile_mf. The
PARMS settings are always vendor-specific.
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';
See Also:
•
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL
syntax
•
Oracle Database Backup and Recovery Reference for channel control
options
•
Oracle Secure Backup Reference for RMAN-specific parameter settings
for Oracle Secure Backup
5.2.4 Testing Whether the Media Manager Library Is Integrated
Correctly
After you have confirmed that the database server can load the media management
library, test to ensure that RMAN can back up to the media manager.
You can perform the following tasks:
•
Testing ALLOCATE CHANNEL on the Media Manager
•
Testing Backup and Restore Operations on the Media Manager
5.2.4.1 Testing ALLOCATE CHANNEL on the Media Manager
The ALLOCATE CHANNEL command is used to perform a basic test of RMAN
communication with the media manager.
To test channel allocation on the media manager:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
5-13
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
2.
Run the ALLOCATE CHANNEL command with the PARMS required by your media
management software.
The following RUN command shows sample vendor-specific PARMS settings:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
}
3.
Examine the RMAN output.
If you do not receive an error message, then the database successfully loaded the
media management library. If you receive the ORA-27211 error, the media
management library could not be loaded:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on c1 channel at 11/30/2007 13:57:18
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25
In this case, check the media management installation to ensure that the library is
correctly installed, and recheck the value for the SBT_LIBRARY parameter as
described in Determining the Location of the Media Management Library.
If the database cannot locate a media management library in the location specified
by the SBT_LIBRARY parameter or the default location, then RMAN issues an
ORA-27211 error and exits.
Whenever channel allocation fails, the database writes a trace file to the trace
subdirectory in the Automatic Diagnostic Repository (ADR) home directory. The
following shows sample output:
SKGFQ OSD: Error in function sbtinit on line 2278
SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log
SBT Initialize failed for /oracle/lib/libobk.so
See Also:
Oracle Database Administrator’s Guide to learn how to use the Automatic
Diagnostic Repository to monitor database operations
5.2.4.2 Testing Backup and Restore Operations on the Media Manager
After testing a channel allocation on the media manager, create and restore a test
backup.
Use the BACKUP and RESTORE commands to perform backup and recovery operations on
the media manager. If the backup and restore operations succeed, then you are ready
to use the media manager with RMAN.
Possible reasons for failures include the following cases:
5-14
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
•
The backup hangs.
A hanging backup usually indicates that the media manager is waiting to mount a
tape. Check if there are any media manager jobs in tape mount request mode and
fix the problem. Ensure that the steps in Configuring RMAN to Make Backups to a
Media Manager are correctly done.
•
The backup fails with ORA-27211: Failed to load Media Management Library.
This error indicates that the media management software is not correctly
configured. Ensure that the steps in Configuring RMAN to Make Backups to a
Media Manager are correctly done. Also, ensure that you have the PARMS and
FORMAT strings required by your media management software.
See Also:
Testing the Media Management API and Troubleshooting RMAN Operations
Example 5-6
Backing Up the Server Parameter File to Tape
You can use the command in this example (substituting the channel settings required
by your media management vendor) to test whether a backup can be created on the
media manager. If your database does not use a server parameter file, then back up
the current control file instead.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
BACKUP SPFILE;
# If your database does not use a server parameter file, use:
# BACKUP CURRENT CONTROLFILE;
}
Example 5-7
Restoring the Server Parameter File from Tape
This example restores the backup created in Example 5-6 to a temporary directory. If
the backup to the media manager succeeds, then attempt to restore the server
parameter file as an initialization parameter file.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
RESTORE SPFILE TO PFILE '/tmp/test_restore.f';
# If your database does not use a server parameter file, use:
# RESTORE CURRENT CONTROLFILE TO '/tmp/test_restore.f';
}
5.2.5 Configuring SBT Channels for Use with a Media Manager
Configuring SBT channels creates a persistent setting that is the default used for
backup and recovery operations with a media manager.
5-15
Chapter 5
Configuring RMAN to Make Backups to a Media Manager
Note:
•
Configuring Advanced Channel Options
•
About Media Manager Backup Piece Names
•
Configuring Automatic SBT Channels
5.2.5.1 About Media Manager Backup Piece Names
A backup piece name is determined by the FORMAT string specified in the BACKUP
command, CONFIGURE CHANNEL command, or ALLOCATECHANNEL command.
The media manager considers the backup piece name as the name of the backup file,
so every backup piece must have a unique name in the media management catalog.
You can use the substitution variables in a FORMAT parameter to generate unique
backup piece names. For example, %d specifies the name of the database, whereas %t
specifies the backup time stamp. For most purposes, you can use %U, in which case
RMAN automatically generates a unique file name. The backup piece name
12i1nk47_1_1 is an example. If you do not specify the FORMAT parameter, then RMAN
automatically generates a unique file name with the %U substitution variable.
Your media manager may impose restrictions on file names and sizes. In this case,
you may need more control over the naming of backup pieces so that they obey media
manager restrictions. For example, some media managers only support a 14-character
backup piece name, and some require special FORMAT strings. The unique names
generated by the %U substitution variable do not exceed 14 characters.
Some media managers may have limits on the maximum size of files that they can
back up or restore. You must ensure that RMAN does not produce backup sets larger
than those limits. To limit backup piece sizes, use the parameter MAXPIECESIZE, which
you can set in the CONFIGURE CHANNEL andALLOCATE CHANNEL commands.
See Also:
•
•
Oracle Database Backup and Recovery Reference
About Number and Size of RMAN Backup Pieces to learn how to set
MAXPIECESIZE
•
Oracle Database Backup and Recovery Reference for the complete list
of variables allowable in format strings with the BACKUP command
•
Your media management documentation to determine the string
character limit for the media manager
5-16
Chapter 5
Configuring RMAN to Make Backups to Recovery Appliance
5.2.5.2 Configuring Automatic SBT Channels
The easiest technique for backing up to a media manager is to configure automatic
SBT channels
As explained in "Configuring the Default Device for Backups: Disk or SBT", you can
use a tape device as your default backup destination.
To configure channels for use with a media manager:
1.
Configure a generic SBT channel.
In the configuration, enter all parameters that you tested in "Testing Backup and
Restore Operations on the Media Manager". The following example configures
vendor-specific channel parameters and sets the default device:
CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS 'ENV=(OB_RESOURCE_WAIT_TIME=1minute,OB_DEVICE=tape1)';
2.
Configure the default device type to SBT, as shown in the following command:
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
If you use multiple tape devices, then you must specify the channel parallelism as
described in "Configuring Parallel Channels for Disk and SBT Devices". The
following configuration enables you to back up to two tape drives in parallel:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
Optionally, check your channel configuration by running the following command:
SHOW CHANNEL FOR DEVICE TYPE sbt;
3.
Make a test backup to tape.
The following command backs up the server parameter file to tape:
BACKUP SPFILE;
4.
List your backups to ensure that the test backup went to the media manager:
LIST BACKUP OF SPFILE;
5.3 Configuring RMAN to Make Backups to Recovery
Appliance
RMAN commands can be used to back up target databases to Zero Data Loss
Recovery Appliance (Recovery Appliance). Certain configuration steps are required to
use the Recovery Appliance as a centralized repository for the target database
backups.
To configure RMAN to create backups to Recovery Appliance:
1.
Ensure that the prerequisites described in "Prerequisites for Using Recovery
Appliance " are met.
2.
Complete the steps listed in "Steps to Configure RMAN for Backups to Recovery
Appliance".
5-17
Chapter 5
Configuring RMAN to Make Backups to Recovery Appliance
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide
5.3.1 Prerequisites for Using Recovery Appliance
Before you can use RMAN to back up a target database to Zero Data Loss Recovery
Appliance (Recovery Appliance), you must install the Recovery Appliance backup
module in the Oracle home of the target database.
The backup module can be installed in the default location or a user-specified location.
Installing the Recovery Appliance backup module creates the shared library used to
transfer backups to the Recovery Appliance and the Oracle wallet containing
credentials used to authenticate the target database with Recovery Appliance.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for information about installing the Recovery Appliance backup
module
5.3.2 Steps to Configure RMAN for Backups to Recovery Appliance
RMAN configuration is required before you can back up Oracle databases to Zero
Data Loss Recovery Appliance (Recovery Appliance).
1.
Determine the location of the Recovery Appliance backup module as described in
"Determining the Location of the Recovery Appliance Backup Module".
2.
Specify Recovery Appliance configuration parameters that must be used by RMAN
to create backups to Recovery Appliance as described in "Specifying Recovery
Appliance Configuration Settings for RMAN Backups".
3.
Allocate one or more RMAN channels that will be used by RMAN to backup the
database to Recovery Appliance.
You must specify the SBT_LIBRARY and the ENV parameters while using Recovery
Appliance. SBT_LIBRARY provides the location of the Recovery Appliance backup
module and ENV provides the configuration parameters.
Instead of allocating RMAN channels, you can also configure an RMAN SBT
channel that will be used to back up to Recovery Appliance. In this case, the
channel configuration is persistent and the settings are applicable until they are
reset (using CONFIGURE command) or overridden for a particular operation using an
ALLOCATE statement.
5-18
Chapter 5
Configuring RMAN to Make Backups to Recovery Appliance
See Also:
•
Example 5-8 and Example 5-9 for examples on configuring RMAN
for Recovery Appliance.
•
Zero Data Loss Recovery Appliance Protected Database
Configuration Guide for information about allocating RMAN channels
5.3.3 Determining the Location of the Recovery Appliance Backup
Module
Before using RMAN to back up target databases to Zero Data Loss Recovery
Appliance (Recovery Appliance), you need to determine the location of the Recovery
Appliance backup module on the target database host. This location is used while
configuring or allocating RMAN channels for Recovery Appliance.
The SBT_LIBRARY parameter in the CONFIGURE or ALLOCATE command specifies the
location of the Recovery Appliance backup module. When RMAN attempts to back up
to Recovery Appliance, it loads the shared library indicated by the SBT_LIBRARY
parameter.
You can specify an absolute path name or a file name for the SBT_LIBRARY parameter. If
you specify a file name, then RMAN searches for the file in an operating systemspecific location. By default, the Recovery Appliance backup module is located
in $ORACLE_HOME/lib/libra.so on UNIX/Linux and in %ORACLE_HOME\database\lib
\libra.sso on Windows.
Example 5-8 Specifying the Recovery Appliance Backup Module Location
During Channel Configuration
The following command configures an RMAN SBT channel by specifying the absolute
path name of the Recovery Appliance backup module on Linux:
CONFIGURE CHANNEL DEVICE TYPE sbt PARAMS 'SBT_LIBRARY=/u01/oracle/lib/libra.so';
5.3.4 Specifying Recovery Appliance Configuration Settings for RMAN
Backups
The client configuration file, stored on the protected database, contains the
configuration settings that are used by the Zero Data Loss Recovery Appliance
(Recovery Appliance) backup module to communicate with the Recovery Appliance.
This file is created automatically when the Recovery Appliance backup module is
installed.
The client configuration file must contain the location of the Oracle wallet that stores
credentials required to authenticate the target database with Recovery Appliance.
Other optional settings may be included.
When using Recovery Appliance, you can include the client configuration settings in
an RMAN command. Use the ENV parameter of the RMAN CONFIGURE CHANNEL or
ALLOCATE CHANNEL command to directly specify client configuration parameters for
Recovery Appliance.
5-19
Chapter 5
Configuring the Fast Recovery Area
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide
Example 5-9
Specifying Recovery Appliance Client Configuration Settings
The following command specifies the Recovery Appliance client configuration settings
directly as part of the CONFIGURE CHANNEL command:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARAMS 'SBT_LIBRARY= libra.so,
ENV=(BA_WALLET=location=file:/home/oracle/product/12.1.0/dbhome_1/wallet
credential_alias=ra-scan:1521/zdlra5:dedicated)';
In this example, ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the
service name of the Recovery Appliance metadata database.
5.4 Configuring the Fast Recovery Area
The fast recovery area feature enables you to set up a disk area where the database
can create and manage a variety of files related to backup and recovery. Use of the
fast recovery area is strongly recommended. Consider configuring a fast recovery area
as a first step in implementing a backup strategy.
This section outlines the functions of the fast recovery area, identifies the files stored
there, explains the rules for file management, and introduces the most important
configuration options. This section contains the following topics:
•
Overview of Files in the Fast Recovery Area
•
Enabling the Fast Recovery Area
•
Disabling the Fast Recovery Area
•
Configuring Locations for Control Files and Redo Logs
•
Configuring RMAN File Creation in the Fast Recovery Area
See Also:
"Maintaining the Fast Recovery Area"
5.4.1 Overview of Files in the Fast Recovery Area
The fast recovery area can contain control files, online redo logs, archived redo logs,
flashback logs, and RMAN backups.
Files in the recovery area are permanent or transient. Permanent files are active files
used by the database instance. All files that are not permanent are transient. In
general, Oracle Database eventually deletes transient files after they become obsolete
under the backup retention policy or have been backed up to tape.
5-20
Chapter 5
Configuring the Fast Recovery Area
The fast recovery area is an Oracle Database managed space that can be used to
hold RMAN disk backups, control file autobackups and archived redo log files. The
files placed in this location are maintained by Oracle Database and the generated file
names are maintained in Oracle Managed Files (OMF) format.
"Table 5-2" describes the files in the recovery area, the classification of each file as
permanent or temporary, and how database availability is affected.
Table 5-2
Files in the Fast Recovery Area
Files
Type
Database Behavior When Fast Recovery Area Is
Inaccessible
Multiplexed copies of the
current control file
Permanent
The instance fails if the database cannot write to a multiplexed
copy of the control file stored in the fast recovery area. Failure
occurs even if accessible multiplexed copies are located outside
the recovery area.
See Also: "Configuring Control File Locations" to learn how to
configure control files in the recovery area
Online redo log files
Permanent
Instance availability is not affected if a mirrored copy of the
online redo log exists in an accessible location outside the fast
recovery area. Otherwise, the instance fails.
See Also: "Configuring Online Redo Log Locations" to learn how
to configure online redo logs in the recovery area
Archived redo log files
Transient
Instance availability is not affected if the log is archived to an
accessible location outside the fast recovery area. Otherwise,
the database eventually halts because it cannot archive the
online redo logs.
See Also: "Configuring Archived Redo Log Locations" to learn
how to configure archived redo logs in the recovery area
Foreign archived redo log files
Transient
Instance availability is not affected.
Note: Foreign archived redo logs are received by a logical
standby database for a LogMiner session. Unlike a normal
archived log, a foreign archived redo log is associated with a
different DBID. For this reason, it cannot be backed up or
restored on a logical standby database.
Image copies of data files and
control files
Transient
Instance availability is not affected.
Backup pieces
Transient
Instance availability is not affected.
Flashback logs
Transient
Instance availability is not affected if guaranteed restore points
are not defined. In this case, the database automatically disables
Flashback Database, writes a message to the alert log, and
continues with database processing. If guaranteed restore points
are configured, the instance fails because of interdependencies
on the flashback logs.
The Oracle Flashback Database feature, which provides a
convenient alternative to database point-in-time recovery
(DBPITR), generates flashback logs. These logs are transient
files and must be stored in the fast recovery area. Unlike other
transient files, flashback logs cannot be backed up to other
media. If the fast recovery area has insufficient space to store
flashback logs and meet other backup retention requirements,
then the recovery area may delete flashback logs.
See Also: "Enabling Flashback Database" to learn how to
enable flashback logging
5-21
Chapter 5
Configuring the Fast Recovery Area
If you are on a Windows platform, then you can use the Volume Shadow Copy Service
(VSS) with the Oracle VSS writer. In this case, the fast recovery area automates
management of files that are backed up in a VSS snapshot and deletes them as
needed.
See Also:
•
Performing Flashback and Database Point-in-Time Recovery
•
Oracle Database Platform Guide for Microsoft Windows to learn about
making backups in a VSS environment
5.4.1.1 Fast Recovery Area with Oracle Managed Files and Automatic Storage
Management
The fast recovery area can be used with Oracle Managed Files (OMF) and Automatic
Storage Management (ASM)
Because the fast recovery area is built on top of OMF, it can be stored anywhere that
Oracle Managed Files can. You can also use the recovery area with ASM.
Even if you choose not to set up the fast recovery area in ASM storage, you can still
use Oracle Managed Files to manage your backup files in an ASM disk group.
However, you lose a major benefit of the fast recovery area: the automatic deletion of
files no longer needed to meet your recoverability goals as space is needed for more
recent backups. Nevertheless, the other automatic features of OMF still function.
When your store backups, using OMF on top of ASM without using a fast recovery
area is supported but discouraged. It is awkward to directly manipulate files under
ASM.
5.4.1.2 How Oracle Manages Disk Space in the Fast Recovery Area
Space in the fast recovery area is balanced among backups and archived logs that
must be kept according to the retention policy, and other files that may be subject to
deletion.
Oracle Database does not delete eligible files from the fast recovery area until the
space must be reclaimed for some other purpose. Files recently moved to tape are
often still available on disk for use in recovery. The recovery area can thus serve as a
cache for tape. When the fast recovery area is full, Oracle Database automatically
deletes eligible files to reclaim space in the recovery area as needed.
See Also:
•
Deletion Rules for the Fast Recovery Area
•
Responding to a Full Fast Recovery Area
5-22
Chapter 5
Configuring the Fast Recovery Area
5.4.2 Enabling the Fast Recovery Area
You enable the fast recovery area by setting two initialization parameters. These
parameters enable the fast recovery area with or without having to shut down and
restart the database instance.
You set the size of the fast recovery area with the parameter
DB_RECOVERY_FILE_DEST_SIZE first, and then you set the physical location of the flash
recovery files with the parameter DB_RECOVERY_FILE_DEST.
Table 5-3 discusses both the mandatory and optional parameters for enabling the fast
recovery area.
In an Oracle Real Application Clusters (Oracle RAC) database, all instances must
have the same values for these initialization parameters. The location must be on a
cluster file system, ASM, or a shared directory.
Table 5-3
Initialization Parameters for the Fast Recovery Area
Initialization Parameter
Required
Description
DB_RECOVERY_FILE_DEST_SIZE
Yes
Specifies the disk quota, which is maximum
storage in bytes of data to be used by the
recovery area for this database. You must set
this parameter before DB_RECOVERY_FILE_DEST.
The DB_RECOVERY_FILE_DEST_SIZE setting does
not include the following kinds of disk overhead:
•
•
Block 0 or the operating system block
header of each Oracle Database file is not
included.
Allow an extra 10% for this data when
computing the actual disk usage required
for the fast recovery area.
DB_RECOVERY_FILE_DEST_SIZE does not
indicate the real size occupied on disk
when the underlying file system is mirrored,
compressed, or affected by overhead not
known to Oracle Database.
For example, if the recovery area is on a
two-way mirrored ASM disk group, each file
of x bytes occupies 2x bytes on the ASM
disk group. In this case, set
DB_RECOVERY_FILE_DEST_SIZE to no more
than half the size of the disks for the ASM
disk group. Likewise, when using a threeway mirrored ASM disk group,
DB_RECOVERY_FILE_DEST_SIZE must be no
more than one third the size of the disks in
the disk group, and so on.
DB_RECOVERY_FILE_DEST
Yes
Specifies the recovery area location, which can
be a file system directory or ASM disk group,
but not a raw disk. The location must be large
enough for the disk quota.
5-23
Chapter 5
Configuring the Fast Recovery Area
Table 5-3
(Cont.) Initialization Parameters for the Fast Recovery Area
Initialization Parameter
Required
Description
DB_FLASHBACK_RETENTION_TARGET
No
Specifies the upper limit (in minutes) on how far
back in time the database may be flashed back.
This parameter is required only for Flashback
Database.
This parameter indirectly determines how much
flashback log data is kept in the recovery area.
The size of flashback logs generated by the
database can vary considerably depending on
the database workload. If more blocks are
affected by database updates during a given
interval, then more disk space is used by the
flashback log data generated for that interval.
See Also:
•
Oracle Database SQL Language Reference for ALTER SYSTEM syntax
•
Oracle Database Administrator’s Guide for details on setting and
changing database initialization parameters
5.4.2.1 Considerations When Setting the Size of the Fast Recovery Area
The larger the fast recovery area is, the more useful it becomes. Ideally, the fast
recovery area is large enough to contain the control files, online redo logs, archived
redo logs, and flashback logs. It should be able to contain a copy of all data files in the
database and the incremental backups used by your chosen backup strategy.
If providing this much space is impractical, then it is best to create an area large
enough to keep a backup of the most important tablespaces and all the archived logs
not yet on tape. At an absolute minimum, the fast recovery area must be large enough
to contain the archived redo logs not yet on tape. If the recovery area has insufficient
space to store new flashback logs and meet other backup retention requirements, then
to make room, the recovery area may delete older flashback logs.
Formulas for estimating a useful fast recovery area size depend on whether:
•
Your database has a small or large number of data blocks that change frequently
•
You store backups only on disk, or on disk and tape
•
You use a redundancy-based backup retention policy, or a recovery windowbased retention policy
•
You plan to use Flashback Database or a guaranteed restore point as alternatives
to point-in-time recovery in response to logical errors
If you plan to enable flashback logging, then the volume of flashback log generation is
approximately the same order of magnitude as redo log generation. For example, if
you intend to set DB_FLASHBACK_RETENTION_TARGET to 24 hours, and if the database
generates 20 gigabytes of redo in a day, then a general rule of thumb is to allow 20
GB to 30 GB of disk space for the flashback logs. The same rule applies to guaranteed
5-24
Chapter 5
Configuring the Fast Recovery Area
restore points when flashback logging is enabled. For example, if the database
generates 20 GB of redo every day, and if the guaranteed restore point is kept for a
day, then plan to allocate 20 to 30 GB.
Suppose that you want to determine the size of a fast recovery area when the backup
retention policy is set to REDUNDANCY 1 and you intend to follow Oracle's suggested
strategy of using an incremental forever. In this example, you use the following formula
to estimate the disk quota, where n is the interval in days between incremental
updates and y is the delay in applying the foreign archived redo logs on a logical
standby database:
Disk
Size
Size
Size
Size
Size
Size
Size
Quota =
of a copy of database +
of an incremental backup +
of (n+1) days of archived redo logs +
of (y+1) days of foreign archived redo logs (for logical standby) +
of control file +
of an online redo log member * number of log groups +
of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)
5.4.2.2 Considerations When Setting the Location of the Fast Recovery Area
Place the fast recovery area on a separate disk from the database area, where the
database maintains active database files such as data files, control files, and online
redo logs. Keeping the fast recovery area on the same disk as the database area
exposes you to loss of both your live database files and backups if a media failure
occurs.
Oracle recommends that DB_RECOVERY_FILE_DEST be set to a different value from
DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n initialization
parameters. The database writes a warning to the alert log if DB_RECOVERY_FILE_DEST
equals these parameters.
Multiple databases can have the same value for DB_RECOVERY_FILE_DEST, but one of the
following must be true:
•
No two databases for which the DB_UNIQUE_NAME initialization parameters are
specified have the same value for DB_UNIQUE_NAME.
•
For those databases where no DB_UNIQUE_NAME is provided, no two databases have
the same value for DB_NAME.
When databases share a single recovery area in this way, the location should be large
enough to hold the files for all databases. Add the values for
DB_RECOVERY_FILE_DEST_SIZE for the databases, then allow for overhead such as
mirroring or compression.
5.4.2.3 Setting the Fast Recovery Area Location and Initial Size
Use database initialization parameters to set the location and size of the fast recovery
area.
Table 5-3 lists the initialization parameters that you must set to enable the fast
recovery area. This section explains how to specify a location for the recovery area
and set its initial size.
5-25
Chapter 5
Configuring the Fast Recovery Area
To determine the optimum size for the fast recovery area and set the recovery
area location:
1.
If you plan to use flashback logging or guaranteed restore points, then query
V$ARCHIVED_LOG to determine how much redo the database generates in the time to
which you intend to set DB_FLASHBACK_RETENTION_TARGET.
2.
Set the recovery area size.
If you plan to use flashback logging or guaranteed restore points, then ensure that
the size value obtained from Step 1 is incorporated into the setting. Set the
DB_RECOVERY_FILE_DEST_SIZE initialization parameter by any of the following means:
•
Shut down the database and set the DB_RECOVERY_FILE_DEST_SIZE parameter in
the initialization parameter file of the database, as shown in the following
example:
DB_RECOVERY_FILE_DEST_SIZE = 10G
•
Specify the parameter with the SQL statement ALTER SYSTEM SET when the
database is open, as shown in the following examples:
ALTER SYSTEM SET
DB_RECOVERY_FILE_DEST_SIZE = 10G
SCOPE=BOTH SID='*';
Note:
The DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST settings
must be persistent across database startup and shutdown. If a
server parameter file is used, then setting SCOPE=BOTH results in the
settings being persistent. However, if a server parameter file is not
used, then the changes made by the ALTER SYSTEM command are not
persistent. You must also add these parameters to the initialization
parameter file.
•
3.
Use the Database Configuration Assistant to set the size.
Set the recovery area location.
Set the initialization parameters by any of the following means:
•
Set DB_RECOVERY_FILE_DEST in the parameter file of the database, as shown in
the following example:
DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'
•
Specify DB_RECOVERY_FILE_DEST with the SQL statement ALTER SYSTEM SET when
the database is open.
The following example sets the fast recovery area to an Automatic Storage
Management (ASM) disk group named disk1:
ALTER SYSTEM SET
DB_RECOVERY_FILE_DEST = '+disk1'
SCOPE=BOTH SID='*';
The following example sets the fast recovery area to the file system directory /
disk1/fast_recovery_area:
5-26
Chapter 5
Configuring the Fast Recovery Area
ALTER SYSTEM SET
DB_RECOVERY_FILE_DEST = '/disk1/fast_recovery_area'
SCOPE = BOTH SID = '*';
•
Use the Database Configuration Assistant to set the location.
If you do not plan to use flashback logging, then open the database (if it is closed)
and do not complete the rest of the steps in this procedure.
4.
If flashback logging is enabled, then run the database under a normal workload for
the time period specified by DB_FLASHBACK_RETENTION_TARGET.
In this way, the database can generate a representative sample of flashback logs.
5.
Query the V$FLASHBACK_DATABASE_LOG view as follows:
SELECT ESTIMATED_FLASHBACK_SIZE
FROM V$FLASHBACK_DATABASE_LOG;
The result is an estimate of the disk space needed to meet the current flashback
retention target, based on the database workload since Flashback Database was
enabled.
6.
If necessary, adjust the flashback log space requirement based on the actual size
of flashback logs generated during the time period specified by
DB_FLASHBACK_RETENTION_TARGET.
See Also:
"Managing Space for Flashback Logs in the Fast Recovery Area"
5.4.3 Disabling the Fast Recovery Area
You can use the ALTER SYSTEM command to disable the fast recovery area.
If you have enabled Flashback Database or use the fast recovery area for archive
logs, then take the appropriate steps from those that follow below. Otherwise, skip to
Step 3:
1.
If Flashback Database is enabled, then disable it before you disable the fast
recovery area.
ALTER DATABASE FLASHBACK OFF;
2.
If you are using the fast recovery area for archive logs, then set the initialization
parameter LOG_ARCHIVE_DEST_n to use a non-fast recovery area location.
For example, to change the fast recovery area for LOG_ARCHIVE_DEST_1 to a non-fast
recovery area location, use the command ALTER SYSTEM SET:
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/ORACLE/DBS/';
3.
Disable the fast recovery area initialization parameter.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='';
5-27
Chapter 5
Configuring the Fast Recovery Area
5.4.4 Configuring Locations for Control Files and Redo Logs
Use initialization parameters to configure the default locations for control files and redo
logs.
See Also:
•
Overview of Files in the Fast Recovery Area
•
Configuring Online Redo Log Locations
•
Configuring Control File Locations
•
Configuring Archived Redo Log Locations
5.4.4.1 Configuring Online Redo Log Locations
The initialization parameters that determine where online redo log files are created are
DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST.
The following SQL statements can create online redo logs in the fast recovery area:
•
CREATE DATABASE
•
ALTER DATABASE ADD LOGFILE
•
ALTER DATABASE ADD STANDBY LOGFILE
•
ALTER DATABASE OPEN RESETLOGS
The default size of an online log created in the fast recovery area is 100 megabytes.
The log member file names are automatically generated by the database.
See Also:
Description of the LOGFILE clause of the CREATE DATABASE statement in Oracle
Database SQL Language Reference for details of the effect of combinations
of the initialization parameters on online redo log creation
5.4.4.2 Configuring Control File Locations
The initialization parameters CONTROL_FILES, DB_CREATE_ONLINE_LOG_DEST_n,
DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST all interact to determine the location
where the database control files are created.
If the database creates an Oracle managed control file, and if the database uses a
server parameter file, then the database sets the CONTROL_FILES initialization parameter
in the server parameter file. If the database uses a client-side initialization parameter
file, then you must set the CONTROL_FILES initialization parameter manually in the
initialization parameter file.
5-28
Chapter 5
Configuring the Fast Recovery Area
See Also:
The "Semantics" section of the description of CREATE CONTROLFILE in Oracle
Database SQL Language Reference for a full description of how these
parameters interact
5.4.4.3 Configuring Archived Redo Log Locations
Oracle recommends that you the use fast recovery area as an archiving location
because the archived logs are automatically managed by the database.
The generated file names for the archived logs in the fast recovery area are for Oraclemanaged files and are not determined by the parameter LOG_ARCHIVE_FORMAT. Whatever
archiving scheme you choose, it is always advisable to create multiple copies of
archived redo logs.
You have the following basic options for archiving redo logs, listed from most to least
recommended:
1.
Enable archiving to the fast recovery area only and use disk mirroring to create the
redundancy needed to protect the archived redo logs.
If DB_RECOVERY_FILE_DEST is specified and no LOG_ARCHIVE_DEST_n is specified, then
LOG_ARCHIVE_DEST_10 is implicitly set to the recovery area. You can override this
behavior by setting LOG_ARCHIVE_DEST_10 to an empty string.
2.
Enable archiving to the fast recovery area and set other LOG_ARCHIVE_DEST_n
initialization parameter to locations outside the fast recovery area.
If a fast recovery area is configured, then you can add the fast recovery area as an
archiving destination by setting any LOG_ARCHIVE_DEST_n parameter to
LOCATION=USE_DB_RECOVERY_FILE_DEST.
3.
Set LOG_ARCHIVE_DEST_n initialization parameters to archive only to non-fast
recovery area locations.
If you use the fast recovery area, then you cannot use the LOG_ARCHIVE_DEST and
LOG_ARCHIVE_DUPLEX_DEST initialization parameters. Using either of these parameters
prevents you from starting the instance. Instead, set the LOG_ARCHIVE_DEST_n
parameters. After your database is using LOG_ARCHIVE_DEST_n, you can configure a
recovery area.
Note also that if you enable archiving but do not set any value for LOG_ARCHIVE_DEST,
LOG_ARCHIVE_DEST_n, or DB_RECOVERY_FILE_DEST, then the redo logs are archived to a
default location that is platform-specific. For example, on Solaris the default is ?/dbs.
See Also:
Oracle Database Reference for details on the semantics of the
LOG_ARCHIVE_DEST_n parameters
5-29
Chapter 5
Configuring the Backup Retention Policy
5.4.5 Configuring RMAN File Creation in the Fast Recovery Area
Certain RMAN commands or implicit actions (such as control file autobackups) can
create files in the fast recovery area.
This section explains how to control whether a command creates files in the fast
recovery area or in another destination. The commands are:
•
BACKUP
If you do not specify the FORMAT clause for disk backups, then RMAN creates
backup pieces and image copies in the fast recovery area, with names in Oracle
Managed Files (OMF) format. If a fast recovery area is enabled, and if you do
specify FORMAT on BACKUP or a channel, then RMAN creates the backup in a
platform-specific location rather than in the recovery area.
•
Control File Autobackup
RMAN can create control file autobackups in the fast recovery area. Use the
RMAN command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
CLEAR to clear any configured format option for the control file autobackup location
on disk. RMAN creates control file autobackups in the fast recovery area when no
other destination is configured.
•
RESTORE ARCHIVELOG
Explicitly or implicitly set a LOG_ARCHIVE_DEST_n parameter to
LOCATION=USE_DB_RECOVERY_FILE_DEST. If you do not specify SET ARCHIVELOG
DESTINATION to override this behavior, then RMAN restores archived redo log files
to the fast recovery area.
•
RECOVER DATABASE or RECOVER TABLESPACE, RECOVER ... BLOCK, and FLASHBACK DATABASE
These commands restore archived redo log files from backup for use during media
recovery, as required by the command. RMAN restores any redo log files needed
during these operations to the fast recovery area and deletes them after they are
applied during media recovery.
To direct the restored archived logs to the fast recovery area, set a
LOG_ARCHIVE_DEST_n parameter to LOCATION = USE_DB_RECOVERY_FILE_DEST. Verify that
you are not using SET ARCHIVELOG DESTINATION to direct restored logs to some other
destination.
5.5 Configuring the Backup Retention Policy
The backup retention policy specifies which backups must be retained to meet your
data recovery requirements.
This policy can be based on a recovery window or redundancy. Use the CONFIGURE
RETENTION POLICY command to specify the retention policy.
This section contains the following topics:
•
Configuring a Redundancy-Based Retention Policy
•
Configuring a Recovery Window-Based Retention Policy
•
Disabling the Retention Policy
5-30
Chapter 5
Configuring the Backup Retention Policy
See Also:
•
About Backup Retention Policies
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
5.5.1 Configuring a Redundancy-Based Retention Policy
The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how
many full or level 0 backups of each data file and control file that RMAN keeps. The
default retention policy is REDUNDANCY 1.
If the number of full or level 0 backups for a specific data file or control file exceeds the
REDUNDANCY setting, then RMAN considers the extra backups as obsolete. As you
produce more backups, RMAN keeps track of which ones to retain and which are
obsolete. RMAN retains all archived logs and incremental backups that are needed to
recover the nonobsolete backups.
Assume that you make a full backup of data file 7 on Monday, Tuesday, Wednesday,
and Thursday. You now have four full backups of this data file. If REDUNDANCY is 2, then
the Monday and Tuesday backups are obsolete. If you make another backup on
Friday, then the Wednesday backup of data file 7 becomes obsolete.
Assume a different case in which REDUNDANCY is 1. You run a level 0 database backup at
noon on Monday, a level 1 cumulative backup at noon on Tuesday and Wednesday,
and a level 0 backup at noon on Thursday. Immediately after each daily backup you
run the command DELETE OBSOLETE. The Wednesday DELETE command does not remove
the Tuesday level 1 backup because this backup is not redundant: the Tuesday level 1
backup could be used to recover the Monday level 0 backup to a time between noon
on Tuesday and noon on Wednesday. However, the DELETE command on Thursday
removes the previous level 0 and level 1 backups.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following
example:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
See Also:
Deleting Obsolete RMAN Backups Based on Retention Policies
5.5.2 Configuring a Recovery Window-Based Retention Policy
The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of
days between the current time and the earliest point of recoverability.
RMAN does not consider any full or level 0 incremental backup as obsolete if it falls
within the recovery window. Additionally, RMAN retains all archived logs and level 1
incremental backups that are needed to recover to a random point within the window.
Use the CONFIGURE RETENTION POLICY command at the RMAN prompt to configure a
recovery window-based retention policy.
5-31
Chapter 5
Backup Optimization and the CONFIGURE command
The following example ensures that you can recover the database to any point within
the last week:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN does not automatically delete backups rendered obsolete by the recovery
window. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in
the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the
DELETE OBSOLETE command.
See Also:
Deleting Obsolete RMAN Backups Based on Retention Policies
5.5.3 Disabling the Retention Policy
When you disable the retention policy, RMAN does not consider any backup as
obsolete.
To disable the retention policy, run this command:
CONFIGURE RETENTION POLICY TO NONE;
Configuring the retention policy to NONE is different from clearing it. Clearing returns the
default setting of REDUNDANCY 1, whereas NONE disables it.
If you disable the retention policy and run REPORT OBSOLETE or DELETE OBSOLETE
commands without passing a retention policy option to the command, then RMAN
issues an error because no retention policy exists to determine which backups are
obsolete.
Caution:
If you are using a fast recovery area, then do not run your database with the
retention policy disabled. If files are never considered obsolete, then a file
can only be deleted from the fast recovery area if it has been backed up to
some other disk location or to a tertiary storage device such as tape. This
action is likely to use all of the space in your recovery area, which interferes
with the normal operation of your database. See "How Oracle Manages Disk
Space in the Fast Recovery Area"
5.6 Backup Optimization and the CONFIGURE command
Run the RMAN CONFIGURE command to enable and disable backup optimization.
Backup optimization skips the backup of files in certain circumstances if the identical
file or an identical version of the file has been backed up.
This section contains the following topics:
•
Overview of Backup Optimization
5-32
Chapter 5
Backup Optimization and the CONFIGURE command
•
Effect of Retention Policies on Backup Optimization for SBT Backups
•
Configuring Backup Optimization
5.6.1 Overview of Backup Optimization
When you enable backup optimization, the BACKUP command skips backing up files
when the identical file has been backed up to the specified device type.
Table 5-4 describes criteria that RMAN uses to determine whether a file is identical to
a file that it already backed up.
Table 5-4
Criteria to Determine an Identical File
Type of File
Criteria to Determine an Identical File
Data file
The data file must have the same DBID, checkpoint SCN,
creation SCN, and RESETLOGS SCN and time as a data file in a
backup. The data file must be offline-normal, read-only, or
closed normally.
Archived log
Same DBID, thread, sequence number, and RESETLOGS SCN
and time
Backup set
Same DBID, backup set record ID, and stamp
If RMAN determines that a file is identical and it has been backed up, then it is a
candidate to be skipped. RMAN must do further checking to determine whether to skip
the file, however, because both the retention policy and the backup duplexing feature
are factors in the algorithm that determines whether RMAN has sufficient backups on
the specified device type.
RMAN uses backup optimization when the following conditions are true:
•
The CONFIGURE BACKUP OPTIMIZATION ON command has been run to enable backup
optimization.
•
You run BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP
BACKUPSET ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES, or BACKUP
DATAFILECOPY.
Note:
When TO DESTINATION is used with BACKUP RECOVERY AREA or BACKUP
RECOVERY FILES, RMAN only skips backups of files that have identical
backups in the TO DESTINATION location that you provide.
•
Only one type of channel is allocated, do not mix disk and SBT channels in the
same backup command.
5-33
Chapter 5
Backup Optimization and the CONFIGURE command
Note:
In backup undo optimization, RMAN excludes undo changes (that are not
needed for recovery of a backup) for transactions that have been committed.
You can enable and disable backup optimization, but backup undo
optimization is built-in behavior.
For example, assume that you have configured backup optimization. These
commands back up to tape the database, all archived logs, and all backup sets:
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
BACKUP DEVICE TYPE sbt BACKUPSET ALL;
If no backed-up file has changed since the last backup, then RMAN does not back up
the files again. RMAN also does not signal an error if it skips all files specified in the
command because the files have already been backed up.
You can override optimization at any time by specifying the FORCE option on the BACKUP
command. For example, you can run:
BACKUP DATABASE FORCE;
BACKUP ARCHIVELOG ALL FORCE;
See Also:
The CONFIGURE entry in Oracle Database Backup and Recovery Reference for
a complete description of the backup optimization rules
5.6.2 Effect of Retention Policies on Backup Optimization for SBT
Backups
Backup optimization is not always applied when backing up to SBT devices.
The exceptions to normal backup optimization behavior for recovery window-based
and redundancy-based retention policies are described in the following sections.
•
About Backup Optimization for SBT Backups with Recovery Window Retention
Policy
•
About Backup Optimization for SBT Backups With Redundancy Retention Policy
•
Configuring Backup Optimization
5-34
Chapter 5
Backup Optimization and the CONFIGURE command
Note:
Use caution when enabling backup optimization if you use a media manager
with its own internal expiration policy. Run the CROSSCHECK command
periodically to synchronize the RMAN repository with the media manager.
Otherwise, RMAN may skip backups due to optimization without recognizing
that the media manager has discarded backups stored on tape.
5.6.2.1 About Backup Optimization for SBT Backups with Recovery Window
Retention Policy
Suppose that backup optimization is enabled, and a recovery window backup retention
policy is in effect. In this case, when performing SBT backups RMAN always backs up
data files whose most recent backup is older than the recovery window.
For example, assume the following scenario:
•
Today is February 21.
•
The recovery window is 7 days.
•
The most recent backup of tablespace tools to tape is January 3.
•
Tablespace tools is read-only.
On February 21, when you issue a command to back up tablespace tools to tape,
RMAN backs it up even though it did not change after the January 3 backup (because
it is read-only). RMAN makes the backup because no backup of the tablespace exists
within the 7-day recovery window.
This behavior enables the media manager to expire old tapes. Otherwise, the media
manager is forced to keep the January 3 backup of tablespace TOOLS indefinitely. By
making a more recent backup of tablespace tools on February 21, RMAN enables the
media manager to expire the tape containing the January 3 backup.
5.6.2.2 About Backup Optimization for SBT Backups With Redundancy
Retention Policy
Assume that you configure a retention policy for redundancy. In this case, RMAN only
skips backups of offline or read-only data files to SBT when there are r + 1 backups of
the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY r.
For example, assume that you enable backup optimization and set the following
retention policy:
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
With these settings, RMAN only skips backups when three identical files are backed
up. Also assume that you have never backed up the users tablespace, which is read/
write, and that you perform the actions described in Table 5-5 over the course of the
week.
5-35
Chapter 5
Backup Optimization and the CONFIGURE command
Table 5-5
Effect of Redundancy Setting on Backup Optimization
Day
Action
Result
Redunda
nt
Backup
Monday
Take users offline
normal.
Tuesday
BACKUP DATABASE
The users tablespace is backed
up.
Wednesday
BACKUP DATABASE
The users tablespace is backed
up.
Thursday
BACKUP DATABASE
The users tablespace is backed
up.
Tuesday
backup
Friday
BACKUP DATABASE
The users tablespace is not
backed up.
Tuesday
backup
Saturday
BACKUP DATABASE
The users tablespace is not
backed up.
Tuesday
backup
Sunday
DELETE OBSOLETE
The Tuesday backup is deleted.
Monday
BACKUP DATABASE
The users tablespace is backed
up.
Wednesd
ay backup
The backups on Tuesday, Wednesday, and Thursday back up the offline users
tablespace to satisfy the condition that three backups must exist (one more than
redundancy setting). The Friday and Saturday backups do not back up the users
tablespace because of backup optimization. The Tuesday backup of users is obsolete
beginning on Thursday.
On Sunday, you delete all obsolete backups, which removes the Tuesday backup of
users. The Tuesday backup is obsolete because of the retention policy setting. The
whole database backup on Monday then backs up the users tablespace to satisfy the
condition that three backups must exist (one more than redundancy setting). In this
way, you can recycle your tapes over time.
See Also:
"Backup Optimization and the CONFIGURE command"
5.6.3 Configuring Backup Optimization
By default, backup optimization is configured to OFF. You can use the SHOW BACKUP
OPTIMIZATION command to view the current settings of backup optimization.
To configure backup optimization:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Run the SHOW BACKUP OPTIMIZATION command to determine whether optimization is
currently enabled.
For example, enter the following command:
5-36
Chapter 5
Configuring an Archived Redo Log Deletion Policy
SHOW BACKUP OPTIMIZATION;
Sample output for SHOW BACKUP OPTIMIZATION follows:
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE BACKUP OPTIMIZATION OFF;
3.
Enable backup optimization by running the following command:
CONFIGURE BACKUP OPTIMIZATION ON;
See Also:
"Using Backup Optimization to Skip Files" for examples of how to optimize
RMAN backups
5.7 Configuring an Archived Redo Log Deletion Policy
You can use RMAN to create a persistent configuration that governs when archived
redo logs are eligible for deletion from disk.
This section contains the following topics:
•
About Archived Redo Log Deletion Policies
•
Enabling an Archived Redo Log Deletion Policy
5.7.1 About Archived Redo Log Deletion Policies
You can use the CONFIGURE ARCHIVELOG DELETION POLICY command to specify when
archived redo logs are eligible for deletion.
This deletion policy applies to all archiving destinations, including the fast recovery
area.
Archived redo logs can be deleted automatically by the database or by user-initiated
RMAN commands. Only logs in the fast recovery area can be deleted automatically by
the database. For archived redo log files in the fast recovery area, the database
retains them as long as possible and automatically deletes eligible logs when
additional disk space is required. You can manually delete eligible logs from any
location, whether inside or outside the fast recovery area, when you issue BACKUP ...
DELETE INPUT or DELETE ARCHIVELOG commands.
5.7.1.1 When the Archived Redo Log Deletion Policy Is Disabled
By default, there is no archived redo log deletion policy and this is why the archive
redo log policy is set to the NONE clause.
In this particular case, the fast recovery area considers archived redo log files in the
recovery area as eligible for deletion if they have been backed up at least once to disk
or SBT or the logs are obsolete according to the backup retention policy. The backup
retention policy considers logs obsolete only if the logs are not needed by a
guaranteed restore point and the logs are not needed by Oracle Flashback Database.
Archived redo logs are needed by Flashback Database if the logs were created later
than SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'.
5-37
Chapter 5
Configuring an Archived Redo Log Deletion Policy
See Also:
•
The CONFIGURE ARCHIVELOG DELETION POLICY entry in Oracle Database
Backup and Recovery Reference for detailed information about policy
options
•
Oracle Data Guard Concepts and Administration to learn how to
configure an archived log deletion policy in a Data Guard environment
5.7.1.2 When the Archived Redo Log Deletion Policy Is Enabled
You can use the CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO
DEVICE TYPE command to enable an archived log deletion policy. This configuration
specifies that archived logs are eligible for deletion only when the specified number of
archived log backups exist on the specified device type.
If the deletion policy is configured with the BACKED UP integer TIMES clause, then a
BACKUP ARCHIVELOG command copies the logs unless integer backups exist on the
specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG
command skips the logs. In this way, the archived log deletion policy functions as a
default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVELOG command. You
can override the deletion policy by specifying the FORCE option on the BACKUP command.
The archived log deletion policy also has options specific to a Data Guard
environment. For example, if you specify the APPLIED ON STANDBY clause, then RMAN
can delete logs after they have been applied at all mandatory remote destinations. If
you specify SHIPPED TO STANDBY, then RMAN can delete logs when they have been
transferred to all mandatory standby destinations.
See Also:
•
The CONFIGURE ARCHIVELOG DELETION POLICY entry in Oracle Database
Backup and Recovery Reference for detailed information about policy
options
•
Oracle Data Guard Concepts and Administration to learn how to
configure an archived log deletion policy in a Data Guard environment
5.7.2 Enabling an Archived Redo Log Deletion Policy
By default the archived redo log deletion policy is set to NONE.
To enable an archived redo log deletion policy:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Run the CONFIGURE ARCHIVELOG DELETION POLICY command with the desired options.
The following example specifies that archived redo logs are eligible to be deleted
from the fast recovery area and all local archiving destinations when logs have
been backed up at least twice to tape:
5-38
Chapter 5
Configuring RMAN in a Data Guard Environment
CONFIGURE ARCHIVELOG DELETION POLICY
TO BACKED UP 2 TIMES TO SBT;
See Also:
•
Deleting Archived Redo Logs After Backups in non-CDBs
•
Oracle Data Guard Concepts and Administration to learn how to manage
archived redo logs in a Data Guard environment
•
Oracle Database Backup and Recovery Reference for a complete
explanation of the CONFIGURE ARCHIVELOG DELETION POLICY command and
the conditions under which archived logs are eligible for deletion
5.8 Configuring RMAN in a Data Guard Environment
If you use RMAN in a Data Guard environment, then you can use the CONFIGURE
command to register and configure settings for the physical databases in this
environment.
RMAN uses the DB_UNIQUE_NAME initialization parameter to distinguish one database
from another. Thus, it is critical that you maintain the uniqueness of the DB_UNIQUE_NAME
in the Data Guard environment.
RMAN must be connected to a recovery catalog when you create or alter a
configuration for a database in the Data Guard environment. If you use the SET DBID
command to set the DBID in the RMAN session, then you can configure a standby
database even when RMAN is not connected as TARGET to a database in the Data
Guard environment. You can even create a configuration for a standby database that
has not yet been created.
You can use the following forms of the CONFIGURE command:
•
CONFIGURE DB_UNIQUE_NAME defines a connection to a physical standby database and
implicitly registers the new database.
New standby databases are also automatically registered when RMAN connects
as TARGET to a standby database for the first time.
•
CONFIGURE FOR DB_UNIQUE_NAME configures settings for a database in the Data Guard
environment.
For example, you can configure channels, default devices, and so on for a
specified database or for all databases in the environment. You can use SHOW ALL
FOR DB_UNIQUE_NAME to show the configuration for a specific standby database or
SHOW ALL FOR DB_UNIQUE_NAME ALL to show configurations for all known databases.
A Data Guard environment involves many considerations that are only relevant for
Data Guard. For example, you can configure an archived redo log deletion policy
based on whether archived logs are transferred to or applied on a standby database.
5-39
Chapter 5
Configuring RMAN in a Data Guard Environment
See Also:
•
Oracle Data Guard Concepts and Administration to learn how to
configure the RMAN environment for use with a standby database
•
Oracle Database Backup and Recovery Reference for a complete
explanation of the CONFIGURE ARCHIVELOG DELETION POLICY command and
the conditions under which archived logs are eligible for deletion
5-40
6
Configuring the RMAN Environment:
Advanced Topics
This chapter describes how to perform setup and configuration tasks. This chapter
contains the following topics:
•
Configuring Advanced Channel Options
•
Configuring Advanced Backup Options
•
Configuring Auxiliary Instance Data File Names
•
Configuring the Snapshot Control File Location
•
Configuring RMAN for Use with a Shared Server
•
Enabling Lost Write Detection
6.1 Configuring Advanced Channel Options
The CONFIGURE CHANNEL command is used to configure RMAN channel options.
This section contains the following topics about advanced channel option:
•
About Channel Control Options
•
Configuring Specific Channel Parameters
See Also:
•
About RMAN Channels for a conceptual overview of configured and
allocated channels
•
Configuring Channels the basics for configuring channels
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
6.1.1 About Channel Control Options
Whether you allocate channels manually or use automatic channel allocation, you can
use channel commands and options to control behavior.
Table 6-1 summarizes the ways in which you can control channel behavior. Unless
noted, all channel parameters are supported in both CONFIGURE CHANNEL and ALLOCATE
CHANNEL commands.
6-1
Chapter 6
Configuring Advanced Channel Options
Table 6-1
Channel Control Options
Type of Channel Control
Commands
Limit I/O bandwidth
consumption
Use the RATE channel parameter to act as a throttling
mechanism for backups.
Limit backup sets and
pieces
Use the MAXPIECESIZE channel parameter to set limits on the
size of backup pieces. You can also use the MAXSETSIZE
parameter on the BACKUP and CONFIGURE commands to set a limit
for the size of backup sets.
Vendor-specific instructions
Use the PARMS channel parameter to specify vendor-specific
information for a media management software. You can also use
the SEND command to send vendor-specific commands to a
media manager.
Channel parallel backup and Use CONFIGURE DEVICE TYPE ... PARALLELISM for persistent
restore operations
channel parallelism or multiple ALLOCATE CHANNEL commands for
job-level parallelism.
Connection settings for
database instances
Specify which instance performs an operation with the CONNECT
channel parameter.
See Also:
•
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL
syntax
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
6.1.2 Configuring Specific Channel Parameters
In addition to configuring parameters that apply to all channels of a particular type, you
can also use the CONFIGURE command to configure parameters that apply to one
specific channel.
Configure specific channels by number when it is necessary to control the parameters
set for each channel separately. This technique is necessary in the following
situations:
•
When running an Oracle Real Application Clusters (Oracle RAC) database in
which individual nodes do not have access to the full set of backups. Each channel
must be configured with a node-specific connect string so that all backups are
accessible by at least one channel.
•
When using a media manager that requires different PARMS settings on each
channel.
To configure specific channel parameters:
•
Run the CONFIGURE CHANNEL n command (where n is a positive integer less than 255)
to configure a specific channel.
When manually numbering channels, you must specify one or more channel
options (for example, MAXPIECESIZE or FORMAT) for each channel. When you use that
6-2
Chapter 6
Configuring Advanced Channel Options
specific numbered channel in a backup, the configured settings for that channel
are used instead of the configured generic channel settings.
See Also:
Oracle Real Application Clusters Administration and Deployment Guide to
learn about RMAN backups in an Oracle RAC environment
6.1.2.1 Configuring Specific Channels: Examples
Example 6-1
Configuring Channel Parallelism for Disk Devices
This example sends disk backups to two different disks. Configure disk channels as
follows:
CONFIGURE DEFAULT DEVICE TYPE TO disk;
# backup goes to disk
CONFIGURE DEVICE TYPE disk PARALLELISM 2;
# two channels used in parallel
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U' # 1st channel to disk1
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U' # 2nd channel to disk2
BACKUP DATABASE; # backup - first channel goes to disk1 and second to disk2
Example 6-2
Configuring Channel Parallelism for Tape Devices
This example configures channels to create parallel database backups. You have two
tape drives and want each drive to use tapes from a different tape media family. The
backup data is divided between the two tape devices. Each configured channel backs
up approximately half the total data.
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
# backup goes to sbt
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # two sbt channels allocated by default
# Configure channel 1 to pool named first_pool
CONFIGURE CHANNEL 1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
# configure channel 2 to pool named second_pool
CONFIGURE CHANNEL 2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=second_pool)';
BACKUP DATABASE; # first stream goes to 'first_pool' and second to 'second_pool'
6.1.2.2 Relationship Between CONFIGURE CHANNEL and Parallelism Setting
The PARALLELISM setting is not constrained by the number of specifically configured
channels.
For example, if you back up to 20 different tape devices, then you can configure 20
different SBT channels, each with a manually assigned number (from 1 to 20) and
each with a different set of channel options. In such a situation, you can set
PARALLELISM to any value up to the number of devices, in this instance 20.
RMAN always numbers parallel channels starting with 1 and ending with the
PARALLELISM setting. For example, if the default device is SBT and parallelism is set to
3, then RMAN names the channels as follows:
ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3
6-3
Chapter 6
Configuring Advanced Backup Options
RMAN always uses the name ORA_SBT_TAPE_n even if you configure DEVICE TYPE sbt (not
the synonymous sbt_tape). RMAN always allocates the number of channels specified
in PARALLELISM, using specifically configured channels if you have configured them and
generic channels if you have not. If you configure specific channels with numbers
higher than the parallelism setting, then this setting prevents RMAN from using them.
See Also:
About RMAN Channels to learn about channels
6.2 Configuring Advanced Backup Options
Backup options enable you to control aspects such as backup size, backup
compression, and backup encryption.
"About Configuring the Environment for RMAN Backups" explains the basics for
configuring RMAN to make backups. This section explains more advanced
configuration options. This section contains the following topics:
•
Configuring the Maximum Size of Backup Sets
•
Configuring the Maximum Size of Backup Pieces
•
Configuring Backup Duplexing
•
Configuring Tablespaces for Exclusion from Whole Database Backups
•
Configuring Compression Options
•
Configuring Backup Encryption
6.2.1 Configuring the Maximum Size of Backup Sets
The CONFIGURE MAXSETSIZE command limits the size of backup sets created on a
channel. This CONFIGURE setting applies to any channel, whether manually allocated or
configured, when the BACKUP command is used to create backup sets. The default
value is given in bytes and is rounded down to the lowest kilobyte value.
In tape backups, it is possible for a multiplexed backup set to span multiple tapes,
which means that blocks from each data file in the backup set are written to multiple
tapes. If one tape of a multivolume backup set fails, then you lose the data on all the
tapes rather than just one. If a backup is not a multisection backup, then a backup set
always includes a whole data file rather than a partial data file. You can use MAXSETSIZE
to specify that each backup set fits on one tape rather than spanning multiple tapes.
The value set by the CONFIGURE MAXSETSIZE command is a default for the given channel.
You can override the configured MAXSETSIZE value by specifying a MAXSETSIZE option for
an individual BACKUP command.
Assume that you issue the following commands at the RMAN prompt:
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
CONFIGURE MAXSETSIZE TO 7500K;
BACKUP TABLESPACE users;
BACKUP TABLESPACE tools MAXSETSIZE 5G;
6-4
Chapter 6
Configuring Advanced Backup Options
The results are as follows:
•
The backup of the users tablespace uses the configured SBT channel and the
configured default MAXSETSIZE setting of 7500K.
•
The backup of the tools tablespace uses the MAXSETSIZE setting of 5G specified in
the BACKUP command.
See Also:
•
Limiting the Size of Backup Sets with BACKUP ... MAXSETSIZE
•
Oracle Database Backup and Recovery Reference for BACKUP syntax
6.2.2 Configuring the Maximum Size of Backup Pieces
Backup piece size is an issue when it exceeds the maximum file size permitted by the
file system or media management software. You can use the MAXPIECESIZE parameter
of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup
pieces.
For example, to limit the backup piece size to 2 gigabytes or less, you can configure
the automatic DISK channel as follows and then run BACKUP DATABASE:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
BACKUP DATABASE;
Note:
In version 2.0 of the media management API, media management vendors
can specify the maximum size of a backup piece that can be written to their
media manager. RMAN respects this limit regardless of the settings that you
configure for MAXPIECESIZE.
See Also:
Oracle Database Backup and Recovery Reference to learn about the
CONFIGURE CHANNEL ... MAXPIECESIZE command
6.2.3 Configuring Backup Duplexing
Use the CONFIGURE ... BACKUP COPIES command to specify how many copies of each
backup piece are created on the specified device type for the specified type of file.
This type of backup is known as a duplexed backup set.
RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape
and disk simultaneously. When backing up to tape, ensure that the number of copies
does not exceed the number of available tape devices. The CONFIGURE settings for
6-5
Chapter 6
Configuring Advanced Backup Options
duplexing only affect backups of data files, control files, and archived logs into backup
sets, and do not affect image copies.
Note:
A control file autobackup is never duplexed.
By default, CONFIGURE ... BACKUP COPIES is set to 1 for each device type.
The following examples show possible duplexing configurations:
# Makes 2 disk copies of each data file and control file backup set
# (autobackups excluded)
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
# Makes 3 copies of every archived redo log backup to tape
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 3;
To return a BACKUP COPIES configuration to its default value, run the same CONFIGURE
command with the CLEAR option, as in the following example:
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt CLEAR;
Note:
If you do not want to create a persistent copies configuration, then you can
specify copies with the BACKUP COPIES and the SET BACKUP COPIES commands.
See Also:
•
About Multiple Copies of RMAN Backups for an overview of duplexed
backups
•
Duplexing Backup Sets to learn how to create duplexed backups
•
Oracle Database Backup and Recovery Reference for BACKUP syntax
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
•
Oracle Database Backup and Recovery Reference for SET syntax
6.2.4 Configuring Tablespaces for Exclusion from Whole Database
Backups
Sometimes you may want to omit a specified tablespace from part of the regular
backup schedule. Use the CONFIGURE command to configure tablespace exclusion.
Here are some possible scenarios to consider:
•
A tablespace is easy to rebuild, so it is more cost-effective to rebuild it than back it
up every day.
6-6
Chapter 6
Configuring Advanced Backup Options
•
A tablespace contains temporary or test data that you do not need to back up.
•
A tablespace does not change often and therefore should be backed up on a
different schedule from other backups.
You can run CONFIGURE EXCLUDE FOR TABLESPACE to exclude the specified tablespace
from the BACKUP DATABASE command. The exclusion condition applies to any data files
that you add to this tablespace in the future.
For example, you can exclude testing tablespaces cwmlite and example from whole
database backups as follows:
CONFIGURE EXCLUDE FOR TABLESPACE cwmlite;
CONFIGURE EXCLUDE FOR TABLESPACE example;
If you run the following command, then RMAN backs up all tablespaces in the
database except cwmlite and example:
BACKUP DATABASE;
You can still back up the configured tablespaces by explicitly specifying them in a
BACKUP command or by specifying the NOEXCLUDE option on a BACKUP DATABASE command.
For example, you can enter one of the following commands:
BACKUP DATABASE NOEXCLUDE; #backs up database, including cwmlite and example
BACKUP TABLESPACE cwmlite, example; # backs up only cwmlite and example
You can disable the exclusion feature for cwmlite and example as follows:
CONFIGURE EXCLUDE FOR TABLESPACE cwmlite CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE example CLEAR;
RMAN includes these tablespaces in future whole database backups.
See Also:
•
Oracle Database Backup and Recovery Reference for BACKUP and
CONFIGURE syntax
6.2.5 Configuring Compression Options
RMAN supports precompression processing and binary compression of backup sets.
The CONFIGURE COMPRESSION ALGORITHM command enables you to configure compression
options.
This following topics contain additional information about compression:
•
About RMAN Precompression Block Processing
•
About RMAN Supported Compression Levels
6.2.5.1 About RMAN Precompression Block Processing
Better backup compression ratios are achieved by consolidating the free space in
each data block, and setting that free space to binary zeroes. This precompression
processing stage has the most benefit for data blocks that have been the subject of
6-7
Chapter 6
Configuring Advanced Backup Options
many deletes and inserts operations. Conversely, it has no effect on data blocks that
are still in their initial loaded state.
The OPTIMIZE FOR LOAD option controls precompression processing. By specifying the
default, OPTIMIZE FOR LOAD TRUE, you ensure that RMAN optimizes CPU usage and
avoids precompression block processing. By specifying OPTIMIZE FOR LOAD FALSE,
RMAN uses additional CPU resources to perform precompression block processing.
See Also:
•
Oracle Database Backup and Recovery Reference for CONFIGURE and SET
syntax
6.2.5.2 About RMAN Supported Compression Levels
Oracle Database provides two categories of compression algorithms: a default
compression algorithm and a group of compression algorithms available with the
Oracle Advanced Compression option.
The default algorithm is a standard feature of Oracle Database while the Oracle
Advanced Compression option is a separately purchased option.
See Also:
•
About RMAN Default Compression
•
About Oracle Advanced Compression Option
6.2.5.2.1 About RMAN Default Compression
Use the CONFIGURE command to configure the default compression algorithm, which
does not require the Oracle Advanced Compression option.
Example 6-3
Configuring Basic Compression for Backup
The following example configures basic compression for RMAN backups..
CONFIGURE COMPRESSION ALGORITHM 'BASIC';
6.2.5.2.2 About Oracle Advanced Compression Option
If you have enabled the Oracle Advanced Compression option, you can choose from
the compression levels listed in the following table.
Compression Level
Performance Benefits and Trade-Offs
HIGH
Best suited for backups over slower networks where the
limiting factor is network speed.
MEDIUM
Recommended for most environments. Good
combination of compression ratios and speed.
6-8
Chapter 6
Configuring Advanced Backup Options
Compression Level
Performance Benefits and Trade-Offs
LOW
Least effect on backup throughput.
The compression ratio generally increases from low to high, with a trade-off of
potentially consuming more CPU resources.
Because the performance of the various compression levels depends on the nature of
the data in the database, network configuration, system resources and the type of
computer system and its capabilities, Oracle cannot document universally applicable
performance statistics. Which level is best for your environment depends on how
balanced your system is regarding bandwidth into the CPU and the actual speed of the
CPU. It is highly recommended that you run tests with the different compression levels
on the data in your environment. Choosing a compression level based on your
environment, network traffic characteristics (workload), and data set is the only way to
ensure that the backup set compression level can satisfy your organization's
performance requirements and applicable service level agreements.
Note:
Restoring a compressed backup is performed inline, and does not require
decompression.
See Also:
•
See Oracle Database Licensing Information for more information about
the Oracle Advanced Compression option.
•
If you are backing up to tape and your tape device performs its own
compression, then do not use both RMAN backup set compression and
the media manager vendor's compression. See the discussion of tuning
RMAN's tape backup performance in Tuning RMAN Performance.
6.2.6 Configuring Backup Encryption
For improved security, you can configure backup encryption for RMAN backup sets.
Encrypted backups cannot be read if they are obtained by unauthorized users.
This section contains the following topics:
•
About Backup Encryption
•
Configuring RMAN Backup Encryption Modes
•
Configuring the Backup Encryption Algorithm
6-9
Chapter 6
Configuring Advanced Backup Options
6.2.6.1 About Backup Encryption
The V$RMAN_ENCRYPTION_ALGORITHMS view contains a list of encryption algorithms
supported by RMAN. If no encryption algorithm is specified, then the default encryption
algorithm is 128-bit Advanced Encryption Standard (AES).
RMAN encryption requires the COMPATIBLE initialization parameter at a target database
to be at least 10.2.0.
The Oracle Secure Backup media management software is the only supported
interface for making encrypted RMAN backups directly to tape. RMAN issues an
ORA-19919 error if you attempt to create encrypted RMAN backups using a media
manager other than Oracle Secure Backup.
When you use the BACKUP BACKUPSET command with encrypted backup sets, the backup
sets are backed up in encrypted form. Because BACKUP BACKUPSET copies an alreadyencrypted backup set to disk or tape, no decryption key is needed during BACKUP
BACKUPSET. The data is never decrypted during any part of the operation. The BACKUP
BACKUPSET command can neither encrypt nor decrypt backup sets.
Encrypted backups are decrypted automatically during restore and recovery, if the
required decryption keys are available. Each backup set gets a separate key. The key
is stored in encrypted form in the backup piece. The backup is decrypted with keys
obtained by a user-supplied password or the Oracle software keystore.
RMAN Encryption Modes
RMAN offers the following encryption modes:
•
Transparent encryption
This is the default mode and uses the Oracle software keystore. A keystore is a
password-protected container used to store a Transparent Data Encryption (TDE)
key. In previous releases, this container was referred to as a wallet.
•
Password encryption
This mode uses only password protection. You must provide a password when
creating and restoring encrypted backups.
•
Dual mode encryption
This mode requires either the keystore or a password.
Note:
Keystore-based encryption is more secure than password-based encryption
because no passwords are involved. Use password-based encryption only
when it is absolutely necessary because your backups must be
transportable.
6-10
Chapter 6
Configuring Advanced Backup Options
See Also:
•
Transparent Encryption of Backups
•
Password Encryption of Backups
•
Dual Mode Encryption of Backups
•
Oracle Database Advanced Security Guide for details about configuring
the Oracle keystore
6.2.6.1.1 Transparent Encryption of Backups
Transparent encryption can create and restore encrypted backups with no DBA
intervention, if the required Oracle key management infrastructure is available.
Transparent encryption is best suited for day-to-day backup operations, where
backups are restored to the same database from which they were created.
Transparent encryption is the default for RMAN encryption.
When you use transparent encryption, you must first configure an Oracle software
keystore for each database. Transparent backup encryption supports both the autologin software keystore and password-based software keystore. When you use the
auto-login software keystore, encrypted backup operations can be performed at any
time, because the auto-login keystore is always open. When you use the passwordbased software keystore, the keystore must be opened before you can perform
backup encryption.
Caution:
If you use an auto-login keystore, do not back it up along with your encrypted
backup data, because users can read the encrypted backups if they obtain
both the backups and the autologin keystore. It is safe to back up the Oracle
keystore because that form of the keystore cannot be used without the
keystore password.
After the Oracle keystore is configured, encrypted backups can be created and
restored with no further DBA intervention. If some columns in the database are
encrypted with Transparent Data Encryption (TDE) column encryption, and if those
columns are backed up using backup encryption, then those columns are encrypted a
second time during the backup. When the backup sets are decrypted during a restore
operation, the encrypted columns are returned to their original encrypted form.
Because the Oracle key management infrastructure archives all previous master keys
in the Oracle keystore, changing or resetting the current database master key does not
affect your ability to restore encrypted backups performed with an older master key.
You can reset the database master key at any time. RMAN can restore all encrypted
backups that were ever created by this database.
6-11
Chapter 6
Configuring Advanced Backup Options
Caution:
If you lose your Oracle keystore, then you are unable to restore any
transparently encrypted backups.
Note:
Oracle Database Advanced Security Guide for information about configuring
an Oracle software keystore
6.2.6.1.2 Password Encryption of Backups
Password encryption requires that the DBA provide a password when creating and
restoring encrypted backups. Restoring a password-encrypted backup requires the
same password that was used to create the backup.
Password encryption is useful for backups that are restored at remote locations, but
which must remain secure in transit. Password encryption cannot be persistently
configured. You do not need to configure an Oracle keystore if password encryption is
used exclusively.
Caution:
If you forget or lose the password that you used to encrypt a passwordencrypted backup, then you are unable to restore the backup.
To use password encryption, use the SET ENCRYPTION ON IDENTIFIED BY password ONLY
command in your RMAN scripts.
6.2.6.1.3 Dual Mode Encryption of Backups
Dual-mode encrypted backups can be restored either transparently or by specifying a
password.
Dual-mode encrypted backups are useful when you create backups that are normally
restored on-site using the Oracle keystore, but which occasionally must be restored
offsite, where the Oracle keystore is not available.
When restoring a dual-mode encrypted backup, you can use either the Oracle
keystore or a password for decryption.
Caution:
If you forget or lose the password that you used to encrypt a dual-mode
encrypted backup and you also lose your Oracle keystore, then you are
unable to restore the backup.
6-12
Chapter 6
Configuring Advanced Backup Options
To create dual-mode encrypted backup sets, specify the SET ENCRYPTION ON IDENTIFIED
BY password command in your RMAN scripts.
6.2.6.2 Configuring RMAN Backup Encryption Modes
You can use the CONFIGURE command to persistently configure transparent encryption
of backups.
You can use the command to specify the following:
•
Whether to use transparent encryptions for backups of all database files
•
Whether to use transparent encryptions for backups of specific tablespaces
•
Which algorithm to use for encrypting backups
You can also use the SET ENCRYPTION command to perform the following actions:
•
Override the encryption settings specified by the CONFIGURE ENCRYPTION command.
For example, you can use SET ENCRYPTION OFF to create an unencrypted backup,
even though a database is configured for encrypted backups.
•
Set a password for backup encryption, persisting until the RMAN client exits.
Because of the sensitive nature of passwords, RMAN does not permit
configuration of passwords that persist across RMAN sessions.
Using or not using persistent configuration settings controls whether archived redo log
backups are encrypted. Backup sets containing archived redo log files are encrypted if
any of the following are true:
•
SET ENCRYPTION ON is in effect when the archive log backup is being created.
•
Encryption is configured for backups of the whole database or at least one
tablespace.
This behavior ensures that the redo associated with any encrypted backup of a data
file is also encrypted.
To configure the environment so that all RMAN backups are encrypted:
1.
Set up the Oracle keystore as explained in Oracle Database Advanced Security
Guide.
2.
Issue the following RMAN command:
CONFIGURE ENCRYPTION FOR DATABASE ON;
At this stage, all RMAN backup sets created by this database use transparent
encryption by default.
You can explicitly override the persistent encryption configuration for an RMAN
session with the following command:
SET ENCRYPTION ON;
The encryption setting remains in effect until you issue the SET ENCRYPTION OFF
command during an RMAN session, or change the persistent setting again with the
following command:
CONFIGURE ENCRYPTION FOR DATABASE OFF;
6-13
Chapter 6
Configuring Auxiliary Instance Data File Names
6.2.6.3 Configuring the Backup Encryption Algorithm
You can use the CONFIGURE command to persistently configure the default algorithm to
use for encryption when writing backup sets.
Possible values are listed in V$RMAN_ENCRYPTION_ALGORITHMS. The default algorithm is
AES 128-bit.
To configure the default backup encryption algorithm:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
2.
Ensure that the target database is mounted or open.
3.
Execute the CONFIGURE ENCRYPTION ALGORITHM command, specifying a valid value
from V$RMAN_ENCRYPTION_ALGORITHMS.ALGORITHM_NAME.
The following example configures the algorithm to AES 256-bit encryption:
CONFIGURE ENCRYPTION ALGORITHM TO 'AES256';
6.3 Configuring Auxiliary Instance Data File Names
You may want to set the names of data files in the auxiliary instance when performing
operations such as data file tablespace point-in-time recovery (TSPITR) or data
transfer with RMAN. You set these names before starting the TSPITR or database
duplication.
The command is as follows, where datafileSpec identifies some data file by its original
name or data file number, and filename is the new path for the specified file:
CONFIGURE AUXNAME FOR datafileSpec TO 'filename';
For example, you might configure a new auxiliary name for data file 2 as follows:
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/newdisk/datafiles/df2.df';
As with other settings, the CONFIGURE command setting persists across RMAN sessions
until cleared with CONFIGURE ... CLEAR, as shown in the following example:
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;
If you are performing TSPITR or running the DUPLICATE command, then by using
CONFIGURE AUXNAME you can preconfigure the file names for use on the auxiliary
database without manually specifying the auxiliary file names during the procedure.
When renaming files with the DUPLICATE command, CONFIGURE AUXNAME is an alternative
to SET NEWNAME command. The difference is that after you set the AUXNAME the first time,
you do not need to reset the file name when you issue another DUPLICATE command;
the AUXNAME setting remains in effect until you issue CONFIGURE AUXNAME ... CLEAR. In
contrast, you must reissue the SET NEWNAME command every time you rename files.
6-14
Chapter 6
Configuring the Snapshot Control File Location
See Also:
•
Performing RMAN Tablespace Point-in-Time Recovery (TSPITR) for
more details on using CONFIGURE AUXNAME for TSPITR
•
Duplicating Databases for more details on using CONFIGURE AUXNAME in
performing database duplication
6.4 Configuring the Snapshot Control File Location
When RMAN needs a read-consistent version of the control file, it creates a temporary
snapshot control file. RMAN needs a snapshot control file when resynchronizing with
the recovery catalog or when making a backup of the current control file.
The default location for the snapshot control file is platform-specific and depends on
the Oracle home of each target database. For example, the default file name on some
Linux platforms is $ORACLE_HOME/dbs/snapcf_@.f. If a fast recovery area is configured for
a target database, then the default location for the snapshot control file is not the fast
recovery area.
This section contains the following topics:
•
Viewing the Configured Location of the Snapshot Control File
•
Setting the Location of the Snapshot Control File
6.4.1 Viewing the Configured Location of the Snapshot Control File
You can see the current snapshot location by running the SHOW command.
This example shows a snapshot location that is determined by the default rule:
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/dbs/snapcf_trgt.f'; # default
This example shows a snapshot control file that has a nondefault file name:
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';
6.4.2 Setting the Location of the Snapshot Control File
Use the CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'filepath' command to change the
name and path of the snapshot control file. Subsequent snapshot control files that
RMAN creates use the specified name and path.
In an Oracle Real Application Clusters (Oracle RAC) environment, the snapshot
control file location must be on shared storage—that is, storage that is accessible to all
Oracle RAC instances.
For example, start RMAN, connect to the target database, and then enter:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';
You can also set the snapshot control file name to a raw device.
6-15
Chapter 6
Configuring RMAN for Use with a Shared Server
To reset the snapshot control file location to the default, run the CONFIGURE SNAPSHOT
CONTROLFILE NAME CLEAR command.
See Also:
•
Resynchronizing the Recovery Catalog
•
Oracle Real Application Clusters Administration and Deployment Guide
for details about handling snapshot control files in Oracle RAC
configurations
6.5 Configuring RMAN for Use with a Shared Server
RMAN cannot connect to a target database through a shared server dispatcher.
RMAN requires a dedicated server process.
If your target database is configured for a shared server, then you must modify your
Oracle Net configuration to provide dedicated server processes for RMAN
connections.
To ensure that RMAN does not connect to a dispatcher when a target database is
configured for a shared server, the net service name used by RMAN must include
(SERVER=DEDICATED) in the CONNECT_DATA attribute of the connect string.
Oracle Net configuration varies greatly from system to system. The following
procedure illustrates only one method. This scenario assumes that the following
service name in tnsnames.ora file connects to a target database using the shared
server architecture, where inst1 is a value of the SERVICE_NAMES initialization parameter:
inst1_shs =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
(CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=shared))
)
To use RMAN with a shared server:
1.
Create a net service name in the tnsnames.ora file that connects to the nonshared
SID. For example, enter:
inst1_ded =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
(CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated))
)
2.
Start SQL*Plus and then connect using both the shared server and dedicated
server service names to confirm the mode of each session.
For example, connect with SYSBACKUP or SYSDBA privilege to inst1_ded and then
execute the following SELECT statement (sample output included):
SQL> SELECT SERVER
2 FROM V$SESSION
3 WHERE SID = (SELECT DISTINCT SID FROM V$MYSTAT);
SERVER
6-16
Chapter 6
Enabling Lost Write Detection
--------DEDICATED
1 row selected.
To connect to a shared server session, connect with SYSBACKUP or SYSDBA privilege
to inst1_shs and then execute the following SELECT statement (sample output
included):
SQL> SELECT SERVER
2 FROM V$SESSION
3 WHERE SID = (SELECT DISTINCT SID FROM V$MYSTAT);
SERVER
--------SHARED
1 row selected.
3.
Start RMAN and connect to the target database using the dedicated service name.
Optionally, connect to a recovery catalog.
See Also:
Your platform-specific Oracle documentation and the Oracle Database
Net Services Reference for a complete description of Oracle Net connect
string syntax
6.6 Enabling Lost Write Detection
A data block lost write occurs when an I/O subsystem acknowledges the completion of
the block write, but the write did not occur in the persistent storage. On a subsequent
block read, the I/O subsystem returns the stale version of the data block, which might
be used to update other blocks of the database, thereby corrupting it.
You can set the DB_LOST_WRITE_PROTECT initialization parameter to TYPICAL or FULL so
that a database records buffer cache block reads in the redo log. The default setting is
NONE. When the parameter is set to TYPICAL, the instance logs buffer cache reads for
read/write tablespaces in the redo log, but not read-only tablespaces. When set to
FULL, the instance also records reads for read-only tablespaces. The performance
overhead for TYPICAL mode is approximately 5 to 10% and potentially higher for FULL
mode.
Lost write detection is most effective when used with Data Guard. In this case, you set
DB_LOST_WRITE_PROTECT in both primary and standby databases. When a standby
database applies redo during managed recovery, it reads the corresponding blocks
and compares the SCNs with the SCNs in the redo log. If the block SCN on the
primary database is lower than on the standby database, then it detects a lost write on
the primary database and throws an external error (ORA-752). If the SCN is higher, it
detects a lost write on the standby database and throws an internal error (ORA-600
[3020]). In either case, the standby database writes the reason for the failure in the
alert log and trace file.
To repair a lost write on a primary database, you must initiate failover to the standby
database. To repair a lost write on a standby database, you must re-create the entire
standby database or restore a backup of only the affected files.
6-17
Chapter 6
Enabling Shadow Lost Write Protection
Enabling lost write detection is also useful when you are not using Data Guard. In this
case, you can encounter a lost write in two ways: during normal database operation or
during media recovery. In the first case, there is no direct way to detect the error.
Indirect symptoms such as inconsistent tables cannot be unambiguously traced to the
lost write. If you retained a backup made before the suspected lost write, however,
then you can restore this backup to an alternative location and recover it. To diagnose
the problem, recover the database or tablespace to the SCN of the stale block read,
which then generates the lost write error (ORA-752).
If a lost write error is encountered during media recovery, the only response is to open
the database with the RESETLOGS option. The database is in a consistent state, but all
data after the RESETLOGS SCN is lost. If you recover a backup made after database
creation, you have no guarantee that other stale blocks have not corrupted the
database. This possibility exists because the restored backup may have been made
after an earlier lost write. To guarantee that no lost writes have corrupted the
database, you must perform media recovery from database creation, which is not a
practical strategy for most database environments.
See Also:
•
Oracle Data Guard Concepts and Administration to learn how to use a
standby database for lost write detection and repair
•
Oracle Database Reference to learn about the DB_LOST_WRITE_PROTECT
initialization parameter
6.7 Enabling Shadow Lost Write Protection
Shadow lost write protection provides fast detection and immediate response to a data
block lost rewrite thereby minimizing data loss and database repair time. A standby
database is not mandatory for using shadow lost write protection.
A data block lost write occurs when an I/O subsystem acknowledges the completion of
a block write, but the write did not occur in the storage. Subsequent block reads will
return the stale version of the data block, which may be used to update other data
blocks, thus corrupting data. Shadow lost write protection uses shadow tablespaces to
store only SCNs for the tracked data files. When a tracked data block is read from
disk, shadow lost write protection detects lost writes by comparing the SCN for the
block in the shadow tablespace with the SCN of the most recent write in the block
being read.
Shadow lost write protection can be enabled at the database level, PDB level,
tablespace level, or data file level. The database compatibility level must be 18.0.0 or
higher.
To use shadow lost write protection:
•
Create one or more shadow tablespaces for shadow lost write protection using the
CREATE BIGFILE TABLESPACE command with the LOST WRITE PROTECTION clause.
•
Enable shadow lost write protection at the required level (database, PDB,
tablespace, or data file). Use the ALTER command with the ENABLE LOST WRITE
PROTECTION clause to enable shadow lost write protection.
6-18
Chapter 6
Enabling Shadow Lost Write Protection
When shadow lost write protection is enabled, RMAN checks the blocks being read for
lost writes. If any lost writes are found, an error is displayed and the backup operation
is aborted.
Note:
Shadow lost write protection is not related to lost write protection that is
configured using the DB_LOST_WRITE_PROTECT initialization parameter.
Related Topics
•
Oracle Database Administrator’s Guide
6-19
7
Using Flashback Database and Restore
Points
This chapter explains Flashback Database and restore points. It discusses configuring,
monitoring, and maintaining these features as part of an overall data protection
strategy.
This chapter contains the following topics:
•
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
•
About Logging for Flashback Database and Guaranteed Restore Points
•
Prerequisites for Flashback Database and Guaranteed Restore Points
•
Using Normal and Guaranteed Restore Points
•
Using Flashback Database
Note:
Detailed information on recovery scenarios that use Flashback Database and
normal and guaranteed restore points can be found in Performing Flashback
and Database Point-in-Time Recovery.
7.1 Overview of Flashback Database, Restore Points and
Guaranteed Restore Points
Oracle Flashback Database and restore points are related data protection features
that enable you to rewind data back in time to correct any problems caused by logical
data corruption or user errors within a designated time window.
These features provide a more efficient alternative to point-in-time recovery and does
not require a backup of the database to be restored first. The effects are similar to
database point-in-time recovery (DBPITR). Flashback Database and restore points are
not only effective in traditional database recovery situations but can also be useful
during database upgrades, application deployments and testing scenarios when test
databases must be quickly created and re-created. Flashback Database also provides
an efficient alternative to rebuilding a failed primary database after a Data Guard
failover.
Restore points provide capabilities related to Flashback Database and other media
recovery operations. In particular, a guaranteed restore point created at a system
change number (SCN) ensures that you can use Flashback Database to rewind the
database to this SCN. You can use restore points and Flashback Database
independently or together.
7-1
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
Flashback Database is accessible through both RMAN and SQL as FLASHBACK
DATABASE . You can use either language to quickly recover the database from logical
data corruption or user errors. The following examples return the database to a
specified SCN or restore point:
FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';
FLASHBACK DATABASE TO SCN 202381;
See Also:
Oracle Data Guard Concepts and Administration
7.1.1 About Flashback Database
Flashback Database is similar to conventional point-in-time recovery in its effects. It
enables you to return a database to its state at a time in the recent past. Flashback
Database is much faster than point-in-time recovery because it does not require
restoring data files from backup and requires applying fewer changes from the
archived redo logs.
You can use Flashback Database to reverse most unwanted changes to a database if
the data files are intact. You can return a database to its state in a previous
incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement.
"Rewinding a Database with Flashback Database" explains how to use the FLASHBACK
DATABASE command to reverse database changes.
Flashback Database uses its own logging mechanism, creating flashback logs and
storing them in the fast recovery area. You can only use Flashback Database if
flashback logs are available. To take advantage of this feature, you must set up your
database in advance to create flashback logs.
To enable Flashback Database, you configure a fast recovery area and set a
flashback retention target. This retention target specifies how far back you can rewind
a database with Flashback Database.
From that time onwards, at regular intervals, the database copies images of each
altered block in every data file into the flashback logs. These block images can later be
reused to reconstruct the data file contents for any moment at which logs were
captured.
When you use Flashback Database to rewind a database to a past target time, the
command determines which blocks changed after the target time and restores them
from the flashback logs. The database restores the version of each block that is
immediately before the target time. The database then uses redo logs to reapply
changes that were made after these blocks were written to the flashback logs.
Redo logs on disk or tape must be available for the entire time period spanned by the
flashback logs. For example, if the flashback retention target is 1 week, then you must
ensure that online and archived redo logs that contain all changes for the past week
are accessible. In practice, redo logs are typically needed much longer than the
flashback retention target to support point-in-time recovery.
7-2
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
7.1.2 About Flashback Database Window
The range of SCNs for which there is currently enough flashback log data to support
the FLASHBACK DATABASE command is called the flashback database window. The
flashback database window cannot extend further back than the earliest SCN in the
available flashback logs.
You cannot back up flashback logs to locations outside the fast recovery area. To
increase the likelihood that enough flashback logs are retained to meet the flashback
database window, you can increase the space in your fast recovery area (see
"Table 5-3").
If the fast recovery area is not large enough to hold the flashback logs and files such
as archived redo logs and other backups needed for the retention policy, then the
database may delete flashback logs from the earliest SCNs forward to make room for
other files. Consequently, the flashback database window can be shorter than the
flashback retention target, depending on the size of the fast recovery area, other
backups that must be retained, and how much flashback logging data is needed. The
flashback retention target is a target, not a guarantee that Flashback Database is
available.
If you cannot use FLASHBACK DATABASE because the flashback database window is not
long enough, then usually you can use database point-in-time recovery (DBPITR) to
achieve a similar result. Guaranteed restore points are the only way to ensure that you
can use Flashback Database to return to a specific point in time or guarantee the size
of the flashback window.
Note:
Some database operations, such as dropping a tablespace or shrinking a
data file, cannot be reversed with Flashback Database. See "Limitations of
Flashback Database" for details.
See Also:
•
Rewinding a Database with Flashback Database to learn about
Flashback Database
•
Performing Database Point-in-Time Recovery to learn about DBPITR
7.1.3 Limitations of Flashback Database
Because Flashback Database works by undoing changes to the data files that exist at
the moment when you run the command, it has certain limitations.
Following are the limitations of Flashback Database:
•
Flashback Database can only undo changes to a data file made by Oracle
Database. It cannot be used to repair media failures, or to recover from accidental
deletion of data files.
7-3
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
•
You cannot use Flashback Database to undo a shrink data file operation.
However, you can take the shrunken file offline, flash back the rest of the
database, and then later restore and recover the shrunken data file.
•
You cannot use Flashback Database alone to retrieve a dropped data file. If you
flash back a database to a time when a dropped data file existed in the database,
only the data file entry is added to the control file. You can only recover the
dropped data file by using RMAN to fully restore and recover the data file.
•
If the database control file is restored from backup or re-created, all accumulated
flashback log information is discarded. You cannot use FLASHBACK DATABASE to
return to a point in time before the restore or re-creation of a control file.
•
When using Flashback Database with a target time at which a NOLOGGING operation
was in progress, block corruption is likely in the database objects and data files
affected by the NOLOGGING operation. For example, if you perform a direct-path
INSERT operation in NOLOGGING mode, and that operation runs from 9:00 to 9:15 on
April 3, 2005, and you later use Flashback Database to return to the target time
09:07 on that date, the objects and data files updated by the direct-path INSERT
may be left with block corruption after the Flashback Database operation
completes.
If possible, avoid using Flashback Database with a target time or SCN that
coincides with a NOLOGGING operation. Also, perform a full or incremental backup of
the affected data files immediately after any NOLOGGING operation to ensure
recoverability to points in time after the operation. If you expect to use Flashback
Database to return to a point in time during an operation such as a direct-path
INSERT, consider performing the operation in LOGGING mode.
See Also:
Oracle Database SQL Language Reference for more information about
operations that support NOLOGGING mode.
7.1.4 About Normal Restore Points
Creating a normal restore point assigns a restore point name to an SCN or specific
point in time.
Thus, a restore point functions as a bookmark or alias for this SCN. Before performing
any operation that you may have to reverse, you can create a normal restore point.
The control file stores the name of the restore point and the SCN.
If you use flashback features or point-in-time recovery, then you can use the name of
the restore point instead of a time or SCN. The following commands support this use
of restore points:
•
The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN
•
The FLASHBACK TABLE statement in SQL
Creating a normal restore point eliminates manually recording an SCN in advance or
determine the correct SCN after the fact by using features such as Flashback Query.
Normal restore points are lightweight. The control file can maintain a record of
thousands of normal restore points with no significant effect on database performance.
7-4
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
Normal restore points eventually age out of the control file if not manually deleted, so
they require no ongoing maintenance.
See Also:
Oracle Database Development Guide to learn how to use Flashback Query
7.1.5 About Guaranteed Restore Points
Like a normal restore point, a guaranteed restore point serves as an alias for an SCN
in recovery operations. A principal difference is that guaranteed restore points never
age out of the control file and must be explicitly dropped.
In general, you can use a guaranteed restore point as an alias for an SCN with any
command that works with a normal restore point. Except as noted, the information
about where and how to use normal restore points applies to guaranteed restore
points as well.
A guaranteed restore point ensures that you can use Flashback Database to rewind a
database to its state at the restore point SCN, even if the generation of flashback logs
is disabled. If flashback logging is enabled, then a guaranteed restore point enforces
the retention of flashback logs required for Flashback Database to any SCN after the
earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind
the database to any SCN in the continuum rather than to a single SCN only.
Note:
If flashback logging is disabled, then you cannot FLASHBACK DATABASE directly
to SCNs between the guaranteed restore points and the current time. You
can, however, flashback to the guaranteed restore point first and then
recover to SCN's between the guaranteed restore point and current time.
If the recovery area has enough disk space to store the needed logs, then you can use
a guaranteed restore point to rewind a whole database to a known good state days or
weeks ago. As with Flashback Database, even the effects of NOLOGGING operations like
direct load inserts can be reversed with guaranteed restore points.
7-5
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
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. See "Limitations of Flashback Database" for details. In addition, when
there are guaranteed restore points in the database, the database
compatibility parameter cannot be set to a higher database version. An
attempt to do so results in an error. This restriction exists because flashback
database is currently unable to reverse the effects of increasing the database
version with the compatibility initialization parameter.
7.1.5.1 Guaranteed Restore Points versus Storage Snapshots
In practice, guaranteed restore points provide a useful alternative to storage
snapshots.
Storage snapshots are often used to protect a database before risky operations such
as large-scale database updates or application patches or upgrades. Rather than
creating a snapshot or duplicate database to test the operation, you can create a
guaranteed restore point on a primary or physical standby database. You can then
perform the risky operation with the certainty that the required flashback logs are
retained.
7.1.6 Overview of Restore Points in a Multitenant Environment
You can create both normal and guaranteed restore points in a multitenant
environment.
The basic concepts of restore points for databases are also applicable to restore
points in a multitenant environment. You can create the following types of restore
points in a multitenant environment:
•
CDB restore point
•
PDB restore point
•
Clean PDB restore point
See Also:
•
Overview of Flashback Database, Restore Points and Guaranteed
Restore Points
•
About CDB Restore Points
•
About Restore Points in PDBs
•
About the Namespace for PDB Restore Points
7-6
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
7.1.6.1 About CDB Restore Points
A CDB restore point serves as an alias for an SCN or a point in time in a multitenant
container database (CDB). It can be a normal restore point or a guaranteed restore
point.
CDB restore points are similar to restore points in a non-CDB, except that you need to
connect to the root as a common user with the SYSDBA or SYSBACKUP privilege to create
them. You can create CDB restore points starting with Oracle Database 12c Release 1
(12.1). CDB restore points are accessible to every pluggable database (PDB) within
the CDB. However, a CDB restore point does not reflect the PDB sub-incarnation of
any of its PDBs.
CDB restore points are useful in the following scenarios:
•
The whole CDB needs to be recovered to a particular point in time
•
Multiple PDBs in a CDB need to be recovered to a particular point in time
See Also:
•
Overview of Restore Points in a Multitenant Environment
•
About Restore Points in PDBs
•
Basic Concepts of Performing Flashback Database for CDBs and PDBs
•
Performing a Flashback Database Operation for a Whole CDB
7.1.6.2 About Restore Points in PDBs
You can create normal and guaranteed restore points in a pluggable database (PDB).
PDB restore points are accessible only to the PDB in which they are defined.
PDB Restore Points
A PDB restore point is a bookmark to a point in time or an SCN in a particular
pluggable database (PDB). It pertains only to the PDB for which it is created and is
only usable for operations on that PDB. A PDB restore point represents the PDB subincarnation of the point in time at which it was created.
PDB restore points can be normal restore points or guaranteed restore points. A
guaranteed PDB restore point guarantees that you can perform a flashback operation
for the PDB to this restore point.
A PDB restore point can be used to perform Flashback Database operations or pointin-time recovery only for the PDB in which it was created.
7-7
Chapter 7
Overview of Flashback Database, Restore Points and Guaranteed Restore Points
Note:
Creating a guaranteed PDB restore point requires careful consideration
because such a restore point can prevent required flashback logs in the
multitenant container database (CDB) from being reused. This can
potentially impact CDB functioning because the fast recovery area could run
out of space.
Clean PDB Restore Points
A clean PDB restore point is a PDB restore point that is created when the PDB is
closed and when there are no outstanding transactions for that PDB. Clean PDB
restore points are only applicable to CDBs that use shared undo.
Clean PDB restore points can be normal or guaranteed restore points. Use the CREATE
CLEAN RESTORE POINT command to explicitly create a clean PDB restore point. For a
CDB that uses shared undo, if a PDB is closed and it has no outstanding transactions,
any PDB restore point created is marked as a clean PDB restore point.
If you anticipate that you may need to rewind a PDB to a particular point in time, for
example, to a state just before an application upgrade, then it is recommended that
you create a clean PDB guaranteed restore point.
For CDBs that use shared undo, a Flashback Database operation to a clean PDB
restore point is faster than a Flashback Database operation to an SCN or other restore
points that are not clean PDB restore points. This is because RMAN does not need to
restore any backups while performing a flashback operation to a clean PDB restore
point.
See Also:
•
About the Namespace for PDB Restore Points
•
About CDB Restore Points
•
Basic Concepts of Performing Flashback Database for CDBs and PDBs
•
Performing a Flashback Database Operation for PDBs
•
About Incarnations of PDBs
7.1.6.3 About the Namespace for PDB Restore Points
Each pluggable database (PDB) has its own namespace for restore points. Therefore,
you can define a PDB restore point with the same name in more than one PDB.
In a multitenant environment, when you use a restore point name in a PDB or for a
PDB operation, the name is first interpreted as a PDB restore point for the concerned
PDB. If a PDB restore point with the specified name is not found, then it is interpreted
as a CDB restore point.
7-8
Chapter 7
About Logging for Flashback Database and Guaranteed Restore Points
See Also:
About Restore Points in PDBs
7.2 About Logging for Flashback Database and Guaranteed
Restore Points
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 fast recovery area. These differences
affect space usage for logs and database performance.
Your recoverability goals partially determine whether to enable logging for flashback
database, or use guaranteed restore points, or both. The implications in performance
and in space usage for these features, separately and when used together, also factor
into your decision.
7.2.1 Guaranteed Restore Points and Fast Recovery Area Space
Usage
Certain rules govern the usage of space in the fast recovery area.
When you create a guaranteed restore point, with or without enabling full flashback
database logging, you must monitor the space available in your fast recovery area.
"Managing Space for Flashback Logs in the Fast Recovery Area" explains how to
monitor fast recovery area disk space usage.
The following rules govern creating, retaining, overwriting and deleting of flashback
logs in the fast recovery area:
•
If the fast recovery area has enough space, then a flashback log is created
whenever necessary to satisfy the flashback retention target.
•
If a flashback log is old enough that it is no longer needed to satisfy the flashback
retention target, then a flashback log is reused.
•
If the database must create a flashback log and the fast recovery area is full or
there is no disk space, then the oldest flashback log is reused instead.
Note:
Reusing the oldest flashback log shortens the flashback database
window. If enough flashback logs are reused due to a lack of disk space,
then the flashback retention target may not be satisfied.
7-9
Chapter 7
About Logging for Flashback Database and Guaranteed Restore Points
•
If the fast recovery area is full, then an archived redo log that is reclaimable
according to the fast recovery area rules may be automatically deleted by the fast
recovery area to make space for other files. In this case, any flashback logs that
require the use of that redo log file for the use of FLASHBACK DATABASE are also
deleted.
Note:
According to fast recovery area rules, a file is reclaimable when one of
the following criteria is true:
•
–
The file is reported as obsolete and not needed by the flashback
database. For example, the file is outside the
DB_FLASHBACK_RETENTION_TARGET parameters.
–
The file is backed up to tape.
Files in the fast recovery area are not eligible for deletion if they are required to
satisfy a guaranteed restore point. However, archived redo logs required to satisfy
a guaranteed restore point may be deleted after they are backed up to disk or
tape. When you use the RMAN FLASHBACK DATABASE command, if the archived redo
logs required to satisfy a specified guaranteed restore point are not available in the
fast recovery area, they are restored from the backups.
Retention of flashback logs and other files required to satisfy the guaranteed
restore point, in addition to files required to satisfy the backup retention policy, can
cause the fast recovery area to fill completely. Consult "Responding to a Full Fast
Recovery Area" if your fast recovery area becomes full.
Caution:
If no files are eligible for deletion from the fast recovery area because of the
requirements imposed by your retention policy and the guaranteed restore
point, then the database performs as if it has encountered a disk full
condition. In many circumstances, this causes your database to halt. See
"Responding to a Full Fast Recovery Area".
7.2.2 About Logging for Guaranteed Restore Points with Flashback
Logging Disabled
Assume that you create a guaranteed restore point when logging for Flashback
Database is disabled. In this case, the first time a data file block is modified after the
time of the guaranteed restore point, the database stores an image of the block before
the modification in the flashback logs. Thus, the flashback logs preserve the contents
of every changed data block when the guaranteed restore point was created. Later
modifications to the same block do not cause the contents to be logged again unless
another guaranteed restore point was created after the block was last modified or a
subsequent flashback database operation has restored the original contents of the
block. When you use Flashback Database to restore a database multiple times to the
same restore point, it is common practise to drop and recreate the guaranteed restore
7-10
Chapter 7
Prerequisites for Flashback Database and Restore Points
point each time. This deletes the old flashback logs and also ensures that the space
quota for the fast recovery area is not exceeded.
This method of logging has the following important consequences:
•
FLASHBACK DATABASE can re-create the data file contents at the time of a guaranteed
restore point by using the block images.
•
For workloads that repeatedly modify the same data, disk space usage can be
less than normal flashback logging. Less space is needed because each changed
block is only logged once. Applications with low volume inserts may benefit from
this disk space saving. This advantage is less likely for applications with high
volume inserts or large batch inserts. The performance overhead of logging for a
guaranteed restore point without flashback database logging enabled can also be
lower.
Assume that your primary goal is the ability to return your database to the time at
which the guaranteed restore point was created. In this case, it is usually more
efficient to turn off flashback logging and use only guaranteed restore points. For
example, suppose that you are performing an application upgrade on a database host
over a weekend. You could create a guaranteed restore point at the start of the
upgrade. If the upgrade fails, then reverse the changes with the FLASHBACK DATABASE
command.
7.2.3 About Logging for Flashback Database with Guaranteed Restore
Points Defined
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.
Flashback logging causes some performance overhead. Depending upon the pattern
of activity on your database, it can also cause significant space pressure in the fast
recovery area. Thus, you should monitor space used in the fast recovery area.
7.3 Prerequisites for Flashback Database and Restore
Points
To ensure successful operation of Flashback Database and guaranteed restore points,
you must first set some key database options.
Flashback Database
Configure the following database settings before enabling Flashback Database:
•
Your database must be running in ARCHIVELOG mode, because archived logs are
used in the Flashback Database operation.
•
You must have a fast recovery area enabled, because flashback logs can only be
stored in the fast recovery area.
7-11
Chapter 7
Using Normal and Guaranteed Restore Points
•
For Oracle Real Application Clusters (Oracle RAC) databases, the fast recovery
area must be in a clustered file system or in ASM.
•
For creating restore points in CDBs, the COMPATIBLE initialization parameter must
be set to 12.1.0 or higher.
Guaranteed Restore Points
To use guaranteed restore points, the database must satisfy the following additional
prerequisite: the COMPATIBLE initialization parameter must be set to 10.2.0 or greater.
Note:
There are no special prerequisites to set before using normal restore points.
Restore Points in PDBs
To create restore points in a pluggable database (PDB), the COMPATIBLE initialization
parameter must be set to 12.2.0 or higher.
7.4 Using Normal and Guaranteed Restore Points
You can create, monitor, and drop both normal and guaranteed restore points.
This section contains the following topics:
•
Creating Normal and Guaranteed Restore Points in non-CDBs
•
Listing Restore Points Using the LIST Command
•
Dropping Restore Points
7.4.1 Creating Normal and Guaranteed Restore Points in non-CDBs
To create normal or guaranteed restore points, use the CREATE RESTORE POINT SQL
statement, providing a name for the restore point and specifying whether it is to be a
guaranteed restore point or a normal one (the default).
To create a restore point:
1.
Connect SQL*Plus to a target database.
See Also:
Oracle Database Administrator’s Guide for using SQL*Plus to connect to
a database
2.
Ensure that the database is open or mounted. If the database is mounted, then it
must have been shut down cleanly (unless it is a physical standby database).
3.
Run the CREATE RESTORE POINT statement.
The following example shows how to create a normal restore point in SQL*Plus:
7-12
Chapter 7
Using Normal and Guaranteed Restore Points
SQL> CREATE RESTORE POINT before_upgrade;
This example shows how to create a guaranteed restore point:
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
See Also:
•
Oracle Database SQL Language Reference for reference information
about the SQL CREATE RESTORE POINT statement
•
"Listing Restore Points Using the LIST Command" to learn how to list
restore point
•
"Dropping Restore Points" to learn how to delete restore points
7.4.2 Creating CDB Restore Points
The CREATE RESTORE POINT SQL command enables you to create normal and
guaranteed restore points in a multitenant container database (CDB).
To create a CDB restore point:
1.
Ensure that the prerequisites described in Prerequisites for Flashback Database
and Restore Points are satisfied.
2.
Connect SQL*Plus to the root as a common user with the SYSDBA or SYSBACKUP
privilege.
3.
Ensure that the CDB is open or mounted. If the CDB is mounted, then it must have
been shut down cleanly (unless it is a physical standby database).
4.
Run the CREATE RESTORE POINT statement to create a CDB restore point.
The following command creates a normal CDB restore point:
SQL> CREATE RESTORE POINT cdb_before_upgrade;
The following command creates a guaranteed CDB restore point:
SQL> CREATE RESTORE POINT cdb_grp_before_upgrade GUARANTEE FLASHBACK DATABASE;
See Also:
•
About CDB Restore Points
•
Creating PDB Restore Points
•
Listing Restore Points Using the V$RESTORE_POINT View
•
Oracle Database Administrator’s Guide for the steps to connect
SQL*Plus to the root
7-13
Chapter 7
Using Normal and Guaranteed Restore Points
7.4.3 Creating PDB Restore Points
You use the CREATE RESTORE POINT SQL statement to create restore points in a
pluggable database (PDB).
The restore point can be a normal PDB restore point, guaranteed PDB restore point,
or clean PDB restore point. You can create PDB restore points either when connected
to the PDB or to the root.
When a PDB uses shared undo, you can create a clean restore point only if the PDB
does not have any outstanding transactions.
To create a PDB restore point when connected to the PDB:
1.
Ensure that the prerequisites described in Prerequisites for Flashback Database
and Restore Points are met.
2.
Connect SQL*Plus to the PDB as a common user or local user with the SYSDBA or
SYSBACKUP privilege.
3.
If you are creating a clean PDB restore point in a CDB that uses shared undo,
then the PDB must be closed.
The following command displays the state of the PDB:
SQL> SELECT name, open_mode FROM V$PDBs;
Use the following command to close the PDB:
SQL> ALTER PLUGGABLE DATABASE CLOSE;
4.
If the multitenant container database (CDB) is in mounted state, then it must have
been shut down consistently (unless it is a physical standby database).
5.
Set the current container to the PDB.
The following command sets to current container to the PDB my_pdb:
SQL> ALTER SESSION SET CONTAINER=my_pdb;
6.
Create a PDB restore point by using the CREATE RESTORE POINT command.
The following command creates a normal PDB restore point:
SQL> CREATE RESTORE POINT before_patching;
The following command creates a guaranteed PDB restore point:
SQL> CREATE RESTORE POINT before_upgrade GUARENTEE FLASHBACK DATABASE;
The following command explicitly creates a clean PDB restore point. If a clean
restore point cannot be created, then an error is returned.
SQL> CREATE CLEAN RESTORE POINT before_patching;
To create a PDB restore point when connected to the CDB:
1.
Ensure that the prerequisites described in Prerequisites for Flashback Database
and Restore Points are met.
2.
Connect SQL*Plus to the root as a common user with the SYSDBA or SYSBACKUP
privilege.
7-14
Chapter 7
Using Normal and Guaranteed Restore Points
3.
If you are creating a clean PDB restore point in a CDB that uses shared undo,
then the PDB must be closed.
The following command closes the PDB my_pdb:
SQL> ALTER PLUGGABLE DATABASE my_pdb CLOSE;
4.
The CDB that contains the PDB can be open or mounted. If the CDB is mounted,
then it must have been shut down consistently (unless it is a physical standby
database).
The following commands place the CDB in a mounted state:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
5.
Set the current container to the root.
SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;
6.
Create a PDB restore point by using the CREATE RESTORE POINT command with the
FOR PLUGGABLE DATABASE clause.
The following command creates a normal PDB restore point:
SQL> CREATE RESTORE POINT mypdb_before_patching FOR PLUGGABLE DATABASE my_pdb;
The following command creates a guaranteed PDB restore point:
SQL> CREATE RESTORE POINT mypdb_grp_before_upgrade FOR PLUGGABLE DATABASE my_pdb
GUARANTEE FLASHBACK DATABASE;
The following command explicitly creates a clean PDB restore point (when the
PDB is closed and has no pending transactions). If the restore point cannot be
created, then an error is displayed.
SQL> CREATE CLEAN RESTORE POINT mypdb_crp_before_patching FOR PLUGGABLE DATABASE
my_pdb;
See Also:
•
About Undo and Flashback Database Operations for PDBs
•
About Restore Points in PDBs
•
Creating CDB Restore Points
•
Oracle Database Administrator’s Guide for the steps to connect
SQL*Plus to the root
•
Listing Restore Points Using the V$RESTORE_POINT View
7.4.4 Listing Restore Points Using the LIST Command
You can use the LIST command to list either a specific restore point or all restore
points known to the RMAN repository. The variations of the command are as follows:
LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;
7-15
Chapter 7
Using Normal and Guaranteed Restore Points
RMAN indicates the SCN and time of the restore point, the type of restore point, and
the name of the restore point. The following example shows sample output:
RMAN> LIST RESTORE POINT ALL;
using target database control file instead of recovery catalog
SCN
RSP Time Type
Time
Name
---------------- --------- ---------- --------- ---341859
28-APR-15
28-APR-15 NORMAL_RS
343690
28-APR-15 GUARANTEED 28-APR-15 GUARANTEED_RS
Note:
The LIST command does not display details such as the PDB incarnation
number and whether a restore point is a PDB restore point. To view
additional details about restore points in a multitenant environment, see
Listing Restore Points Using the V$RESTORE_POINT View.
See Also:
"Rewinding a Database with Flashback Database"
7.4.5 Listing Restore Points Using the V$RESTORE_POINT View
You can use the V$RESTORE_POINT control file view to obtain information about all
currently-defined restore points (normal and guaranteed), including CDB restore points
and PDB restore points.
The V$RESTORE_POINT view contains additional information about restore points in a
multitenant environment that is not displayed by the LIST RESTORE POINT command.
This includes details such as the incarnation of the pluggable database (PDB) in which
a PDB restore point was created and whether a restore point is a PDB restore point or
clean PDB restore point.
The following steps display information about PDB restore points for all PDBs in the
CDB:
1.
2.
Connect SQL*Plus to the target database. If the target database is a multitenant
container database (CDB), then connect to the root.
•
To view restore points for all PDBs, you must connect to the root as a common
use with the SYSDBA or SYSBACKUP privilege.
•
To view the restore points in a particular PDB, you can connect to that PDB as
a common user or local user with the SYSDBA or SYSBACKUP privilege.
Query the V$RESTORE_POINT view to display information about restore points.
Example 7-1
Displaying Restore Points in a Multitenant Environment
The following query displays details about all restore points in a multitenant
environment (query output formatted to fit in the page):
7-16
Chapter 7
Using Normal and Guaranteed Restore Points
SELECT name, guarantee_flashback_database, pdb_restore_point,
clean_pdb_restore_point, pdb_incarnation#, storage_sizeFROM v$restore_point;
NAME
GUARANTEE_ PDB_RESTORE_POINT CLEAN_PDB_RESTORE_POINT
STORAGE_SIZE
----------------- ---------------- ---------------------------------CDB_GRP_BEFORE_PATCH
YES
NO
NO
84586
PDB_GRP_BEFORE_UPGRADE_TEMP
YES
YES
NO
4562
CDB_RP1
NO
NO
NO
0
PDB1_BEFORE_PATCHING
NO
YES
NO
0
MYPDB_CLEAN_GRP_BEFORE_UPGRADE NO
YES
YES
0
For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points,
STORAGE_SIZE indicates the approximate number of bytes of disk space in the fast
recovery area that is tied up retaining logs required to guarantee FLASHBACK DATABASE to
that restore point.
See Also:
•
Oracle Database Reference for information about V$RESTORE_POINT
•
Listing Restore Points Using the LIST Command
•
Rewinding a Database with Flashback Database
•
Performing a Flashback Database Operation for a Whole CDB
•
Performing a Flashback Database Operation for PDBs
7.4.6 Dropping Restore Points
When you are satisfied that you do not need an existing restore point, or when you
want to create a restore point with the name of an existing restore point, you can drop
the restore point, using the DROP RESTORE POINT SQL*Plus statement.
For example:
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
The same statement is used to drop both normal and guaranteed restore points.
7-17
Chapter 7
Using Flashback Database
Note:
Normal restore points eventually age out of the control file, even if not
explicitly dropped. The rules governing retention of restore points in the
control file are:
•
The most recent 2048 restore points are always kept in the control file,
regardless of their age.
•
Any restore point more recent than the value of
CONTROL_FILE_RECORD_KEEP_TIME is retained, regardless of how many
restore points are defined.
Normal restore points that do not meet either of these conditions may age
out of the control file.
Guaranteed restore points never age out of the control file. They remain until they are
explicitly dropped.
See also:
Oracle Database SQL Language Reference for reference information about
the SQL DROP RESTORE POINT statement
7.5 Using Flashback Database
To use flashback logging for a target database, you must enable Flashback Database.
Certain guidelines can be followed to ensure optimal performance of Flashback
Database.
This section contains the following topics:
•
Enabling Flashback Database
•
Disabling Flashback Database Logging
•
Configuring the Environment for Optimal Flashback Database Performance
•
Monitoring the Effect of Flashback Database on Performance
•
About Flashback Writer (RVWR) Behavior with I/O Errors
7.5.1 Enabling Flashback Database
Use the ALTER DATABASE command to enable Flashback Database
To enable flashback logging:
1.
Configure the recovery area as described in "Enabling the Fast Recovery Area".
2.
Ensure the database instance is open or mounted. If the instance is mounted, then
the database must be shut down cleanly unless it is a physical standby database.
Other Oracle Real Application Clusters (Oracle RAC) instances can be in any
mode.
7-18
Chapter 7
Using Flashback Database
3.
Optionally, set the DB_FLASHBACK_RETENTION_TARGET to the length of the desired
flashback window in minutes:
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH; # 3 days
By default DB_FLASHBACK_RETENTION_TARGET is set to 1 day (1440 minutes).
Note:
This setting must be persistent across database startup and shutdown.
4.
Enable the Flashback Database feature for the whole database:
ALTER DATABASE FLASHBACK ON;
5.
Optionally, disable flashback logging for specific tablespaces.
By default, flashback logs are generated for all permanent tablespaces. You can
reduce overhead by disabling flashback logging for specific tablespaces as in the
following example:
ALTER TABLESPACE tbs_3 FLASHBACK OFF;
You can re-enable flashback logging for a tablespace later with this command:
ALTER TABLESPACE tbs_3 FLASHBACK ON;
If you disable Flashback Database for a tablespace, then you must take its data
files offline before running FLASHBACK DATABASE.
When you enable Flashback Database while the database is open, there is a very
small chance the command may not be able to obtain the memory it needs. If the
command fails because of that reason, retry the command after a while or retry after a
shutdown and restart of the instance.
When you enable Flashback Database on a physical standby database, you can flash
back a standby database. Flashback Database of standby databases has some
applications in the Data Guard environment.
See Also:
Oracle Data Guard Concepts and Administration for details about standby
databases
7.5.2 Disabling Flashback Database Logging
Use the ALTER DATABASE command to disable Flashback Database.
On a database instance that is either in mount or open state, issue the following
command:
ALTER DATABASE FLASHBACK OFF;
7-19
Chapter 7
Using Flashback Database
7.5.3 Configuring the Environment for Optimal Flashback Database
Performance
Maintaining flashback logs imposes comparatively limited overhead on an database
instance. Changed blocks are written from memory to the flashback logs at relatively
infrequent, regular intervals, to limit processing and I/O overhead.
To achieve good performance for large production databases with Flashback
Database enabled, Oracle recommends the following:
•
Use a fast file system for your fast recovery area, preferably without operating
system file caching.
Files that the database creates in the fast recovery area, including flashback logs,
are typically large. Operating system file caching is typically not effective for these
files, and may actually add CPU overhead for reading from and writing to these
files. Thus, it is recommended to use a file system that avoids operating system
file caching, such as Automatic Storage Management (ASM).
•
Configure enough disk spindles for the file system that holds the fast recovery
area.
For large production databases, multiple disk spindles may be needed to support
the required disk throughput for the database to write the flashback logs
effectively.
•
If the storage system used to hold the fast recovery area does not have nonvolatile
RAM, then try to configure the file system on striped storage volumes.
Use a relatively small stripe size such as 128 KB. This technique enables each
write to the flashback logs to be spread across multiple spindles, improving
performance.
•
For large databases, set the initialization parameter LOG_BUFFER to at least 8 MB.
The overhead of logging for Flashback Database depends on the mixture of reads and
writes in the database workload. When you have a write-intensive workload, the
Flashback Database logging overhead is high since it must log all those database
changes. Queries do not change data and thus do not contribute to logging activity for
Flashback Database.
7.5.4 Monitoring the Effect of Flashback Database on Performance
Several data analysis methods are available to monitor the Flashback Database
workload on your system.
•
AWR reports
The Automatic Workload Repository (AWR) automates database statistics
gathering by collecting, processing, and maintaining performance statistics for
database problem detection and self-tuning. You can compare AWR reports from
before and after the Flashback Database was turned on to monitor performance
effects.
•
AWR snapshots
You can review AWR snapshots to pinpoint system usage caused by flashback
logging. For example, if flashback buf free by RVWR is the top wait event, then you
7-20
Chapter 7
Using Flashback Database
know that Oracle Database cannot write flashback logs very quickly. Therefore,
you might want to tune the file system and storage used by the fast recovery area,
possibly using a technique described in "Configuring the Environment for Optimal
Flashback Database Performance"
•
V$FLASHBACK_DATABASE_STAT view
The V$FLASHBACK_DATABASE_STAT view shows the bytes of flashback data logged by
the database. Each row in the view shows the statistics accumulated (typically
over the course of an hour). The FLASHBACK_DATA and REDO_DATA columns describe
bytes of flashback data and redo data written respectively during the time interval,
while the DB_DATA column describes bytes of data blocks read and written. The
columns FLASHBACK_DATA and REDO_DATA correspond to sequential writes, whereas
DB_DATA column corresponds to random reads and writes.
•
V$SYSSTAT view
Because of the difference between sequential I/O and random I/O, a better
indication of I/O overhead is the number of I/O operations issued for flashback
logs. The V$SYSSTAT statistics shown in Table 7-1 can tell you the number of I/O
operations that your instance has issued for various purposes.
Table 7-1
V$SYSSTAT Statistics
Column Name
Column Meaning
Physical write I/O request
The number of write operations issued for writing data blocks
Physical read I/O request
The number of read operations issued for reading data blocks
Redo writes
The number of write operations issued for writing to the redo log
Flashback log writes
The number of write operations issued for writing to flashback
logs
Flashback log write bytes
Total size in bytes of flashback database data written from this
instance
See Also:
•
Oracle Database Reference for more details on columns in the V$SYSSTAT
view
•
Oracle Database Performance Tuning Guide to learn about AWR
•
Oracle Database 2 Day + Performance Tuning Guide for more
information about AWR reports
7.5.5 About Flashback Writer (RVWR) Behavior with I/O Errors
When flashback is enabled or when there are guaranteed restore points, the
background process RVWR writes flashback data to flashback database logs in the
fast recovery area.
If RVWR encounters an I/O error, then the following behavior is expected:
•
If there are any guaranteed restore points defined, then the instance fails when
RVWR encounters I/O errors.
7-21
Chapter 7
Using Flashback Database
•
If no guaranteed restore points are defined, then the instance remains unaffected
when RVWR encounters I/O errors. Note the following cases:
–
On a primary database, Oracle Database automatically disables Flashback
Database while the database is open. All existing transactions and queries
proceed unaffected. This behavior is expected for both single-instance and
Oracle RAC databases.
–
On a physical or logical standby, RVWR appears to have stopped responding,
retrying the I/O periodically. This may eventually cause the logical standby or
the managed recovery of the physical standby to suspend. (Oracle Database
does not cause the standby instance to fail because it does not want to cause
the primary database to fail in maximum protection mode.) To resolve the
issue, you can issue either a SHUTDOWN ABORT or an ALTER DATABASE FLASHBACK
OFF command.
7-22
Part III
Backing Up and Archiving Data
The chapters in this part describe how to use the RMAN utility to perform advanced
backup and recovery operations, and explain RMAN performance tuning and
troubleshooting.
This part contains these chapters:
•
RMAN Backup Concepts
•
Backing Up the Database
•
Backing Up the Database: Advanced Topics
8
RMAN Backup Concepts
This chapter describes the general concepts that you must understand to make any
type of RMAN backup. This chapter contains the following topics:
•
About Consistent and Inconsistent RMAN Backups
•
About Online Backups and Backup Mode
•
About Backup Sets
•
About RMAN Image Copies
•
About Multiple Copies of RMAN Backups
•
About RMAN Control File and Server Parameter File Autobackups
•
About RMAN Incremental Backups
•
About Backup Retention Policies
8.1 About Consistent and Inconsistent RMAN Backups
Use the RMAN BACKUP command to create both consistent and inconsistent backups.
The RMAN BACKUP command supports backing up the following types of files:
•
Data files and control files
•
Server parameter file
•
Archived redo logs
•
RMAN backups
Although the database depends on other types of files, such as network configuration
files, password files, and the contents of the Oracle home, you cannot back up these
files with RMAN. Likewise, some features of Oracle Database, such as external tables,
may depend upon files other than the data files, control files, and redo log. RMAN
cannot back up these files. Use general-purpose backup software such as Oracle
Secure Backup to protect files that RMAN does not support.
When you execute the BACKUP command in RMAN, the output is always either one or
more backup sets or one or more image copies. A backup set is an RMAN-specific
proprietary format, whereas an image copy is a bit-for-bit copy of a file. By default,
RMAN creates backup sets.
See Also:
•
About Consistent RMAN Backups
•
About Inconsistent RMAN Backups
8-1
Chapter 8
About Online Backups and Backup Mode
8.1.1 About Consistent RMAN Backups
A consistent backup occurs when the database is in a consistent state. You can use
the BACKUP command to make consistent backups of the database.
A database is in a consistent state after being shut down with the SHUTDOWN NORMAL,
SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown
guarantees that all redo has been applied to the data files. If you mount the database
and make a backup at this point, then you can restore the database backup later and
open it without performing media recovery. But you will, of course, lose all transactions
that occurred after the backup was created.
8.1.2 About Inconsistent RMAN Backups
Any database backup that is not consistent is an inconsistent backup. A backup made
when the database is open is inconsistent, as is a backup made after an instance
failure or SHUTDOWN ABORT command.
When a database is restored from an inconsistent backup, Oracle Database must
perform media recovery before the database can be opened, applying changes from
the redo logs that took place after the backup was created.
Note:
RMAN does not permit you to make inconsistent backups when the database
is in NOARCHIVELOG mode. If you employ user-managed backup techniques for
a NOARCHIVELOG database, then you must not make inconsistent backups of
this database.
If the database runs in ARCHIVELOG mode, and you back up the archived redo logs and
data files, inconsistent backups can be the foundation for a sound backup and
recovery strategy. Inconsistent backups offer superior availability because you do not
have to shut down the database to make backups that fully protect the database.
8.2 About Online Backups and Backup Mode
You can create RMAN backups or user-managed backups.
When performing a user-managed backup of an online tablespace or database, an
operating system utility can back up a data file at the same time that the database
writer (DBWR) is updating the file. It is possible for the utility to read a block in a halfupdated state, so that the block that is copied to the backup media is updated in its
first half, while the second half contains older data. This type of logical corruption is
known as a fractured block, that is, a block that is not consistent with an SCN. If this
backup must be restored and the block requires recovery, then recovery fails because
the block is not usable.
For third-party snapshot technologies, you must use one of the following techniques to
eliminate the risk of creating fractured blocks:
8-2
Chapter 8
About Backup Sets
•
Ensure that the snapshot technology complies with Oracle requirements for online
backups
•
Take the database or data files offline
•
Place the database in backup mode before using a third-party snapshot backup
See Also:
•
Making Backups with Third-Party Snapshot Technologies.
•
Recovery Using Storage Snapshot Optimization
Unlike user-managed tools, RMAN does not require extra logging or backup mode
because it knows the format of data blocks. RMAN is guaranteed not to back up
fractured blocks. During an RMAN backup, a database server session reads each data
block and checks whether it is fractured by comparing the block header and footer. If a
block is fractured, then the session rereads the block. If the same fracture is found,
then the block is considered permanently corrupt. Also, RMAN does not need to freeze
the data file header checkpoint because it knows the order in which the blocks are
read, which enables it to capture a known good checkpoint for the file.
See Also:
Making User-Managed Backups of Online Tablespaces and Data Files to
learn how to back up online tablespaces when not using RMAN
8.3 About Backup Sets
When you execute the BACKUP command in RMAN, you create one or more backup
sets or image copies. By default, RMAN creates backup sets regardless of whether
the destination is disk or a media manager.
Note:
Data file backup sets are typically smaller than data file image copies and
take less time to write.
This section contains the following topics:
•
About Backup Sets and Backup Pieces
•
About RMAN Block Compression for Backup Sets
•
About Binary Compression for RMAN Backup Sets
•
About RMAN Backup Undo Optimization
•
About Encryption for RMAN Backup Sets
8-3
Chapter 8
About Backup Sets
•
About File Names for RMAN Backup Pieces
•
About Number and Size of RMAN Backup Pieces
•
About Number and Size of RMAN Backup Sets
•
About Multiplexed RMAN Backup Sets
•
About RMAN Proxy Copies
8.3.1 About Backup Sets and Backup Pieces
RMAN can store backup data in a logical structure called a backup set, which is the
smallest unit of an RMAN backup.
A backup set contains the data from one or more data files, archived redo logs, control
files, or server parameter file. Backup sets, which are only created and accessed
through RMAN, are the only form in which RMAN can write backups to media
managers such as tape drives and tape libraries.
A backup set contains one or more binary files in an RMAN-specific format. Each of
these files is known as a backup piece. A backup set can contain multiple data files.
For example, you can back up 10 data files into a single backup set consisting of a
single backup piece. In this case, RMAN creates one backup piece as output. The
backup set contains only this backup piece.
If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN
produces a multisection backup. This is a backup of a single large file, produced by
multiple channels in parallel, each of which produces one backup piece. Each backup
piece contains one file section of the file being backed up.
For non-multisection backups, RMAN only records backup sets in the repository that
complete successfully. There is no such thing as a partial backup set. This differs from
an unsuccessful multisection backup, where it is possible for RMAN metadata to
contain a record for a partial backup set. In the latter case, you must use the DELETE
command to delete the partial backup set.
Note:
RMAN never considers partial backups as candidates for restore and
recovery.
See Also:
Backing Up the Database
8.3.2 About RMAN Block Compression for Backup Sets
RMAN can use block compression when creating backup sets.
The following types of block compression are available:
8-4
Chapter 8
About Backup Sets
•
Unused Block Compression (Supports disk backup and Oracle Secure Backup
tape backup)
•
Null Block Compression (Supports all backups)
RMAN block compression is not traditional binary compression. Rather, it is a set of
techniques that RMAN uses to altogether avoid backing up certain blocks that are not
needed in this backup.
8.3.2.1 About Unused Block Compression
When employing unused block compression, RMAN skips reading, and backing up,
any database blocks that are not currently allocated to some database object. This is
regardless of whether those blocks had previously been allocated.
So if a database table is dropped, RMAN will not back up the space that was occupied
by that table until new objects are created in that space.
Unused block compression is used automatically when the following conditions are
true:
•
The COMPATIBLE initialization parameter is set to 10.2 or higher.
•
There are currently no guaranteed restore points defined for the database.
•
The data file is locally managed.
•
The data file is being backed up to a backup set as part of a full backup or a level
0 incremental backup.
•
The backup set is created on disk, or Oracle Secure Backup is the media
manager.
8.3.2.2 About Null Block Compression
When employing null block compression, RMAN omits from its output any block that
has never contained data.
Null block compression is always used with level 0 or full backups that are created in
backup set format.
8.3.3 About Binary Compression for RMAN Backup Sets
RMAN supports binary compression of backup sets. Binary compression is only
enabled when you specify AS COMPRESSED BACKUPSET in the BACKUP command, or onetime with the CONFIGURE DEVICE TYPE [DISK | SBT] BACKUP TYPE TO COMPRESSED BACKUPSET
command.
You have two binary compression options:
•
You can use the BASIC compression algorithm, which does not require the Oracle
Advanced Compression option. This setting offers a compression ratio comparable
to MEDIUM, at the expense of additional CPU consumption.
•
If you have enabled the Oracle Advanced Compression option, you can choose
from the compression levels outlined in "About Oracle Advanced Compression
Option".
8-5
Chapter 8
About Backup Sets
See Also:
•
Configuring Compression Options
•
Oracle Database Backup and Recovery Reference to learn about BACKUP
AS BACKUPSET and CONFIGURE COMPRESSION ALGORITHM
8.3.4 About RMAN Backup Undo Optimization
In backup undo optimization, RMAN excludes undo not needed for recovery of a
backup, that is, for transactions that have been committed.
Backup undo optimization works for disk backups and Oracle Secure Backup tape
backups. Unlike backup optimization, backup undo optimization is not configurable.
8.3.5 About Encryption for RMAN Backup Sets
RMAN supports backup encryption for backup sets. You can use keystore-based
transparent encryption, password-based encryption, or both.
You can use the CONFIGURE ENCRYPTION command to configure persistent transparent
encryption. Use the SET ENCRYPTION command at the RMAN session level to specify
password-based encryption.
Note:
Keystore-based encryption is more secure than password-based encryption
because no passwords are involved. Use password-based encryption only
when it is absolutely necessary because your backups must be
transportable.
To create encrypted backups on disk with RMAN, the database must use the
Advanced Security Option. For encrypted RMAN backups directly to tape, the Oracle
Secure Backup SBT is the only supported interface.
See Also:
•
Configuring Backup Encryption
•
Encrypting RMAN Backups
8.3.6 About File Names for RMAN Backup Pieces
You can either let RMAN determine a unique name for backup pieces or use the
FORMAT clause to specify a name.
8-6
Chapter 8
About Backup Sets
If you do not specify the FORMAT parameter, then RMAN automatically generates a
unique file name with the %U substitution variable in the default backup location.
An example of RMAN generating an SBT backup piece name by %U is:
2i1nk47_1_1
An example of a non- Oracle Managed File (OMF) backup piece on disk is:
/backups/TEST/2i1nk47_1_1
The FORMAT clause supports substitution variables other than %U for generating unique
file names. For example, you can use %d to generate the name of the database, %I for
the DBID, %t for the time stamp, and so on.
You can specify up to four FORMAT parameters. If you specify multiple FORMAT
parameters, then RMAN uses the multiple FORMAT parameters only when you specify
multiple copies. You can create multiple copies by using the BACKUP ... COPIES, SET
BACKUP COPIES, or CONFIGURE ... BACKUP COPIES commands.
Note:
If you use a media manager, then check your vendor documentation for
restrictions on FORMAT, such as the size of the name, the naming conventions,
and so on.
See Also:
•
Specifying a Format for RMAN Backups
•
Oracle Database Backup and Recovery Reference for descriptions of the
FORMAT clause and the substitution variables
8.3.7 About Number and Size of RMAN Backup Pieces
By default a backup set contains one backup piece. To restrict the size of each backup
piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL
commands.
The MAXPIECESIZE option limits backup piece size to the specified number of bytes. If
the total size of the backup set is greater than the specified backup piece size, then
RMAN creates multiple physical pieces to hold the backup set contents.
You can use this option for media managers that cannot manage a backup piece that
spans multiple tapes. For example, if a tape can hold 10 GB, but the backup set being
created must hold 80 GB of data, then you must instruct RMAN to create backup
pieces of 10 GB, small enough to fit on the tapes used with the media manager. In this
case, the backup set media consists of eight tapes. Media managers supporting SBT
2.0 can return a value to RMAN indicating the largest supported backup piece size,
which RMAN uses in planning backup activities.
8-7
Chapter 8
About Backup Sets
If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN can
create a multisection backup. In this case, a single backup set can contain multiple
backup pieces, each containing a file section. The purpose of multisection backups is
to enable multiple channels to back up a large file in parallel.
See Also:
•
Configuring the Maximum Size of Backup Pieces
•
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL
syntax
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
8.3.8 About Number and Size of RMAN Backup Sets
You use the backupSpec clause of the BACKUP command to specify the objects to be
backed up. Each backupSpec clause produces at least one backup set.
The total number and size of backup sets depends mostly on an internal RMAN
algorithm. However, you can influence RMAN behavior with the MAXSETSIZE parameter
in the CONFIGURE or BACKUP command. By limiting the size of the backup set, the
parameter indirectly limits the number of files in the set and can possibly force RMAN
to create additional backup sets. Also, you can specify BACKUP ... FILESPERSET to
specify the maximum number of files in each backup set.
See Also:
•
About Backup Set Size
•
Tuning RMAN Performance to learn about RMAN buffer management
•
Oracle Database Backup and Recovery Reference to learn the syntax
for the backupSpec clause
8.3.9 About Multiplexed RMAN Backup Sets
When creating backup sets, RMAN can simultaneously read multiple files from disk
and then write their blocks into the same backup set. For example, RMAN can read
from two data files simultaneously, and then combine the blocks from these data files
into a single backup piece. The combination of blocks from multiple files is called
backup multiplexing.
Image copies, by contrast, are never multiplexed.
8-8
Chapter 8
About Backup Sets
Note:
If RMAN creates a multisection backup of a data file, then the data file is not
multiplexed with any other data file or file section.
As Figure 8-1 illustrates, RMAN can back up three data files into a backup set that
contains only one backup piece. This backup piece contains the intermingled data
blocks of the three input data files.
Figure 8-1
File 1
Data File Multiplexing
File 2
File 3
Server session
1
2
3
1
2
3
1
2
3
1
Backup set
RMAN multiplexing is determined by several factors. For example, the FILESPERSET
parameter of the BACKUP command determines how many data files to put in each
backup set. The MAXOPENFILES parameter of ALLOCATE CHANNEL or CONFIGURE CHANNEL
defines how many data files RMAN can read from simultaneously. The basic
multiplexing algorithm is as follows:
•
Number of files in each backup set
This number is the minimum of the FILESPERSET setting and the number of files
read by each channel. The FILESPERSET default is 64.
•
The level of multiplexing
This is the number of input files simultaneously read and then written into the
same backup piece. The level of multiplexing is the minimum of MAXOPENFILES and
the number of files in each backup set. The MAXOPENFILES default is 8.
Suppose that you back up 12 data files with one channel when FILEPERSET is set to 4.
The level of multiplexing is the lesser of this number and 8. Thus, the channel
simultaneously writes blocks from 4 data files into each backup piece.
Now suppose that you back up 50 data files with one channel. The number of files in
each backup set is 50. The level of multiplexing is the lesser of this number and 8.
8-9
Chapter 8
About Backup Sets
Thus, the channel simultaneously writes blocks from 8 data files into each backup
piece.
RMAN multiplexing of backup sets is different from media manager multiplexing. One
type of media manager multiplexing occurs when the media manager writes the
concurrent output from multiple RMAN channels to a single sequential device. Another
type occurs when a backup mixes database files and non-database files on the same
tape.
Note:
Oracle recommends that you never use media manager multiplexing for
RMAN backups.
See Also:
•
Allocation of Input Disk Buffers to learn how multiplexing affects
allocation of disk buffers during backups
•
Oracle Database Backup and Recovery Reference for BACKUP syntax
8.3.10 About RMAN Proxy Copies
During a proxy copy, RMAN turns over control of the data transfer to a media manager
that supports this feature. Proxy copy can only be used with media managers that
support it and cannot be used with channels of type DISK. The PROXY option of the
BACKUP command specifies that a backup is a proxy copy.
For each file that you attempt to back up with the BACKUP PROXY command, RMAN
queries the media manager to determine whether it can perform a proxy copy. If the
media manager cannot proxy copy the file, then RMAN backs up the file as if the PROXY
option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy
copy cannot be performed.)
Control files are never backed up with proxy copy. If the PROXY option is specified on an
operation backing up a control file, then it is silently ignored for the purposes of
backing up the control file.
See Also:
•
Oracle Database Reference for more information about the
V$PROXY_DATAFILE view
•
Oracle Database Reference for more information about the
V$PROXY_ARCHIVEDLOG view
•
Oracle Database Backup and Recovery Reference for the BACKUP
command and the PROXY option
8-10
Chapter 8
About RMAN Image Copies
8.4 About RMAN Image Copies
An image copy is an exact copy of a single data file, archived redo log file, or control
file.
Image copies are not stored in an RMAN-specific format. They are identical to the
results of copying a file with operating system commands. RMAN can use image
copies during RMAN restore and recover operations, and you can also use image
copies with non-RMAN restore and recovery techniques.
This section contains the following topics:
•
About RMAN-Created Image Copies
•
About User-Managed Image Copies
8.4.1 About RMAN-Created Image Copies
To create image copies and have them recorded in the RMAN repository, you run the
RMAN BACKUP AS COPY command.
Alternatively, you can configure the default backup type for disk as image copies. A
database server session is used to create the copy. The server session also performs
actions such as validating the blocks in the file and recording the image copy in the
RMAN repository.
As with backup pieces, FORMAT variables are used to specify the names of image
copies. The default format %U, which was explained in "About File Names for RMAN
Backup Pieces", is defined differently for image copies. The following example shows
the name for data file 2 generated by %U:
/d1/oracle/work/orcva/RDBMS/datafile/o1_mf_sysaux_2qylngm3_.dbf
When creating image copies, you can also name the output copies with the
DB_FILE_NAME_CONVERT parameter of the BACKUP command. This parameter works
identically to the DB_FILE_NAME_CONVERT initialization parameter. Pairs of file name
prefixes are provided to change the names of the output files. If a file is not converted
by any of the pairs, then RMAN uses the FORMAT specification: if no FORMAT is specified,
then RMAN uses the default format %U.
Example 8-1
Specifying File Names with DB_FILE_NAME_CONVERT
This example copies the data files whose file name is prefixed with /maindisk/oradata/
users so that they are prefixed with /backups/users_ts.
BACKUP AS COPY
DB_FILE_NAME_CONVERT ('/maindisk/oradata/users',
'/backups/users_ts')
TABLESPACE users;
If you run a RESTORE command, then by default RMAN restores a data file or control file
to its original location by copying an image copy backup to that location. Image copies
are chosen over backup sets because of the extra overhead of reading through an
entire backup set in search of files to be restored.
If you must restore and recover a current data file, and if you have an image copy
available on disk, then you do not need to have RMAN copy the image copy back to its
8-11
Chapter 8
About RMAN Image Copies
old location. Instead, you can use the image copy in place as a replacement for the
data file to be restored. "Performing Complete Recovery After Switching to a Copy"
explains how to perform this task.
See Also:
•
Configuring the Default Type for Backups: Backup Sets or Copies to
learn how to make either backup sets or image copies the default type of
RMAN backups
•
Specifying Backup Set or Copy for an RMAN Backup to Disk
•
Oracle Database Backup and Recovery Reference to learn about the
meaning of %U for image copies
8.4.2 About User-Managed Image Copies
RMAN can use image copies created by mechanisms outside of RMAN, such as
native operating system file copy commands or third-party utilities that leave image
copies of files on disk. This type of copy is known as a user-managed backup or
operating system backup.
You can use the CATALOG command to inspect an existing image copy and enter its
metadata into the RMAN repository. However, the CATALOG command does not do the
following:
•
Read all blocks in the data file copy to ensure there are no corruptions
•
Guarantee that the image copy was correctly made in backup mode
After you catalog these files, you can use them with the RESTORE or SWITCH commands
just as you can for RMAN-generated image copies.
Some sites store their data files on mirrored disk volumes, which permit the creation of
image copies by breaking a mirror. After you have broken the mirror, you can notify
RMAN of the existence of a new user-managed copy, thus making it eligible for a
backup. You must notify RMAN when the copy is no longer available by using the
CHANGE ... UNCATALOG command.
See Also:
•
Making User-Managed Database Backups
•
Adding Backup Records to the RMAN Repository to learn how to catalog
data file and archived log image copies
•
Making Split Mirror Backups with RMAN
•
Oracle Database Backup and Recovery Reference for CHANGE syntax
8-12
Chapter 8
About Sparse Backups
8.5 About Sparse Backups
You can use the RMAN BACKUP command to back up data blocks from sparse data
files, tablespaces containing sparse data files, sparse pluggable databases (PDBs),
and multitenant container databases (CDBs) containing sparse PDBs.
A sparse data file is a logical Oracle object that is created as a shadow of a base data
file object and is stored in a physical storage space known as delta space. For
instance, consider a sparse database DB0 that is created from a base database DB. In a
sparse environment, it is mandatory that the base objects must be read-only. Unlike
the base database, sparse databases are read-write databases. In this case, DB, a
read-only database, consists of 5 data files. DB0 recreates the logical versions of each
of these 5 base data files and assigns a separate delta storage space for each
individual file. When the sparse database DB0 updates a data block in one of the
sparse data files, only the updated block is logically stored in the delta space of that
modified data file. When you choose to perform a sparse backup on DB0, the operation
will copy data only from the delta storage space of the database and the delta space of
the sparse data files. A sparse backup can either be in the backup set format (default)
or the image copy format. RMAN restores sparse data files from sparse backups and
then recovers them from archive and redo logs. You can perform a complete or a
point-in-time recovery on sparse data files.
To perform sparse backup and recovery operations, your database must have the
COMPATIBLE initialization parameter set to 12.2 or higher.
If your database has the COMPATIBLE initialization parameter as 12.2 and you perform a
full or level 0 incremental backup on a non-sparse (normal) data file, then RMAN
performs a traditional full or level 0 incremental backup of the specified data file. On
the other hand, if you perform a full or level 0 incremental backup on a sparse data file,
then RMAN performs a backup only of all the latest changes from the delta storage
space of that particular data file.
For a database with the COMPATIBLE initialization parameter less than 12.2, RMAN
continues to perform the backup and recovery operations as before and are not
influenced by the sparseness of a data file.
Sparse backups help in efficiently managing storage space and facilitate faster backup
and recovery.
Note:
The base (read-only) data files in a sparse database are not encrypted.
Ensure that the base data files are stored in a protected storage and
accessed using secured communications.
See Also:
Backing Up Sparse Databases with RMAN
8-13
Chapter 8
About Preplugin Backups
8.6 About Preplugin Backups
A preplugin backup is an RMAN backup of a non-CDB or a PDB that was created
before the non-CDB or PDB was plugged in to a different CDB.
The CDB into which the non-CDB or PDB is plugged in is referred to as the destination
CDB. Preplugin backups can be used for PDB restore and recovery operations in
destination CDB. To perform media recovery, all the required archive redo logs must
be included in the preplugin backup.
For preplugin backups to be usable in the destination CDB, metadata about the
preplugin backups must be exported to the RMAN repository of the destination CDB.
When a PDB is unplugged from a source CDB, the required metadata is stored in the
XML file created during the unplug operation. With non-CDBs, metadata required to
make preplugin backups usable in the destination CDB is added to the non-CDB’s
data dictionary using the DBMS_PDB.EXPORTRMANBACKUP() procedure.
Preplugin backups are usable only on the destination CDB into which the source nonCDB or PDB are plugged in. For example, assume that you migrate a PDB from the
CDB src_cdb to the CDB stage_cdb. Subsequently, you migrate the source PDB from
the CDB stage_cdb to the CDB prod_cdb. The PDB backups created on the CDB
src_pdb are accessible to CDB stage_pdb. However, the CDB prod_cdb can only access
the PDB backups created on the CDB stage_cdb, not the PDB backups created on the
CDB src_cdb.
See Also:
•
Creating Preplugin Backups of PDBs Using RMAN
•
Creating a Preplugin Backup of the Whole Database
8.7 About Multiple Copies of RMAN Backups
RMAN enables you to make multiple, identical copies of backups.
Use one of the following ways:
•
Duplex backups with the BACKUP ... COPIES command, in which case RMAN
creates multiple copies of each backup set
See About Duplexed Backup Sets.
•
Back up your files as backup sets or image copies, and then back up the backup
sets or image copies with the RMAN BACKUP BACKUPSET or BACKUP COPY OF
commands
See About Backups of RMAN Backups.
8.7.1 About Duplexed Backup Sets
When backing up data files, archived redo log files, server parameter files, and control
files into backup pieces, RMAN can create a duplexed backup set, producing up to
8-14
Chapter 8
About Multiple Copies of RMAN Backups
four identical copies of each backup piece in the backup set on different backup
destinations with one BACKUP command. Duplexing is not supported for backup
operations that produce image copies.
You can use the COPIES parameter in the CONFIGURE, SET, or BACKUP commands to
specify duplexing of backup sets when using the BACKUP command. RMAN can duplex
backups to either disk or tape, but cannot duplex backups to tape and disk
simultaneously. When backing up to tape, ensure that the number of copies does not
exceed the number of available tape devices.
The FORMAT parameter of the BACKUP command specifies the destinations for duplexed
backups. The following example creates three copies of the backup of data file 7:
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7
FORMAT '/disk1/%U','?/oradata/%U','?/%U';
RMAN places the first copy of each backup piece in /disk1, the second in ?/oradata,
and the third in the Oracle home. RMAN does not produce three backup sets, each
with a different unique backup set key. Rather, RMAN produces one backup set with a
unique key, and generates three identical copies of each backup piece in the set.
See Also:
•
"Configuring Backup Duplexing"
•
"Duplexing Backup Sets"
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
•
Oracle Database Backup and Recovery Reference for SET syntax
8.7.2 About Backups of RMAN Backups
You can use the BACKUP command to back up existing backup sets and image copies.
Backing up existing backups enables you to make multiple, identical copies of RMAN
backups.
The following sections provide more information about the methods of creating
backups up backups:
•
Backups of Backup Sets
•
Backups of Image Copies
8.7.2.1 Backups of Backup Sets
The RMAN BACKUP BACKUPSET command backs up backup sets that were created on
disk. The command is a useful way to spread backups among multiple media.
If RMAN discovers that one copy of a backup set is corrupted or missing, then it
searches for other copies of the same backup set. This behavior is similar to the
behavior of RMAN when backing up archived redo logs that exist in multiple archiving
destinations.
8-15
Chapter 8
About Multiple Copies of RMAN Backups
Starting with Oracle Database Release 18c, while backing up backup sets, you can
compress backup sets that were not previously compressed by using the BACKUP AS
COMPRESSED BACKUPSET command.
RMAN enables you to create encrypted backups of unencrypted backup sets. Before
you back up the unencrypted backup sets, use the SET ENCRYPTION FOR DATABASE ON
command to enable encryption. Note that the SET command enables encryption for the
current RMAN session. If encryption is not required for subsequent operations, then
turn off encryption for the database.
Example 8-2
Backing Up Backup Sets to Tape
This example shows how you might run the BACKUP command weekly as part of the
production backup schedule. In this way, you ensure that all your backups exist on
both disk and tape.
BACKUP DEVICE TYPE DISK AS BACKUPSET
DATABASE PLUS ARCHIVELOG;
BACKUP
DEVICE TYPE sbt
BACKUPSET ALL; # copies backup sets on disk to tape
Note:
Backups to sbt that use automatic channels require that you first run the
CONFIGURE DEVICE TYPE sbt command.
Example 8-3
Managing Space Allocation
You can also use BACKUP BACKUPSET to manage backup space allocation. This example
backs up backup sets that were created more than a week ago from disk to tape, and
then deletes them from disk.
BACKUP
DEVICE TYPE sbt
BACKUPSET COMPLETED BEFORE 'SYSDATE-7'
DELETE INPUT;
DELETE INPUT here is equivalent to DELETE ALL INPUT: RMAN deletes all existing copies of
the backup set. If you duplexed a backup to four locations, then RMAN deletes all four
copies of the pieces in the backup set.
See Also:
"Backing Up RMAN Backups"
8.7.2.2 Backups of Image Copies
You can use the BACKUP COPY OF command to back up existing image copies of
database files either as backup sets or as image copies. When using this command,
an image copy of every data file specified in the command must exist. If there are
multiple copies of a data file, then the latest one is used. If you specify a tablespace or
8-16
Chapter 8
About RMAN Control File and Server Parameter File Autobackups
the whole database, then RMAN issues an error if there are data files in the database
or tablespace for which there are no image copy backups.
8.8 About RMAN Control File and Server Parameter File
Autobackups
Having recent backups of your control file and server parameter file is extremely
valuable in many recovery situations. To ensure that you have backups of these files,
the database supports control file and server parameter file autobackups.
The autobackup occurs independently of any backup of the current control file
explicitly requested as part of your BACKUP command. With a control file autobackup,
RMAN can recover the database even if the current control file, recovery catalog, and
server parameter file are inaccessible. Because the path used to store the autobackup
follows a well-known format, RMAN can search for and restore the server parameter
file from that autobackup. After you have started the instance with the restored server
parameter file, RMAN can restore the control file from the autobackup. After you
mount the control file, use the RMAN repository in the mounted control file to restore
the data files.
It is recommended that you turn on control file autobackups. Otherwise, RMAN
database point-in-time recovery (DBPITR) and point-in-time recovery (PITR) for PDBs
may not work effectively when PITR needs to undo data file additions or deletions.
This section contains the following topics:
•
When RMAN Performs Control File Autobackups
•
How RMAN Performs Control File Autobackups
8.8.1 When RMAN Performs Control File Autobackups
Depending on the configuration of the target database, RMAN can perform
autobackups of the control file and server parameter file.
For non-CDBs, if CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically
backs up the control file and the current server parameter file (if used to start the
database) after a successful BACKUP command. For CDBs and standalone databases
with the COMPATIBLE initialization parameter set to 12.0 or higher, by default, the control
file autobackup is turned on.
If the database runs in ARCHIVELOG mode, RMAN makes control file autobackups when
a structural change to the database affects the contents of the control file.
Note:
Beginning with Oracle Database Release 11g Release 2, RMAN takes only
one control file autobackup when multiple structural changes contained in a
script (for example, adding tablespaces, altering the state of a tablespace or
data file, adding a new online redo log, renaming a file, and so on) have
been applied.
8-17
Chapter 8
About RMAN Incremental Backups
8.8.2 How RMAN Performs Control File Autobackups
The first channel allocated during the backup job creates the autobackup and places it
into its own backup set. For autobackups after database structural changes, the server
process associated with the structural change makes the backup.
If a server parameter file is in use by the database, then RMAN backs it up in the
same backup set as the control file autobackup. After the autobackup completes, the
database writes a message containing the complete path of the backup piece and the
device type to the alert log located in the Automatic Diagnostic Repository (ADR).
Note:
Control file autobackups are never duplexed.
The control file autobackup file name has a default format of %F for all device types, so
that RMAN can determine the file location and restore it without a repository. You can
specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command,
but all autobackup formats must include the %F variable. If you do not use the default
format, then during disaster recovery you must specify the format that was used to
generate the autobackups. Otherwise, RMAN cannot restore the autobackup.
See Also:
•
Configuring Control File and Server Parameter File Autobackups
•
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
•
Oracle Database Backup and Recovery Reference for BACKUP syntax
•
Oracle Database Backup and Recovery Reference to learn about the
substitution variable %F
8.9 About RMAN Incremental Backups
An incremental backup copies only those data blocks that have changed since a
previous backup. You can use RMAN to create incremental backups of data files,
tablespaces, or the whole database.
By default, RMAN makes full backups. A full backup of a data file includes every
allocated block in the file being backed up. A full backup of a data file can be an image
copy, in which case every data block is backed up. It can also be stored in a backup
set, in which case data file blocks not in use may be skipped.
A full backup has no effect on subsequent incremental backups. Image copies are
always full backups because they include every data block in a data file. A backup set
is by default a full backup because it can potentially include every data block in a data
file, although unused block compression means that blocks never used are excluded
and, in some cases, currently unused blocks are excluded (see "About RMAN Block
Compression for Backup Sets").
8-18
Chapter 8
About RMAN Incremental Backups
A full backup cannot be part of an incremental backup strategy; that is, it cannot be the
parent for a subsequent incremental backup.
See Also:
•
About Multilevel Incremental Backups
•
About the Incremental Backup Algorithm
8.9.1 About Multilevel Incremental Backups
RMAN can create multilevel incremental backups. Each incremental level is denoted
by a value of 0 or 1.
A level 0 incremental backup, which is the base for subsequent incremental backups,
copies all blocks containing data. The only difference between a level 0 incremental
backup and a full backup is that a full backup is never included in an incremental
strategy. Thus, an incremental level 0 backup is a full backup that happens to be the
parent of incremental backups whose level is greater than 0.
A level 1 incremental backup can be either of the following types:
•
A differential incremental backup, which backs up all blocks changed after the
most recent incremental backup at level 1 or 0
See About Differential Incremental Backups.
•
A cumulative incremental backup, which backs up all blocks changed after the
most recent incremental backup at level 0
See About Cumulative Incremental Backups.
Incremental backups are differential by default.
Incremental backups at level 0 can be either backup sets or image copies, but
incremental backups at level 1 can only be backup sets.
Note:
Cumulative backups are preferable to differential backups when recovery
time is more important than disk space, because fewer incremental backups
must be applied during recovery.
The size of the backup file depends solely upon the number of blocks modified, the
incremental backup level, and the type of incremental backup (differential or
cumulative).
8.9.1.1 About Differential Incremental Backups
In a differential level 1 backup, RMAN backs up all blocks that have changed since the
most recent incremental backup at level 1 (cumulative or differential) or level 0.
8-19
Chapter 8
About RMAN Incremental Backups
For example, in a differential level 1 backup, RMAN determines which level 1 backup
occurred most recently and backs up all blocks modified after that backup. If no level 1
is available, then RMAN copies all blocks changed since the base level 0 backup.
If no level 0 backup is available in either the current or parent incarnation, then the
behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN
copies all blocks that have been changed since the file was created. Otherwise, RMAN
generates a level 0 backup.
Figure 8-2
Differential Incremental Backups
Backup
level
0
Day
Sun
1
1
1
1
1
1
0
Mon Tues
Wed
Thur
Fri
Sat
Sun
1
1
1
1
1
1
0
Mon Tues
Wed
Thur
Fri
Sat
Sun
In the example shown in Figure 8-2, the following activity occurs each week:
•
Sunday
An incremental level 0 backup backs up all blocks that have ever been in use in
this database.
•
Monday through Saturday
On each day from Monday through Saturday, a differential incremental level 1
backup backs up all blocks that have changed since the most recent incremental
backup at level 1 or 0. The Monday backup copies blocks changed since Sunday
level 0 backup, the Tuesday backup copies blocks changed since the Monday
level 1 backup, and so forth.
8.9.1.2 About Cumulative Incremental Backups
In a cumulative level 1 backup, RMAN backs up all blocks used since the most recent
level 0 incremental backup in either the current or parent incarnation.
Cumulative incremental backups reduce the work needed for a restore operation by
ensuring that you only need one incremental backup from any particular level.
8-20
Chapter 8
About RMAN Incremental Backups
Cumulative backups require more space and time than differential backups because
they duplicate the work done by previous backups at the same level.
In the example shown in Figure 8-3, the following occurs each week:
•
Sunday
An incremental level 0 backup backs up all blocks that have ever been in use in
this database.
•
Monday - Saturday
A cumulative incremental level 1 backup copies all blocks changed since the most
recent level 0 backup. Because the most recent level 0 backup was created on
Sunday, the level 1 backup on each day Monday through Saturday backs up all
blocks changed since the Sunday backup.
See Also:
Making and Updating RMAN Incremental Backups
Figure 8-3
Cumulative Incremental Backups
Backup
level
0
Day
Sun
1
1
1
1
1
1
0
Mon Tues
Wed
Thur
Fri
Sat
Sun
1
1
1
1
1
1
0
Mon Tues
Wed
Thur
Fri
Sat
Sun
8.9.2 About Block Change Tracking
The block change tracking feature for incremental backups improves incremental
backup performance by recording changed blocks in each data file in a block change
tracking file.
The block change tracking file is a small binary file stored in the database area. RMAN
tracks changed blocks as redo is generated.
8-21
Chapter 8
About RMAN Incremental Backups
If block change tracking is enabled, then RMAN uses the change tracking file to
identify changed blocks for incremental backups, thus avoiding the need to scan every
block in the data file. RMAN only uses block change tracking when the incremental
level is greater than 0, because a level 0 incremental backup includes all blocks.
See Also:
Using Block Change Tracking to Improve Incremental Backup Performance
8.9.3 About the Incremental Backup Algorithm
The following concepts are essential for understanding the algorithm that RMAN uses
to make incremental backups:
•
Checkpoint SCN
Every data file has a data file checkpoint SCN, which you can view in
V$DATAFILE.CHECKPOINT_CHANGE#. All changes with an SCN lower than this SCN are
guaranteed to be in the file. When a level 0 incremental backup is restored, the
restored data file contains the checkpoint SCN that it had when the level 0 was
created. When a level 1 incremental backup is applied to a file, the checkpoint
SCN of the file is advanced to the checkpoint SCN that the file had when the
incremental level 1 backup was created.
•
Incremental start SCN
This SCN applies only to level 1 incremental backups. All blocks whose SCN is
greater than or equal to the incremental start SCN are included in the backup.
Blocks whose SCN is lower than the incremental start SCN are not included in the
backup. The incremental start SCN is most often the checkpoint SCN of the parent
of the level 1 backup.
•
Block SCN
Every data block in a data file records the SCN at which the most recent change
was made to the block.
When RMAN makes a level 1 incremental backup of a file, RMAN reads the file,
examines the SCN of every block, and backs up blocks whose SCN is greater than or
equal to the incremental start SCN for this backup. If the backup is differential, then
the incremental start SCN is the checkpoint SCN of the most recent level 1 backup. If
the backup is cumulative, then the incremental start SCN is the checkpoint SCN of the
most recent level 0 backup.
When block change tracking is enabled, RMAN uses bitmaps to avoid reading blocks
that have not changed during the range from incremental start SCN to checkpoint
SCN. RMAN still examines every block that is read and uses the SCN in the block to
decide which blocks to include in the backup.
One consequence of the incremental backup algorithm is that RMAN applies all blocks
containing changed data during recovery, even if the change is to an object created
with the NOLOGGING option. Thus, if you restore a backup made before NOLOGGING
changes were made, then incremental backups are the only way to recover these
changes.
8-22
Chapter 8
About Backup Retention Policies
8.9.4 About Recovery with Incremental Backups
During media recovery, RMAN examines the restored files to determine whether it can
recover them with an incremental backup. If it has a choice, then RMAN always
chooses incremental backups over archived redo logs because applying changes at a
block level is faster than applying redo.
RMAN does not need to restore a base incremental backup of a data file to apply
incremental backups to the data file during recovery. For example, you can restore
data file image copies and recover them with incremental backups.
See Also:
About Selection of Incremental Backups and Archived Redo Logs
8.9.5 About the Incremental-Forever Backup Strategy for Recovery
Appliance
The incremental-forever backup strategy eliminates the need for creating recurring full
backups when backing up to Zero Data Loss Recovery Appliance (Recovery
Appliance). Although Recovery Appliance supports other RMAN backup strategies, the
recommended method for ongoing backups is the incremental-forever backup
strategy.
With the incremental-forever backup strategy, you need to create only one initial level
0 full backup and subsequent level 1 incremental backups. The initial backup and the
subsequent incrementals must be RMAN backup sets and not image copies.
Note that the Recovery Appliance incremental-forever backup strategy is different from
the incrementally updated backup strategy in a conventional RMAN setup. With
RMAN, incrementally updated backups use an initial image copy, followed by
incremental backups which are eventually merged into the full backup. Therefore,
there is always at least one full image copy, a few incremental backups, and some
archived redo logs.
See Also:
•
About Real-time Redo Transport for Recovery Appliance
•
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for information about the incremental-forever backup strategy
8.10 About Backup Retention Policies
You can use the CONFIGURE RETENTION POLICY command to create a persistent and
automatic backup retention policy.
8-23
Chapter 8
About Backup Retention Policies
When a backup retention policy is in effect, RMAN considers a backup of data files or
control files as an obsolete backup, that is, no longer needed for recovery, according
to criteria specified in the CONFIGURE command. You can use the REPORT OBSOLETE
command to view obsolete files and the DELETE OBSOLETE command to delete them.
As you produce backups over time, older backups become obsolete as they are no
longer needed to satisfy the retention policy. RMAN can identify the obsolete files for
you, but it does not automatically delete them. You must use the DELETE OBSOLETE
command to delete files that are no longer needed to satisfy the retention policy.
If a fast recovery area is configured, then the database automatically deletes files that
are either obsolete or backed up to tape when more recovery area space is needed for
new files. The disk quota rules are distinct from the retention policy rules, but the
database never deletes files in violation of the retention policy to satisfy the disk quota.
Refer to "Responding to a Full Fast Recovery Area".
A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on
the user-defined retention policy, that it is not needed for recovery. A backup is
considered an expired backup only when RMAN performs a crosscheck and cannot
find the file. In short, obsolete means a file is not needed, whereas expired means it is
not found.
A backup retention policy applies only to full or level 0 data file and control file
backups. For data file copies and proxy copies, if RMAN determines that the copy or
proxy copy is not needed, then the copy or proxy copy can be deleted. For data file
backup sets, RMAN cannot delete the backup set until all data file backups within the
backup set are obsolete.
The retention policy is not responsible for deleting or rendering obsolete archived redo
logs and incremental level 1 backups. Rather, these files become obsolete when no
full backups exist that need them. Besides affecting full or level 0 data file and control
file backups, the retention policy affects archived redo logs and level 1 incremental
backups. First, RMAN decides which data file and control file backups are obsolete.
Then, RMAN considers as obsolete all archived logs and incremental level 1 backups
that are not needed to recover the oldest data file or control file backup that must be
retained.
Note:
RMAN cannot implement an automatic retention policy if backups are
deleted by non-RMAN techniques, for example, through the media
manager's tape retention policy. The media manager must never expire a
tape until all RMAN backups on that tape have been removed from the
media manager's catalog.
There are two mutually exclusive options for implementing a retention policy:
redundancy and recovery window.
This section contains the following topics:
•
About the Recovery Window
•
About Backup Redundancy
•
About Batch Deletes of Obsolete Backups
8-24
Chapter 8
About Backup Retention Policies
•
About Backup Retention Policy and Fast Recovery Area Deletion Rules
8.10.1 About the Recovery Window
A recovery window is a period that begins with the current time and extends backward
in time to the point of recoverability. The point of recoverability is the earliest time for a
hypothetical point-in-time recovery, that is, the earliest point to which you can recover
following a media failure.
For example, if you implement a recovery window of 1 week, then RMAN retains full
backups and required incremental backups and archived logs so that the database
can be recovered up to 7 days in the past. You implement this retention policy as
follows:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
This command ensures that for each data file, one backup that is older than the point
of recoverability is retained. For example, if the recovery window is 7, then there must
always exist one backup of each data file that satisfies the following condition:
SYSDATE - BACKUP CHECKPOINT TIME >= 7
All backups older than the most recent backup that satisfied this condition are
obsolete.
Assume the retention policy illustrated in Figure 8-4. The retention policy has the
following aspects:
•
The recovery window is 7 days.
•
Database backups are scheduled every two weeks on these days:
•
–
January 1
–
January 15
–
January 29
–
February 12
The database runs in ARCHIVELOG mode, and archived logs are saved on disk only if
needed for the retention policy.
8-25
Chapter 8
About Backup Retention Policies
Figure 8-4
Recovery Window, Part 1
Recovery Window = 7
Log 100
Log 250
Backup
Jan 1
Log 500
Log 750
Log 850
Backup
Jan 8
Backup
Jan 15
Jan 22
Jan 16
Point of
Recoverability
Jan 29
Jan 23
Current
Time
As illustrated in Figure 8-4, the current time is January 23 and the point of
recoverability is January 16. Hence, the January 15 backup is needed for recovery,
and so are the archived logs from log sequence 500 through 850. The logs before 500
and the January 1 backup are obsolete because they are not needed for recovery to a
point within the window.
Assume the same scenario a week later, as depicted in Figure 8-5.
Figure 8-5
Recovery Window, Part 2
Recovery Window = 7
Log 100
Log 250
Backup
Jan 1
Log 500
Log 750
Backup
Jan 8
Jan 15
Log 1000
Log 1150
Backup
Jan 22
Jan 29
Jan 23
Point of
Recoverability
Feb 5
Jan 30
Current
Time
8-26
Chapter 8
About Backup Retention Policies
In this scenario, the current time is January 30 and the point of recoverability is
January 23. Note how the January 15 backup is not obsolete even though a more
recent backup (January 29) exists in the recovery window. This situation occurs
because restoring the January 29 backup does not enable you to recover to the
earliest time in the window, January 23. To ensure recoverability to any point in the
window, you must save the January 15 backup and all archived logs from sequence
500 to 1150.
See Also:
Configuring a Recovery Window-Based Retention Policy
8.10.2 About Backup Redundancy
In some cases using a recovery window can complicate disk space planning because
the number of backups that must be retained is not constant and depends on the
backup schedule. In contrast, a redundancy-based retention policy specifies how
many backups of each data file must be retained.
For example, you can configure a redundancy of 2 as follows:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
The default retention policy is configured to REDUNDANCY 1.
See Also:
Configuring a Redundancy-Based Retention Policy
8.10.3 About Batch Deletes of Obsolete Backups
You can run the REPORT OBSOLETE command to determine which backups are currently
obsolete according to the retention policy.
A companion command, DELETE OBSOLETE, deletes all files that are obsolete according
to the retention policy. You can run DELETE OBSOLETE periodically to minimize space
wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a
weekly script.
You can also override the configured retention policy by specifying the REDUNDANCY or
RECOVERY WINDOW options on the REPORT or DELETE commands. Using DELETE OBSOLETE with
a recovery window shorter than the configured recovery window effectively reduces
the window of recoverability. For example, if the configured window is 14 days, but you
execute DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS, then you no longer have the
ability to recover to a time between 7 and 14 days ago.
8-27
Chapter 8
About Backup Retention Policies
See Also:
•
Reporting on RMAN Operationsto learn how to generate reports and
delete backups
•
Oracle Database Backup and Recovery Reference for DELETE syntax
•
Oracle Database Backup and Recovery Reference for REPORT syntax
8.10.4 About Backup Retention Policy and Fast Recovery Area
Deletion Rules
If you configure a fast recovery area, then the database uses an internal algorithm to
select files in the fast recovery area that are no longer needed to meet the configured
retention policy.
The retention policy is never violated when determining which files to delete from the
fast recovery area to satisfy the disk quota rules. These backups have status OBSOLETE
and are eligible for deletion to satisfy the disk quota rules.
The RMAN status OBSOLETE is always determined in reference to a retention policy. For
example, if a database backup is considered OBSOLETE in the RMAN repository, then it
is because it is either not needed for recovery to a point within the recovery window, or
it is redundant.
There is one important difference between the fast recovery area rules for OBSOLETE
status and the disk quota rules for deletion eligibility. Assume that archived logs 1000
through 2000, which are on disk, are needed for the current recovery window and so
are not obsolete. If you back up these logs to tape, then the retention policy considers
the disk logs as required, that is, not obsolete. Nevertheless, the fast recovery area
disk quota algorithm considers the logs on disk as eligible for deletion because they
have been backed up to tape. The logs on disk do not have OBSOLETE status in the
repository, but they are eligible for deletion by the fast recovery area.
See Also:
Deletion Rules for the Fast Recovery Area
8-28
9
Backing Up the Database
This chapter explains how to perform the most basic backup tasks and implement
backup strategies using RMAN. This chapter contains the following topics:
•
Overview of RMAN Backups
•
Specifying Backup Output Options
•
Backing Up Database Files with RMAN
•
Backing Up CDBs and PDBs
•
Backing Up Application Containers
•
Backing Up Sparse Databases with RMAN
•
Backing Up Archived Redo Logs with RMAN
•
Making and Updating RMAN Incremental Backups
•
Making Database Backups for Long-Term Storage
•
Backing Up RMAN Backups
See Also:
•
Backing Up the Database: Advanced Topics to learn about more
advanced topics such as backup optimization, duplexing, backup
encryption, and restartable backups
•
Oracle Data Guard Concepts and Administration to learn how to perform
RMAN backup and recovery in a Data Guard environment
9.1 Overview of RMAN Backups
RMAN backups are created using the BACKUP command.
This section provides an overview of RMAN backups.
9.1.1 Purpose of RMAN Backups
The primary purpose of RMAN backups is to protect your data. If a media failure or
disaster occurs, then you can restore your backups and recover lost changes.
You can also make backups to preserve data for long-time archival, as explained in
"Making Database Backups for Long-Term Storage", and to transfer data, as explained
in the chapters included in Transferring Data with RMAN.
9-1
Chapter 9
Specifying Backup Output Options
9.1.2 Basic Concepts of RMAN Backups
You can back up all or part of your database with the BACKUP command from within the
RMAN client.
In many cases, after your database has been configured in accordance with your
backup strategy, you can back up the database by entering the following command at
the RMAN prompt:
RMAN> BACKUP DATABASE;
RMAN uses the configured settings, the records of previous backups, and the control
file record of the database structure to determine an efficient set of steps for the
backup. RMAN then performs these steps.
As explained in "About RMAN File Management in a Data Guard Environment", you
can run RMAN backups at any database in a Data Guard environment. Any backup of
any database in the environment is usable for recovery of any other database if the
backup is accessible. You can offload all backups of database files, including control
file backups, to a physical standby database and thereby avoid consuming resources
on the primary database.
See Also:
•
Oracle Database Backup and Recovery Reference to learn about the
BACKUP command
•
Oracle Data Guard Concepts and Administration to learn how to back up
a standby database with RMAN
9.2 Specifying Backup Output Options
You can provide arguments to the BACKUP command to override the default backup
options.
If you specify only the minimum required options for an RMAN command such as
BACKUP DATABASE, then RMAN automatically determines the destination device,
locations for backup output, and a backup tag based on your configured environment
and built-in RMAN defaults.
The most typical backup options are described in the following sections:
•
Specifying the Device Type for an RMAN Backup
•
Specifying Backup Set or Copy for an RMAN Backup to Disk
•
Specifying a Format for RMAN Backups
•
Specifying Tags for an RMAN Backup
•
Making Compressed Backups
•
Specifying Multisection Incremental Backups
•
Making Multisection Backups Using Image Copies
9-2
Chapter 9
Specifying Backup Output Options
See Also:
Backing Up the Database: Advanced Topics to learn about advanced backup
options such as duplexing and restarting backups
9.2.1 Specifying the Device Type for an RMAN Backup
The BACKUP command takes a DEVICE TYPE clause that specifies whether to back up to
disk or tape device.
When you run BACKUP without a DEVICE TYPE clause, RMAN stores the backup on the
configured default device (disk or SBT). You set the default device with the CONFIGURE
DEFAULT DEVICE TYPE command.
Example 9-1
Specifying Device Type DISK
This example illustrates a backup to disk.
BACKUP
DEVICE TYPE DISK
DATABASE;
See Also:
Configuring the Default Device for Backups: Disk or SBT for information
about configuring the default device
9.2.2 Specifying Backup Set or Copy for an RMAN Backup to Disk
RMAN can create backups on disk as image copies or as backup sets.
"Configuring the Default Type for Backups: Backup Sets or Copies" explains how to
configure the default disk device. You can override this default with the AS COPY or AS
BACKUPSET clauses.
Example 9-2
Making Image Copies
This example uses BACKUP AS COPY to back up to disk as image copies.
BACKUP AS COPY
DEVICE TYPE DISK
DATABASE;
Example 9-3
Making Backup Sets
To back up your data into backup sets, use the AS BACKUPSET clause. This example
illustrates how you can allow backup sets to be created on the configured default
device, or direct them specifically to disk or tape.
BACKUP AS BACKUPSET
DATABASE;
BACKUP AS BACKUPSET
9-3
Chapter 9
Specifying Backup Output Options
DEVICE TYPE DISK
DATABASE;
BACKUP AS BACKUPSET
DEVICE TYPE SBT
DATABASE;
9.2.3 Specifying a Format for RMAN Backups
RMAN provides a range of options to name the files generated by the BACKUP
command.
RMAN uses the following set of rules to determine the format of the output files, which
are listed in order of precedence:
1.
If a FORMAT parameter is specified on the BACKUP command, then this setting
controls the generated file name.
For example, you can direct the output to a specific location, as shown in the
following command:
BACKUP DATABASE
FORMAT "/disk1/backup_%U"; # specifies a location on the file system
In this case, backups are stored with generated unique file names with the prefix /
disk1/backup_. The %U substitution variable, used to generate a unique string at this
point in the file name, is required.
You can also use the FORMAT parameter to name an ASM disk group as the backup
destination, as shown in the following example:
BACKUP DATABASE
FORMAT '+dgroup1'; # specifies an ASM disk group
No %U is required in this case because Automatic Storage Management (ASM)
generates unique file names as needed. However, you can specify %U if desired.
Note:
If you specify FORMAT when a fast recovery area is enabled, then RMAN
obeys the FORMAT setting. If no location is specified in the FORMAT clause,
then RMAN creates the backup in a platform-specific location.
2.
If a FORMAT setting is configured for the specific channel used for the backup, then
this setting controls the generated file name.
3.
If a FORMAT setting is configured for the device type used for the backup, then this
setting controls the generated file name.
4.
If a fast recovery area is enabled during a disk backup, and if FORMAT is not
specified, then RMAN creates the backup with an automatically generated name in
the fast recovery area.
5.
If no other conditions in this list apply, then the default location and file name
format of the backup are platform-specific.
9-4
Chapter 9
Specifying Backup Output Options
See Also:
Oracle Database Backup and Recovery Reference to learn about the FORMAT
clause, and the installation guides in the Oracle Database documentation
library to learn about the default file locations for your platform
9.2.3.1 Specifying Multiple Formats for Disk Backups
When backing up to disk, you can specify a format to spread the backup across
several drives for improved performance.
•
To back up a database to multiple disk drives, allocate one DISK channel for each
disk drive and specify the format string on the ALLOCATE CHANNEL command so that
the file names are on different disks.
RUN
{
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;
}
•
To create a default configuration that distributes backups to multiple disk drives by
default, configure multiple disk channels.
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
BACKUP AS
DEVICE TYPE DISK PARALLELISM 3;
DEFAULT DEVICE TYPE TO DISK;
CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
COPY DATABASE;
Typically, you do not need to specify a format when backing up to tape because the
default %U variable generates a unique file name for tape backups.
9.2.4 Specifying Tags for an RMAN Backup
RMAN attaches a character string called a tag to every backup it creates, as a way of
identifying the backup. You can either accept the default tag or specify your own with
the TAG parameter of the BACKUP command.
This section contains the following topics:
•
About Backup Tags
•
Specifying Tags for Backup Sets and Image Copies
9.2.4.1 About Backup Tags
User-specified tags are a useful way to indicate the purpose or usage of different
classes of backups or copies.
You can tag backup sets, proxy copies, data file copies, or control file copies. For
example, you can tag data file copies that you intend to use in a SWITCH command as
9-5
Chapter 9
Specifying Backup Output Options
for_switch_only and file copies to use only for a RESTORE command as
for_restore_only.
Tags do not need to be unique, so multiple backup sets or image copies can have the
same tag (for example, weekly_backup). Assume that you specify that a data file be
restored from backups that have a specific tag. If multiple backups of the requested file
have the desired tag, then RMAN restores the most recent backup that has the
desired tag, within any constraints on the RESTORE command.
In practice, tags are often used to distinguish a series of backups created as part of a
single strategy, such as an incremental backup strategy. For example, you might
create a weekly incremental backup with a tag like BACKUP TAG weekly_incremental.
Many forms of the BACKUP command let you associate a tag with a backup, and many
RESTORE and RECOVER commands let you specify a tag to restrict which backups to use in
the RESTORE or RECOVER operation.
If you do not explicitly specify a tag with the TAG parameter of the BACKUP command,
then RMAN implicitly creates a default tag for backups (except for control file
autobackups). The format of the tag is TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is
the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is
the seconds. For example, a backup of data file 1 may get the tag TAG20070208T133437.
The date and time refer to when RMAN started the backup in the time zone of the
instance performing the backup. If multiple backup sets are created by one BACKUP
command, then each backup piece has the same default tag.
Tags are stored in uppercase, regardless of the case used when entering them. The
maximum length of a backup tag is 30 bytes. Tags cannot use operating system
environment variables or use special formats such as %T or %D.
See Also:
Oracle Database Backup and Recovery Referencefor the default format
description in BACKUP...TAG
9.2.4.2 Specifying Tags for Backup Sets and Image Copies
Use the TAG parameter with the BACKUP command to specify tags for backup sets and
image copies.
The characters in a tag must be limited to the characters that are legal in file names on
the target database file system. For example, Automatic Storage Management (ASM)
does not support the use of the hyphen (-) in the file names it uses internally, so a tag
including a hyphen (such as weekly-incr) is not a legal tag name for backups in ASM
disk groups.
When you tag a backup set, the tag is an attribute of each backup piece in a given
copy of a backup set. If you create a multiplexed backup set, then each copy of the
backup set is assigned the same tag.
Example 9-4
Applying a Tag to a Backup Set
This example creates one backup set with the tag MONDAYBKP.
BACKUP AS BACKUPSET
COPIES 1
9-6
Chapter 9
Specifying Backup Output Options
DATAFILE 7
TAG mondaybkp;
Example 9-5
Applying Tags to Image Copies
This example shows that copies of data files in tablespaces users and tools are
assigned the tag MONDAYCPY. When you specify a tag for image copies, the tag applies
to each individual copy.
BACKUP AS COPY
TABLESPACE users, tools
TAG mondaycpy;
Example 9-6
Assigning Tags to Output Copies
This example creates new copies of all image copies of the database that have the tag
full_cold_copy and gives the new copies the tag new_full_cold_copy. You can use FROM
TAG to copy an image copy with a specific tag, and then use TAG to assign the output
copy a different tag.
BACKUP AS COPY
COPY OF DATABASE
FROM TAG full_cold_copy
TAG new_full_cold_copy;
9.2.5 Making Compressed Backups
When creating backup sets, you can use RMAN support for binary compression of
backup sets by including the AS COMPRESSED BACKUPSET option to the BACKUP command.
RMAN compresses the backup set contents before writing them to disk. The details of
which binary compression level is used are automatically recorded in the backup set.
There is no need to explicitly mention the type of compression used or how to
decompress the backup set in the recovery operation.
Binary compression creates some performance overhead during backup and restore
operations. Binary compression consumes CPU resources, so do not routinely
schedule compressed backups when CPU usage is high. However, the following
circumstances may warrant paying the performance penalty:
•
You are using disk-based backups when disk space in your fast recovery area or
other disk-based backup destination is limited.
•
You are performing your backups to some device over a network when reduced
network bandwidth is more important than CPU usage.
•
You are using some archival backup media such as CD or DVD, where reducing
backup sizes saves on media costs and archival storage.
See Also:
•
About Binary Compression for RMAN Backup Sets
•
AS COMPRESSED BACKUPSET option of the BACKUP command in Oracle
Database Backup and Recovery Reference for performance details
regarding backup sets
9-7
Chapter 9
Specifying Backup Output Options
Example 9-7
Making Compressed Backups
This example backs up the entire database and archived logs to the configured default
backup destination (disk or tape), producing compressed backup sets.
BACKUP
AS COMPRESSED BACKUPSET
DATABASE PLUS ARCHIVELOG;
9.2.6 Specifying Multisection Incremental Backups
A multisection backup enables large data files to be divided into sections that can be
backed up in parallel across multiple channels. This provides faster backup
performance and better recovery times.
A multisection backup contains multiple backup pieces. During a multisection backup
operation, RMAN writes to each backup piece, in parallel, by using a separate channel
for each backup piece.
Multisection full backups of databases and data files are supported starting with Oracle
Database 11g Release 1. Starting with Oracle Database 12c Release 1 (12.1), RMAN
supports multisection incremental backups. Wherever applicable, RMAN also uses
unused block compression and block change tracking while creating multisection
incremental backups. When backup sets are used, you can create multisection full or
incremental backups.
To create level 0 multisection incremental backups, the COMPATIBLE parameter must be
set to 11.0 or higher. However, to create multisection incremental backups of level 1 or
higher, you must set the COMPATIBLE parameter to 12.0.0 or higher. RMAN always
creates multisection incremental backups with FILESPERSET set to 1.
Use the SECTION SIZE clause of the BACKUP command to create multisection backups.
The SECTION SIZE clause specifies the size of each backup section. If you specify a
section size that is larger than the size of the file, then RMAN does not use
multisection backups for that file. If you specify a small section size that would produce
more than 256 sections, then RMAN increases the section size to a value that results
in exactly 256 sections.
Views to Identify Multisection Backups
Use the MULTI_SECTION column of the V$BACKUP_SET view or the recovery catalog view
RC_BACKUP_SET to determine if a backup is a multisection backup. For multisection
backups, the MULTI_SECTION column contains YES.
Views That Contain Metadata for Multisection Backups
The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views provide information about the
number of blocks in each section of a multisection backup. The BLOCKS column
specifies the number of blocks in each multisection backup.
Example 9-8
Multisection Incremental Backup of Database as Backup Sets
The following example creates a multisection level 1 incremental backup of the data
file as backup sets.
1.
Ensure that the initialization parameter COMPATIBLE of the target database is set to
12.0.0 or higher.
9-8
Chapter 9
Specifying Backup Output Options
2.
Start RMAN and connect to a target database as a user with the SYSBACKUP or
SYSDBA privilege.
See Also:
Making Database Connections with RMAN for information about
connecting to a target database
3.
If required, configure RMAN to write in parallel to the backup device.
The following example configures RMAN to use two disk channels in parallel.
CONFIGURE DEVICE TYPE disk PARALLELISM 2;
4.
Execute BACKUP with SECTION SIZE to indicate that a multisection backup must be
created.
The following example creates a multisection section level 1 backup of the data file
users_df.dbf using backup sets. Each backup piece is 100MB.
BACKUP
INCREMENTAL LEVEL 1
SECTION SIZE 100M
DATAFILE '/oradata/datafiles/users_df.dbf';
See Also:
•
About Unused Block Compression
•
Using Block Change Tracking to Improve Incremental Backup
Performance
9.2.7 Making Multisection Backups Using Image Copies
While an image copy is being created, RMAN uses multiple channels to write files
sections. However, the output of this operation is one copy for each data file.
Multisection backups provide better performance by using multiple channels to back
up large files in parallel. Starting with Oracle Database 12c Release 1 (12.1), you can
create multisection full backups that are stored as image copies.
Use the SECTION SIZE clause to create multisection backups. If the section size that you
specify is larger than the size of the file, then RMAN does not use multisection
backups for that file. If you specify a small section size that would produce more than
256 sections, then RMAN increases the section size to a value that results in exactly
256 sections
Example 9-9
Multisection Backup of Data File as Image Copies
Use the following steps to create a multisection backup of a database as image
copies:
1.
Ensure that the COMPATIBLE parameter for the target database is set to 12.0.0 or
higher.
9-9
Chapter 9
Backing Up Database Files with RMAN
2.
Start RMAN and connect to a target database as a user with the SYSBACKUP or
SYSDBA privilege.
3.
If required, configure channel parallelism so that RMAN can perform the backup
operation using multiple drives in parallel.
4.
Execute BACKUP with SECTION SIZE and AS COPY to indicate that a multisection
backup must be created using image copies.
The following command creates a multisection incremental backup of the entire
database using image copies. Each backup piece is 500MB.
BACKUP
AS COPY
SECTION SIZE 500M
DATABASE;
See Also:
•
Making Database Connections with RMAN for information about
connecting to a target database
•
Specifying Multisection Incremental Backups for information about the
views that contain information about multisection backups.
9.3 Backing Up Database Files with RMAN
This section contains the following topics:
•
Backing Up a Whole Database with RMAN
•
Backing Up Tablespaces and Data Files with RMAN
•
Backing Up Control Files with RMAN
•
Backing Up Server Parameter Files with RMAN
•
Backing Up a Database in NOARCHIVELOG Mode
9.3.1 Backing Up a Whole Database with RMAN
You can perform a whole database backup with the database mounted or open.
To perform a whole database backup, from the RMAN prompt, use the BACKUP
DATABASE command.
You may want to exclude specified tablespaces from a whole database backup. You
can persistently skip tablespaces across RMAN sessions by executing the CONFIGURE
EXCLUDE command for each tablespace that you always want to skip. You can override
the configured setting with BACKUP ... NOEXCLUDE.
To back up the database:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in "Making Database Connections with RMAN".
2.
Ensure that the database is mounted or open.
9-10
Chapter 9
Backing Up Database Files with RMAN
3.
Issue the BACKUP DATABASE command at the RMAN prompt.
The simplest form of the command requires no options or parameters:
BACKUP DATABASE;
The list of files (data files, control file, server parameter file) backed up depends on
the keyword used with the BACKUP command.
The following example backs up the database, switches the online redo logs, and
includes archived logs in the backup:
BACKUP DATABASE PLUS ARCHIVELOG;
By archiving the logs immediately after the backup, you ensure that you have a full
set of archived logs through the time of the backup. In this way, you guarantee that
you can perform media recovery after restoring this backup.
See Also:
•
Oracle Database Backup and Recovery Reference to learn about the
BACKUP command and CONNECT command
•
"Skipping Offline, Read-Only, and Inaccessible Files" to learn how to use
BACKUP ... SKIP to skip inaccessible data files or data files that are in
offline or read-only tablespaces
9.3.2 Backing Up Tablespaces and Data Files with RMAN
You can back up one or more tablespaces with the BACKUP TABLESPACE command or
one or more data files with the BACKUP DATAFILE command.
When you specify tablespaces, RMAN translates the tablespace name internally into a
list of data files. The database can be mounted or open. Tablespaces can be read/
write or read-only.
Note:
Transportable tablespaces do not have to be in read/write mode for backup
as in previous releases.
RMAN automatically backs up the control file and the server parameter file (if the
instance was started with a server parameter file) when data file 1 is included in the
backup. If control file autobackup is enabled, then RMAN writes the current control file
and server parameter file to a separate autobackup piece. Otherwise, RMAN includes
these files in the backup set that contains data file 1.
To back up tablespaces or data files:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
9-11
Chapter 9
Backing Up Database Files with RMAN
See Also:
Making Database Connections with RMAN for information about
connecting to a target database
2.
If the database instance is not started, then either mount or open the database.
3.
Run the BACKUP TABLESPACE command or BACKUP DATAFILE command at the RMAN
prompt.
The following example backs up the users and tools tablespaces to tape:
BACKUP
DEVICE TYPE sbt
TABLESPACE users, tools;
The following example uses an SBT channel to back up data files 1 through 4 and a
data file copy stored at /tmp/system01.dbf to tape:
BACKUP
DEVICE TYPE sbt
DATAFILE 1,2,3,4
DATAFILECOPY '/tmp/system01.dbf';
9.3.3 Backing Up Control Files with RMAN
You can back up the control file when the database is mounted or open. RMAN uses a
snapshot control file to ensure a read-consistent version.
If the CONFIGURE CONTROLFILE AUTOBACKUP command is set to ON (by default it is OFF), then
RMAN automatically backs up the control file and server parameter file after every
backup and after database structural changes. The control file autobackup contains
metadata about the previous backup, which is crucial for disaster recovery.
Note:
You can restore a backup of a control file made on one Data Guard database
to any other database in the environment. Primary and standby control file
backups are interchangeable. See Oracle Data Guard Concepts and
Administration to learn how to use RMAN to restore files on a standby
database.
If the autobackup feature is not set, then you must manually back up the control file in
one of the following ways:
•
Run BACKUP CURRENT CONTROLFILE.
•
Include a backup of the control file within any backup by using the INCLUDE CURRENT
CONTROLFILE option of the BACKUP command.
•
Back up data file 1, because RMAN automatically includes the control file and
server parameter file in backups of data file 1.
9-12
Chapter 9
Backing Up Database Files with RMAN
Note:
If the control file block size is different from the block size for data file 1,
then the control file cannot be written into the same backup set as the
data file. RMAN writes the control file into a backup set by itself if the
block size is different. The V$CONTROLFILE.BLOCK_SIZE column indicates
the control file block size, whereas the DB_BLOCK_SIZE initialization
parameter indicates the block size of data file 1.
9.3.3.1 About Manual Backups of the Control File
A manual backup of the control file is different from a control file autobackup. RMAN
makes a control file autobackup after the files specified in the BACKUP command are
backed up.
Thus, the autobackup—unlike a manual control file backup—contains metadata about
the backup that just completed. Also, RMAN can automatically restore autobackups
without the use of a recovery catalog.
You can make a manual backup of the current control file either as a backup set or as
an image copy. For a backup set, RMAN first creates a snapshot control file for read
consistency. You can configure the file name and location of the snapshot control file.
A snapshot control file is not needed for an image copy.
In an Oracle Real Application Clusters (Oracle RAC) environment, the following
restrictions apply:
•
The snapshot control file location must be on shared storage—that is, storage that
is accessible by all Oracle RAC instances.
•
The destination of an image copy of the current control file must be shared
storage.
See Also:
•
Configuring the Snapshot Control File Location
•
Making a Manual Backup of the Control File
9.3.3.2 Making a Manual Backup of the Control File
To make a manual backup, you can either specify INCLUDE CURRENT CONTROLFILE when
backing up other files or specify BACKUP CURRENT CONTROLFILE.
You can also back up control file copies on disk by specifying the CONTROLFILECOPY
parameter.
To manually back up the control file:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
9-13
Chapter 9
Backing Up Database Files with RMAN
3.
Execute the BACKUP command with the desired control file clause.
Example 9-10
Backing Up a Tablespace and Current Control File to Tape
This example backs up tablespace users to tape and includes the current control file in
the backup:
BACKUP DEVICE TYPE sbt
TABLESPACE users
INCLUDE CURRENT CONTROLFILE;
Example 9-11
Backing Up Current Control File to Fast Recovery Area
This example backs up the current control file to the fast recovery area as a backup
set:
BACKUP CURRENT CONTROLFILE;
RMAN first creates a snapshot control file.
Example 9-12
Backing Up the Current Control File as Image Copy
This example backs up the current control file to the default disk device as an image
copy:
BACKUP AS COPY
CURRENT CONTROLFILE
FORMAT '/tmp/control01.ctl';
Example 9-13
Backing Up a Control File Copy
This example backs up the control file copy created in the previous example to tape:
BACKUP AS COPY
CURRENT CONTROLFILE
FORMAT '/tmp/control01.ctl';
BACKUP DEVICE TYPE sbt
CONTROLFILECOPY '/tmp/control01.ctl';
A snapshot control file is not needed when backing up a control file copy.
If the control file autobackup feature is enabled, then RMAN makes two control file
backups in these examples: the explicit backup of the files specified in the BACKUP
command and the control file and server parameter file autobackup.
See Also:
Oracle Database Backup and Recovery Reference to learn about the
CONFIGURE CONTROLFILE AUTOBACKUP command
9-14
Chapter 9
Backing Up Database Files with RMAN
9.3.4 Backing Up Server Parameter Files with RMAN
RMAN automatically backs up the current server parameter file in certain cases. The
BACKUP SPFILE command backs up the parameter file explicitly. The server parameter
file that is backed up is the one currently in use by the instance.
To back up the server parameter file:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
The database must have been started with a server parameter file. If the instance
is started with a client-side initialization parameter file, then RMAN issues an error
if you execute BACKUP ... SPFILE.
3.
Execute the BACKUP ... SPFILE command.
The following example backs up the server parameter file to tape:
BACKUP DEVICE TYPE sbt SPFILE;
See Also:
Backing Up Control Files with RMAN
9.3.5 Backing Up a Database in NOARCHIVELOG Mode
You can only back up a database in NOARCHIVELOG mode when the database is closed
and in a consistent state.
The script shown in Example 9-14 puts the database into the correct mode for a
consistent, whole database backup and then backs up the database. The script
assumes that control file autobackup is enabled for the database.
You can skip tablespaces, such as read-only tablespaces, but any skipped tablespace
that has not been offline or read-only since its last backup is lost if the database has to
be restored from a backup.
Example 9-14
Backing Up a Database in NOARCHIVELOG Mode
SHUTDOWN IMMEDIATE;
# Start the database in case it suffered instance failure or was
# closed with SHUTDOWN ABORT before starting this script.
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP
INCREMENTAL LEVEL 0
MAXSETSIZE 10M
DATABASE
TAG 'BACKUP_1';
# Now that the backup is complete, open the database.
ALTER DATABASE OPEN;
9-15
Chapter 9
Backing Up Database Files with RMAN
9.3.6 Creating a Preplugin Backup of the Whole Database
Preplugin backups ensure that an RMAN backup is usable after a non-CDB is plugged
in as a PDB into a CDB.
Starting with Oracle Database Release 18c, you can create preplugin backups of nonCDBs. The preplugin backups are used for restore and recover operations after this
non-CDB is plugged in as a PDB in a destination CDB. Preplugin backups can be
either tape and disk backups.
To create a preplugin backup of a non-CDB:
1.
Start RMAN and connect to the target database (non-CDB) as a user with the
SYSDBA or SYSBACKUP privilege as described in "Making Database Connections with
RMAN".
Connect to a recovery catalog if one is used.
2.
Ensure that the required prerequisites are met as described in Oracle Database
Backup and Recovery Reference.
3.
(Optional) Configure autobackups for the database control file and server
parameter file as described in "Configuring Control File and Server Parameter File
Autobackups".
4.
Perform a full backup of the non-CDB, including archived redo log files.
If backups of the non-CDB already exist, then you can just create backups of the
archived redo log files. All existing RMAN backups are usable after their metadata
is exported into the data dictionary by using the dbms_pdb.exportrmanbackup()
procedure.
Although it is not mandatory to backup archived redo log files, it is recommended
that you do so. By archiving the logs immediately after the backup, you ensure that
you have a full set of archived logs through the time of the backup. This enables
you to perform media recovery after restoring this backup.
The following command backs up a non-CDB including all archived redo log files.
The TAG clause specifies the backup tag that is used to identify this RMAN backup.
RMAN> BACKUP DATABASE PLUS ARCHIVELOG ALL TAG for_migration;
5.
Exit RMAN.
6.
In the target database, connect to SQL*Plus as a user with the SYSDBA or SYSBACKUP
privilege.
7.
Export the RMAN backup metadata for the non-CDB into its data dictionary by
using the DBMS_PDB.EXPORTRMANBACKUP procedure.
SQL> EXECUTE DBMS_PDB.EXPORTRMANBACKUP();
While plugging the non-CDB as a PDB in a destination CDB, this backup metadata
of the source non-CDB is copied into the data dictionary of the destination CDB.
9-16
Chapter 9
Backing Up CDBs and PDBs
See Also:
About Preplugin Backups
9.4 Backing Up CDBs and PDBs
Use the BACKUP command to back up multitenant container databases (CDBs) and
pluggable databases (PDBs).
This section contains the following topics:
•
About Backing Up CDBs and PDBs
•
Backing Up a Whole CDB
•
Backing Up the Root with RMAN
•
Backing Up the Root with Oracle Enterprise Manager Cloud Control
•
Backing Up PDBs with RMAN
•
Backing Up PDBs with Oracle Enterprise Manager Cloud Control
•
Backing Up Tablespaces and Data Files in a PDB
Note:
Backups of a non-CDB are not usable after the non-CDB is plugged in as a
PDB into another CDB.
See Also:
Oracle Database Concepts for an introduction to PDBs
9.4.1 About Backing Up CDBs and PDBs
RMAN and Oracle Enterprise Manager Cloud Control provide full support for backup
and recovery in a multitenant environment.
The multitenant architecture enables an Oracle Database to function as a CDB. You
can back up and recover a whole CDB, the root only, or one or more pluggable
databases (PDBs). You can also back up and recover individual tablespaces and data
files in a PDB.
You might want to perform nightly backups of the whole multitenant container
database (CDB) by using an incremental backup strategy, or you might want to make
frequent separate backups of individual PDBs and do less frequent backups of either
the whole CDB or of the root.
In terms of the ability to recover from data loss, separately backing up the root and all
PDBs, including the CDB seed, is equivalent to backing up the whole CDB. The main
9-17
Chapter 9
Backing Up CDBs and PDBs
difference is in the number of RMAN commands that you must enter and the time to
recover. Recovering a whole CDB requires less time than recovering the root plus all
PDBs.
If the compatibility parameter for CDBs and PDBs is set to 12.2 or higher, RMAN also
enables you to perform sparse backups on your CDB and PDB. These backups copy
the latest updates from the delta storage space assigned to each database.
See Also:
About Sparse Backups for more information on sparse backups
9.4.2 Backing Up a Whole CDB
Backing up a whole multitenant container database (CDB) is similar to backing up a
non-CDB. When you back up a whole CDB, RMAN backs up the root, all the pluggable
databases (PDBs), and the archived redo logs.
The BACKUP command is used to back up CDBs. You can then recover either the whole
CDB, the root only, or one or more PDBs from the CDB backup.
To backup up a whole CDB:
1.
Start RMAN and connect to the root as a common user with the SYSBACKUP or
SYSDBA privilege and to a recovery catalog (if used) as described in Making
Database Connections with RMAN.
2.
Ensure that the database is mounted or open.
3.
Issue the BACKUP DATABASE command at the RMAN prompt.
The simplest form of the command requires no options or parameters:
BACKUP DATABASE;
The list of files backed up depends on the keyword used with the BACKUP
command.
The following example backs up the CDB, switches the online redo logs, and
includes archived logs in the backup:
BACKUP DATABASE PLUS ARCHIVELOG;
By archiving the logs immediately after the backup, you ensure that you have a full
set of archived logs through the time of the backup. In this way, you guarantee that
you can perform media recovery after restoring this backup.
Note:
Proxy PDBs are not backed up while backing up a CDB.
9-18
Chapter 9
Backing Up CDBs and PDBs
9.4.3 Backing Up the Root with RMAN
You can use RMAN to make a backup of only the root. Because the root contains
critical metadata for the whole CDB, Oracle recommends that you back up the root or
back up the whole CDB at regular intervals.
To back up the root with RMAN:
1.
Start RMAN and connect to the root as a common user with the SYSBACKUP or
SYSDBA privilege as described in Connecting as Target to the Root.
2.
Enter the following command:
BACKUP DATABASE ROOT;
9.4.4 Backing Up the Root with Oracle Enterprise Manager Cloud
Control
Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to back up the
root.
Use the following steps to back up the root with Cloud Control:
1.
From the Database Home page, select Backup & Recovery from the Availability
menu, and then select Schedule Backup.
2.
If you have not logged in to the database previously, then the Database Login
page is displayed. Log in to the database using Named or New credentials and
then click Login.
Cloud Control displays the Schedule Backup page.
3.
From the Customized Backup section, choose Container Database Root, and
then click Schedule Customized Backup.
The Schedule Backup Wizard appears and displays the Options page.
4.
Complete the wizard by navigating the remainder of the pages to back up the root.
For more information about each page of the wizard, click Help.
See Also:
Accessing the Database Home Page Using Cloud Control
9.4.5 Backing Up PDBs with RMAN
RMAN enables you to back up one or more PDBs in a CDB using the BACKUP
command.
There are two approaches to backing up a PDB with RMAN:
•
Connect to the root and then use the BACKUP PLUGGABLE DATABASE command. This
approach enables you to back up multiple PDBs with a single command.
9-19
Chapter 9
Backing Up CDBs and PDBs
When you connect to the root and back up a PDB, this backup is visible to the root
and to that particular PDB but not to the other PDBs.
•
Connect to the PDB and use the BACKUP DATABASE command. This approach backs
up only a single PDB and enables you to use the same commands used for
backing up non-CDBs.
Backups created when connected to any PDB are visible when connected to the
root.
When you back up individual PDBs, the archived redo logs are not backed up.
To back up one or more PDBs while connected to the root:
1.
Start RMAN and connect to the root as a common user with the SYSBACKUP or
SYSDBA privilege as described in Connecting as Target to the Root.
2.
Issue a BACKUP PLUGGABLE DATABASE command at the RMAN prompt.
The following example backs up the PDBs sales and hr:
BACKUP PLUGGABLE DATABASE sales, hr;
To back up one PDB while connected to the PDB:
1.
Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA
privilege as described in Connecting as Target to a PDB.
2.
Issue a BACKUP DATABASE command at the RMAN prompt.
BACKUP DATABASE;
Note:
Backing up a proxy PDB using RMAN is not supported.
Note:
PDB backups can be used to perform media recovery only if the backups
include all the archived redo log files that contain changes for this PDB.
When creating a backup while connected to the PDB, there may be some
situations in which all the required logs are not backed up.
9.4.6 Creating Preplugin Backups of PDBs Using RMAN
Preplugin backups of a PDB can be used to perform restore and recover operations
after the PDB is migrated and plugged in to a different destination CDB.
Starting with Oracle Database Release 18c, you can create preplugin backups of
PDBs to disk and tape.
9-20
Chapter 9
Backing Up CDBs and PDBs
Note:
The destination CDB does not manage backups created on the source CDB
after it has been plugged in to the destination CDB.
To create preplugin backups of a PDB:
1.
Ensure that the required prerequisites are met as described in Oracle Database
Backup and Recovery Reference.
2.
Start RMAN and connect using one of the following techniques as described in
"Making Database Connections with RMAN":
•
•
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
Connect to the PDB as a local user or common user with the SYSDBA or
SYSBACKUP privilege.
3.
(Optional) Configure control file and server parameter file autobackups for the
target database as described in "Configuring Control File and Server Parameter
File Autobackups".
4.
Create a full backup of the PDB including the archived redo log files.
If RMAN backups of the PDB already exist, then these backups are usable after
the PDB is migrated to another destination CDB. However, it is recommended that
you back up the archived redo log files.
The following command backs up the PDB when you are connected to the PDB as
a local user with the SYSDBA or SYSBACKUP privilege:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG ALL TAG for_migration;
The following command backs up the PDB my_pdb when connected to the ROOT as a
common user with the SYSDBA or SYSBACKUP privilege:
RMAN> BACKUP PLUGGABLE DATABASE my_pdb PLUS ARCHIVELOG ALL TAG for_migration;
Note:
When you use BACKUP PLUGGABLE DATABASE, all the required archived redo
logs are backed up only when the CDB uses local undo.
The metadata that is required for these preplugin backups to be usable in a destination
CDB is included in the XML file created when the PDB is unplugged from the source
CDB.
See Also:
About Preplugin Backups
9-21
Chapter 9
Backing Up CDBs and PDBs
9.4.7 Backing Up PDBs with Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to perform
backups of pluggable databases (PDBs).
To back up one or more PDBs with Cloud Control, complete the following steps:
1.
From the Database Home page, select Backup & Recovery from the Availability
menu, and then select Schedule Backup.
2.
If you have not logged in to the database previously, then the Database Login
page is displayed. Log in to the database using Named or New credentials and
then click Login.
Cloud Control displays the Schedule Backup page.
3.
From the Customized Backup section, select Pluggable Databases, and then
click Schedule Customized Backup.
The Schedule Backup Wizard appears and displays the Pluggable Databases
page.
4.
Select the PDBs that you want to back up by following these steps:
a.
Click Add to display the Available Pluggable Databases page.
b.
From the list of PDBs shown, click in the Select column to designate the PDBs
you want to back up. Optionally, you can click Select All to turn on the Select
option for all available PDBs. Click Select None to deselect all PDBs.
c.
Click the Select button to return to the Pluggable Databases page.
d.
Optionally, you can remove PDBs from the table by clicking in the Select
column for each PDB that you want to remove and then clicking Remove.
5.
Click Next to move to the Options page of the wizard.
6.
Complete the wizard by navigating the remainder of the pages to back up the
PDBs. For more information about each page of the wizard, click Help.
See Also:
Accessing the Database Home Page Using Cloud Control
9.4.8 Backing Up Tablespaces and Data Files in a PDB
Because tablespaces in different PDBs can have the same name, to eliminate
ambiguity you must connect directly to a PDB to back up one or more of its
tablespaces.
Ensure that the CDB is open or mounted. Tablespaces can be read-only or read-write.
In contrast, because data file numbers and paths are unique across the CDB, you can
connect to either the root or a PDB to back up PDB data files. If you connect to the
root, you can back up data files from multiple PDBs with a single command. If you
connect to a PDB, you can back up only data files in that PDB.
9-22
Chapter 9
Backing Up CDBs and PDBs
To back up tablespaces in a PDB:
1.
Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA
privilege as described in Connecting as Target to a PDB.
2.
Issue a BACKUP TABLESPACE command.
The following example backs up the tablespaces users and examples to the
configured default device.
BACKUP TABLESPACE users, examples;
To back up data files in a PDB:
1.
Do one of the following:
•
Start RMAN and connect to the root as a common user with the SYSBACKUP or
SYSDBA privilege.
Start RMAN and connect to the PDB as a local user with the SYSBACKUP or
•
SYSDBA privilege.
2.
Issue a BACKUP DATAFILE command.
BACKUP DATAFILE 10, 13;
See Also:
•
Connecting as Target to the Root
•
Connecting as Target to a PDB
9.4.9 Example: Creating a Preplugin Backup of a PDB with RMAN
This example creates a preplugin backup of the PDB my_pdb that is contained in CDB
cdb_prod. The CDB uses shared undo and is open in read-write mode.
1.
Ensure that the prerequisites required for creating preplugin backups are met as
described in Oracle Database Backup and Recovery Reference.
2.
Start RMAN and connect to the root as a common user with the SYSBACKUP
privilege.
The following command uses password file authentication to connect to the root.
cdb_prod is the net service name of the CDB.
CONNECT TARGET "sbu@cdb_prod AS SYSBACKUP";
Enter the password for the sbu user when prompted.
3.
Enable control file autobackup for the CDB.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
4.
Back up the PDB using the BACKUP PLUGGABLE DATABASE command. Include archived
redo logs in the backup so that you can use this backup to perform media
recovery, if required.
9-23
Chapter 9
Backing Up Application Containers
The following command creates a preplugin backup of my_pdb, including the
archived redo log files. The tag used when naming the backups is mypdb_bkup.
BACKUP PLUGGABLE DATABASE my_pdb PLUS ARCHIVELOG TAG mypdb_bkup;
9.5 Backing Up Application Containers
RMAN enables you to use the BACKUP command to perform backup operations on the
application root, one or more application PDBs, and the application container.
Note:
•
About Backing Up Application Containers
•
Backing Up the Application Root
•
Backing Up the Application Root and its Application PDBs
•
Backing Up Application PDBs
9.5.1 About Backing Up Application Containers
RMAN can back up application containers, application PDBs, and the application root.
An application container is an optional component of a CDB that stores data for one or
more applications and shares application metadata and common data. A CDB can
contain zero or more application containers. An application container consists of
exactly one application root (different from the root in its CDB) and one or more
application PDBs. The application root serves as the parent container to all the
application PDBs plugged into it.
An application container typically contains one or more application common users. An
application common user can only connect to the application root in which it was
created or a PDB that is plugged in to this application root. An application root has its
own service name, and you can connect to the application root in the same way that
you connect to a PDB.
To perform backup and recovery tasks for the application root or application PDBs,
you connect either to the application root or CDB root.
See Also:
•
Oracle Database Concepts for conceptual information about application
containers
•
Oracle Database Administrator’s Guide for information about creating
application containers
9-24
Chapter 9
Backing Up Application Containers
9.5.2 Backing Up the Application Root
RMAN provides multiple ways of backing up the application root using the BACKUP
command.
Use one of the following approaches to back up the application root:
•
Connect to the application root and use the BACKUP DATABASE ROOT command
•
Connect to the CDB root and use the BACKUP PLUGGABLE DATABASE command
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To connect to and back up the application root:
1.
Start RMAN and connect to the application root as an application common user
with the SYSDBA or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
2.
Use the following BACKUP command to back up the application root.
BACKUP DATABASE ROOT;
To back up the application root when connected to the root in a CDB
1.
Start RMAN and connect to the CDB root as a common user with the SYSDBA or
SYSBACKUP privilege.
2.
Use the BACKUP PLUGGABLE DATABASE command to back up the application root.
The following example backs up an application root named hr_appcont:
BACKUP PLUGGABLE DATABASE hr_appcont;
See Also:
Making RMAN Connections to a CDB
9.5.3 Backing Up the Application Root and its Application PDBs
Use the BACKUP command to back up an application container, which consists of the
application root and all the application PDBs that belong to the application root.
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To back up the application root and all its application PDBs:
1.
Start RMAN and connect to the application root as an application common user
with the SYSDBA or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
2.
Use the following command to back up the application container:
BACKUP DATABASE;
9-25
Chapter 9
Backing Up Sparse Databases with RMAN
See Also:
Making RMAN Connections to a CDB
9.5.4 Backing Up Application PDBs
The BACKUP command is used to back up one or more application PDBs.
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To back up one or more application PDBs:
1.
Start RMAN and establish one of the following types of connections:
•
Connect to the application root as an application common user with the SYSDBA
or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
•
2.
Connect to the CDB root as a common user with the SYSDBA or SYSBACKUP
privilege.
Use the BACKUP PLUGGABLE DATABASE command to back up the application PDB. To
back up multiple application PDBs, use a comma-separated list of application PDB
names.
The following command backs up an application PDB named hr_app_pdb:
BACKUP PLUGGABLE DATABASE hr_app_pdb;
See Also:
Making RMAN Connections to a CDB
9.6 Backing Up Sparse Databases with RMAN
Use the BACKUP command to back up sparse databases.
This section contains the following topics:
•
Backing Up a Sparse Database with RMAN
•
Backing Up Sparse Tablespaces and Data Files with RMAN
•
Backing Up a Sparse CDB with RMAN
•
Backing Up a Sparse PDB with RMAN
9-26
Chapter 9
Backing Up Sparse Databases with RMAN
Note:
The base (read-only) data files in a sparse database are not encrypted.
Ensure that the base data files are stored in a protected storage and
accessed using secured communications.
9.6.1 Backing Up a Sparse Database with RMAN
RMAN enables you to back up a sparse database, using steps similar to backing up a
whole database, in the backup set or image copy format.
The difference while backing up a sparse database is that RMAN backs up data only
from the delta storage space of the database, which contains the latest changes made
to the data blocks within the sparse database.
Ensure you meet the following requirements before backing up a sparse database:
•
The base database for your sparse database must be read-only
•
The COMPATIBLE initialization parameter of the database being backed up must be
set to 12.2 or higher.
To back up a sparse database
1.
Start RMAN and connect to a target database as described in Making Database
Connections with RMAN.
2.
Ensure that the database is mounted or open.
3.
Issue the BACKUP command with the AS SPARSE option. To specify your backup
format, use one of the following options:
•
To create your backup in the backup set format, use the AS SPARSE BACKUPSET
option. The following example performs a sparse backup in the backup set
format:
BACKUP AS SPARSE BACKUPSET DATABASE PLUS ARCHIVELOG;
•
To create your backup in the image copy format use the AS SPARSE COPY option.
The following example performs a backup in the image copy format:
BACKUP AS SPARSE COPY DATABASE PLUS ARCHIVELOG;
•
To create your backup in the compressed backup set format use the
COMPRESSED BACKUPSET option. The following example performs a backup in the
compressed backups set format:
BACKUP AS SPARSE COMPRESSED BACKUPSET DATABASE;
9-27
Chapter 9
Backing Up Sparse Databases with RMAN
See Also:
•
About Sparse Backups for more information on sparse backups
•
Backing Up a Whole Database with RMAN for more information on
how to perform a traditional backup on a normal database
•
Backing Up Sparse Tablespaces and Data Files with RMAN
•
Performing Complete Recovery of a Sparse Database
See Also:
Oracle Database Backup and Recovery Reference for more information
on the options to back up sparse databases
9.6.2 Backing Up Sparse Tablespaces and Data Files with RMAN
You can back up one or more tablespaces containing sparse data files or individual
sparse data files using the BACKUP command.
While backing up tablespaces, RMAN translates the BACKUP command to individual
data files that are sparse compatible. Similarly, only data files containing sparse data
blocks are eligible for a sparse backup. RMAN creates sparse backups of sparse data
files and non-sparse backups of non-sparse data files.
Ensure that the database containing the sparse tablespace or data file has the
COMPATIBLE initialization parameter set to 12.2 or higher.
To back up sparse tablespaces or data files:
1.
Start RMAN and connect to a target database. For tablespaces and data files in
CDB, you must connect to the root as a user with the SYSDBA or SYSBACKUP privilege.
See Also:
Making Database Connections with RMAN for information about
connecting to a target database
2.
Ensure that the database instance is mounted or open.
3.
Run the BACKUP command for the tablespace or data file with the AS SPARSE option.
Specify whether you want the backup in the backup set format, image copy format,
or compressed backup set format. To do this, state one of the following options:
•
To create your backup in the backup set format, use the AS SPARSE BACKUPSET
option. The following example performs a sparse backup in the backup set
format:
BACKUP AS SPARSE BACKUPSET TABLESPACE MYTBS1;
9-28
Chapter 9
Backing Up Sparse Databases with RMAN
•
To create your backup in the image copy format use the AS SPARSE COPY option.
The following example performs a backup in the image copy format:
BACKUP AS SPARSE COPY DATAFILE 8,9,10;
•
To create your backup in the compressed backup set format use the
COMPRESSED BACKUPSET option. The following example performs a backup in the
compressed backups set format:
BACKUP AS SPARSE COMPRESSED BACKUPSET TABLESPACE MYTBS3;
See Also:
•
Backing Up a Sparse Database with RMAN
•
Oracle Database Backup and Recovery Reference
9.6.3 Backing Up a Sparse CDB with RMAN
You can back up a sparse multitenant container database (CDB) or a CDB containing
some sparse pluggable databases (PDBs) by performing a backup operation similar to
backing up a sparse database using the BACKUP command.
Ensure that the COMPATIBLE initialization parameter of your CDB is set to 12.2 or higher.
To back up a sparse CDB:
1.
Start RMAN and connect to root as a common user with the SYSBACKUP or SYSDBA
privilege.
2.
Ensure that the CDB is mounted or open and in ARCHIVELOG mode.
3.
Enter the BACKUP command with the AS SPARSE option. Specify which format you
want to create your backup in:
•
To create your backup in the backup set format, use the AS SPARSE BACKUPSET
option. The following example performs a backup on the sparse CDB in the
backup set format:
BACKUP AS SPARSE BACKUPSET DATABASE;
•
To create your backup in the image copy format use the AS SPARSE COPY option.
The following example performs a backup on the sparse CDB in the image
copy format:
BACKUP AS SPARSE COPY DATABASE;
•
To create your backup in the compressed backup set format use the
COMPRESSED BACKUPSET option. The following example performs a backup on the
sparse CDB in the compressed backups set format:
BACKUP AS SPARSE COMPRESSED BACKUPSET DATABASE;
9-29
Chapter 9
Backing Up Sparse Databases with RMAN
See Also:
•
Backing Up a Sparse Database with RMAN
•
Performing Complete Recovery of a Sparse CDB
9.6.4 Backing Up a Sparse PDB with RMAN
RMAN enables you to back up one or more sparse PDBs in a CDB.
Ensure that the COMPATIBLE initialization parameter is set to 12.2 or higher.
To back up a sparse PDB while connected to root:
1.
Start RMAN and connect to the root as a common user with the SYSBACKUP or
SYSDBA privilege as described in Connecting as Target to the Root.
2.
Run the BACKUP command for the pluggable database. Specify the format for your
backup:
•
To create your backup in the backup set format, use the AS SPARSE BACKUPSET
option. The following example performs a sparse backup in the backup set
format:
BACKUP AS SPARSE BACKUPSET PLUGGABLE DATABASE PDB1;
•
To create your backup in the image copy format use the AS SPARSE COPY option.
The following example performs a backup in the image copy format:
BACKUP AS SPARSE COPY PLUGGABLE DATABASE PDB1;
•
To create your backup in the compressed backup set format use the
COMPRESSED BACKUPSET option. The following example performs a backup in the
compressed backups set format:
BACKUP AS SPARSE COMPRESSED BACKUPSET PLUGGABLE DATABASE PDB1;
To back up a sparse PDB while connected to the PDB:
1.
Start RMAN. Connect to the sparse PDB as a local user with the SYSBACKUP or
SYSDBA privilege as described in Connecting as Target to a PDB.
2.
Run the BACKUP command at the RMAN prompt, with the AS SPARSE option and the
format required. To specify the format for your backup, use one of the following
commands:
•
To create your backup in the backup set format, use the AS SPARSE BACKUPSET
option. The following example performs a sparse backup in the backup set
format:
BACKUP AS SPARSE BACKUPSET DATABASE;
•
To create your backup in the image copy format use the AS SPARSE COPY option.
The following example performs a backup in the image copy format:
BACKUP AS SPARSE COPY DATABASE;
9-30
Chapter 9
Backing Up Archived Redo Logs with RMAN
•
To create your backup in the compressed backup set format use the
COMPRESSED BACKUPSET option. The following example performs a backup in the
compressed backups set format:
BACKUP AS SPARSE COMPRESSED BACKUPSET DATABASE;
3.
To back up a tablespace from a sparse PDB, connect to the selected PDB directly
and then run the BACKUP command with the AS SPARSE option, the appropriate
backup format, and the tablespace name.
4.
To back up a data file from a sparse PDB, you can either connect to root or
directly to the PDB. Run the BACKUP command with the AS SPARSE option, the
backup format, and the data file name, to back up an individual data file.
See Also:
Backing Up PDBs with RMAN
Performing Recovery of a Sparse PDB with RMAN
9.7 Backing Up Archived Redo Logs with RMAN
Archived redo logs are the key to successful media recovery. You should back them
up regularly.
This section contains the following topics:
•
About Backups of Archived Redo Logs for non-CDBs
•
About Backup of Archived Redo Logs in CDBs
•
Backing Up Archived Redo Log Files in non-CDBs
•
Backing Up Only Archived Redo Logs That Need Backups in non-CDBs
•
Backing Up Archived Redo Logs in CDBs
•
Deleting Archived Redo Logs After Backups in non-CDBs
•
Deleting Archived Redo Logs After Backups in CDBs
9.7.1 About Backups of Archived Redo Logs for non-CDBs
Several features of RMAN backups are specific to archived redo logs. For example,
you can use BACKUP ... DELETE to delete one or all copies of archived redo logs from
disk after backing them up to backup sets.
This section contains the following topics:
•
About Archived Redo Log Failover
•
About Online Redo Log Switching
9.7.1.1 About Archived Redo Log Failover
Even if your redo logs are being archived to multiple destinations and you use RMAN
to back up archived redo logs, RMAN selects only one copy of the archived redo log
9-31
Chapter 9
Backing Up Archived Redo Logs with RMAN
file to include in the backup set. Because logs with the same log sequence number are
identical, RMAN does not need to include more than one log copy.
The archived redo log failover feature enables RMAN to complete a backup even
when some archiving destinations are missing logs or contain logs with corrupt blocks.
If at least one log corresponding to a given log sequence and thread is available in the
fast recovery area or any of the archiving destinations, then RMAN tries to back it up.
If RMAN finds a corrupt block in a log file during backup, it searches other destinations
for a copy of that log without corrupt blocks.
For example, assume that you archive logs 121 through 124 to two destinations: /
arch1 and /arch2. Table 9-1 shows the archived redo log records in the control file.
Table 9-1
Sample Archived Redo Log Records
Sequence
File Name in /arch1
File Name in /arch2
121
/arch1/archive1_121.arc
/arch2/archive1_121.arc
122
/arch1/archive1_122.arc
/arch2/archive1_122.arc
123
/arch1/archive1_123.arc
/arch2/archive1_123.arc
124
/arch1/archive1_124.arc
/arch2/archive1_124.arc
However, unknown to RMAN, a user deletes logs 122 and 124 from the /arch1
directory. Afterward, you run the following backup:
BACKUP ARCHIVELOG
FROM SEQUENCE 121
UNTIL SEQUENCE 125;
With failover, RMAN completes the backup, using logs 122 and 124 in /arch2.
9.7.1.2 About Online Redo Log Switching
Automatic online redo log switching is an important RMAN feature.
To make an open database backup of archived redo logs that includes the most recent
online redo log, you can execute the BACKUP command with any of the following
clauses:
•
PLUS ARCHIVELOG
•
ARCHIVELOG ALL
•
ARCHIVELOG FROM ...
Before beginning the backup, RMAN switches out of the current redo log group, and
archives all online redo logs that have not yet been archived, up to and including the
redo log group that was current when the command was issued. This feature ensures
that the backup contains all redo generated before the start of the command.
An effective way of backing up archived redo logs is the BACKUP ... PLUS ARCHIVELOG
command, which causes RMAN to do the following:
1.
Run the ALTER SYSTEM ARCHIVE LOG CURRENT statement.
2.
Run BACKUP ARCHIVELOG ALL . If backup optimization is enabled, then RMAN skips
logs that it has already backed up to the specified device.
3.
Back up the rest of the files specified in the BACKUP command.
9-32
Chapter 9
Backing Up Archived Redo Logs with RMAN
4.
Run the ALTER SYSTEM ARCHIVE LOG CURRENT statement.
5.
Back up any remaining archived logs generated during the backup. If backup
optimization is not enabled, then RMAN backs up the logs generated in Step 1
plus all the logs generated during the backup.
The preceding steps guarantee that data file backups taken during the command are
recoverable to a consistent state. Also, unless the online redo log is archived at the
end of the backup, DUPLICATE is not possible with the backup.
9.7.2 About Backup of Archived Redo Logs in CDBs
In a CDB, archived redo logs can be backed up only when you connect to the root as a
common user with the SYSDBA or SYSBACKUP privilege.
When you connect to a PDB as a local user with SYSDBA or SYSBACKUP privilege, you
cannot back up or delete archived redo logs.
If your archived redo logs are being copied to multiple destinations, when you connect
to the root and backup archived redo log files, RMAN includes only one copy of the
archived redo log files in a backup. You can switch archived redo log files when you
connect to root of a CDB. Therefore, the information in "About Archived Redo Log
Failover" and "About Online Redo Log Switching" is applicable when you connect to
the root. However, you cannot backup or switch archived redo log files when
connected to a PDB.
See Also:
Backing Up Archived Redo Logs in CDBs
9.7.3 Backing Up Archived Redo Log Files in non-CDBs
To back up archived logs, use the BACKUP ARCHIVELOG command.
If backup optimization is enabled, then RMAN skips backups of archived logs that
have already been backed up to the specified device.
To back up archived redo log files:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
3.
Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command.
The following example backs up the database and all archived redo logs:
BACKUP DATABASE PLUS ARCHIVELOG;
The following example uses a configured disk or SBT channel to back up one copy
of each log sequence number for all archived redo logs:
BACKUP ARCHIVELOG ALL;
9-33
Chapter 9
Backing Up Archived Redo Logs with RMAN
You can also specify a range of archived redo logs by time, SCN, or log sequence
number, as in the following example:
BACKUP ARCHIVELOG
FROM TIME 'SYSDATE-30'
UNTIL TIME 'SYSDATE-7';
9.7.4 Backing Up Only Archived Redo Logs That Need Backups in
non-CDBs
You can indicate that RMAN should automatically skip backups of archived redo logs.
Use one of the following techniques:
•
Configure backup optimization.
If you enable backup optimization, then the BACKUP ARCHIVELOG command skips
backing up files when an identical archived log has been backed up to the
specified device type. An archived log is considered identical to another when it
has the same DBID, thread, sequence number, and RESETLOGS SCN and time.
•
Configure an archived redo log deletion policy.
If the deletion policy is configured with the BACKED UP integer TIMES clause, then a
BACKUP ARCHIVELOG command copies the logs unless integer backups exist on the
specified device type. If integer backups of the logs exist, then the BACKUP
ARCHIVELOG command skips the logs.
The BACKUP ... NOT BACKED UP integer TIMES command specifies that RMAN backs up
only those archived log files that have not been backed up at least integer times to the
specified device. To determine the number of backups for a file, RMAN only considers
backups created on the same device type as the current backup.
The BACKED UP clause is a convenient way to back up archived logs to a specified
device type. For example, you can specify that RMAN should keep two copies of each
archived redo log on tape and skip additional backups.
To back up archived redo logs that need backups:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
3.
Ensure that appropriate channels are configured for the backup.
4.
Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause.
BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;
See Also:
•
Backup Optimization and the CONFIGURE command
•
Configuring an Archived Redo Log Deletion Policy
•
Using Backup Optimization to Skip Files for scenarios using NOT BACKED
UP
9-34
Chapter 9
Backing Up Archived Redo Logs with RMAN
9.7.5 Backing Up Archived Redo Logs in CDBs
You can back up archived redo logs in a multitenant container database (CDB) by
using the BACKUP ARCHIVELOG command.
To back up archived redo logs in a CDB:
1.
Start RMAN and connect to the root as a user with the SYSDBA or SYSBACKUP
privilege as described in Connecting as Target to the Root.
2.
Ensure that the target CDB is mounted or open.
3.
Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command.
The following example backs up the database and all archived redo logs:
BACKUP DATABASE PLUS ARCHIVELOG;
The following example uses a configured disk or SBT channel to back up one copy
of each log sequence number for all archived redo logs:
BACKUP ARCHIVELOG ALL;
To back up only archived redo logs that need backup in a CDB:
1.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege.
2.
Ensure that the target CDB is mounted or open.
3.
Ensure that appropriate channels are configured for the backup.
4.
Configure RMAN to automatically skip backups of archived redo logs. Use one of
the following techniques:
5.
•
Configure backup optimization so that the BACKUP ARCHIVELOG command skips
backing up files when an identical archived log has been backed up to the
specified device type.
•
Configure an archived redo log retention policy using the BACKED UP integer
TIMES clause. A BACKUP ARCHIVELOG command will copy the logs unless integer
backups exist on the specified device type.
Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause.
BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;
See Also:
•
About Backup of Archived Redo Logs in CDBs
•
Backing Up Only Archived Redo Logs That Need Backups in non-CDBs
9-35
Chapter 9
Backing Up Archived Redo Logs with RMAN
9.7.6 Deleting Archived Redo Logs After Backups in non-CDBs
The BACKUP ARCHIVELOG ... DELETE INPUT command deletes archived log files after they
are backed up. This command eliminates the separate step of manually deleting
archived redo logs.
With DELETE INPUT, RMAN deletes only the specific copy of the archived log chosen for
the backup set. With DELETE ALL INPUT, RMAN deletes each backed-up archived redo
log file from all log archiving destinations.
The BACKUP ... DELETE INPUT and DELETE ARCHIVELOG commands obey the archived
redo log deletion policy for logs in all archiving locations. For example, if you specify
that logs be deleted only when backed up at least twice to tape, then BACKUP ...
DELETE honors this policy.
For the following procedure, assume that you archive to /arc_dest1, /arc_dest2, and
the fast recovery area.
To delete archived redo logs after a backup:
1.
Start RMAN and connect to a target database and a recovery catalog (if used) as
described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
3.
Run the BACKUP command with the DELETE INPUT clause.
Assume that you run the following BACKUP command:
BACKUP DEVICE TYPE sbt
ARCHIVELOG ALL
DELETE ALL INPUT;
In this case, RMAN backs up only one copy of each log sequence number in these
archiving locations. RMAN deletes all copies of any log that it backed up from both
the fast recovery area and the other archiving destinations.
If you specify DELETE INPUT rather than DELETE ALL INPUT, then RMAN only deletes
the specific archived redo log files that it backed up. For example, RMAN deletes
the logs in /arc_dest1 if these files were used as the source of the backup, but
leave the contents of the /arc_dest2 intact.
See Also:
•
Configuring an Archived Redo Log Deletion Policy
•
Oracle Data Guard Concepts and Administration to learn about archived
redo log management with standby databases
•
Oracle Database Backup and Recovery Reference to learn about the
CONFIGURE ARCHIVELOG DELETION POLICY and DELETE ARCHIVELOG commands
•
Deleting RMAN Backups and Archived Redo Logs
9-36
Chapter 9
Making and Updating RMAN Incremental Backups
9.7.7 Deleting Archived Redo Logs After Backups in CDBs
In a CDB, you can delete archived redo logs after they are backed up by using the
BACKUP ARCHIVELOG ... DELETE INPUT command.
To delete archived redo logs in a CDB after they are backed up:
1.
Start RMAN and connect to the root as a user with the SYSDBA or SYSBACKUP
privilege as described in Making Database Connections with RMAN.
2.
Ensure that the target database is mounted or open.
3.
Run the BACKUP command with the DELETE INPUT clause.
See Also:
Oracle Database Backup and Recovery Reference for information about the
BACKUP command
9.8 Making and Updating RMAN Incremental Backups
An incremental backup copies only data file blocks that have changed since a
specified previous backup. Use the BACKUP command to create incremental backups.
An incremental backup is either a cumulative incremental backup or a differential
incremental backup.
Although the content of the backups is the same, BACKUP DATABASE and BACKUP
INCREMENTAL LEVEL 0 DATABASE are different. A full backup is not usable as part of an
incremental strategy, whereas a level 0 incremental backup is the basis of an
incremental strategy. No RMAN command can change a full backup into a level 0
incremental backup.
As with full backups, RMAN can make incremental backups of an ARCHIVELOG mode
database that is open. If the database is in NOARCHIVELOG mode, then RMAN can make
incremental backups only after a consistent shutdown.
This section contains the following topics:
•
Purpose of RMAN Incremental Backups
•
Planning an Incremental Backup Strategy
•
Making Incremental Backups
•
Incrementally Updating Backups
•
Using Block Change Tracking to Improve Incremental Backup Performance
9.8.1 Purpose of RMAN Incremental Backups
RMAN incremental backups provide multiple benefits.
The primary reasons for making incremental backups part of your strategy are:
9-37
Chapter 9
Making and Updating RMAN Incremental Backups
•
Faster daily backups if block change tracking is enabled (see "Using Block
Change Tracking to Improve Incremental Backup Performance")
•
Ability to roll forward data file image copies, thereby reducing recovery time and
avoiding repeated full backups
•
Less bandwidth consumption when backing up over a network
•
Improved performance when the aggregate tape bandwidth for tape write I/Os is
much less than the aggregate disk bandwidth for disk read I/Os
•
Possibility of recovering changes to objects created with the NOLOGGING option
For example, direct load inserts do not create redo log entries, so their changes
cannot be reproduced with media recovery. Direct load inserts do change data
blocks, however, and these blocks are captured by incremental backups.
•
Ability to synchronize a physical standby database with the primary database
You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup
on the primary database that starts at the current SCN of the standby database,
which you can then use to roll forward the standby database. See Oracle Data
Guard Concepts and Administration to learn how to apply incremental backups to
a standby database.
See Also:
Oracle Database Administrator’s Guide for more information about NOLOGGING
mode
9.8.2 Planning an Incremental Backup Strategy
Choose a backup strategy according to an acceptable MTTR (mean time to recover).
For example, you can implement a three-level backup scheme so that a level 0 backup
is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is
taken daily. In this strategy, you never have to apply more than a day of redo for
complete recovery.
When deciding how often to take level 0 backups, a general rule is to take a new level
0 backup whenever 20% or more of the data has changed. If the rate of change to
your database is predictable, then you can observe the size of your incremental
backups to determine when a new level 0 backup is appropriate. The following SQL
query determines the number of blocks written to an incremental level 1 backup of
each data file with at least 20% of its blocks backed up:
SELECT
FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME,
BLOCKS, DATAFILE_BLOCKS
FROM
V$BACKUP_DATAFILE
WHERE
INCREMENTAL_LEVEL > 0
AND
BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;
Compare the number of blocks in level 1 backups to a level 0 backup. For example, if
you create only level 1 cumulative backups, then take a new level 0 backup when the
most recent level 1 backup is about half the size of the level 0 backup.
9-38
Chapter 9
Making and Updating RMAN Incremental Backups
An effective way to conserve disk space is to make incremental backups to disk, and
then offload the backups to tape with the BACKUP AS BACKUPSET command. Incremental
backups are generally smaller than full backups, which limits the space required to
store them until they are moved to tape. When the incremental backups on disk are
backed up to tape, the tape is more likely to stream because all blocks of the
incremental backup are copied to tape. There is no possibility of delay due to time
required for RMAN to locate changed blocks in the data files.
Another strategy is to use incrementally updated backups, as explained in
"Incrementally Updating Backups". In this strategy, you create an image copy of each
data file, and then periodically roll forward this copy by making and then applying a
level 1 incremental backup. In this way you avoid the overhead of making repeated full
image copies of your data files, but enjoy all of the advantages.
In a Data Guard environment, you can offload incremental backups to a physical
standby database. Incremental backups of a standby and primary database are
interchangeable. Thus, you can apply an incremental backup of a standby database to
a primary database, or apply an incremental backup of a primary database to a
standby database.
See Also:
Oracle Data Guard Concepts and Administration to learn how to back up a
standby database with RMAN. In particular, consult Chapter 10, "Managing
Physical and Snapshot Standby Databases"
9.8.3 Making Incremental Backups
After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. By
default incremental backups are differential.
To make an incremental backup:
1.
Start RMAN and connect to a target database and a recovery catalog (if used).
See Also:
Making Database Connections with RMAN
2.
Ensure that the target database is mounted or open.
3.
Execute the BACKUP INCREMENTAL command with the desired options.
Use the LEVEL parameter to indicate the incremental level. The following example
makes a level 0 incremental database backup.
BACKUP
INCREMENTAL LEVEL 0
DATABASE;
The following example makes a differential incremental backup at level 1 of the
SYSTEM and tools tablespaces. It only backs up those data blocks changed since
the most recent level 1 or level 0 backup.
9-39
Chapter 9
Making and Updating RMAN Incremental Backups
BACKUP
INCREMENTAL LEVEL 1
TABLESPACE SYSTEM, tools;
The following example makes a cumulative incremental backup at level 1 of the
tablespace users, backing up all blocks changed since the most recent level 0
backup.
BACKUP
INCREMENTAL LEVEL 1 CUMULATIVE
TABLESPACE users;
9.8.3.1 Making Incremental Backups of a VSS Snapshot
You can use the Volume Shadow Copy Service (VSS) with the Oracle VSS writer to
make a shadow copy or snapshot of files in a database.
You must use a third-party backup program other than RMAN to make VSS snapshots
with the Oracle VSS writer. In this case, the fast recovery area automates
management of files that are backed up in a VSS snapshot and deletes them as
needed.
You can use the BACKUP INCREMENTAL LEVEL 1 ... FROM SCN command in RMAN to
create incremental backups in the fast recovery area. Thus, you can use this
command to create an incremental level 1 backup of a VSS shadow copy. RMAN can
apply incremental backups during recovery transparently.
See Also:
Oracle Database Platform Guide for Microsoft Windows to learn how to make
VSS backups with RMAN
9.8.4 Incrementally Updating Backups
By incrementally updating backups, you can avoid the overhead of making full image
copy backups of data files, while also minimizing time required for media recovery of
your database. For example, if you run a daily backup script, then you never have
more than 1 day of redo to apply for media recovery.
To incrementally update data file backups:
1.
Create a full image copy backup of a data file with a specified tag.
2.
At regular intervals (such as daily), make a level 1 differential incremental backup
of the data file and use the same tag as the base data file copy.
3.
Apply the incremental backup to the most recent backup with the same tag.
This technique rolls forward the backup to the time when the level 1 incremental
backup was made. RMAN can restore this incremental forever and apply changes
from the redo log. The result equals restoring a data file backup taken at the SCN of
the most recently applied incremental level 1 backup.
9-40
Chapter 9
Making and Updating RMAN Incremental Backups
Note:
If you run RECOVER COPY daily without specifying an UNTIL TIME, then a
continuously updated image copy cannot satisfy a recovery window of more
than a day. The incrementally updated backup feature is an optimization for
fast media recovery.
9.8.4.1 Incrementally Updating Backups: Basic Example
To create incremental backups for use in an incrementally updated backup strategy,
use the BACKUP ... FOR RECOVER OF COPY WITH TAG form of the BACKUP command. The
command is best understood in a sample script that implements the strategy.
The script in Example 9-15, run regularly, is all that is required to implement a strategy
based on incrementally updated backups.
Example 9-15
Basic Incremental Update Script
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
To understand the script and the strategy, you must understand the effects of these
two commands when no data file copies or incremental backups exist. Note two
important features:
•
The BACKUP command in Example 9-15 does not always create a level 1
incremental backup.
•
The RECOVER command in Example 9-15 causes RMAN to apply any available
incremental level 1 backups with the specified tag to a set of data file copies with
the same tag.
Table 9-2 shows the effect of the script when it is run once per day starting on
Monday.
Table 9-2
Effect of Basic Script When Run Daily
Command Monday
RECOVER
Because no incremental
backup or data file copy
exists, the command
generates a message
(but not an error). That
is, the command has no
effect.
Tuesday
Wednesday
Thursday Onward
A database copy now
exists, but no
incremental level 1
backup exists with
which to recover it.
Thus, the RECOVER
command has no effect.
The level 1 incremental
backup made on
Tuesday is applied to
the database copy,
bringing the copy up to
the checkpoint SCN of
the level 1 incremental
backup.
The level 1 incremental
backup made yesterday
is applied to the
database copy, bringing
the copy up to the
checkpoint SCN of the
level 1 incremental
backup.
9-41
Chapter 9
Making and Updating RMAN Incremental Backups
Table 9-2
(Cont.) Effect of Basic Script When Run Daily
Command Monday
BACKUP
No level 0 image copy
exists, so the command
creates an image copy
of the database and
applies the tag
incr_update. This copy
is needed to begin the
cycle of incremental
updates.
Tuesday
Wednesday
Thursday Onward
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between Monday and
Tuesday.
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between Tuesday and
Wednesday.
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between now and the
most recent backup with
the tag incr_update.
Note: If the script sets
DEVICE TYPE sbt, then
the first run creates the
copy on disk, not on
tape. Subsequent runs
make level 1 backups
on tape.
Note the following additional details about Example 9-15:
•
Each time a data file is added to the database, an image copy of the new data file
is created the next time the script runs. The next run makes the first level 1
incremental for the added data file. On all subsequent runs the new data file is
processed like any other data file.
•
You must use tags to identify the data file copies and incremental backups in this
strategy so that they do not interfere with other backup strategies. If you use
multiple incremental backup strategies, then RMAN cannot unambiguously create
incremental level 1 backups unless you tag level 0 backups.
The incremental level 1 backups to apply to those image copies are selected
based upon the tag of the image copy data files and the available incremental
level 1 backups. The tag is essential in the selection of the incremental level
backups.
•
After the third run of the script, the following files are available for a point-in-time
recovery:
–
An image copy of the database, as of the checkpoint SCN of the preceding run
of the script, 24 hours earlier
–
An incremental backup for the changes after the checkpoint SCN of the
preceding run
–
Archived redo logs including all changes between the checkpoint SCN of the
image copy and the current time
If you must restore and recover your database during the following 24 hours, then
you can restore the data files from the incrementally updated data file copies. You
can then apply changes from the most recent incremental level 1 and the redo
logs to reach the desired SCN. At most, you have 24 hours of redo to apply, which
limits how long point-in-time recovery takes to finish.
9-42
Chapter 9
Making and Updating RMAN Incremental Backups
9.8.4.2 Incrementally Updated Backups: Advanced Example
You can extend the basic script in Example 9-15 to provide fast recoverability to a
window greater than 24 hours. Example 9-16 shows how to maintain a window of 7
days by specifying the beginning time of your window of recoverability in the RECOVER
command.
Example 9-16
Advanced Incremental Update Script
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update'
UNTIL TIME 'SYSDATE - 7';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
Table 9-3 shows the effect of the script when it is run once per day starting on
Monday, January 1.
Table 9-3
Effect of Advanced Script When Run Daily
Command Monday 1/1
Tuesday 1/2 - Monday
1/8
Tuesday 1/9
Wednesday 1/10
Onward
RECOVER
Because no incremental
backup or data file copy
exists, the command
generates a message
(but not an error). That
is, the command has no
effect.
A database copy exists,
but SYSDATE-7 specifies
a time before the base
copy was created. For
example, on
Wednesday SYSDATE-7
specifies the
Wednesday before
Monday 1/1. Thus, the
RECOVER command has
no effect.
SYSDATE-7 now
specifies a date after
the base copy was
created. The database
copy made on Monday
1/1 is updated with the
incremental backup
made on Tuesday 1/2,
bringing the copy up to
the checkpoint SCN of
the level 1 incremental
backup.
The database copy is
updated with the
incremental backup
made 7 days ago,
bringing the copy up to
the checkpoint SCN of
the level 1 incremental
backup.
BACKUP
No level 0 image copy
exists, so the command
creates an image copy
of the database and
applies the tag
incr_update. This copy
is needed to begin the
cycle of incremental
updates.
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between yesterday and
today.
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between Monday 1/8
and Tuesday 1/9.
The command makes
an incremental level 1
backup and assigns it
the tag incr_update.
This backup contains
blocks that changed
between yesterday and
today.
Note: If the script sets
DEVICE TYPE sbt, then
the first run creates the
copy on disk, not on
tape. Subsequent runs
make level 1 backups
on tape.
9-43
Chapter 9
Making and Updating RMAN Incremental Backups
As with the basic script in Example 9-15, you have fast recoverability to any point in
time between the SCN of the data file copies and the present. RMAN can use both
block changes from the incremental backups and individual changes from the redo
logs. Because you have the daily level 1 incremental backups, you never need to
apply more than 1 day of redo.
See Also:
Oracle Database Backup and Recovery Reference to learn about the RECOVER
command
9.8.5 Using Block Change Tracking to Improve Incremental Backup
Performance
The block change tracking feature for incremental backups improves backup
performance by recording changed blocks for each data file.
This section contains the following topics:
•
About Block Change Tracking
•
Enabling and Disabling Block Change Tracking
•
Disabling Block Change Tracking
•
Checking Whether Change Tracking Is Enabled
•
Changing the Location of the Block Change Tracking File
9.8.5.1 About Block Change Tracking
If block change tracking is enabled on a primary or standby database, then RMAN
uses a block change tracking file to identify changed blocks for incremental backups.
By reading this small bitmap file to determine which blocks changed, RMAN avoids
having to scan every block in the data file that it is backing up.
Block change tracking is disabled by default. Nevertheless, the benefits of avoiding full
data file scans during backup are considerable, especially if only a small percentage of
data blocks are changed between backups. If your backup strategy involves
incremental backups, then block change tracking is recommended. Block change
tracking does not change the commands used to perform incremental backups. The
block change tracking file requires no maintenance after initial configuration.
You can only enable block change tracking at a physical standby database if a license
for the Oracle Active Data Guard option is enabled.
9.8.5.1.1 About Space Management in the Block Change Tracking File
Oracle Database automatically manages space in the change tracking file to retain
block change data that covers the eight most recent backups. After the maximum of
eight bitmaps is reached, the oldest bitmap is overwritten by the bitmap that tracks the
current changes.
9-44
Chapter 9
Making and Updating RMAN Incremental Backups
The block change tracking file maintains bitmaps that mark changes in the data files
between backups. The database performs a bitmap switch before each backup.
The first level 0 incremental backup scans the entire data file. Subsequent incremental
backups use the block change tracking file to scan only the blocks that have been
marked as changed since the last backup. An incremental backup can be optimized
only when it is based on a parent backup that was made after the start of the oldest
bitmap in the block change tracking file.
Consider the eight-bitmap limit when developing your incremental backup strategy. For
example, if you make a level 0 database backup followed by seven differential
incremental backups, then the block change tracking file now includes eight bitmaps. If
you then make a cumulative level 1 incremental backup, then RMAN cannot optimize
the backup, because the bitmap corresponding to the parent level 0 backup is
overwritten with the bitmap that tracks the current changes.
9.8.5.1.2 Location of the Block Change Tracking File
By default, the block change tracking file is created as an Oracle managed file in the
destination specified by the DB_CREATE_FILE_DEST initialization parameter. You can also
place the block change tracking file in any location that you choose, by specifying its
name when enabling block change tracking.
One block change tracking file is created for the whole database. Oracle recommends
against using a raw device (that is, a disk without a file system) as a change tracking
file.
Note:
In an Oracle Real Application Clusters (Oracle RAC) environment, the
change tracking file must be located on shared storage accessible from all
nodes in the cluster.
RMAN does not support backup and recovery of the change tracking file. The
database resets the change tracking file when it determines that the change tracking
file is invalid. If you restore and recover the whole database or a subset, then the
database resets the block change tracking file and starts tracking changes again. After
you make a level 0 incremental backup, the next incremental backup can use change
tracking data.
9.8.5.1.3 About the Size of the Block Change Tracking File
The size of the block change tracking file is proportional to the size of the database
and the number of enabled threads of redo.
The size of the block change tracking file can increase and decrease as the database
changes. The size is not related to the frequency of updates to the database.
Typically, the space required for block change tracking for a single instance is
approximately 1/30,000 the size of the data blocks to be tracked. For an Oracle RAC
environment, it is 1/30,000 of the size of the database, times the number of enabled
threads.
The following factors that may cause the file to be larger than this estimate suggests:
9-45
Chapter 9
Making and Updating RMAN Incremental Backups
•
To avoid the overhead of allocating space as your database grows, the block
change tracking file size starts at 10 megabytes. New space is allocated in 10 MB
increments. Thus, for any database up to approximately 300 gigabytes, the file
size is no smaller than 10 MB, for up to approximately 600 gigabytes the file size is
no smaller than 20 megabytes, and so on.
•
For each data file, a minimum of 320 kilobytes of space is allocated in the block
change tracking file, regardless of the size of the data file. Thus, if you have a
large number of relatively small data files, the change tracking file is larger than for
databases with a smaller number of larger data files containing the same data.
9.8.5.2 Enabling and Disabling Block Change Tracking
You can enable block change tracking when the database is either open or mounted.
This section assumes that you intend to create the block change tracking file as an
Oracle managed file in the database area, which is where the database maintains
active database files such as data files, control files, and online redo log files. See
"Overview of Files in the Fast Recovery Area" to learn about the database area and
fast recovery area.
To enable block change tracking:
1.
Start SQL*Plus and connect to a target database with administrator privileges.
2.
Ensure that the DB_CREATE_FILE_DEST initialization parameter is set.
SHOW PARAMETER DB_CREATE_FILE_DEST
If the parameter is not set, and if the database is open, then you can set the
parameter with the following form of the ALTER SYSTEM statement:
ALTER SYSTEM SET
DB_CREATE_FILE_DEST = '/disk1/bct/'
SCOPE=BOTH SID='*';
3.
Enable block change tracking.
Execute the following ALTER DATABASE statement:
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
You can also create the change tracking file in a location that you choose yourself
by using the following form of SQL statement:
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f' REUSE;
The REUSE option tells Oracle Database to overwrite any existing block change
tracking file with the specified name.
9.8.5.3 Disabling Block Change Tracking
When you disable block change tracking, the database removes the block change
tracking file from the operating system.
This section assumes that the block change tracking feature is currently enabled.
9-46
Chapter 9
Making and Updating RMAN Incremental Backups
To disable block change tracking:
1.
Start SQL*Plus and connect to a target database with administrator privileges.
2.
Ensure that the target database is mounted or open.
3.
Disable block change tracking.
Execute the following ALTER DATABASE statement:
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
9.8.5.4 Checking Whether Change Tracking Is Enabled
You can query the V$BLOCK_CHANGE_TRACKING view to determine whether change tracking
is enabled, and if it is, the file name of the block change tracking file.
To determine whether change tracking is enabled:
Enter the following query in SQL*Plus (sample output included):
COL STATUS FORMAT A8
COL FILENAME FORMAT A60
SELECT STATUS, FILENAME
FROM V$BLOCK_CHANGE_TRACKING;
STATUS FILENAME
-------- -----------------------------------------------------------ENABLED /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg
9.8.5.5 Changing the Location of the Block Change Tracking File
To move the change tracking file, use the ALTER DATABASE RENAME FILE statement.
The database must be mounted. The statement updates the control file to refer to the
new location and preserves the contents of the change tracking file. If you cannot shut
down the database, then you can disable and enable block change tracking. In this
case, you lose the contents of the existing block change tracking file.
To change the location of the change tracking file:
1.
Start SQL*Plus and connect to a target database.
2.
If necessary, determine the current name of the change tracking file:
SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;
3.
If possible, shut down the database. For example:
SQL> SHUTDOWN IMMEDIATE
If you shut down the database, then skip to the next step. If you choose not to shut
down the database, then execute the following SQL statements and skip all
remaining steps:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
In this case you lose the contents of the block change tracking file.
9-47
Chapter 9
Making Database Backups for Long-Term Storage
4.
Using host operating system commands, move the block change tracking file to its
new location.
5.
Mount the database and move the change tracking file to a location that has more
space. For example:
ALTER DATABASE RENAME FILE
'/disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg' TO
'/disk2/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg';
This statement changes the location of the change tracking file while preserving its
contents.
6.
Open the database:
SQL> ALTER DATABASE OPEN;
See Also:
Oracle Database SQL Language Reference to learn about the ALTER
DATABASE statement and the ALTER SYSTEM statement
9.9 Making Database Backups for Long-Term Storage
This section explains the basic concepts and tasks involved in making backups for
long-term storage.
This section contains the following topics:
•
Purpose of Archival Backups
•
Basic Concepts of Archival Backups
•
Making an Archival Backup for Long-Term Storage
•
Making a Temporary Archival Backup
9.9.1 Purpose of Archival Backups
You can use BACKUP... KEEP to create a backup that is both all-inclusive and exempt
from the backup retention policy.
The backup is all-inclusive because every file needed to restore and recover the
database is backed up to a single disk or tape location. The KEEP option also specifies
that the backup is exempt from the retention policy either forever or for a specified
period. The general name for a backup created with BACKUP ... KEEP is an archival
backup.
As explained in "About Data Archival", one purpose of a backup and recovery strategy
is to preserve data. You can use BACKUP ... KEEP to retain a database backup for
longer than the time dictated by the retention policy. For example, you can back up the
database on the first day of every year to satisfy a regulatory requirement and store
the media off-site. Years after you make the archival backup, you can restore and
recover it to query the data as it appeared at the time of the backup.
Another purpose of an archival backup is to create a backup that you want to restore
for testing purposes and then delete. For example, you can back up the database,
9-48
Chapter 9
Making Database Backups for Long-Term Storage
restore the database in a test environment, and then discard the archival backup after
the test database is operational. A related purpose is to create a self-contained backup
that you can delete after transferring it to another user or host. For example, another
user might want a copy of the database for reporting or testing.
9.9.2 Basic Concepts of Archival Backups
You can exempt a backup from the retention policy by using the KEEP option with the
BACKUP command.
You can also use the KEEP and NOKEEP options of the CHANGE command to change the
status of an existing backup. Backups with KEEP attributes are valid backups that can
be recovered like any other backups.
You can specify an end date for an archival backup with the KEEP UNTIL TIME clause, or
specify that the backup is kept FOREVER. If you specify UNTIL, then RMAN marks the
backup as obsolete when the UNTIL time has passed, regardless of any configured
retention policy. For example, if you specify KEEP UNTIL TIME '01-JAN-13', then the
backup is obsolete one second after midnight on January 1, 2013. If you specify an
UNTIL TIME of 9:00 p.m, then the backup is obsolete at 9:01 p.m.
When you specify KEEP on the BACKUP command, RMAN generates multiple backup
sets. Note the following characteristics of the BACKUP ... KEEP command:
•
It automatically backs up the data files, control file (even if the control file
autobackup is disabled), and the server parameter file.
•
It automatically generates an archived redo log backup to ensure that the
database backup can be recovered to a consistent state.
•
If the FORMAT, POOL, or TAG parameters are specified, then they are used for all
backups. For this reason, the FORMAT string must allow for the creation of multiple
backup pieces. Specifying the %U substitution variable is the easiest way to meet
this requirement.
•
It supports an optional RESTORE POINT clause that creates a normal restore point,
which is a label for an SCN to which the backup must be recovered to be made
consistent. The SCN is captured just after the data file backups complete. RMAN
resynchronizes restore points with the recovery catalog and maintains the restore
points while the backup exists.
See Also:
•
Listing Restore Points Using the LIST Command for information on how
to display restore points
•
Oracle Database Backup and Recovery Reference for CHANGE syntax
•
Oracle Database Backup and Recovery Reference for BACKUP ... KEEP
syntax
9-49
Chapter 9
Making Database Backups for Long-Term Storage
9.9.3 Making an Archival Backup for Long-Term Storage
Typically, you make an archival backup to tape. Because your data protection backups
are most likely to be on a set of tapes that remain accessible and are recycled, it is
advisable to reserve a set of tapes for the archival backup.
You can write the archival backup to this special set of tapes and then place them in
off-site storage. You can vary the procedure for creating an archival backup by
creating a stored script or shell script that updates dynamically. When you run the
script, you can dynamically set the name of the restore point, backup format, and so
on.
See Also:
•
Using Substitution Variables in Command Files
•
Creating and Executing Dynamic Stored Scripts to learn how to make
archival backups with RMAN command files
9.9.3.1 Making an Archival Backup
Use the BACKUP command with the KEEP option to make archival backups.
This scenario makes a long-term archival backup with a backup tag of QUARTERLY and
assigns it to a special family of Oracle Secure Backup tapes reserved for long-term
storage. Note the following features of this example:
•
The FOREVER keyword indicates that this backup is never eligible for deletion by the
backup retention policy.
•
The BACKUP command creates the restore point named FY06Q4 to match the SCN at
which point this backup is consistent.
To make a long-term archival backup:
1.
Start RMAN and connect to a target database and recovery catalog.
The target database can be open or mounted. A recovery catalog is required for
KEEP FOREVER, but is not required for any other KEEP option.
See Also:
Making Database Connections with RMAN
2.
Run BACKUP ... KEEP to make the backup.
The following example generates a data file and archived log backup and creates
a normal restore point. The specified restore point must not already exist.
The log backup contains just those archived logs needed to restore this backup to
a consistent state. The database performs an online redo log switch to archive the
redo that is in the current online logs and is necessary to make this new backup
9-50
Chapter 9
Making Database Backups for Long-Term Storage
consistent. The control file autobackup has a copy of the restore point, so it can be
referenced as soon as the control file is restored.
RUN
{
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP FOREVER
RESTORE POINT FY06Q4;
}
The following variation keeps the backup for 365 days instead of keeping it
forever. After a year has passed, the backup becomes obsolete regardless of the
backup retention policy settings.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP UNTIL TIME 'SYSDATE+365'
RESTORE POINT FY06Q4;
}
See Also:
Overview of Flashback Database, Restore Points and Guaranteed Restore
Points to learn about restore points
9.9.4 Making a Temporary Archival Backup
One purpose of an archival backup is to create a test database.
The technique for making a test database is essentially the same as the technique
described in "Making an Archival Backup for Long-Term Storage". The difference is
that you intend to delete the backup soon after creating it.
You can specify the temporary status of the backup with the BACKUP ... KEEP UNTIL
parameter. Assume that you want to make a backup and then restore it to a new host
the same day. In this case, you can specify KEEP UNTIL TIME SYSDATE+1 to indicate that
RMAN overrides the retention policy for this backup for only one day. After one day,
the backup becomes obsolete, regardless of any configured backup retention policy.
The command in Example 9-17 makes an archival backup on a temporary disk with
the tag TESTDB. The example creates a normal restore point, which is a label for the
time to which the backup is recovered. RMAN only backs up the archived redo logs if
the database is open during the backup. Archived logs are not needed for offline
backups and so are not backed up.
Example 9-17
Creating a Temporary Archival Backup
BACKUP DATABASE
FORMAT '/disk1/oraclebck/%U'
9-51
Chapter 9
Backing Up RMAN Backups
TAG TESTDB
KEEP UNTIL TIME 'SYSDATE+1'
RESTORE POINT TESTDB06;
The recommended technique for restoring an archival backup is to use the DUPLICATE
command.
9.10 Backing Up RMAN Backups
This section explains how to back up backup sets and image copies and contains the
following topics:
•
About Backups of RMAN Backups
•
Backing Up Backup Sets with RMAN
•
Backing Up Image Copy Backups with RMAN
9.10.1 About Backups of RMAN Backups
You can use the BACKUP BACKUPSET command to back up backup sets produced by
other backup jobs. You can also use BACKUP RECOVERY AREA to back up recovery files
created in the current and all previous fast recovery area destinations.
Recovery files are full and incremental backup sets, control file autobackups, data file
copies, and archived redo logs. SBT and disk backups are supported for BACKUP
RECOVERY AREA. For disk backups of the recovery files, you must use the TO DESTINATION
option.
The preceding commands are especially useful in the following scenarios:
•
Ensuring that all backups exist both on disk and on tape.
•
Moving backups from disk to tape and then freeing space on disk. This task is
especially important when the database uses a fast recovery area so that the
space can be reused as needed.
You can also use the BACKUP COPY OF command to back up image copies of data files,
control files, and archived redo logs. The output of this command can be either backup
sets or image copies, so you can generate backup sets from image copies. This form
of backup is used to back up a database backup created as image copies on disk to
tape.
Note:
In a multitenant environment, you cannot back up backup sets and image
copies of PDBs that have been dropped. RMAN skips backing up these
backups.
9.10.1.1 About Multiple Copies of RMAN Backup Sets
The BACKUP BACKUPSET command creates additional copies of backup pieces in a
backup set, but does not create a new backup set.
9-52
Chapter 9
Backing Up RMAN Backups
Thus, BACKUP BACKUPSET is similar to using the DUPLEX or MAXCOPIES option of BACKUP (see
"Duplexing Backup Sets"). The extra copy of a backup set created by BACKUP BACKUPSET
is not a new backup set, just as copies of a backup set produced by other forms of the
BACKUP command are not separate backup sets.
9.10.1.2 Viewing the Effect of a Backup Retention Policy on Backups of
Backups
For a backup retention policy based on redundancy, a backup set is counted as one
instance of a backup. This statement is true even if there are multiple copies of the
backup pieces that form the backup set, such as when a backup set has been backed
up from disk to tape.
For a recovery window retention policy, either all of the copies of a backup set are
obsolete, or none of them are. This point is easiest to grasp when viewing the output
of the LIST and REPORT commands.
To view the effect of a backup retention policy on backups of backups:
1.
Back up a data file.
The following example backs up data file 5:
BACKUP AS BACKUPSET DATAFILE 5;
2.
Run the LIST command for the data file backup from Step 1.
For example, run the following command (sample output included).
LIST BACKUP OF DATAFILE 5 SUMMARY;
List of Backups
===============
Key
TY LV S
------- -- -- 18
B F A
TAG20070804T160
3.
Device Type Completion Time #Pieces #Copies Compressed Tag
----------- --------------- ------- ------- ---------- --DISK
04-AUG-13
1
1
NO
134
Use the backup set key from the previous step to back up the backup set.
For example, enter the following command:
BACKUP BACKUPSET 18;
4.
Run the same LIST command that you ran in Step 2.
For example, run the following command (sample output included).
LIST BACKUP OF DATAFILE 5 SUMMARY;
List of Backups
===============
Key
TY LV S
------- -- -- 18
B F A
TAG20070804T160
Device Type Completion Time #Pieces #Copies Compressed Tag
----------- --------------- ------- ------- ---------- --DISK
04-AUG-13
1
2
NO
134
Only one backup set is shown in this output, but there are now two copies of it.
5.
Generate a report to see the effect of these copies under a redundancy-based
backup retention policy.
For example, issue the following command:
9-53
Chapter 9
Backing Up RMAN Backups
REPORT OBSOLETE REDUNDANCY 1;
No copy is reported as obsolete because both copies of the backup set have the
same values for set_stamp and set_count.
6.
Generate a report to see the effect of these copies under a recovery windowbased backup retention policy.
For example, issue the following command:
REPORT OBSOLETE RECOVERY WINDOW OF 1 DAYS;
No copy of the backup set is reported as obsolete or based on the
CHECKPOINT_CHANGE# of this backup set, with the current time and the availability of
other backups.
See Also:
•
Configuring a Redundancy-Based Retention Policy
•
Reporting on RMAN Operations to learn how to use the LIST and
REPORT commands
9.10.2 Backing Up Backup Sets with RMAN
Use the BACKUP BACKUPSET command to copy backup sets from disk to tape.
The procedure in this section assumes that you have configured an SBT device as
your default device.
To back up backup sets from disk to tape:
1.
If you are backing up a subset of available backup sets, then execute the LIST
BACKUPSET command to obtain their primary keys.
The following example lists the backup sets in summary form:
RMAN> LIST BACKUPSET SUMMARY;
List of Backups
===============
Key TY LV S Device Type
--- -- -- - ----------1 B F A DISK
2 B F A DISK
3 B F A DISK
Completion Time
--------------28-MAY-13
29-MAY-13
30-MAY-13
#Pieces
------1
1
1
#Copies
------1
1
1
Comp
---NO
NO
NO
Tag
--TAG20070528T132432
TAG20070529T132433
TAG20070530T132434
The following example lists details about backup set 3:
RMAN> LIST BACKUPSET 3;
List of Backup Sets
===================
BS Key Type LV Size
Device Type
------- ---- -- ---------- ----------3
Full
8.33M
DISK
BP Key: 3 Status: AVAILABLE
Elapsed Time Completion Time
------------ --------------00:00:01
30-MAY-13
Compressed: NO Tag: TAG20070530T132434
9-54
Chapter 9
Backing Up RMAN Backups
Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
Control File Included: Ckp SCN: 397221
Ckp time: 30-MAY-13
SPFILE Included: Modification time: 30-MAY-13
SPFILE db_unique_name: PROD
2.
Execute the BACKUP BACKUPSET command.
The following example backs up all disk backup sets to tape and then deletes the
input disk backups:
BACKUP BACKUPSET ALL
DELETE INPUT;
The following example backs up only the backup sets with the primary key 1 and 2
to tape and then deletes the input disk backups:
BACKUP BACKUPSET 1,2
DELETE INPUT;
3.
Optionally, execute the LIST command to see a listing of backup sets and pieces.
The output lists all copies, including backup piece copies created by BACKUP
BACKUPSET .
9.10.3 Backing Up Image Copy Backups with RMAN
Use the BACKUP command to back up image copies to tape.
This section assumes that you have configured an SBT device as your default device.
When you back up image copies that have multiple copies of the data files, specifying
tags for the backups makes it easier to identify the input image copy. All image copies
of data files have tags. The tag of an image copy is inherited by default when the
image copy is backed up as a new image copy.
To back up image copies from disk to tape:
1.
Issue the BACKUP ... COPY OF or BACKUP DATAFILECOPY command.
The following example backs up data file copies that have the tag DBCopy:
BACKUP DATAFILECOPY FROM TAG DBCopy;
The following example backs up the latest image copies of a database to tape,
assigns the tag QUARTERLY_BACKUP, and deletes the input disk backups:
BACKUP DEVICE TYPE sbt
TAG "quarterly_backup"
COPY OF DATABASE
DELETE INPUT;
2.
Optionally, issue the LIST command to see a listing of backup sets. The output lists
all copies, including backup piece copies created by the BACKUP command with the
BACKUPSET clause.
9-55
10
Backing Up the Database: Advanced
Topics
This chapter explains advanced RMAN backup procedures. This chapter contains the
following topics:
•
Limiting the Size of RMAN Backup Sets
•
Using Backup Optimization to Skip Files
•
Skipping Offline, Read-Only, and Inaccessible Files
•
Duplexing Backup Sets
•
Making Split Mirror Backups with RMAN
•
Encrypting RMAN Backups
•
Restarting RMAN Backups
•
Managing Backup Windows
See Also:
Backing Up the Database for basic backup procedures
10.1 Limiting the Size of RMAN Backup Sets
You can use the CONFIGURE command to create persistent settings that govern backup
set size.
This control is helpful when backing up very large files. If you do not have a backup set
size persistently configured, then you can also use the BACKUP... MAXSETSIZE command
to limit the size of backup sets.
You can use the CONFIGURE command, but not the BACKUP command, to set a limit for the
size of individual backup pieces. This control is especially useful when you use a
media manager that has restrictions on the sizes of files, or when you must back up
very large files.
See Also:
•
Configuring the Maximum Size of Backup Sets
•
Configuring the Maximum Size of Backup Pieces
This section contains the following topics:
10-1
Chapter 10
Limiting the Size of RMAN Backup Sets
•
About Backup Set Size
•
Limiting the Size of Backup Sets with BACKUP ... MAXSETSIZE
•
Dividing the Backup of a Large Data File into Sections
10.1.1 About Backup Set Size
The MAXSETSIZE parameter of the BACKUP command specifies a maximum size for a
backup set in units of bytes (default), kilobytes, megabytes, or gigabytes.
For example, to limit a backup set to 305 MB, specify MAXSETSIZE 305M. RMAN attempts
to limit all backup sets to this size.
You can use BACKUP ... MAXSETSIZE to limit the size of backup sets so that the
database is divided among multiple backup sets. If the backup fails part way through,
then you can use the restartable backup feature to back up only those files that were
not backed up during the previous attempt.
In some cases the MAXSETSIZE value may be too small to contain the largest file that
you are backing up. When determining whether MAXSETSIZE is too small, RMAN uses
the size of the original data file rather than the file size after compression. RMAN
displays an error stack such as the following:
RMAN-00571:
RMAN-00569:
RMAN-00571:
RMAN-03002:
RMAN-06182:
===========================================================
=============== ERROR MESSAGE STACK FOLLOWS ===============
===========================================================
failure of backup command at 11/03/13 14:40:33
archive log larger than MAXSETSIZE: thread 1 seq 1
/oracle/oradata/trgt/arch/archive1_1.dbf
See Also:
•
•
Restarting RMAN Backups for information on how to restart RMAN
backups
Oracle Database Backup and Recovery Reference to learn about the
CONFIGURE MAXSETSIZE command
10.1.2 Limiting the Size of Backup Sets with BACKUP ...
MAXSETSIZE
Backup piece size is an issue in those situations where it exceeds the maximum file
size of the file system or media management software. Use the MAXSETSIZE parameter
of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup
pieces.
To limit the size of backup sets:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
10-2
Chapter 10
Limiting the Size of RMAN Backup Sets
See Also:
Making Database Connections with RMAN
2.
Execute the BACKUP command with the MAXSETSIZE parameter.
The following example backs up archived logs to tape, limiting the size of each
backup set to 100 MB:
BACKUP DEVICE TYPE sbt
MAXSETSIZE 100M
ARCHIVELOG ALL;
10.1.3 Dividing the Backup of a Large Data File into Sections
If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN creates
a backup set in which each backup piece contains the blocks from one file section.
A file section is a contiguous range of blocks in a file. This type of backup is called a
multisection backup.
Note:
You cannot specify SECTION SIZE with MAXPIECESIZE.
The purpose of multisection backups is to enable RMAN channels to back up a single
large file in parallel. RMAN divides the work among multiple channels, with each
channel backing up one file section in a file. Backing up a file in separate sections can
improve the performance of backups of large data files.
If a multisection backup completes successfully, then no backup set generated during
the backup contains a partial data file. If a multisection backup is unsuccessful, then
the RMAN metadata can contain a record for a partial backup set. RMAN does not
consider partial backups for restore and recovery. You must use the DELETE command
to delete the partial backup set.
If you specify a section size that is larger than the size of the file, then RMAN does not
use multisection backup for the file. If you specify a small section size that would
produce more than 256 sections, then RMAN increases the section size to a value that
results in exactly 256 sections.
To make a multisection backup:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
If necessary, configure channel parallelism so that RMAN can make the backup
parallel.
3.
Execute BACKUP with the SECTION SIZE parameter.
For example, suppose that the users tablespace contains a single data file of 900
MB. Also assume that three SBT channels are configured, with the parallelism
setting for the SBT device set to 3. You can break up the data file in this
tablespace into file sections as shown in the following example:
10-3
Chapter 10
Using Backup Optimization to Skip Files
BACKUP
SECTION SIZE 300M
TABLESPACE users;
In this example, each of the three SBT channels backs up a 300 MB file section of
the users data file.
See Also:
Make Parallel the Validation of a Data File to learn how to validate sections
of a large data file
10.2 Using Backup Optimization to Skip Files
You run the CONFIGURE BACKUP OPTIMIZATION command to enable backup optimization.
When certain criteria are met, RMAN skips backups of files that are identical to files
that are already backed up.
For the following scenarios, assume that you configure backup optimization and a
retention policy as shown in the following example.
Example 10-1
Configuring Backup Optimization
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
With RMAN configured as shown in Example 10-1, you run the following command
every night to back up the database to tape:
BACKUP DATABASE;
Because backup optimization is configured, RMAN skips backups of offline and readonly data files only if the most recent backups were made on or after the earliest point
in the recovery window. RMAN does not skip backups when the most recent backups
are older than the window. For example, optimization ensures you do not end up with
a new backup of a read-only data file every night, so long as one backup set
containing this file exists within the recovery window.
See Also:
•
Backup Optimization and the CONFIGURE command
•
About Backup Optimization for SBT Backups with Recovery Window
Retention Policy for a scenario involving backup optimization and
recovery windows
•
Oracle Database Backup and Recovery Reference for a detailed
description of criteria used by CONFIGURE BACKUP OPTIMIZATION to
determine whether a file is identical and can potentially be skipped
10-4
Chapter 10
Using Backup Optimization to Skip Files
10.2.1 Optimizing a Daily Archived Log Backup to a Single Tape:
Scenario
Assume that you want to back up all the archived logs every night, but you do not want
to have multiple copies of each log sequence number. With RMAN configured as
shown in Example 10-1, you run the following command in a script nightly at 1 a.m.:
BACKUP DEVICE TYPE sbt
ARCHIVELOG ALL;
RMAN skips all logs except those produced in the last 24 hours. In this way, you keep
only one copy of each archived log on tape.
10.2.2 Optimizing a Daily Archived Log Backup to Multiple Media
Families: Scenario
In Oracle Secure Backup, a media family is a named group of volumes with a set of
shared, user-defined attributes. In this scenario, you back up logs that are not on tape
to one media family, then back up the same logs to a second media family. Finally,
you delete old logs.
With RMAN configured as shown in Example 10-2, run the following script at the same
time every night to back up the logs generated during the previous day to two separate
media families.
Example 10-2
Backing Up Archived Redo Logs to Multiple Media Families
# The following command backs up just the logs that are not on tape. The
# first copies are saved to the tapes from the media family "log_family1".
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=log_family1)';
BACKUP ARCHIVELOG ALL;
}
# Make one more copy of the archived logs and save them to tapes from a
# different media family
RUN
{
ALLOCATE CHANNEL c2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=log_family2)';
BACKUP ARCHIVELOG
NOT BACKED UP 2 TIMES;
}
If your goal is to delete logs from disk that have been backed up two times to SBT,
then the simplest way to achieve the goal is with an archived redo log deletion policy.
The following one-time configuration specifies that archived redo logs are eligible for
deletion from disk if two archived log backups exist on tape:
CONFIGURE ARCHIVELOG DELETION POLICY
TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;
After running the script in Example 10-2, you can delete unneeded logs by executing
DELETE ARCHIVELOG ALL.
10-5
Chapter 10
Using Backup Optimization to Skip Files
10.2.3 Creating a Weekly Secondary Backup of Archived Logs:
Example
Assume a more sophisticated scenario in which your goal is to back up the archived
logs to tape every day. You are worried about tape failure, however, so you want to
ensure that you have more than one copy of each log sequence number on a separate
tape before you perform your weekly deletion of logs from disk. This scenario assumes
that the database is not using a fast recovery area.
First, perform a one-time configuration as follows:
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
BACKUP OPTIMIZATION ON;
DEVICE TYPE sbt PARALLELISM 1;
default DEVICE TYPE TO sbt;
CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy);
Because you have optimization enabled, you can run the following command every
evening to back up all archived logs to the first_copy media family that have not
already been backed up:
BACKUP ARCHIVELOG ALL TAG first_copy;
Every Friday evening you create an additional backup of all archived logs in a different
media family. After the backup, you want to delete all archived logs that have at least
two copies on tape. So you run the following script:
RUN
{
# manually allocate a channel, to specify that the backup run by this
# channel goes to both media families "first_copy" and "second_copy"
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=second_copy)';
ALLOCATE CHANNEL c2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy)';
BACKUP
CHANNEL c1
ARCHIVELOG
UNTIL TIME 'SYSDATE'
NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
TAG SECOND_COPY;
BACKUP
CHANNEL c2
ARCHIVELOG
UNTIL TIME 'SYSDATE'
NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
TAG FIRST_COPY;
}
# now delete from disk all logs that have been backed up to tape at least twice
DELETE
ARCHIVELOG ALL
BACKED UP 2 TIMES TO DEVICE TYPE sbt;
The following table explains the effects of the daily and weekly backup scripts.
10-6
Chapter 10
Skipping Offline, Read-Only, and Inaccessible Files
Table 10-1
Effects of Daily and Weekly Scripts
Script
Tape Contents After Script
Disk Contents After Script
Daily
Archived logs that have not yet been
backed up are now in media family
first_copy.
All archived logs created since the last
DELETE command are still on disk.
Weekly
Archived logs that have fewer than two
backups on tape are now in media
families first_copy and second_copy.
All archived logs that have been backed
up at least twice to tape are deleted.
After the weekly backup, you can send the tape from the media family second_copy to
offsite storage. Use this tape backup only if the primary tape from pool first_copy is
damaged. Because the secondary tape is offsite, you do not want RMAN to use it for
recovery, so you can mark the backup as unavailable:
CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;
See Also:
•
•
Maintaining RMAN Backups and Repository Records to learn how to
change the status of and delete backups
Oracle Database Backup and Recovery Reference to learn about the
CHANGE and DELETE commands
10.3 Skipping Offline, Read-Only, and Inaccessible Files
By default, the BACKUP command terminates when it cannot access a data file.
You can specify parameters to prevent termination, as listed in Table 10-2.
Table 10-2
BACKUP ... SKIP Options
If you specify...
Then RMAN skips...
SKIP INACCESSIBLE
Data files that RMAN cannot read.
SKIP OFFLINE
Offline data files. Some offline data files can still be read
because they exist on disk. Others have been deleted or
moved and so cannot be read, making them inaccessible.
SKIP READONLY
Data files in read-only tablespaces.
The following example uses an automatic channel to back up the database, and skips
all data files that might cause the backup job to terminate.
Example 10-3
BACKUP
SKIP
SKIP
SKIP
Skipping Files During an RMAN Backup
DATABASE
INACCESSIBLE
READONLY
OFFLINE;
10-7
Chapter 10
Duplexing Backup Sets
10.4 Duplexing Backup Sets
RMAN can make up to four copies of a backup set simultaneously, each an exact
duplicate of the others.
A copy of a duplexed backup set is a copy of each backup piece in the backup set,
with each copy getting a unique copy number (for example, 0tcm8u2s_1_1 and
0tcm8u2s_1_2). It is not possible to duplex backup sets to the fast recovery area.
You can use BACKUP ... COPIES or CONFIGURE ... BACKUP COPIES to duplex backup sets.
RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape
and disk simultaneously. 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 writes each copy to a separate medium (for example, a
separate tape). When backing up to tape, ensure that the number of copies does not
exceed the number of available tape devices.
Duplexing applies only to backup sets, not image copies. It is an error to specify the
BACKUP... COPIES when creating image copy backups, and the CONFIGURE... BACKUP
COPIES setting is ignored for image copy backups.
See Also:
About Multiple Copies of RMAN Backups for a conceptual overview of RMAN
backup copies
10.4.1 Duplexing Backup Sets with CONFIGURE BACKUP COPIES
The CONFIGURE...BACKUP COPIES command specifies the number of identical backup
sets to create on the specified device type.
This setting applies to all backup sets except control file autobackups (because the
autobackup of a control file always produces one copy) and backup sets when backed
up with the BACKUP BACKUPSET command.
To duplex a backup with CONFIGURE ... BACKUP COPIES:
1.
Configure the number of copies on the desired device type for data files and
archived redo logs on the desired device types.
By default, CONFIGURE...BACKUP COPIES is set to 1 for each device type. The
following example configures duplexing for data files and archived logs on tape
and also duplexing for data files (but not archived redo logs) on disk:
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
CONFIGURE
2.
DEVICE TYPE sbt PARALLELISM 1;
DEFAULT DEVICE TYPE TO sbt;
CHANNEL DEVICE TYPE DISK FORMAT '/disk1/%U', '/disk2/%U';
DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
Execute the BACKUP command.
10-8
Chapter 10
Duplexing Backup Sets
The following command backs up the database and archived logs to tape, making
two copies of each data file and archived log:
BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
Because of the configured formats for the disk channel, the following command
backs up the database to disk, placing one copy of the backup sets produced in
the /disk1 directory and the other in the /disk2 directory:
BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE;
If the FORMAT clause were not configured on CONFIGURE CHANNNEL, then you specify
FORMAT on the BACKUP command itself. For example, you issue the following
command:
BACKUP AS BACKUPSET DATABASE
FORMAT '/disk1/%U',
'/disk2/%U';
3.
Issue a LIST BACKUP command to see a listing of backup sets and pieces.
For example, enter the following command:
LIST BACKUP SUMMARY;
The #Copies column shows the number of backup sets, which may have been
produced by duplexing or by multiple backup commands.
See Also:
•
•
Configuring Backup Duplexing
Configuring Backup Duplexing to learn about the CONFIGURE BACKUP
COPIES command
•
About Configuring the Environment for RMAN Backups to learn about
basic backup configuration option
10.4.2 Duplexing Backup Sets with BACKUP ... COPIES
The COPIES option of the BACKUP command overrides every other COPIES or DUPLEX
setting to control duplexing of backup sets.
To duplex a backup with BACKUP ... COPIES:
1.
Specify the number of identical copies with the COPIES option of the BACKUP
command. For example, run the following to make three copies of each backup set
in the default DISK location:
BACKUP AS BACKUPSET DEVICE TYPE DISK
COPIES 3
INCREMENTAL LEVEL 0
DATABASE;
Because you specified COPIES in the BACKUP command, RMAN makes three backup
sets of each data file regardless of the CONFIGURE DATAFILE COPIES setting.
10-9
Chapter 10
Making Split Mirror Backups with RMAN
2.
Issue a LIST BACKUP command to see a listing of backup sets and pieces (the
#Copies column shows the number of copies, which may have been produced
through duplexing or through multiple invocations of the BACKUP command). For
example, enter:
LIST BACKUP SUMMARY;
10.5 Making Split Mirror Backups with RMAN
Many sites keep a backup of the database stored on disk in case a media failure
occurs on the primary database or an incorrect user action requires point-in-time
recovery. A data file backup on disk simplifies the restore step of recovery, making
recovery much quicker and more reliable.
Caution:
Never make backups, split mirror or otherwise, of online redo logs. Restoring
online redo log backups can create two archived logs with the same
sequence number but different contents. Also, it is best to use the BACKUP
CONTROLFILE command rather than a split mirror to make control file backups.
One way of creating a data file backup on disk is to use disk mirroring. For example,
the operating system can maintain three identical copies of each file in the database.
In this configuration, you can split off a mirrored copy of the database to use as a
backup.
RMAN does not automate the splitting of mirrors, but can make use of split mirrors in
backup and recovery. For example, RMAN can treat a split mirror of a data file as a
data file copy, and can also back up this copy to disk or tape. The procedure in this
section explains how to make a split mirror backup with the ALTER SYSTEM SUSPEND/
RESUME functionality.
Some mirroring technology does not require Oracle Database to suspend all I/O
before a mirror can be separated and used as a backup. Refer to your storage
manager, volume manager, or file system documentation for information about
whether you must suspend I/O from the database instance.
To make a split mirror backup of a tablespace by using SUSPEND/RESUME:
1.
Start RMAN and then place the tablespaces to back up into backup mode with the
ALTER TABLESPACE ... BEGIN BACKUP statement. (To place all tablespaces in backup
mode, you can the ALTER DATABASE BEGIN BACKUP instead.)
For example, to place tablespace users in backup mode, you connect RMAN to a
target database and run the following SQL command:
ALTER TABLESPACE users BEGIN BACKUP;
2.
Suspend I/O if your mirroring software or hardware requires it. For example, enter
the following command in RMAN:
ALTER SYSTEM SUSPEND;
3.
Split the mirrors for the underlying data files contained in these tablespaces.
10-10
Chapter 10
Encrypting RMAN Backups
4.
Take the database out of the suspended state. For example, enter the following
command in RMAN:
ALTER SYSTEM RESUME;
5.
Take the tablespaces out of backup mode. For example, enter:
ALTER TABLESPACE users END BACKUP;
You can also use ALTER DATABASE END BACKUP to take all tablespaces out of backup
mode.
6.
Catalog the user-managed mirror copies as data file copies with the CATALOG
command. For example, enter:
CATALOG DATAFILECOPY '/dk2/oradata/trgt/users01.dbf'; # catalog split mirror
7.
Back up the data file copies. For example, run the BACKUP DATAFILECOPY command
at the prompt:
BACKUP DATAFILECOPY '/dk2/oradata/trgt/users01.dbf';
8.
When you are ready to resilver a split mirror, first use the CHANGE ... UNCATALOG
command to uncatalog the data file copies you cataloged in Step 6. For example,
enter:
CHANGE DATAFILECOPY '/dk2/oradata/trgt/users01.dbf' UNCATALOG;
9.
Resilver the split mirror for the affected data files.
See Also:
•
Making User-Managed Backups in SUSPEND Mode
•
Oracle Database Administrator’s Guide for more information about
the SUSPEND/RESUME feature
•
Oracle Database SQL Language Reference for the ALTER SYSTEM
SUSPEND syntax
10.6 Encrypting RMAN Backups
You can protect RMAN backup sets with backup encryption. Encrypted backups
cannot be read if they are obtained by unauthorized users.
The RMAN backup encryption feature requires the Enterprise Edition of the database.
This section contains the following topics:
•
About RMAN Backup Encryption Settings
•
Making Transparent-Mode Encrypted Backups
•
Making Password-Mode Encrypted Backups
•
Making Dual-Mode Encrypted Backups
10.6.1 About RMAN Backup Encryption Settings
Backup encryption is performed based on the specified encryption settings.
10-11
Chapter 10
Encrypting RMAN Backups
Encryption can be set with the following commands:
•
CONFIGURE ENCRYPTION
You can use this command to persistently configure transparent encryption. You
cannot persistently configure dual mode or password mode encryption.
•
SET ENCRYPTION
You can use this command to configure dual mode or password mode encryption
at the RMAN session level.
Note:
Keystore-based encryption is more secure than password-based encryption
because no passwords are involved. Use password-based encryption only
when absolutely necessary because your backups must be transportable.
The database uses a new encryption key for every encrypted backup. The backup
encryption key is then encrypted with either the password, the database master key, or
both, depending on the chosen encryption mode. Individual backup encryption keys or
passwords are never stored in clear text.
A single restore operation can process backups encrypted in different modes. For
each backup piece that it restores, RMAN checks whether it is encrypted.
Transparently encrypted backups need no intervention if the Oracle keystore is open
and available.
If password encryption is detected, then RMAN searches for a matching key in the list
of passwords entered in the SET DECRYPTION command. If RMAN finds a usable key,
then the restore operation proceeds. Otherwise, RMAN searches for a key in the
Oracle keystore. If RMAN finds a usable key, then the restore operation proceeds;
otherwise, RMAN signals an error that the backup piece cannot be decrypted.
Note:
If RMAN restores a set of backups created with different passwords, then all
required passwords must be included with SET DECRYPTION .
RMAN encryption is a CPU-intensive operation and can affect backup performance.
The actual amount of CPU utilization during encryption depends on whether both input
and output devices for disk and SBT produce and consume data faster than the CPU
can encrypt it. Here are a few guidelines for managing and trying to maximize CPU
performance:
•
Because encrypted backups consume more CPU resources than unencrypted
backups, you can improve performance of encrypted backups to disk by using
more RMAN channels. A general rule is to use the same number of channels as
the number of CPU cores in your system. For example, use two channels for a
dual-core processor.
•
If both the disk subsystem and SBT-subsystem are fast, you can expect very high
CPU utilization. You may want to consider slowing the rate of the backup by
10-12
Chapter 10
Encrypting RMAN Backups
setting the RMAN READRATE parameter. For example, you can set an upper limit for
block reads so that RMAN does not consume excessive disk bandwidth and
thereby degrade online performance.
See Also:
•
Performing Complete Database Recovery to learn how to restore
password-encrypted backups
•
Determining the Encryption Status of Backup Pieces
•
Oracle Database Backup and Recovery Reference to learn about the
ENCRYPTION and DECRYPTION options of the SET command
10.6.2 Making Transparent-Mode Encrypted Backups
If you have configured transparent encryption with the CONFIGURE command as
explained in "Configuring RMAN Backup Encryption Modes", then no additional
commands are required to create encrypted backups. Make RMAN backups as
normal.
10.6.3 Making Password-Mode Encrypted Backups
You can set an encryption password in an RMAN session by executing the SET
ENCRYPTION BY PASSWORD command. If transparent encryption is configured, then specify
the ONLY keyword to indicate that the backups are protected with a password and not
with the configured transparent encryption.
Note:
Create a password that is secure. See Oracle Database Security Guide for
more information.
To make password-mode encrypted backups:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute the SET ENCRYPTION ON IDENTIFIED BY password ONLY command.
The following example sets the encryption password for all tablespaces (where
password is a placeholder for the actual password that you enter) in the backup
and specifies ONLY to indicate that the encryption is password-only:
SET ENCRYPTION IDENTIFIED BY password ONLY ON FOR ALL TABLESPACES;
3.
Back up the database.
For example, enter the following command:
BACKUP DATABASE PLUS ARCHIVELOG;
10-13
Chapter 10
Restarting RMAN Backups
10.6.4 Making Dual-Mode Encrypted Backups
Use the SET ENCRYPTION BY PASSWORD command at the RMAN prompt to make
password-protected backups. If transparent encryption is configured, then omit the
ONLY keyword to indicate that the backups are protected with both a password and the
configured transparent encryption.
Note:
Create a password that is secure. See Oracle Database Security Guide for
more information.
To make dual-mode encrypted backups:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute the SET ENCRYPTION BY PASSWORD command, making sure to omit the ONLY
keyword.
The following example sets the encryption password for all tablespaces (where
password is a placeholder for the actual password that you enter) in the backup
and omits ONLY to indicate dual-mode encryption:
SET ENCRYPTION IDENTIFIED BY password ON FOR ALL TABLESPACES;
3.
Back up the database.
For example, enter the following command:
BACKUP DATABASE PLUS ARCHIVELOG;
10.7 Restarting RMAN Backups
With the restartable backup feature, RMAN backs up only those files that were not
backed up after a specified date.
This section contains the following topics:
•
About Restartable Backups
•
Restarting a Backup After It Partially Completes
10.7.1 About Restartable Backups
The minimum unit of restartability is a data file. However, if a backup set contains one
backup piece, and if this piece contains blocks from multiple data files, then the unit of
restartability is the backup piece. The unit of restartability for image copies is a data
file.
The benefit of restartable backups is that if the backup generates multiple backup sets,
then the backup sets that completed successfully do not have to be rerun. However, if
the entire database is written into one backup set, and if the backup fails halfway
through, then the entire backup has to be restarted.
10-14
Chapter 10
Restarting RMAN Backups
Any I/O errors that RMAN encounters when reading files or writing to the backup
pieces or image copies cause RMAN to terminate the backup job in progress. For
example, if RMAN tries to back up a data file but the data file is not on disk, then
RMAN terminates the backup. If multiple channels are being used or redundant copies
of backups are being created, however, then RMAN may be able to continue the
backup without user intervention.
RMAN can back up only those files that have not been backed up since a specified
date. Use this feature after a backup fails to back up the parts of the database missed
by the failed backup.
You can restart a backup by specifying the SINCE TIME clause on the BACKUP command.
If the SINCE TIME is later than the completion time, then RMAN backs up the file. If you
use BACKUP DATABASE NOT BACKED UP without the SINCE TIME parameter, then RMAN only
backs up files that have never been backed up.
See Also:
Oracle Database Backup and Recovery Reference for BACKUP ... NOT BACKED
UP syntax
10.7.2 Restarting a Backup After It Partially Completes
Use the SINCE TIME parameter of the BACKUP command to specify a date after which a
new backup is required.
If the SINCE TIME is later than the completion time, then RMAN backs up the file. If you
use BACKUP DATABASE NOT BACKED UP without the SINCE TIME parameter, then RMAN only
backs up files that have never been backed up.
To only back up files that were not backed up after a specified date:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute the BACKUP ... NOT BACKED UP SINCE TIME command.
Specify a valid date in the SINCE TIME parameter. The following example uses the
default configured channel to back up all database files and archived redo logs
that have not been backed up in the last two weeks:
BACKUP
NOT BACKED UP SINCE TIME 'SYSDATE-14'
DATABASE PLUS ARCHIVELOG;
See Also:
Oracle Database Backup and Recovery Reference for an example of how to
use the BACKUP command to restart a backup that did not complete
10-15
Chapter 10
Managing Backup Windows
10.8 Managing Backup Windows
This section explains how to use backup windows to set limits for the time span in
which a backup job can complete.
This section contains the following topics:
•
About Backup Windows
•
Specifying a Backup Duration
•
Permitting Partial Backups in a Backup Window
•
Minimizing Backup Load and Duration
10.8.1 About Backup Windows
A backup window is a period of time during which a backup must complete. For
example, you may want to restrict your database backups to a window of time when
user activity on your system is low, such as between 2:00 a.m. and 6:00 a.m.
RMAN backs up the least recently backed up files first. By default, RMAN backs up the
files at the maximum possible speed. Specifying a window does not mean that RMAN
backs up data faster than normal to ensure that the backup completes before the
window ends.
By default, if the backup is not complete within the DURATION time, then RMAN
interrupts the backup and reports an error. If the BACKUP command is in a RUN
command, then the RUN command terminates. Any completed backup sets are retained
and can be used in restore operations, even if the entire backup is not complete. Thus,
if you retry a job that was interrupted when the available duration expired, each
successive attempt covers more of the files needing backup. Any incomplete backup
sets are discarded.
10.8.2 Specifying a Backup Duration
Use the DURATION parameter of the BACKUP command to specify how long a given
backup job is allowed to run.
To specify a backup duration:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute the BACKUP DURATION command.
For example, run the following command at 2:00 a.m. to specify that the backup
runs until 6:00 a.m.:
BACKUP
DURATION 4:00
TABLESPACE users;
10-16
Chapter 10
Managing Backup Windows
See Also:
Oracle Database Backup and Recovery Reference for the syntax of the
BACKUP command
10.8.3 Permitting Partial Backups in a Backup Window
When you specify PARTIAL, RMAN does not report an error when a backup is
interrupted because of the end of the backup window. Instead, RMAN displays a
message showing which files are not backed up.
If the BACKUP command is part of a RUN block, then the remaining commands in the RUN
block continue to execute.
If you specify FILESPERSET 1, then RMAN puts each file into its own backup set. When
a backup is interrupted at the end of the backup window, only the backup of the file
currently being backed up is lost. All backup sets completed during the window are
saved, minimizing the lost work caused by the end of the backup window.
To prevent RMAN from issuing an error when a backup partially completes:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute the BACKUP DURATION command with the PARTIAL option.
For example, you run the following command at 2:00 a.m. to specify that the
backup runs until 6:00 a.m. and that each data file is in a separate backup set:
BACKUP
DURATION 4:00 PARTIAL
TABLESPACE users
FILESPERSET 1;
10.8.4 Minimizing Backup Load and Duration
When using DURATION you can run the backup with the maximum possible performance,
or run as slowly as possible while still finishing within the allotted time, to minimize the
performance impact of backup tasks.
To maximize performance, use the MINIMIZE TIME option with DURATION, as shown in
Example 10-4.
Example 10-4
Using MINIMIZE TIME with BACKUP DURATION
BACKUP
DURATION 4:00 PARTIAL
MINIMIZE TIME
DATABASE
FILESPERSET 1;
To extend the backup to use the full time available, use the MINIMIZE LOAD option, as in
Example 10-5.
Example 10-5
Using MINIMIZE LOAD with BACKUP DURATION
In this example, RMAN monitors the progress of the running backup, and periodically
estimates how long the backup takes to complete at its present rate. If RMAN
10-17
Chapter 10
Managing Backup Windows
estimates that the backup will finish before the end of the backup window, then it slows
down the rate of backup so that the full available duration is used. This reduces the
overhead on the database associated with the backup.
BACKUP
DURATION 4:00
MINIMIZE LOAD
DATABASE
FILESPERSET 1;
Note these issues when using DURATION and MINIMIZE LOAD with a tape backup:
•
Efficient backup to tape requires tape streaming. If you use MINIMIZE LOAD, then
RMAN may reduce the rate of backup to the point where tape streaming is not
optimal.
•
RMAN holds the tape resource for the entire duration of the backup window. This
prevents the use of the tape resource for any other purpose during the backup
window.
Because of these concerns, it is not recommended that you use MINIMIZE LOAD when
backing up to tape.
See Also:
Media Manager Component of the Write Phase for SBT for more details on
efficient tape handling
10-18
Part IV
Managing RMAN Backups
The following chapters describe how to manage RMAN backups. This part of the book
contains these chapters:
•
Reporting on RMAN Operations
•
Maintaining RMAN Backups and Repository Records
•
Managing a Recovery Catalog
11
Reporting on RMAN Operations
This chapter describes how to report on RMAN operations. This chapter contains the
following topics:
•
Overview of RMAN Reporting
•
Listing Backups and Recovery-Related Objects
•
Reporting on Backups and Database Schema
•
Using V$ Views to Query Backup Metadata
•
Querying Recovery Catalog Views
11.1 Overview of RMAN Reporting
This section explains the purpose and basic concepts of RMAN reporting.
11.1.1 Purpose of RMAN Reporting
As part of your backup and recovery strategy, you should periodically run reports that
indicate what you have backed up. You can determine which data files need backups
or which files were not backed up recently. Also, you can preview which backups
RMAN must restore if a problem occurs.
Another important aspect of backup and recovery is monitoring space usage. If you
back up to disk, then it is possible for the disk to fill, which can create performance
problems or even cause the database to halt. You can use RMAN to determine
whether a backup is an obsolete backup and can therefore be deleted.
You may also need to obtain historical information about RMAN jobs. For example,
you may want to know how many backup jobs have been issued, the status of each
backup job (for example, whether it failed or completed), when a job started and
finished, and what type of backup was performed.
11.1.2 Basic Concepts of RMAN Reporting
RMAN stores metadata of every database on which it performs operations.
RMAN always stores its RMAN repository of metadata in the control file of the target
database. For example, suppose that you use RMAN to back up the prod1 and prod2
databases. RMAN stores the metadata for backups of prod1 in the control file of prod1,
and the metadata for backups of prod2 in the control file of prod2.
Optionally, you can use RMAN with a recovery catalog. In this case, RMAN maintains
an additional repository of metadata in a set of tables in a separate recovery catalog
database. For example, you could create a recovery catalog in prod3. You can register
multiple target databases in this recovery catalog. For example, if you register prod1
and prod2 in the recovery catalog stored in prod3, then RMAN stores metadata about
its backups of prod1 and prod2 in the recovery catalog schema.
11-1
Chapter 11
Overview of RMAN Reporting
The following table lists the techniques used to access metadata from the RMAN
repository.
Table 11-1
Techniques for Accessing Data from the RMAN Repository
Technique
Description
Additional Information
RMAN LIST and
REPORT commands
The RMAN LIST and REPORT
•
commands provide extensive
information about available
•
backups and how they can be used
to restore and recover your
•
database.
V$ views
When the database is open,
Oracle Database Reference
several V$ views provide direct
access to RMAN repository records
in the control file of each target
database.
"Listing Backups and
Recovery-Related Objects"
"Reporting on Backups and
Database Schema"
LIST , REPORT, and RESTORE
commands in Oracle
Database Backup and
Recovery Reference
Some V$ views such as
V$DATAFILE_HEADER, V$PROCESS,
and V$SESSION contain information
not found in the recovery catalog
views.
RC_ views
If your database is registered in a
Oracle Database Backup and
recovery catalog, then RC_ views
Recovery Reference
provide direct access to the RMAN
repository data stored in the
recovery catalog.
The RC_ views mostly correspond
to the V$ views.
RESTORE ...
PREVIEW and
RESTORE ...
VALIDATE HEADER
commands
These commands list the backups
that RMAN can restore to the
specified time.
These commands are documented
in "Previewing Backups Used in
Restore Operations"
RESTORE ... PREVIEW queries the
metadata but does not read the
backup files. The RESTORE ...
VALIDATE HEADER command
performs the same work, but in
addition to listing the files needed
for restore and recovery
operations, the command validates
the backup file headers to
determine whether the files on disk
or in the media management
catalog correspond to the metadata
in the RMAN repository.
The RMAN repository can sometimes fail to reflect the reality on disk and tape. For
example, a user may delete a backup with an operating system utility, so that the
RMAN repository incorrectly reports the backup as available. You can use commands
such as CHANGE, CROSSCHECK, and DELETE to update the RMAN repository to reflect the
actual state of available backups. Otherwise, the output of the commands and views
may be misleading, which means that RMAN may not be able to find the backups to
restore and recover your database.
11-2
Chapter 11
Listing Backups and Recovery-Related Objects
See Also:
•
Crosschecking the RMAN Repository to learn how to keep the RMAN
repository current
•
Maintaining RMAN Backups and Repository Records
11.1.3 Reporting in a Data Guard Environment
In a Data Guard environment, you can use the LIST, REPORT, and SHOW commands just
as you can when not using Data Guard. You can run these commands with the FOR
DB_UNIQUE_NAME clause to show the backups associated with a specified database.
As explained in "About RMAN File Management in a Data Guard Environment", every
backup is associated with the primary or standby database that created it. For
example, if you backed up the database with the DB_UNIQUE_NAME of standby1, then the
standby1 database is associated with this backup.
For example, the following command lists archived redo logs associated only with
sfstandby:
LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME sfstandby;
If you use the LIST, REPORT, and SHOW commands in a Data Guard environment without
specifying the FOR DB_UNIQUE_NAME clause, then RMAN shows the files that are
accessible to the target database. "About Association of Backups in a Data Guard
Environment" explains when backups are considered accessible to RMAN.
In a Data Guard environment, you must use RMAN with a recovery catalog. RMAN
stores the metadata for all backup and recovery files in the Data Guard environment in
the recovery catalog. When running the RMAN reporting commands, you can either
connect RMAN as TARGET to a mounted or open database, or identify the database with
the SET DBID command.
See Also:
Oracle Data Guard Concepts and Administration to report on RMAN
operations in a Data Guard environment
11.2 Listing Backups and Recovery-Related Objects
The LIST command uses the information in the RMAN repository to provide lists of
backups and other objects relating to backup and recovery.
This section contains the following topics:
•
About the LIST Command
•
Listing All Backups and Copies
•
Listing Selected Backups and Copies
11-3
Chapter 11
Listing Backups and Recovery-Related Objects
•
Listing Preplugin Backups
•
Listing Database Incarnations
11.2.1 About the LIST Command
The primary purpose of the LIST command is to list backup and copies.
For example, you can list:
•
Backups and proxy copies of a database, tablespace, data file, archived redo log,
or control file
•
Backups that have expired
•
Backups restricted by time, path name, device type, tag, or recoverability
•
Archived redo log files and disk copies
Besides backups and copies, RMAN can list other types of data. The following table
summarizes several useful objects that you can list.
Table 11-2
LIST Objects
Contents of List Command
Description
Backup sets and
proxy copies
LIST BACKUP
You can list all backup sets, copies, and proxy copies of
a database, tablespace, data file, archived redo log,
control file, or server parameter file.
Image copies
LIST COPY
You can list data file copies and archived redo log files.
By default, LIST COPY displays copies of all database
files and archived redo logs. Both usable and unusable
image copies are included in the output, even those that
cannot be restored or are expired or unavailable.
Archived redo log LIST ARCHIVELOG You can list archive redo log files. You can list all
files
archive log redo log files or specify individual archive log
files through SCN, time, or sequence number ranges. If
you specify a range you can further restrict the list
returned by specifying an incarnation number.
Preplugin
backups
LIST ...
PREPLUGIN
You can list all preplugin backups and preplugin
archived redo log files.
Database
incarnations
LIST
INCARNATION
You can list all incarnations of a database. A new
database incarnation is created when you open with the
RESETLOGS option.
Databases in a
Data Guard
environment
LIST
DB_UNIQUE_NAME
A database in a Data Guard environment is
distinguished by its DB_UNIQUE_NAME initialization
parameter setting. You can list all databases that have
the same DBID.
11-4
Chapter 11
Listing Backups and Recovery-Related Objects
Table 11-2
(Cont.) LIST Objects
Contents of List Command
Description
Backups and
LIST ... FOR
copies for a
DB_UNIQUE_NAME
primary or
standby database
in a Data Guard
environment
You can list all backups and copies for a specified
database in a Data Guard environment or for all
databases in the environment.
RMAN restricts the output to files or objects associated
exclusively with the database with the specified
DB_UNIQUE_NAME. For example, you can use LIST with
FOR DB_UNIQUE_NAME to display the list of archived redo
log files associated with a particular standby or primary
database. Objects that are not owned by any database
(SITE_KEY column in the recovery catalog view is null)
are not listed.
Restore points
LIST RESTORE
POINT
You can list restore points known to the RMAN
repository.
Names of stored
scripts
LIST SCRIPT
NAMES
You can list the names of recovery catalog scripts
created with the CREATE SCRIPT or REPLACE SCRIPT
command. A recovery catalog is required.
Failures for use
LIST FAILURE
with Data
Recovery Advisor
A failure is a persistent data corruption mapped to a
repair option. Diagnosing and Repairing Failures with
Data Recovery Advisor explains how to use LIST
FAILURE with the ADVISE and REPAIR commands.
The LIST command supports options that control how output is displayed. Table 11-3
summarizes the most common LIST options.
Table 11-3
Most Common LIST Options
LIST Option
Description
LIST EXPIRED
Lists backups or copies that are recorded in the RMAN repository but
that were not present at the expected location on disk or tape during
the most recent crosscheck. Such backups may have been deleted
outside of RMAN.
LIST ... BY FILE
Lists backups of each data file, archived redo log file, control file, and
server parameter file. Each row describes a backup of a file.
LIST ... SUMMARY
Provides a one-line summary of each backup.
The LIST objects and options are not exhausted by the contents of the preceding
tables. For example, you can list backups restricted by time, path name, device type,
tag, or recoverability.
See Also:
Oracle Database Backup and Recovery Reference for a complete
description of the LIST command
11-5
Chapter 11
Listing Backups and Recovery-Related Objects
11.2.2 Listing All Backups and Copies
Specify the desired objects with the listObjList or recordSpec clause. If you do not
specify an object, then RMAN displays copies of all database files and archived redo
log files.
By default, RMAN serially lists each backup or proxy copy and then identifies the files
included in the backup. You can also list backups by file.
By default, RMAN lists in verbose mode, which means that it provides extensive,
multiline information. You can also list backups in a summary mode if the verbose
mode generates too much output.
To view a summary report of all backups and copies, execute the LIST command with
the SUMMARY option.
Example 11-1
Summary Listing of All Backups
This example shows a summary of all RMAN backups.
RMAN> list backup summary;
List of Backups
===============
Key
TY LV S
------- -- -- 1
B A A
2
B F A
3
B A A
4
B F A
5
B F A
Device Type
----------SBT_TAPE
SBT_TAPE
SBT_TAPE
SBT_TAPE
DISK
Completion Time
--------------21-OCT-13
21-OCT-13
21-OCT-13
21-OCT-13
04-NOV-13
#Pieces
------1
1
1
1
1
#Copies
------1
1
1
1
1
Compressed
---------NO
NO
NO
NO
YES
Tag
--TAG20131021T094505
TAG20131021T094513
TAG20131021T094624
TAG20131021T094639
TAG20131104T195949
To view verbose output for backups and copies, execute the LIST command without
the SUMMARY option.
Example 11-2
Verbose Listings of Backups and Copies
This example lists RMAN backups and copies with the default verbose output.
RMAN> list backup;
List of Backup Sets
===================
BS Key Size
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------7
136M
DISK
00:00:20
04-NOV-13
BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20071104T200759
Piece Name: /d2/RDBMS/backupset/2013_11_04/
o1_mf_annnn_TAG20071104T200759_ztjxx3k8_.bkp
List
Thrd
---1
1
1
of Archived Logs in backup set 7
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------1
173832
21-OCT-13 174750
2
174750
21-OCT-13 174755
3
174755
21-OCT-13 174758
Next Time
--------21-OCT-13
21-OCT-13
21-OCT-13
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------8
Full
2M
DISK
00:00:01
04-NOV-13
11-6
Chapter 11
Listing Backups and Recovery-Related Objects
BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20071104T200829
Piece Name: /disk1/oracle/dbs/c-774627068-20131104-01
Controlfile Included: Ckp SCN: 631510
Ckp time: 04-NOV-13
SPFILE Included: Modification time: 21-OCT-13
RMAN> list copy;
List of Datafile Copies
=======================
Key
File S Completion Time Ckp SCN
Ckp Time
------- ---- - --------------- ---------- --------------1
7
A 11-OCT-13
360072
11-OCT-13
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7bf82_.dbf
Tag: DF7COPY
2
8
A 11-OCT-13
360244
11-OCT-13
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7qmcj_.dbf
Tag: TAG20131011T184835
List of Control File Copies
===========================
Key
S Completion Time Ckp SCN
Ckp Time
------- - --------------- ---------- --------------3
A 11-OCT-13
360380
11-OCT-13
Name: /d2/RDBMS/controlfile/o1_mf_TAG20131011T185335_2lv80zqd_.ctl
Tag: TAG20131011T185335
List of Archived Log Copies for database with db_unique_name RDBMS
=====================================================================
Key
Thrd Seq
S Low Time
------- ---- ------- - --------1
1
1
A 11-OCT-13
Name: /work/arc_dest/arcr_1_1_603561743.arc
2
1
2
A 11-OCT-13
Name: /work/arc_dest/arcr_1_2_603561743.arc
3
1
3
A 11-OCT-13
Name: /work/arc_dest/arcr_1_3_603561743.arc
Example 11-3
Listing Backups By File
This example illustrates how to list backups by file using LIST with the BY FILE option.
RMAN> list backup by file;
List of Datafile Backups
========================
File Key
---- ------1
5
2
2
5
2
TY
B
B
B
B
LV
-F
F
F
F
S
A
A
A
A
Ckp SCN
---------631092
175337
631092
175337
Ckp Time
--------04-NOV-13
21-OCT-13
04-NOV-13
21-OCT-13
#Pieces
------1
1
1
1
#Copies
------1
1
1
1
Compressed
---------YES
NO
YES
NO
Tag
--TAG20131104T195949
TAG20131021T094513
TAG20131104T195949
TAG20131021T094513
... some rows omitted
List of Archived Log Backups
============================
11-7
Chapter 11
Listing Backups and Recovery-Related Objects
Thrd Seq
Low SCN
Low Time BS Key
---- ------- ---------- --------- ------1
1
173832
21-OCT-13 7
1
1
2
174750
21-OCT-13 7
1
... some rows omitted
1
38
575472
03-NOV-13 7
1
39
617944
04-NOV-13 7
List of Controlfile Backups
===========================
CF Ckp SCN Ckp Time BS Key
---------- --------- ------631510
04-NOV-13 8
631205
04-NOV-13 6
List of SPFILE Backups
======================
Modification Time BS Key
----------------- ------21-OCT-13
8
21-OCT-13
6
S
A
A
S
A
A
#Pieces
------1
1
#Pieces
------1
1
S
A
A
A
A
#Pieces
------1
1
1
1
A 1
A 1
#Copies
------1
1
#Copies
------1
1
#Copies
------1
1
1
1
Compressed
---------NO
NO
NO
NO
Tag
--TAG20131104T200759
TAG20131021T094505
TAG20131104T200759
TAG20131021T094505
1
1
NO
NO
TAG20131104T200759
TAG20131104T200759
Compressed
---------NO
NO
Compressed
---------NO
NO
Tag
--TAG20131104T200829
TAG20131104T200432
Tag
--TAG20131104T200829
TAG20131104T200432
See Also:
Oracle Database Backup and Recovery Reference for an explanation of the
various column headings in the LIST output
11.2.3 Listing Selected Backups and Copies
You can specify several different conditions to narrow your LIST output.
To list selected backups and copies:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Run LIST COPY or LIST BACKUP with the listObjList or recordSpec clause. For
example, enter any of the following commands:
# lists backups of all files in database
LIST BACKUP OF DATABASE;
# lists copy of specified datafile
LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf';
# lists specified backup set
LIST BACKUPSET 213;
# lists datafile copy
LIST DATAFILECOPY '/tmp/tools01.dbf';
You can also restrict the search by specifying the maintQualifier or RECOVERABLE
clause. For example, enter any of the following commands:
# specify a backup set by tag
LIST BACKUPSET TAG 'weekly_full_db_backup';
# specify a backup or copy by device type
LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt;
# specify a backup by directory or path
LIST COPY LIKE '/tmp/%';
11-8
Chapter 11
Listing Backups and Recovery-Related Objects
# specify a backup or copy by a range of completion dates
LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2012' AND '17-DEC-2012';
# specify logs backed up at least twice to tape
LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
# specify backup sets backed up at least once to disk
LIST BACKUPSET BACKED UP 1 TIMES TO DISK;
# specify backups of PDB backed up at least twice to sbt
LIST BACKUP OF PLUGGABLE DATABASE my_pdb BACKED UP 2 TIMES TO SBT;
3.
Examine the output.
The output depends upon the options that you pass to the LIST command. For
example, the following lists copies of data file 1 contained in backup sets.
RMAN> LIST BACKUP OF DATAFILE 1;
List of Backup Sets
===================
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------2
Full
230M
SBT_TAPE
00:00:49
21-OCT-13
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20131021T094513
Handle: 02f4eatc_1_1 Media: /smrdir
List of Datafiles in backup set 2
File LV Type Ckp SCN
Ckp Time Name
---- -- ---- ---------- --------- ---1
Full 175337
21-OCT-13 /oracle/dbs/tbs_01.f
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------5
Full
233M
DISK
00:04:30
04-NOV-13
BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20131104T195949
Piece Name: /disk1/2013_11_04/o1_mf_nnndf_TAG20131104T195949_ztjxfvgz_.bkp
List of Datafiles in backup set 5
File LV Type Ckp SCN
Ckp Time Name
---- -- ---- ---------- --------- ---1
Full 631092
04-NOV-13 /oracle/dbs/tbs_01.f
See Also:
•
Oracle Database Backup and Recovery Reference for listObjList and
recordSpec syntax
•
Oracle Database Backup and Recovery Reference for an explanation of
the columns in the LIST output
11.2.4 Listing Preplugin Backups
Use the LIST command to list preplugin backups and preplugin archived redo log files.
The COMPATIBLE parameter for the target CDB must be set to 18.0.0 or higher.
1.
Start RMAN and connect to the root of the target database as a common user with
the SYSDBA or SYSBACKUP privilege. Connect to a recovery catalog, if used.
2.
Ensure that the target CDB is in read-write or read-only mode.
11-9
Chapter 11
Listing Backups and Recovery-Related Objects
3.
Set the current container to the PDB whose backup objects you want to display by
using the SET command.
The following command sets the current container to my_pdb.
SET PREPLUGIN CONTAINER = my_pdb;
4.
Run the LIST PREPLUGIN command with the listObjList or recordSpec clause to
display preplugin backups.
To list preplugin backups of a PDB, use the following command:
LIST PREPLUGIN BACKUP OF PLUGGABLE DATABASE pdb1;
To list all preplugin archived redo log files in the target CDB, use the following
command:
LIST PREPLUGIN ARCHVELOG ALL;
11.2.5 Listing Database Incarnations
Each time an OPEN RESETLOGS operation is performed on a database, this operation
creates a new incarnation of the database.
When performing incremental backups, RMAN can use a backup from a previous
incarnation or the current incarnation as a basis for subsequent incremental backups.
When performing restore and recovery operations, RMAN can use backups from a
previous incarnation just as it can use backups from the current incarnation, if all
archived logs are available.
To list database incarnations:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Run the LIST INCARNATION command, as shown in the following example:
LIST INCARNATION;
If you are using a recovery catalog, and if you register multiple target databases in
the same catalog, then you can distinguish them by using the OF DATABASE option:
LIST INCARNATION OF DATABASE prod3;
Following is a sample output of listing the incarnation of a particular database:
RMAN> LIST INCARNATION OF DATABASE rdbms;
List of
DB Key
------1
2
Database Incarnations
Inc Key DB Name DB ID
------- -------- ---------------1
RDBMS
774627068
2
RDBMS
774627068
STATUS
-----PARENT
CURRENT
Reset SCN
---------1
173832
Reset Time
---------21-OCT-13
21-OCT-13
The preceding output indicates that a RESETLOGS operation was performed on
database rdbms at SCN 173832, resulting in a new incarnation. The incarnation is
distinguished by incarnation key (represented in the Inc Key column).
11-10
Chapter 11
Reporting on Backups and Database Schema
See Also:
•
Oracle Database Backup and Recovery Reference for an
explanation of the various column headings in the LIST output
•
About Database Incarnations database incarnations and their effect
on database recovery
11.3 Reporting on Backups and Database Schema
The RMAN REPORT command analyzes the available backups and your database.
This section contains the following topics:
•
About Reports of RMAN Backups
•
Reporting on Files Needing a Backup Under a Retention Policy
•
Reporting on Data Files Affected by Unrecoverable Operations
•
Reporting on Obsolete Backups
•
Reporting on the Database Schema
11.3.1 About Reports of RMAN Backups
The REPORT command provides various reports of RMAN backups.
You can use the REPORT command to answer important questions, such as:
•
Which files need a backup?
•
Which files have had unrecoverable operations performed on them?
•
Which backups are obsolete and can be deleted?
•
What was the physical schema of the target database or a database in the Data
Guard environment at some previous time?
•
Which files have not been backed up recently?
Reports enable you to confirm that your backup and recovery strategy is in fact
meeting your requirements for database recoverability. The two major forms of REPORT
used to determine whether your database is recoverable are:
•
REPORT NEED BACKUP
Reports which database files must be backed up to meet a configured or specified
retention policy
•
REPORT UNRECOVERABLE
Reports which database files require backup because they have been affected by
some NOLOGGING operation such as a direct-path INSERT
The RMAN repository contains other information that you can access with the REPORT
command. The following table summarizes the REPORT options.
11-11
Chapter 11
Reporting on Backups and Database Schema
Table 11-4
REPORT Options
Contents of
Report
Command
Description
Obsolete
backups
REPORT OBSOLETE Full backups, data file copies, and archived redo logs
recorded in the RMAN repository that can be deleted
because they are no longer needed
Database
schema
REPORT SCHEMA
The names of all data files (permanent and temporary)
and tablespaces for the target database at the specified
point in time. If you use RMAN in a Data Guard
environment, then you can report the schema for a
specified DB_UNIQUE_NAME.
See Also:
Oracle Database Backup and Recovery Reference for a description of the
REPORT command
11.3.2 Reporting on Files Needing a Backup Under a Retention Policy
Use the REPORT NEED BACKUP command to determine which database files need backup
under a specific retention policy.
With no arguments, REPORT NEED BACKUP reports which objects need backup under the
currently configured retention policy. The output for a configured retention policy of
REDUNDANCY 1 is similar to this example:
RMAN> REPORT NEED BACKUP;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- ----------------------------------------------------2
0
/oracle/oradata/trgt/undotbs01.dbf
Note:
If you disable the retention policy using CONFIGURE RETENTION POLICY TO NONE ,
then REPORT NEED BACKUP returns an error message, because without a
retention policy, RMAN cannot determine which files must be backed up.
11-12
Chapter 11
Reporting on Backups and Database Schema
11.3.2.1 Using RMAN REPORT NEED BACKUP with Different Retention
Policies
You can use options of the REPORT NEED BACKUP command to specify different retention
policies.
Use one of the following forms to specify different criteria for REPORT NEED BACKUP:
•
REPORT NEED BACKUP RECOVERY WINDOW OF n DAYS
Displays objects requiring backup to satisfy a recovery window-based retention
policy
•
REPORT NEED BACKUP REDUNDANCY n
Displays objects requiring backup to satisfy a redundancy-based retention policy
•
REPORT NEED BACKUP DAYS n
Displays files that require more than n days' worth of archived redo log files for
recovery
•
REPORT NEED BACKUP INCREMENTAL n
Displays files that require application of more than n incremental backups for
recovery
11.3.2.2 Using RMAN REPORT NEED BACKUP with Tablespaces and Data
Files
The REPORT NEED BACKUP command can check the entire database, skip specified
tablespaces, or check only specific tablespaces or data files against different retention
policies.
The following are examples:
REPORT
REPORT
REPORT
REPORT
NEED
NEED
NEED
NEED
BACKUP
BACKUP
BACKUP
BACKUP
RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2;
REDUNDANCY 2 DATAFILE 1;
TABLESPACE TBS_3; # uses configured retention policy
INCREMENTAL 2; # checks entire database
See Also:
Oracle Database Backup and Recovery Reference for all possible options for
REPORT NEED BACKUP and an explanation of the various column headings in the
output
11.3.2.3 Using REPORT NEED BACKUP with Backups on Tape or Disk Only
You can limit the backups tested by the REPORT NEED BACKUP command to disk-based or
tape-based backups only.
Following are some examples:
11-13
Chapter 11
Reporting on Backups and Database Schema
REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE sbt;
REPORT NEED BACKUP DEVICE TYPE DISK;
REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE sbt;
11.3.3 Reporting on Data Files Affected by Unrecoverable Operations
When a data file has been changed by an unrecoverable operation, such as a direct
load insert, normal media recovery cannot be used to recover the file, because an
unrecoverable operation does not generate redo. You must perform either a full or
incremental backup of affected data files after such operations, to ensure that data
blocks affected by the unrecoverable operation can be recovered using RMAN.
To identify data files affected by an unrecoverable operation:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
See Also:
Making Database Connections with RMAN
2.
Execute the REPORT UNRECOVERABLE command.
The following example includes sample output:
RMAN> REPORT UNRECOVERABLE;
Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- ----------------------------------1
full
/oracle/oradata/trgt/system01.dbf
11.3.4 Reporting on Obsolete Backups
You can report backup sets, backup pieces, and data file copies that are obsolete that
is, not needed to meet a specified retention policy by specifying the OBSOLETE keyword.
To report obsolete backups:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
See Also:
Making Database Connections with RMAN
2.
Execute the CROSSCHECK command to update the status of backups in the repository
compared to their status on disk.
In the simplest case, you could crosscheck all backups on disk, tape or both, using
any one of the following commands:
CROSSCHECK BACKUP DEVICE TYPE DISK;
CROSSCHECK BACKUP DEVICE TYPE sbt;
CROSSCHECK BACKUP; # crosschecks all backups on all devices
11-14
Chapter 11
Reporting on Backups and Database Schema
3.
Run REPORT OBSOLETE to identify which backups are obsolete because they are no
longer needed for recovery.
If you do not specify any other options, then REPORT OBSOLETE displays the backups
that are obsolete according to the current retention policy, as shown in the
following example:
RMAN> REPORT OBSOLETE;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of obsolete backups and copies
Type
Key
Completion Time
Filename/Handle
-------------------- ------ ------------------ -------------------Datafile Copy
44
08-FEB-13
/backup/ora_df549738566_s70_s1
Datafile Copy
45
08-FEB-13
/backup/ora_df549738567_s71_s1
Datafile Copy
46
08-FEB-13
/backup/ora_df549738568_s72_s1
Backup Set
26
08-FEB-13
Backup Piece
26
08-FEB-13
/backup/ora_df549738682_s76_s1
.
.
.
You can also check which backups are obsolete under different recovery windowbased or redundancy-based retention policies, by using REPORT OBSOLETE with
RECOVERY WINDOW and REDUNDANCY options, as shown in these examples:
REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS;
REPORT OBSOLETE REDUNDANCY 1;
See Also:
•
Maintaining RMAN Backups and Repository Records for more details on
how to update the RMAN repository record to contain the actual set of
available backups.
•
Configuring the Backup Retention Policy for a conceptual overview of
RMAN backup retention policy
•
Deleting Expired RMAN Backups and Copies for information about
deleting RMAN backups and deleting records of RMAN backups from
the RMAN repository
11.3.5 Reporting on the Database Schema
The REPORT SCHEMA command lists and displays information about the database files,
tablespaces, and so on.
If you do not specify FOR DB_UNIQUE_NAME with REPORT SCHEMA, then a recovery catalog
connection is optional, but a target database connection is required. In a Data Guard
environment, you can specify REPORT SCHEMA FOR DB_UNIQUE_NAME to report the schema
for a database in the environment. In this case, an RMAN connection to a target
database is not required. You can connect RMAN to the recovery catalog and set the
DBID instead.
11-15
Chapter 11
Reporting in CDBs and PDBs
To report on the database schema:
1.
Start RMAN and connect to the desired databases.
See Also:
Making Database Connections with RMAN
2.
If you did not connect RMAN to a target database in the previous step, and you
intend to specify the FOR DB_UNIQUE_NAME clause on REPORT SCHEMA, then set the
database DBID. For example, enter the following command:
RMAN> SET DBID 28014364;
3.
Run the REPORT SCHEMA command as shown in the following example:
RMAN> REPORT SCHEMA;
Report of database schema for database with db_unique_name DGRDBMS
List of Permanent Datafiles
===========================
File Size(MB) Tablespace
---- -------- -------------------1
450
SYSTEM
2
141
SYSAUX
3
50
UD1
4
50
TBS_11
5
50
TBS_11
RB segs
------YES
NO
YES
NO
NO
Datafile Name
-----------------------/disk1/oracle/dbs/t_db1.f
/disk1/oracle/dbs/t_ax1.f
/disk1/oracle/dbs/t_undo1.f
/disk1/oracle/dbs/tbs_111.f
/disk1/oracle/dbs/tbs_112.f
List of Temporary Files
=======================
File Size(MB) Tablespace
Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- -------------------1
40
TEMP
32767
/disk1/oracle/dbs/t_tmp1.f
If you use a recovery catalog, then you can use the atClause to specify a past time,
SCN, or log sequence number, as shown in these examples of the command:
RMAN>
RMAN>
RMAN>
RMAN>
REPORT
REPORT
REPORT
REPORT
SCHEMA
SCHEMA
SCHEMA
SCHEMA
AT TIME 'SYSDATE-14';
# schema 14
AT SCN 1000;
# schema at
AT SEQUENCE 100 THREAD 1; # schema at
FOR DB_UNIQUE_NAME standby1; # schema
days ago
scn 1000
sequence 100
for database standby1
See Also:
Oracle Database Backup and Recovery Reference for a description of
the REPORT SCHEMA output
11.4 Reporting in CDBs and PDBs
You can view reports on the metadata related to a multitenant container database
(CDB), the root only, or one or more pluggable databases (PDBs).
11-16
Chapter 11
Reporting in CDBs and PDBs
The concepts and practices of reporting on non-CDBs is applicable to CDBs and
PDBs, with the differences described in the following sections.
•
Reporting in CDBs
•
Reporting in PDBs
11.4.1 Reporting in CDBs
The steps to view reporting information for a CDB are similar to the ones used for a
non-CDB. The only difference is that you must connect to the root as a common user
with the common SYSBACKUP or common SYSDBA privilege.
The LIST and LIST BACKUP OF commands will display backups of the whole CDB. The
REPORT NEED BACKUP TABLESPACE command displays information about the tablespaces in
the root that need backup.
See Also:
Making RMAN Connections to a CDB
The following command, when connected to the root, displays all the data files in the
CDB that need backup:
REPORT NEED BACKUP;
This command, when connected to the root, provides a summary list of backups of the
whole CDB:
LIST BACKUP SUMMARY;
11.4.2 Reporting in PDBs
Use one of the following techniques to view reporting information for PDBs:
•
Connect to the root and use the LIST ... PLUGGABLE DATABASE or REPORT PLUGGABLE
DATABASE commands. This enables you to display information regarding one or
more PDBs.
The following command, when connected to the root, provides a verbose list of
backups in the PDBs hr_pdb and sales_pdb.
LIST BACKUP OF PLUGGABLE DATABASE hr_pdb, sales_pdb;
•
Connect to the PDB and use the LIST BACKUP or REPORT commands. This approach
displays information for only one PDB and also uses the same commands that are
used for non-CDBs.
The following command, when connected to a particular PDB, displays all the data
files in the PDB that need backup:
REPORT NEED BACKUP;
When connected to a PDB, you cannot view reporting information about obsolete
backups or delete obsolete backups.
11-17
Chapter 11
Using V$ Views to Query Backup Metadata
See Also:
Making RMAN Connections to a CDB
11.4.2.1 Listing Backups of Dropped PDBs
Use the LIST command with the GUID option to list backups of pluggable databases
(PDBs) that have been dropped from a multitenant container database (CDB).
After a PDB is dropped, you cannot perform operations or query data dictionary views
by using the PDB name. However, you can obtain information about dropped PDBs by
querying using GUID of a PDB.
To list backups of dropped PDBs:
1.
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
2.
Query the DBA_PDB_HISTORY view to determine the GUID of the PDB that was
dropped.
The following example displays the PDBs that were dropped from the CDB
test_db:
SELECT pdb_name, pdb_guid FROM dba_pdb_history
WHERE db_name = 'test_db';
3.
Use the LIST command with the GUID option to display backups of a dropped PDB.
The following commands display backup sets and image copies of a dropped PDB
with the specified GUID:
LIST BACKUP GUID 'CDFFD672330A7527D0147204CD0E08D4';
LIST COPY GUID 'CDFFD672330A7527D0147204CD0E08D4';
11.5 Using V$ Views to Query Backup Metadata
In some cases, V$ views supply information that is not available through use of the
LIST and REPORT commands.
This section describes cases in which V$ views are particularly useful and contains the
following topics.
•
Querying Details of Past and Current RMAN Jobs
•
Determining the Encryption Status of Backup Pieces
11.5.1 Querying Details of Past and Current RMAN Jobs
An RMAN job is the set of commands executed within an RMAN session. Thus, one
RMAN job can contain multiple commands.
For example, you may execute two separate BACKUP commands and a RECOVER COPY
command in a single session. An RMAN backup job is the set of BACKUP commands
executed in one RMAN job. For example, a BACKUP DATABASE and BACKUP ARCHIVELOG ALL
command executed in the same RMAN job constitute a single RMAN backup job.
11-18
Chapter 11
Using V$ Views to Query Backup Metadata
The views V$RMAN_BACKUP_JOB_DETAILS and V$RMAN_BACKUP_SUBJOB_DETAILS and their
corresponding recovery catalog versions provide details of RMAN backup jobs. For
example, the views show how long a backup took, how many backup jobs have been
issued, the status of each backup job (for example, whether it failed or completed),
when a job started and finished, and what type of backup was performed. The
SESSION_KEY column is the unique key for the RMAN session in which the backup job
occurred.
RMAN backups often write less than they read. Because of RMAN compression, the
OUTPUT_BYTES_PER_SEC column cannot be used as the measurement of backup speed.
The appropriate column to measure backup speed is INPUT_BYTES_PER_SEC. The ratio
between read and written data is described in the COMPRESSION_RATIO column.
To query details about past and current RMAN jobs:
1.
Connect SQL*Plus to the database whose backup history you intend to query.
2.
Query the V$RMAN_BACKUP_JOB_DETAILS view for information about the backup type,
status, and start and end time.
The following query shows the backup job history ordered by session key, which is
the primary key for the RMAN session:
COL STATUS FORMAT a9
COL hrs
FORMAT 999.99
SELECT SESSION_KEY, INPUT_TYPE, STATUS,
TO_CHAR(START_TIME,'mm/dd/yy hh24:mi') start_time,
TO_CHAR(END_TIME,'mm/dd/yy hh24:mi') end_time,
ELAPSED_SECONDS/3600
hrs
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;
The following sample output shows the backup job history:
SESSION_KEY
----------9
16
113
3.
INPUT_TYPE
------------DATAFILE FULL
DB FULL
ARCHIVELOG
STATUS
--------COMPLETED
COMPLETED
COMPLETED
START_TIME
-------------04/18/07 18:14
04/18/07 18:20
04/23/07 16:04
END_TIME
HRS
-------------- ------04/18/07 18:15
.02
04/18/07 18:22
.03
04/23/07 16:05
.01
Query the V$RMAN_BACKUP_JOB_DETAILS view for the rate of backup jobs in an RMAN
session.
The following query shows the backup job speed ordered by session key, which is
the primary key for the RMAN session. The columns in_sec and out_sec display
the data input and output per second.
COL in_sec FORMAT a10
COL out_sec FORMAT a10
COL TIME_TAKEN_DISPLAY FORMAT a10
SELECT SESSION_KEY,
OPTIMIZED,
COMPRESSION_RATIO,
INPUT_BYTES_PER_SEC_DISPLAY in_sec,
OUTPUT_BYTES_PER_SEC_DISPLAY out_sec,
TIME_TAKEN_DISPLAY
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;
The following sample output shows the speed of the backup jobs:
11-19
Chapter 11
Using V$ Views to Query Backup Metadata
SESSION_KEY
----------9
16
113
4.
OPT COMPRESSION_RATIO IN_SEC
OUT_SEC
--- ----------------- ---------- ---------NO
1
8.24M
8.24M
NO
1.32732239
6.77M
5.10M
NO
1
2.99M
2.99M
TIME_TAKEN
---------00:01:14
00:01:45
00:00:44
Query the V$RMAN_BACKUP_JOB_DETAILS view for the size of the backups in an RMAN
session.
If you run BACKUP DATABASE, then V$RMAN_BACKUP_JOB_DETAILS.OUTPUT_BYTES shows
the total size of backup sets written by the backup job for the database that you
are backing up. To view backup set sizes for all registered databases, query
V$RMAN_BACKUP_JOB_DETAILS.
The following query shows the backup job size and throughput ordered by session
key, which is the primary key for the RMAN session. The columns in_size and
out_size display the data input and output per second.
COL in_size FORMAT a10
COL out_size FORMAT a10
SELECT SESSION_KEY,
INPUT_TYPE,
COMPRESSION_RATIO,
INPUT_BYTES_DISPLAY in_size,
OUTPUT_BYTES_DISPLAY out_size
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;
The following sample output shows the size of the backup jobs:
SESSION_KEY
----------10
17
INPUT_TYPE
COMPRESSION_RATIO IN_SIZE
OUT_SIZE
------------- ----------------- ---------- ---------DATAFILE FULL
1 602.50M
602.58M
DB FULL
1.13736669 634.80M
558.13M
See Also:
Oracle Database Reference to learn about the V$RMAN_BACKUP_JOB_DETAILS
view
11.5.2 Determining the Encryption Status of Backup Pieces
The ENCRYPTED column of the V$BACKUP_PIECE and V$RMAN_BACKUP_PIECE views indicates
whether a backup piece is encrypted (YES) or unencrypted (NO).
For example, you can run the following query in SQL*Plus to determine which backup
pieces are encrypted:
COL
COL
COL
COL
COL
BS_REC
BP_REC
MB
ENCRYPTED
TAG
FORMAT
FORMAT
FORMAT
FORMAT
FORMAT
99999
99999
9999999
A7
A25
SELECT S.RECID AS "BS_REC", P.RECID AS "BP_REC", P.ENCRYPTED,
P.TAG, P.HANDLE AS "MEDIA_HANDLE"
FROM V$BACKUP_PIECE P, V$BACKUP_SET S
11-20
Chapter 11
Querying Recovery Catalog Views
WHERE P.SET_STAMP = S.SET_STAMP
AND
P.SET_COUNT = S.SET_COUNT;
The following sample output shows that the backups are encrypted:
BS_REC BP_REC ENCRYPT TAG
------ ------ ------- ------------------------MEDIA_HANDLE
-------------------------------------------------------------------------------1
1 YES
TAG20070711T140124
/disk1/c-39525561-20070711-00
2
2 YES
TAG20070711T140128
/disk1/c-39525561-20070711-01
3
3 YES
TAG20070711T140130
/disk1/c-39525561-20070711-02
See Also:
Oracle Database Reference to learn about the V$BACKUP_PIECE view
11.6 Querying Recovery Catalog Views
The LIST, REPORT, and SHOW commands provide the easiest means of accessing the
data in the control file and the recovery catalog.
Nevertheless, you can sometimes also obtain useful information from the recovery
catalog views, which reside in the recovery catalog schema and use the RC_ prefix.
This section contains the following topics:
•
About Recovery Catalog Views
•
Querying Catalog Views for the Target DB_KEY or DBID Values
•
Querying RC_BACKUP_FILES
11.6.1 About Recovery Catalog Views
RMAN obtains backup and recovery metadata from a target database control file and
stores it in the tables of the recovery catalog. The recovery catalog views are derived
from these tables. The recovery catalog views are not normalized or optimized for user
queries.
In general, the recovery catalog views are not as user-friendly as the RMAN reporting
commands. For example, when you start RMAN and connect to a target database, you
obtain the information for this target database only when you issue LIST, REPORT, and
SHOW commands. If you have 10 different target databases registered in the same
recovery catalog, then any query of the catalog views shows the metadata for all
incarnations of all 10 databases. You often must perform complex selects and joins
among the views to extract usable information about a database incarnation.
Most of the catalog views have a corresponding V$ view in the database. For example,
RC_BACKUP_PIECE corresponds to V$BACKUP_PIECE. The primary difference between the
recovery catalog view and corresponding V$ view is that each recovery catalog view
11-21
Chapter 11
Querying Recovery Catalog Views
contains metadata about all the target databases registered in the recovery catalog.
The V$ view contains information only about itself.
See Also:
Oracle Database Backup and Recovery Reference for a description of
recovery catalog views
11.6.1.1 About Unique Identifiers for Registered Databases
Most recovery catalog views contain the columns DB_KEY and DBINC_KEY. Each
database registered in the recovery catalog can be uniquely identified by either the
primary key, which is the DB_KEY column value, or the DBID, which is the 32-bit unique
database identifier. Each incarnation of a database is uniquely identified by the
DBINC_KEY column.
You can use DB_KEY and DBINC_KEY to retrieve the records of a specific incarnation of a
target database. Then, you can perform joins with most of the other catalog views to
isolate records belonging to this incarnation.
An important difference between catalog and V$ views is that a different system of
unique identifiers is used for backup and recovery files. For example, many V$ views
such as V$ARCHIVED_LOG use the RECID and STAMP columns to form a concatenated
primary key. The corresponding recovery catalog view uses a derived value as its
primary keys and stores this value in a single column. For example, the primary key in
RC_ARCHIVED_LOG is the AL_KEY column. The AL_KEY column value is the primary key that
RMAN displays in the LIST command output.
11.6.1.2 About Unique Identifiers in a Data Guard Environment
Special considerations apply when querying the recovery catalog in a Data Guard
environment.
In a Data Guard environment, multiple databases share the same DBID. Several views
contain a DB_UNIQUE_NAME column, which indicates the DB_UNIQUE_NAME of the database
incarnation to which the record belongs. All databases in a Data Guard environment
share the same DBID but have different DB_UNIQUE_NAME values.
The value of DB_UNIQUE_NAME is null when the database name is not known to the
catalog, as for Oracle9i databases that are registered in a recovery catalog. Also, the
column value is null when a database is upgraded to Oracle Database 11g or later but
the recovery catalog schema has not reconciled the database names for all files.
In the recovery catalog views, the primary database and its associated standby
databases share the same DB_KEY. However, every database in a Data Guard
environment has a unique RC_SITE.SITE_KEY value. For example, a primary database
prod and its standby database standby1 might both have the DB_KEY value of 1, whereas
the SITE_KEY of prod is 3 and the SITE_KEY of standby1 is 30.
Some recovery catalog views do not have a DB_UNIQUE_NAME column, but include a
SITE_KEY column. You can use the SITE_KEY column to join with RC_SITE.SITE_KEY to
determine the DB_UNIQUE_NAME of the database associated with a file. As explained in
"About RMAN File Management in a Data Guard Environment", every file in a Data
Guard environment is associated with the primary or standby database that created it.
11-22
Chapter 11
Querying Recovery Catalog Views
See Also:
Oracle Data Guard Concepts and Administration to learn how to report on
and manage files in a Data Guard environment
11.6.2 Querying Catalog Views for the Target DB_KEY or DBID
Values
The DB_KEY value, which is the primary key for a registered database, is used only in
the recovery catalog. The easiest way is to obtain the DB_KEY is to use the DBID of the
target database, which is displayed whenever you connect RMAN to a database as
TARGET.
The DBID distinguishes databases registered in the RMAN recovery catalog.
Assume that you want to obtain information about a database registered in the
recovery catalog.
To query the catalog for information about the current incarnation of a database:
1.
Determine the DBID for the database whose records you want to view.
You can obtain the DBID by looking at the output displayed when RMAN connects
to the database, querying V$RMAN_OUTPUT, or querying a V$DATABASE view. The
following example connects SQL*Plus to the desired database and queries the
DBID:
SQL> CONNECT / AS SYSBACKUP
SQL> SELECT DBID
2 FROM V$DATABASE;
DBID
--------598368217
2.
Start SQL*Plus and connect to the recovery catalog database as the owner of the
recovery catalog.
3.
Obtain the database key for the database whose DBID you obtained in Step 1.
To obtain the DB_KEY for a database run the following query, where dbid_of_target
is the DBID obtained in Step 1:
SELECT DB_KEY
FROM RC_DATABASE
WHERE DBID = dbid_of_target;
4.
Query the records for the current incarnation of the database whose DBID you
obtained in Step 1.
To obtain information about the current incarnation of a target database, specify
the target database DB_KEY value and perform a join with the
RC_DATABASE_INCARNATION view. Use a WHERE condition to specify that the
CURRENT_INCARNATION column value is set to YES. For example, to obtain information
about backup sets in the current incarnation of a target database with the DB_KEY
value of 1, query as follows:
11-23
Chapter 11
Querying Recovery Catalog Views
SELECT
FROM
WHERE
AND
AND
BS_KEY, BACKUP_TYPE, COMPLETION_TIME
RC_DATABASE_INCARNATION i, RC_BACKUP_SET b
i.DB_KEY = 1
i.DB_KEY = b.DB_KEY
i.CURRENT_INCARNATION = 'YES';
See Also:
•
Oracle Database Backup and Recovery Reference for details about the
RC_DATABASE_INCARNATION view
•
About Database Incarnations
11.6.3 Querying RC_BACKUP_FILES
You can query the view RC_BACKUP_FILES for information about all backups of any
database registered in the recovery catalog. Before querying RC_BACKUP_FILES,
however, you must call the DBMS_RCVMAN.SETDATABASE procedure.
Specify the DBID of a database registered in the recovery catalog, as shown in the
following example:
SQL> CALL DBMS_RCVMAN.SETDATABASE(null,null,null,2283997583);
The fourth parameter must be the DBID of a database registered in the recovery
catalog. The other parameters must all be NULL.
See Also:
•
Oracle Database Backup and Recovery Reference for details about the
RC_BACKUP_FILES view
•
Determining the DBID of the Database for techniques for determining the
DBID of a database
11-24
12
Maintaining RMAN Backups and
Repository Records
This chapter describes how to manage the RMAN repository records, and RMAN
backups and copies. This chapter also explains maintenance tasks related to the fast
recovery area. This chapter contains the following topics:
•
Overview of RMAN Backup and Repository Maintenance
•
Maintaining the Control File Repository
•
Maintaining the Fast Recovery Area
•
Updating the RMAN Repository
•
Deleting RMAN Backups and Archived Redo Logs
•
Dropping a Database
See Also:
Managing a Recovery Catalog for RMAN maintenance issues that are
specific to a recovery catalog
12.1 Overview of RMAN Backup and Repository
Maintenance
This section explains the purpose and basic concepts of RMAN repository
maintenance.
12.1.1 Purpose of Backup and Repository Maintenance
The recommended maintenance strategy is to configure a fast recovery area, a
backup retention policy, and an archived redo log deletion policy. In this case, the
database automatically maintains and deletes backups and archived redo logs as
needed. However, manual maintenance of database backups and archived redo logs
is sometimes necessary.
Managing RMAN backups involves the following related tasks:
•
Managing the database backups that are stored on disk or tape
•
Managing the records of those backups in the RMAN repository
An important part of RMAN maintenance is deleting backups that are no longer
needed. If you configure a fast recovery area, then the database automatically deletes
unneeded files in this area automatically; even so, you may want to delete backups
12-1
Chapter 12
Overview of RMAN Backup and Repository Maintenance
and copies from tape. You may even need to delete an entire database. You can use
an RMAN command to perform these tasks.
The fast recovery area may require occasional maintenance. For example, the fast
recovery area may become full, in which case you can add space to it. Alternatively,
you may want to change the location of the recovery area.
It is possible for the RMAN repository to fail to reflect the true state of files on disk or
tape. For example, a user may delete a backup from disk with an operating system
utility. In this case, the RMAN repository shows that the file exists when it does not. In
a similar situation, a tape containing RMAN backups may be corrupted. You can use
RMAN maintenance commands to update the repository with accurate information.
12.1.2 Basic Concepts of Backup and Repository Maintenance
RMAN provides multiple commands to maintain RMAN backups and repository
records.
Following are the RMAN maintenance commands:
•
The CATALOG command enables you to add records about RMAN and usermanaged backups that are currently not recorded in the RMAN repository, or to
remove records for backups that are recorded.
•
The CHANGE command enables you to update the status of records in the RMAN
repository.
•
The CROSSCHECK command enables you to synchronize the logical backup records
with the physical reality of files in backup storage.
•
The DELETE command enables you to delete backups from the operating system.
12.1.2.1 About Maintenance Commands and RMAN Repository Metadata
RMAN always stores its metadata in the control file of each target database on which it
performs operations. If you register a target database in the recovery catalog, then
RMAN stores the metadata for this target database in the recovery catalog.
All of the RMAN maintenance commands work with or without a recovery catalog.
See Also:
Maintaining a Recovery Catalog
12.1.2.2 About Maintenance Commands in a Data Guard Environment
The database in a Data Guard environment that creates a backup or copy is
associated with the file. For example, if RMAN is connected to target database
standby1 and backs it up, then this backup is associated with standby1.
If backups are accessible to RMAN according to the criteria specified in "About RMAN
File Management in a Data Guard Environment", you can use RMAN maintenance
commands such as CHANGE, DELETE, and CROSSCHECK for backups when connected to any
primary or standby database.
12-2
Chapter 12
Overview of RMAN Backup and Repository Maintenance
12.1.2.2.1 About Crosschecks in a Data Guard Environment
For a crosscheck, RMAN can only update the status of a file from AVAILABLE to EXPIRED
when connected to the database associated with the file.
Thus, if RMAN crosschecks a file and does not find it, and if the file is associated with
a database to which it is not connected as TARGET, then RMAN prompts you to perform
the crosscheck when connected to the target database associated with the file. RMAN
performs a crosscheck when you run the CROSSCHECK or CHANGE ... AVAILABLE
command.
12.1.2.2.2 About Deletion in a Data Guard Environment
RMAN can delete files when connected to any database. If RMAN is not connected as
TARGET to the database associated with a file, and if RMAN cannot delete a file
successfully, then RMAN prompts you to connect as TARGET to the database
associated with the file. You must then use DELETE ... FORCE to delete the file
metadata.
12.1.2.2.3 About Updates to RMAN Metadata in a Data Guard Environment
If a maintenance command changes RMAN metadata only, then you can connect
RMAN as TARGET to any database in the Data Guard environment.
Commands that change only metadata include:
•
CHANGE ... UNAVAILABLE or CHANGE ... UNCATALOG
•
CHANGE ... KEEP or CHANGE ... NOKEEP
•
CHANGE ... RESET DB_UNIQUE_NAME
By default, the CHANGE command only operates on files that are accessible according to
the rules specified in "About Accessibility of Backups in a Data Guard Environment".
However, you can change the status of files associated with a database other than the
target database by using the FOR DB_UNIQUE_NAME option.
12.1.2.2.4 About Files Not Associated with a Database
A backup remains associated with a database unless you explicitly use the CHANGE ...
RESET DB_UNIQUE_NAME to associate the backup with a different database.
In some cases the DB_UNIQUE_NAME may not be known for a specific file. For example,
the value of DB_UNIQUE_NAME is null when the database name is not known to the
recovery catalog, as for Oracle9i databases that are registered in a recovery catalog.
Also, rows can have a DB_UNIQUE_NAME of null because a database has been upgraded
to the current version, but the recovery catalog schema has not reconciled the
DB_UNIQUE_NAME values for all files. By default, RMAN associates files whose SITE_KEY is
null with the database to which RMAN is connected as TARGET.
12-3
Chapter 12
Maintaining the Control File Repository
See Also:
•
Oracle Data Guard Concepts and Administration to learn how to use
RMAN to back up and restore files in a Data Guard environment
•
Oracle Database Backup and Recovery Reference for a description of
the RMAN CHANGE command
12.2 Maintaining the Control File Repository
RMAN is designed to work without a recovery catalog. If you choose not to use a
recovery catalog, however, then the control file of each target database is the
exclusive repository for RMAN metadata.
You must know how information is stored in the control file and ensure that your
backup and recovery strategy protects the control file.
See Also:
Oracle Database Administrator’s Guide for an overview of the control file and
more details about managing control files
12.2.1 About Control File Records
The control file contains two types of records: circular reuse records and noncircular
reuse records.
Circular reuse records contain noncritical information that is eligible to be overwritten if
needed. These records contain information that is continually generated by the
database. When all available record slots are full, the database either expands the
control file to make room for a new record or overwrites the oldest record. The
CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in
days of a record before it can be reused.
Noncircular reuse records contain critical information that does not change often and
cannot be overwritten. Some examples of information in noncircular reuse records
include data files, online redo log files, and redo threads.
As you make backups of a target database, the database records these backups in the
control file. To prevent the control file from growing too large because of the addition of
new records, records can be reused if they are older than a threshold that you specify.
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum
age in days of a record before it can be overwritten:
CONTROL_FILE_RECORD_KEEP_TIME = integer
For example, if the parameter value is 14, then any record of age 14 days or older is a
candidate for reuse. Information in an overwritten record is lost. The oldest record
available for reuse is used first.
12-4
Chapter 12
Maintaining the Control File Repository
When the database must add new RMAN repository records to the control file, but no
record is older than the threshold, the database attempts to expand the size of the
control file. If the underlying operating system prevents the expansion of the control file
(due to a disk full condition, for instance), then the database overwrites the oldest
record in the control file.
The database records the overwrite in the alert log located in the Automatic Diagnostic
Repository (ADR). For each record that it overwrites, the database records an entry in
the alert log similar to the following:
kccwnc: following control file record written over:
RECID #72 Recno 72 Record timestamp
07/28/06 22:15:21
Thread=1 Seq#=3460
Backup set key: stamp=372031415, count=17
Low scn: 0x0000.3af33f36
07/27/06 21:00:08
Next scn: 0x0000.3af3871b
07/27/06 23:23:54
Resetlogs scn and time
scn: 0x0000.00000001
12.2.1.1 About Fast Recovery Area and Control File Records
When a control file record containing information about a file created in the fast
recovery area is about to be reused, the database attempts to delete the file from the
fast recovery area when the file is eligible for deletion. Otherwise, the database
expands the size of the control file section containing the record for this file.
The database logs the expansion in the alert log with a message like this example,
where nnnn is the number of the control file record type:
kccwnc: trying to expand control file section nnnn for Oracle Managed Files
If the control file is at the maximum size supported under the host operating system,
then the database cannot expand the control file. In such a situation, this warning
appears in the alert log:
WARNING: Oracle Managed File filename is unknown to control file. This is the result
of limitation in control file size that could not keep all recovery area files.
The preceding message means that the control file cannot hold a record of all fast
recovery area files needed to satisfy the configured retention policy. The next section
explains how to respond to this situation.
See Also:
Oracle Database Reference for information about the
CONTROL_FILE_RECORD_KEEP_TIME initialization parameter
12-5
Chapter 12
Maintaining the Control File Repository
12.2.2 Preventing the Loss of Control File Records
The best way to prevent the loss of RMAN metadata because of overwritten control file
records is to use a recovery catalog.
If you cannot use a recovery catalog, then you can take the following measures:
•
Set the CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file
that you must keep. For example, if you back up the whole database once a week,
then you must keep every backup for at least 7 days. Set
CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14. The default value of
CONTROL_FILE_RECORD_KEEP_TIME is 7 days.
Caution:
Regardless of whether you use a recovery catalog, never use RMAN
when CONTROL_FILE_RECORD_KEEP_TIME is set to 0. If you do, then you may
lose backup records.
•
Store the control file in a file system rather than on a raw device so that it can
expand.
•
Monitor the alert log to ensure that Oracle Database is not overwriting control file
records. The alert log is located in the Automatic Diagnostic Repository (ADR).
If you use a fast recovery area, then follow these guidelines to avoid a situation in
which the control file cannot hold a record of all fast recovery area files needed to
satisfy the backup retention policy:
•
If the block size of the control file is not at its maximum, then use a larger block
size, preferably 32 kilobytes.
To achieve this aim, you must set the SYSTEM tablespace block size to be greater
than or equal to the control file block size, and re-create the control file after
changing DB_BLOCK_SIZE. The files in the fast recovery area are recataloged, but the
records for files on tape are lost.
•
Make the files in the fast recovery area eligible for deletion by backing them up to
tertiary storage such as tape.
For example, you can use BACKUP RECOVERY AREA to specifically back up files in the
fast recovery area to a media manager.
•
If the backup retention policy is keeping backups and archived logs longer than
your business requirements, then you can make more files in the fast recovery
area eligible for deletion by changing the retention policy to a shorter recovery
window or lower degree of redundancy.
12.2.3 Protecting the Control File
If you are not using a recovery catalog to store RMAN metadata, then it is doubly
important that you protect each target database control file.
You can use the following strategy to protect the control file.
12-6
Chapter 12
Maintaining the Fast Recovery Area
To protect the control file:
1.
Create redundant copies of control files through multiplexing or operating system
mirroring.
In this way, the database can survive the loss of a subset of the control files
without requiring you to restore a control file from backup. Oracle recommends
that you use a minimum of two multiplexed or mirrored control files on separate
disks.
2.
Configure the control file autobackup feature.
In this case, RMAN automatically backs up the control file when you run certain
RMAN commands. If a control file autobackup is available, RMAN can restore the
server parameter and backup control file, and mount the database. After the
control file is mounted, you can restore the remainder of the database.
3.
Keep a record of the database DBID.
If you lose the control files, then you can use the DBID to recover the database.
See Also:
•
Backing Up Control Files with RMAN to learn about manual and
automatic control file backups
•
About RMAN Control File and Server Parameter File Autobackups
12.3 Maintaining the Fast Recovery Area
Although the fast recovery area is largely self-managing, some situations may require
database administration intervention.
12.3.1 Deletion Rules for the Fast Recovery Area
RMAN uses certain rules to determine when files can be deleted from the fast
recovery area.
The following rules govern when files become eligible for deletion from the recovery
area:
•
Permanent files are never eligible for deletion.
•
Files that are obsolete under the retention policy are eligible for deletion.
•
Transient files that have been copied to tape are eligible for deletion.
•
Archived redo logs are not eligible for deletion until all the consumers of the logs
have satisfied their requirements.
Consumers of logs can include RMAN, standby databases, Oracle Streams
databases, and the Flashback Database feature.
•
Foreign archived logs that have been mined by a LogMiner session on a logical
standby database are eligible for deletion. Because it is generated from a different
12-7
Chapter 12
Maintaining the Fast Recovery Area
database than the current database, a foreign archived redo log has a different
DBID than the current archived redo logs.
The safe and reliable way to control deletion of files from the fast recovery area is to
configure your retention policy and archived log deletion policy. To increase the
likelihood that files moved to tape are retained on disk, increase the fast recovery area
quota.
See Also:
•
"Overview of Files in the Fast Recovery Area" for information about the
contents of the fast recovery area and the difference between permanent
and transient files
•
"Configuring an Archived Redo Log Deletion Policy" for information about
how to configure an archived redo log deletion policy that determines
when logs are eligible to be deleted
•
Configuring the Backup Retention Policy for information about how to
configure the retention policy
•
Oracle Data Guard Concepts and Administration to learn about archived
redo log management in a Data Guard environment
12.3.2 Monitoring Fast Recovery Area Space Usage
You can use the V$RECOVERY_FILE_DEST and V$RECOVERY_AREA_USAGE views to determine
whether you have allocated enough space for your fast recovery area.
Query the V$RECOVERY_FILE_DEST view to discover the current location, disk quota,
space in use, space reclaimable by deleting files, and total number of files in the fast
recovery area. The space columns specify the amount in bytes. Query the
V$RECOVERY_AREA_USAGE view to discover the percentage of the total disk quota used by
different types of files. Also, you can determine how much space for each type of file
can be reclaimed by deleting files that are obsolete, redundant, or backed up to tape.
When guaranteed restore points are defined on your database, you must monitor the
amount of space used in your fast recovery area for files required to meet the
guarantee. Use the query for viewing guaranteed restore points in "Listing Restore
Points Using the V$RESTORE_POINT View" and see the STORAGE_SIZE column to
determine the space required for files related to each guaranteed restore point.
Example 12-1
Fast Recovery Area Space Consumption
The following example displays details about the fast recovery area such as the
location, disk quota, space usage, and number of files.
SELECT * FROM V$RECOVERY_FILE_DEST;
NAME
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID
------------ ----------- ---------- ----------------- --------------- -----/mydisk/rcva 5368709120 109240320
256000
28
0
12-8
Chapter 12
Maintaining the Fast Recovery Area
Example 12-2
Fast Recovery Area Space Usage Based on Type of Files
The following example displays the percentage of space used, percentage of space
that can be reclaimed, and number of files in the fast recovery area for each type of
file.
SELECT * FROM V$RECOVERY_AREA_USAGE;
FILE_TYPE
PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID
------------ ------------------ ------------------------- --------------- -----CONTROLFILE
0
0
0
0
ONLINELOG
2
0
22
0
ARCHIVELOG
4.05
2.01
31
0
BACKUPPIECE
3.94
3.86
8
0
IMAGECOPY
15.64
10.43
66
0
FLASHBACKLOG
.08
0
1
0
See Also:
•
V$RECOVERY_AREA_USAGE in Oracle Database Reference
•
V$RECOVERY_FILE_DEST in Oracle Database Reference
12.3.3 Managing Space for Flashback Logs in the Fast Recovery Area
You cannot manage the flashback logs in the fast recovery area directly other than by
setting the flashback retention target or using guaranteed restore points.
Nevertheless, you can manage fast recovery area space as a whole to maximize the
space available for retention of flashback logs. In this way you increase the likelihood
of achieving the flashback target.
To make space for flashback logs, back up the other contents of your fast recovery
area to tape with commands such as BACKUP RECOVERY AREA, BACKUP BACKUPSET, and so
on. Oracle Database automatically removes obsolete files from the fast recovery area.
If offloading backups to tape still does not create enough space to satisfy the backup
retention policy and flashback retention target, then allocate more space in the fast
recovery area.
Note:
You cannot back up flashback logs. Thus, the BACKUP RECOVERY AREA operation
does not include the flashback logs when backing up the fast recovery area
contents to tape.
See Also:
About Logging for Flashback Database with Guaranteed Restore Points
Defined for the rules for flashback log deletion
12-9
Chapter 12
Maintaining the Fast Recovery Area
12.3.4 Responding to a Full Fast Recovery Area
If the RMAN retention policy requires keeping a set of backups larger than the fast
recovery area disk quota, or if the retention policy is set to NONE, then the fast recovery
area can fill completely with no reclaimable space.
The database issues a warning alert when reclaimable space is less than 15% and a
critical alert when reclaimable space is less than 3%. To warn the DBA of this
condition, an entry is added to the alert log and to the DBA_OUTSTANDING_ALERTS table
(used by Enterprise Manager). Nevertheless, the database continues to consume
space in the fast recovery area until there is no reclaimable space left.
When the recovery area is completely full, the error displayed is as follows, where
nnnnn is the number of bytes required and mmmmm is the disk quota:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit
You have several choices for how to resolve a full fast recovery area when no files are
eligible for deletion:
•
Make more disk space available and increase DB_RECOVERY_FILE_DEST_SIZE to
reflect the additional space.
•
Move backups from the fast recovery area to tertiary storage such as tape.
One convenient way to back up all of your recovery area files to tape together is
the BACKUP RECOVERY AREA command. After you transfer backups from the recovery
area to tape, you can delete files from the fast recovery area. Flashback logs
cannot be backed up outside the recovery area and are not backed up by BACKUP
RECOVERY AREA.
•
Run DELETE for any files that have been removed with an operating system utility.
If you use host operating system commands to delete files, then the database is
not aware of the resulting free space. You can run the RMAN CROSSCHECK
command to have RMAN recheck the contents of the fast recovery area and
identify expired files, and then use the DELETE EXPIRED command to delete every
expired backup from the RMAN repository.
•
Ensure that your guaranteed restore points are necessary. If not, delete them.
Flashback logs that are not needed for a guaranteed restore point are deleted
automatically to gain space for other files in the fast recovery area. A guaranteed
restore point forces the retention of flashback logs required to perform Flashback
Database to the restore point SCN.
•
Review your backup retention policy and, if using Data Guard, your archived redo
log deletion policy.
12-10
Chapter 12
Maintaining the Fast Recovery Area
See Also:
•
Deleting RMAN Backups and Archived Redo Logs
•
Dropping Restore Points
•
Backing Up the Database to decide on a retention policy
•
Oracle Data Guard Concepts and Administrationfor more information
about archived log deletion policy with Data Guard
12.3.5 Changing the Fast Recovery Area to a New Location
Use the ALTER SYSTEM command to change the location of the fast recovery area.
If you must move the fast recovery area of your database to a new location, then
follow this procedure:
1.
Start SQL*Plus on the target database and change the DB_RECOVERY_FILE_DEST
initialization parameter. For example, enter the following command to set the
destination to the ASM disk group disk1:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
After you change this parameter, all new fast recovery area files are created in the
new location.
2.
Either leave or move the permanent files, flashback logs, and transient files in the
old flash recovery location.
If you leave the existing files in the flash recovery, then the database deletes the
transient files from the old fast recovery area as they become eligible for deletion.
If you must move the old files to the new fast recovery area, then see the Oracle
Automatic Storage Management Administrator's Guide. The procedure for moving
database files into and out of an ASM disk group with RMAN works when moving
files into and out of a fast recovery area.
12.3.6 Disabling the Fast Recovery Area
The ALTER SYSTEM command can be used to disable the fast recovery area.
Before disabling the fast recovery area, you must first drop all guaranteed restore
points and then turn off Flashback Database.
You can then set the DB_RECOVERY_FILE_DEST initialization parameter to a null string to
disable the fast recovery area. For example, use the following SQL statement to
change the parameter on a running database:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';
The database no longer provides the space management features of the fast recovery
area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files are still
known to the RMAN repository, however, and available for backup and restore
activities.
12-11
Chapter 12
Updating the RMAN Repository
12.3.7 Responding to an Instance Crash During File Creation
As a rule, the fast recovery area is self-maintaining. When an instance crashes during
the creation of a file in the fast recovery area, however, the database may leave the
file in the fast recovery area.
When this situation occurs, the alert log contains the following error, where location is
the location of the fast recovery area:
ORA-19816: WARNING: Files may exist in location that are not known to database.
In such a situation, use the RMAN command CATALOG RECOVERY AREA to recatalog any
such files. If the file header of the file in question is corrupted, then delete the file
manually with an operating system utility.
12.4 Updating the RMAN Repository
Several situations can cause a discrepancy between the repository and the files that it
records, including tape or disk failures and user-managed copies or deletions of
RMAN-related files.
This section explains how to ensure that the RMAN repository accurately reflects the
reality of the RMAN-related files stored on disk and tape.
12.4.1 Crosschecking the RMAN Repository
To ensure that data about backups in the recovery catalog or control file is
synchronized with corresponding data on disk or in the media management catalog,
perform a crosscheck. The CROSSCHECK command operates only on files that are
currently recorded in the RMAN repository.
If you use a fast recovery area, backup retention policy, and archived redo log deletion
policy, then you do not need to perform crosschecks very often. If you delete files by
means other than RMAN, then you must perform a crosscheck periodically to ensure
that the repository data stays current.
12.4.1.1 About RMAN Crosschecks
Crosschecks update outdated RMAN repository information about backups whose
repository records do not match their physical status. For example, if a user removes
archived logs from disk with an operating system command, the repository still
indicates that the logs are on disk, when in fact they are not.
Figure 12-1 illustrates a crosscheck of a media manager. RMAN queries the RMAN
repository for the names and locations of the four backup sets to be checked. RMAN
sends this information to the target database server, which queries the media
management software about the backups. The media management software then
checks its media catalog and reports back to the server that backup set 3 is missing.
RMAN updates the status of backup set 3 to EXPIRED in the repository. The record for
backup set 3 is deleted after you run DELETE EXPIRED.
12-12
Chapter 12
Updating the RMAN Repository
Figure 12-1
Crosschecking a Media Manager
Media Manager
Oracle Database
RMAN
Media Management
Library
Recovery
Catalog
Control
file
Backup
set 1
Backup
set 2
Backup
set 3
Backup
set 4
Crosschecks are useful because they can do the following:
•
Update outdated information about backups that disappeared from disk or tape or
became corrupted
•
Update the repository if you delete archived redo logs or other files with operating
system commands
Use the crosscheck feature to check the status of a backup on disk or tape. If the
backup is on disk, then CROSSCHECK checks whether the header of the file is valid. If a
backup is on tape, then the command checks that the backups exist in the media
management software catalog.
Backup pieces and image copies can have the status AVAILABLE, EXPIRED, or
UNAVAILABLE. You can view the status of backups by running the RMAN LIST command
or by querying V$BACKUP_FILES or recovery catalog views such as RC_DATAFILE_COPY or
RC_ARCHIVED_LOG. A crosscheck updates the RMAN repository so that all of these
techniques provide accurate information. RMAN updates each backup in the RMAN
repository to status EXPIRED if the backup is no longer available. If a new crosscheck
determines that an expired backup is available again, then RMAN updates its status to
AVAILABLE.
Note:
The CROSSCHECK command does not delete operating system files or remove
repository records. You must use the DELETE command for these operations.
You can issue the DELETE EXPIRED command to delete all expired backups. RMAN
removes the record for the expired file from the repository. If for some reason the file
still exists on the media, then RMAN issues warnings and lists the mismatched objects
that cannot be deleted.
12-13
Chapter 12
Updating the RMAN Repository
See Also:
•
Oracle Database Backup and Recovery Reference for CROSSCHECK syntax
and a description of the possible status values
•
Oracle Database Backup and Recovery Reference for DELETE syntax
12.4.1.2 Crosschecking All Backups and Copies
After connecting to the target database and recovery catalog (if you use one), run
CROSSCHECK commands as needed to verify the status and availability of backups known
to RMAN.
You can configure or manually allocate multiple channels before issuing CROSSCHECK or
DELETE commands. RMAN searches for each backup on all channels that have the
same device type as the channel used to create the backup. The multichannel feature
is primarily intended for use when crosschecking or deleting backups on both disk and
tape within a single command. For example, assume that you have an SBT channel
configured as follows:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE sbt;
In this case you can run the following commands to crosscheck both disk and SBT:
CROSSCHECK BACKUP;
CROSSCHECK COPY;
RMAN uses both the SBT channel and the preconfigured disk channel to perform the
crosscheck. Sample output follows:
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=12 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820
.
.
.
If you do not have an automatic SBT channel configured, then you can manually
allocate maintenance channels on disk and tape.
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
CROSSCHECK COPY;
You do not have to manually allocate a disk channel because RMAN uses the
preconfigured disk channel.
12-14
Chapter 12
Updating the RMAN Repository
12.4.1.3 Crosschecking Specific Backup Sets and Copies
You can use the LIST command to report your backups and then use the CROSSCHECK
command to check that specific backups described in the LIST output still exist.
The DELETE EXPIRED command deletes repository records for backups that fail the
crosscheck.
To crosscheck specified backups:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Run a LIST command to identify the backups to be checked.
For example, run the following command:
LIST BACKUP; # lists all backup sets, proxy copies, and image copies
Crosscheck the desired backups or copies.
The following sample commands illustrate different types of crosschecks:
CROSSCHECK BACKUP; # checks backup sets, proxy copies, and image copies
CROSSCHECK COPY OF DATABASE;
CROSSCHECK BACKUPSET 1338, 1339, 1340;
CROSSCHECK BACKUPPIECE TAG 'nightly_backup';
CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE;
CROSSCHECK BACKUP OF DATAFILE "?/oradata/trgt/system01.dbf"
COMPLETED AFTER 'SYSDATE-14';
CROSSCHECK BACKUPSET DEVICE TYPE disk BACKED UP 3 TIMES TO sbt;
CROSSCHECK BACKUP OF DATABASE BACKED UP 2 TIMES TO sbt;
CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl';
CROSSCHECK DATAFILECOPY 113, 114, 115;
CROSSCHECK PROXY 789;
See Also:
Oracle Database Backup and Recovery Reference for more details on using
CROSSCHECK to check backups of specific files
12.4.1.4 Crosschecking Preplugin Backups
Use the CROSSCHECK command to verify the status and availability of preplugin backups
and preplugin archived redo log files known to RMAN.
Ensure that the preplugin backups and preplugin archived redo log files created on the
source CDB are accessible to the target database.
To crosscheck preplugin backups:
1.
Start RMAN and connect to the root of the target database as a common user with
the SYSDBA or SYSBACKUP privilege. Connect to a recovery catalog, if used.
See "Making Database Connections with RMAN".
2.
Ensure that the target CDB is open in read-write mode.
12-15
Chapter 12
Updating the RMAN Repository
The following command displays the open mode of the database:
SELECT OPEN_MODE FROM V$DATABASE;
3.
Set the preplugin container to the PDB whose preplugin backups must be
crosschecked.
The following example sets the preplugin container to the PDB my_pdb:
SET PREPLUGIN CONTAINER=my_pdb;
4.
Run the CROSSCHECK command to verify the status and availability of preplugin
backups.
The following command crosschecks the backups for PDB my_pdb.
CROSSCHECK PREPLUGIN BACKUP OF PLUGGABLE DATABASE my_pdb;
12.4.2 Changing the Repository Status of Backups and Copies
RMAN provides multiple methods of changing the repository status of backups and
copies.
Perform any of the following tasks to change the repository status of backups and
copies:
•
Making backups available or unavailable
You can change the status of a backup if it becomes temporarily available or
unavailable. For example, if a mounted disk undergoes maintenance, then you can
update the records for backups on the disk to status UNAVAILABLE.
Updating a Backup to Status AVAILABLE or UNAVAILABLE describes how to
make backups available or unavailable.
•
Including or exempting backups from the retention policy
Archival backups can be created by using the KEEP clause to exempt backups from
the configured retention policy. You can also change the status of an archival
backup and subsequently include it in the configured retention policy.
Changing the Status of an Archival Backup describes how to change the status of
archival backups.
12.4.2.1 Updating a Backup to Status AVAILABLE or UNAVAILABLE
Run the CHANGE...UNAVAILABLE command when a backup cannot be found or has
migrated offsite.
RMAN does not use files with status UNAVAILABLE in RESTORE or RECOVER commands. If
the file is later found or returns to the main site, then you can update its status again
by issuing CHANGE...AVAILABLE . The files in the fast recovery area cannot be marked as
UNAVAILABLE.
To update the status of a file in the repository to UNAVAILABLE or AVAILABLE:
1.
Issue a LIST command to determine the availability status of RMAN backups. For
example, issue the following command to list all backups:
LIST BACKUP;
2.
Run CHANGE with the UNAVAILABLE or AVAILABLE keyword to update its status in the
RMAN repository.
12-16
Chapter 12
Updating the RMAN Repository
The following examples illustrate forms of the CHANGE command:
CHANGE
CHANGE
CHANGE
CHANGE
CHANGE
CHANGE
CHANGE
DATAFILECOPY '/tmp/control01.ctl' UNAVAILABLE;
COPY OF ARCHIVELOG SEQUENCE BETWEEN 1000 AND 1012 UNAVAILABLE;
BACKUPSET 12 UNAVAILABLE;
BACKUP OF SPFILE TAG "TAG20120208T154556" UNAVAILABLE;
DATAFILECOPY '/tmp/system01.dbf' AVAILABLE;
BACKUPSET 12 AVAILABLE;
BACKUP OF SPFILE TAG "TAG20120208T154556" AVAILABLE;
See Also:
Oracle Database Backup and Recovery Reference for CHANGE command
syntax
12.4.2.2 Changing the Status of an Archival Backup
You can designate backups as exempt from the retention policy. This technique is
useful for archiving backups to comply with business requirements.
An archival backup is still a fully valid backup, however, and can be restored just as
any other RMAN backup.
Note:
The KEEP FOREVER clause requires the use of a recovery catalog, because the
control file cannot contain an infinitely large set of RMAN repository data.
You can use the CHANGE command to alter the KEEP status of an existing backup. For
example, you may decide that you no longer want to keep a long-term backup. The
same options available for BACKUP...KEEP are available with CHANGE...KEEP .
You cannot set KEEP attributes for backup sets or files stored in the fast recovery area.
To alter the KEEP status of an archival backup:
1.
Issue a LIST command to list the backups. For example, issue the following
command to list all backups:
LIST BACKUP;
2.
Issue a CHANGE...KEEP command to define a different retention period for this
backup, or a CHANGE...NOKEEP command to let the retention policy apply to this file.
This example allows a backup set to be subject to the backup retention policy:
CHANGE BACKUPSET 231 NOKEEP;
This example makes a data file copy exempt from the retention policy for 180
days:
CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL TIME 'SYSDATE+180';
12-17
Chapter 12
Updating the RMAN Repository
See Also:
Making Database Backups for Long-Term Storage
12.4.2.3 Changing the Status of Backups for Dropped PDBs
Use the CHANGE command with the GUID option to change the status of backups that
correspond to pluggable databases (PDBs) that have been dropped from a multitenant
container database (CDB).
After you drop a PDB, you cannot use the PDB name to change the status of backups
associated with the dropped PDB. Instead, use the GUID to identify the dropped PDB.
1.
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
2.
Query the DBA_PDB_HISTORY view to determine the GUID of the PDB that was
dropped.
The following example displays the PDBs that were deleted from the CDB test_db:
SELECT pdb_name, pdb_guid FROM dba_pdb_history
WHERE db_name = 'test_db';
3.
Use the CHANGE command with the GUID clause to modify the status of a backup
corresponding to a dropped PDB.
The following commands remove RMAN repository records of backup pieces and
image copies associated with a dropped PDB that is identified using its GUID.
CHANGE BACKUPPIECE GUID 'DFCE8C3A437F214EB4230070EC0D294E' UNCATALOG;
CHANGE COPY GUID 'DFCE8C3A437F214EB4230070EC0D294E' UNCATALOG;
12.4.2.4 Changing the Status of Preplugin Backups
Use the CHANGE command to modify the repository status of preplugin backups and
preplugin archived redo log files.
Ensure that the preplugin backups and archived redo log files created on the source
CDB are accessible to the target database.
To change the status of preplugin backups:
1.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege. Connect to a recovery catalog, if used.
See "Making Database Connections with RMAN".
2.
Ensure that the target CDB is open in read-write mode.
The following command displays the open mode of the database:
SELECT OPEN_MODE FROM V$DATABASE;
3.
Set the current container to the PDB whose preplugin backups must be
crosschecked.
The following example sets the preplugin container to the PDB my_pdb:
SET PREPLUGIN CONTAINER=my_pdb;
12-18
Chapter 12
Updating the RMAN Repository
4.
Run the CHANGE command to verify the status and availability of preplugin archived
redo log files.
The following command makes all preplugin archived redo log files available.
CHANGE PREPLUGIN BACKUP OF ARCHIVELOG ALL AVAILABLE;
12.4.3 Adding Backup Records to the RMAN Repository
You can use the CATALOG command to make RMAN aware of the existence of archived
logs not recorded in the repository or copies of database files that are created through
means other than RMAN.
12.4.3.1 About Cataloging Operations
The target database control file keeps records of all archived redo logs generated by
the target database and all RMAN backups. The purpose of the CATALOG command is to
add metadata to the repository when it does not have a record of files for RMAN to
manage.
Run the RMAN CATALOG command when:
•
You use an operating system utility to make copies of data files, archived logs, or
backup pieces. In this case, the repository has no record of them.
•
You perform recovery with a backup control file and you change the archiving
destination or format during recovery. In this situation, the repository does not
have information about archived logs needed for recovery, and you must catalog
these logs.
•
You want to catalog data file copy as a level 0 backup, thus enabling you to
perform an incremental backup later by using the data file copy as the base of an
incremental backup strategy.
•
You want to catalog user-managed copies of Oracle7 database files created
before you migrated to a higher release, or of Oracle8 and higher database files
created before you started to use RMAN. These data file copies enable you to
recover the database if it fails after migration but before you have a chance to take
a backup of the migrated database.
Whenever you make a user-managed copy, for example, by using the UNIX cp
command to copy a data file, be sure to catalog it. When making user-managed
copies, you can use the ALTER TABLESPACE...BEGIN/END BACKUP statement to make data
file copies off an online tablespace. Although RMAN does not create such data file
copies, you can use the CATALOG command to add them to the recovery catalog so that
RMAN is aware of them.
For a user-managed copy to be cataloged, it must be:
•
Accessible on disk
•
A complete image copy of a single file
•
Either a data file copy, control file copy, archived redo log copy, or backup piece
copy
For example, if you store data files on mirrored disk drives, then you can create a
user-managed copy by breaking the mirror. In this scenario, use the CATALOG command
to notify RMAN of the existence of the user-managed copy after breaking the mirror.
12-19
Chapter 12
Updating the RMAN Repository
Before reforming the mirror, run a CHANGE...UNCATALOG command to notify RMAN that
the file copy no longer exists.
12.4.3.2 Cataloging User-Managed Data File Copies
Use the CATALOG command to propagate information about user-managed copies to the
RMAN repository. After the files are cataloged, you can run the LIST command or
query V$BACKUP_FILES view to confirm the information is contained in the RMAN
repository.
To create and catalog a user-managed copy of a data file:
1.
Make a data file copy with an operating system utility. ALTER TABLESPACE BEGIN/END
BACKUP is necessary if the database is open and the data files are online while the
backup is in progress. This example backs up an online data file, using the
SQL*Plus HOST command to issue an operating system command.
SQL> ALTER TABLESPACE users BEGIN BACKUP;
SQL> HOST CP $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf;
SQL> ALTER TABLESPACE users END BACKUP;
2.
Start RMAN and connect to a target database and recovery catalog (if used).
3.
Run the CATALOG command.
For example, enter the following command to catalog a user-managed data file
copy:
CATALOG DATAFILECOPY '/tmp/users01.dbf';
If you try to catalog a data file copy from a database other than the connected
target database, then RMAN issues an error such as the following:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of catalog command on default channel at 08/29/2013 14:44:34
ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf
See Also:
Oracle Database Backup and Recovery Reference for CATALOG command
syntax
12.4.3.3 Cataloging Backup Pieces
You can catalog backup pieces on disk. This technique is useful if you use an
operating system utility to copy backup pieces from one location to another on the
same host, or from one host to another.
You can even catalog a backup piece from a prior incarnation of the database. RMAN
can determine whether that backup piece can be used during a subsequent restore
and recovery operation.
To catalog a backup piece:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
12-20
Chapter 12
Updating the RMAN Repository
2.
Catalog the file names of the backup pieces.
For example, enter the following command:
CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';
3.
Optionally, run a LIST command or query V$ views to verify your changes.
Views include V$BACKUP_PIECE, V$BACKUP_SET, V$BACKUP_DATAFILE, V$BACKUP_REDOLOG,
and V$BACKUP_SPFILE. The following query shows the names of backup pieces:
SELECT HANDLE
FROM V$BACKUP_PIECE;
See Also:
Oracle Database Backup and Recovery Reference for CATALOG
BACKUPPIECE restrictions
12.4.3.4 Cataloging All Files in a Disk Location
If you use Automatic Storage Management (ASM), an Oracle Managed Files
framework, or the fast recovery area, then you may want to recatalog files that are
known to the disk management system but are no longer listed in the RMAN
repository. This situation can occur when the intended mechanism for tracking file
names fails due to media failure, software bug, or user error.
The CATALOG START WITH command enables you to search through all files in an ASM
disk group, Oracle Managed Files location, or traditional file system directory and
investigate those that are not recorded in the RMAN repository. If the command can
catalog a file, then it does so. If it cannot catalog the file, then it makes its best guess
about the contents of the skipped file.
The CATALOG RECOVERY AREA command enables you to catalog all files in the recovery
area. Typically, you do not need to run this command manually because RMAN
automatically runs it as needed, for example, when you restore or create a control file.
You can run this command when files are copied into the fast recovery area by
operating system utilities.
To catalog all files in a disk location:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Run the CATALOG command, specifying the disk location whose files you want to
catalog.
For example, enter the following commands:
CATALOG START WITH '+disk'; # catalog all files from an ASM disk group
CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory
Note:
Wildcard characters are not legal in the START WITH clause.
12-21
Chapter 12
Updating the RMAN Repository
You can use the CATALOG RECOVERY AREA command to catalog all files in the
recovery area. During this operation, any files in the recovery area not listed in the
RMAN repository are added. For example:
CATALOG RECOVERY AREA;
3.
Run a LIST command to verify that the files were cataloged.
12.4.3.5 Cataloging Preplugin Archived Redo Logs
Use the CATALOG command to add preplugin archived redo log files to the RMAN
repository.
Ensure that the preplugin archived redo log files created on the source CDB are
accessible to the target database.
To catalog preplugin backups of archived redo log files:
1.
Start RMAN and connect to the root of the target database as a common user with
the SYSDBA or SYSBACKUP privilege. Connect to a recovery catalog, if used.
See "Making Database Connections with RMAN".
2.
Ensure that the target CDB is open in read-write mode.
The following command displays the open mode of the database:
SELECT OPEN_MODE FROM V$DATABASE;
3.
Set the current container to the PDB whose preplugin backups must be
crosschecked.
The following example sets the preplugin container to the PDB my_pdb:
SET PREPLUGIN CONTAINER=my_pdb;
4.
Run the CATALOG command to catalog preplugin archived redo log files in the
RMAN repository.
The following command catalogs the specified preplugin archived redo log.
CATALOG PREPLUGIN ARCHIVELOG '/disk1/backups/DB18c/backupset/2017_10_09/
o1_mf_annnn_MYPDB_MIGR_dxq2r45h_.bkp';
12.4.4 Removing Records from the RMAN Repository
You can remove records for files from the RMAN repository.
12.4.4.1 About Uncataloging Operations in the RMAN Repository
Run the CHANGE...UNCATALOG command to perform the following actions on RMAN
repository records:
•
Update a backup record in the control file repository to status DELETED
•
Delete a specific backup record from the recovery catalog (if you use one)
RMAN does not change the specified physical files: it only alters the repository records
for these files.
You can use this command when you have deleted a backup through a means other
than RMAN. For example, if you delete archived redo logs with an operating system
12-22
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
utility, then remove the record for this log from the repository by issuing a CHANGE
ARCHIVELOG ... UNCATALOG command.
12.4.4.2 Removing Records for Files Deleted with Operating System Utilities
You can use the CHANGE ... UNCATALOG command to update the RMAN repository for
the absent files.
In some circumstances, users may have removed backups or archived redo logs with
operating system utilities. Unless you run CROSSCHECK, RMAN does not know about the
deletion. In such cases, you can use the CHANGE..UNCATALOG command.
To remove the catalog record for a backup or archived redo log:
1.
Run a CHANGE ... UNCATALOG command for the backups that you deleted from the
operating system with operating system commands. This example deletes
repository references to disk copies of the control file and data file 1:
CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG;
CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;
CHANGE BACKUPSET '/disk1/oradata/backups/db1_full.bkp' UNCATALOG;
2.
Optionally, view the relevant recovery catalog view, for example, RC_DATAFILE_COPY
or RC_CONTROLFILE_COPY, to confirm that a given record was removed. This query
confirms that the record of copy 4833 was removed:
SELECT CDF_KEY, STATUS
FROM RC_DATAFILE_COPY
WHERE CDF_KEY = 4833;
CDF_KEY
STATUS
---------- -----0 rows selected.
12.5 Deleting RMAN Backups and Archived Redo Logs
You can use the RMAN DELETE command to delete archived redo logs and RMAN
backups.
For backups on disk, deleting backups physically removes the backup file from disk.
For backups on SBT devices, the RMAN DELETE command instructs the media
manager to delete the backup pieces or proxy copies on tape. In either case, RMAN
updates the RMAN repository to reflect the deletion.
Note:
In a CDB, you can delete archived logs only when you connect to the root as
a user with the SYSDBA or SYSBACKUP privilege. Archived redo logs cannot be
deleted when connected to a PDB.
12.5.1 Overview of Deleting RMAN Backups
Every RMAN backup produces a corresponding record in the RMAN repository. This
record is stored in the control file. If a recovery catalog is used, then the record can
12-23
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
also be found in the recovery catalog after the recovery catalog is resynchronized from
the control file.
For example, if you generate a full database backup set, then you can view the record
for this backup set in V$BACKUP_SET. If you use a recovery catalog, then you can also
access the record in the RC_BACKUP_SET catalog view.
The V$ control file views and recovery catalog views differ in the way that they store
information, and this affects how RMAN handles repository records. The recovery
catalog RMAN repository is stored in actual database tables, while the control file
version of the repository is stored in an internal structure in the control file.
When you use an RMAN command to delete a backup or archived redo log file, RMAN
does the following:
•
Removes the physical file from the operating system (if the file is still present)
•
Updates the file records in the control file to status DELETED
•
Removes the file records from the recovery catalog tables (if RMAN is connected
to a recovery catalog)
Because of the way that control file data is stored, RMAN cannot remove the record
from the control file, only update it to DELETED status. Because the recovery catalog
tables are ordinary database tables, however, RMAN deletes rows from them in the
same way that rows are deleted from any table.
12.5.1.1 About RMAN Deletion Commands
You can delete backups and recovery catalog records for backups.
The following table describes the RMAN commands that can delete backups.
Table 12-1
RMAN Deletion Commands
Command
Purpose
DELETE
To delete backups, update the control file records to status
DELETED, and remove their records from the recovery catalog
(if a recovery catalog is used).
You can specify that DELETE removes backups that are
EXPIRED or OBSOLETE. If you run DELETE EXPIRED on a backup
that exists, then RMAN issues a warning and does not delete
the backup. If you use the DELETE command with the optional
FORCE keyword, then RMAN deletes the specified backups, but
ignores any I/O errors, including those that occur when a
backup is missing from disk or tape. It then updates the RMAN
repository to reflect the fact that the backup is deleted,
regardless of whether RMAN was able to delete the file or
whether the file was missing.
RMAN uses all configured channels to perform the deletion. If
you use DELETE for files on devices that are not configured for
automatic channels, then you must first use ALLOCATE CHANNEL
FOR MAINTENANCE command. For example, if you made a
backup with the SBT channel, but only a disk channel is
configured, then you must manually allocate an SBT channel
for DELETE. An automatic or manually allocated maintenance
channel is required when you use DELETE command on a diskonly file.
12-24
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
Table 12-1
(Cont.) RMAN Deletion Commands
Command
Purpose
BACKUP...DELETE [ALL]
INPUT
To back up archived logs, data file copies, or backup sets,
then delete the input files from the operating system after the
successful completion of the backup. RMAN also deletes and
updates repository records for the deleted input files.
If you specify DELETE INPUT (without ALL), then RMAN deletes
only the specific files that it backs up. If you specify ALL INPUT,
then RMAN deletes all copies of the files recorded in the
RMAN repository.
CHANGE...UNCATALOG
To delete recovery catalog records for specified backups and
change their control file records to status DELETED. The
CHANGE...UNCATALOG command only changes the RMAN
repository record of backups, and does not actually delete
backups.
The RMAN repository record for an object can sometimes fail to reflect the physical
status of the object. For example, you back up an archived redo log to disk and then
use an operating system utility to delete it. If you run DELETE without first running
CROSSCHECK, then the repository erroneously lists the log as AVAILABLE.
If you run RMAN interactively, then RMAN asks for confirmation before deleting any
files. You can suppress these confirmations by using the NOPROMPT keyword with any
form of the BACKUP command:
DELETE NOPROMPT ARCHIVELOG ALL;
See Also:
Oracle Database Backup and Recovery Reference for a description of DELETE
behavior when mismatches occur between the RMAN repository and
physical media
12.5.1.2 About Deletion of Archived Redo Logs
The recommended maintenance strategy is to configure a fast recovery area, a
backup retention policy, and an archived redo log deletion policy.
By default, the archived redo logs deletion policy is configured to NONE. In this case, the
fast recovery area considers the logs eligible for deletion if they have been backed up
at least once to disk or tape or the logs are obsolete according to the backup retention
policy.
Archived redo logs can be deleted automatically by the database or by any of the userinitiated RMAN commands listed in Table 12-1. For logs in the recovery area, the
database retains them as long as possible and automatically deletes eligible logs
when disk space is required. You can delete eligible logs from any location, inside or
outside the recovery area, with BACKUP ... DELETE INPUT or DELETE ARCHIVELOG. Both of
these commands obey the archive redo log deletion policy when the policy is any
setting other than NONE. You can override the archived redo log deletion policy settings
by using the FORCE option in the DELETE command.
12-25
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
See Also:
•
Basic Concepts of Backup and Repository Maintenance
•
Configuring an Archived Redo Log Deletion Policy
•
The CONFIGURE ARCHIVELOG DELETION POLICY entry in Oracle Database
Backup and Recovery Reference for detailed information about policy
options
12.5.2 Deleting All Backups and Copies
Use the RMAN DELETE command to delete backups and image copies.
In some circumstances, you may need to delete all backup sets, proxy copies, and
image copies associated with a database. For example, you no longer need a
database and want to remove all related files from the system. An image copy is a file
generated with BACKUP AS COPY command, a log archived by the database, or a file
cataloged with the CATALOG command.
To delete all backups and copies:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
If necessary, allocate maintenance channels for the devices containing the
backups to be deleted.
As explained in Table 12-1, RMAN uses all configured channels to perform the
deletion. If channels are configured, then you do not need to manually allocate
maintenance channels.
3.
Crosscheck the backups and copies to ensure that the logical records are
synchronized with the physical media.
CROSSCHECK BACKUP;
CROSSCHECK COPY;
4.
Delete the backups and copies.
For example, enter the following commands and then enter YES when prompted:
DELETE BACKUP;
DELETE COPY;
If disk and tape channels are configured, then RMAN uses both the configured
SBT channel and the preconfigured disk channel when deleting. RMAN prompts
you for confirmation before deleting any files.
12.5.3 Deleting Specified Backups and Copies
You can use both the DELETE and BACKUP ... DELETE commands to delete specific
backups and copies.
The BACKUP ... DELETE command backs up the files first, typically to tape, and then
deletes the input files afterward.
12-26
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
The DELETE command supports a wide range of options to identify objects to delete.
When deleting archived redo logs, RMAN uses the configured settings to determine
whether a log can be deleted.
To delete specified backups and copies:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
If necessary, allocate maintenance channels for the devices containing the
backups to be deleted.
As explained in Table 12-1, RMAN uses all configured channels to perform the
deletion. If channels are configured, then you do not need to manually allocate
maintenance channels.
3.
Delete the specified backups and copies.
The following examples show many of the common ways to specify backups and
archived logs to delete with the DELETE command:
•
Deleting backups using primary keys from LIST output:
DELETE BACKUPPIECE 101;
•
Deleting backups by file name on disk:
DELETE CONTROLFILECOPY '/tmp/control01.ctl';
•
Deleting archived redo logs:
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 300;
•
Deleting backups based on tags:
DELETE BACKUP TAG 'before_upgrade';
•
Deleting backups based on the objects backed up and the media or disk
location where the backup is stored:
DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape
DELETE COPY OF CONTROLFILE LIKE '/tmp/%';
•
Deleting archived redo logs from disk based on whether they are backed up
on tape:
DELETE ARCHIVELOG ALL
BACKED UP 3 TIMES TO sbt;
•
Deleting backup sets that were backed up twice to tape:
DELETE BACKUPSET DEVICE TYPE disk BACKED UP 2 TIMES TO sbt;
•
Deleting backups of the target database that were backed up once to tape:
DELETE BACKUP OF DATABASE DEVICE TYPE disk BACKED UP 1 TIMES TO sbt;
See Also:
•
Configuring an Archived Redo Log Deletion Policy
•
Oracle Database Backup and Recovery Reference for complete
information about the DELETE command options
12-27
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
12.5.3.1 Deleting Specified Files with BACKUP ... DELETE
You can use BACKUP ... DELETE to back up archived redo logs, data file copies, or
backup sets and then delete the input files after successfully backing them up.
Specifying the DELETE INPUT option is equivalent to issuing the DELETE command for the
input files. RMAN uses the configured settings to determine whether an archived redo
log can be deleted.The ALL option in the DELETE ALL INPUT clause applies only to
archived redo logs. If you run BACKUP ... DELETE ALL INPUT, then the command deletes
all copies of corresponding archived redo logs or data file copies that match the
selection criteria in the BACKUP command.
See Also:
Configuring an Archived Redo Log Deletion Policy
12.5.4 Deleting Expired RMAN Backups and Copies
If you run CROSSCHECK, and if RMAN cannot locate the files, then it updates their records
in the RMAN repository to EXPIRED status. You can then use the DELETE EXPIRED
command to remove records of expired backups and copies from the RMAN
repository.
The DELETE EXPIRED command issues warnings if any files marked as EXPIRED actually
exist. In rare cases, the repository can mark a file as EXPIRED even though it exists. For
example, a directory containing a file is corrupted at the time of the crosscheck, but is
later repaired, or the media manager was not configured properly and reported some
backups as not existing when they really existed.
To delete expired repository records:
1.
If you have not performed a crosscheck recently, then issue a CROSSCHECK
command. For example, issue:
CROSSCHECK BACKUP;
2.
Delete the expired backups. For example, issue:
DELETE EXPIRED BACKUP;
12.5.5 Deleting Obsolete RMAN Backups Based on Retention Policies
The RMAN DELETE command supports an OBSOLETE option, which deletes backups that
are no longer needed to satisfy specified recoverability requirements.
You can delete files that are obsolete according to the configured default retention
policy, or another retention policy that you specify as an option to the DELETE OBSOLETE
command. As with other forms of the DELETE command, the files deleted are removed
from backup media, deleted from the recovery catalog, and marked as DELETED in the
control file.
If you specify the DELETE OBSOLETE command with no arguments, then RMAN deletes all
obsolete backups defined by the configured retention policy. For example:
12-28
Chapter 12
Deleting RMAN Backups and Archived Redo Logs
DELETE OBSOLETE;
12.5.5.1 DELETE OBSOLETE Behavior When KEEP UNTIL TIME Expires
If the KEEP UNTIL TIME period has not expired for an archival backup, RMAN does not
consider the backup as obsolete. As soon as the KEEP UNTIL period expires, however,
the backup is immediately considered to be obsolete, regardless of any configured
backup retention policy. Thus, DELETE OBSOLETE deletes any backup created with
BACKUP ... KEEP UNTIL TIME if the KEEP time has expired.
See Also:
Oracle Database Backup and Recovery Reference for keepOption syntax
12.5.6 Deleting Backups of Dropped PDBs
Use the DELETE command with the GUID option to delete backups of pluggable
databases (PDBs) that have been dropped from a multitenant container database
(CDB).
The DELETE BACKUP ... OF PLUGGABLE DATABASE command deletes backups of the
specified PDB. However, after a PDB is dropped, you cannot use this command
because the a PDB with the specified name no longer exists. In such cases, use the
DELETE BACKUP … GUID command to delete backups of dropped PDBs. Each PDB has a
globally unique identifier (GUID) which can be used to uniquely identify a PDB. The
GUID of dropped PDBs is available in the DBA_PDB_HISTORY view.
To delete backups of a dropped PDB:
1.
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
2.
Query the DBA_PDB_HISTORY view to determine the GUID of the PDB that was
dropped.
The following example displays the PDBs that were deleted from the CDB prod_db:
SELECT pdb_name, pdb_guid FROM dba_pdb_history
WHERE db_name = 'prod_db';
3.
Use the DELETE command with the GUID option to delete backups or copies
associated with the dropped PDB.
The following commands delete backup sets and image copies of a dropped PDB
with the specified GUID:
DELETE BACKUP GUID '100E64EC12445321C0352900AF0FAC93';
DELETE COPY GUID '100E64EC12445321C0352900AF0FAC93';
12.5.7 Deleting Preplugin Backups
Use the DELETE command to delete preplugin backups and prelplugin archived redo log
files.
Ensure that the preplugin backups created on the source database are accessible to
the target CDB.
12-29
Chapter 12
Dropping a Database
To delete preplugin backups:
1.
Start RMAN and connect to the root of the target CDB as a common user with the
SYSDBA or SYSBACKUP privilege. Connect to a recovery catalog, if used.
See "Making Database Connections with RMAN".
2.
Ensure that the target CDB is open in read-write mode.
The following command displays the open mode of the database:
SELECT OPEN_MODE FROM V$DATABASE;
3.
Set the current container to the PDB whose preplugin backups must be
crosschecked.
The following example sets the preplugin container to the PDB my_pdb:
SET PREPLUGIN CONTAINER=my_pdb;
4.
Run the DELETE command to verify the status and availability of preplugin backups.
The following command deletes preplugin backups of the PDB my_pdb.
DELETE PREPLUGIN BACKUP OF PLUGGABLE DATABASE my_pdb;
12.6 Dropping a Database
To remove a database from the operating system, you can use the DROP DATABASE
command in RMAN. RMAN removes the server parameter file, all data files, online
redo logs, and control files belonging to the target database.
DROP DATABASE requires that RMAN be connected to the target database, and that the
target database be mounted. The command does not require connection to the
recovery catalog. If RMAN is connected to the recovery catalog, and if you specify the
option INCLUDE COPIES AND BACKUPS, then RMAN also unregisters the database.
To delete a database:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
See Also:
Making Database Connections with RMAN
2.
Catalog all backups that are associated with the database. For example, the
following commands catalog files in the fast recovery area, and then in a
secondary archiving destination:
CATALOG START WITH '+disk1';
# all files from recovery area on ASM disk
CATALOG START WITH '/arch_dest2'; # all files from second archiving location
3.
Delete all backups and copies associated with the database. For example:
DELETE BACKUPSET; # deletes all backups
DELETE COPY; # deletes all image copies (including archived logs)
4.
Remove the database from the operating system.
The following command deletes the database and automatically unregisters it from
the recovery catalog (if used). RMAN prompts for confirmation.
12-30
Chapter 12
Dropping a Database
DROP DATABASE;
See Also:
•
Dropping a Database with SQL*Plus to learn how to use the SQL DROP
DATABASE statement
•
Oracle Database Backup and Recovery Reference for the RMAN DROP
DATABASE command syntax
12-31
13
Managing a Recovery Catalog
This chapter explains how to manage an RMAN recovery catalog. The catalog is a
database schema that contains the RMAN repository data for one or more target
databases. This chapter contains the following topics:
•
Overview of the RMAN Recovery Catalog
•
Creating a Recovery Catalog
•
Registering a Database in the Recovery Catalog
•
Cataloging Backups in the Recovery Catalog
•
Creating and Managing Virtual Private Catalogs
•
Protecting the Recovery Catalog
•
Managing Stored Scripts
•
Maintaining a Recovery Catalog
•
Dropping a Recovery Catalog
See Also:
–
Maintaining RMAN Backups and Repository Recordsto learn how to
manage the RMAN repository as stored in the control file, without a
recovery catalog
–
The compatibility matrix in Oracle Database Backup and Recovery
Reference for descriptions of supported interoperability scenarios
13.1 Overview of the RMAN Recovery Catalog
This section explains the basic concepts related to managing a recovery catalog.
13.1.1 Purpose of the RMAN Recovery Catalog
A recovery catalog is a database schema used by RMAN to store metadata about one
or more Oracle databases. Typically, you store the catalog in a dedicated database.
A recovery catalog provides the following benefits:
•
A recovery catalog creates redundancy for the RMAN repository stored in the
control file of each target database. The recovery catalog serves as a secondary
metadata repository. If the target control file and all backups are lost, then the
RMAN metadata still exists in the recovery catalog.
13-1
Chapter 13
Overview of the RMAN Recovery Catalog
•
A recovery catalog centralizes metadata for all your target databases. Storing the
metadata in a single place makes reporting and administration tasks easier to
perform.
•
A recovery catalog can store metadata history much longer than the control file.
This capability is useful if you must do a recovery that goes further back in time
than the history in the control file. The added complexity of managing a recovery
catalog database can be offset by the convenience of having the extended backup
history available.
Some RMAN features function only when you use a recovery catalog. For example,
you can store RMAN scripts in a recovery catalog. The chief advantage of a stored
script is that it is available to any RMAN client that can connect to the target database
and recovery catalog. Command files are only available if the RMAN client has access
to the file system on which they are stored.
A recovery catalog is required when you use RMAN in a Data Guard environment. By
storing backup metadata for all primary and standby databases, the catalog enables
you to offload backup tasks to one standby database while enabling you to restore
backups on other databases in the environment.
13.1.2 Basic Concepts for the RMAN Recovery Catalog
The recovery catalog contains metadata about RMAN operations for each registered
target database. When RMAN is connected to a recovery catalog, RMAN obtains its
metadata exclusively from the catalog.
The catalog includes the following types of metadata:
•
Data file and archived redo log backup sets and backup pieces
•
Data file copies
•
Archived redo logs and their copies
•
Database structure (tablespaces and data files)
•
Stored scripts, which are named user-created sequences of RMAN commands
•
Persistent RMAN configuration settings
13.1.2.1 About Database Registration in an RMAN Recovery Catalog
The process of enrolling of a database in a recovery catalog for RMAN use is called
registration.
The recommended practice is to register every target database in your environment in
a single recovery catalog. For example, you can register databases prod1, prod2, and
prod3 in a single catalog owned by rco in the database catdb.
See Also:
Registering a Database in the Recovery Catalog
13-2
Chapter 13
Overview of the RMAN Recovery Catalog
13.1.2.2 About Centralization of Metadata in a Base RMAN Recovery Catalog
The owner of a centralized recovery catalog, which is also called the base recovery
catalog, can grant or revoke restricted access to the catalog to other database users.
Each restricted user has full read/write access to his own metadata, which is called a
virtual private catalog. The RMAN metadata is stored in the schema of the virtual
private catalog owner. The owner of the base recovery catalog determines which
objects each virtual private catalog user can access.
You can use a recovery catalog in an environment in which you use or have used
different versions of Oracle Database. As a result, your environment can have different
versions of the RMAN client, recovery catalog database, recovery catalog schema,
and target database. "Importing and Moving a Recovery Catalog" explains how to
merge multiple recovery catalog schemas into one.
See Also:
Creating and Managing Virtual Private Catalogs
13.1.2.3 About RMAN Recovery Catalog Resynchronization
For RMAN operations such as backup, restore, and crosscheck, RMAN always first
updates the control file and then propagates the metadata to the recovery catalog.
This flow of metadata from the mounted control file to the recovery catalog, which is
known as recovery catalog resynchronization, ensures that the metadata that RMAN
obtains from the control file is current.
See Also:
Resynchronizing the Recovery Catalog
13.1.2.4 About Stored Scripts
You can use a stored script as an alternative to a command file for managing
frequently used sequences of RMAN commands. The script is stored in the recovery
catalog rather than on the file system.
A local stored script is associated with the target database to which RMAN is
connected when the script is created, and can only be executed when you are
connected to this target database. A global stored script can be run against any
database registered in the recovery catalog. A virtual private catalog user has readonly access to global scripts. Creating or updating global scripts must be done while
connected to the base recovery catalog.
13-3
Chapter 13
Overview of the RMAN Recovery Catalog
See Also:
Managing Stored Scripts
13.1.2.5 Recovery Catalog in a Data Guard Environment
You must use a recovery catalog to manage RMAN metadata for all physical
databases, both primary and standby databases, in the Data Guard environment.
RMAN uses the recovery catalog as the single source of truth for the Data Guard
environment.
RMAN can use the recovery catalog to update a primary or standby control file in a
reverse resynchronization. In this case, the metadata flows from the catalog to the
control file rather than the other way around. RMAN automatically performs
resynchronizations in most situations in which they are needed. Thus, you do not need
to use the RESYNC command to manually resynchronize very often.
See Also:
•
About RMAN in a Data Guard Environment
•
Oracle Data Guard Concepts and Administration to learn how to
configure the RMAN environment for use with a standby database
13.1.3 Basic Steps of Managing a Recovery Catalog
Managing a recovery catalog consists of creating the catalog and then registering your
target databases with the catalog.
The basic steps for setting up a recovery catalog for use by RMAN are as follows:
1.
Create the recovery catalog.
"Creating a Recovery Catalog" explains how to perform this task.
2.
Register your target databases in the recovery catalog.
This step enables RMAN to store metadata for the target databases in the
recovery catalog. "Registering a Database in the Recovery Catalog" explains this
task.
3.
If needed, catalog any older backups whose records are no longer stored in the
target control file.
"Cataloging Backups in the Recovery Catalog" explains how to perform this task.
4.
If needed, create virtual private catalogs for specific users and determine the
metadata to which they are permitted access.
"Creating and Managing Virtual Private Catalogs" explains how to perform this
task.
5.
Protect the recovery catalog by including it in your backup and recovery strategy.
13-4
Chapter 13
Creating a Recovery Catalog
"Protecting the Recovery Catalog" explains how to back up and recover the
catalog, and increase its availability.
See Also:
•
"Managing Stored Scripts" for information about how to store RMAN
scripts in the recovery catalog and manage them
•
"Reporting on RMAN Operations" explains how to report on RMAN
operations
•
"Maintaining a Recovery Catalog" describes a variety of tasks for
ongoing recovery catalog maintenance, including how to import one
recovery catalog into another recovery catalog
•
"Dropping a Recovery Catalog" for information about deleting a recovery
catalog
13.2 Creating a Recovery Catalog
Creating a recovery catalog consists of multiple phases that includes configuring the
recovery catalog database, creating the recovery catalog schema owner, and then
creating the catalog.
To create a recovery catalog:
1.
Configure the database that contains the recovery catalog, as described in
"Configuring the Recovery Catalog Database".
2.
Create the database user that owns the recovery catalog, as described in
"Creating the Recovery Catalog Schema Owner".
3.
Create the recovery catalog, as described in "Executing the CREATE CATALOG
Command".
13.2.1 Configuring the Recovery Catalog Database
When you use a recovery catalog, RMAN requires that you maintain a recovery
catalog schema. The recovery catalog is stored in the default tablespace of the
schema. Privileged users such as SYS cannot be the owner of the recovery catalog.
Decide which database you will use to install the recovery catalog schema, and also
how you will back up this database. Also, decide whether to operate the catalog
database in ARCHIVELOG mode, which is recommended.
Note:
Do not use the target database to be backed up as the database for the
recovery catalog. The recovery catalog must be protected if the target
database is lost.
13-5
Chapter 13
Creating a Recovery Catalog
13.2.1.1 Planning the Size of the Recovery Catalog Schema
You must allocate space to be used by the catalog schema. The size of the recovery
catalog schema depends upon the number of databases monitored by the catalog.
The schema also grows as the number of archived redo log files and backups for each
database increases. Finally, if you use RMAN stored scripts stored in the catalog,
some space must be allocated for those scripts.
For example, assume that the trgt database has 100 files, and that you back up the
database once a day, producing 50 backup sets containing 1 backup piece each. If
you assume that each row in the backup piece table uses the maximum amount of
space, then one daily backup consumes less than 170 kilobytes in the recovery
catalog. So, if you back up once a day for a year, then the total storage in this period is
about 62 megabytes. Assume approximately the same amount for archived logs.
Thus, the worst case is about 120 megabytes for a year for metadata storage. For a
more typical case in which only a portion of the backup piece row space is used, 15
MB for each year is realistic.
If you plan to register multiple databases in your recovery catalog, then remember to
add up the space required for each one based on the previous calculation to arrive at
a total size for the default tablespace of the recovery catalog schema.
13.2.1.2 Allocating Disk Space for the Recovery Catalog Database
If you are creating your recovery catalog in an existing database, then add enough
room to hold the default tablespace for the recovery catalog schema.
If you are creating a new database to hold your recovery catalog, then in addition to
the space for the recovery catalog schema itself, allow space for other files in the
recovery catalog database:
•
SYSTEM and SYSAUX tablespaces
•
Temporary tablespaces
•
Undo tablespaces
•
Online redo log files
Most of the space used in the recovery catalog database is devoted to supporting
tablespaces, for example, the SYSTEM, temporary, and undo tablespaces. Table 13-1
describes typical space requirements.
Table 13-1
Typical Recovery Catalog Space Requirements for 1 Year
Type of Space
Space Requirement
SYSTEM tablespace
90 MB
Temp tablespace
5 MB
Rollback or undo tablespace
5 MB
Recovery catalog tablespace
15 MB for each database registered in the recovery catalog
Online redo logs
1 MB each (three groups, each with two members)
13-6
Chapter 13
Creating a Recovery Catalog
Caution:
Ensure that the recovery catalog and target databases do not reside on the
same disk. If both your recovery catalog and your target database suffer hard
disk failure, then your recovery process is much more difficult. If possible,
take other measures as well to eliminate common points of failure between
your recovery catalog database and the databases that you are backing up.
13.2.2 Creating the Recovery Catalog Schema Owner
After choosing the recovery catalog database and creating the necessary space, you
are ready to create the owner of the recovery catalog and grant this user necessary
privileges.
Assume the following background information for the instructions in the following
sections:
•
A tablespace called TOOLS in the recovery catalog database CATDB stores the
recovery catalog. If you use an RMAN reserved word as a tablespace name, you
must enclose it in quotes and put it in uppercase.
•
A tablespace called TEMP exists in the recovery catalog database.
To create the recovery catalog schema in the recovery catalog database:
1.
Start SQL*Plus and connect with administrator privileges to the database
containing the recovery catalog. In this example, the database is catdb.
2.
Create a user and schema for the recovery catalog. For example, you could enter
the following SQL statement (replacing password with a user-defined password):
CREATE USER rco IDENTIFIED BY password
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;
Note:
Create a password that is secure.
3.
Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the
user with all privileges required to maintain and query the recovery catalog.
GRANT RECOVERY_CATALOG_OWNER TO rco;
4.
(Optional) Enable the VPD model for the recovery catalog by running the
dbmsrmanvpc.sql script with the –vpd option.
The following command enables the VPD model for the recovery catalog owned
by the user rco:
SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;
13-7
Chapter 13
Creating a Recovery Catalog
See Also:
•
Oracle Database Backup and Recovery Reference for a list of RMAN
reserved words
•
Oracle Database Security Guide for information about creating secure
passwords
13.2.3 Executing the CREATE CATALOG Command
After creating the catalog owner, create the catalog tables with the RMAN CREATE
CATALOG command. The command creates the catalog in the default tablespace of the
catalog owner.
Note:
Starting with Oracle Database 12c Release 1 (12.1.0.2), the recovery catalog
database must use the Enterprise Edition of Oracle Database.
To create the recovery catalog:
1.
Enable Oracle Partitioning for the recovery catalog database.
2.
Start RMAN and connect to the database that will contain the catalog. Connect to
the database as the recovery catalog owner.
3.
Run the CREATE CATALOG command to create the catalog. The creation of the catalog
can take several minutes. If the catalog tablespace is this user's default
tablespace, then you can run the following command:
RMAN> CREATE CATALOG;
You can specify the tablespace name for the catalog in the CREATE CATALOG
command. For example:
RMAN> CREATE CATALOG TABLESPACE cat_tbs;
Note:
If the tablespace name for the recovery catalog is an RMAN reserved
word, then it must be uppercase and enclosed in quotes. For example:
CREATE CATALOG TABLESPACE 'CATALOG';
4.
You can check the results by using SQL*Plus to query the recovery catalog to see
which tables were created:
SQL> SELECT TABLE_NAME FROM USER_TABLES;
13-8
Chapter 13
Registering a Database in the Recovery Catalog
See Also:
•
GRANT command syntax in Oracle Database SQL Language Reference
•
CREATE USER command syntax in Oracle Database SQL Language
Reference
•
Oracle Database Backup and Recovery Reference for CREATE CATALOG
command syntax
13.3 Registering a Database in the Recovery Catalog
Registering a target database in the recovery catalog maintains the database’s
records in the recovery catalog.
13.3.1 About Registration of a Database in the Recovery Catalog
The process of enrolling of a target database in a recovery catalog is called
registration.
If a target database is not registered in the recovery catalog, then RMAN cannot use
the catalog to store metadata for operations on this database. You can still perform
RMAN operations on an unregistered database: RMAN always stores its metadata in
the control file of the target database.
If you are not using the recovery catalog in a Data Guard environment, then use the
REGISTER command to register each database. Each database must have a unique
DBID. If you use the RMAN DUPLICATE command or the CREATE DATABASE statement in
SQL, then the database is assigned a unique DBID automatically. If you create a
database by other means, then the copied database may have the same DBID as its
source database. You can change the DBID with the DBNEWID utility so that you can
register the source and copy databases in the same catalog.
You can use the UNREGISTER command to unregister a database from the recovery
catalog.
13.3.1.1 About Standby Database Registration
In a Data Guard environment, the primary and standby databases share the same
DBID and database name. To be eligible for registration in the recovery catalog, each
database in the Data Guard environment must have different DB_UNIQUE_NAME values.
The DB_UNIQUE_NAME parameter for a database is set in its initialization parameter file. If
you use RMAN in a Data Guard environment, then you can use the REGISTER DATABASE
command only for the primary database.
You can use the following techniques to register a standby database in the recovery
catalog:
•
When you connect to a standby database as TARGET, RMAN automatically registers
the database in the recovery catalog.
13-9
Chapter 13
Registering a Database in the Recovery Catalog
•
When you run the CONFIGURE DB_UNIQUE_NAME command for a standby database that
is not known to the recovery catalog, RMAN automatically registers this standby
database if its primary database is registered.
See Also:
•
Unregistering a Target Database from the Recovery Catalog
•
Oracle Database Backup and Recovery Reference for DUPLICATE
command syntax
•
Oracle Database Utilitiesto learn how to use the DBNEWID utility to change
the DBID
•
Oracle Data Guard Concepts and Administration to learn about using
RMAN in a Data Guard environment
13.3.2 Registering a Database with the REGISTER DATABASE
Command
The first step in using a recovery catalog with a target database is registering the
target database in the recovery catalog. If you use the catalog in a Data Guard
environment, then you can only register the primary database in this way.
Use the following procedure:
1.
Start RMAN and connect to a target database and recovery catalog. The recovery
catalog database must be open.
For example, issue the following command to connect to the catalog database with
the net service name catdb as user rco (who owns the catalog schema):
% rman TARGET / CATALOG rco@catdb;
2.
If the target database is not mounted, then mount or open it:
STARTUP MOUNT;
3.
Register the target database in the connected recovery catalog:
REGISTER DATABASE;
RMAN creates rows in the catalog tables to contain information about the target
database, then copies all pertinent data about the target database from the control
file into the catalog, synchronizing the catalog with the control file.
4.
Verify that the registration was successful by running REPORT SCHEMA:
REPORT SCHEMA;
Report of database schema for database with db_unique_name TRGT
List of Permanent Datafiles===========================
File Size(MB) Tablespace
RB segs Datafile Name
---- ---------- ---------------- ------- ------------------1
307200 SYSTEM
NO
/oracle/oradata/trgt/system01.dbf
2
20480 UNDOTBS
YES /oracle/oradata/trgt/undotbs01.dbf
3
10240 CWMLITE
NO
/oracle/oradata/trgt/cwmlite01.dbf
13-10
Chapter 13
Cataloging Backups in the Recovery Catalog
4
5
6
7
8
10240
10240
10240
10240
10240
DRSYS
EXAMPLE
INDX
TOOLS
USERS
NO
NO
NO
NO
NO
/oracle/oradata/trgt/drsys01.dbf
/oracle/oradata/trgt/example01.dbf
/oracle/oradata/trgt/indx01.dbf
/oracle/oradata/trgt/tools01.dbf
/oracle/oradata/trgt/users01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace
Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- -------------------1
200
TEMP
32767
/oracle/oradata/trgt/tbs_tmp.dbf
13.4 Cataloging Backups in the Recovery Catalog
If you have data file copies, backup pieces, or archived logs on disk, then you can
catalog them in the recovery catalog with the CATALOG command. When using a
recovery catalog, cataloging older backups that have aged out of the control file lets
RMAN use the older backups during restore operations.
The following commands illustrate this technique:
CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
You can also catalog multiple backup files in a directory by using the CATALOG START
WITH command, as shown in the following example:
CATALOG START WITH '/disk1/backups/';
RMAN lists the files to be added to the RMAN repository and prompts for confirmation
before adding the backups. Be careful when creating your prefix with CATALOG START
WITH. RMAN scans all paths for all files on disk that begin with the specified prefix. The
prefix is not just a directory name. Using the wrong prefix can cause the cataloging of
the wrong set of files.
For example, assume that a group of directories /disk1/backups, /disk1/
backups-year2003, /disk1/backupsets, /disk1/backupsets/test and so
on, all contain backup files. The following command catalogs all files in all of these
directories, because /disk1/backups is a prefix for the paths for all of these
directories:
CATALOG START WITH '/disk1/backups';
To catalog only backups in the /disk1/backups directory, the correct command is as
follows:
CATALOG START WITH '/disk1/backups/';
See Also:
•
Oracle Database Backup and Recovery Reference for REGISTER syntax
•
Oracle Database Upgrade Guide for issues relating to database
migration
13-11
Chapter 13
Creating and Managing Virtual Private Catalogs
13.5 Creating and Managing Virtual Private Catalogs
RMAN provides multiple commands to create and manage virtual private catalogs.
13.5.1 Overview of Virtual Private Catalogs
By default, all of the users of an RMAN recovery catalog have full privileges to read,
select, insert, update, and delete any metadata in the catalog. For example, if the
administrators of two unrelated databases share the same recovery catalog, each
administrator could, whether inadvertently or maliciously, destroy catalog data for the
other's database. In many enterprises, this situation is tolerated because the same
people manage many different databases and also manage the recovery catalog. But
in other enterprises where clear separation of duty exists between administrators of
various databases, and between the DBA and the administrator of the recovery
catalog, you may desire to restrict each database administrator to modify only backup
metadata belonging to those databases that they are responsible for, while still
keeping the benefits of a single, centrally-managed, RMAN recovery catalog. This goal
can be achieved by implementing virtual private catalogs.
Every RMAN recovery catalog starting with Oracle Database 11g supports virtual
private catalogs, but they are not used unless explicitly created. There is no restriction
on the number of virtual private catalogs that can be created beneath one recovery
catalog. Each virtual private catalog is owned by a database schema user which is
different than the user who owns the recovery catalog.
After you set up a virtual private catalog user, the administrator for the recovery
catalog grants each virtual private catalog the privilege to use that catalog for one or
more databases that are currently registered in the recovery catalog. The administrator
of the recovery catalog can also grant the privilege to register new databases while
using a virtual private catalog.
Note:
Every virtual private catalog has access to all global stored scripts, and those
non-global stored scripts that belong to those databases for which this virtual
private catalog has privileges. Virtual private catalogs cannot access nonglobal stored scripts that belong to databases that they do not have
privileges for, and they cannot create global stored scripts.
13.5.2 About Using the VPD Model for Virtual Private Catalogs
RMAN uses the Virtual Private Database (VPD) functionality to implement virtual
private catalogs.
The VPD functionality is not enabled by default when the RMAN base recovery catalog
is created. You need to explicitly enable the VPD model for a base recovery catalog by
running the $ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql script after
upgrading the base catalog schema.
The format of the dbmsrmanvpc.sql script is as follows:
13-12
Chapter 13
Creating and Managing Virtual Private Catalogs
$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql [[-vpd | -novpd | -scan ]
base_catalog_schema_name[...]] | -all
The RMAN base catalog schema names are provided as command-line parameters
when running dbmsrmanvpc.sql. You can specify a maximum of ten base catalog
schema names each time you run the script.
Table 13-2 describes the options that you can use when running the dbmsrmanvpc.sql
script. You must use one of the command line options or provide a catalog schema
name.
Table 13-2
dbmsrmanvpc.sql Options
dbmsrmanvpc.sql
Option Name
Description
-vpd
Grants the privileges required to support the VPD protected catalog.
-novpd
Disables VPD functionality by cleaning up the base recovery catalog
schema, revoking grants, and removing database objects.
This option can only be used when there are no existing VPC users
registered in the base recovery catalog.
-scan
Performs a scan of the RMAN base catalog owner schemas and
reports on the roles granted and the status of VPC users.
-all
Automatically detects the RMAN base catalog schemas and upgrades.
Example 13-1
Enabling VPD Model for VPC User Schemas
Connect to SQL*Plus and use the following command to enable the VPD model for all
the virtual private catalogs of the RMAN base catalog rman_cat.
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rman_cat
13.5.3 Creating Virtual Private Catalogs
Creating a virtual private catalog is a multi-step process in which you first create the
database user who will own the virtual private catalog and then create the virtual
private catalog.
Note:
If the recovery catalog is a virtual private catalog, then the RMAN client
connecting to it must be at patch level 10.1.0.6 or 10.2.0.3. Oracle9i RMAN
clients cannot connect to a virtual private catalog. This version restriction
does not affect RMAN client connections to an Oracle Database 11g base
recovery catalog, even if it has some virtual private catalog users.
Assume that the following databases are registered in the base recovery catalog:
prod1, prod2, and prod3. The database user who owns the base recovery catalog is rco.
You want to create database user vpc1 and grant this user access privileges only to
prod1 and prod2. By default, a virtual private catalog owner has no access to the base
recovery catalog.
13-13
Chapter 13
Creating and Managing Virtual Private Catalogs
The base RMAN recovery catalog must be created before you create virtual private
catalogs.
To create a virtual private catalog:
1.
Start SQL*Plus and connect to the recovery catalog database with administrator
privileges.
2.
Create the user who will own the virtual private catalog.
For example, if you want database user vpc1 to own the virtual private catalog,
then execute the following command (replacing password with a user-defined
password):
SQL> CREATE USER vpc1 IDENTIFIED BY password
2 DEFAULT TABLESPACE vpcusers
3 QUOTA UNLIMITED ON vpcusers;
Note:
Create a password that is secure. See Oracle Database Security Guide
for more information.
3.
Grant the CREATE SESSION privilege to the user who owns the virtual private catalog
and then exit SQL*Plus.
The following example grants the privilege to user vpc1:
SQL> GRANT CREATE SESSION TO vpc1;
SQL> EXIT;
4.
Start RMAN and connect to the recovery catalog database as the base recovery
catalog owner (not the virtual private catalog owner).
The following example connects to the base recovery catalog as rco:
% rman
RMAN> CONNECT CATALOG rco@catdb;
recovery catalog database Password: password
connected to recovery catalog database
5.
Grant desired privileges to the virtual private catalog owner.
The following example gives user vpc1 access to the metadata for prod1 and prod2
(but not prod3):
RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1;
RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;
You can also use a DBID rather than a database name. The virtual private catalog
user does not have access to the metadata for any other databases registered in
the recovery catalog.
You can also grant the user the ability to register new target databases in the
recovery catalog. For example:
RMAN> GRANT REGISTER DATABASE TO vpc1;
13-14
Chapter 13
Creating and Managing Virtual Private Catalogs
See Also:
Oracle Database Backup and Recovery Reference for details about RMAN
version compatibility
13.5.4 Registering a Database with a Virtual Private Catalog
To store backup metadata for a target database in a virtual private catalog, you must
register the database with the virtual private catalog.
Create the virtual private catalog before you register a target database with it.
To register database with a virtual private catalog and store backup metadata:
1.
Start RMAN and connect to the recovery catalog database as the virtual private
catalog owner (not the base recovery catalog owner). Connect to the database
that you want to register as TARGET.
%rman
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG vpc1@catdb;
2.
Register the database whose metadata must be stored in the virtual private
catalog.
The following example registers the database with the virtual private catalog owner
vpc1.
RMAN> REGISTER DATABASE;
3.
Back up the database using the BACKUP command with the required clauses.
Metadata related to the backup is stored in the virtual private catalog.
13.5.5 Revoking Privileges from a Virtual Private Catalog Owner
After you create a virtual private catalog, you can revoke catalog access privileges as
necessary.
Assume that two databases are registered in the base recovery catalog: prod1 and
prod2. As owner of the base recovery catalog, you have granted the vpc1 user access
privileges to prod1. You have also granted this user the right to register databases in
his virtual private catalog. Now you want to revoke privileges from vpc1.
To revoke privileges from a virtual private catalog owner:
1.
Start RMAN and connect to the recovery catalog database as the recovery catalog
owner (not the virtual private catalog owner).
The following example connects to the recovery catalog as rco:
% rman
RMAN> CONNECT CATALOG rco@catdb;
2.
Revoke specified privileges from the virtual private catalog owner.
The following command revokes access to the metadata for prod1 from virtual
private catalog owner vpc1:
13-15
Chapter 13
Creating and Managing Virtual Private Catalogs
REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
You can also specify a DBID rather than a database name. The catalog vpc1
retains all other granted catalog privileges.
You can also revoke the privilege to register new target databases in the recovery
catalog. For example:
REVOKE REGISTER DATABASE FROM vpc1;
13.5.6 Upgrading Virtual Private Catalogs
This section describes how to use the UPGRADE CATALOG command to upgrade a virtual
private catalog.
RMAN uses the Virtual Private Database (VPD) functionality to implement virtual
private catalogs. If you created a recovery catalog and virtual private catalogs by using
a version lower than Oracle Database 12c Release 1 (12.1.0.2) or if your database is
not upgraded to Oracle Database 12c Release 2 (12.2) or higher, then you must
upgrade these virtual private catalogs. RMAN provides scripts, located in
the $ORACLE_HOME/rdbms/admin directory, to upgrade virtual private catalogs.
To upgrade virtual private catalogs:
1.
Use SQL*Plus to connect to the recovery catalog database as the SYS user with
SYSDBA privilege.
2.
Run the dbmsrmansys.sql script to grant additional privileges that are required for
the RECOVERY_CATALOG_OWNER role.
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
3.
Run the dbmsmanvpc.sql script to upgrade virtual private catalog schemas to the
VPD model.
The base recovery catalog schema name must be provided as an input parameter
to this script. You can specify a maximum of 10 schema names. Alternately, you
can use the -all option to automatically detect base catalog schemas and
upgrade all associated virtual private catalog schemas.
The following command upgrades the virtual private catalog schemas of the base
recovery catalog owned by rco:
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco
4.
Connect RMAN to the base recovery catalog, upgrade the base recovery catalog,
and then exit RMAN.
Assume that the database user who owns the base recovery catalog is rco. The
following command upgrades the base recovery catalog. The UPGRADE CATALOG
command must be entered twice to confirm the upgrade.
$ rman CATALOG rco@catdb
recovery catalog database password:
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
13-16
Chapter 13
Protecting the Recovery Catalog
See Also:
"About Using the VPD Model for Virtual Private Catalogs" for information
about the dbmsrmanvpc.sql script and its options
13.6 Protecting the Recovery Catalog
Include the recovery catalog database in your backup and recovery strategy. If you do
not back up the recovery catalog and a disk failure occurs that destroys the recovery
catalog database, then you may lose the metadata in the catalog. Without the recovery
catalog contents, recovery of your other databases is likely to be more difficult.
13.6.1 Backing Up the Recovery Catalog
A single recovery catalog can store metadata for multiple target databases.
Consequently, loss of the recovery catalog can be disastrous. You must back up the
recovery catalog frequently.
This section provides general guidelines for developing a strategy for protecting the
recovery catalog.
13.6.1.1 Backing Up the Recovery Catalog Frequently
The recovery catalog database is a database like any other, and is also a key part of
your backup and recovery strategy. Protect the recovery catalog like any other part of
your database, by backing it up. The backup strategy for your recovery catalog
database is part of an overall backup and recovery strategy.
Back up the recovery catalog with the same frequency that you back up a target
database. For example, if you make a weekly whole database backup of a target
database, then back up the recovery catalog after the backup of the target database.
This backup of the recovery catalog can help you in a disaster recovery scenario.
Even if you must restore the recovery catalog database with a control file autobackup,
you can use the full record of backups in your restored recovery catalog database to
restore the target database.
13.6.1.2 Choosing the Appropriate Technique for Physical Backups
When backing up the recovery catalog database, you can use RMAN to make the
backups.
As illustrated in Figure 13-1, start RMAN with the NOCATALOG option so that the
repository for RMAN is the control file in the catalog database.
13-17
Chapter 13
Protecting the Recovery Catalog
Figure 13-1 Using the Control File as the Repository for Backups of the
Recovery Catalog
Back up using
RMAN
Target
database
Store metadata about
backups of target
Catalog
database
catalog
Store metadata
about backups
of catalog
Control
file
Back up
using RMAN
Control file
autobackup
Follow these guidelines when developing an RMAN backup strategy for the recovery
catalog database:
•
Run the recovery catalog database in ARCHIVELOG mode so that you can do pointin-time recovery if needed.
•
Set the retention policy to a REDUNDANCY value greater than 1.
•
Back up the database to two separate media (for example, disk and tape).
•
Run BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if
available, or just to disk.
•
Do not use another recovery catalog as the repository for the backups.
•
Configure the control file autobackup feature to ON.
With this strategy, the control file autobackup feature ensures that the recovery catalog
database can always be recovered, so long as the control file autobackup is available.
See Also:
Performing Disaster Recovery for more information for recovery with a
control file autobackup
13.6.1.3 Separating the Recovery Catalog from the Target Database
A recovery catalog is only effective when separated from the data that it is designed to
protect. Thus, you must never store a recovery catalog containing the RMAN
13-18
Chapter 13
Protecting the Recovery Catalog
repository for a database in the same database as the target database. Also, do not
store the catalog database on the same disks as the target database.
To illustrate why data separation is advised, assume that you store the catalog for
database prod1 in prod1. If prod1 suffers a total media failure, and if the recovery
catalog for prod1 is also stored in prod1, then if you lose the database you also lose the
recovery catalog. At this point the only option is to restore an autobackup of the control
file for prod1 and use it to restore and recover the database without the benefit of any
information stored in the recovery catalog.
13.6.1.4 Exporting the Recovery Catalog Data for Logical Backups
Logical backups of the RMAN recovery catalog created with the Data Pump Export
utility can be a useful supplement for physical backups.
For damage to a recovery catalog database, you can use Data Pump Import to quickly
reimport the exported recovery catalog data into another database and rebuild the
catalog.
13.6.2 Recovering the Recovery Catalog
Restoring and recovering the recovery catalog database is much like restoring and
recovering any other database with RMAN.
You can restore the control file and server parameter file for the recovery catalog
database from an autobackup, then restore and perform complete recovery on the rest
of the database. If you are in a situation where you are using multiple recovery
catalogs, then you can also use another recovery catalog to record metadata about
backups of this recovery catalog database.
If recovery of the recovery catalog database through the normal Oracle recovery
procedures is not possible, then you must re-create the catalog. Examples of this
worst-case scenario include:
•
A recovery catalog database that has never been backed up
•
A recovery catalog database that has been backed up, but cannot be recovered
because the data file backups or archived logs are not available
You have the following options for partially re-creating the contents of the missing
recovery catalog:
•
Use the RESYNC CATALOG command to update the recovery catalog with any RMAN
repository information from the control file of the target database or a control file
copy. Any metadata from control file records that aged out of the control file is lost.
•
Issue CATALOG START WITH commands to recatalog any available backups.
To minimize the likelihood of this worst-case scenario, your backup strategy must at
least include backing up the recovery catalog. This technique is described in "Backing
Up the Recovery Catalog".
13-19
Chapter 13
Managing Stored Scripts
See Also:
•
Oracle Database Backup and Recovery Reference for information about
the CATALOG command
•
Oracle Database Backup and Recovery Reference for information about
the CROSSCHECK command
13.7 Managing Stored Scripts
You can create and store scripts in the recovery catalog.
See Also:
About Stored Scripts
13.7.1 About Stored Scripts
You can use a stored script as an alternative to a command file for managing
frequently used sequences of RMAN commands. The script is stored in the recovery
catalog rather than on the file system.
Stored scripts can be local or global. A local script is associated with the target
database to which RMAN is connected when the script is created, and can only be
executed when you are connected to that target database. A global stored script can
be run against any database registered in the recovery catalog, if the RMAN client is
connected to the recovery catalog and a target database.
The commands allowable within the brackets of the CREATE SCRIPT command are the
same commands supported within a RUN block. Any command that is legal within a RUN
command is permitted in the stored script. The following commands are not legal
within stored scripts: RUN, @, and @@.
When specifying a script name, RMAN permits but generally does not require that you
use quotes around the name of a stored script. If the name begins with a digit or is an
RMAN reserved word, however, then you must put quotes around the name to use it
as a stored script name. Consider avoiding stored script names that begin with
nonalphabetic characters or that are the same as RMAN reserved words.
Consider using a naming convention to avoid confusion between global and local
stored scripts. For the EXECUTE SCRIPT, DELETE SCRIPT and PRINT SCRIPT commands, if
the script name passed as an argument is not the name of a script defined for the
connected target instance, then RMAN looks for a global script by the same name. For
example, if the global script global_backup is in the recovery catalog, but no local
stored script global_backup is defined for the target database, then the following
command deletes the global script:
DELETE SCRIPT global_backup;
To use commands related to stored scripts, even global scripts, you must be
connected to both a recovery catalog and a target database instance.
13-20
Chapter 13
Managing Stored Scripts
13.7.2 Creating Stored Scripts
You can use the CREATE SCRIPT command to create a stored script.
If GLOBAL is specified, then a global script with this name must not exist in the recovery
catalog. If GLOBAL is not specified, then a local script must not exist with the same name
for the same target database. You can also use the REPLACE SCRIPT to create a new
script or update an existing script.
To create a stored script:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
See Also:
Making Database Connections with RMAN
2.
Run the CREATE SCRIPT command.
The following example illustrates creation of a local script:
CREATE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
For a global script, the syntax is similar:
CREATE GLOBAL SCRIPT global_full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
Optionally, you can provide a COMMENT with descriptive information:
CREATE GLOBAL SCRIPT global_full_backup
COMMENT 'use only with ARCHIVELOG mode databases'
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
You can also create a script by reading its contents from a text file. The file must
begin with a left brace ({) character, contain a series of commands valid within a
RUN block, and end with a right brace (}) character. Otherwise, a syntax error is
signalled, just as if the commands were entered at the keyboard.
CREATE SCRIPT full_backup
FROM FILE '/tmp/my_script_file.txt';
3.
Examine the output.
If no errors are displayed, then RMAN successfully created the script and stored in
the recovery catalog.
13-21
Chapter 13
Managing Stored Scripts
See Also:
Oracle Database Backup and Recovery Reference for the list of RMAN
reserved words
13.7.3 Replacing Stored Scripts
To update stored scripts, use the REPLACE SCRIPT command.
If you are replacing a local script, then you must be connected to the target database
that you connected to when you created the script. If the script does not exist, then
RMAN creates it.
To replace a stored script:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Execute REPLACE SCRIPT.
This following example updates the script full_backup with new contents:
REPLACE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
You can update global scripts by specifying the GLOBAL keyword as follows:
REPLACE GLOBAL SCRIPT global_full_backup
COMMENT 'A script for full backup to be used with any database'
{
BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
}
As with CREATE SCRIPT, you can update a local or global stored script from a text file
with the following form of the command:
REPLACE GLOBAL SCRIPT global_full_backup
FROM FILE '/tmp/my_script_file.txt';
See Also:
Oracle Database Backup and Recovery Reference for REPLACE SCRIPT
command syntax
13.7.4 Executing Stored Scripts
Use the EXECUTE SCRIPT command to run a stored script.
If GLOBAL is specified, then a global script with this name must exist in the recovery
catalog; otherwise, RMAN returns error RMAN-06004. If GLOBAL is not specified, then
RMAN searches for a local stored script defined for the current target database. If no
13-22
Chapter 13
Managing Stored Scripts
local script with this name is found, then RMAN searches for a global script by the
same name and executes it if one is found.
To execute a stored script:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
If needed, use SHOW to examine your configured channels.
Your script uses the automatic channels configured at the time you execute the
script. Use ALLOCATE CHANNEL commands in the script if you must override the
configured channels. Because of the RUN block, if an RMAN command in the script
fails, subsequent RMAN commands in the script do not execute.
3.
Run EXECUTE SCRIPT . This command requires a RUN block, as shown in the
following example:
RUN
{
EXECUTE SCRIPT full_backup;
}
The preceding command invokes a local script if one exists with the name
specified. If no local script is found, but there is a global script with the name
specified, then RMAN executes the global script.
You can also use EXECUTE GLOBAL SCRIPT to control which script is invoked if a local
and a global script have the same name. If there is no local script called
global_full_backup, the following two commands have the same effect:
RUN
{
EXECUTE GLOBAL SCRIPT global_full_backup;
}
RUN
{
EXECUTE SCRIPT global_full_backup;
}
See Also:
Oracle Database Backup and Recovery Reference for EXECUTE SCRIPT
command syntax
13.7.5 Creating and Executing Dynamic Stored Scripts
You can specify substitution variables in the CREATE SCRIPT command.
When you start RMAN on the command line, the USING clause specifies one or more
values for use in substitution variables in a command file. As in SQL*Plus, &1 indicates
where to place the first value, &2 indicates where to place the second value, and so on.
To create and use a dynamic stored script:
1.
Create a command file that contains a CREATE SCRIPT statement with substitution
variables for values that must be dynamically updated.
13-23
Chapter 13
Managing Stored Scripts
The following example uses substitution variables for the name of the tape set, for
a string in the FORMAT specification, and for the name of the restore point.
CREATE SCRIPT quarterly {
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3
DATABASE;
}
2.
Connect RMAN to a target database (which must be mounted or open) and
recovery catalog, specifying the initial values for the recovery catalog script.
For example, enter the following command:
% rman TARGET / CATALOG rco@catdb USING arc_backup bck0906 FY06Q3
A recovery catalog is required for KEEP FOREVER, but is not required for any other
KEEP option.
3.
Run the command file created in the first step to create the stored script.
For example, run the /tmp/catscript.rman command file as follows:
RMAN> @/tmp/catscript.rman
This step creates but does not execute the stored script.
4.
Every quarter, execute the stored script, passing values for the substitution
variables.
The following example executes the recovery catalog script named quarterly. The
example specifies arc_backup as the name of the media family (set of tapes),
bck1206 as part of the FORMAT string and FY06Q4 as the name of the restore point.
RUN
{
EXECUTE SCRIPT quarterly
USING arc_backup
bck1206
FY06Q4;
}
See Also:
Making Database Backups for Long-Term Storage
13.7.6 Printing Stored Scripts
The PRINT SCRIPT command displays a stored script or writes it out to a file.
To print stored scripts:
1.
Start RMAN and connect to a target database and recovery catalog.
13-24
Chapter 13
Managing Stored Scripts
2.
Run the PRINT SCRIPT command as follows:
PRINT SCRIPT full_backup;
To send the contents of a script to a file, use this form of the command:
PRINT SCRIPT full_backup
TO FILE '/tmp/my_script_file.txt';
For global scripts, the analogous syntax is as follows:
PRINT GLOBAL SCRIPT global_full_backup;
PRINT GLOBAL SCRIPT global_full_backup
TO FILE '/tmp/my_script_file.txt';
See Also:
Oracle Database Backup and Recovery Reference for PRINT
SCRIPTcommand syntax
13.7.7 Listing Stored Script Names
Use the LIST ... SCRIPT NAMES command to display the names of scripts defined in the
recovery catalog.
LIST GLOBAL SCRIPT NAMES and LIST ALL SCRIPT NAMES are the only commands that work
when RMAN is connected to a recovery catalog without connecting to a target
instance; the other forms of the LIST ... SCRIPT NAMES command require a recovery
catalog connection.
To list stored script names:
1.
Start RMAN and connect to a target database and recovery catalog.
2.
Run the LIST ... SCRIPT NAMES command.
For example, run the following command to list the names of all global and local
scripts that can be executed for the currently connected target database:
LIST SCRIPT NAMES;
The following example lists only global script names:
LIST GLOBAL SCRIPT NAMES;
To list the names of all scripts stored in the current recovery catalog, including
global scripts and local scripts for all target databases registered in the recovery
catalog, use the following form of the command:
LIST ALL SCRIPT NAMES;
For each script listed, the output indicates which target database the script is
defined for (or whether a script is global).
13-25
Chapter 13
Managing Stored Scripts
See Also:
Oracle Database Backup and Recovery Reference for LIST SCRIPT NAMES
command syntax and output format
13.7.8 Deleting Stored Scripts
Use the DELETE GLOBAL SCRIPT command to delete a stored script from the recovery
catalog.
To delete a stored script:
1.
Start RMAN and connect to a target database and recovery catalog.
2.
Enter the DELETE SCRIPT command.
If you use DELETE SCRIPT without GLOBAL, and there is no stored script for the target
database with the specified name, then RMAN looks for a global stored script by
the specified name and deletes the global script if it exists. For example, suppose
you enter the following command:
DELETE SCRIPT 'global_full_backup';
In this case, RMAN looks for a script global_full_backup defined for the connected
target database, and if it did not find one, it searches the global scripts for a script
called global_full_backup and delete that script.
To delete a global stored script, use DELETE GLOBAL SCRIPT:
DELETE GLOBAL SCRIPT 'global_full_backup';
See Also:
Oracle Database Backup and Recovery Reference for DELETE SCRIPT
command syntax
13.7.9 Executing a Stored Script at RMAN Startup
To run the RMAN client and start a stored script in the recovery catalog on startup, use
the SCRIPT argument when starting the RMAN client.
For example, you could enter the following command to execute script /tmp/
fbkp.cmd:
% rman TARGET / CATALOG rco@catdb SCRIPT '/tmp/fbkp.cmd';
You must connect to the recovery catalog, which contains the stored script, and the
target database, to which the script applies, when starting the RMAN client.
If local and global stored scripts are defined with the same name, then RMAN always
executes the local script.
13-26
Chapter 13
Maintaining a Recovery Catalog
See Also:
Oracle Database Backup and Recovery Reference for full RMAN client
command line syntax
13.8 Maintaining a Recovery Catalog
Maintaining the recovery catalog consists of tasks such as resynchronizing, updating,
and upgrading the recovery catalog.
This section describes various management and maintenance tasks.
13.8.1 About Recovery Catalog Maintenance
After you have created a recovery catalog and registered your target databases, you
must maintain this catalog.
For example, you must run the RMAN maintenance commands, which are explained
in " Maintaining RMAN Backups and Repository Records", to update backup records
and to delete backups that are no longer needed. You must perform this type of
maintenance regardless of whether you use RMAN with a recovery catalog. Other
types of maintenance, such as upgrading a recovery catalog schema, are specific to
use of RMAN with a recovery catalog.
If you use a recovery catalog in a Data Guard environment, then special
considerations apply for backups and database files recorded in the catalog. See
"About RMAN File Management in a Data Guard Environment" for an explanation of
when backups are accessible to RMAN and how RMAN maintenance commands work
with accessible backups.
13.8.2 Resynchronizing the Recovery Catalog
When RMAN performs a resynchronization, it compares the recovery catalog to either
the current or backup control file of the target database and updates the catalog with
metadata that is missing or changed.
Most RMAN commands perform a resynchronization automatically when the target
control file is mounted and the catalog is available. In a Data Guard environment,
RMAN can perform a reverse resynchronization to update a database control file with
metadata from the catalog.
13.8.2.1 About Resynchronization of the Recovery Catalog
Resynchronization of the recovery catalog ensures that the metadata that RMAN
obtains from the control file stays current. Resynchronizations can be full or partial.
In a partial resynchronization, RMAN reads the current control file of the target
database to update changed metadata about new backups, new archived redo logs,
and so on. RMAN does not resynchronize metadata about the database physical
schema.
In a full resynchronization, RMAN updates all changed records, including those for the
database schema. RMAN performs a full resynchronization after structural changes to
13-27
Chapter 13
Maintaining a Recovery Catalog
database (adding or dropping database files, creating new incarnation, and so on) or
after changes to the RMAN persistent configuration.
RMAN creates a snapshot control file, which is a temporary backup control file, when it
performs a full resynchronization. The database ensures that only one RMAN session
accesses a snapshot control file at any point in time. RMAN creates the snapshot
control file in an operating system-specific location on the target database host. You
can specify the name and location of the snapshot control file, as explained in
"Configuring the Snapshot Control File Location".
This snapshot control file ensures that RMAN has a consistent view of the control file.
Because the control file is intended for short-term use, it is not registered in the
catalog. RMAN records the control file checkpoint in the recovery catalog to indicate
the currency of the catalog.
See Also:
Oracle Database Backup and Recovery Reference for more information
about the RESYNC command
13.8.2.1.1 About RMAN Recovery Catalog Resynchronization in a Data Guard
Environment
RMAN only automatically resynchronizes the recovery catalog with a database when
connected to this database as TARGET. Thus, RMAN does not automatically
resynchronize every database in a Data Guard environment when connected as
TARGET to one database in the environment.
You can use the RESYNC CATALOG FROM DB_UNIQUE_NAME command to manually
resynchronize the recovery catalog with a database in the Data Guard environment.
For an example of a manual resynchronization, assume that RMAN is connected as
TARGET to production database prod, and that you have used CONFIGURE to create a
configuration for dgprod3. If you run RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3, then
RMAN resynchronizes the recovery catalog with the dgprod3 control file. In this case
RMAN performs both a normal resynchronization, in which metadata flows from the
dgprod3 control file to the catalog, and a reverse resynchronization. In a reverse
resynchronization, RMAN uses the persistent configurations in the recovery catalog to
update the dgprod3 control file.
See Also:
Oracle Data Guard Concepts and Administration
13.8.2.2 Deciding When to Resynchronize the Recovery Catalog
RMAN automatically resynchronizes the recovery catalog when RMAN is connected to
a target database and recovery catalog and you have executed RMAN commands.
Thus, you do not need to manually run the RESYNC CATALOG command very often. The
following sections describe situations requiring a manual catalog resynchronization:
13-28
Chapter 13
Maintaining a Recovery Catalog
•
Resynchronizing After the Recovery Catalog is Unavailable
•
Resynchronizing in ARCHIVELOG Mode When You Back Up Infrequently
•
Resynchronizing After Configuring a Standby Database
•
Resynchronizing the Recovery Catalog Before Control File Records Age Out
13.8.2.2.1 Resynchronizing After the Recovery Catalog is Unavailable
If the recovery catalog is unavailable when you issue RMAN commands that cause a
partial resynchronization, then open the catalog database later and resynchronize it
manually with the RESYNC CATALOG command.
For example, the target database may be in New York while the recovery catalog
database is in Japan. You may not want to make daily backups of the target database
in CATALOG mode, to avoid depending on the availability of a geographically distant
database. In such a case you could connect to the catalog as often as feasible and run
the RESYNC CATALOG command.
13.8.2.2.2 Resynchronizing in ARCHIVELOG Mode When You Back Up Infrequently
Assume that a target database runs in ARCHIVELOG mode. Also assume that you do the
following:
•
Back up the database infrequently (for example, hundreds of redo logs are
archived between database backups)
•
Generate a high number of log switches every day (for example, 1000 switches
between catalog resynchronizations)
In this case, you may want to manually resynchronize the recovery catalog regularly
because the recovery catalog is not updated automatically when a redo log switch
occurs or when a redo log is archived. The database stores metadata about redo log
switches and archived redo logs only in the control file. You must periodically
resynchronize to propagate this information into the recovery catalog.
How frequently you must resynchronize the recovery catalog depends on the rate at
which the database archives redo logs. The cost of the operation is proportional to the
number of records in the control file that have been inserted or changed since the
previous resynchronization. If no records have been inserted or changed, then the cost
of resynchronization is very low; if many records have been inserted or changed, then
the resynchronization is more time-consuming.
13.8.2.2.3 Resynchronizing After Configuring a Standby Database
You can create or change an RMAN configuration for a standby database even when
not connected to this database as TARGET.
You perform this task with the CONFIGURE DB_UNIQUE_NAME or CONFIGURE ... FOR
DB_UNIQUE_NAME command. As explained in "Manually Resynchronizing the Recovery
Catalog", you can resynchronize the standby database manually to update the control
file of the standby database.
13.8.2.2.4 Resynchronizing the Recovery Catalog Before Control File Records Age Out
Your goal is to ensure that the metadata in the recovery catalog is current. Because
the recovery catalog obtains its metadata from the target control file, the currency of
the data in the catalog depends on the currency of the data in the control file. You
13-29
Chapter 13
Maintaining a Recovery Catalog
must make sure that the backup metadata in the control file is recorded in the catalog
before it is overwritten with new records.
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum
number of days that records are retained in the control file before they are candidates
for being overwritten. Thus, you must ensure that you resynchronize the recovery
catalog with the control file records before these records are erased.
Perform either of the following actions at intervals less than the
CONTROL_FILE_RECORD_KEEP_TIME setting:
•
Make a backup, thereby performing an implicit resynchronization of the recovery
catalog
•
Manually resynchronize the recovery catalog with the RESYNC CATALOG command
Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between
backups or resynchronizations. Otherwise, control file records could be reused before
they are propagated to the recovery catalog. An extra week is a safe margin in most
circumstances.
Caution:
Never set CONTROL_FILE_RECORD_KEEP_TIME to 0. If you do, then backup records
may be overwritten in the control file before RMAN can add them to the
catalog.
One problem can arise if the control file becomes too large. The size of the target
database control file grows depending on the number of:
•
Backups that you perform
•
Archived redo logs that the database generates
•
Days that this information is stored in the control file
If the control file grows so large that it can no longer expand because it has reached
either the maximum number of blocks or the maximum number of records, then the
database may overwrite the oldest records even if their age is less than the
CONTROL_FILE_RECORD_KEEP_TIME setting. In this case, the database writes a message to
the alert log. If you discover that this situation occurs frequently, then reducing the
value of CONTROL_FILE_RECORD_KEEP_TIME and increase the frequency of
resynchronizations.
See Also:
•
Oracle Database Reference for more information about the
CONTROL_FILE_RECORD_KEEP_TIME parameter
•
Oracle Database Administrator’s Guide for more detailed information on
other aspects of control file management
•
Preventing the Loss of Control File Records to learn how to monitor the
overwriting of control file records
13-30
Chapter 13
Maintaining a Recovery Catalog
13.8.2.3 Manually Resynchronizing the Recovery Catalog
Use RESYNC CATALOG to force a full resynchronization of the recovery catalog with a
target database control file.
You can specify a database unique name with RESYNC CATALOG FROM DB_UNIQUE_NAME or
ALL, depending on whether you want to resynchronize a specific database or all
databases in the Data Guard environment. To use DB_UNIQUE_NAME ALL, you must
connect to the target database using password file authentication and as the SYS user.
Typically, you perform this operation after you run the CONFIGURE command for a
standby database, but have not yet connected to this standby database.
1.
Start RMAN and connect to a target database and recovery catalog.
2.
Mount or open the target database:
STARTUP MOUNT;
3.
Resynchronize the recovery catalog.
Run the RESYNC CATALOG command at the RMAN prompt as follows:
RESYNC CATALOG;
The following example resynchronizes the control file of standby1:
RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;
The following variation, when connected to the target database as the SYS user
and using password file authentication, resynchronizes the control files for all
databases in the Data Guard environment:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
See Also:
•
Oracle Database Backup and Recovery Reference for RESYNC CATALOG
command syntax
•
Oracle Data Guard Concepts and Administration to learn how to
configure the RMAN environment for use with a standby database
13.8.3 Updating the Recovery Catalog After Changing a
DB_UNIQUE_NAME
You may decide to change the DB_UNIQUE_NAME of a database in a Data Guard
environment. In this case, you can run the CHANGE DB_UNIQUE_NAME command to
associate the metadata stored in recovery catalog for the old DB_UNIQUE_NAME to the
new DB_UNIQUE_NAME.
The CHANGE DB_UNIQUE_NAME command does not actually change the DB_UNIQUE_NAME of
the database itself. Instead, it updates the catalog metadata for the database whose
unique name has been or will be changed.
13-31
Chapter 13
Maintaining a Recovery Catalog
The following procedure assumes that the DB_UNIQUE_NAME of the primary database is
prodny, and that you have changed the DB_UNIQUE_NAME of a standby database from
prodsf1 to prodsf2. You can use the same procedure after changing the DB_UNIQUE_NAME
of a primary database, except in Step 1 connect RMAN as TARGET to a standby
database instead of a primary database.
To update the recovery catalog after DB_UNIQUE_NAME is changed:
1.
Connect RMAN to the primary database as TARGET and also to the recovery
catalog. For example, enter the following commands:
% rman
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CONNECT TARGET sbu@prodny
target database Password: password
connected to target database: PRODNY (DBID=39525561)
2.
List the DB_UNQUE_NAME values known to the recovery catalog.
Run the following LIST command:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
3.
Change the DB_UNIQUE_NAME in the RMAN metadata.
The following example changes the database unique name from standby database
prodsf1 to prodsf2:
RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
13.8.4 Unregistering a Target Database from the Recovery Catalog
You can use the UNREGISTER DATABASE command to unregister a database from the
recovery catalog.
When a database is unregistered from the recovery catalog, all RMAN repository
records in the recovery catalog are lost. The database can be registered again, but the
recovery catalog records for that database are then based on the contents of the
control file at the time of reregistration. Records older than the
CONTROLFILE_RECORD_KEEP_TIME setting in the target database control file are lost. Stored
scripts, which are not stored in the control file, are also lost.
13.8.4.1 Unregistering a Target Database When Not in a Data Guard
Environment
Use the UNREGISTER DATABASE command to unregister a target database.
This scenario assumes that you are not using the recovery catalog to store metadata
for primary and standby databases.
To unregister a database:
1.
Start RMAN and connect as TARGET to the database to unregister. Also connect to
the recovery catalog.
13-32
Chapter 13
Maintaining a Recovery Catalog
It is not necessary to connect to the target database, but if you do not, then you
must specify the name of the target database in the UNREGISTER command. If
multiple databases have the same name in the recovery catalog, then you must
create a RUN block around the command and use SET DBID to set the DBID for the
database.
2.
Make a note of the DBID as displayed by RMAN at startup.
For example, RMAN outputs a line of the following form when it connects to a
target database that is open:
connected to target database: PROD (DBID=39525561)
3.
As a precaution, it may be useful to list all of the backups recorded in the recovery
catalog using LIST BACKUP SUMMARY and LIST COPY SUMMARY. This way, you can
recatalog backups not known to the control file if you later decide to reregister the
database.
4.
If your intention is to actually delete all backups of the database completely, then
run DELETE statements to delete all existing backups. Do not delete all backups if
your intention is only to remove the database from the recovery catalog and rely
on the control file to store the RMAN metadata for this database.
The following commands illustrate how to delete backups:
DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;
RMAN lists the backups that it intends to delete and prompts for confirmation
before deleting them.
5.
Run the UNREGISTER DATABASE command. For example:
UNREGISTER DATABASE;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database name is "RDBMS" and DBID is 931696259
Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database unregistered from the recovery catalog
13.8.4.2 Unregistering a Standby Database
The UNREGISTER command supports a DB_UNIQUE_NAME clause for use in a Data Guard
environment. You can use this clause to remove metadata for a specific database.
The recovery catalog associates a backup with a particular database. When you
unregister a database, RMAN updates the database name for these backup files to
null. Thus, the backups are still recorded but have no owner. You can execute the
CHANGE ... RESET DB_UNIQUE_NAME command to associate ownership of the currently
ownerless backups to a different database. If you specify INCLUDING BACKUPS on the
UNREGISTER command, then RMAN removes the backup metadata for the unregistered
database as well.
In this scenario, assume that primary database lnx3 has associated standby database
standby1. You want to unregister the standby database.
13-33
Chapter 13
Maintaining a Recovery Catalog
To unregister a standby database:
1.
Start RMAN and connect as TARGET to the primary database. Also, connect RMAN
to a recovery catalog.
For example, enter the following commands:
% rman
RMAN> CONNECT TARGET "sbu@lnx3 AS SYSBACKUP";
target database Password: password
connected to target database: LNX3 (DBID=781317675)
RMAN> CONNECT CATALOG rco@catdb;
2.
List the database unique names.
For example, execute the LIST DB_UNIQUE_NAME command as follows:
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
List of
DB Key
------1
1
3.
Databases
DB Name DB ID
------- ----------------LNX3
781317675
LNX3
781317675
Database Role
--------------STANDBY
PRIMARY
Db_unique_name
-----------------STANDBY1
LNX3
Run the UNREGISTER DB_UNIQUE_NAME command.
For example, execute the UNREGISTER command as follows to unregister database
standby:
RMAN> UNREGISTER DB_UNIQUE_NAME standby1;
RMAN displays the database name and DBID, and prompts you for a confirmation:
database db_unique_name is "standby1", db_name is "LNX3" and DBID is 781317675
Do you really want to unregister the database (enter YES or NO)? yes
When the process is complete, RMAN outputs the following message:
database with db_unique_name standby1 unregistered from the recovery catalog
13.8.4.3 Unregistering a Target Database in a Recovery Appliance
Environment
In a Zero Data Loss Recovery Appliance (Recovery Appliance) environment, the
UNREGISTER DATABASE command cannot be used to unregister a protected database from
the Recovery Appliance catalog. Instead, use the DBMS_RA.DELETE_DB procedure.
To unregister a target database from the Recovery Appliance recovery catalog:
1.
Obtain the DB_NAME of the protected database that you want to unregister.
2.
(Optional) To delete all the backups associated with this protected database,
perform the following steps:
•
Connect to the protected database as a user with the SYSDBA or SYSBACKUP
privilege.
•
Use the following commands to delete all backups:
13-34
Chapter 13
Maintaining a Recovery Catalog
DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;
RMAN lists the backups that it intends to delete and prompts for confirmation
before deleting them.
3.
Start SQL*Plus and connect to the Recovery Appliance metadata database as
RASYS (Recovery Appliance catalog owner).
4.
Unregister the protected database from Recovery Appliance using the
DBMS_RA.DELETE_DB procedure.
begin
DBMS_RA.DELETE_DB('TEST_DB');
end;
/
RMAN prompts you to confirm the unregister database operation.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for details of the
DBMS_RA.DELETE_DB procedure
13.8.5 Resetting the Database Incarnation in the Recovery Catalog
You create an incarnation of the database when you open the database with the
RESETLOGS option. You can access a record of the new incarnation in the
V$DATABASE_INCARNATION view.
If you open the database with the RESETLOGS option, then a new database incarnation
record is automatically created in the recovery catalog. The database also implicitly
and automatically issues a RESET DATABASE command, which specifies that this new
incarnation of the database is the current incarnation. All subsequent backups and log
archiving done by the target database is associated with the new database
incarnation.
Whenever RMAN returns the database to an SCN before the current RESETLOGS SCN,
either with RESTORE and RECOVER or FLASHBACK DATABASE, the RESET DATABASE TO
INCARNATION command is required. However, you do not need to execute RESET
DATABASE TO INCARNATION explicitly in the following scenarios because RMAN runs the
command implicitly with Flashback.
•
You use FLASHBACK DATABASE to rewind the database to an SCN in the direct
ancestral path.
•
You use FLASHBACK DATABASE to rewind the database to a restore point.
The following procedure explains how to reset the database incarnation when
recovering through a RESETLOGS.
To reset the recovery catalog to an older incarnation for media recovery:
1.
Determine the incarnation key of the desired database incarnation. Obtain the
incarnation key value by issuing a LIST command:
13-35
Chapter 13
Maintaining a Recovery Catalog
LIST INCARNATION OF DATABASE trgt;
List of
DB Key
------1
1
Database
Inc Key
------2
582
Incarnations
DB Name DB ID
------- -----TRGT
1224038686
TRGT
1224038686
STATUS
------PARENT
CURRENT
Reset SCN
---------1
59727
Reset Time
---------02-JUL-12
10-JUL-12
The incarnation key is listed in the Inc Key column.
2.
Reset the database to the old incarnation. For example, enter:
RESET DATABASE TO INCARNATION 2;
3.
If the control file of the previous incarnation is available and mounted, then skip to
Step 6 of this procedure. Otherwise, shut down the database and start it without
mounting. For example:
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
4.
Restore a control file from the old incarnation. If you have a control file tagged,
then specify the tag. Otherwise, you can run the SET UNTIL command, as in this
example:
RUN
{
SET UNTIL 'SYSDATE-45';
RESTORE CONTROLFILE; # only if current control file is not available
}
5.
Mount the restored control file:
ALTER DATABASE MOUNT;
6.
Run RESTORE and RECOVER commands to restore and recover the database files from
the prior incarnation, then open the database with the RESETLOGS option. For
example, enter:
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
See Also:
•
About Database Incarnations
•
Oracle Database Backup and Recovery Reference for RESET DATABASE
syntax
•
Oracle Database Backup and Recovery Reference for LIST syntax
13.8.6 Upgrading the Recovery Catalog
This section explains what a recovery catalog upgrade is and when you must do it.
13-36
Chapter 13
Maintaining a Recovery Catalog
13.8.6.1 About Recovery Catalog Upgrades
If you are upgrading to Oracle Database 12c Release 1 (12.1.0.2) or later, then the
recovery catalog database must use the Enterprise Edition of Oracle Database.
If you use a version of the recovery catalog schema that is older than that required by
the RMAN client, then you must upgrade it. The compatibility matrix in Oracle
Database Backup and Recovery Reference explains which schema versions are
compatible with which versions of RMAN. For example, you must upgrade the catalog
if you use an Oracle Database 11g RMAN client with a release 10.2 version of the
recovery catalog schema.
The Oracle Database 10g Release 1 version of the recovery catalog schema requires
the CREATE TYPE privilege. If you created the recovery catalog owner in a release before
10gR1, and if you granted the RECOVERY_CATALOG_OWNER role when it did not include the
CREATE TYPE privilege, then you must grant CREATE TYPE to this user explicitly before
upgrading the catalog.
You receive an error when issuing UPGRADE CATALOG if the recovery catalog is at a
version greater than that required by the RMAN client. RMAN permits the UPGRADE
CATALOG command to be run if the recovery catalog is current and does not require
upgrading, however, so that you can re-create packages at any time if necessary.
Check the message log for error messages generated during the upgrade.
13.8.6.1.1 Special Considerations for Upgrading the Recovery Catalog in a Data Guard
Environment
Assume that you upgrade the recovery catalog schema to Oracle Database 11g or
later in a Data Guard environment. When RMAN connects to a standby database, it
automatically registers the new database information and resynchronizes to obtain the
file names from the control file.
During the resynchronization, RMAN associates the names with the target database
name. Because the recovery catalog contains historical metadata, some records in the
catalog are not known to the control file. For example, the standby1 control file does
not know about all backups made on primary1. The database unique name for these
old records is null. As explained in "About Recovery Catalog Maintenance", you can
use CROSSCHECK to fix these records.
13.8.6.2 Determining the Schema Version of the Recovery Catalog
The schema version of the recovery catalog is stored in the recovery catalog itself.
The information is important in case you maintain multiple databases of different
versions in your production system, and you must determine whether the catalog
schema version is usable with a specific target database version.
To determine the schema version of the recovery catalog:
1.
Start SQL*Plus and connect to the recovery catalog database as the catalog
owner.
2.
Query the RCVER table to obtain the schema version, as in the following example
(sample output included):
SELECT *
FROM rcver;
13-37
Chapter 13
Maintaining a Recovery Catalog
VERSION
-----------12.01.00.01
If the table displays multiple rows, then the highest version in the RCVER table is the
current catalog schema version. The table stores only the major version numbers and
not the patch numbers. For example, assume that the rcver table displays the
following rows:
VERSION
-----------10.02.00
11.02.00
12.01.00.01
These rows indicate that the catalog was created with a release 10.2.0 executable,
then upgraded to release 11.2.0, and finally upgraded to release 12.1.0.1. The current
version of the catalog schema is 12.1.0.1.
See Also:
Oracle Database Backup and Recovery Reference for the complete set of
compatibility rules governing the RMAN environment
13.8.6.3 Using the UPGRADE CATALOG Command
This scenario assumes that you are upgrading a recovery catalog schema to the
current version.
Note:
Starting with Oracle Database 12c Release 1 (12.1.0.2), the recovery catalog
database must use the Enterprise Edition of Oracle Database.
To upgrade the recovery catalog:
1.
Enable Oracle Partitioning for the recovery catalog database.
2.
If the recovery catalog database uses the Standard Edition, then use one of the
following techniques:
•
Migrate the recovery catalog database from Standard Edition to Enterprise
Edition.
•
Move the recovery catalog into an Oracle Enterprise Edition database and
then use the IMPORT CATALOG command to import the recovery catalog into this
database.
3.
Use SQL*Plus to connect to the recovery catalog database as the SYS user with
the SYSDBA privilege.
4.
Run the dbmsrmansys.sql script to grant additional privileges that are required for
the RECOVERY_CATALOG_OWNER role.
13-38
Chapter 13
Maintaining a Recovery Catalog
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
5.
(Optional) Enable the VPD model for the recovery catalog by running the
dbmsrmanvpc.sql script with the –vpd option..
The following command enables the VPD model for the recovery catalog owned
by the user rco:
SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;
6.
Exit SQL*Plus.
7.
Start RMAN and connect RMAN to the recovery catalog database.
8.
Run the UPGRADE CATALOG command:
RMAN> UPGRADE CATALOG;
recovery catalog owner is rman
enter UPGRADE CATALOG command again to confirm catalog upgrade
9.
Run the UPDATE CATALOG command again to confirm:
RMAN> UPGRADE CATALOG;
recovery catalog upgraded to version 12.01.00.01
DBMS_RCVMAN package upgraded to version 12.01.00.01
DBMS_RCVCAT package upgraded to version 12.01.00.01
Note:
To bypass this step, add the NOPROMPT option after the UPGRADE CATALOG
command in step 7.
See Also:
•
Oracle Database Backup and Recovery Reference for UPGRADE CATALOG
command syntax
•
Oracle Database Backup and Recovery Reference for information about
recovery catalog compatibility
•
Oracle Database Upgrade Guide for complete compatibility and
migration information
13.8.7 Importing and Moving a Recovery Catalog
You can use the IMPORT CATALOG command in RMAN to merge one recovery catalog
schema into another.
This command is useful in the following situations:
•
You have multiple recovery catalog schemas for different versions of the
database. You want to merge all existing schemas into one without losing backup
metadata.
•
You want to move a recovery catalog from one database to another database.
13-39
Chapter 13
Maintaining a Recovery Catalog
13.8.7.1 About Recovery Catalog Imports
When using IMPORT CATALOG, the source catalog schema is the catalog schema to
import into a different schema. The destination catalog schema is the catalog
schema into which you intend to import the source catalog schema.
By default, RMAN imports metadata from all target databases registered in the source
recovery catalog. Optionally, you can specify the list of database IDs to be imported
from the source catalog schema.
By default, RMAN unregisters the imported databases from the source catalog
schema after a successful import. To indicate whether the unregister was successful,
RMAN prints messages before and after unregistering the merged databases. You can
also specify the NO UNREGISTER option to specify that the databases is not unregistered
from the source catalog.
A stored script is either global or local. It is possible for global scripts, but not local
scripts, to have name conflicts during import because the destination schema already
contains the script name. In this case, RMAN renames the global script name to COPY
OF script_name. For example, RMAN renames bp_cmd to COPY OF bp_cmd.
If the renamed global script is still not unique, then RMAN renames it to COPY(2) OF
script_name. If this script name also exists, then RMAN renames the script to COPY(3)
OF script_name. RMAN continues the COPY(n) OF pattern until the script is uniquely
named.
13.8.7.2 About Importing Recovery Catalogs in a Recovery Appliance
Environment
In a Recovery Appliance environment, a single, centrally-managed Recovery
Appliance catalog residing on the Recovery Appliance is shared by all the protected
databases. This catalog must be used by all protected databases that send backups to
Recovery Appliance.
When you move protected databases to a data protection strategy that uses Recovery
Appliance, you can choose to migrate existing backups and backup metadata to
Recovery Appliance. To migrate backup metadata, you must import the RMAN
recovery catalog into the Recovery Appliance catalog.
See Also:
•
Zero Data Loss Recovery Appliance Administrator's Guide for an
overview of the Recovery Appliance catalog
•
Zero Data Loss Recovery Appliance Protected Database Configuration
Guide for the steps to migrate backups and backup metadata
13.8.7.3 Prerequisites for Importing a Recovery Catalog
A target database, recovery catalog database, and recovery catalog schema can be at
different database versions. The recommended practice is to import all existing
13-40
Chapter 13
Maintaining a Recovery Catalog
recovery catalogs into a single recovery catalog at the latest version of the recovery
catalog schema.
"Determining the Schema Version of the Recovery Catalog" explains how to determine
the catalog version. Check the compatibility matrix to determine which schema
versions are compatible in your environment.
When using IMPORT CATALOG, the version of the source recovery catalog schema must
be equal to the current version of the RMAN executable with which you run the
command. If the source catalog schema is a lower version, then upgrade it to the
current version before importing the schema. "Upgrading the Recovery Catalog"
explains how to upgrade. If the source recovery catalog schema is a higher version,
then retry the import with a higher version RMAN executable.
No database can be registered in both the source and destination catalog schema. If a
database is currently registered in both catalog schemas, then unregister the database
from source catalog schema before performing the import.
See Also:
Oracle Database Backup and Recovery Reference
13.8.7.4 Importing a Recovery Catalog
When importing one recovery catalog into another, no connection to a target database
is necessary. RMAN only needs connectivity to the source and destination catalogs.
In this example, database srcdb contains a 10.2 recovery catalog schema owned by
user 102cat, while database destdb contains an 11.1 recovery catalog schema owned
by user 111cat.
To import a recovery catalog:
1.
Start RMAN and connect as CATALOG to the destination recovery catalog schema.
For example:
% rman
RMAN> CONNECT CATALOG 111cat@destdb;
2.
Import the source recovery catalog schema, specifying the connection string for
the source catalog.
For example, enter the following command to import the catalog owned by 102cat
on database srcdb:
IMPORT CATALOG 102cat@srcdb;
A variation is to import metadata for a subset of the target databases registered in
the source catalog. You can specify the databases by DBID or database name, as
shown in the following examples:
IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242;
IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4;
3.
Optionally, connect to a target database to check that the metadata was
successfully imported. For example, the following commands connect to database
prod1 as TARGET and list all backups for this database:
13-41
Chapter 13
Dropping a Recovery Catalog
CONNECT TARGET "sbu@prod1 AS SYSBACKUP";
LIST BACKUP;
sbu is a user who is granted the SYSBACKUP privilege in the target database.
13.8.7.5 Moving a Recovery Catalog
The procedure for moving a recovery catalog from one database to another is a
variation of the procedure for importing a catalog.
In this scenario, the source database is the database containing the existing recovery
catalog, while the destination database contains the moved recovery catalog.
To move a recovery catalog from the source database to the destination database:
1.
Create a recovery catalog on the destination database, but do not register any
databases in the new catalog.
"Creating a Recovery Catalog" explains how to perform this task.
2.
Import the source catalog into the catalog created in the preceding step.
"Importing a Recovery Catalog" explains how to perform this task.
13.9 Dropping a Recovery Catalog
The DROP CATALOG command removes those objects that were created by the CREATE
CATALOG command. If the user who owns the recovery catalog also owns objects that
were not created by CREATE CATALOG, then the DROP CATALOG command does not remove
these objects.
If you drop a recovery catalog, and if you have no backups of the recovery catalog
schema, then backups of all target databases registered in this catalog may become
unusable. However, the control file of every target database still retains a record of
recent backups of this database.
The DROP CATALOG command is not appropriate for unregistering a single database from
a recovery catalog that has multiple target databases registered. Dropping the
recovery catalog deletes the recovery catalog record of backups for all target
databases registered in the catalog.
To drop a recovery catalog schema:
1.
Start RMAN and connect to a target database and recovery catalog. Connect to
the recovery catalog as the owner of the catalog schema to be dropped.
The following example connects to a recovery catalog as user rco:
% rman TARGET / CATALOG rco@catdb
2.
Run the DROP CATALOG command:
DROP CATALOG;
recovery catalog owner is rco
enter DROP CATALOG command again to confirm catalog removal
13-42
Chapter 13
Dropping a Recovery Catalog
Note:
To bypass the next confirmation step, add the NOPROMPT option with the
DROP CATALOG command in this step.
3.
Run the DROP CATALOG command again to confirm:
DROP CATALOG;
Note:
Even after you drop the recovery catalog, the control file still contains
records about the backups. To purge RMAN repository records from the
control file, re-create the control file.
See Also:
•
Oracle Database Backup and Recovery Reference for DROP CATALOG
command syntax
•
Unregistering a Target Database from the Recovery Catalog to learn
how to unregister a database from the catalog
13-43
Part V
Diagnosing and Responding to Failures
The following chapters describe how to diagnose and respond to media failures and
data corruptions. This part of the book contains the following chapters:
•
RMAN Data Repair Concepts
•
Diagnosing and Repairing Failures with Data Recovery Advisor
•
Validating Database Files and Backups
•
Performing Complete Database Recovery
•
Performing Flashback and Database Point-in-Time Recovery
•
Performing Block Media Recovery
•
Performing RMAN Recovery: Advanced Scenarios
•
Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)
•
Recovering Tables and Table Partitions from RMAN Backups
14
RMAN Data Repair Concepts
This chapter describes the general concepts that you must understand to perform data
repair. This chapter contains the following topics:
•
Overview of RMAN Data Repair
•
About RMAN Restore Operations
•
About RMAN Media Recovery
14.1 Overview of RMAN Data Repair
As explained in "About Data Protection", a principal purpose of a backup and recovery
strategy is data protection. The key to an effective, efficient strategy is to understand
the basic options of data repair.
14.1.1 About Problems Requiring Data Repair
While several problems can halt the normal operation of an Oracle database or affect
database I/O operations, only the following typically require DBA intervention and data
repair: user errors, application errors, and media failures.
14.1.1.1 About User Errors
User errors occur when, either due to an error in application logic or a manual mistake,
data in your database is changed or deleted incorrectly.
For example, a user logs in to the wrong database and drops a database table. User
errors are estimated to be the greatest single cause of database downtime.
14.1.1.2 About Application Errors
Sometimes a software malfunction can corrupt data blocks. In a physical corruption,
which is also called a media corruption, the database does not recognize the block.
14.1.1.3 About Media Failures
A media failure occurs when a problem external to the database prevents it from
reading from or writing to a file during normal operations.
Typical media failures include disk failures and the deletion of database files. Media
failures are less common than user or application errors, but your backup and
recovery strategy should prepare for them.
14.1.2 About RMAN Data Repair Techniques
RMAN provides multiple methods of data repair.
14-1
Chapter 14
Overview of RMAN Data Repair
Depending on the situations you anticipate, consider incorporating each of the options
described in the following table into your strategy for responding to data loss, and then
set up your database to make these options possible.
Table 14-1
RMAN Data Repair Techniques
Data Repair Technique
Description
Additional Information
Data Recovery Advisor
This Oracle Database
infrastructure can diagnose
failures, advise you on how to
respond to them, and repair
the failures automatically.
"Overview of Data Recovery
Advisor"
logical flashback features
This subset of Oracle
Flashback Technology
features enables you to view
or rewind individual database
objects or transactions to a
past time. These features do
not require use of RMAN.
"Overview of Oracle
Flashback Technology and
Database Point-in-Time
Recovery"
Oracle Flashback Database
Flashback Database is a
"Basic Concepts of Point-inblock-level recovery
Time Recovery and Flashback
mechanism that is similar to
Features"
media recovery, but is
generally faster and does not
require a backup to be
restored. You can return your
whole database to a previous
state without restoring old
copies of your data files from
backup, if you have enabled
flashback logging in advance.
You must have a fast recovery
area configured for logging for
flashback database or
guaranteed restore points.
data file media recovery
This form of media recovery
•
enables you to restore data
file backups and apply
•
archived redo logs or
incremental backups to
recover lost changes. You can
either recover a whole
database or a subset of the
database. Data file media
recovery is the most generalpurpose form of recovery and
can protect against both
physical and logical failures.
block media recovery
This form of media recovery
enables you to recover
individual blocks within a data
file rather than the whole data
file.
"Performing Complete
Database Recovery"
"Performing Database
Point-in-Time Recovery"
"Overview of Block Media
Recovery"
14-2
Chapter 14
About RMAN Restore Operations
Table 14-1
(Cont.) RMAN Data Repair Techniques
Data Repair Technique
Description
Additional Information
tablespace point-in-time
recovery (TSPITR)
This is a specialized form of
"Overview of RMAN TSPITR"
point-in-time recovery in which
you recover one or more
tablespaces to a time earlier
than the rest of the database.
In general, the concepts required to use the preceding repair techniques are explained
along with the techniques. This chapter explains concepts that are common to several
RMAN data repair solutions.
14.2 About RMAN Restore Operations
In an RMAN restore operation, you select files to be restored and then run the RESTORE
command. Typically, you restore files in preparation for media recovery.
You can restore the following types of files:
•
Database (all data files)
•
Tablespaces
•
Control files
•
Archived redo logs
•
Server parameter files
You can specify either the default location or a new location for restored data files and
control files. If you restore to the default location, then RMAN overwrites any files with
the same name that currently exist in this location. Alternatively, you can use the SET
NEWNAME command to specify new locations for restored data files. You can then run a
SWITCH command to update the control file to indicate that the restored files in their new
locations are now the current data files.
See Also:
•
Oracle Database Backup and Recovery Reference for RESTORE syntax
and prerequisites
•
Oracle Database Backup and Recovery Reference for SET NEWNAME
syntax
•
Oracle Database Backup and Recovery Reference for SWITCH syntax
14.2.1 About RMAN Backup Selection
RMAN uses the records of available backup sets or image copies in the RMAN
repository to select the best available backups for use in the restore operation.
The most recent backup available, or the most recent backup satisfying any UNTIL
clause specified in the RESTORE command, is the preferred choice. If two backups are
14-3
Chapter 14
About RMAN Restore Operations
from the same point in time, then RMAN prefers image copies over backup sets
because RMAN can restore more quickly from image copies than from backup sets
(especially those stored on tape).
All specifications of the RESTORE command must be satisfied before RMAN restores a
backup. Unless limited by the DEVICE TYPE clause, the RESTORE command searches for
backups on all device types of configured channels. If no available backup in the
repository satisfies all the specified criteria, then RMAN returns an error indicating that
the file cannot be restored.
If you use only manually allocated channels, then a backup job may fail if there is no
usable backup on the media for which you allocated channels. Configuring automatic
channels makes it more likely that RMAN can find and restore a backup that satisfies
the specified criteria.
See Also:
"Configuring Advanced Channel Options"
14.2.2 About RMAN Restore Failover
RMAN automatically uses restore failover to skip corrupted or inaccessible backups
and look for usable backups. When a backup is not found, or contains corrupt data,
RMAN automatically looks for another backup from which to restore the desired files.
RMAN generates messages that indicate the type of failover that it is performing. For
example, when RMAN fails over to another backup of the same file, it generates a
message similar to the following:
failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009
If no usable copies are available, then RMAN searches for previous backups. The
message generated is similar to the following example:
ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup
RMAN performs restore failover repeatedly until it has exhausted all possible backups.
If all of the backups are unusable or no backups exists, then RMAN attempts to recreate the data file. Restore failover is also used when there are errors restoring
archived redo logs during RECOVER, RECOVER ... BLOCK, and FLASHBACK DATABASE
commands.
14.2.3 About RMAN Restore of Encrypted Backups
RMAN automatically decrypts backup sets that are protected with backup encryption
when their contents are restored. Additional steps, if any, depend on the on the
technique that was used to encrypt the backups.
14-4
Chapter 14
About RMAN Restore Operations
•
Transparent backup encryption using an auto-login software keystore requires no
intervention if the Oracle keystore is available.
When restoring a backup on a host that is different from the source host on which
the backup is created, manually copy the Oracle keystore from the source
database to the destination host.
•
Transparent backup encryption using a password-based keystore requires the
keystore to be open.
Manually copy the Oracle software keystore to the destination host on which the
backup is being restored and provide the password required to open the keystore.
The SET DECRYPTION WALLET OPEN IDENTIFIED BY command to provide the password.
•
Password-encrypted backups require the correct password to be entered before
they can be restored.
Use the SET DECRYPTION IDENTIFIED BY command to specify the password that must
be used to decrypt the encrypted backup.
•
Dual-mode encrypted backups can be restored either transparently, by using the
Oracle software keystore, or by specifying a password for decryption.
TDE Master Keys and Transparently Encrypted Backups
When you reset (or rotate, rekey) a TDE master encryption key, RMAN can still restore
backups that were encrypted using the old TDE master encryption key. This is
possible because the Oracle keystore stores a history of all retired TDE master
encryption keys.
Note:
If the Oracle keystore that contains the TDE master key is lost and needs to
be recreated, then any backups that were encrypted using the old TDE
master keys are invalidated and cannot be used.
See Also:
Oracle Database Advanced Security Guide
14.2.4 About RMAN Restore Operations and ASM
When Automatic Storage Management (ASM) disk groups are used, an RMAN restore
operation creates new copies of data files only if the full name of a data file, including
the incarnation, does not match with the name of an existing data file.
A fully qualified ASM file name is of the form +diskgroup/dbname/filetype/
filetypetag.file.incarnation. When you first restore the control file and then
restore the other database files, the names of the data files in the control file may not
match with the names of the existing data files and therefore the data files are
recreated.
Use one of the following methods to ensure that existing data files are not recreated
during a restore or duplicate operation:
14-5
Chapter 14
About RMAN Media Recovery
•
In the control file, use alias names for each data file. The alias must not include
the ASM incarnation number.
•
After restoring the control file and before restoring the other database files, use the
CATALOG command to ensure that the existing data files are cataloged in the
restored control file. Next, use the SWITCH command to make the restored control
file point to the existing data files.
•
Use SET NEWNAME to rename the data files before restoring the data files and after
restoring the control file.
14.2.5 About RMAN Restore Optimization
RMAN uses restore optimization to avoid restoring data files from backup when
possible. If a data file is present in the correct location and its header contains the
expected information, then RMAN does not restore the data file from backup.
Note:
Restore optimization only checks the data file header. It does not the scan
the data file body for corrupted blocks.
You can use the FORCE option of the RESTORE command to override this behavior and
restore the requested files unconditionally.
Restore optimization is particularly useful when an operation that restores several data
files is interrupted. For example, assume that a full database restore encounters a
power failure after all except one data file has been restored. If you run the same
RESTORE command again, then RMAN only restores the single data file that was not
restored during the previous attempt.
Restore optimization is also used when duplicating a database. If a data file at the
duplicate is in the correct place with the correct header contents, then the data file is
not duplicated. Unlike RESTORE, DUPLICATE does not support a FORCE option. To force
RMAN to duplicate a data file that is skipped due to restore optimization, delete the
data file from the duplicate before running the DUPLICATE command.
See Also:
Oracle Real Application Clusters Administration and Deployment Guide for
description of RESTORE behavior in an Oracle RAC configuration
14.3 About RMAN Media Recovery
In media recovery, RMAN applies changes to restored data to roll forward this data in
time.
RMAN can perform either data file media recovery or block media recovery.
Data file media recovery is the application of redo logs or incremental backups to a
restored data file to update it to the current time or some other specified time. As
14-6
Chapter 14
About RMAN Media Recovery
explained in Oracle Database Concepts, you can use RMAN to perform complete
recovery, database point-in-time recovery (DBPITR), or tablespace point-in-time
recovery (TSPITR). You can use the RESTORE command to restore backups of lost and
damaged data files or control files and the RECOVER command to perform media
recovery.
Block media recovery is the recovery of individual data blocks rather than entire data
files. This section explains data file media recovery only. Block media recovery, which
is a specialized form of media recovery, is explained in "Overview of Block Media
Recovery".
14.3.1 About Selection of Incremental Backups and Archived Redo
Logs
RMAN automates media recovery. RMAN automatically restores and applies both
incremental backups and archived redo logs in whatever combination is most efficient.
If the RMAN repository indicates that no copies of a required log sequence number
exist on disk, then it automatically restores the required log from backup. By default,
RMAN restores the archived logs to the fast recovery area, if an archiving destinations
is set to USE_DB_RECOVERY_FILE_DEST. Otherwise, RMAN restores the logs to the first
local archiving destination specified in the initialization parameter file.
See Also:
Oracle Database Backup and Recovery Reference for CROSSCHECK syntax
14.3.2 About Database Incarnations
A database incarnation is created whenever you open the database with the RESETLOGS
option.
After complete recovery, you can resume normal operations without an OPEN
RESETLOGS . After a DBPITR or recovery with a backup control file, however, you must
open the database with the RESETLOGS option, thereby creating a new incarnation of the
database. The database requires a new incarnation to avoid confusion when two
different redo streams have the same SCNs, but occurred at different times. If you
apply the wrong redo to your database, then you corrupt it.
The existence of multiple incarnations of a single database determines how RMAN
treats backups that are not in the current incarnation path. Usually, the current
database incarnation is the correct one to use. Nevertheless, in some cases resetting
the database to a previous incarnation is the best approach. For example, you may be
dissatisfied with the results of a point-in-time recovery that you have performed and
want to return the database to a time before the RESETLOGS. An understanding of
database incarnations is helpful to prepare for such situations.
14.3.2.1 About RMAN OPEN RESETLOGS Operations
RMAN performs certain actions when you open the database with the RESETLOGS
option.
14-7
Chapter 14
About RMAN Media Recovery
The action performed are as follows:
•
Archives the current online redo logs (if they are accessible) and then erases the
contents of the online redo logs and resets the log sequence number to 1.
For example, if the current online redo logs are sequence 1000 and 1001 when
you open RESETLOGS, then the database archives logs 1000 and 1001 and then
resets the online redo logs to sequence 1 and 2.
•
Creates the online redo log files if they do not currently exist.
•
Initializes redo thread records and online redo log records in the control file to the
beginning of the new database incarnation.
More specifically, the database sets the redo thread status to closed, sets the
current thread sequence in the redo thread records to 1, sets the thread
checkpoint of each redo thread to the beginning of log sequence 1, chooses one
redo log from each thread and initialize its sequence to 1, and so on.
•
Updates all current data files and online redo logs and all subsequent archived
redo logs with a new RESETLOGS SCN and time stamp.
Because the database does not apply an archived redo log to a data file unless the
RESETLOGS SCN and time stamps match, the RESETLOGS requirement prevents you from
corrupting data files with archived logs that are not from direct parent incarnations of
the current incarnation. The relationship among incarnations is explained more fully in
the following section.
In previous releases, it was recommended that you back up the database immediately
after the OPEN RESETLOGS. Because you can now easily recover a pre-RESETLOGS backup
like any other backup, making a new database backup is optional. To perform
recovery through RESETLOGS you must have all archived logs generated after the most
recent backup and at least one control file (current, backup, or created).
14.3.2.2 Relationship Among Database Incarnations
Database incarnations can stand in the following relationships to each other:
•
•
The current incarnation is the one in which the database is currently operating.
The incarnation from which the current incarnation branched following an OPEN
RESETLOGS operation is the parent incarnation of the current incarnation.
•
The parent of the parent incarnation is an ancestor incarnation. Any parent of an
ancestor incarnation is also an ancestor of the current incarnation.
•
The direct ancestral path of the current incarnation begins with the earliest
incarnation and includes only the branches to an ancestor of the current
incarnation, the parent incarnation, or the current incarnation.
An incarnation number is used to uniquely tag and identify a stream of redo.
Figure 14-1 illustrates a database that goes through several incarnations, each with a
different incarnation number.
14-8
Chapter 14
About RMAN Media Recovery
Database Incarnation History
SCN 3000
SC
N
20
00
SC
N
30
00
Figure 14-1
In
ca
rn
at
io
n
2
Incarnation 3
SCN 1000
SCN 1
SCN 2000
Incarnation 1
Direct Ancestral Path
Incarnation 1 of the database starts at SCN 1 and continues through SCN 1000 to
SCN 2000. Suppose that at SCN 2000 in incarnation 1, you perform a point-in-time
recovery back to SCN 1000, and then open the database with the RESETLOGS option.
Incarnation 2 now begins at SCN 1000 and continues to SCN 3000. In this example,
incarnation 1 is the parent of incarnation 2.
Suppose that at SCN 3000 in incarnation 2, you perform a point-in-time recovery to
SCN 2000 and open the database with the RESETLOGS option. In this case, incarnation 2
is the parent of incarnation 3. Incarnation 1 is an ancestor of incarnation 3.
When DBPITR or Flashback Database has occurred in database, an SCN can refer to
multiple points in time, depending on which incarnation is current. For example, SCN
1500 in Figure 14-1 could refer to an SCN in incarnation 1 or 2.
You can use the RESET DATABASE TO INCARNATION command to specify that SCNs are to
be interpreted in the frame of reference of a specific database incarnation. The RESET
DATABASE TO INCARNATION command is required when you use FLASHBACK, RESTORE, or
RECOVER to return to an SCN in a noncurrent database incarnation. However, RMAN
executes the RESET DATABASE TO INCARNATION command implicitly with Flashback, as
explained in "Resetting the Database Incarnation in the Recovery Catalog".
See Also:
•
•
"Recovering the Database to an Ancestor Incarnation"
Oracle Database Backup and Recovery Reference for details about the
RESET DATABASE command
14-9
Chapter 14
About RMAN Media Recovery
14.3.2.3 About Incarnations of PDBs
A pluggable database (PDB) incarnation is a subincarnation of the multitenant
container database (CDB) and is expressed as (database_incarnation,
pdb_incarnation).
For example, if the CDB is incarnation 5, and a PDB is incarnation 3, then the fully
specified incarnation number of the PDB is (5, 3). The initial incarnation of a PDB is 0.
Subsequent incarnations are unique but not always sequential numbers.
The V$PDB_INCARNATION view contains information about all PDB incarnations. Use the
following query to display the current incarnation of a PDB:
SELECT PDB_INCARNATION# FROM V$PDB_INCARNATION
WHERE STATUS = 'CURRENT' AND CON_ID = PDB_container_id;
14.3.2.4 About Orphaned Backups
When a database goes through multiple incarnations, some backups can become
orphaned backups. Orphaned backups are backups created during incarnations of the
database that are not in the direct ancestral path.
Assume the scenario shown in Figure 14-1. If incarnation 3 is the current incarnation,
then the following backups are orphaned:
•
All backups from incarnation 1 after SCN 1000
•
All backups from incarnation 2 after SCN 2000
In contrast, the following backups are not orphaned because they are in the direct
ancestral path:
•
All backups from incarnation 1 before SCN 1000
•
All backups from incarnation 2 before SCN 2000
•
All backups from incarnation 3
You can use orphaned backups when you intend to restore the database to an SCN
not in the direct ancestral path. RMAN can restore backups from parent and ancestor
incarnations and recover to the current time, even across OPEN RESETLOGS operations, if
a continuous path of archived logs exists from the earliest backups to the point to
which you want to recover. If you restore a control file from an incarnation in which the
changes represented in the backups had not been abandoned, then RMAN can also
restore and recover orphaned backups.
14.3.2.5 About Orphaned PDB Backups
Orphan PDB backups can result when you perform point-in-time recovery on a
pluggable database (PDB) and then open the PDB using the RESETLOGS option.
After recovering a PDB to a specified point-in-time, when you open the PDB using the
RESETLOGS option, a new incarnation of the PDB is created. Orphan PDB backups are
backups that were created when the SCN or time value was between the SCN or time
to which the PDB was recovered and the SCN or time at which the PDB was opened
in RESETLOGS mode. The END_RESETLOGS_SCN column of the V$PDB_INCARNATION view
contains the SCN at which the PDB is opened in RESETLOGS mode.
14-10
15
Diagnosing and Repairing Failures with
Data Recovery Advisor
This chapter explains how to use the Data Recovery Advisor tool in RMAN to diagnose
and repair database failures. This chapter contains the following topics:
•
Overview of Data Recovery Advisor
•
Listing Failures
•
Checking for Block Corruptions by Validating the Database
•
Determining Repair Options
•
Repairing Failures
•
Changing Failure Status and Priority
15.1 Overview of Data Recovery Advisor
The Data Recovery Advisor is a tool that helps reduce database recovery time by
determining the best automated repair option for database failures.
15.1.1 Purpose of Data Recovery Advisor
Data Recovery Advisor is an Oracle Database tool that automatically diagnoses data
failures, determines and presents appropriate repair options, and executes repairs at
the user's request.
In this context, a data failure is a corruption or loss of persistent data on disk. By
providing a centralized tool for automated data repair, Data Recovery Advisor
improves the manageability and reliability of an Oracle database and thus helps
reduce the MTTR.
Diagnosing a data failure and devising an optimal strategy for repair requires a high
degree of training and experience. Data Recovery Advisor provides the following
advantages over traditional repair techniques:
•
Data Recovery Advisor can potentially detect, analyze, and repair data failures
before a database process discovers the corruption and signals an error. Early
warnings help limit damage caused by corruption.
•
Manually assessing symptoms of data failures and correlating them into a problem
statement can be complex, error-prone, and time-consuming. Data Recovery
Advisor automatically diagnoses failures, assesses their impact, and reports these
findings to the user.
•
Traditionally, users must manually determine repair options along with the repair
impact. If multiple failures are present, then users must determine the right
sequence of repair execution and try to consolidate repairs. In contrast, Data
Recovery Advisor automatically determines the best repair options and runs
checks to ensure that these options are feasible in your environment.
15-1
Chapter 15
Overview of Data Recovery Advisor
•
Execution of a data repair can be complex and error-prone. If you choose an
automated repair option, then Data Recovery Advisor executes the repair and
verifies its success.
15.1.2 Basic Concepts of Data Recovery Advisor
You must familiarize yourself with a few concepts before using the Data Recovery
Advisor.
See Also:
•
User Interfaces to Data Recovery Advisor
•
About Data Integrity Checks
•
About Failures
•
About Manual Actions and Automatic Repair Options
•
About Supported Database Configurations for Data Recovery Advisor
15.1.2.1 User Interfaces to Data Recovery Advisor
Data Recovery Advisor has both a command-line and GUI interface. The GUI interface
is available in Oracle Enterprise Manager Cloud Control.
In the RMAN command-line interface, the Data Recovery Advisor commands are LIST
FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE.
A failure is detected either automatically by the database or through a manual check
such as the VALIDATE command. You can use the LIST FAILURE command to view
problem statements for failures and the effect of these failures on database
operations. Each failure is uniquely identified by a failure number. In the same RMAN
session, you can then use the ADVISE FAILURE command to view repair options, which
typically include both automated and manual options.
After executing ADVISE FAILURE, you can either repair failures manually or run the
REPAIR FAILURE command to repair the failures automatically. A repair is an action that
fixes one or more failures. Examples of repairs include block media recovery, data file
media recovery, and Oracle Flashback Database. When you choose an automated
repair option, Data Recovery Advisor verifies the repair success and closes the
relevant repaired failures.
15.1.2.2 About Data Integrity Checks
A checker is a diagnostic operation or procedure registered with the Health Monitor to
assess the health of the database or its components.
The health assessment is known as a data integrity check and can be invoked
reactively or proactively.
Failures are normally detected reactively. A database operation involving corrupted
data results in an error, which automatically invokes a data integrity check that
searches the database for failures related to the error. If failures are diagnosed, then
they are recorded in the Automatic Diagnostic Repository (ADR), which is a directory
15-2
Chapter 15
Overview of Data Recovery Advisor
structure stored outside of the database. You can use Data Recovery Advisor to
generate repair advice and repair failures only after failures have been detected by the
database and stored in ADR.
You can also invoke a data integrity check proactively. You can execute the check
through the Health Monitor, which detects and stores failures in the same way as
when the checks are invoked reactively. You can also check for block corruption with
the VALIDATE and BACKUP VALIDATE commands, as explained in "Checking for Block
Corruptions by Validating the Database".
See Also:
Oracle Database Administrator’s Guide to learn how to use the Health
Monitor
15.1.2.3 About Failures
A failure is a persistent data corruption that is detected by a data integrity check.
A failure can manifest itself as observable symptoms such as error messages and
alerts, but a failure is different from a symptom because it represents a diagnosed
problem. After a problem is diagnosed by the database as a failure, you can obtain
information about the failure and potentially repair it with Data Recovery Advisor.
Because failure information is not stored in the database itself, the database does not
need to be open or mounted for you to access it. You can view failures when the
database is started in NOMOUNT mode. Thus, the availability of the control file and
recovery catalog does not affect the ability to view detected failures, although it may
affect the feasibility of some repairs.
Data Recovery Advisor can diagnose failures such as the following:
•
Components such as data files and control files that are not accessible because
they do not exist, do not have the correct access permissions, have been taken
offline, and so on
•
Physical corruptions such as block checksum failures and invalid block header
field values
•
Inconsistencies such as a data file that is older than other database files
•
I/O failures such as hardware errors, operating system driver failures, and
exceeding operating system resource limits (for example, the number of open
files)
The Data Recovery Advisor may detect or handle some logical corruptions. In general,
corruptions of this type require help from Oracle Support Services.
15-3
Chapter 15
Overview of Data Recovery Advisor
See Also:
•
About the Failure Status
•
About Failure Priority
•
About Failure Grouping
15.1.2.3.1 About the Failure Status
Every failure has a failure status: OPEN or CLOSED.
The status of a failure is OPEN until the appropriate repair action is invoked. The status
changes to CLOSED after the failure is repaired.
Every time you execute LIST FAILURE , Data Recovery Advisor revalidates all open
failures and closes failures that no longer exist. Thus, if you fixed some failures as part
of a separate procedure, or if the failures were transient problems that disappeared by
themselves, running LIST FAILURE automatically closes them.
You can use CHANGE FAILURE to change the status of an open failure to CLOSED if you
have fixed it manually. However, it makes sense to use CHANGE FAILURE ... CLOSED only
if for some reason the failure was not closed automatically. If a failure still exists when
you use CHANGE to close it manually, then Data Recover Advisor re-creates it with a
different failure ID when the appropriate data integrity check is executed.
15.1.2.3.2 About Failure Priority
Every failure has a failure priority: CRITICAL, HIGH, or LOW. Data Recovery Advisor only
assigns CRITICAL or HIGH priority to diagnosed failures.
Failures with CRITICAL priority require immediate attention because they make the
whole database unavailable. For example, a disk containing a current control file may
fail. Failures with HIGH priority make a database partly unavailable or unrecoverable
and usually have to be repaired quickly. Examples include block corruptions and
missing archived redo logs.
If a failure was assigned a HIGH priority, but the failure has little impact on database
availability and recoverability, then you can downgrade the priority to LOW. A LOW priority
indicates that a failure can be ignored until more important failures are fixed.
By default LIST FAILURE displays only failures with CRITICAL and HIGH priority. You can
use the CHANGE command to change the status for LOW and HIGH failures, but you cannot
change the status of CRITICAL failures. The main reason for changing a priority to LOW is
to reduce the LIST FAILURE output. If a failure cannot be revalidated at this time (for
example, because of another failure), then LIST FAILURE shows the failure as open.
15.1.2.3.3 About Failure Grouping
For clarity, Data Recovery Advisor groups related failures together.
For example, if 20 different blocks in a file are corrupted, then these failures are
grouped under a single parent failure. By default, Data Recovery Advisor lists
information about the group of failures, although you can specify the DETAIL option to
list information about the individual subfailures.
15-4
Chapter 15
Overview of Data Recovery Advisor
A subfailure has the same format as a failure. You can get advice on a subfailure and
repair it separately or in combination with any other failure.
15.1.2.4 About Manual Actions and Automatic Repair Options
The ADVISE FAILURE command can present both manual and automatic repair options.
Data Recovery Advisor categorizes manual actions as either mandatory or optional.
In some cases, the only possible actions are manual. Suppose that no backups exist
for a lost control file. In this case, the manual action is to execute the CREATE
CONTROLFILE statement. Data Recovery Advisor presents this manual action as
mandatory because no automatic repair is available. In contrast, suppose that RMAN
backups exist for a missing data file. In this case, the REPAIR FAILURE command can
perform the repair automatically by restoring and recovering the data file. An optional
manual action is to restore the data file if it was unintentionally renamed or moved.
Data Recovery Advisor suggests optional manual actions if they might prevent a more
extreme form of repair such as data file restore and recovery.
In contrast to manual actions, automated repairs can be performed by Data Recovery
Advisor. The ADVISE FAILURE command presents an option ID for each automated
repair option and summarizes the action.
Data Recovery Advisor performs feasibility checks before recommending an
automated repair. For example, Data Recovery Advisor checks that all backups and
archived redo logs needed for media recovery are present and consistent. Data
Recovery Advisor may need specific backups and archived redo logs. If the files
needed for recovery are not available, then recovery is not possible.
Note:
For performance reasons, Data Recovery Advisor does not exhaustively
check every byte in every file. Thus, a feasible repair may still fail because of
a corrupted backup or archived redo log file.
15.1.2.4.1 About Consolidated Repairs
When possible, Data Recovery Advisor consolidates repairs to fix multiple failures into
a single repair. A consolidated repair may contain multiple steps.
Sometimes a consolidated repair is not possible, as when one failure prevents the
creation of repairs for other failures. For example, the feasibility of a data file repair
cannot be determined when the control file is missing. In such cases, Data Recovery
Advisor generates a repair option for failures that can be repaired and prints a
message stating that some selected failures cannot be repaired at this time. After
executing the proposed repair, you can repeat the LIST, ADVISE, and REPAIR sequence
to repair remaining failures.
15.1.2.4.2 About Repair Scripts
Whenever Data Recovery Advisor generates an automated repair option, it creates a
script that explains which commands RMAN intends to use to repair the failure. Data
Recovery Advisor prints the location of this script, which is a text file residing on the
operating system.
15-5
Chapter 15
Overview of Data Recovery Advisor
Example 15-1 shows a sample repair script, which shows how Data Recovery Advisor
plans to repair the loss of data file 27.
Example 15-1
Sample Repair Script
# restore and recover data file
ALTER DATABASE DATAFILE 27 OFFLINE;
restore datafile 27;
recover datafile 27;
ALTER DATABASE DATAFILE 27 ONLINE;
If you do not want Data Recovery Advisor to automatically repair the failure, then you
can copy the script, edit it, and execute it manually.
15.1.2.5 About Supported Database Configurations for Data Recovery Advisor
Data Recovery Advisor is supported only on some database configurations.
15.1.2.5.1 About Data Recovery Advisor and Oracle Real Application Clusters
Data Recovery Advisor only supports single-instance databases. Oracle Real
Application Clusters (Oracle RAC) databases are not supported.
If a data failure occurs that brings down all Oracle RAC instances, then you can mount
the database in single-instance mode and use Data Recovery Advisor to detect and
repair control file, SYSTEM data file, and data dictionary failures. You can also invoke
data recovery checks proactively to test other database components for data failures.
This approach does not detect data failures that are local to other cluster instances, for
example, an inaccessible data file.
15.1.2.5.2 About Data Recovery Advisor and Oracle Data Guard
There are some limitation with Data Recovery Advisor in an Oracle Data Guard
environment.
In a Data Guard environment, Data Recovery Advisor cannot do the following:
•
Use files transferred from a physical standby database to repair failures on a
primary database
•
Diagnose and repair failures on a standby database
However, if the primary database is unavailable, then Data Recovery Advisor may
recommend a failover to a standby database. After the failover you can repair the old
primary database. If you are using Enterprise Manager Cloud Control in a Data Guard
configuration, then you can initiate a failover through the Data Recovery Advisor
recommendations page.
See Also:
Oracle Data Guard Concepts and Administration to learn how to use RMAN
in a Data Guard configuration
15-6
Chapter 15
Overview of Data Recovery Advisor
15.1.2.5.3 About Data Recovery Advisor and CDBs
Data Recovery Advisor can only be used to diagnose and repair data corruptions in
non-CDBs and the root of a multitenant container database (CDB). Data Recovery
Advisor is not supported for pluggable databases (PDBs).
15.1.3 Basic Steps of Diagnosing and Repairing Failures
The Data Recovery Advisor workflow begins when you either suspect or discover a
failure. You can discover failures in many ways, including error messages, alerts, trace
files, and failed data integrity checks.
As explained in "About Data Integrity Checks", the database can automatically
diagnose failures when errors occur.
To respond to failures, start an RMAN session and perform all of the following steps in
the same session and in the order they are listed:
1.
List failures by running the LIST FAILURE command.
This task is explained in "Listing Failures".
2.
If you suspect that failures exist that have not been automatically diagnosed by the
database, then run VALIDATE DATABASE to check for corrupt blocks and missing files.
If VALIDATE detects a problem, then RMAN triggers execution of a failure
assessment. If a failure is detected, then RMAN logs it into the Automated
Diagnostic Repository, where is can be accessed by Data Recovery Advisor.
This task is explained in "Checking for Block Corruptions by Validating the
Database".
3.
Determine repair options by running the ADVISE FAILURE command.
This task is explained in "Determining Repair Options".
4.
Choose a repair option. You can repair the failures manually or run the REPAIR
FAILURE command to fix them automatically.
This task is explained in "Repairing Failures".
5.
Return to the first step to confirm that all failures were repaired or determine which
failures remain.
Performing the steps for diagnosing and repairing failures in an order that is different
from the one listed in this section may result in errors.
If appropriate, you can use CHANGE FAILURE command at any time in the Data Recovery
Advisor workflow to change the priority of a failure from LOW to HIGH or HIGH to LOW, or
close a failure that has been fixed manually. This task is explained in "Changing
Failure Status and Priority".
See Also:
Oracle Data Guard Concepts and Administration for a complete example on
recovering a database using the Data Recovery Advisor
15-7
Chapter 15
Listing Failures
15.1.4 Diagnosing and Repairing Failures in CDBs
You can use the Data Recovery Advisor to automatically diagnose data failures,
determine appropriate repair options, and execute repairs in a CDB.
The steps used for a CDB are similar to the ones that you would use for a non-CDB.
The only difference is that, for a CDB, you connect to the root and then use the steps
described in this chapter to perform repair actions.
You cannot diagnose data failures and execute repairs for individual PDBs in a CDB.
See Also:
"Making RMAN Connections to a CDB"
15.2 Listing Failures
If you suspect or know that one or more database failures have occurred, then use
LIST FAILURE to obtain information about them.
You can list all or a subset of failures and restrict output in various ways. Failures are
uniquely identified by failure numbers. These numbers are not consecutive, so gaps
between failure numbers have no significance.
The LIST FAILURE command does not execute data integrity checks to diagnose new
failures; rather, it lists the results of previously executed assessments. Thus,
repeatedly executing LIST FAILURE reveals new failures only if the database
automatically diagnosed them in response to errors that occurred in between
command executions. However, executing LIST FAILURE causes Data Recovery
Advisor to revalidate all existing failures. If a user fixed failures manually, or if transient
failures disappeared, then Data Recovery Advisor removes these failures from the
LIST FAILURE output. If a failure cannot be revalidated at this moment (for example,
because of another failure), LIST FAILURE shows the failure as open.
See Also:
•
Listing All Failures
•
Listing a Subset of Failures
15.2.1 Listing All Failures
The easiest way to determine problems that your database is encountering is to use
the LIST FAILURE command.
To list all failures:
1.
Start RMAN and connect to a target database. The target database instance must
be started.
15-8
Chapter 15
Listing Failures
2.
Execute the LIST FAILURE command.
The following example reports all failures known to Data Recovery Advisor (the
output has been reformatted to fit on the page).
RMAN> LIST FAILURE;
List of Database Failures
=========================
Failure ID Priority Status
---------- -------- --------142
HIGH
OPEN
missing
101
HIGH
OPEN
system01.dbf' contains one or
Time Detected Summary
------------- ------23-APR-13
One or more non-system datafiles are
23-APR-13
Datafile 1: '/disk1/oradata/prod/
more corrupt blocks
In this example, RMAN reports two different failures: a group of missing data files
and a data file with corrupt blocks. The output indicates the unique identifier for
each failure (142 and 101), the priority, status, and detection time.
3.
Optionally, execute LIST FAILURE ... DETAIL to list failures individually.
Data Recovery Advisor consolidates failures when possible. Specify the DETAIL
option to list failures individually. For example, if multiple block corruptions exist in
a file, then specifying the DETAIL option lists each of the block corruptions. The
following example lists detailed information about failure 101.
RMAN> LIST FAILURE 101 DETAIL;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------101
HIGH
OPEN
23-APR-13
Datafile 1: '/disk1/oradata/prod/
system01.dbf' contains one or more corrupt blocks
List of child failures for parent failure ID 101
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------104
HIGH
OPEN
23-APR-13
Block 56416 in datafile 1: '/disk1/
oradata/prod/system01.dbf' is media corrupt
Impact: Object BLKTEST owned by SYS might be unavailable
4.
Proceed to determine how to repair the failures displayed by the LIST FAILURE
command as described in "Determining Repair Options".
15.2.2 Listing a Subset of Failures
Besides providing more verbose output, LIST FAILURE also enables you to restrict
output.
For example, you can execute LIST FAILURE with the CRITICAL, HIGH, LOW, or CLOSED
options to list only failures with a particular status or priority. You can also exclude
specified failures from the output by specifying EXCLUDE FAILURE.
To list a subset of failures:
1.
Start RMAN and connect to a target database. The target database instance must
be started.
15-9
Chapter 15
Checking for Block Corruptions by Validating the Database
2.
Execute LIST FAILURE with the desired options.
The following examples illustrate some LIST FAILURE commands:
LIST FAILURE LOW;
LIST FAILURE CLOSED;
LIST FAILURE EXCLUDE FAILURE 234234;
See Also:
Oracle Database Backup and Recovery Reference to learn about the LIST
FAILURE command
15.3 Checking for Block Corruptions by Validating the
Database
The database invokes data integrity checks reactively when a user transaction is trying
to access corrupted data. In some cases, latent failures can go undetected.
For example, when a data block corruption error occurs, the database reactively
execute a data integrity check that validates the block on which the error occurred and
other blocks in its immediate vicinity. However, blocks outside of the vicinity may be
corrupted. Also, corrupted blocks that are never read by the database are never
detected by a reactive data integrity check.
One effective way to execute a data integrity check proactively is to run the VALIDATE or
BACKUP VALIDATE commands in RMAN. These commands can check data files and
control files for physical and logical corruption. If RMAN discovers block corruptions,
then it logs them into the Automatic Diagnostic Repository and creates one or more
failures. You can then use Data Recovery Advisor to list information about the failures
and repair them.
To validate the database:
1.
Start RMAN and connect to a target database. The target database must be
mounted.
2.
Validate the desired database files.
The following example uses VALIDATE DATABASE to check for physical and logical
corruption in the whole database (partial sample output included). Because
"Listing Failures" indicates that some data files are missing, the SKIP INACCESSIBLE
clause is specified. The output shows that the system01.dbf database file has one
newly corrupt block (Blocks Failing) and no blocks previously marked corrupt by
the database (Marked Corrupt).
RMAN> VALIDATE CHECK LOGICAL SKIP INACCESSIBLE DATABASE;
Starting validate at 23-APR-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=103 device type=DISK
could not access datafile 28
skipping inaccessible file 28
RMAN-06060: WARNING: skipping datafile compromises tablespace USERS
recoverability
15-10
Chapter 15
Checking for Block Corruptions by Validating the Database
RMAN-06060: WARNING: skipping datafile compromises tablespace USERS
recoverability
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf
input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf
input datafile file number=00022 name=/disk1/oradata/prod/undotbs01.dbf
input datafile file number=00023 name=/disk1/oradata/prod/cwmlite01.dbf
input datafile file number=00024 name=/disk1/oradata/prod/drsys01.dbf
input datafile file number=00025 name=/disk1/oradata/prod/example01.dbf
input datafile file number=00026 name=/disk1/oradata/prod/indx01.dbf
input datafile file number=00027 name=/disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:25
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ---------1
FAILED 0
3536
57600
637711
File Name: /disk1/oradata/prod/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ---------------Data
1
41876
Index
0
7721
Other
0
4467
.
.
.
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ---------27 OK
0
1272
1280
400914
File Name: /disk1/oradata/prod/tools01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ---------------Data
0
0
Index
0
0
Other
0
8
validate found one or more corrupt blocks
See trace file /disk1/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_2596.trc
for details
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type
Status Blocks Failing Blocks Examined
------------ ------ -------------- --------------SPFILE
OK
0
2
Control File OK
0
512
Finished validate at 23-APR-13
15-11
Chapter 15
Determining Repair Options
See Also:
•
About Data Integrity Checks
•
Validating Database Files and Backups
•
Oracle Database Backup and Recovery Reference to learn about the
VALIDATE command
•
Oracle Database Administrator’s Guide to learn about how Oracle
Database manages diagnostic data
15.4 Determining Repair Options
Use the ADVISE FAILURE command to display repair options after running LIST FAILURE
in an RMAN session. This command prints a summary of the failures and implicitly
closes all open failures that are repaired.
Where appropriate, the ADVISE FAILURE command presents a list of manual and
automated repair options. Manual options, which are categorized as either mandatory
or optional, appear first. In some cases, an optional manual fix can avoid more
extreme actions such as restoring and recovering data files. As a rule, use the repair
technique that has the least effect on the database and the least possibility for error.
See Also:
•
Determining Repair Options for All Failures
•
Determining Repair Options for a Subset of Failures
15.4.1 Determining Repair Options for All Failures
If one or more failures exist, then you typically use LIST FAILURE to show information
about the failures and then ADVISE FAILURE in the same RMAN session to obtain a
report of your repair options.
To determine repair options for all failures:
1.
List failures as described in "Listing All Failures".
2.
In the same RMAN session, execute ADVISE FAILURE.
The following example requests repair options for all failures known to Data
Recovery Advisor and includes sample output (reformatted to fit the page).
RMAN> ADVISE FAILURE;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------142
HIGH
OPEN
23-APR-13
One or more non-system datafiles
15-12
Chapter 15
Determining Repair Options
are missing
101
HIGH
OPEN
23-APR-13
Datafile 1: '/disk1/oradata/prod/
system01.dbf' contains one or more corrupt blocks
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved,
restore it
Automated Repair Options
========================
Option Repair Description
------ -----------------1
Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm
In the preceding example, ADVISE FAILURE reports two failures: a missing data file
and a data file with corrupt blocks. The command does not list mandatory manual
actions, but it suggests making sure that the missing data file was not accidentally
renamed or removed. The automated repair option involves block media recovery
and restoring and recovering the missing data file. ADVISE FAILURE lists the location
of the repair script.
The following variation of the same example shows the output when the RMAN
backups or archived redo logs needed for the automated repair are not available.
The command ADVISE FAILURE now shows mandatory manual actions.
RMAN> ADVISE FAILURE;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------142
HIGH
OPEN
23-APR-13
One or more non-system datafiles
are missing
101
HIGH
OPEN
23-APR-13
Datafile 1:
'/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=103 device type=DISK
analyzing automatic repair options complete
Mandatory Manual Actions
========================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or
moved, restore it
2. Contact Oracle Support Services if the preceding recommendations cannot be
used, or if they do not fix the failures selected for repair
15-13
Chapter 15
Determining Repair Options
Optional Manual Actions
=======================
no manual actions available
Automated Repair Options
========================
Option Repair Description
------ -----------------1
Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_1863891774.hm
3.
Proceed to "Repairing Failures" to determine how to repair the failures shown in
the LIST FAILURE output.
15.4.2 Determining Repair Options for a Subset of Failures
You can also request repair options for specific failures. You can specify failures by
status (CRITICAL, HIGH, or LOW) or by failure number. You can also use EXCLUDE FAILURE
to exclude one or more failures from the report.
To determine repair options for a subset of failures:
1.
List failures as described in "Listing All Failures".
2.
In the same RMAN session, execute ADVISE FAILURE with the desired options.
The following example requests repair options for failure 101 only.
RMAN> ADVISE FAILURE 101;
List of Database Failures
=========================
Failure ID Priority Status
---------- -------- --------101
HIGH
OPEN
system01.dbf' contains one or
Time Detected Summary
------------- ------23-APR-13
Datafile 1: '/disk1/oradata/prod/
more corrupt blocks
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
no manual actions available
Automated Repair Options
========================
Option Repair Description
------ -----------------1
Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_708819503.htm
3.
Proceed to "Repairing Failures" to determine how to repair the failures displayed
by the LIST FAILURE command.
15-14
Chapter 15
Repairing Failures
See Also:
Oracle Database Backup and Recovery Reference to learn about the ADVISE
FAILURE command
15.5 Repairing Failures
You can use Data Recovery Advisor to repair failures automatically.
This section contains the following topics:
•
About Repairing Failures
•
Repairing a Failure
15.5.1 About Repairing Failures
If ADVISE FAILURE suggests manual repairs, then try these first. If manual repairs are
not possible, or if they do not repair all failures, then you can use REPAIR FAILURE to
automatically fix failures suggested in the most recent ADVISE FAILURE command in
your current RMAN session.
By default, REPAIR FAILURE prompts for confirmation before it begins executing. You
can suppress the confirmation prompt by specifying the NOPROMPT option. After it starts
executing, the command indicates the current phase of repair. Depending on the
circumstances, RMAN may prompt for a response. After executing a repair, RMAN
reevaluates all existing failures on the chance that they may have been fixed during
this repair.
While repairing a failure, wherever possible, RMAN takes a file online, restores and
recovers it, and then brings it back online again. You can repair failures for a selected
database, tablespace, or data file.
Before performing a repair, it is typically advisable to preview it by specifying the
PREVIEW option. RMAN does not make any repairs and generates a script with all repair
actions and comments. If you do not specify a particular repair option, then RMAN
uses the first repair option of the most recent ADVISE FAILURE command in the current
session. By default the repair script is displayed to standard output. You can use the
SPOOL command to write the script to an editable file.
See Also:
•
Oracle Database Backup and Recovery Reference to learn about the
REPAIR FAILURE command
•
Oracle Database Backup and Recovery Reference to learn about the
SPOOL command
15-15
Chapter 15
Repairing Failures
15.5.2 Repairing a Failure
By default the script is displayed to standard output. You can use the SPOOL command
to write the script to an editable file.
To repair a failure:
1.
List failures as described in "Listing All Failures".
2.
Display repair options as described in "Determining Repair Options".
3.
Optionally, execute REPAIR FAILURE PREVIEW.
The following example previews the first repair options displayed by the previous
ADVISE FAILURE command in the RMAN session.
RMAN> REPAIR FAILURE PREVIEW;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover datafile
sql 'alter database datafile 28 offline';
restore datafile 28;
recover datafile 28;
sql 'alter database datafile 28 online';
# block media recovery
recover datafile 1 block 56416;
4.
Execute REPAIR FAILURE.
The following repair restores and recovers one data file and performs block media
recovery on one corrupt block. RMAN prompts for confirmation that it should
perform the repair. The user-entered text is in bold.
RMAN> REPAIR FAILURE;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover data file
sql 'alter database datafile 28 offline';
restore datafile 28;
recover datafile 28;
sql 'alter database datafile 28 online';
# block media recovery
recover datafile 1 block 56416;
Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script
sql statement: alter database datafile 28 offline
Starting restore at 23-APR-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00028 to /disk1/oradata/prod/users01.dbf
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2013_04_18/
o1_mf_nnndf_TAG20130418T182042_32fjzd3z_.bkp
15-16
Chapter 15
Changing Failure Status and Priority
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2013_04_18/
o1_mf_nnndf_TAG20130418T182042_32fjzd3z_.bkp tag=TAG20130418T182042
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 23-APR-13
Starting recover at 23-APR-13
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 23-APR-13
sql statement: alter database datafile 28 online
Starting recover at 23-APR-13
using channel ORA_DISK_1
searching flashback logs for block images until SCN 429690
finished flashback log search, restored 1 blocks
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 23-APR-13
repair failure complete
5.
Optionally, execute LIST FAILURE to confirm
15.6 Changing Failure Status and Priority
In some situations, you may want to use the CHANGE FAILURE command to alter the
status or priority of a failure.
For example, if a block corruption has HIGH priority, you may want to change it to LOW
temporarily if the block is in a little-used tablespace.
If you repair a failure by a means other than the REPAIR FAILURE command, then Data
Recovery Advisor closes it implicitly the next time you execute LIST FAILURE. For this
reason, you do not normally need to execute the CHANGE FAILURE ... CLOSED command.
You need to use this command only if the automatic failure revalidation fails, but you
believe the failure no longer exists. If you use CHANGE FAILURE to close a failure that still
exists, then Data Recovery Advisor re-creates it with a different failure ID when the
appropriate data integrity check is executed.
Typically, you specify the failures to change by failure number. You can also change
failures in bulk by specifying ALL, CRITICAL, HIGH, or LOW. You can change a failure to
CLOSED or to PRIORITY HIGH or PRIORITY LOW.
To change the status or priority of a failure:
1.
List failures as described in "Listing All Failures".
The following example lists one failure involving corrupt data blocks.
RMAN> LIST FAILURE;
List of Database Failures
=========================
15-17
Chapter 15
Changing Failure Status and Priority
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------142
HIGH
OPEN
23-APR-13
One or more non-system datafiles
are missing
101
HIGH
OPEN
23-APR-13
Datafile 25: '/disk1/oradata/prod/
example01.dbf' contains one or more corrupt blocks
2.
Execute CHANGE FAILURE with the desired options.
The following example changes the priority of a block corruption failure from HIGH
to LOW.
RMAN> CHANGE FAILURE 101 PRIORITY LOW;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected
---------- -------- --------- ------------101
HIGH
OPEN
23-APR-13
example01.dbf' contains one or more corrupt
Summary
------Datafile 25: '/disk1/oradata/prod/
blocks
Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority
3.
Optionally, execute LIST FAILURE ALL to view the change.
If you execute LIST FAILURE without ALL, then the command lists failures with LOW
priority only if no CRITICAL or HIGH priority failures exist.
RMAN> LIST FAILURE ALL;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected Summary
---------- -------- --------- ------------- ------142
HIGH
OPEN
23-APR-13
One or more non-system datafiles
are missing
101
LOW
OPEN
23-APR-13
Datafile 25: '/disk1/oradata/prod/
example01.dbf' contains one or more corrupt blocks
See Also:
Oracle Database Backup and Recovery Reference to learn about the CHANGE
command
15-18
16
Validating Database Files and Backups
This chapter explains how to check the integrity of database files and backups. This
chapter contains the following topics:
•
Overview of RMAN Validation
•
Checking for Block Corruption with the VALIDATE Command
•
Validating Database Files with BACKUP VALIDATE
•
Validating Backups Before Restoring Them
•
Validating CDBs and PDBs
16.1 Overview of RMAN Validation
Validation enables you to check the integrity of your backups.
16.1.1 Purpose of RMAN Validation
The main purpose of RMAN validation is to check for corrupt blocks and missing files.
You can also use RMAN to determine whether backups can be restored.
You can use the following RMAN commands to perform validation:
•
VALIDATE
•
BACKUP ... VALIDATE
•
RESTORE ... VALIDATE
See Also:
•
Oracle Database Backup and Recovery Reference for VALIDATE syntax
•
Oracle Database Backup and Recovery Reference for RESTORE ...
VALIDATE syntax
16.1.2 Basic Concepts of RMAN Validation
The database prevents operations that result in unusable backup files or corrupted
restored data files.
The database automatically does the following:
•
Blocks access to data files while they are being restored or recovered
•
Permits only one restore operation for each data file at a time
•
Ensures that incremental backups are applied in the correct order
16-1
Chapter 16
Overview of RMAN Validation
•
Stores information in backup files to allow detection of corruption
•
Checks a block every time it is read or written in an attempt to report a corruption
as soon as it has been detected
16.1.2.1 About Checksums and Corrupt Blocks
A corrupt block is a block that has been changed so that it differs from what Oracle
Database expects to find.
Block corruptions can be caused by several different failures including, but not limited
to the following:
•
Faulty disks and disk controllers
•
Faulty memory
•
Oracle Database software defects
DB_BLOCK_CHECKSUM is a database initialization parameter that controls the writing of
checksums for the blocks in data files and online redo log files in the database (not
backups). If DB_BLOCK_CHECKSUM is typical, then the database computes a checksum for
each block during normal operations and stores it in the header of the block before
writing it to disk. When the database reads the block from disk later, it recomputes the
checksum and compares it to the stored value. If the values do not match, then the
block is corrupt.
By default, the BACKUP command computes a checksum for each block and stores it in
the backup. The BACKUP command ignores the values of DB_BLOCK_CHECKSUM because
this initialization parameter applies to data files in the database, not backups.
16.1.2.2 About Physical and Logical Block Corruption
In a physical corruption, which is also called a media corruption, the database does
not recognize the block at all: the checksum is invalid, the block contains all zeros, or
the header and footer of the block do not match.
Note:
By default, the BACKUP command computes a checksum for each block and
stores it in the backup. If you specify the NOCHECKSUM option, then RMAN does
not perform a checksum of the blocks when creating the backup.
In a logical corruption, the contents of the block are logically inconsistent. Examples of
logical corruption include corruption of a row piece or index entry. If RMAN detects
logical corruption, then it logs the block in the alert log and server session trace file.
By default, RMAN does not check for logical corruption. If you specify CHECK LOGICAL on
the BACKUP command, however, then RMAN tests data and index blocks for logical
corruption, such as corruption of a row piece or index entry, and log them in the alert
log located in the Automatic Diagnostic Repository (ADR). If you use RMAN with the
following configuration when backing up or restoring files, then it detects all types of
block corruption that are possible to detect:
16-2
Chapter 16
Overview of RMAN Validation
•
In the initialization parameter file of a database, set DB_BLOCK_CHECKSUM=typical so
that the database calculates data file checksums automatically (not for backups,
but for data files in use by the database)
•
Do not precede the BACKUP command with SET MAXCORRUPT so that RMAN does not
tolerate any unmarked block corruptions.
•
In a BACKUP command, do not specify the NOCHECKSUM option so that RMAN
calculates a checksum when writing backups
•
In BACKUP and RESTORE commands, specify the CHECK LOGICAL option so that RMAN
checks for logical and physical corruption
16.1.2.3 About Limits for Corrupt Blocks in RMAN Backups
You can use the SET MAXCORRUPT command to set the total number of unmarked
corruptions permitted in a file for RMAN backups. The default is zero, meaning that
RMAN does not tolerate unmarked corrupt blocks of any kind.
If the MAXCORRUPT limit is exceeded when RMAN encounters an unmarked corrupt block
during a backup, then RMAN terminates the backup. Otherwise, RMAN writes the
newly detected corrupt block to the backup with a special header indicating that the
block is marked corrupt. You can use the VALIDATE command to determine which
blocks are marked as corrupt and to find any unmarked corrupt blocks.
Because RMAN allows marked corrupt blocks in a backup, and because RMAN can
be instructed to allow unmarked corrupt blocks to be marked as corrupt in the backup
(when MAXCORRUPT is used), it is possible to restore a data file that has several blocks
marked as corrupt. If you backup this restored data file (assuming no new corruptions
have happened), even without MAXCORRUPT setting, the backup succeeds. This is
because the previously marked corruptions do not stop RMAN from completing the
backup.
See Also:
Oracle Database Backup and Recovery Reference for SET MAXCORRUPT syntax
16.1.2.4 About Detecting Block Corruption
Oracle Database supports different techniques for detecting, repairing, and monitoring
block corruption.
The technique depends on whether the corruption is interblock corruption or intrablock
corruption. In intrablock corruption, the corruption occurs within the block itself. This
corruption can be either physical or logical. In an interblock corruption, the corruption
occurs between blocks and can only be logical.
For example, the V$DATABASE_BLOCK_CORRUPTION view records intrablock corruptions,
while the Automatic Diagnostic Repository (ADR) tracks all types of corruptions.
Table 16-1 summarizes how the database treats different types of block corruption.
16-3
Chapter 16
Checking for Block Corruption with the VALIDATE Command
Table 16-1
Detection, Repair, and Monitoring of Block Corruption
Response
Intrablock Corruption
Interblock Corruption
Detection
All database utilities detect intrablock corruption, Only DBVERIFY and the ANALYZE statement
including RMAN (for example, the BACKUP
detect interblock corruption.
command) and the DBVERIFY utility. If a
database process can encounter the ORA-1578
error, then it can detect the corruption and
monitor it.
Tracking
The V$DATABASE_BLOCK_CORRUPTION view
displays blocks marked corrupt by Oracle
Database components such as RMAN
commands, ANALYZE, SQL queries, and so on.
Any process that encounters an intrablock
corruption records the block corruption in this
view and in ADR.
The database monitors this type of block
corruption in ADR.
Repair
Repair techniques include block media
recovery, restoring data files, recovering with
incremental backups, and block newing. Block
media recovery can repair physical corruptions,
but not logical corruptions.
You must fix interblock corruption using manual
techniques such as dropping an object,
rebuilding an index, and so on.
Any RMAN command that fixes or detects that a
block is repaired updates
V$DATABASE_BLOCK_CORRUPTION. For example,
RMAN updates the repository at end of
successful block media recovery. If a BACKUP,
RESTORE, or VALIDATE command detects that a
block is no longer corrupted, then it removes the
repaired block from the view.
See Also:
•
Performing Complete Database Recovery
•
Performing Block Media Recovery
•
Oracle Database Administrator’s Guide to learn about ADR
16.2 Checking for Block Corruption with the VALIDATE
Command
You can use the VALIDATE command to manually check for physical and logical
corruptions in database files.
This command performs the same types of checks as BACKUP VALIDATE, but VALIDATE
can check a larger selection of objects. For example, you can validate individual
blocks with the VALIDATE DATAFILE ... BLOCK command.
To specify a copy number for the backup piece being validated, run the VALIDATE FROM
COPY NUMBER command.
16-4
Chapter 16
Checking for Block Corruption with the VALIDATE Command
When validating whole files, RMAN checks every block of the input files. If the backup
validation discovers previously unmarked corrupt blocks, then RMAN updates the
V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions.
Use VALIDATE BACKUPSET when you suspect that one or more backup pieces in a backup
set are missing or have been damaged. This command checks every block in a
backup set to ensure that the backup can be restored. If RMAN finds block corruption,
then it issues an error and terminates the validation. The command VALIDATE BACKUPSET
enables you to choose which backups to check, whereas the VALIDATE option of the
RESTORE command lets RMAN choose.
To use VALIDATE to check database files and backups:
1.
Start RMAN and connect to a target database.
See Also:
"Making Database Connections with RMAN"
2.
Execute the VALIDATE command with the desired options.
For example, to validate all data files and control files (and the server parameter
file if one is in use), execute the following command at the RMAN prompt:
RMAN> VALIDATE DATABASE;
Alternatively, you can validate a particular backup set by using the form of the
command shown in the following example (sample output included).
RMAN> VALIDATE BACKUPSET 22;
Starting validate at 17-AUG-13
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=89 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece
/disk1/oracle/work/orcva/RDBMS/backupset/2013_08_16/o1_mf_nnndf_
TAG20130816T153034_2g774bt2_.bkp
channel ORA_DISK_1: piece
handle=/disk1/oracle/work/orcva/RDBMS/backupset/2013_08_16/o1_mf_nnndf_
TAG20130816T153034_2g774bt2_.bkp tag=TAG20130816T153034
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
Finished validate at 17-AUG-13
The following example illustrates how you can check individual data blocks within
a data file for corruption.
RMAN> VALIDATE DATAFILE 1 BLOCK 10;
Starting validate at 17-AUG-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
16-5
Chapter 16
Validating Database Files with BACKUP VALIDATE
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ---------1
OK
0
2
127
481907
File Name: /disk1/oracle/dbs/tbs_01.f
Block Type Blocks Failing Blocks Processed
---------- -------------- ---------------Data
0
36
Index
0
31
Other
0
58
Finished validate at 17-AUG-13
Make Parallel the Validation of a Data File
If you must validate a large data file, then RMAN can make the work parallel by
dividing the file into sections and processing each file section in parallel. If multiple
channels are configured or allocated, and if you want the channels to make parallel the
validation, then specify the SECTION SIZE parameter of the VALIDATE command.
If you specify a section size that is larger than the size of the file, then RMAN does not
create file sections. If you specify a small section size that would produce more than
256 sections, then RMAN increases the section size to a value that results in exactly
256 sections.
To make parallel the validation of a data file:
1.
Start RMAN and connect to a target database. The target database must be
mounted or open.
2.
Run VALIDATE with the SECTION SIZE parameter.
The following example allocates two channels and validates a large data file. The
section size is 1200 MB.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
VALIDATE DATAFILE 1 SECTION SIZE 1200M;
}
See Also:
•
•
"Dividing the Backup of a Large Data File into Sections"
Oracle Database Backup and Recovery Reference to learn about the
VALIDATE command
16.3 Validating Database Files with BACKUP VALIDATE
You can also use the BACKUP VALIDATE command to perform validation.
This command can perform the following tasks:
•
Check data files for physical and logical block corruption
16-6
Chapter 16
Validating Database Files with BACKUP VALIDATE
•
Confirm that all database files exist and are in the correct locations
When you run BACKUP VALIDATE, RMAN reads the files to be backed up in their entirety,
as it does during a real backup. RMAN does not, however, actually produce any
backup sets or image copies.
You cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP VALIDATE.
To validate specific backup sets, run the VALIDATE command.
To validate files with the BACKUP VALIDATE command:
1.
Start RMAN and connect to a target database and recovery catalog (if used).
2.
Run the BACKUP VALIDATE command.
For example, you can validate that all database files and archived logs can be
backed up by running a command as shown in the following example. This
command checks for physical corruptions only.
BACKUP VALIDATE
DATABASE
ARCHIVELOG ALL;
To check for logical corruptions in addition to physical corruptions, run the
following variation of the preceding command:
BACKUP VALIDATE
CHECK LOGICAL
DATABASE
ARCHIVELOG ALL;
In the preceding examples, the RMAN client displays the same output as when
really backing up the files. If RMAN cannot back up one or more of the files, then it
issues an error message. For example, RMAN may show output similar to the
following:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2013 14:33:47
ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
See Also:
•
Oracle Database Backup and Recovery Reference for BACKUP syntax
•
Performing Block Media Recoveryto learn how to repair corrupt blocks
discovered by BACKUP VALIDATE
16-7
Chapter 16
Validating Backups Before Restoring Them
16.4 Validating Backups Before Restoring Them
You can run RESTORE...VALIDATE to test whether RMAN can restore a specific file or set
of files from a backup. RMAN chooses which backups to use.
The database must be mounted or open for this command. You do not have to take
data files offline when validating the restore of data files, because validation of
backups of the data files only reads the backups and does not affect the production
data files.
When validating files on disk or tape, RMAN reads all blocks in the backup piece or
image copy. RMAN also validates offsite backups. The validation is identical to a real
restore operation except that RMAN does not write output files.
RMAN also allows to specify a copy number for the backup pieces being validated.
Note:
As an additional test measure, you can perform a trial recovery with the
RECOVER ... TEST command. A trial recovery applies redo in a way similar to
normal recovery, but it is in memory only and it rolls back its changes after
the trial.
To validate backups with the RESTORE command:
1.
Run the RESTORE command with the VALIDATE option.
This following example illustrates validating the restore of the database and all
archived redo logs:
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;
If you do not see an RMAN error stack, then skip the subsequent steps. The lack
of error messages means that RMAN had confirmed that it can use these backups
successfully during a real restore and recovery.
2.
If you see error messages in the output and the RMAN-06026 message, then
investigate the cause of the problem. If possible, correct the problem that is
preventing RMAN from validating the backups and retry the validation.
The following error means that RMAN cannot restore one or more of the specified
files from your available backups:
RMAN-06026: some targets not found - aborting restore
The following sample output shows that RMAN encountered a problem reading the
specified backup:
RMAN-03009: failure of restore command on c1 channel at 12-DEC-12 23:22:30
ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
16-8
Chapter 16
Validating CDBs and PDBs
See Also:
Oracle Database Backup and Recovery Reference to learn about the
RESTORE...VALIDATE command
16.5 Validating CDBs and PDBs
RMAN enables you to validate multitenant container databases (CDBs) and pluggable
databases (PDBs) using the VALIDATE command.
You can also choose to specify a copy number for the backup pieces being validated
for both CDBs and PDBs.
All of the procedures in this chapter apply to CDBs, with the differences described in
the following sections:
•
Validating a Whole CDB
•
Validating PDBs
16.5.1 Validating a Whole CDB
The steps to validate a CDB are similar to the ones used to validate a non-CDB.
The only difference is that you must connect to the root as a common user with the
common SYSBACKUP or SYSDBA privilege. Then, use the VALIDATE DATABASE and RESTORE
DATABASE VALIDATE commands.
See Also:
"Making RMAN Connections to a CDB"
The following command, when connected to the root, validates the whole CDB:
VALIDATE DATABASE;
The following command validates the root:
VALIDATE DATABASE ROOT;
16.5.2 Validating PDBs
There are multiple methods to validate PDBs.
Use one of the following techniques to validate PDBs:
•
Connect to the root and use the VALIDATE PLUGGABLE DATABASE or RESTORE PLUGGABLE
DATABASE VALIDATE command. This enables you to validate one or more PDBs.
The following command, when connected to the root, validates the PDBs hr_pdb
and sales_pdb.
VALIDATE PLUGGABLE DATABASE hr_pdb, sales_pdb;
16-9
Chapter 16
Validating CDBs and PDBs
•
Connect to the PDB and use the VALIDATE DATABASE and RESTORE DATABASE VALIDATE
commands to validate only one PDB. The commands used here are the same
commands that you would use for a non-CDB.
The following command, when connected to a PDB, validates the restore of the
database.
RESTORE DATABASE VALIDATE;
See Also:
"Making RMAN Connections to a CDB"
16-10
17
Performing Complete Database Recovery
This chapter explains how to use RMAN to return your database to normal operation
after the loss of one or more data files. This chapter contains the following topics:
•
Overview of Complete Database Recovery
•
Preparing for Complete Database Recovery
•
Performing Complete Database Recovery
•
Performing Complete Recovery of CDBs
•
Performing Complete Recovery of Application Containers
•
Performing Complete Recovery of Sparse Databases with RMAN
17.1 Overview of Complete Database Recovery
Complete recovery returns your database to normal operation after the loss of one or
more database files.
This section contains the following topics:
•
Purpose of Complete Database Recovery
•
Scope of This Chapter
•
About Real-time Redo Transport for Recovery Appliance
17.1.1 Purpose of Complete Database Recovery
Complete recovery is recovering a database to the most recent point in time, without
the loss of any committed transactions.
This chapter assumes that some or all of your data files are lost or damaged.
Typically, this situation is caused by a media failure or accidental deletion. Your goal is
to return the database to normal operation by restoring the damaged files from RMAN
backups and recovering all database changes.
17.1.2 Scope of This Chapter
The complete recovery operations described in this chapter are subject to certain
conditions.
This chapter makes the following assumptions:
•
You have lost some or all data files and your goal is to recover all changes, but
you have not lost all current control files or an entire online redo log group.
•
Your database is using the current server parameter file.
•
You have the complete set of archived redo logs and incremental backups needed
for recovery of your data file backups. Every data file either has a backup, or a
17-1
Chapter 17
Overview of Complete Database Recovery
complete set of online and archived redo logs goes back to the creation of a data
file with no backup.
RMAN can handle lost data files without user intervention during restore and
recovery. When a data file is lost, the possible cases can be classified as follows:
•
–
The control file knows about the data file, that is, you backed up the control file
after data file creation, but the data file itself is not backed up. If the data file
record is in the control file, then RESTORE creates the data file in the original
location or in a user-specified location. The RECOVER command can then apply
the necessary logs to the data file.
–
The control file does not have the data file record, that is, you did not back up
the control file after data file creation. During recovery, the database detects
the missing data file and reports it to RMAN, which creates a data file and
continues recovery by applying the remaining logs. If the data file was created
in a parent incarnation, then it is created during the restore or recovery phase
as appropriate.
You are not restoring and recovering an encrypted tablespace.
If you perform media recovery on an encrypted tablespace, then the Oracle
keystore must be open when performing media recovery of this tablespace.
•
Your database runs in a single-instance configuration.
Although RMAN can restore and recover databases in Oracle RAC and Data
Guard configurations, these scenarios are beyond the scope of this manual.
•
You are using the RMAN client rather than Oracle Enterprise Manager.
See Also:
•
" Performing Flashback and Database Point-in-Time Recovery" for
information about recovering some but not all database changes
•
"Performing Recovery with a Backup Control File" for information about
recovering the database when all control files are lost
•
"Restoring the Server Parameter File" for information about restoring a
backup server parameter file
17.1.3 About Real-time Redo Transport for Recovery Appliance
Zero Data Loss Recovery Appliance (Recovery Appliance) substantially reduces the
window of potential data loss that exists between successive archived redo log
backups. You to recover target databases to within a few subseconds of a database
failure.
When real-time redo transport is configured for a target database, redo data from the
current redo log groups is written asynchronously to Recovery Appliance as it is
generated. As the redo stream is received, it is stored as a complete RMAN archived
redo log. If the target database crashes, the redo data received from the current redo
log group, until the time of the crash, is used during restore and recovery operations.
You must perform certain configuration steps to enable real-time redo transport for the
target database.
17-2
Chapter 17
Preparing for Complete Database Recovery
Note:
Real-time redo transport can be used only with Recovery Appliance.
See Also:
Zero Data Loss Recovery Appliance Protected Databases Configuration
Guide for the steps to configure real-time redo transport
17.2 Preparing for Complete Database Recovery
You must plan your database restore and recovery strategy based on your recovery
goal and which database files have been lost.
This section contains the following topics:
•
Identifying the Database Files to Restore or Recover
•
Determining the DBID of the Database
•
Previewing Backups Used in Restore Operations
•
Validating Backups Before Restoring Them
•
Restoring Archived Redo Logs Needed for Recovery
•
Providing the Password Required to Decrypt Encrypted Backups
17.2.1 Identifying the Database Files to Restore or Recover
The techniques for determining which files require restore or recovery depend upon
the type of file that is lost.
This section contains the following topics:
•
Identifying a Lost Control File
•
Identifying Data Files Requiring Media Recovery
17.2.1.1 Identifying a Lost Control File
The database shuts down immediately when any of the multiplexed control files
become inaccessible.
If you try to start the database without a valid control file at each location specified in
the CONTROL_FILES initialization parameter, then the database reports an error.
Loss of some but not all copies of your control file does not require you to restore a
control file from backup. If at least one control file remains intact, then you can either
copy an intact copy of the control file over the damaged or missing control file, or
update the initialization parameter file so that it does not refer to the damaged or
missing control file. After the CONTROL_FILES parameter references only present, intact
copies of the control file, you can restart your database.
17-3
Chapter 17
Preparing for Complete Database Recovery
If you restore the control file from backup, then you must perform media recovery of
the whole database and then open it with the OPEN RESETLOGS option, even if no data
files must be restored. This technique is described in "Performing Recovery with a
Backup Control File".
17.2.1.2 Identifying Data Files Requiring Media Recovery
The decision about when and how to recover depends on the state of the database
and the location of its data files.
Use RMAN or SQL*Plus to identify data files that require media recovery.
See Also:
•
Identifying Data Files with RMAN
•
Identifying Data Files with SQL
17.2.1.2.1 Identifying Data Files with RMAN
An easy technique for determining which data files are missing is to run a VALIDATE
DATABASE command.
Example 17-1
VALIDATE DATABASE
This example validates the database and tries to read all specified data files (sample
output included).
RMAN> VALIDATE DATABASE;
Starting validate at 20-OCT-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=90 device type=DISK
could not read file header for datafile 7 error reason 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/20/2013 13:05:43
RMAN-06056: could not access datafile 7
The output of VALIDATE DATABASE command indicates that data file 7 is inaccessible.
You can then run the REPORT SCHEMA command to obtain the tablespace name and file
name for data file 7 as follows (sample output included):
RMAN> REPORT SCHEMA;
Report of database schema for database with db_unique_name RDBMS
List of Permanent Datafiles
===========================
File Size(MB) Tablespace
---- -------- -------------------1
450
SYSTEM
2
86
SYSAUX
3
15
UD1
4
2
SYSTEM
RB segs
------***
***
***
***
Datafile Name
-----------------------+DATAFILE/tbs_01.f
+DATAFILE/tbs_ax1.f
+DATAFILE/tbs_undo1.f
+DATAFILE/tbs_02.f
17-4
Chapter 17
Preparing for Complete Database Recovery
5
6
7
2
2
2
TBS_1
TBS_1
TBS_2
***
***
***
+DATAFILE/tbs_11.f
+DATAFILE/tbs_12.f
+DATAFILE/tbs_21.f
List of Temporary Files
=======================
File Size(MB) Tablespace
Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- -------------------1
40
TEMP
32767
+DATAFILE/tbs_tmp1.f
17.2.1.2.2 Identifying Data Files with SQL
Although VALIDATE DATABASE is a good technique for determining whether files are
inaccessible, you may want to use SQL queries to obtain more detailed information.
To determine whether data files require media recovery:
1.
Start SQL*Plus and connect to the target database instance with administrator
privileges.
2.
Determine the status of the database by executing the following SQL query:
SELECT STATUS FROM V$INSTANCE;
If the status is OPEN, then the database is open. Nevertheless, some data files may
require media recovery.
3.
Query V$DATAFILE_HEADER to determine the status of your data files. Run the
following SQL statements to check the data file headers:
SELECT
FROM
WHERE
OR
FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME
V$DATAFILE_HEADER
RECOVER = 'YES'
(RECOVER IS NULL AND ERROR IS NOT NULL);
Each row returned represents a data file that either requires media recovery or has
an error requiring a restore. Check the RECOVER and ERROR columns. RECOVER
indicates whether a file needs media recovery, and ERROR indicates whether there
was an error reading and validating the data file header.
If ERROR is not NULL, then the data file header cannot be read and validated. Check
for a temporary hardware or operating system problem causing the error. If there
is no such problem, then you must restore the file or switch to a copy.
If the ERROR column is NULL and the RECOVER column is YES, then the file requires
media recovery (and may also require a restore from backup).
Note:
Because V$DATAFILE_HEADER only reads the header block of each data file,
it does not detect all problems that require the data file to be restored.
For example, this view cannot tell whether a data file contains corrupt
data blocks.
4.
Optionally, query V$RECOVER_FILE to list data files requiring recovery by data file
number with their status and error information. For example, execute the following
query:
17-5
Chapter 17
Preparing for Complete Database Recovery
SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM V$RECOVER_FILE;
Note:
You cannot use V$RECOVER_FILE with a control file restored from backup
or a control file that was re-created after the time of the media failure
affecting the data files. A restored or re-created control file does not
contain the information needed to update V$RECOVER_FILE accurately.
To find data file and tablespace names, you can also perform joins using the data
file number and the V$DATAFILE and V$TABLESPACE views, as shown in the following
example.
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS 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#;
The ERROR column identifies the problem for each file requiring recovery.
See Also:
•
V$DATAFILE_HEADER in Oracle Database Reference
•
V$RECOVER_FILE in Oracle Database Reference
•
V$DATAFILE in Oracle Database Reference
•
V$TABLESPACE in Oracle Database Reference
17.2.2 Determining the DBID of the Database
It is recommended that you record the DBID of your database.
In situations requiring the recovery of your server parameter file or control file from
autobackup, you must know the DBID. Be sure to record the DBID along with other
basic information about your database.
If you do not have a record of the DBID of your database, then you can find it in the
following places without opening your database:
•
The DBID is used in forming the file name for the control file autobackup. Locate
this file, and then refer to "Configuring the Control File Autobackup Format" to
determine where the DBID appears in the file name.
•
If you have any text files that preserve the output from an RMAN session, then the
DBID is displayed by the RMAN client when it starts up and connects to your
database. Typical output follows:
% rman TARGET /
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Jan 16 17:51:30 2013
17-6
Chapter 17
Preparing for Complete Database Recovery
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
connected to target database: PROD (DBID=36508508)
17.2.3 Previewing Backups Used in Restore Operations
Previewing backups helps you to ensure that all backups required for a restore and
recovery operation are available.
You can apply RESTORE ... PREVIEW to any RESTORE operation to create a detailed list of
every backup to be used in the requested RESTORE operation, and the necessary target
SCN for recovery after the RESTORE operation is complete. This command accesses the
RMAN repository to query the backup metadata, but does not actually read the backup
files to ensure that they can be restored.
As an alternative to RESTORE ... PREVIEW, you can use the RESTORE ... VALIDATE HEADER
command. In addition to listing the files needed for restore and recovery, the
RESTORE ... VALIDATE HEADER command validates the backup file headers to determine
whether the files on disk or in the media management catalog correspond to the
metadata in the RMAN repository.
When planning your restore and recovery operation, use RESTORE ... PREVIEW or
RESTORE ... VALIDATE HEADER to ensure that all required backups are available or to
identify situations in which you may want to direct RMAN to use or avoid specific
backups.
To preview backups to be used in a restore operation:
1.
Run a RESTORE command with the PREVIEW option.
For example, run one of the following commands:
RESTORE DATABASE PREVIEW;
RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW;
If the report produced by RESTORE ... PREVIEW provides too much information, then
specify the SUMMARY option as shown in the following example:
RESTORE DATABASE PREVIEW SUMMARY;
If you are satisfied with the output, then stop here. If the output indicates that
RMAN will request a backup from a tape that you know is temporarily unavailable,
then continue with this procedure. If the output indicates that a backup is stored
off-site, then skip to "Recalling Off-site Backups".
2.
If needed, use the CHANGE command to set the backup status of any temporarily
unavailable backups to UNAVAILABLE.
"Updating a Backup to Status AVAILABLE or UNAVAILABLE" explains how to
perform this task.
3.
Optionally, run RESTORE ... PREVIEW again to confirm that the restore operation
does not attempt to use unavailable backups.
17-7
Chapter 17
Preparing for Complete Database Recovery
See Also:
Oracle Database Backup and Recovery Referencefor details on interpreting
RESTORE ... PREVIEW output, which is in the same format as the output of the
LIST command
17.2.3.1 Recalling Off-site Backups
An offsite backup is stored in a remote location, such as a secure storage facility, and
cannot be restored unless the media manager retrieves the media.
Some media managers provide status information to RMAN about which backups are
off-site. Off-site backups are marked as AVAILABLE in the RMAN repository even though
the media must be retrieved from storage before the backup can be restored. If RMAN
attempts to restore an off-site backup, then the restore job fails.
To recall offsite backups:
1.
(Optional) Identify the off-site backups using the RESTORE ... PREVIEW command.
The command output indicates whether backups are stored off-site, as shown by
the text after the sample output in the following example.
List of Backup Sets
===================
BS Key Size
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------9
2.25M
SBT_TAPE
00:00:00
21-MAY-13
BP Key: 9 Status: AVAILABLE Compressed: NO Tag: TAG20130521T144258
Handle: 0aii9k7i_1_1 Media: 0aii9k7i_1_1
List
Thrd
---1
1
1
1
1
1
of Archived Logs in backup set 9
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------1
392314
21-MAY-13 392541
2
392541
21-MAY-13 392545
3
392545
21-MAY-13 392548
4
392548
21-MAY-13 395066
5
395066
21-MAY-13 395095
6
395095
21-MAY-13 395355
Next Time
--------21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
List of remote backup files
============================
Handle: aii9k7i_1_1 Media: 0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-13
released channel: dev1
You can use RESTORE ... PREVIEW RECALL to instruct the media manager to make offsite backups available.
2.
If backups are stored offsite, then execute a RESTORE ... PREVIEW command with
the RECALL option.
The following example initiates recall for the off-site archived log backups shown in
the previous step (sample output included):
17-8
Chapter 17
Preparing for Complete Database Recovery
RESTORE ARCHIVELOG ALL PREVIEW RECALL;
The following sample output indicates that RMAN initiated a recall:
List of Backup Sets
===================
BS Key Size
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------9
2.25M
SBT_TAPE
00:00:00
21-MAY-13
BP Key: 9 Status: AVAILABLE Compressed: NO Tag: TAG20130521T144258
Handle: VAULT0aii9k7i_1_1 Media: /tmp,VAULT0aii9k7i_1_1
List
Thrd
---1
1
1
1
1
1
of Archived Logs in backup set 9
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------1
392314
21-MAY-13 392541
2
392541
21-MAY-13 392545
3
392545
21-MAY-13 392548
4
392548
21-MAY-13 395066
5
395066
21-MAY-13 395095
6
395095
21-MAY-13 395355
Next Time
--------21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
21-MAY-13
Initiated recall for the following list of remote backup files
==========================================================
Handle: VAULT0aii9k7i_1_1 Media: /tmp,VAULT0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-13
released channel: dev1
3.
Run the RESTORE ... PREVIEW command. If necessary, return to the previous step
until no backups needed for the restore operation are reported as off-site.
17.2.4 Validating Backups Before Restoring Them
Validating backups determines if the backups are usable.
Although the output of a restore preview operation indicates which backups will be
restored, the usability of the backups is not actually verified. You can run RMAN
commands to test the availability of usable backups for any RESTORE operation, or test
the contents of a specific backup for use in RESTORE operations. The contents of the
backups are actually read and checked for corruption.
Use one of the following validation options:
•
RESTORE ... VALIDATE to test whether RMAN can restore a specific object from a
backup. RMAN chooses which backups to use.
•
VALIDATE BACKUPSET to test the validity of a backup set that you specify.
See Also:
Validating Database Files and Backups
17-9
Chapter 17
Preparing for Complete Database Recovery
17.2.5 Restoring Archived Redo Logs Needed for Recovery
RMAN restores archived redo log files from backup automatically as needed to
perform recovery.
You can also restore archived redo logs manually to save the time needed to restore
these files later during the RECOVER command, or if you want to store the restored
archived redo log files in some new location. RMAN also gives you the flexibility of
restoring all archive redo log files, the current ones, or archive redo log files from a
specified previous incarnation of the database.
In case of missing archived redo logs during disaster recovery, RMAN enables you to
automate the database recovery till the last available archived redo log, using the
UNTIL AVAILABLE REDO option. You can use this option only when performing recovery
for a whole database. Using this option for a data file, tablespace, or pluggable
database is not supported. To perform point-in-time recovery for a pluggable
database, you must provide the SCN number as the point of recovery.
By default, RMAN restores archived redo logs with names constructed using the
LOG_ARCHIVE_FORMAT and the highest LOG_ARCHIVE_DEST_n parameters of the target
database. These parameters are combined in a platform-specific fashion to form the
name of the restored archived log.
This section contains the following topics:
•
"Restoring Archived Redo Logs to a New Location"
•
"Restoring Archived Redo Logs to Multiple Locations"
17.2.5.1 Restoring Archived Redo Logs to a New Location
RMAN enables you to override the default location for restored archived redo log files.
The SET ARCHIVELOG DESTINATION command manually stages archived logs to different
locations while a database restore operation is occurring. During recovery, RMAN
knows where to find the newly restored archived logs; it does not require them to be in
the location specified in the initialization parameter file.
To restore archived redo logs to a new location:
1.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN".
2.
Ensure that the database is mounted or open.
3.
Perform the following operations within a RUN command:
a.
Specify the new location for the restored archived redo logs using SET
ARCHIVELOG DESTINATION.
b.
Either explicitly restore the archived redo logs or execute commands that
automatically restore the logs.
The following sample RUN command explicitly restores all backup archived logs to a
new location:
RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE ARCHIVELOG ALL;
17-10
Chapter 17
Preparing for Complete Database Recovery
# restore and recover data files as needed
.
.
.
}
The following example sets the archived log destination and then uses RECOVER
DATABASE to restore archived logs from this destination automatically:
RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE DATABASE;
RECOVER DATABASE; # restores and recovers logs automatically
}
17.2.5.2 Restoring Archived Redo Logs to Multiple Locations
To manage disk space that is used to contain the restored logs, you can specify
restore destinations for archived logs multiple times in one RUN block, to distribute
restored logs among several destinations.
Note that you cannot specify multiple destinations simultaneously to produce multiple
copies of the same log during the restore operation.
The following example restores 300 archived redo logs from backup, distributing them
across the directories /fs1/tmp, /fs2/tmp, and /fs3/tmp:
RUN
{
# Set a new location for logs 1 through 100.
SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
# Set a new location for logs 101 through 200.
SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
# Set a new location for logs 201 through 300.
SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
# restore and recover data files as needed
.
.
.
}
When you issue a RECOVER command, RMAN finds the needed restored archived logs
automatically across the destinations to which they were restored, and applies them to
the data files.
17.2.6 Providing the Password Required to Decrypt Encrypted
Backups
For backups encrypted using certain techniques, you must provide the password that
will be used to decrypt these backups.
•
Backups that were encrypted using transparent encryption with an auto-login
keystore require no intervention to restore, if the keystore is available. RMAN
decrypts these backups while restoring their contents.
17-11
Chapter 17
Performing Complete Database Recovery
•
For backups that were encrypted using transparent encryption with a passwordbased software keystore, the keystore must be available and the keystore
password must be provided before the restore operation is performed. Use the SET
command with the DECRYPTION WALLET OPEN IDENTIFIED BY option to specify the
password that must be used to open the password-based software keystore.
The following command sets the keystore password for a password-based
software keystore (where password is a placeholder for the actual password that
you enter):
SET DECRYPTION WALLET OPEN IDENTIFIED BY password;
•
Backups created using password-mode encryption require the correct password to
be entered before they can be restored. Use the SET DECRYPTION command to
specify the password used to decrypt the backups. If you are restoring from a
group of backups that were created with different passwords, then specify all of
the required passwords on the SET DECRYPTION command. RMAN automatically
uses the correct password with each backup set. The SET command must be used
before executing the RESTORE and RECOVER commands.
The following command sets the password used to decrypt backups (where
password is a placeholder for the actual password that you enter):
SET DECRYPTION IDENTIFIED BY password;
See Also:
Oracle Database Backup and Recovery Reference for additional information
about performing restore operations using encrypted backups
17.3 Performing Complete Database Recovery
During complete recovery RMAN restores one or more data files and then applies all
the redo generated after the restored backup.
This section describes the basic outline of complete database recovery, which is
intended to encompass a wide range of different scenarios.
This section contains the following topics:
•
About Complete Database Recovery
•
Performing Complete Recovery of the Whole Database
•
Performing Complete Recovery of a Tablespace
•
Performing Complete Recovery After Switching to a Copy
17.3.1 About Complete Database Recovery
You use the RESTORE and RECOVER commands to restore and recover the database.
During the recovery, RMAN automatically restores backups of any needed archived
redo logs. If backups are stored on a media manager, then channels must be
configured in advance or a RUN block with ALLOCATE CHANNEL commands must be used to
enable access to backups stored there.
17-12
Chapter 17
Performing Complete Database Recovery
If RMAN restores archived redo logs to the fast recovery area during a recovery, then
it automatically deletes the restored logs after applying them to the data files.
Otherwise, you can use the DELETE ARCHIVELOG command to delete restored archived
redo logs from disk when they are no longer needed for recovery. For example, you
can enter the following command:
RECOVER DATABASE DELETE ARCHIVELOG;
17.3.1.1 About Restoring Data Files to a Nondefault Location
If you cannot restore data files to their default locations, then you must update the
control file to reflect the new locations of the data files.
Use the RMAN SET NEWNAME command within a RUN command to specify the new file
name. Afterward, use a SWITCH command, which is equivalent to using the SQL
statement ALTER DATABASE RENAME FILE, to update the names of the data files in the
control file. SWITCH DATAFILE ALL updates the control file to reflect the new names for all
data files for which a SET NEWNAME has been issued in a RUN command.
See Also:
Oracle Database Backup and Recovery Reference for SWITCH syntax
17.3.2 Performing Complete Recovery of the Whole Database
This scenario assumes that database trgt has lost most or all of its data files. It also
assumes that the database uses a fast recovery area.
After restore and recovery of a whole database, when the database is open, missing
temporary tablespaces that were recorded in the control file are re-created with their
previous creation size, AUTOEXTEND, and MAXSIZE attributes. Only temporary tablespaces
that are missing are re-created. If a temp file exists at the location recorded in the
RMAN repository but has an invalid header, then RMAN does not re-create the temp
file.
If the temp files were created as Oracle-managed files, then they are re-created in the
current DB_CREATE_FILE_DEST location. Otherwise, they are re-created at their previous
locations. If RMAN cannot re-create the file due to an I/O error or some other cause,
then the error is reported in the alert log and the database open operation continues.
See Also:
"Scope of This Chapter" for some of the assumptions used in the recovery
procedures
To restore and recover the whole database:
1.
Complete the preparation steps required for your scenario, as described in
"Preparing for Complete Database Recovery".
17-13
Chapter 17
Performing Complete Database Recovery
2.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN".
RMAN displays the database status when it connects: not started, not mounted,
not open (when the database is mounted but not open), or none (when the
database is open).
3.
If the database is not mounted, then mount but do not open the database.
For example, enter the following command:
STARTUP MOUNT;
4.
Use the SHOW command to see which channels are preconfigured.
For example, enter the following command (sample output is included):
SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_
LIBRARY=/usr/local/oracle/backup/lib/libobk.so";
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
5.
Restore and recover the database. Do one of the following:
•
If you are restoring all data files to their original locations, then execute RESTORE
DATABASE and RECOVER DATABASE sequentially at the RMAN prompt.
For example, enter the following commands if automatic channels are
configured (sample output included):
RMAN> RESTORE DATABASE;
Starting restore at 20-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=35 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1:
channel ORA_DISK_1:
channel ORA_DISK_1:
channel ORA_DISK_1:
.
.
.
Finished restore at
starting datafile backup set restore
specifying datafile(s) to restore from backup set
restoring datafile 00001 to /disk1/oracle/dbs/tbs_01.f
restoring datafile 00002 to /disk1/oracle/dbs/tbs_ax1.f
20-JUN-13
RMAN> RECOVER DATABASE;
Starting recover at 20-JUN-13
17-14
Chapter 17
Performing Complete Database Recovery
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
.
.
.
channel ORA_DISK_1: reading from backup piece
/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece
handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp tag=TAG20130620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jhv47k_.arc thread=1 sequence=5
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:15
Finished recover at 20-JUN-13
If you manually allocate channels, then you must issue the RESTORE and
RECOVER commands together within a RUN block as shown in the following
example:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE DATABASE;
RECOVER DATABASE;
}
•
If you are restoring some data files to new locations, then execute RESTORE
DATABASE and RECOVER DATABASE sequentially in a RUN command. Use the SET
NEWNAME command to rename data files, as described in "About Restoring Data
Files to a Nondefault Location".
The following example restores the database, specifying new names for three
of the data files, and then recovers the database:
RUN
{
SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}
17-15
Chapter 17
Performing Complete Database Recovery
6.
Examine the output to see if media recovery was successful. If so, open the
database.
For example, enter the following command:
ALTER DATABASE OPEN;
17.3.3 Performing Complete Recovery of a Tablespace
Use the RESTORE and RECOVER commands with the TABLESPACE option to perform
complete recovery of a tablespace
Scope of This Chapter for some of the assumptions used in the recovery procedures
In the basic scenario, the database is open, and some but not all of the data files are
damaged. You want to restore and recover the damaged tablespace while leaving the
database open so that the rest of the database remains available. This scenario
assumes that database TRGT has lost tablespace USERS.
To restore and recover a tablespace:
1.
Complete the preparation steps that are required for your recovery scenario as
described in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to a target database as described in "Making Database
Connections with RMAN".
3.
If the database is open, then take the tablespace requiring recovery offline.
For example, enter the following command to take USERS offline:
ALTER TABLESPACE users OFFLINE IMMEDIATE;
4.
Use the SHOW command to see which channels are preconfigured.
For example, enter the following command (sample output is included):
SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_
LIBRARY=/usr/local/oracle/backup/lib/libobk.so";
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
5.
Restore and recover the tablespace. Do one of the following:
•
If you are restoring data files to their original locations, then run the RESTORE
TABLESPACE and RECOVER TABLESPACE commands at the RMAN prompt.
For example, enter the following command if automatic channels are
configured (sample output included):
RMAN> RESTORE TABLESPACE users;
17-16
Chapter 17
Performing Complete Database Recovery
Starting restore at 20-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=37 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=38 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00012 to /disk1/oracle/dbs/users01.f
channel ORA_DISK_1: restoring datafile 00013 to /disk1/oracle/dbs/users02.f
channel ORA_DISK_1: restoring datafile 00021 to /disk1/oracle/dbs/users03.f
channel ORA_DISK_1: reading from backup piece
/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_nnndf_
TAG20130620T105435_29jflwor_.bkp
channel ORA_DISK_1: piece
handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_nnndf_
TAG20130620T105435_29jflwor_.bkp tag=TAG20130620T105435
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 20-JUN-13
RMAN> RECOVER TABLESPACE users;
Starting recover at 20-JUN-13
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
starting media recovery
archived log for thread 1 with sequence 27 is on disk as file
/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_20/o1_mf_1_27_29jjmtc9_.arc
archived log for thread 1 with sequence 28 is on disk as file
/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_20/o1_mf_1_28_29jjnc5x_.arc
.
.
.
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=7
.
.
.
channel ORA_DISK_1: reading from backup piece
/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece
handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp tag=TAG20130620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jkdvjq_.arc thread=1 sequence=5
channel default: deleting archived log(s)
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jkdvjq_.arc RECID=91 STAMP=593611179
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
17-17
Chapter 17
Performing Complete Database Recovery
20/o1_mf_1_6_29jkdvbz_.arc thread=1 sequence=6
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:01
Finished recover at 20-JUN-13
•
If you are restoring some data files to new locations, then execute RESTORE
TABLESPACE and RECOVER TABLESPACE in a RUN command. Use the SET NEWNAME
command to rename data files, as described in "About Restoring Data Files to
a Nondefault Location".
The following example restores the data files in tablespace users to a new
location, and then performs recovery. Assume that the old data files were
stored in the /disk1 path and the new ones will be stored in the /disk2 path.
RUN
{
# specify the new location for each datafile
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users01.f' TO
'/disk2/users01.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users02.f' TO
'/disk2/users02.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users03.f' TO
'/disk2/users03.f';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL; # update control file with new file names
RECOVER TABLESPACE users;
}
6.
Examine the output to see if recovery was successful. If so, bring the recovered
tablespace back online.
For example, enter the following command:
ALTER TABLESPACE users ONLINE;
17.3.4 Performing Complete Recovery After Switching to a Copy
You can recover a database by switching to image copies of inaccessible data files.
This technique takes less time than traditional restore and recovery because no
backups need to be restored.
If you have image copies of the inaccessible data files in the fast recovery area, then
you can use the SWITCH DATAFILE ... TO COPY command to point the control file at the
data file copy and then use RECOVER to recover lost changes. You can also use the
SWITCH DATABASE TO COPY command to point the control file at a copy of the whole
database.
Note:
A SWITCH TABLESPACE ... TO COPY command is also supported for cases when
all data files in a tablespace are lost and copies of all data files exist. The
same restriction exists for SWITCH DATABASE ... TO COPY.
17-18
Chapter 17
Performing Complete Database Recovery
See Also:
•
Performing Recovery After Switching to a Data File Copy
•
Performing Complete Recovery After Switching to a Database Copy
17.3.4.1 Performing Recovery After Switching to a Data File Copy
When one or more data files are damaged, you can perform recovery by switching to
existing image copies of the damaged data files.
"Scope of This Chapter" for some of the assumptions used in the recovery procedures
In the basic scenario, the database is open, and some but not all of the data files are
damaged. During the course of the day, a data file goes missing due to storage failure.
You must repair this file, but cannot afford the time to do a restore and recovery from a
backup. You decide to use a recent image copy backup as the new file, thus
eliminating restore time. This scenario assumes that database trgt has lost data file 4.
To switch to a data file copy and perform recovery:
1.
Complete the preparation steps required for your scenario, as described in
"Preparing for Complete Database Recovery".
2.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN".
3.
If the database is open, then take the tablespace requiring recovery offline.
Enter the following command to take data file 4 offline:
ALTER DATABASE DATAFILE 4 OFFLINE;
4.
Switch the offline data file to the latest copy.
Enter the following command to point the control file to the latest image copy of
data file 4:
SWITCH DATAFILE 4 TO COPY;
5.
Recover the data file with the RECOVER DATAFILE command.
Enter the following command:
RECOVER DATAFILE 4;
RMAN automatically restores archived redo logs and incremental backups.
Because the database uses a fast recovery area, RMAN automatically deletes
them after they have been applied.
6.
Examine the output to see if recovery was successful. If so, bring the recovered
data file back online.
Enter the following command to bring data file 4 online:
ALTER DATABASE DATAFILE 4 ONLINE;
17-19
Chapter 17
Performing Complete Recovery of CDBs
17.3.4.2 Performing Complete Recovery After Switching to a Database Copy
You can perform complete database recovery by switching to image copies of the
damaged data files instead of restoring these data files.
"Scope of This Chapter" for some of the assumptions used in the recovery procedures
In this scenario, the database is shut down, and all of the data files are damaged. You
have image copies of all the damaged data files and decide to use the existing image
copies as the new data files, thus eliminating restore time.
To switch to a database copy and perform recovery:
1.
Complete the preparation steps required for your scenario, as described in
"Preparing for Complete Database Recovery".
2.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN".
3.
Mount the database.
4.
Switch the database to the latest copy.
Enter the following command to point the control file to the latest image copy of the
database:
SWITCH DATABASE TO COPY;
5.
Recover the database with the RECOVER DATABASE command.
Enter the following command:
RECOVER DATABASE;
RMAN automatically restores archived redo logs and incremental backups.
Because the database uses a fast recovery area, RMAN automatically deletes
them after they have been applied.
6.
Examine the output to see if recovery was successful. If so, open the database.
Enter the following command to open the database:
ALTER DATABASE OPEN;
17.4 Performing Complete Recovery of CDBs
RMAN and Oracle Enterprise Manager Cloud Control (Cloud Control) provide full
support for backup and recovery in a multitenant environment.
You can back up and recover a whole multitenant container database (CDB), root
only, or one or more pluggable databases (PDBs).
The section contains the following topics:
•
Performing Complete Recovery of a Whole CDB
•
Performing Complete Recovery of the Root
•
Performing Complete Recovery of PDBs with RMAN
•
Performing Complete Recovery of PDBs with Cloud Control
17-20
Chapter 17
Performing Complete Recovery of CDBs
•
Performing Complete Recovery Using Preplugin Backups
•
Performing Complete Recovery of Tablespaces or Data Files in a PDB with RMAN
•
Performing Complete Recovery of Tablespaces in a PDB with Cloud Control
•
Performing Complete Recovering of CDBs After Switching to a Copy
17.4.1 Performing Complete Recovery of a Whole CDB
When you recover a whole CDB, you recover the root and all PDBs in a single
operation.
To recover a whole CDB:
1.
Complete the preparation steps that are required for your scenario, as described in
"Preparing for Complete Database Recovery"
2.
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege, as
described in "Connecting as Target to the Root".
3.
If the database is not mounted, then mount but do not open the database. Use the
following g command:
STARTUP MOUNT;
4.
Use the SHOW command to see which channels are preconfigured.
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
5.
Restore and recover the database. Do one of the following:
•
If you are restoring all data files to their original locations, then execute RESTORE
DATABASE and RECOVER DATABASE sequentially at the RMAN prompt.
For example, enter the following commands if automatic channels are
configured:
RESTORE DATABASE;
RECOVER DATABASE;
If you manually allocate channels, then you must issue the RESTORE and
RECOVER commands together within a RUN block as shown in the following
example:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE DATABASE;
RECOVER DATABASE;
}
•
If you are restoring some data files to new locations, then execute RESTORE
DATABASE and RECOVER DATABASE sequentially in a RUN command. Use the SET
NEWNAME command to rename data files.
The following example restores the database, specifying new names for three
of the data files, and then recovers the database:
RUN
{
SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
17-21
Chapter 17
Performing Complete Recovery of CDBs
SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}
6.
Examine the output to see if media recovery was successful. If so, open the
database.
For example, enter the following command:
ALTER DATABASE OPEN;
See Also:
About Restoring Data Files to a Nondefault Location
17.4.2 Performing Complete Recovery of the Root
You might consider recovering only the root if a data corruption or user error occurs
that affects only the root.
However, Oracle strongly recommends that you recover all PDBs after recovering the
root to prevent metadata inconsistencies among the root and the PDBs. In this case, it
might be preferable to perform a complete recovery of the whole CDB.
See Also:
"Scope of This Chapter" for some of the assumptions used in the recovery
procedures
To recover the root:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Connecting as Target to the Root".
3.
Place the CDB in mounted mode.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
4.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
5.
Restore and recover the root with the following commands:
RESTORE DATABASE ROOT;
RECOVER DATABASE ROOT;
6.
Examine the output to see if media recovery was successful. If so, proceed to the
next step.
17-22
Chapter 17
Performing Complete Recovery of CDBs
7.
(Strongly recommended) Recover all PDBs, including the CDB seed.
a.
Issue the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE
commands.
The following example recovers the PDBs sales and hr:
RESTORE PLUGGABLE DATABASE 'PDB$SEED', sales, hr;
RECOVER PLUGGABLE DATABASE 'PDB$SEED', sales, hr;
b.
8.
Examine the output to see if media recovery was successful. If so, proceed to
the next step.
Open the CDB and all PDBs.
ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE ALL OPEN;
See Also:
Performing Complete Recovery of a Whole CDB
17.4.3 Performing Complete Recovery of PDBs with RMAN
You can perform complete recovery of one or more PDBs without affecting operations
of other open PDBs.
See Also:
"Scope of This Chapter" for some of the assumptions used in the recovery
procedures
There are two approaches to recovering a PDB with RMAN:
•
Connect to the root and then use the RESTORE PLUGGABLE DATABASE and RECOVER
PLUGGABLE DATABASE commands. This approach enables you to recover multiple
PDBs with a single command.
•
Connect to the PDB and use the RESTORE DATABASE and RECOVER DATABASE
commands. This approach recovers only a single PDB and enables you to use the
same commands used for recovering non-CDB databases.
Video:
unilink:vid_dbbackup_recoverpdb
To recover one or more PDBs while connected to the root:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
17-23
Chapter 17
Performing Complete Recovery of CDBs
2.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Connecting as Target to the Root".
3.
Close the PDBs that you want to recover.
ALTER PLUGGABLE DATABASE sales, hr CLOSE;
If any data files are missing, an error occurs and you cannot close a PDB. You
must then connect to the PDB to which the missing data file belongs, take the
missing data file offline, and then close the PDB.
The following command takes the data file 12 offline:
ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;
Note:
If the data files that store the SYSTEM tablespace of a PDB are missing,
then follow the recovery steps that are described in "Performing
Complete Recovery of Tablespaces or Data Files in a PDB with RMAN".
4.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
5.
Issue the RESTORE PLUGGABLE DATABASE and RECOVER PLUGGABLE DATABASE commands.
The following example recovers the CDB seed, PDB$SEED, and the PDBs sales and
hr:
RESTORE PLUGGABLE DATABASE 'pdb$seed', sales, hr;
RECOVER PLUGGABLE DATABASE 'pdb$seed', sales, hr;
6.
If any data files were taken offline in Step 2, make these data files online.
Connect to the PDB to which the missing data file belongs and then make the data
file online. The following command makes the data file 12 online:
ALTER DATABASE DATAFILE 12 ONLINE;
7.
Examine the output to see if media recovery was successful. If so, open the PDBs.
ALTER PLUGGABLE DATABASE sales, hr OPEN;
To connect to and recover one PDB:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to the PDB as a local user with the SYSDBA system
privilege, as described in "Connecting as Target to a PDB".
3.
Close the PDB.
ALTER PLUGGABLE DATABASE CLOSE;
If any data files are missing, an error occurs and you cannot close the PDB. You
must take the missing data file offline and then close the PDB.
The following command takes the data file 12 offline:
ALTER DATABASE DATAFILE 12 OFFLINE;
17-24
Chapter 17
Performing Complete Recovery of CDBs
Note:
If the data files that store the SYSTEM tablespace of a PDB are missing,
then follow the recovery steps described in "Performing Complete
Recovery of Tablespaces or Data Files in a PDB with RMAN".
4.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
5.
Issue the RESTORE DATABASE and RECOVER DATABASE commands.
RESTORE DATABASE;
RECOVER DATABASE;
6.
If any data files were taken offline in Step 2, make these data files online.
The following command makes the data file 12 online:
ALTER DATABASE DATAFILE 12 ONLINE;
7.
Open the PDB.
ALTER PLUGGABLE DATABASE OPEN;
17.4.4 Performing Complete Recovery of PDBs with Cloud Control
Enterprise Manager Cloud Control (Cloud Control) provides an interface to recover
PDBs.
To recover one or more PDBs with Cloud Control:
1.
From the Database Home page, select Backup & Recovery from the Availability
menu, and then select Perform Recovery.
2.
If you have not logged in to the database previously, the Database Login page is
displayed. Log in to the database using Named or New credentials and then click
Login.
Cloud Control displays the Perform Recovery page.
3.
From the User Directed Recovery section, select Pluggable Databases from the
Recovery Scope drop-down list, and then click Recover.
The Perform Pluggable Database Recovery Wizard appears and displays the
Pluggable Databases page.
4.
5.
Select the PDBs that you want to recover by following these steps:
a.
Click Add to display the Available Pluggable Databases page.
b.
From the list of PDBs shown, click in the Select column to designate the PDBs
that you want to recover. Optionally, you can click Select All to turn on the
Select option for all available PDBs. Click Select None to deselect all PDBs.
c.
Click the Select button to return to the Pluggable Databases page.
d.
Optionally, you can remove PDBs from the table by clicking in the Select
column for each PDB that you want to remove and then clicking Remove.
Complete the wizard by navigating through the remainder of the pages to recover
the PDBs. For more information about each page of the wizard, click Help.
17-25
Chapter 17
Performing Complete Recovery of CDBs
See Also:
"Accessing the Database Home Page Using Cloud Control"
17.4.5 Performing Complete Recovery Using Preplugin Backups
Use the RECOVER command to perform complete recovery using preplugin backups.
This section contains the following topics:
•
About Complete Recovery of PDBs Using PrePlugin Backups
•
Performing Complete Recovery of PDBs Using Preplugin Backups
•
Example: Performing Complete Recovery of PDBs Using Preplugin Backups
17.4.5.1 About Complete Recovery of PDBs Using PrePlugin Backups
Preplugin backups are used to restore and recover a PDB to its state at a time in the
past that was before the PDB was plugged in to the current CDB.
To perform complete recovery using preplugin backups, use the FROM PREPLUGIN clause
of the RESTORE and RECOVER commands. RMAN restores data files using preplugin
backups and then uses the preplugin incremental backups and archived redo logs to
recover data files to a point in time that is before the PDB was plugged in to the
destination CDB.
The metadata for the preplugin backups is migrated to the destination CDB when you
unplug the PDB or use the DBMS_PDB.EXPORTRMANBACKUP() procedure with non-CDBs.
Preplugin backups are not automatically migrated to the destination CDB. You must
ensure that the destination CDB has access to the backups created on the source
database.
The location to which RMAN restores preplugin archived redo logs depends on
whether a fast recovery area is configured in the destination CDB. If a fast recovery
area is not the default destination for archived redo log files in the CDB, then RMAN
restores preplugin archived redo logs to the fast recovery area. If the fast recovery
area is the default destination for archived redo log files in the CDB, then you must use
the SET ARCHIVELOG DESTINATION command to specify a location for the preplugin
archived redo log files.
See Also:
•
About Preplugin Backups
•
Performing Complete Recovery of PDBs Using Preplugin Backups
•
Example: Performing Complete Recovery of PDBs Using Preplugin
Backups
17-26
Chapter 17
Performing Complete Recovery of CDBs
17.4.5.2 Performing Complete Recovery of PDBs Using Preplugin Backups
RMAN performs complete recovery of a PDB using preplugin backups. These
preplugin backups were created on a source non-CDB or a source CDB before the
PDB was migrated to the current target CDB.
Preplugin backups must include all archived redo logs that are required to recover the
PDB.
To perform complete recovery using preplugin backups of a non-CDB, the non-CDB
backups must be created using the procedure described in "Creating a Preplugin
Backup of the Whole Database".
Note:
You cannot recover a PDB using preplugin backups if the preplugin backup
was created before the PDB was opened with the RESETLOGS option.
To perform complete recovery of a PDB using preplugin backups:
1.
Ensure that the prerequisites for performing recovery using preplugin backups
described in Oracle Database Backup and Recovery Reference are met.
2.
Ensure that the shared location containing preplugin backups of the PDB is
accessible to the destination host.
Note:
Using shared disk is the only method that is supported to share prelugin
backups with the destination host. Manually copying the required
backups to the destination is not supported.
3.
Connect to the target CDB using one of the following techniques:
•
Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege
•
Connect to the PDB that needs to be recovered as a user with the SYSDBA or
SYSBACKUP privilege.
See "Making Database Connections with RMAN".
4.
Close the PDB that is being recovered. For example:
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE;
5.
Set the current container to the PDB that is being recovered. For example:
SET PREPLUGIN CONTAINER=pdb1;
6.
(Optional) To view the preplugin backups, use the LIST command.
LIST PREPLUGIN BACKUP OF PLUGGABLE DATABASE pdb1;
LIST PREPLUGIN ARCHIVELOG ALL;
17-27
Chapter 17
Performing Complete Recovery of CDBs
7.
(Optional) To catalog any backups that were not stored in the source database
control file before migration, use the CATALOG...PREPLUGIN command.
The ROOT must be open in read-write mode for cataloging backups. The following
command catalogs the specified archived redo log:
CATALOG PREPLUGIN ARCHIVELOG '/disk1/o1_mf_annnn_dmy2r45h_.bkp';
8.
Restore the PDB using preplugin backups.
RESTORE PLUGGABLE DATABASE pdb1 FROM PREPLUGIN;
9.
Recover the PDB using preplugin backups.
The RECOVER ... FROM PREPLUGIN command performs preplugin recovery. If the
destination CDB uses the fast recovery area as the archivelog destination, then
use SET ARCHIVELOG DESTINATION to specify the destination to which preplugin
backups must be recovered.
RUN
{
SET ARCHIVELOG DESTINATION TO '/disk1/alog_dest';
RECOVER PLUGGABLE DATABASE pdb1 FROM PREPLUGIN;
}
10. Restore any new data files that were added after pdb1 was plugged in to the
destination CDB and then perform normal recovery of pdb1.
RESTORE PLUGGABLE DATABASE pdb1 SKIP PREPLUGIN;
RECOVER PLUGGABLE DATABASE pdb1;
11. Open the recovered PDB.
The following command opens the PDB called pdb1.
ALTER PLUGGABLE DATABASE pdb1 OPEN;
See Also:
•
Example: Performing Complete Recovery of PDBs Using Preplugin
Backups
•
About Complete Recovery of PDBs Using PrePlugin Backups
17.4.5.3 Example: Performing Complete Recovery of PDBs Using Preplugin
Backups
This example performs complete recovery of a PDB my_pdb in the destination CDB
prod_cdb using preplugin backups.
The PDB my_pdb was unplugged from the CDB test_cdb and then plugged in to the
CDB prod_cdb. When this PDB was unplugged from test_cdb, its metadata was stored
in the file mypdb.xml. This metadata was used to plug my_pdb into prod_cdb. The backups
of my_pdb that were created in the source CDB test_cdb are stored in the shared
location /oracle/database/backups. The CDB prod_cdb uses the fast recovery area to
store archived redo log files.
17-28
Chapter 17
Performing Complete Recovery of CDBs
1.
Ensure that the prerequisites for performing recovery using preplugin backups
described in Oracle Database Backup and Recovery Reference are met.
2.
Set up a shared disk to share the preplugin backups created on the source with
the destination host.
3.
Start RMAN and connect to the root of prod_cdb as a common user with the
SYSBABKUP privilege.
The following command uses password file authentication to connect to the root as
a common user with the SYSBACKUP privilege.
CONNECT TARGET sbu@prod_cdb as SYSBACKUP;
4.
Close the PDB my_pdb.
ALTER PLUGGABLE DATABASE my_pdb CLOSE IMMEDIATE;
5.
Set the preplugin container to the PDB that is being recovered.
SET PREPLUGIN CONTAINER=my_pdb;
6.
Restore my_pdb using the preplugin backups that were created on the source CDB
test_cdb before my_pdb was plugged in to prod_cdb.
RESTORE PLUGGABLE DATABASE my_pdb FROM PREPLUGIN;
7.
Recover my_pdb using preplugin backups. Because the fast recovery area is
configured to store archived redo log files for the destination CDB, you must
specify an alternate destination for the restored preplugin archived redo log files.
RUN
{
SET ARCHIVELOG DESTINATION TO '/disk1/arc_dest/';
RECOVER PLUGGABLE DATABASE my_pdb FROM PREPLUGIN;
}
8.
If any data files were added to my_pdb after it was plugged in to prod_cdb, then
restore these data files and then recover the PDB my_pdb.
RESTORE PLUGGABLE DATABASE my_pdb SKIP PREPLUGIN;
RECOVER PLUGGABLE DATABASE my_pdb;
9.
Open the PDB my_pdb.
ALTER PLUGGABLE DATABASE my_pdb OPEN;
17.4.6 Performing Complete Recovery of Tablespaces or Data Files in
a PDB with RMAN
Because tablespaces in different PDBs can have the same name, to eliminate
ambiguity, you must connect directly to a PDB to recover one or more of its
tablespaces. In contrast, because data file numbers and paths are unique across the
CDB, you can connect either to the root or to a PDB when recovering PDB data files.
If you connect to the root, you can recover data files from multiple PDBs with a single
command. If you connect to a PDB, you can recover only data files in that PDB.
To restore and recover a non-SYSTEM tablespace in a PDB:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
17-29
Chapter 17
Performing Complete Recovery of CDBs
2.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN."
3.
If the database is open, then take the tablespace requiring recovery offline.
For example, enter the following command to take USERS offline:
ALTER TABLESPACE users OFFLINE IMMEDIATE;
4.
Use the SHOW command to see which channels are preconfigured.
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
5.
Restore and recover the tablespace. Do one of the following:
•
If you are restoring data files to their original locations, then run the RESTORE
TABLESPACE and RECOVER TABLESPACE commands at the RMAN prompt.
For example, enter the following commands if automatic channels are
configured:
RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;
•
6.
If you are restoring some data files to new locations, then execute RESTORE
TABLESPACE and RECOVER TABLESPACE in a RUN command. Use the SET NEWNAME
command to rename data files.
Examine the output to see if recovery was successful. If so, bring the recovered
tablespace back online.
For example, enter the following command:
ALTER TABLESPACE users ONLINE;
To restore and recover the SYSTEM tablespace in a PDB:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Connecting as Target to the Root".
3.
Shut down the CDB and restart it in mount mode.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
4.
Restore and recover the data files that store the SYSTEM tablespace of the affected
PDB.
RESTORE DATAFILE 2,3;
RECOVER DATAFILE 2,3;
5.
Open all the PDBs in the CDB.
ALTER PLUGGABLE DATABASE ALL OPEN READ WRITE;
To recover non-SYSTEM data files in a PDB:
1.
Complete the preparation steps that are required for your recovery scenario, as
described in "Preparing for Complete Database Recovery".
2.
Do one of the following:
17-30
Chapter 17
Performing Complete Recovery of CDBs
3.
•
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Connecting as Target to the Root".
•
Start RMAN and connect to the PDB as a local user with the SYSDBA privilege,
as described in "Connecting as Target to a PDB".
Issue the RESTORE DATAFILE and RECOVER DATAFILE commands.
RESTORE DATAFILE 10, 13;
RECOVER DATAFILE 10, 13;
See Also:
"About Restoring Data Files to a Nondefault Location"
17.4.7 Performing Complete Recovery of Tablespaces in a PDB with
Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) provides an interface to
recover tablespaces within a PDB.
To perform complete recovery of tablespaces in a PDB with Cloud Control:
1.
From the Database Home page, select Backup & Recovery from the Availability
menu, and then select Perform Recovery.
2.
If you have not logged in to the database previously, the Database Login page is
displayed. Log in to the database using Named or New credentials and then click
Login.
Cloud Control displays the Perform Recovery page.
3.
From the User Directed Recovery section, select Tablespaces from the Recovery
Scope drop-down list, and then click Recover.
4.
On the Perform Object Level Recovery:Point-in-time page, ensure that Recover to
the current time is selected, and click Next.
5.
On the Perform Object Level Recovery: Tablespaces page, select the tablespaces
that you want to recover by completing these steps:
a.
Click Add to display the Available Tablespaces page.
The Search Results table shows all available tablespaces and includes the
name of the PDB to which each tablespace belongs.
6.
b.
Click Select to designate the tablespaces that you want to recover. Optionally,
you can click Select All to turn on the Select option for all available
tablespaces. Click Select None to deselect all tablespaces.
c.
Click the Select button to return to the Perform Object Level Recovery:
Tablespaces page.
d.
Optionally, you can remove tablespaces from the table by turning on the
Select option for each tablespace that you want to remove and then clicking
Remove.
Click Next to move to the next step in the wizard.
17-31
Chapter 17
Performing Complete Recovery of Application Containers
7.
Complete the wizard by navigating through the remainder of the pages to recover
the PDB tablespace. For more information about each page of the wizard, click
Help.
See Also:
"Accessing the Database Home Page Using Cloud Control"
17.4.8 Performing Complete Recovering of CDBs After Switching to a
Copy
Recovering a CDB by switching to a copy is faster than traditional restore and
recovery.
If you have image copies of the inaccessible data files in your CDB or PDB, then you
can recover lost changes by using the SWITCH command to point the control file at the
data file copies.
See Also:
"Scope of This Chapter" for some of the assumptions used in the recovery
procedures
To switch a data file in a CDB:
•
Connect to the root and use the same steps that you would use for a non-CDB as
described in "Performing Recovery After Switching to a Data File Copy".
To switch a data file in a PDB, use one of the following techniques:
•
Connect to the root and use the SWITCH ... PLUGGABLE DATABASE or SWITCH DATAFILE
command. This enables you to switch the data files for one or more PDBs.
•
Connect to the PDB and use the SWITCH DATABASE or SWITCH DATAFILE command to
switch data files in that PDB.
See Also:
Making RMAN Connections to a CDB
17.5 Performing Complete Recovery of Application
Containers
RMAN enables you to use the RESTORE and RECOVER commands to perform complete
recovery of the application containers without impacting the other containers in the
CDB.
17-32
Chapter 17
Performing Complete Recovery of Application Containers
See Also:
•
Performing Complete Recovery of the Application Root
•
Performing Complete Recovery of the Application Root and Application
PDBs
•
Performing Complete Recovery of Application PDBs
17.5.1 Performing Complete Recovery of the Application Root
Use the RESTORE and RECOVER commands to perform complete recovery of the
application root.
Use one of the following approaches to perform complete recovery of the application
root:
•
Connect to the application root and use the RESTORE DATABASE and RECOVER DATABASE
commands
•
Connect to the CDB root and use the RESTORE PLUGGABLE DATABASE and RECOVER
PLUGGABLE DATABASE commands
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To connect to and recover the application root:
1.
Start RMAN and connect to the application root as an application common user
with the SYSDBA or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
2.
Close the application container whose application root needs recovery.
ALTER DATABASE CLOSE;
3.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
4.
Restore and recover the application root using the following commands:
RESTORE DATABASE ROOT;
RECOVER DATABASE ROOT;
5.
Examine the output to see if media recovery was successful. If so, proceed to the
next step.
6.
Open the application root.
ALTER DATABASE OPEN;
To recover the application root when connected to the root in a CDB
1.
Start RMAN and connect to the CDB root as a common user with the SYSDBA or
SYSBACKUP privilege.
2.
Close the application container that must be recovered.
17-33
Chapter 17
Performing Complete Recovery of Application Containers
The following command closes the application container whose application root is
called hr_appcont.
ALTER PLUGGABLE DATABASE hr_appcont CLOSE;
3.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
4.
Restore and recover the application root.
The following commands restore and recover an application root named
hr_appcont:
RESTORE PLUGGABLE DATABASE hr_appcont;
RECOVER PLUGGABLE DATABASE hr_appcont;
5.
Examine the output to see if media recovery was successful. If so, proceed to the
next step.
6.
Open the application root.
ALTER PLUGGABLE DATABASE hr_appcont OPEN;
See Also:
Making RMAN Connections to a CDB
17.5.2 Performing Complete Recovery of the Application Root and
Application PDBs
You can perform complete recovery of an application container, which includes the
application root and all its application PDBs without impacting the other PDBs within
the CDB.
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To perform complete recovery of the application root and all its application
PDBs:
1.
Start RMAN and connect to the application root as an application common user
with the SYSDBA or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
2.
Close the application container that must be recovered.
ALTER DATABASE CLOSE;
3.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
4.
Restore and recover the application container (application root and all application
PDBs) using the following commands.
RESTORE DATABASE;
RECOVER DATABASE;
17-34
Chapter 17
Performing Complete Recovery of Application Containers
5.
Examine the output to see if media recovery was successful. If so, proceed to the
next step.
6.
Open the application root and all the application PDBs.
ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE ALL OPEN;
See Also:
Making RMAN Connections to a CDB
17.5.3 Performing Complete Recovery of Application PDBs
Use the RESTORE and RECOVER commands to perform complete recovery of one or more
application PDBs.
The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.
To perform complete recovery of an application PDB:
1.
Start RMAN and establish one of the following types of connections:
•
Connect to the application root as an application common user with the SYSDBA
or SYSBACKUP privilege.
The application root has its own service name and you can connect to the
application root in the same way that you connect to a PDB.
•
2.
Connect to the CDB root as a common user with the SYSDBA or SYSBACKUP
privilege.
Close the application PDB for which complete recovery is required.
The following command closes the application PDB called hr_appcont_pdb1:
ALTER PLUGGABLE DATABASE hr_appcont_pdb1 CLOSE;
3.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
4.
Restore and recover the application PDB.
The following commands perform complete recovery of an application PDB called
hr_appcont_pdb1
RESTORE PLUGGABLE DATABASE hr_appcont_pdb1;
RECOVER PLUGGABLE DATABASE hr_appcont_pdb1;
5.
Examine the output to see if media recovery was successful. If so, proceed to the
next step.
6.
Open the application PDB.
The following commands opens the application PDB called hr_appcont_pdb1:
ALTER PLUGGABLE DATABASE hr_appcont_pdb1 OPEN;
17-35
Chapter 17
Performing Complete Recovery of Sparse Databases with RMAN
See Also:
Making RMAN Connections to a CDB
17.6 Performing Complete Recovery of Sparse Databases
with RMAN
You can recover sparse databases to the most recent point in time using the RESTORE
and RECOVER commands.
This section contains the following topics:
•
Performing Complete Recovery of a Sparse Database
•
Performing Complete Recovery of a Sparse CDB
•
Performing Recovery of a Sparse PDB with RMAN
Note:
The base (read-only) data files in a sparse database are not encrypted.
Ensure that the base data files are stored in a protected storage and
accessed using secured communications.
17.6.1 Performing Complete Recovery of a Sparse Database
Performing recovery of a database containing sparse data files is very similar to
performing recovery of a whole database.
RMAN first restores the logical data that was backed up from the delta storage space
of the database and then recovers the database by reading from the redo log and
applying the logical data file blocks. You can perform either complete recovery or
point-in-time recovery of a sparse database, tablespace, or data file.
To recover a sparse database:
1.
Complete the preparation steps required for your recovery scenario, as described
in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to a target database, as described in "Making Database
Connections with RMAN".
3.
If the database is not mounted, then mount but do not open the database.
For example, enter the following command:
STARTUP MOUNT;
4.
Use the SHOW command to see which channels are preconfigured.
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
17-36
Chapter 17
Performing Complete Recovery of Sparse Databases with RMAN
5.
Restore and recover the sparse database. The following commands perform
complete recovery of a sparse database:
RESTORE FROM SPARSE DATABASE;
RECOVER DATABASE;
6.
To recover a specific tablespace containing sparse data files, use the RESTORE and
RECOVER commands for the tablespace.
The following example restores and recovers the tablespace MY_TBS
RESTORE FROM SPARSE TABLESPACE MY_TBS;
RECOVER TABLESPACE MY_TBS;
17.6.2 Performing Complete Recovery of a Sparse CDB
Performing recovery of a sparse CDB is very similar to performing the complete
recovery of a sparse database.
To recover a sparse CDB:
1.
Complete the preparation steps required for your scenario, as described in
"Preparing for Complete Database Recovery".
2.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Making Database Connections with RMAN".
3.
If the CDB is not mounted, then mount but do not open the CDB.
For example, enter the following command:
STARTUP MOUNT;
4.
Use the SHOW command to see which channels are preconfigured.
If the necessary devices and channels are configured, then no action is necessary.
Otherwise, you can use the CONFIGURE command to configure automatic channels,
or include ALLOCATE CHANNEL commands within a RUN block.
5.
Restore and recover the sparse CDB. The following commands perform complete
recovery of a sparse CDB:
RESTORE FROM SPARSE DATABASE;
RECOVER DATABASE;
6.
To recover a specific tablespace containing sparse data files, use the RESTORE and
RECOVER commands for the tablespace.
The following example restores and recovers the tablespace MY_TBS
RESTORE FROM SPARSE TABLESPACE MY_TBS;
RECOVER TABLESPACE MY_TBS;
17.6.3 Performing Recovery of a Sparse PDB with RMAN
You can recover a sparse PDB while you are connected at the root level or at the CDB
level.
To recover one or more sparse PDBs while connected to the root:
1.
Complete the preparation steps required for your recovery scenario, as described
in "Preparing for Complete Database Recovery".
17-37
Chapter 17
Performing Complete Recovery of Sparse Databases with RMAN
2.
Start RMAN and connect to the root as a common user with the SYSDBA or
SYSBACKUP privilege, as described in "Making RMAN Connections to a CDB".
3.
Close the PDBs that you want to recover.
ALTER PLUGGABLE DATABASE sales, hr CLOSE;
If any data files are missing, an error occurs and you cannot close a PDB. You
must then connect to the PDB to which the missing data file belongs, take the
missing data file offline, and then close the PDB.
The following command takes the data file 12 offline:
ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;
Note:
If the data files that store the SYSTEM tablespace of a PDB are missing,
then follow the recovery steps described in "Performing Complete
Recovery of Tablespaces or Data Files in a PDB with RMAN".
4.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
5.
Run the RESTORE and RECOVER commands for the pluggable database.
The following example performs complete recovery of the PDB HR_PDB when
connected to the root:
RESTORE FROM SPARSE PLUGGABLE DATABASE HR_PDB;
RECOVER PLUGGABLE DATABASE HR_PDB;
To connect to and recover one sparse PDB:
1.
Complete the preparation steps required for your recovery scenario, as described
in "Preparing for Complete Database Recovery".
2.
Start RMAN and connect to the PDB as a local user with the SYSDBA or SYSBACKUP
system privilege, as described in "Making RMAN Connections to a CDB".
3.
Close the PDB.
ALTER PLUGGABLE DATABASE CLOSE;
If any data files are missing, an error occurs and you cannot close the PDB. You
must take the missing data file offline and then close the PDB.
The following command takes the data file 12 offline:
ALTER DATABASE DATAFILE 12 OFFLINE;
Note:
If the data files that store the SYSTEM tablespace of a PDB are missing,
then follow the recovery steps described in "Performing Complete
Recovery of Tablespaces or Data Files in a PDB with RMAN".
17-38
Chapter 17
Performing Complete Recovery of Sparse Databases with RMAN
4.
(Optional) Use the CONFIGURE command to configure the default device type and
automatic channels.
5.
Issue the RESTORE and RECOVER commands.
The following example restores and recovers the PDB USERS_PDB
RESTORE FROM SPARSE DATABASE FROM USERS_PDB;
RECOVER DATABASE USERS_PDB;
.
17-39
18
Performing Flashback and Database Pointin-Time Recovery
This chapter explains how to investigate unwanted database changes, and select and
perform an appropriate recovery strategy based upon Oracle Flashback Technology
and database backups. It contains the following topics:
•
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
•
Rewinding a Table with Flashback Table
•
Rewinding a DROP TABLE Operation with Flashback Drop
•
Rewinding a Database with Flashback Database
•
Performing Database Point-in-Time Recovery
•
Flashback and Database Point-in-Time Recovery Scenarios
18.1 Overview of Oracle Flashback Technology and
Database Point-in-Time Recovery
This overview describes the purpose and basic concepts of Oracle Flashback
Technology and database point-in-time recovery.
18.1.1 Purpose of Flashback and Database Point-in-Time Recovery
Certain situations are suited for using point-in-time recovery or flashback features to
return the database or database object to its state at a previous point in time.
Some typical situations include the following:
•
A user error or corruption removes needed data or introduces corrupted data. For
example, a user or DBA might erroneously delete or update the contents of one or
more tables, drop database objects that are still needed during an update to an
application, or run a large batch update that fails midway.
•
A database upgrade fails or an upgrade script goes awry.
•
A complete database recovery after a media failure cannot succeed because you
do not have all of the needed redo logs or incremental backups.
18.1.2 Basic Concepts of Point-in-Time Recovery and Flashback
Features
Database point-in-time recovery (DBPITR) and Flashback features enable you to
recover your database to a prior point in time.
DBPITR is the most basic solution to unwanted database changes. It is sometimes
called incomplete recovery because it does not use all of the available redo or
18-1
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
completely recover all changes to your database. In this case, you restore a whole
database backup and then apply redo logs or incremental backups to re-create all
changes up to a point in time before the unwanted change.
If unwanted database changes are extensive but confined to specific tablespaces,
then you can use tablespace point-in-time recovery (TSPITR) to return these
tablespaces to an earlier system change number (SCN) while the unaffected
tablespaces remain available.
If unwanted database changes are limited to specific tables or table partitions, then
you can use a previously created RMAN backup to return only these objects to a point
in time before the unwanted changes occurred.
Oracle Database also provides a set of features collectively known as Flashback
Technology that supports viewing past states of data, and winding and rewinding data
back and forth in time, without requiring the restore of the database from backup.
Depending on the changes to your database, Flashback Technology can often reverse
the unwanted changes more quickly and with less impact on database availability.
See Also:
•
Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)
•
Recovering Tables and Table Partitions
18.1.2.1 Basic Concepts of Database Point-in-Time Recovery for non-CDBs
DBPITR works at the physical level to return the data files to their state at a target time
in the past.
In an RMAN DBPITR operation, you specify a target SCN, log sequence, restore point,
or time. RMAN restores the database from backups created before the target time,
and then applies incremental backups and logs to re-create all changes between the
time of the data file backups and the end point of recovery. When the end point is
specified as an SCN, the database applies the redo logs and stops after each redo
thread or the specified SCN, whichever occurs first. When the end point is specified as
a time, the database internally determines a suitable SCN for the specified time and
then recovers to this SCN.
If your backup strategy is properly designed and your database is running in
ARCHIVELOG mode, then DBPITR is an option in nearly all circumstances. RMAN
simplifies DBPITR in comparison to the user-managed DBPITR described in
"Performing Incomplete Database Recovery". Given a target SCN, data files are
restored from backup and recovered efficiently with no intervention from the user.
Nevertheless, RMAN DBPITR has the following disadvantages:
•
You cannot return selected objects to their earlier state, only the entire database.
•
Your entire database is unavailable during the DBPITR.
•
DBPITR can be time-consuming because RMAN must restore all data files. Also,
RMAN may need to restore redo logs and incremental backups to recover the data
files. If backups are on tape, then this process can take even longer.
18-2
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
18.1.2.2 Basic Concepts of Point-in-Time Recovery for PDBs
RMAN provides support for point-in-time recovery for one or more PDBs. To recover
PDBs, you must connect to the root as a user with SYSDBA or SYSBACKUP privilege. After
recovery, old backups of the PDB remain valid and can be used if a media failure
occurs.
When you perform PITR of a PDB, all the data files for this PDB are recovered inplace. However, to recover the PDB to the specified target time, RMAN also needs the
UNDO tablespace as it existed at the target time. When shared undo is used, the UNDO
tablespace is shared by all PDBs and therefore it cannot be recovered in-place. RMAN
restores the UNDO, SYSTEM, and SYSAUX tablespaces in the root to an auxiliary database
and then uses the undo information to recover the PDB to the target time.
If a fast recovery area is configured, Oracle Database uses it as the auxiliary
destination. If the fast recovery area is not configured, then you must use the AUXILIARY
DESTINATION clause to specify the location used for auxiliary database files. Ensure that
there is sufficient space in the fast recovery area to restore the root tablespaces and
the undo tablespace. If the fast recovery area does not have the required space, use
an alternate location by specifying the AUXILIARY DESTINATION clause.
In a Data Guard environment, for the standby database to follow a primary database in
which a PDB was restored to a particular point in time, you may need to either flash
back the entire standby database, restore the PDB, or flash back the PDB.
See Also:
Performing Point-in-Time Recovery of CDBs and PDBs
18.1.2.3 Basic Concepts of Flashback Technology
The flashback features of the Oracle Database are more efficient than media recovery
in most circumstances in which they are available. You can use them to investigate
past states of the database.
18.1.2.3.1 About Physical Flashback Features Useful in Backup and Recovery
Oracle Flashback Database is the most efficient alternative to DBPITR.
Unlike the other flashback features, it operates at a physical level and reverts the
current data files to their contents at a past time. The result is like the result of a
DBPITR, including the OPEN RESETLOGS, but Flashback Database is typically faster
because it does not require you to restore data files and requires only limited
application of redo compared to media recovery.
A fast recovery area is required for Flashback Database. To enable logging for
Flashback Database, you must set the DB_FLASHBACK_RETENTION_TARGET initialization
parameter and issue the ALTER DATABASE FLASHBACK ON statement.
During normal operation, the database periodically writes old images of data file blocks
to the flashback logs. Flashback logs are written sequentially and often in bulk. In
some respects, flashback logging is like a continuous backup. The database
automatically creates, deletes, and resizes flashback logs in the recovery area.
18-3
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
Flashback logs are not archived. You need only be aware of flashback logs for
monitoring performance and determining disk space allocation for the recovery area.
When you perform a Flashback Database operation, the database uses flashback logs
to access past versions of data blocks and also uses some data in the archived redo
logs. Consequently, you cannot enable Flashback Database after a failure is
discovered and then use Flashback Database to rewind through this failure. You can
use the related capability of guaranteed restore points to protect the contents of your
database at a fixed point in time, such as immediately before a risky database change.
If any unrecoverable operations are encountered during the small amount of redo
apply required, then logically corrupt data blocks will result. This can lead to Oracle
errors when such blocks are accessed.
See Also:
•
Rewinding a Database with Flashback Database
•
Configuring the Fast Recovery Area
•
Oracle Database Administrator’s Guide
18.1.2.3.2 About Logical Flashback Features Useful in Backup and Recovery
Logical flashback features are used to recover tables and their contents to a past time.
The logical features are as follows:
•
Flashback Table
You can recover a table or set of tables to a specified earlier point in time without
taking any part of the database offline. In many cases, Flashback Table eliminates
the need to perform more complicated point-in-time recovery operations.
Flashback Table restores tables while automatically maintaining associated
attributes such as current indexes, triggers, and constraints, and not requiring you
to find and restore application-specific properties.
•
Flashback Drop
You can reverse the effects of a DROP TABLE statement.
All logical flashback features except Flashback Drop rely on undo data. Used
primarily for providing read consistency for SQL queries and rolling back transactions,
undo records contain the information required to reconstruct data as it existed at a
past time and examine the record of changes since that past time.
Flashback Drop relies on a mechanism called the recycle bin, which the database
uses to manage dropped database objects until the space they occupied is needed for
new data. There is no fixed amount of space allocated to the recycle bin, and no
guarantee regarding how long dropped objects remain in the recycle bin. Depending
on system activity, a dropped object may remain in the recycle bin for seconds or for
months.
18-4
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
See Also:
•
Rewinding a Table with Flashback Table
•
Rewinding a DROP TABLE Operation with Flashback Drop
•
Oracle Database Administrator’s Guide for more information about undo
data and automatic undo management
18.1.3 Basic Concepts of Performing Flashback Database for CDBs
and PDBs
You can perform a Flashback Database operation for a whole multitenant container
database (CDB) or for a particular pluggable database (PDB).
Flashback Database for a whole CDB enables you to rewind the entire CDB, including
all its PDBs, to a previous point in time. Flashback Database for a particular PDB
enables you to reverse unwanted changes caused by logical data corruption or user
errors in that PDB. When you perform a Flashback Database operation for a specific
PDB, the other PDBs can be open and operational.
You can perform multiple flashback database operations on a single PDB. However,
you can only perform a flashback operation on a PDB to one of its ancestor
incarnations. A PDB must always stay in a past incarnation that is compatible with the
overall database incarnation.
To perform a Flashback Database operation for a PDB, the desired target point in time
can be specified using a PDB restore point, a CDB restore point, an SCN, or a time
expression. A flashback operation on a PDB to a CDB restore point is equivalent to a
flashback operation on the PDB to the restore point SCN on the CDB incarnation. In
general, for PDBs, a flashback operation to a PDB restore point is more accurate than
a flashback operation to a CDB restore point. This is because a PDB restore point
represents the PDB sub-incarnation of the point in time at which it was created.
You can also perform a Flashback Database operation for a PDB on a physical
standby database.
Backups of a PDB continue to be valid even after a Flashback Database operation is
performed on that PDB. In case of a media failure, you can recover from the failure by
restoring these PDB backups. This type of PDB recovery can recover through
database resetlogs and PDB resetlogs.
Note:
You cannot perform a flashback operation only on the root, you must perform
a flashback operation on the entire CDB.
18-5
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
Note:
To perform a flashback operation for an application container, you must
perform flashback operations for the application root and all the individual
application PDBs that are part of the application container. Performing a
flashback operation on the application root reverts only the application root to
the specified point in time.
See Also:
•
Performing a Flashback Database Operation for a Whole CDB
•
Performing a Flashback Database Operation for PDBs
•
Performing Flashback Database with SQL*Plus
18.1.3.1 About Flashback Database and PITR for PDBs
For pluggable databases (PDBs) that use local undo, database point-in-time recovery
(PITR) and flashback operations are independent of each other.
For PDBs that use shared undo, database point-in-time recovery and flashback
operations are independent with the following caveat:
•
If you perform a flashback operation for a PDB or recover a PDB to a particular
point in time, Oracle Database may apply undo data during the PDB resetlogs
operation to back out transactions that are not committed at that point in time. If
you subsequently recover the entire multitenant container database (CDB) to a
point in time that is in the middle of the PDB resetlogs operation, then you will
receive a warning that some PDBs may not be opened. For such PDBs, you need
to perform one of the following mutually exclusive actions:
–
Recover the entire CDB or perform a flashback operation for the entire CDB to
a different SCN
–
Recover all the affected PDBs or perform a flashback database operation for
all the affected PDBs to a different SCN
See Also:
•
Basic Concepts of Performing Flashback Database for CDBs and PDBs
•
About Undo and Flashback Database Operations for PDBs
•
About Managing Redo Corruption in CDBs
18-6
Chapter 18
Overview of Oracle Flashback Technology and Database Point-in-Time Recovery
18.1.3.2 About Undo and Flashback Database Operations for PDBs
A multitenant container database (CDB) can use shared undo or local undo. The
technique used by RMAN to perform flashback database operations depends on the
type of undo configuration for the CDB.
When a CDB uses local undo, performing a flashback database operation on a
pluggable database (PDB) is straight-forward because only data files related to that
PDB need to be modified.
In the case of a CDB that uses shared undo, since one set of tablespaces is shared by
all PDBs, undo data for multiple PDBs may be mixed within the undo tablespaces and
even within individual data blocks. Therefore, to perform a flashback database
operation for a PDB, RMAN automatically uses an auxiliary instance to restore shared
undo tablespaces and certain tablespaces in the root and then recovers data to the
required point in time. This process may involve restoring backups for a relatively
small amount of data. When you perform a flashback database operation on a PDB to
a clean PDB restore point, no auxiliary instance or restoring of backups is required.
By default, the auxiliary instance is created in the fast recovery area. You can use the
AUXILIARY DESTINATION clause in the FLASHBACK DATABASE command to specify an
alternate location for the auxiliary instance.
See Also:
•
Basic Concepts of Performing Flashback Database for CDBs and PDBs
•
About Flashback Database and PITR for PDBs
•
About Managing Redo Corruption in CDBs
•
Performing a Flashback Database Operation for a Whole CDB
•
Performing a Flashback Database Operation for PDBs
18.1.3.3 About Managing Redo Corruption in CDBs
RMAN provides methods to manage redo corruption to data blocks in a PDB.
In very rare circumstances, the redo logs in a multitenant container database (CDB)
may be corrupted. In such a scenario, if the affected data blocks reside only in one
pluggable database (PDB), then you can do one of the following:
•
perform a flashback operation on the PDB to a point in time before the corruption
and then open the PDB with RESETLOGS
•
perform a point-in-time recovery of the PDB to a point in time before the corruption
and then open the PDB with RESETLOGS
After you perform one of these steps on the primary database, any standby database
of this primary database can also skip the corrupted redo provided you perform the
steps required to enable a standby to follow a primary after a PITR or Flashback on
the PDB.
18-7
Chapter 18
Rewinding a Table with Flashback Table
See Also:
•
Basic Concepts of Performing Flashback Database for CDBs and PDBs
•
Oracle Data Guard Concepts and Administration for steps to enable a
standby to follow a primary
18.2 Rewinding a Table with Flashback Table
Flashback Table uses information in the undo tablespace rather than restored backups
to retrieve the table. When a Flashback Table operation occurs, new rows are deleted
and old rows are reinserted. The rest of your database remains available while the
flashback of the table is being performed.
To rewind a table to a previous point in time:
1.
Ensure that the prerequisites described in "Prerequisites for Flashback Table" are
met.
2.
Perform a Flashback Table operation on the table, as described in "Performing a
Flashback Table Operation".
See Also:
Oracle Database Administrator’s Guide for more information about automatic
undo management
18.2.1 Prerequisites for Flashback Table
To perform a Flashback Table operation, the table must be eligible to be flashed back
and the user performing the operation must have the required privileges.
You must have the following privileges to use the Flashback Table feature:
•
You must have been granted the FLASHBACK ANY TABLE system privilege or you must
have the FLASHBACK object privilege on the table.
•
You must have READ or SELECT, INSERT, DELETE, and ALTER privileges on the table.
•
To flash back a table to a restore point, you must have the SELECT ANY DICTIONARY
or FLASHBACK ANY TABLE system privilege or the SELECT_CATALOG_ROLE role.
For an object to be eligible to be flashed back, the following prerequisites must be met:
•
The object must not be included the following categories: tables that are part of a
cluster, materialized views, Advanced Queuing (AQ) tables, static data dictionary
tables, system tables, remote tables, object tables, nested tables, or individual
table partitions or subpartitions.
•
The structure of the table must not have been changed between the current time
and the target flashback time.
18-8
Chapter 18
Rewinding a Table with Flashback Table
The following Data Definition Language (DDL) operations change the structure of
a table: upgrading, moving, or truncating a table; adding a constraint to a table,
adding a table to a cluster; modifying or dropping a column; adding, dropping,
merging, splitting, coalescing, or truncating a partition or subpartition (except
adding a range partition).
•
Row movement must be enabled on the table, which indicates that rowids change
after the flashback occurs.
This restriction exists because if rowids before the flashback were stored by the
application, then there is no guarantee that the rowids correspond to the same
rows after the flashback. If your application depends on rowids, then you cannot
use Flashback Table.
•
The undo data in the undo tablespace must extend far enough back in time to
satisfy the flashback target time or SCN.
The point to which you can perform Flashback Table is determined by the undo
retention period, which is the minimal time for which undo data is kept before
being recycled, and tablespace characteristics. The undo data contains
information about data blocks before they were changed. The flashback operation
uses undo to re-create the original data.
To ensure that the undo information is retained for Flashback Table operations,
Oracle suggests setting the UNDO_RETENTION parameter to 86400 seconds (24
hours) or greater for the undo tablespace.
Note:
FLASHBACK TABLE ... TO BEFORE DROP is a use of the Flashback Drop feature,
not Flashback Table, and therefore is not subject to these prerequisites. See
"Rewinding a DROP TABLE Operation with Flashback Drop" for more
information.
18.2.2 Performing a Flashback Table Operation
To use the Flashback Table feature on one or more tables, use the FLASHBACK TABLE
SQL statement with a target time or SCN.
Assume that you want to perform a flashback of the hr.temp_employees table after a
user made some incorrect updates. Use the following steps:
1.
Ensure that the prerequisites that are described in "Prerequisites for Flashback
Table" are met.
2.
Connect SQL*Plus to the target database and identify the current SCN.
You cannot roll back a FLASHBACK TABLE statement, but you can issue another
FLASHBACK TABLE statement and specify a time just before the current time.
Therefore, it is advisable to record the current SCN. You can obtain it by querying
V$DATABASE as follows:
SELECT CURRENT_SCN FROM V$DATABASE;
3.
Identify the time, SCN, or restore point to which you want to return the table.
18-9
Chapter 18
Rewinding a Table with Flashback Table
If you have created restore points, then you can list available restore points by
executing the following query:
SELECT NAME, SCN, TIME FROM V$RESTORE_POINT;
4.
Ensure that enough undo data exists to rewind the table to the specified target.
If the UNDO_RETENTION initialization parameter is set, and the undo retention
guarantee is on, then you can use the following query to determine how long undo
data is being retained:
SELECT NAME, VALUE/60 MINUTES_RETAINED
FROM V$PARAMETER
WHERE NAME = 'undo_retention';
5.
Ensure that row movement is enabled for all objects that you are rewinding with
Flashback Table.
You can enable row movement for a table with the following SQL statement:
ALTER TABLE hr.temp_employees ENABLE ROW MOVEMENT;
6.
Determine whether the table that you intend to flash back has dependencies on
other tables. If dependencies exist, then decide whether to flash back these tables
as well.
You can issue the following SQL query to determine the dependencies, where
schema_name is the schema for the table to be flashed back and table_name is
the name of the table:
SELECT
FROM
WHERE
AND
AND
AND
AND
7.
other.owner, other.table_name
sys.all_constraints this, sys.all_constraints other
this.owner = schema_name
this.table_name = table_name
this.r_owner = other.owner
this.r_constraint_name = other.constraint_name
this.constraint_type='R';
Execute a FLASHBACK TABLE statement for the objects to flash back.
The following SQL statement returns the hr.temp_employees table to the restore
point named temp_employees_update:
FLASHBACK TABLE hr.temp_employees
TO RESTORE POINT temp_employees_update;
The following SQL statement rewinds the hr.temp_employees table to its state when
the database was at the time specified by the SCN:
FLASHBACK TABLE hr.temp_employees
TO SCN 123456;
As shown in the following example, you can also specify the target point in time
with TO_TIMESTAMP:
FLASHBACK TABLE hr.temp_employees
TO TIMESTAMP TO_TIMESTAMP('2013-10-17 09:30:00', 'YYYY-MM-DD HH:MI:SS');
18-10
Chapter 18
Rewinding a DROP TABLE Operation with Flashback Drop
Note:
The mapping of time stamps to SCNs is not always exact. When you use
time stamps with the FLASHBACK TABLE statement, the time to which the
table is flashed back can vary by up to approximately 3 seconds of the
time specified for TO_TIMESTAMP. If an exact point in time is required, then
use an SCN rather than a time.
8.
Optionally, query the table to check the data.
See Also:
Keeping Triggers Enabled During Flashback Table
18.2.2.1 Keeping Triggers Enabled During Flashback Table
By default, the database disables triggers on the affected table before performing a
FLASHBACK TABLE operation. After the operation, the database returns the triggers to the
state they were in before the operation (enabled or disabled).
To keep triggers enabled during the flashback of the table, add an ENABLE TRIGGERS
clause to the FLASHBACK TABLE statement.
For example, assume that at 17:00 an HR administrator discovers that an employee is
missing from the hr.temp_employees table. This employee was included in the table at
14:00, the last time the report was run. Therefore, someone accidentally deleted the
record for this employee between 14:00 and 17:00. The HR administrator uses
Flashback Table to return the table to its state at 14:00, respecting any triggers set on
the hr.temp_employees table, by using the SQL statement in the following example:
FLASHBACK TABLE hr.temp_employees
TO TIMESTAMP TO_TIMESTAMP('2013-03-03 14:00:00' , 'YYYY-MM-DD HH:MI:SS')
ENABLE TRIGGERS;
See Also:
•
Oracle Database Administrator’s Guide to learn how to recover tables
with the Flashback Table feature
•
Oracle Database SQL Language Reference for a simple Flashback
Table scenario
18.3 Rewinding a DROP TABLE Operation with Flashback
Drop
You can retrieve objects from the recycle bin with the FLASHBACK TABLE ... TO BEFORE
DROP statement.
18-11
Chapter 18
Rewinding a DROP TABLE Operation with Flashback Drop
This section contains the following topics:
•
About Flashback Drop
•
Prerequisites of Flashback Drop
•
Performing a Flashback Drop Operation
18.3.1 About Flashback Drop
Flashback Drop reverses the effects of a DROP TABLE operation. Flashback Drop is
faster than other recovery mechanisms that can be used in this situation, such as
point-in-time recovery, and does not lead to downtime or loss of recent transactions.
When you drop a table, the database does not immediately remove the space
associated with the table. Instead, the table is renamed and, along with any associated
objects, placed in the recycle bin. System-generated recycle bin object names are
unique. You can query objects in the recycle bin, just as you can query other objects.
A flashback operation retrieves the table from the recycle bin. When retrieving dropped
tables, you can specify either the original user-specified name of the table or the
system-generated name.
When you drop a table, the table and all of its dependent objects go into the recycle
bin together. Likewise, when you perform Flashback Drop, the objects are generally all
retrieved together. When you restore a table from the recycle bin, dependent objects
such as indexes do not get their original names back; they retain their systemgenerated recycle bin names. Oracle Database retrieves all indexes defined on the
table except for bitmap join indexes, and all triggers and constraints defined on the
table except for referential integrity constraints that reference other tables.
Some dependent objects such as indexes may possibly have been reclaimed because
of space pressure. In such cases, the reclaimed dependent objects are not retrievable
from the recycle bin.
18.3.2 Prerequisites of Flashback Drop
Prerequisites must be met before you perform a Flashback Drop operation.
The user privileges required for the operations related to Flashback Drop and the
recycle bin are as follows:
•
DROP
Any user with DROP privileges over an object can drop the object, placing it in the
recycle bin.
•
FLASHBACK TABLE ... TO BEFORE DROP
Privileges for this statement are tied to the privileges for DROP. That is, any user
who can drop an object can perform Flashback Drop to retrieve the dropped object
from the recycle bin.
•
PURGE
Privileges for a purge of the recycle bin are tied to the DROP privileges. Any user
having DROP TABLE, DROP ANY TABLE, or PURGE DBA_RECYCLE_BIN privileges can purge the
objects from the recycle bin.
•
READ or SELECT and FLASHBACK for objects in the Recycle Bin
18-12
Chapter 18
Rewinding a DROP TABLE Operation with Flashback Drop
Users must have the READ or SELECT and FLASHBACK privileges over an object in the
recycle bin to query the object in the recycle bin. Any users who had the READ or
SELECT privilege over an object before it was dropped continue to have the READ or
SELECT privilege over the object in the recycle bin. Users must have FLASHBACK
privilege to query any object in the recycle bin, because these are objects from a
past state of the database.
Objects must meet the following prerequisites to be eligible for retrieval from the
recycle bin:
•
The recycle bin is only available for non-system, locally managed tablespaces. If a
table is in a non-system, locally managed tablespace, but one or more of its
dependent segments (objects) is in a dictionary-managed tablespace, then these
objects are protected by the recycle bin.
•
Tables that have fine-grained auditing (FGA) and Virtual Private Database (VPD)
policies defined over them are not protected by the recycle bin.
•
Partitioned index-organized tables are not protected by the recycle bin.
•
The table must not have been purged, either by a user or by Oracle Database
during a space reclamation operation.
18.3.3 Performing a Flashback Drop Operation
Use the FLASHBACK TABLE ... TO BEFORE DROP statement to recover objects from the
recycle bin. You can specify either the name of the table in the recycle bin or the
original table name.
This section assumes a scenario in which you drop the wrong table. Many times you
have been asked to drop tables in the test databases, but in this case you accidentally
connect to the production database instead and drop hr.employee_demo. You decide to
use FLASHBACK TABLE to retrieve the dropped object.
To retrieve a dropped table:
1.
Ensure that the prerequisites described in "Prerequisites of Flashback Drop" are
met.
2.
Connect SQL*Plus to the target database and obtain the name of the dropped
table in the recycle bin.
You can use the SQL*Plus command SHOW RECYCLEBIN as follows:
SHOW RECYCLEBIN;
ORIGINAL NAME
RECYCLEBIN NAME
TYPE
DROP TIME
---------------- --------------------------------- ------------ ------------EMPLOYEE_DEMO
BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 TABLE
2013-04-11:17:08:54
The ORIGINAL NAME column shows the original name of the object, whereas the
RECYCLEBIN NAME column shows the name of the object as it exists in the bin.
Alternatively, you can query USER_RECYCLEBIN or DBA_RECYCLEBIN to obtain the table
name. The following example queries the RECYCLEBIN view to determine the original
names of dropped objects:
SELECT object_name AS recycle_name, original_name, type
FROM recyclebin;
RECYCLE_NAME
ORIGINAL_NAME
TYPE
-------------------------------- --------------------- ----------
18-13
Chapter 18
Rewinding a DROP TABLE Operation with Flashback Drop
BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 EMPLOYEE_DEMO
BIN$JKS983293M1dsab4gsz/I249==$0 I_EMP_DEMO
TABLE
INDEX
If you plan to manually restore original names for dependent objects, then ensure
that you make note of each dependent object's system-generated recycle bin
name before you restore the table.
Note:
Object views such as DBA_TABLES do not display the recycle bin objects.
3.
Optionally, query the table in the recycle bin.
You must use the recycle bin name of the object in your query rather than the
object's original name. The following example queries the table with the recycle bin
name of BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0:
SELECT *
FROM "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0";
Quotation marks are required because of the special characters in the recycle bin
name.
Note:
If you have the necessary privileges, then you can also use Flashback
Query on tables in the recycle bin, but only by using the recycle bin
name rather than the original table name. You cannot use Data
Manipulation Language (DML) or DDL statements on objects in the
recycle bin.
4.
Retrieve the dropped table.
Use the FLASHBACK TABLE ... TO BEFORE DROP statement. The following example
restores the BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 table, changes its name back to
hr.employee_demo, and purges its entry from the recycle bin:
FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP;
The table name is enclosed in quotation marks because of the possibility of
special characters appearing in the recycle bin object names.
Alternatively, you can use the original name of the table:
FLASHBACK TABLE HR.EMPLOYEE_DEMO TO BEFORE DROP;
You can also assign a new name to the restored table by specifying the RENAME TO
clause. For example:
FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP
RENAME TO hr.emp_demo;
5.
Optionally, verify that all dependent objects retained their system-generated
recycle bin names.
The following query determines the names of the indexes of the retrieved
hr.employee_demo table:
18-14
Chapter 18
Rewinding a DROP TABLE Operation with Flashback Drop
SELECT INDEX_NAME
FROM USER_INDEXES
WHERE TABLE_NAME = 'EMPLOYEE_DEMO';
INDEX_NAME
-----------------------------BIN$JKS983293M1dsab4gsz/I249==$0
6.
Optionally, rename the retrieved indexes to their original names.
The following statement renames the index to its original name of i_emp_demo:
ALTER INDEX "BIN$JKS983293M1dsab4gsz/I249==$0" RENAME TO I_EMP_DEMO;
7.
If the retrieved table had referential constraints before it was placed in the recycle
bin, then re-create them.
This step must be performed manually because the recycle bin does not preserve
referential constraints on a table.
See Also:
Retrieving Objects Using Flashback Drop When Multiple Objects Share the
Same Original Name
18.3.3.1 Retrieving Objects Using Flashback Drop When Multiple Objects
Share the Same Original Name
You can create, and then drop, several objects with the same original name. All
dropped objects are stored in the recycle bin.
For example, consider the SQL statements in the following example:
Example 18-1
Dropping Multiple Objects with the Same Name
CREATE TABLE temp_employees ( ...columns ); # temp_employees version 1
DROP TABLE temp_employees;
CREATE TABLE temp_employees ( ...columns ); # temp_employees version 2
DROP TABLE temp_employees;
CREATE TABLE temp_employees ( ...columns ); # temp_employees version 3
DROP TABLE temp_employees;
Each table temp_employees is assigned a unique name in the recycle bin when it is
dropped. You can use a FLASHBACK TABLE ... TO BEFORE DROP statement with the
original name of the table, as shown in this example:
FLASHBACK TABLE temp_employees TO BEFORE DROP;
The most recently dropped table with this original name is retrieved from the recycle
bin, with its original name.
The following example shows the retrieval from the recycle bin of all three dropped
temp_employees tables from the previous example, with each assigned a new name.
18-15
Chapter 18
Rewinding a Database with Flashback Database
Example 18-2
Renaming Dropped Tables
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_3;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_2;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_1;
Because the original name in FLASHBACK TABLE refers to the most recently dropped table
with this name, the last table dropped is the first retrieved.
You can also retrieve any table from the recycle bin, regardless of any collisions
among original names, by using the unique recycle bin name of the table. For
example, assume that you query the recycle bin as follows (sample output included):
SELECT object_name, original_name, createtime
FROM recyclebin;
OBJECT_NAME
-----------------------------BIN$yrMKlZaLMhfgNAgAIMenRA==$0
BIN$yrMKlZaVMhfgNAgAIMenRA==$0
BIN$yrMKlZaQMhfgNAgAIMenRA==$0
ORIGINAL_NAME
--------------TEMP_EMPLOYEES
TEMP_EMPLOYEES
TEMP_EMPLOYEES
CREATETIME
------------------2013-02-05:21:05:52
2013-02-05:21:25:13
2013-02-05:22:05:53
You can use the following command to retrieve the middle table:
FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;
See Also:
•
•
Oracle Database Administrator’s Guide to learn how to use Flashback
Drop and manage the recycle bin
Oracle Database SQL Language Reference for information about the
FLASHBACK TABLE statement
18.4 Rewinding a Database with Flashback Database
Flashback Database reverses unwanted changes by returning your database to its
state at a previous point in time.
This section contains the following topics:
•
Prerequisites of Flashback Database
•
Performing a Flashback Database Operation
•
Performing a Flashback Database Operation for a Whole CDB
•
Performing a Flashback Database Operation for PDBs
•
Monitoring Flashback Database
18-16
Chapter 18
Rewinding a Database with Flashback Database
18.4.1 Prerequisites of Flashback Database
Flashback Database works by undoing changes to the data files that exist at the
moment that you run the command. Prerequisites must be met to perform a Flashback
Database operation.
To use the FLASHBACK DATABASE command to return your database contents to points in
time within the flashback window, your database must have been previously
configured for flashback logging. To return the database to a guaranteed restore point,
you must have previously defined a guaranteed restore point.
Note the following important prerequisites:
•
No current data files are lost or damaged. You can only use FLASHBACK DATABASE to
rewind changes to a data file made by an Oracle database, not to repair media
failures.
•
You are not trying to recover from accidental deletion of data files, undo a shrink
data file operation, or undo a change to the database name.
•
You are not trying to use FLASHBACK DATABASE to return to a point in time before the
restore or re-creation of a control file. If the database control file is restored from
backup or re-created, then all accumulated flashback log information is discarded.
•
You are not trying to use FLASHBACK DATABASE to undo a compatibility change.
See Also:
•
"Overview of Flashback Database, Restore Points and Guaranteed
Restore Points"
•
"Using Normal and Guaranteed Restore Points"
•
Oracle Database Backup and Recovery Reference for a complete list of
command prerequisites and usage notes for FLASHBACK DATABASE
18.4.2 Performing a Flashback Database Operation
A Flashback Database operation uses the FLASHBACK DATABASE command to rewind the
database to a past point in time.
This topic presents a basic technique for performing a flashback of the database,
specifying the desired target point in time with a time expression, the name of a normal
or guaranteed restore point, or an SCN. It makes the following assumptions:
•
You are rewinding the database to a point in time within the current database
incarnation.
•
The SCN used in the FLASHBACK DATABASE command refers to an SCN in the direct
ancestral path of the database incarnations. An incarnation is in this path if it was
not abandoned after the database was previously opened with the RESETLOGS
option.
To perform a Flashback Database operation:
18-17
Chapter 18
Rewinding a Database with Flashback Database
1.
Ensure that the prerequisites described in "Prerequisites of Flashback Database"
are met.
2.
Connect SQL*Plus to the target database and determine the desired SCN, restore
point, or point in time for the FLASHBACK DATABASE command.
Obtain the earliest SCN in the flashback database window as follows:
SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
FROM V$FLASHBACK_DATABASE_LOG;
The most recent SCN that can be reached with Flashback Database is the current
SCN of the database. The following query returns the current SCN:
SELECT CURRENT_SCN FROM V$DATABASE;
You can query available guaranteed restore points as follows (sample output
included):
SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE
FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES';
NAME
SCN TIME
DATABASE_INCARNATION# GUA
--------------- ---------- --------------------- --------------------- --BEFORE_CHANGES
5753126 04-MAR-12 12.39.45 AM
2 YES
Note:
If the flashback window does not extend far enough back into the past to
reach the desired target time, and if you do not have a guaranteed
restore point at the desired time, then you can achieve similar results by
using database point-in-time recovery, as described in "Performing
Database Point-in-Time Recovery".
3.
Shut down the database consistently, ensure that it is not opened by any instance,
and then mount it:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
4.
Repeat the query in Step 2 of this procedure.
S