oracle database 10g backup recovery vol - 1

Oracle Database 10g: Backup and RecoveryVolume I Student Guide

D22057GC10 Production 1.0 June 2006 D46524

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Authors Donna Keesling Maria Billings Technical Contributors and Reviewers Christopher Andrews Tammy Bednar Tom Best Harald van Breederode Mary Jane Bryksa Marielle Canning Tim Chien Donna Cooksey Judy Ferstenberg Gerlinde Frenzen Joel Goodman Pete Jones Isabelle Marchand Sabiha Miri Manish Pawar Jim Spiller George Stabler Anthony Woodell Editor Daniel Milne Graphic Designer Satish Bettegowda Publisher Jobi Varghese

Copyright 2006, Oracle. All rights reserved. Disclaimer This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract. Trademark Notice Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Contents

1

Introduction Objectives 1-2 Course Objectives 1-3 What Is Backup and Recovery? 1-4 Performing Backup and Recovery Operations for an Oracle Database 1-5 Using Oracle Recovery Manager 1-6 Recovery Manager Components 1-7 Using Oracle Secure Backup 1-9 Overview of Oracle Backup Methods 1-10 When Do You Need to Use a Backup for Recovery? 1-12 Responding to User Error 1-13 Overview of Data Recovery 1-14 Oracle Database Architecture: Crash Recovery 1-15 Oracle Database Architecture: Recovery After Media Failure 1-16 Developing a Backup and Recovery Strategy for Your Oracle Database 1-17 Oracle Solutions for High Availability 1-18 Oracle High Availability Solutions for Unplanned Downtime 1-19 Summary 1-21 Configuring for Recoverability Objectives 2-2 Configuring Your Database for Backup and Recovery Operations 2-3 Configuring ARCHIVELOG Mode 2-4 Specifying a Backup Destination 2-5 Specifying a Retention Policy 2-6 Using a Flash Recovery Area 2-8 Defining a Flash Recovery Area 2-9 Defining Flash Recovery Area Using Enterprise Manager 2-10 Flash Recovery Area Space Management 2-11 Flash Recovery Area Space Usage 2-13 Monitoring the Flash Recovery Area 2-14 Benefits of Using a Flash Recovery Area 2-15 Summary 2-16 Practice Overview 2-17

2

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

iii

3

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

4

r O

Using RMAN to Perform Recovery Objectives 4-2 Using RMAN RESTORE and RECOVER Commands 4-3 Performing Recovery Using Enterprise Manager 4-4 Comparing Complete and Incomplete Recovery 4-5 Complete Recovery Following the Loss of Datafiles 4-6 Performing Complete Recovery: Loss of a Non-Critical datafile in ARCHIVELOG Mode 4-7

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

iv

Performing Complete Recovery: Loss of a System-Critical Datafile in ARCHIVELOG Mode 4-8 Recovery Using Incrementally Updated Backups 4-9 Using the Flash Recovery Area for Fast Recovery 4-10 Performing Restore and Recovery of a Database in NOARCHIVELOG Mode 4-11 Using Incremental Backups to Recover a Database in NOARCHIVELOG Mode 4-12 Restoring and Recovering the Database on a New Host 4-13 Preparing to Restore the Database to a New Host 4-14 Restoring the Database to a New Host 4-15 Performing Recovery with a Backup Control File 4-19 Restoring the Server Parameter File from the Control File Autobackup 4-20 Restoring the Control File from Autobackup 4-21 Performing Disaster Recovery 4-23 Summary 4-25 Practice Overview 4-26 5 Using Oracle Flashback Technologies Objectives 5-2 Using Oracle Flashback Technology 5-3 Flashback Drop and the Recycle Bin 5-4 Understanding the Recycle Bin 5-5 Restoring Tables from the Recycle Bin 5-6 Automatic Space Reclamation in the Recycle Bin 5-7 Manual Space Reclamation in the Recycle Bin 5-8 Bypassing the Recycle Bin 5-9 Querying the Recycle Bin 5-10 Querying Data in Dropped Tables 5-11 Using Flashback Technology to Query Data 5-12 Configuring Undo for Flashback 5-13 Flashback Query: Overview 5-14 Flashback Query: Example 5-15 Flashback Versions Query: Overview 5-16 Using Enterprise Manager to Perform Flashback Versions Query 5-17 Flashback Versions Query: Considerations 5-18 Flashback Transaction Query: Overview 5-19 Using Enterprise Manager to Perform Flashback Transaction Query 5-20 Flashback Transaction Query: Considerations 5-21 Flashback Table: Overview 5-22 Flashback Table 5-23 Enabling Row Movement on a Table 5-24 Performing Flashback Table 5-25

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

v

Flashback Table: Considerations 5-26 Flashback Database: Overview 5-27 Flashback Database Architecture 5-28 Configuring Flashback Database 5-29 Using Enterprise Manager to Configure Flashback Database 5-30 Flashback Database: Examples 5-31 Using Enterprise Manager to Perform Flashback Database 5-32 Flashback Database Considerations 5-35 Monitoring Flashback Database 5-36 Tuning Considerations for Flashback Database 5-39 Using Guaranteed Restore Points 5-41 Summary 5-42 Practice Overview 5-43 6 Using RMAN to Create a Duplicate Database Objectives 6-2 Using RMAN to Create a Duplicate Database 6-3 Using a Duplicate Database 6-4 Creating a Duplicate Database 6-5 Creating an Initialization Parameter File for the Auxiliary Instance 6-6 Specifying Parameters to Control File Naming 6-7 Starting the Instance in NOMOUNT Mode 6-9 Ensuring That Backups and Archived Redo Log Files Are Available 6-10 Allocating Auxiliary Channels 6-11 Using the RMAN DUPLICATE Command 6-12 Understanding the RMAN Duplication Operation 6-13 Specifying Options for the DUPLICATE Command 6-14 Using Enterprise Manager to Create a Duplicate Database 6-15 Using Enterprise Manager: Source Working Directory 6-16 Using Enterprise Manager: Select Destination 6-17 Using Enterprise Manager: Destination Options 6-18 Using Enterprise Manager: Review Page 6-19 Summary 6-20 Practice Overview 6-21 Performing Tablespace Point-in-Time Recovery Objectives 7-2 Tablespace Point-in-Time Recovery (TSPITR) Concepts 7-3 Tablespace Point-in-Time Recovery (TSPITR): Terminology 7-4 Tablespace Point-in-Time Recovery: Architecture 7-5 Understanding When to Use TSPITR 7-7

7

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

vi

Preparing for TSPITR 7-8 Determining the Correct Target Time 7-9 Determining the Tablespaces for the Recovery Set 7-10 Identifying Objects That Will Be Lost 7-11 Performing Basic RMAN TSPITR 7-12 Performing Fully Automated TSPITR 7-13 Using Enterprise Manager to Perform TSPITR 7-14 Understanding TSPITR Processing 7-15Performing Customized RMAN TSPITR with an RMAN-Managed Auxiliary Instance 7-17

Performing RMAN TSPITR Using Your Own Auxiliary Instance 7-18 Troubleshooting RMAN TSPITR 7-19 Summary 7-21 Practice Overview 7-22 8 Using the RMAN Recovery Catalog Objectives 8-2 RMAN Repository Data Storage: Comparison of Options 8-3 Storing Information in the Recovery Catalog 8-4 Reasons to Use a Recovery Catalog 8-5 Creating the Recovery Catalog: Three Steps 8-6 Configuring the Recovery Catalog Database 8-7 Creating the Recovery Catalog Owner 8-8 Creating the Recovery Catalog 8-9 Managing Target Database Records in the Recovery Catalog 8-10 Registering a Database in the Recovery Catalog 8-11 Using Enterprise Manager to Register a Database 8-12 Unregistering a Target Database from the Recovery Catalog 8-14 Cataloging Additional Backup Files 8-15 Manually Resynchronizing the Recovery Catalog 8-16 Using RMAN Stored Scripts 8-17 Creating RMAN Stored Scripts 8-18 Executing RMAN Stored Scripts 8-19 Displaying RMAN Stored Script Information 8-20 Updating and Deleting RMAN Stored Scripts 8-21 Backing Up and Recovering the Recovery Catalog 8-22 Re-creating an Unrecoverable Recovery Catalog 8-23 Exporting and Importing the Recovery Catalog 8-24 Upgrading the Recovery Catalog 8-25 Dropping the Recovery Catalog 8-26 Summary 8-27 Practice Overview 8-28

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

vii

9

Monitoring and Tuning RMAN Objectives 9-2 Monitoring RMAN Sessions 9-3 Monitoring RMAN Job Progress 9-5 Monitoring RMAN Job Performance 9-7 Interpreting RMAN Message Output 9-8 Using the DEBUG Option 9-9 Understanding RMAN Code Layer Error Numbers 9-10 Interpreting RMAN Error Stacks 9-11 Tuning RMAN 9-12 RMAN Multiplexing 9-13 Allocating Disk Buffer: Example 9-14 Allocating Tape Buffers 9-15 Comparing Synchronous and Asynchronous I/O 9-16 Monitoring RMAN Job Performance 9-18 Asynchronous I/O Bottlenecks 9-19 Synchronous I/O Bottlenecks 9-20 Tape Backup Speed 9-21 Tape Subsystem Performance Rules 9-22 Controlling Tape Buffer Size with BLKSIZE 9-23 Channel Tuning 9-24 Tuning the BACKUP Command 9-25 Tuning RMAN Backup Performance 9-26 Setting LARGE_POOL_SIZE 9-27 Tuning RMAN Tape Streaming Performance Bottlenecks 9-28 Summary 9-30 Practice Overview 9-31

10 Oracle Secure Backup Overview Objectives 10-2 Oracle Secure Backup Tape Backup Management 10-3 What Is Oracle Secure Backup? 10-4Oracle Secure Backup: Tape Management and Integration with Oracle Products 10-5

r O

Client/Server Architecture Host Roles 10-6 Oracle Secure Backup for Centralized Tape Backup Management 10-7 Typical SAN Environment 10-8 Oracle Secure Backup Interface Options 10-9 Media Concepts: Overview 10-10 Backup Pieces and Backup Images 10-11 Media Management Expiration Policies 10-12 Oracle Secure Backup Media Family 10-14

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

viii

Tape Drives and Libraries 10-15 Virtual Tape Libraries (VTL) 10-17 Managing Data to Be Protected 10-18 Oracle Secure Backup Jobs 10-19 Securing Data and Access to the Backup Domain 10-20 Oracle Secure Backup: The Integration Advantage 10-22 Why Use Oracle Secure Backup? 10-23 Summary 10-24 11 Installing Oracle Secure Backup Objectives 11-2 Performing Preinstallation Tasks 11-3 Installation and Configuration of the Administrative Domain 11-4 Performing Installation Tasks 11-5 Administrative Server Installation: Example 11-6 Wizard-Based Installation on Windows 11-13 Oracle Secure Backup Interfaces 11-14 Integration with Enterprise Manager 11-15 Oracle Secure Backup Administrative Server Page 11-16 Configuring the Administrative Server in EM 11-17 Oracle Secure Backup Web Tool Home Page 11-18 Common obtool Commands 11-19 Configuring Oracle Secure Backup Users 11-20 Adding Oracle Secure Backup Users 11-21 Preauthorizing Access 11-23 Summary 11-24 Practice Overview 11-25 12 Using RMAN and Oracle Secure Backup Objectives 12-2 RMAN and Oracle Secure Backup Basic Process Flow 12-3 RMAN Database Backup to Tape 12-4 Database Backup Storage Selector 12-5 Defining Database Storage Selectors 12-7 Media Families and RMAN 12-8 Oracle Database Disk and Tape Backup Solution 12-9 Backing Up the Flash Recovery Area to Tape 12-10 Defining Retention for RMAN Backups 12-11 Backup Settings 12-12 Scheduling Backups with EM 12-13 Oracle-Suggested Backup to Tape 12-14

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

ix

RMAN and Oracle Secure Backup Job Execution 12-15 Managing Database Tape Backups 12-16 Performing Database Recovery 12-18 RMAN Automatic Failover to Previous Backup 12-19 Summary 12-20 Practice Overview 12-21 13 Backing Up File-System Files with Oracle Secure Backup Objectives 13-2 Backing Up File-System Files with Oracle Secure Backup 13-3 File-System Backups 13-4 Managing Media Families 13-5 Dataset Script: Examples 13-6 Creating Datasets 13-9 Creating Backup Windows 13-11 Creating Backup Schedules 13-13 Creating Backup Triggers 13-14 Previewing a Backup Trigger 13-16 Creating On-Demand Backup Requests 13-17 Submitting Backup Requests 13-19 Reviewing Jobs 13-20 Summary 13-21 Practice Overview 13-22 14 Restoring File-System Backups with Oracle Secure Backup Objectives 14-2 Browsing the Catalog for File-System Backup Data 14-3 Restoring File-System Data 14-4 Restoring File-System Files with Oracle Secure Backup 14-5 The Restore Page 14-6 Listing All File-System Backups of a Client 14-7 Creating a Catalog-Based Restore Request 14-8 Submitting Restore Requests 14-12 Summary 14-13 Practice Overview 14-14

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

x

15 Managing Oracle Secure Backup Security Objectives 15-2 Guarding Access and Data 15-3 Managing User Access Control 15-4 Predefined Classes and User Rights 15-5 Defining an Oracle Secure Backup User 15-8 Oracle Secure Backup User: OS Permissions 15-9 Preauthorization 15-11 Assigning Windows Account Information 15-12 Authentication 15-13 Leveraging Oracle Security Technology 15-14 Administrative Server Certificate Authority (CA) 15-16 Oracle Wallets 15-18 Encrypted Backups to Tape 15-20 Creating RMAN Encrypted Backups 15-21 Using Transparent Mode Encryption 15-22 Using Password Mode Encryption 15-24 Using Dual Mode Encryption 15-25 Restoring Encrypted Backups 15-26 Performing Encrypted Recovery 15-27 Summary 15-28 Practice Overview 15-29 16 Managing the Administrative Domain Objectives 16-2 Oracle Secure Backup Processes: Daemons 16-3 Managing Common Daemon Operations 16-5 Managing Policies and Defaults 16-6 Configuring Oracle Secure Backup Policies 16-7 Oracle Secure Backup: Backup Metadata Catalogs 16-8 Oracle Secure Backup: Directory Structure 16-10 Backing Up the Catalog 16-11 Adding Clients 16-12 Adding Media Servers 16-13 NAS Devices 16-15 Adding NDMP Media Servers 16-16 Adding Devices 16-17 Discovering Devices on NDMP Hosts 16-19 Managing Devices 16-20 Tape Library Properties 16-21 Tape Drive Properties 16-22

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

xi

Managing Volumes 16-23 Oracle Secure Backup Jobs 16-25 Managing Jobs 16-27 Viewing Job Properties and Transcripts 16-29 Suspending and Resuming Job Dispatching 16-31 Job Summaries 16-33 Displaying Log Files and Transcripts 16-34 Summary 16-35 Practice Overview 16-36 Appendix A: Practices Appendix B: Practice Solutions Appendix C: Oracle Secure Backup Additional Installation Topics Topics C-2 Windows Installation: Overview C-3 Stopping Tape Device Drivers C-4 Oracle Secure Backup Setup C-6 Service Startup Dialogs C-8 Service Login Dialog Box C-9 Oracle Secure Backup Installed Files C-10 Installed Files for Host Role: Administrative Server C-14 Installed Files for Host Role: Media Server C-16 Installed Files for Host Role: Client C-17 Specifying Installation Parameters C-18 Client Installation: Example C-20 Media Server Installation: Example C-21 Verifying Your Installation C-22 Uninstalling Oracle Secure Backup C-23 Summary C-25 Appendix D: Glossary

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

xii

Introduction

Copyright 2006, Oracle. All rights reserved.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Objectives

After completing this lesson, you should be able to: Describe course objectives Describe backup methods Describe the forms of data recovery Describe Oracle Recovery Manager architecture Plan a recovery strategy Plan a backup strategy based on your recovery strategy


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Oracle Database 10g: Backup and Recovery 1 - 2

Course Objectives

After completing this course, you should be able to: Use Oracle Recovery Manager (RMAN) to perform backup and recovery operations Create a duplicate database Perform tablespace point-in-time recovery Create and manage an RMAN recovery catalog Use Oracle Secure Backup to back up and restore Oracle databases and file-system data to and from tape


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


What Is Backup and Recovery?

Backup and recovery constitutes the strategies and procedures you employ to: Protect your database against data loss Reconstruct your database following data loss


What Is Backup and Recovery? The phrase backup and recovery refers to the strategies and techniques that are employed by database administrators to protect the database from loss and to reconstruct the database should loss occur.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Performing Backup and Recovery Operations for an Oracle DatabaseFor performing backup and recovery based on physical backups, the following solutions are available: Recovery Manager: A utility with a command-line client and an Enterprise Manager GUI interface User-managed backup and recovery: A technique that involves using operating system commands to create backups and using SQL*Plus commands for additional backup and recovery operations


Performing Backup and Recovery Operations for an Oracle Database Physical backups are backups of the physical files that comprise your Oracle database, including datafiles, control files, and archived redo log files. You can make backups of your database by using Recovery Manager (RMAN), a utility that creates and manages backups and enables you to perform recovery operations. Alternatively, you can create backups of your database files and perform recovery through a combination of SQL commands and operating system commands. RMAN is the preferred solution for backup and recovery operations for an Oracle database.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Using Oracle Recovery Manager

RMAN: Is a command-line client for advanced functions Has powerful control and scripting language Has a published API that enables interface with most popular backup software Backs up data, control, archived log, and server parameter files Backs up files to disk or tape

Enterprise Manager uses Recovery Manager (RMAN) to perform backup and recovery operations.


Using Oracle Recovery Manager RMAN is the component of Oracle Database that is used to perform backup and recovery operations. It can make consistent and inconsistent backups, perform incremental or full backups, and back up either the whole database or a portion of it. RMAN uses its own powerful job control and scripting language, as well as a published API that interfaces RMAN with many popular backup software solutions. RMAN can store backups on disk for quick recovery or place them on tape for long-term storage. In order for RMAN to store backups on tape, an interface to the tape device known as a Media Management Library (MML) must be configured. Enterprise Manager supplies a graphical interface to the most commonly used RMAN functionality. Advanced backup and recovery operations are accessible through the RMAN command-line client.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Recovery Manager Components

Target database (control file repository)

Server session

Recovery Manager (RMAN)

Enterprise Manager Server session

Options

Channel Auxiliary database

Channel

Channel MML Recovery catalog database

Disk

Flash Recovery AreaCopyright 2006, Oracle. All rights reserved.

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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Using Oracle Secure Backup

One tool to backup and restore Oracle databases and file-system data to and from tape Integrated with RMAN and Enterprise Manager Supports Oracle9i and Oracle Database 10g


Using Oracle Secure Backup The Oracle Secure Backup tape management system has been introduced to lower software costs and complexity. Oracle Secure Backup can back up all types of file-system files. Although Oracle Secure Backup has no specialized knowledge of database backup and recovery algorithms, it can serve as a media management layer for Recovery Manager (RMAN) through the system backup to tape (SBT) interface. In this capacity, Oracle Secure Backup provides the same services for RMAN as other supported third-party SBT libraries. Oracle Secure Backup delivers reliable database and file system backup to tape, with support for the major tape drives and libraries accessible through various protocols, including Small Computer System Interface (SCSI), Small Computer System Interface protocol (iSCSI), Network Data Management Protocol (NDMP), and Fibre Channel. Note: Oracle continues to support third-party media management vendors (MMV) through its Backup Solutions Program (BSP). Oracle Secure Backup uses the same RMAN API as thirdparty media management software, so you have a choice of products to use for writing your database backups to tape.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Overview of Oracle Backup Methods

Backup strategies: Whole: A backup of the control file and all datafiles that belong to a database Partial: A portion of the database

Backup types: Full: A non-incremental RMAN backup Incremental: Only information that has changed since some previous backup

Backups modes: Offline: Consistent, also referred to as cold backup Online: Inconsistent, also referred to as hot backup


Overview of Oracle Backup Methods A whole database backup includes all datafiles and at least one control file. Partial database backups may include zero or more tablespaces, zero or more datafiles, and may or may not include a control file. Full backups are non-incremental RMAN backups. You can make a full backup of only one datafile. Full does not refer to how much of the database is backed up, but to the fact that the backup is not incremental. Incremental backups make a copy of all data blocks that have changed since some previous backup. Oracle Database 10g supports two levels of incremental backup (0 and 1). A level 0 or baseline backup is equivalent to a full backup and contains all data blocks. A level 1 cumulative incremental backs up all database blocks changed since the level 0 backup. A level 1 differential incremental backs up all database blocks changed since a level 0 or level 1 backup. To restore using incremental backups, the baseline backup must first be restored, and then the incremental backup. You can make incremental backups with Recovery Manager (RMAN). Offline backups (also known as cold or consistent backups) are taken while the database is not open. They are consistent because at the time of the backup, the system change number (SCN) in the datafile headers matches the SCN in the control files.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Overview of Oracle Backup Methods (continued) Online backups (also known as hot or inconsistent backups) are taken while the database is open. The backups are inconsistent because, with the database open, there is no guarantee that the datafiles are synchronized with the control files.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


When Do You Need to Use a Backup for Recovery?The use of a backup to perform recovery is often required for the following types of errors: Media failure: The failure of a read or write of a database file due to a physical problem with the file User errors: Data in your database is changed or deleted incorrectly


When Do You Need to Use a Backup for Recovery? When you experience media failure, such as the loss of a disk drive, you may need to recover your database. This type of recovery typically requires the use of a backup of the affected files. In the case of user errors, when data in the database has been incorrectly updated or deleted, a backup may be required to enable you to recover the database to a point before the unwanted change.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Responding to User Error

Possible responses to user error include: Reentering the lost data manually, if a record of the changes exists Importing the dropped object, if a suitable export file exists or the object is still available on a standby database Performing tablespace point-in-time recovery (TSPITR) of one or more tablespaces Returning the database to a past state using database point-in-time recovery Using one of the Oracle Flashback features to recover from logical corruption by returning affected objects to a past stateCopyright 2006, Oracle. All rights reserved.

Responding to User Error When a user error occurs, your recovery options are based on the techniques and features you implemented in anticipation of the error. In later lessons, you investigate tablespace point-in-time recovery, database point-in-time recovery, and Oracle Flashback features.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Overview of Data Recovery

Crash recovery: Automatic recovery after instance failure Media recovery: Recovery of current datafiles, control files Complete recovery: Recovery of the database to the most recent point in time Incomplete recovery (point-in-time recovery): Recovery of the database to its state at a specific time or system change number (SCN)


Overview of Data Recovery Crash (instance) recovery and media recovery are performed to restore data integrity. Crash recovery happens the first time an Oracle database instance is started after a crash (or SHUTDOWN ABORT). The goal of crash recovery is to bring the datafiles to a transactionconsistent state, preserving all committed changes up to the point when the instance failed. Media recovery is initiated when you have experienced a loss of datafiles or all control files. You can perform a complete recovery to bring the database back to the point of failure by restoring datafiles from a backup and performing a recovery operation. In addition, you can perform an incomplete recovery operation by recovering the database to a named time or system change number (SCN).

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Oracle Database Architecture: Crash Recovery

The online redo log files are used to roll the database forward. Uncommitted changes are rolled back.

Online redo log files

Undo blocks

Database at time of instance failure

Database with committed and uncommitted transactionsCopyright 2006, Oracle. All rights reserved.

Database with committed transactions only

Oracle Database Architecture: Crash Recovery Crash recovery employs two distinct operations: Rolling forward the current, online datafiles by applying both committed and uncommitted transactions contained in online redo records Rolling back changes made in uncommitted transactions to their original state

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Oracle Database Architecture: Recovery After Media Failure Datafiles are restored from a backup. Archived and online redo log files are used to roll the database forward.

Online and archived redo log files

Undo blocks

Database with restored datafiles

Database with committed and uncommitted transactionsCopyright 2006, Oracle. All rights reserved.

Recovered database

Oracle Database Architecture: Recovery After Media Failure Media recovery is used to recover from a lost or damaged current datafile, server parameter file (SPFILE), or control file. It can also recover changes that were recorded in the redo log files but not in the datafiles for a tablespace that went offline without the OFFLINE NORMAL option. Media recovery has the following characteristics: Must be explicitly invoked by the DBA Applies needed changes to datafiles that have been restored from backup, not to online datafiles Requires the use of archived redo log files as well as the online redo log file

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Developing a Backup and Recovery Strategy for Your Oracle Database Assess service-level criteria, including: Data availability requirements Data criticality Recovery point and time objectives

Anticipate the errors that will arise in your environment and put in place the backup procedures needed to recover from those errors.


Developing a Backup and Recovery Strategy for Your Oracle Database Developing best practices for backup and recovery of your Oracle database begins with an assessment of all service level criteria for your environment, including recovery point and time objectives, data availability requirements, and data criticality.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Oracle Solutions for High Availability

In addition to backup and recovery strategies and procedures, consider the following Oracle solutions: Oracle Data Guard: Provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases Oracle Real Application Clusters (RAC): Enables access to a single database from multiples instances Oracle Streams: Enables the propagation and management of data, transactions, and events in a data stream LogMiner: Enables you to query redo log files through a SQL interface to provide data recovery


Additional Oracle Solutions for High Availability High availability systems are computing environments configured to provide nearly full-time availability. These systems typically have redundant hardware and software that make them available despite failures. Well-designed high availability systems avoid having single points of failure. When failures occur, the failover processes implemented as part of the system move processing performed by the failed component to backup components. Oracle has a number of products and features that provide high availability in cases of unplanned downtime or planned downtime. In this course, you focus on various backup and recovery techniques that help you to meet high availability needs. Additional Oracle solutions for high availability include Oracle Data Guard, Oracle Real Application Clusters (RAC), Oracle Streams, and LogMiner.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Oracle High Availability Solutions for Unplanned Downtime Computer failure: Fast-start fault recovery, Real Application Clusters (RAC), Data Guard, Oracle Streams Storage failure: Automatic Storage Management (ASM), RMAN with Flash Recovery Area, Data Guard, Oracle Streams Human errors: Oracle security features, Oracle Flashback technology, LogMiner Data corruption: Hardware Assisted Resilient Data (HARD) initiative, RMAN with Flash Recovery Area, Data Guard, Oracle Streams Site failure: RMAN, Data Guard, Oracle Streams


Oracle High Availability Solutions for Unplanned Downtime Oracle provides high availability solutions for the following types of unplanned downtime: Computer failure: The system on which the database operates is unavailable Storage failure: The storage holding some or all of the database is unavailable Human errors: Unintentional or malicious actions cause data within the database to become logically corrupt or unusable Data corruption: A hardware or software component causes corrupt data to be read or written to the database Site failure: An event causes all or a significant portion of an application to stop processing or slow to an unusable level The table on the following page describes the appropriate Oracle solution for the various types of unplanned downtimes. Additionally, an estimate of recovery time is provided for each. Use this table to help plan the appropriate implementation of Oracle solutions to enable you to meet your recovery goals.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Oracle High Availability Solutions for Unplanned Downtime (continued) Source: Oracle Database High Availability Overview Outage Type Oracle Solution Computer failures Fast-start Fault Recovery RAC Benefits Tunable and predictable cache recovery Automatic recovery of failed nodes and instances, fast connection failover, and service failover Fast start failover and fast connection failover Online replica database Mirroring; online auto rebalance Recovery Time Minutes to hours No downtime

Data Guard Oracle Streams Storage failure ASM RMAN with flash recovery area Data Guard Oracle Streams Human errors Oracle security features Oracle Flashback technology LogMiner Data corruption HARD RMAN with flash recovery area Data Guard

< 1 minute No downtime No downtime

Fully managed database recovery Minutes to hours and managed disk-based backups Fast start failover and fast connection failover Online replica database Restrict user access Fine-grained and database-wide rewind capability Log analysis Corruption prevention within a storage array < 1 minute No downtime No downtime

Online block media recovery and Minutes to hours managed disk-based backups Automatic validation of redo blocks; fast failover to an uncorrupted standby database Online replica database Fast start failover and fast connection failover Online replica database

Oracle Streams Site failure

ra O

le c

RMAN

In

rn te

l& a

O

I A

s U

O e

< 30 minutes

ly n

Minutes to hours No downtime

< 1 minute

No downtime Seconds to 5 minutes Seconds to 5 minutes

Fully managed database recovery Hours to days

Data Guard Oracle Streams


Summary

In this lesson, you should have learned how to: Describe backup methods Describe the forms of data recovery Describe Oracle Recovery Manager architecture Plan a recovery strategy Plan a backup strategy based on your recovery strategy


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Configuring for Recoverability


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Objectives

After completing this lesson, you should be able to: Configure your database in ARCHIVELOG mode Specify a retention policy Configure the Flash Recovery Area


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring Your Database for Backup and Recovery Operations Operate the database in ARCHIVELOG mode.Archiver (ARCn)Online redo log files Archived redo log files

Configure the Flash Recovery Area.

Archived redo log files

Control file backups

Datafile backups


Configuring Your Database When you operate your database in ARCHIVELOG mode, you have more recovery options after a data loss, including point-in-time recovery of the database or some tablespaces. It is recommended that you take advantage of the Flash Recovery Area to store as many backup and recovery-related files as possible, including disk backups and archived redo logs. Some features of Oracle Database backup and recovery, such as Oracle Flashback Database and guaranteed restore points, require the use of a Flash Recovery Area.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring ARCHIVELOG Mode

Perform the following steps to place the database in ARCHIVELOG mode: Using Enterprise Manager:1. Select the ARCHIVELOG Mode check box. 2. Click Apply. The database can be set to ARCHIVELOG mode only from the MOUNT state. 3. Click Yes when asked whether you want to restart the database.

Using SQL commands:1. Place the database in MOUNT mode. 2. Issue the ALTER DATABASE ARCHIVELOG MODE command 3. Open the database.


Configuring ARCHIVELOG Mode Placing the database in ARCHIVELOG mode prevents redo logs from being overwritten until they have been archived. The following SQL command is used to place the database in ARCHIVELOG mode:SQL> ALTER DATABASE ARCHIVELOG;

This command can be issued only while the database is in the MOUNT state. With the database in NOARCHIVELOG mode (the default), recovery is possible only until the time of the last backup. All transactions made after that backup are lost. In ARCHIVELOG mode, recovery is possible until the time of the last commit. Most production databases are operated in ARCHIVELOG mode. Note: Back up your database after switching to ARCHIVELOG mode because your database is recoverable only from the last backup taken in that mode.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Specifying a Backup Destination

Backups can be written to: Disk directory Tape using Oracle Secure Backup Media Management Library (tape device) Flash recovery area: Disk area set aside for backup and recovery and flashback database purposes


Backup Destinations Backups can be written to a designated disk directory, a Media Management Library, or the Flash Recovery Area. Specifying a disk directory or the Flash Recovery Area means that backups go to hard-disk media. Typically, backups are regularly moved offline to tape via the media management interface in order to maintain disk space availability. Any disk directory can be specified as the destination of a backup provided that it already exists. If you set up a Flash Recovery Area, many backup and recovery tasks are simplified for you. The Oracle database automatically names files for you, and deletes obsolete files when there is space pressure. More information about configuring Flash Recovery is provided later in this lesson.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Specifying a Retention Policy

Retention policy: Describes which backups will be kept and for how long Two types of retention policies: Recovery window: Establishes a period of time within which point-in-time recovery must be possibleFile2 File2 needs to be backed up: Seven-day retention File1 Now

Redundancy: Establishes a fixed number of backups that must be kept

Retention policies are mutually exclusive.Copyright 2006, Oracle. All rights reserved.

Specifying a Retention Policy A retention policy describes which backups will be kept and for how long. You can set the value of the retention policy by using the RMAN CONFIGURE command or Enterprise Manager. The best practice is to establish a period of time during which it will be possible to discover logical errors and fix the affected objects by doing a point-in-time recovery to just before the error occurred. This period of time is called the recovery window. This policy is specified in number of days. For each datafile, there must always exist one backup that satisfies the following condition:SYSDATE - checkpoint_time CONFIGURE RETENTION POLICY 2 TO RECOVERY WINDOW OF 7 DAYS;

Then, for each file there must be a backup that satisfies:

In the example in the slide, File1 has a backup that is within the seven-day retention period. File2 does not, so it needs to be backed up in order to satisfy the retention policy.

r O

cl a

SYSDATE - (SELECT checkpoint_time FROM V$DATAFILE WHERE file#= ) >= 7

In e

rn te

l& a

O

I A

s U

O e

ly n


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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Using a Flash Recovery Area

The Flash Recovery Area provides a centralized location for control file backups, archived redo logs, flashback logs, and database backups. The Flash Recovery Area can be defined as a directory, file system, or ASM disk group. A single Flash Recovery Area can be shared by more than one database.

Database area

Flash Recovery Area


Using a Flash Recovery Area The Flash Recovery Area is a unified storage location for all recovery-related files and activities in an Oracle database. All files that are needed to completely recover a database from a media failure are part of the Flash Recovery Area. The recovery-related files include: Control file: A copy is created in the Flash Recovery Area location at database creation. Archived redo log files: When the Flash Recovery Area is configured, LOG_ARCHIVE_DEST_10 is automatically set to the Flash Recovery Area location. The Archiver background process creates archived redo log files in the Flash Recovery Area and in other configured LOG_ARCHIVE_DEST_n locations. If no LOG_ARCHIVE_DEST_n locations are defined, the default location for archived redo log files is in the Flash Recovery Area. Flashback logs: Flashback logs are generated when Flashback Database is enabled. Control file autobackups: The default location for control file autobackups created by RMAN and autobackups generated by the Oracle database server is the Flash Recovery Area. Datafile copies: The BACKUP AS COPY command creates image datafile copies in the Flash Recovery Area. RMAN files: This is the default location that is used by RMAN for backups and restoration of the archive log content from tape for a recovery operation.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Defining a Flash Recovery Area

The Flash Recovery Area is defined by setting the following initialization parameters: DB_RECOVERY_FILE_DEST_SIZE: Sets the disk limit, expressed in bytes DB_RECOVERY_FILE_DEST: Sets the location for the Flash Recovery Area

These parameters are dynamic and can be altered or disabled.


Defining a Flash Recovery Area Use the following mandatory parameters to define the Flash Recovery Area: DB_RECOVERY_FILE_DEST_SIZE: You must define a disk limit, which is the amount of space that the Flash Recovery Area is permitted to use. Setting a disk limit allows the remaining disk space not dedicated to the Flash Recovery Area to be used for other purposes. The recommended size of the disk limit is the sum of the database size, size of incremental backups, and size of all archive log files that have not been copied to tape. In addition, when configuring the value of this parameter, it is recommended to set the value approximately 10 percent lower than what the operating system reports as free space because this disk limit does not include any overhead size that is not known to the Oracle database. For example, the DB_RECOVERY_FILE_DEST_SIZE parameter should account for any file system overhead due to file system metadata, compression, or mirroring. Therefore, if 10 GB is allocated for the Flash Recovery Area and the operating system reports free space as 10 GB (neglecting any file system overhead), then set the value of this parameter 10 percent lower than 10 GB. The minimum size of the Flash Recovery Area should be at least large enough to contain archived redo log files that have not been copied to tape. DB_RECOVERY_FILE_DEST: A Flash Recovery Area specification contains a location, which is a valid destination to create files.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Defining Flash Recovery Area Using Enterprise Manager


Defining Flash Recovery Area Using Enterprise Manager You can use Enterprise Manager Grid Control and Database Control to easily define the Flash Recovery Area. On the Database Control home page, navigate to the Maintenance page and click the Recovery Settings link in the Backup/Recovery Settings region. You can define the Flash Recovery Area location and its size on the Recovery Settings page. You must set the size of the Flash Recovery Area when specifying its location. Specifying a size allows any remaining disk space that is not dedicated to the Flash Recovery Area to be used for other purposes.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Flash Recovery Area Space ManagementDisk limit is reached and a new file needs to be written into the Flash Recovery Area Space pressure occurs Warning issued to user RMAN updates list of files that may be deleted 1 2 Backup files to be deleted

Database file backup 1 2 3 4

Flash Recovery Area

Files that are no longer required on disk are deleted


Flash Recovery Area Space Management Each time RMAN creates a file in the Flash Recovery Area, the list of files that are no longer required on disk is updated. When the Flash Recovery Area experiences space pressure or is low on free space because there are no files that can be deleted from the Flash Recovery Area, you are warned of the danger of running out of disk space. The Oracle Database server and RMAN continue to create files in the Flash Recovery Area until 100% of the disk limit is reached. When setting DB_RECOVERY_FILE_DEST_SIZE, you must consider whether you have allocated enough disk space before running out of space or necessitating a backup to tape. Files that are obsolete or have been backed up to tape are likely candidates for deletion to provide free space. When a file is written into the Flash Recovery Area and space is needed for that file, the Oracle Database server deletes a file that is on the obsolete files list. When a file is written and deleted from the Flash Recovery Area, notification is written into the alert log. Note: When Flash Recovery Area used space is at 85%, a warning is issued, and when used space is at 97%, a critical warning is issued. These are internal settings and cannot be changed. A sample alert log output follows:

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

WARNING: db_recovery_file_dest_size of 52428800 bytes is 100.00% used, and has 0 remaining bytes available.


Flash Recovery Area Space Management (continued) You can issue the following query to determine the action to take:SQL> SELECT object_type, message_type, message_level, 2> reason, suggested_action 3> FROM dba_outstanding_alerts;

Your choice is to add further disk space, back up files to a tertiary device, delete files from the Flash Recovery Area using RMAN, or consider changing the RMAN retention policy.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Flash Recovery Area Space Usage

Configure the retention policy to the minimum value appropriate for your database. Back up the archive log files regularly and delete the files upon completion of the backup. Use the RMAN REPORT OBSOLETE and DELETE OBSOLETE commands to remove backups and file copies that are not required.


Flash Recovery Area Space Usage To avoid running out of space in the Flash Recovery Area, you should never store usermanaged files in this area. You should also perform the following steps as needed or appropriate: Use RMAN to delete unnecessary files from the Flash Recovery Area. Use RMAN to take frequent backups of the Flash Recovery Area. Change the RMAN retention policy to retain backups for a smaller period of time. Change the RMAN archived log deletion policy. Add disk space and increase the value of the DB_RECOVERY_FILE_DEST_SIZE database initialization parameter if you are frequently running out of space. For example, to back up the archived log files in the Flash Recovery Area and then delete the files after they have been successfully backed up, you would use the RMAN command: If you use a backup solution other than RMAN, you still have to use RMAN to remove the files from the Flash Recovery Area. After the archived redo log files have been backed up and removed from disk, use the RMAN CROSSCHECK and DELETE commands to reclaim the archived log space from the Flash Recovery Area. You should do this on a regular basis, or after every backup.

r O

cl a

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

In e

rn te

l& a

O

I A

s U

O e

ly n


Monitoring the Flash Recovery Area


Monitoring the Flash Recovery Area Real-time Flash Recovery Area metrics can be viewed through Enterprise Manager Database Control. On the Maintenance page, scroll down to the Related Links section and select All Metrics. Scan the list and click Recovery Area. The displayed page shows the Recovery Area Free Space (%) metric, which indicates the percentage of the recovery that is free space. Click the percentage number to see the graph of recovery area usage.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Benefits of Using a Flash Recovery Area

Using the Flash Recovery Area for recovery-related files: Simplifies the location of database backups Automatically manages the disk space allocated for recovery files


Benefits of Using a Flash Recovery Area Using a Flash Recovery Area for all recovery-related files simplifies the ongoing administration of your database. Oracle Corporation recommends the use of the Flash Recovery Area for all recovery-related files.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Summary

In this lesson, you should have learned how to: Configure your database in ARCHIVELOG mode Specify a retention policy Configure the Flash Recovery Area


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Practice Overview

This practice covers the following topics: Placing the database in ARCHIVELOG mode Verifying that the Flash Recovery Area is configured Using RMAN to connect to the target database


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Using RMAN to Create Backups


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

Objectives

After completing this lesson, you should be able to: Configure persistent settings Configure backup destinations Configure backup optimization Create duplexed backup sets


r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Using RMAN to Create Backups

When creating a backup using RMAN, you can specify: Type: Full or incremental Files to back up: Entire database, datafiles, control file, server parameter file, archived redo log files Backup type: Image copy or backup set


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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Backup Destinations

Backups can be written to: Disk directory Media Management Library (tape device) Typically used for disaster recovery, when disk backups are lost.

Flash Recovery Area This is the disk area set aside for backup and recovery and flashback database purposes. Define the location and the size. Files are automatically named by using Oracle Managed Files. Files are automatically retained and deleted as necessary.


Backup Destinations Backups can be written to a designated disk directory, a Media Management Library, or the Flash Recovery Area. Specifying a disk directory or the Flash Recovery Area means that backups go to hard-disk media. Typically, they are regularly moved offline to tape via the media management interface in order to maintain disk space availability. Any disk directory can be specified as the destination of a backup provided that it already exists. If you configure a Flash Recovery Area, many backup and recovery tasks are simplified for you. The Oracle Database server automatically names files for you, and deletes obsolete files when there is space pressure.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring Persistent Settings for RMAN

RMAN is preset with default configuration settings. Use the CONFIGURE command to: Configure automatic channels Specify the backup retention policy Specify the number of backup copies to be created Set the default backup type to BACKUPSET or COPY Limit the size of backup pieces Exempt a tablespace from backup Enable and disable backup optimization Configure automatic backups of control files


Configuring Persistent Settings for RMAN To simplify ongoing use of RMAN for backup and recovery, RMAN enables you to set a number of persistent configuration settings for each target database. These settings control many aspects of RMANs behavior. You can save persistent configuration information such as channel parameters, parallelism, and the default device type in the RMAN repository (which is stored in either the control file or a recovery catalog database). These settings have default values, which allow you to use RMAN immediately. However, as you develop a more advanced backup and recovery strategy, you may have to change these settings to implement that strategy. You can use the CONFIGURE command to configure persistent settings for RMAN backup, restore, duplication, and maintenance jobs. These settings are in effect for any RMAN session until the configuration is cleared or changed.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Using Enterprise Manager to Configure RMAN Settings


Using Enterprise Manager to Configure RMAN Settings You can use Oracle Enterprise Manager to specify the backup settings for an instance. To specify backup settings, on the Maintenance page, select Backup Settings in the Backup/Recovery Settings section. The Backup Settings property page consists of three tabs: Device: Used to set the disk and tape configuration settings, including the Media Management Library (MML) settings Backup Set (shown in the slide): Used to specify parameters for backup sets and to enter host credentials Policy: Used to set various backup and retention policies before you initiate a backup, such as automatically backing up the control file and SPFILE. The Policy page also allows you to configure block change tracking support, a feature that provides faster incremental backups. Note: Backup settings change the databasewide settings and apply to any backups that do not override settings at the backup level.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Managing Persistent Settings

Use the SHOW command to list current settings:RMAN> SHOW CONTROLFILE AUTOBACKUP FORMAT; RMAN> SHOW EXCLUDE; RMAN> SHOW ALL;

Use the CLEAR command to reset any persistent setting to its default value:RMAN> CONFIGURE BACKUP OPTIMIZATION CLEAR; RMAN> CONFIGURE MAXSETSIZE CLEAR; RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;


Managing Persistent Settings Using the RMAN SHOW command, you can view the RMAN configuration settings. If SHOW ALL is executed when connected to a target database, only node-specific configurations and database configurations are displayed. You can return to the default value for any CONFIGURE command by executing the same command with the CLEAR option.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring and Allocating Channels for Use in Backups Configure automatic channels with the CONFIGURE command:RMAN> RMAN> RMAN> RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE sbt BACKUP DATABASE;

Allocate channels manually with the ALLOCATE CHANNEL command within a RUN block:RMAN> RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK; BACKUP DATABASE PLUS ARCHIVELOG; }


Configuring and Allocating Channels for Use in Backups Choose from the following options for configuring channels and executing backups: Configure automatic channels with the CONFIGURE command, and then issue the BACKUP command at the RMAN prompt or within a RUN block. Manually allocate channels with the ALLOCATE CHANNEL command within a RUN block, and then issue BACKUP commands.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring Backup Optimization

The BACKUP command skips backing up files when the identical files have already been backed up. It is used when the following conditions are true: Backup optimization is enabled. BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL commands are executed. Only one type of channel is allocated.

It can be overriden with the FORCE option. It is always used for RECOVERY AREA, DB_RECOVERY_FILE_DEST, and RECOVERY FILES BACKUP options.


Configuring Backup Optimization If you enable backup optimization, the BACKUP command skips backing up files when the identical files have already been backed up to the specified device type. If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. However, RMAN performs further checking to determine whether to skip the file, because both the retention policy and the backup duplexing feature are factors in the algorithm that RMAN uses to determine whether there are sufficient backups on the specified device type. Refer to the Oracle Database Backup and Recovery Advanced Users Guide for detailed information about the criteria that RMAN uses to determine whether a file is identical and the backup optimization algorithm. You can enable backup optimization on the Backup Settings page in Enterprise Manager or by issuing the CONFIGURE BACKUP OPTIMIZATION ON command. By default, backup optimization is disabled. Backup optimization is automatically enabled for the BACKUP RECOVERY AREA | DB_RECOVERY_FILE_DEST and BACKUP RECOVERY FILES commands.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Configuring Backup Optimization (continued) To override backup optimization and back up all files whether or not they have changed, specify the FORCE option on the BACKUP command as in the following example:BACKUP DEVICE TYPE sbt BACKUPSET ALL FORCE;

Note that the FORCE option does not apply to files in the recovery area. You can disable backup optimization on a persistent basis using Enterprise Manager or by issuing the following command:CONFIGURE BACKUP OPTIMIZATION OFF;

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Creating Backup Sets

RMAN> BACKUP AS BACKUPSET 2> FORMAT '/BACKUP/df_%d_%s_%p.bus' 3> TABLESPACE hr_data;Datafile 1 Datafile 2 Datafile 3

Datafile 1 Datafile 2 Datafile 3

Tablespace HR_DATA

Backup set


Creating Backup Sets RMAN can store its backups in an RMAN-exclusive format called a backup set. A backup set is a collection of files called backup pieces, each of which may contain one or more database file backups. Note: The FORMAT parameter specifies a pattern to use in creating a file name for the backup pieces created by this command. The FORMAT specification can also be provided through the ALLOCATE CHANNEL and CONFIGURE commands.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Creating Image Copies

RMAN> 2> 3> RMAN> 4> 5>

BACKUP AS COPY DATAFILE '/ORADATA/users_01_db01.dbf' FORMAT '/BACKUP/users01.dbf'; BACKUP AS COPY ARCHIVELOG LIKE '/arch%' FORMAT 'arch_%U.bak';

Copy of datafile 3Datafile 3 Datafile 3

Copy of archived logArchived log file Archived log fileCopyright 2006, Oracle. All rights reserved.

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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


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

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


BACKUP Command Options

Scan for logical corruptions and physical corruptions. Set a threshold on the number of detected corruptions allowed before aborting. Validate the target input files before performing a backup operation. Duplex the backup set. Overwrite an existing backup set or image copy. Pass control of the data transfer between storage devices and the datafiles on disk to the media management layer. Encrypt the backup files.


BACKUP Command Options

During the backup operation, an Oracle database process computes a checksum for each block to detect corruption. RMAN verifies the checksum when restoring the copy. This is referred to as physical corruption detection. You can use the NOCHECKSUM option to suppress the checksum operation and speed up the backup process. If the database is already maintaining block checksums, then this option has no effect. You can use the CHECK LOGICAL option to test data and index blocks that pass physical corruption checks for logical corruptionfor example, corruption of a row piece or index entry. If logical corruption is detected, the block is logged in the alert log and trace file of the server process. You can set a threshold for the allowed number of logical and physical corruptions with the MAXCORRUPT parameter. As long as the sum of physical and logical corruptions that is detected for a file remains below this value, the RMAN backup operation completes and the Oracle database populates the V$DATABASE_BLOCK_CORRUPTION view with the corrupt block ranges. If MAXCORRUPT is exceeded, then the operation terminates without populating the view. You can use the VALIDATE option to check for physical and logical errors in database files. When using the BACKUP command with the VALIDATE option, RMAN scans the specified files and verifies their contents, testing whether this file can be backed up. This command does not actually back up the specified files.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


BACKUP Command Options (continued) You can create up to four identical copies of each backup piece by duplexing the backup set. Use any of the following commands to produce a duplexed backup set: BACKUP COPIES SET BACKUP COPIES CONFIGURE ... BACKUP COPIES RMAN does not produce multiple backup sets, but produces identical copies of each backup piece in the set. You cannot use this option with the BACKUP AS COPY command to create multiple image copies. If you specify REUSE, you enable RMAN to overwrite an already existing backup set or image copy with the same file name as the file that BACKUP is currently creating. The PROXY copy functionality backs up the specified files by giving the media management software control over the data transfer between storage devices and the datafiles on disk. The media managernot RMANdecides how and when to move data. When you run BACKUP with the PROXY option, RMAN performs these steps: 1. It searches for a channel of the specified device type that is proxy capable. If no such channel is found, then RMAN issues a warning and attempts a conventional (that is, nonproxy) backup of the specified files. 2. If RMAN locates a proxy-capable channel, it calls the media manager to check whether it can proxy copy the files. If the media manager cannot proxy copy, then RMAN uses conventional backup sets to back up the files. If you do not want RMAN to try a conventional copy when a proxy copy fails, use the ONLY option. Because image copies are written only to disk, you cannot use the PROXY option with the BACKUP AS COPY command. Note: If you specify PROXY, then the %p variable must be included in the FORMAT string either explicitly or implicitly within %U. Encryption of backups is discussed later in this lesson.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Creating a Whole Database Backup

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Archived log file copies

Datafile copies

Control file

SPFILE


Creating a Whole Database Backup A whole database backup is a copy of all datafiles and the control file. You can optionally include the server parameter file (SPFILE) and archived redo log files. Using Recovery Manager to make an image copy of all the database files simply requires mounting the database, starting RMAN, and entering the BACKUP command shown in the slide. Note: You must have issued the following CONFIGURE commands to make the backup as described previously: CONFIGURE DEFAULT DEVICE TYPE TO disk; CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; CONFIGURE CONTROLFILE AUTOBACKUP ON; You can also create a backup (either a backup set or image copies) of previous image copies of all datafiles and control files in the database by using the following command: By default, RMAN executes each BACKUP command serially. However, you can parallelize the copy operation by: Using the CONFIGURE DEVICE TYPE DISK PARALLELISM n command, where n is the desired degree of parallelism Allocating multiple channels Specifying one BACKUP AS COPY command and listing multiple files

r O

cl a

RMAN> BACKUP COPY OF DATABASE;

In e

rn te

l& a

O

I A

s U

O e

ly n


RMAN Backup Types A full backup contains all used datafile blocks. A level 0 incremental backup is equivalent to a full backup that has been marked as level 0. A cumulative level 1 incremental backup contains only blocks modified since the last level 0 incremental backup. A differential level 1 incremental backup contains only blocks modified since the last incremental backup.Full, or "level 0 incremental backup"

Cumulative incremental backup

Differential incremental backup


RMAN Backup Types Full Backups A full backup is different from a whole database backup. A full datafile backup is a backup that includes every used data block in the file. RMAN copies all blocks into the backup set or image copy, skipping only datafile blocks that have never been used. For a full image copy, the entire file contents are reproduced exactly. A full backup cannot be part of an incremental backup strategy; it cannot be the parent for a subsequent incremental backup. Incremental Backups An incremental backup is either a level 0 backup, which includes every block in the datafiles except blocks that have never been used, or a level 1 backup, which includes only those blocks that have been changed since a previous backup was taken. A level 0 incremental backup is physically identical to a full backup. The only difference is that the level 0 backup can be used as the base for a level 1 backup, but a full backup can never be used as the base for a level 1 backup. Incremental backups are specified through the INCREMENTAL keyword of the BACKUP command. You specify INCREMENTAL LEVEL = [0 | 1].

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


RMAN Backup Types (continued) Incremental Backups (continued) RMAN can create multilevel incremental backups as follows: Differential: Is the default type of incremental backup that backs up all blocks changed after the most recent incremental backup at either level 1 or level 0 Cumulative: Backs up all blocks changed after the most recent backup at level 0 Examples To perform an incremental backup at level 0, use the following command:RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

To perform a differential incremental backup, use the following command:RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

To perform a cumulative incremental backup, use the following command:RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

RMAN makes full backups by default if neither FULL nor INCREMENTAL is specified. Unused block compression causes never-written blocks to be skipped when backing up datafiles to backup sets, even for full backups. A full backup has no effect on subsequent incremental backups, and is not considered part of any incremental backup strategy, although a full image copy backup can be incrementally updated by applying incremental backups with the RECOVER command. This is covered later in this lesson.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Fast Incremental Backup

Optimizes incremental backups Tracks which blocks have changed since the last backup

Oracle Database 10g has integrated change tracking: A change tracking file is introduced. Changed blocks are tracked as redo is generated. Database backup automatically uses the changed block list.List of changed blocks Redo generation

CTWR

1011001010110 0001110100101 1010101110011

Change tracking file Redo log

SGA


Fast Incremental Backup The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database. During media recovery, RMAN examines the restored files to determine whether it can recover them from an incremental backup. RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than reapplying individual changes. If you enable the block change tracking feature, Oracle Database tracks the physical location of all database changes in a file called the change tracking file. RMAN uses this change tracking data to determine which blocks to read during an incremental backup, creating much faster incremental backups by eliminating the need to read the entire datafile. The maintenance of this file is fully automatic and does not require your intervention. The size of the block change tracking file is proportional to the: Database size in bytes Number of enabled threads in a RAC environment Number of old backups maintained by the block change tracking file The minimum size for the block change tracking file is 10 MB, and any new space is allocated in 10 MB increments. The Oracle database does not record block change information by default.

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n


Enabling Fast Incremental Backup

ALTER DATABASE {ENABLE|DISABLE} BLOCK CHANGE TRACKING [USING FILE '...']


Enabling Fast Incremental Backup You enable block change tracking from the Database Control home page. Click the Policy tab from the Backup Settings on the Maintenance tabbed page. You do not need to set the block change tracking file destination if the DB_CREATE_FILE_DEST initialization parameter is set because the file is created as an Oracle Managed File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however, specify the name of the block change tracking file, placing it in any location you choose. You can also enable or disable this feature by using an ALTER DATABASE command. If the change tracking file is stored in the database area with your database files, then it is deleted when you disable change tracking. You can rename the block change tracking file by using the ALTER DATABASE RENAME command. Your database must be in the MOUNT state to rename the tracking file. The ALTER DATABASE RENAME FILE command updates the control file to refer to the new location. You can use the following syntax to move the block change tracking file name:

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

ALTER DATABASE RENAME FILE '...' TO '...';


Monitoring Block Change Tracking

SQL> SELECT filename, status, bytes 2 FROM v$block_change_tracking; SQL> 2 3 4 5 5 6 7 8 SELECT file#, avg(datafile_blocks), avg(blocks_read), avg(blocks_read/datafile_blocks) * 100 AS PCT_READ_FOR_BACKUP, avg(blocks) FROM v$backup_datafile WHERE used_change_tracking = 'YES' AND incremental_level > 0 GROUP BY file#;Copyright 2006, Oracle. All rights reserved.

Monitoring Block Change Tracking The output of the V$BLOCK_CHANGE_TRACKING view shows where the block change tracking file is located, the status of block change tracking (ENABLED/DISABLED), and the size (in bytes) of the file. The query on the V$BACKUP_DATAFILE view shows how effective the block change tracking is in minimizing the incremental backup I/O (the PCT_READ_FOR_BACKUP column). A high value indicates that RMAN reads most blocks in the datafile during an incremental backup. You can reduce this ratio by decreasing the time between the incremental backups. A sample formatted output from the V$BACKUP_DATAFILE query is shown below:FILE# ----1 2 3 4 5 BLOCKS_IN_FILE -------------56320 3840 49920 640 19200

r O

cl a

In e

rn te

l& a

O

I A

s U

O e

ly n

BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP ----------- ------------------- ---------------4480 7 462 2688 70 2408 16768 33 4457 64 10 1 256 1 91


Creating an Oracle-Suggested Backup


Creating an Oracle-Suggested Backup Enterprise Manager makes it easy for you to set up an Oracle-suggested backup strategy that protects your data and provides efficient recoverability to any point in the preceding 24 hours. The Oracle-suggested strategy uses the incremental backup and incrementally updated backup features, providing faster recoverability than is possible when applying database changes from the archived log files. To establish an Oracle-suggested strategy, navigate to the Maintenance page. In the Backup/Recovery region, select Schedule Backup. The Backup Strategy enables you to select from the Oracle-Suggested Backup and Customized Backup strategies. The Oracle-suggested strategy takes a full database copy as the first backup. Because it is a whole database backup, you might want to consider taking this at a period of least activity. After that, an incremental backup to

oracle database 10g backup recovery vol - 1

Documents