Oracle 9i DBA Fund - II

INSTRUCTOR’S EDITION
Oracle9i
Database:
Fundamentals II
ANDREW C. SIMKOVSKY
Oracle9i Database: Fundamentals II
Andrew C.
Simkovsky
Andrew Simkovsky is an Oracle
Certified Professional Database
Administrator and published
author. His previous works include
Oracle training manuals for
Element K Press, and Oracle8i:
OCP Virtual Test Center (Sybex).
Currently, he is a Senior Database
Administrator for World Fuel
Services Corporation in Miami,
Florida. Andrew is also a SYSOP
for the world-renowned Quest
Software/RevealNet Labs DBA
Pipeline (www.quest-pipelines.
com). Prior to working at World
Fuel Services, Andrew held several
Oracle-related positions, including
IT manager, DBA, consultant, and
OCP instructor. He has managed
Oracle databases ranging in size
from 5 gigabytes to over 20
terabytes, and his Oracle
experience includes Internet
startups, telecommunications,
retail, and teaching.
ORACLE9I DATABASE: FUNDAMENTALS II
Course Number: 079176
Course Edition: 1.0
For software version: version 9.2.0.1.0
ACKNOWLEDGEMENTS
Project Team
Curriculum Developer and Technical Writer: Andrew C. Simkovsky • Sr. Copy Editors: Angie J. French and
Christy D. Johnson • Material Editor: Lance Anderson • Graphic/Print Designer: Isolina Salgado Toner •
Project Technical Support: Michael Toscano
Project Support
Content Manager: Susan B. SanFilippo • Project Coordinator: Nicole Heinsler • Development Assistance:
Warren Capps
NOTICES
DISCLAIMER: While Element K Content LLC takes care to ensure the accuracy and quality of these materials, we cannot guarantee their accuracy, and all materials are
provided without any warranty whatsoever, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. The name used in the data
files for this course is that of a fictitious company. Any resemblance to current or future companies is purely coincidental. We do not believe we have used anyone’s name in
creating this course, but if we have, please notify us and we will change the name in the next revision of the course. Element K is an independent provider of integrated
training solutions for individuals, businesses, educational institutions, and government agencies. Use of screenshots, photographs of another entity’s products, or another
entity’s product name or service in this book is for editorial purposes only. No such use should be construed to imply sponsorship or endorsement of the book by, nor any
affiliation of such entity with Element K. This courseware may contain links to sites on the Internet that are owned and operated by third parties (the “External Sites”). Element
K is not responsible for the availability of, or the content located on or through, any External Site. Please contact Element K if you have any concerns regarding such links or
External Sites.
TRADEMARK NOTICES: Element K and the Element K logo are trademarks of Element K LLC and its affiliates. Oracle9i is a registered trademark of Oracle Corporation in
the U.S. and other countries; the Oracle products and services discussed or described may be trademarks of Oracle Corporation. All other product names and services used
throughout this book may be common law or registered trademarks of their respective proprietors.
Copyright © 2003 Element K Content LLC. All rights reserved. Screenshots used for illustrative purposes are the property of the software proprietor. This publication, or any
part thereof, may not be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, storage in an information
retrieval system, or otherwise, without express written permission of Element K, 500 Canal View Boulevard, Rochester, NY 14623, (585) 240-7500, (800) 434-3466. Element K
Courseware LLC’s World Wide Web site is located at www.elementkcourseware.com.
This book conveys no rights in the software or other products about which it was written; all use or licensing of such software or other products is the responsibility of the
user according to terms and conditions of the owner. Do not make illegal copies of books or software. If you believe that this book, related materials, or any other Element K
materials are being reproduced or transmitted without permission, please call 1-800-478-7788.
ii Oracle9i Database: Fundamentals II

ORACLE9I DATABASE: FUNDAMENTALS II CONTENT
OVERVIEW
About This Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Lesson 1: Oracle Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Lesson 2: Backup and Recovery Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Lesson 3: User-managed Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Lesson 4: Recovery Manager Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Lesson 5: Recovery Manager Recoveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Lesson 6: Loading and Moving Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Additional Instructor Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Contents iii
CONTENTS ORACLE9I DATABASE: FUNDAMENTALS II
CONTENTS
About This Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Course Setup Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
How To Use This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
LESSON 1: ORACLE NETWORKING

Topic 1A Oracle9i Networking Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
Task 1A-1 Describe Oracle Net Architecture . . . . . . . . . . . . . . . . . . . . 6
The User Connection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Task 1A-2 Identify the Steps in the User Connection Process . . . . . . . . 12
Oracle Net Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Task 1A-3 Describe Oracle Net Layered Architecture . . . . . . . . . . . . . . . 17
Additional Networking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Task 1A-4 Identify Additional Networking Options . . . . . . . . . . . . . . . . 24
Topic 1B Basic Oracle Net Server-side Configuration . . . . . . . . . . . . . . 25

Task 1B-1 Configuring the Listener Process . . . . . . . . . . . . . . . . . . . . 28
The Listener Control (lsnrctl) Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Task 1B-2 Using the Listener Control (lsnrctl) Utility . . . . . . . . . . . . . . 37
Configure the Listener Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Task 1B-3 Configuring the Listener Manually . . . . . . . . . . . . . . . . . . . 42
Topic 1C Basic Oracle Net Client-side Configuration . . . . . . . . . . . . . . 46

Task 1C-1 Identify Names Resolution Methods . . . . . . . . . . . . . . . . . . 48
Configure Host Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Task 1C-2 Configuring Host Naming . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configure Local Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Task 1C-3 Configuring Local Naming . . . . . . . . . . . . . . . . . . . . . . . . . 57
Troubleshooting Connection Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Task 1C-4 Configuring Client and Server Tracing . . . . . . . . . . . . . . . . . 68
Topic 1D Oracle Shared Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Task 1D-1 Describing Oracle Shared Server Architecture . . . . . . . . . . . . 77
Configuring Oracle Shared Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Task 1D-2 Configure Oracle Shared Server. . . . . . . . . . . . . . . . . . . . . . 83
Monitoring and Tuning Oracle Shared Server . . . . . . . . . . . . . . . . . . . . 83
Task 1D-3 Describe Methods to Monitor and Tune Oracle Shared Server. . 86
iv Oracle9i Database: Fundamentals II

Configuring the Listener for Web Clients . . . . . . . . . . . . . . . . . . . . . . . 87
Task 1D-4 Configure the Listener for Web Clients. . . . . . . . . . . . . . . . . 90 CONTENTS
Lesson Review 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
LESSON 2: BACKUP AND RECOVERY OVERVIEW

Topic 2A Introduction to Backup and Recovery . . . . . . . . . . . . . . . . . . 96
Task 2A-1 Identify Types of Failures . . . . . . . . . . . . . . . . . . . . . . . . . 99
Backup and Recovery Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Task 2A-2 Describe Backup and Recovery Basics . . . . . . . . . . . . . . . . . 104
Instance and Media Recovery Structures . . . . . . . . . . . . . . . . . . . . . . . 105
Task 2A-3 Identify Instance and Media Recovery Structures . . . . . . . . . 113
Topic 2B Cold Backup and Recovery Concepts. . . . . . . . . . . . . . . . . . . .114

Task 2B-1 Performing a Cold Database Backup . . . . . . . . . . . . . . . . . . 115
Cold Recovery Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Task 2B-2 Perform a Cold Database Recovery . . . . . . . . . . . . . . . . . . . 123
Topic 2C Hot Backup and Recovery Concepts . . . . . . . . . . . . . . . . . . . .127

Task 2C-1 Configuring Archivelog Mode . . . . . . . . . . . . . . . . . . . . . . . 132
Hot Recovery Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Task 2C-2 Describe Hot Database Recovery. . . . . . . . . . . . . . . . . . . . . 138
Lesson Review 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
LESSON 3: USER-MANAGED BACKUP AND RECOVERY

Topic 3A User-managed Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Task 3A-1 Hot Backup Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Backing Up the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Task 3A-2 Backing Up the Control File . . . . . . . . . . . . . . . . . . . . . . . . 150
Read-only Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Task 3A-3 Identify Backup Considerations for Read-only Tablespaces . . . 154
Resolving a Failed Hot Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Task 3A-4 Resolve a Failed Hot Backup . . . . . . . . . . . . . . . . . . . . . . . 155
Topic 3B User-managed Complete Recovery . . . . . . . . . . . . . . . . . . . . .159

Task 3B-1 Recover a Tablespace After a Failure . . . . . . . . . . . . . . . . . . 162
Trial Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Task 3B-2 Perform a Trial Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Restoring Datafiles to New Locations. . . . . . . . . . . . . . . . . . . . . . . . . . 171
Task 3B-3 Restore Datafiles to New Locations . . . . . . . . . . . . . . . . . . . 173
Topic 3C User-managed Incomplete Recovery. . . . . . . . . . . . . . . . . . . .176

Task 3C-1 Describe Incomplete Recovery Concepts . . . . . . . . . . . . . . . 180
Loss of Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Contents v
CONTENTS Task 3C-2 Recovering After Loss of Control File . . . . . . . . . . . . . . . . . 182
Loss of the Current Online Log Group . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Task 3C-3 Recover From the Loss of the Current Online Log Group . . . . . 190
Read-only Tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Task 3C-4 Identify Recovery Considerations for Read-only Tablespaces . . 198
Tablespace Point-in-Time Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Task 3C-5 Describe Tablespace Point-in-Time Recovery . . . . . . . . . . . . . 201
Lesson Review 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
LESSON 4: RECOVERY MANAGER BACKUPS

Topic 4A RMAN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
Task 4A-1 List and Describe RMAN Features . . . . . . . . . . . . . . . . . . . . 208
The RMAN Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Task 4A-2 Describe the RMAN Repository and its Contents . . . . . . . . . . 213
RMAN Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Task 4A-3 Describe the RMAN Process Flow . . . . . . . . . . . . . . . . . . . . 216
Image Copies and Backup Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Task 4A-4 Describe How RMAN Creates Image Copies and Backup Sets . . 219
Topic 4B Configuring the RMAN Environment . . . . . . . . . . . . . . . . . . . .219

Task 4B-1 Using the Control File as the RMAN Repository . . . . . . . . . . . 221
Create the Recovery Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Task 4B-2 Creating the Recovery Catalog . . . . . . . . . . . . . . . . . . . . . . 224
Register a Target Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Task 4B-3 Registering a Target Database . . . . . . . . . . . . . . . . . . . . . . 227
RMAN Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Task 4B-4 Set the RMAN Configuration Parameters . . . . . . . . . . . . . . . 233
Topic 4C RMAN Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236

Task 4C-1 Performing Cold Database Backups Using RMAN . . . . . . . . . . 239
RMAN Hot Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Task 4C-2 Perform a Hot Backup of the Database Using RMAN . . . . . . . 244
RMAN Incremental Hot Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Task 4C-3 Perform Incremental Hot Backups using RMAN . . . . . . . . . . . 248
Backing Up the Archive Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Task 4C-4 Backing Up the Archive Logs . . . . . . . . . . . . . . . . . . . . . . . 253
Topic 4D RMAN Catalog Maintenance and Management . . . . . . . . . . . .254

Task 4D-1 Creating, Using, and Managing RMAN Scripts . . . . . . . . . . . . 256
RMAN Reports and Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Task 4D-2 Generate RMAN Reports and Lists . . . . . . . . . . . . . . . . . . . . 262
Crosscheck and Delete Backup Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Task 4D-3 Crosschecking and Deleting Backup Sets . . . . . . . . . . . . . . . 269
Catalog OS-level Database Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Task 4D-4 Cataloging OS-level Database Backups. . . . . . . . . . . . . . . . . 273
vi Oracle9i Database: Fundamentals II

Backup and Restore Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Task 4D-5 Validate Backup and Restore Operations . . . . . . . . . . . . . . . 275 CONTENTS
Backing Up the Recovery Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Task 4D-6 List and Describe Methods to Back Up the Recovery Catalog . 279
Lesson Review 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
LESSON 5: RECOVERY MANAGER RECOVERIES

Topic 5A RMAN Complete Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .286
Task 5A-1 Restoring Files with RMAN . . . . . . . . . . . . . . . . . . . . . . . . 288
Performing Complete Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Task 5A-2 Perform a Complete Recovery . . . . . . . . . . . . . . . . . . . . . . . 293
Block Media Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Task 5A-3 Describe Block Media Recovery. . . . . . . . . . . . . . . . . . . . . . 296
Topic 5B RMAN Incomplete Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . .297

Task 5B-1 Describe Recovery with RMAN After Loss of Control File. . . . . 300
Loss of the Current Redo Log Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Task 5B-2 Using RMAN to Recover After Loss of the Current Redo Log . . 302
Tablespace Point-in-Time Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Task 5B-3 Describe Tablespace Point-in-Time Recovery Using RMAN . . . . 313
Lesson Review 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
LESSON 6: LOADING AND MOVING DATA

Topic 6A Load Data into the Database . . . . . . . . . . . . . . . . . . . . . . . . . .318
Task 6A-1 Using SQL*Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Direct Load Inserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Task 6A-2 Loading Data Using Direct Load Inserts . . . . . . . . . . . . . . . . 330
External Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Task 6A-3 Creating and Accessing External Tables . . . . . . . . . . . . . . . . 336
Topic 6B The Export and Import Utilities . . . . . . . . . . . . . . . . . . . . . . .341

Task 6B-1 Exporting the Database. . . . . . . . . . . . . . . . . . . . . . . . . . . 344
The Import Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Task 6B-2 Importing Data into the Database . . . . . . . . . . . . . . . . . . . 350
Transportable Tablespaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Task 6B-3 Transporting a Tablespace . . . . . . . . . . . . . . . . . . . . . . . . . 355
Apply Your Knowledge 6-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Lesson Review 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Additional Instructor Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371
Contents vii
viii Oracle9i Database: Fundamentals II
ABOUT THIS COURSE ABOUT THIS
This course introduces the concepts of Oracle9i® network configuration and data-
base backup and recovery. You will learn how to configure the Oracle9i network
COURSE
environment to support connections to and from the database. You will also learn
how to perform backups of the Oracle database using various techniques and how
to recover the database in various failure scenarios. Finally, you will learn how to
load, move, and reorganize large volumes of data very quickly using Oracle-
provided utilities. This course helps prepare students for Oracle’s exam, Oracle9i
Database: Fundamentals II (1Z0-032).
Course Prerequisites
To ensure your success, we recommend you first take the following Element K
courses or have equivalent knowledge:
• Oracle9i: SQL, PL/SQL, and SQL*Plus
• Oracle9i Database: Fundamentals I
Course Objectives
When you’re done working your way through this course, you’ll be able to:
• Describe and configure the Oracle Network Environment.

• Describe the basic concepts of database backup and recovery in Oracle9i.
• Perform user-managed backups and recoveries of the database.
• Perform backups of the database using RMAN.
• Perform complete and incomplete recoveries of the database using RMAN.
• Move data around quickly and easily using Oracle-provided utilities.
COURSE SETUP INFORMATION

Hardware and Software Requirements
To run this course, you will need:
About This Course ix

• Each machine (instructor and student) to meet the following minimum hard-
ware requirements:
— Pentium II 600 processor or faster.
— At least 256 MB of RAM.
— A minimum of 10 GB of available hard disk space for the System and
Oracle partitions.
— 256 k cache.
— 4x CD-ROM drive.
— SVGA monitor.
— Mouse or compatible pointing device.
• Each machine (instructor and student) to have the following software
installed or available:
— Microsoft Windows 2000 Professional with Service Pack 2 or higher.
— Oracle9i Enterprise Edition 9.2.0.1.0 (this installation will include both
Server and Client).
— Microsoft Notepad v.4.0 or better.
— One of the following Web browsers:
• Netscape Navigator 4.76 or higher.
• Microsoft Internet Explorer 5.0 or higher.
Class Requirements
In order for the class to run properly, perform the procedures described below.
1. As you prepare for the installation of the Oracle software, it is expected that
you will have your computer configured with the previously outlined
requirements. Please be sure that your hard drives are partitioned into at
This course will normally least two partitions. One partition should be designated as the C drive for the
refer to the D:\oracle drive. In operating system software. The system drive should be at least 2 GB in size
reality, you may be using the
and formatted as either FAT or NTFS. The second partition should be desig-
D drive, the E drive, or some
other drive letter. If your nated as the D drive and reserved for the Oracle installation. This drive
Oracle partition is declared needs to be at least 8 GB and formatted as either FAT or NTFS.
as a letter other than D, you
will need to replace the 2. Once the computer’s operating system is fully installed and configured, start
references in this manual Windows 2000 Professional and log on as Administrator.
with your respective drive
letter. Note: If you are installing Oracle by using the downloaded installation files
from Oracle Corporation’s Web site, rather than the installation CD-ROMs,
follow the instructions that came with the downloaded media. Additionally, the
installation files require considerable space on disk. Therefore, once the
Oracle9i software is installed, you should immediately delete the downloaded
installation files from the system.
Insert the Oracle9i (9.2.0.1.0) Enterprise Edition CD in the CD-ROM drive.

The CD will automatically run, and you will see the initial Oracle9i Wel-
come screen displayed on the screen. Click Install/Deinstall Products, and
the Oracle Universal Installer will begin loading.
3. Once the installer loads, you will see the Welcome screen. Click Next.
x Oracle9i Database: Fundamentals II

4. The File Locations screen prompts you to enter the paths for the source and
destination. The Source should show E:\stage\products.jar. If Destination
already doesn’t show it, set the Destination Name to OraHome92 and the
Path to D:\oracle\ora92. Click Next.
Note: If you are installing Oracle from the downloaded installation files, the
Source path may be different than the one given here.
You will see a progress meter in the upper-right corner of the installer win-
dow as the products list is loaded. This progress meter will appear several
times throughout the installation process.
5. The Available Products screen asks you to select a product to install. Select
Oracle9i Database 9.2.0.1.0, and then click Next.
Note: The software version you may actually be installing might have a
slightly different version number, such as 9.2.0.2.0. This course is designed to
work with Oracle9i version 9.2.0.1.0 or higher.
6. The Installation Types screen asks you to select an installation type. Select
Enterprise Edition, and then click Next.
7. The Database Configuration screen asks you to select a database suited to

your needs. Select General Purpose, and then click Next.
8. The Oracle Services for Microsoft Transaction Server screen asks you to
enter the port number on which the Oracle MTS Recovery Service will lis-
ten for requests. Leave the value at its default setting, and then click Next.
9. The Database Identification screen asks you to enter the Global Database
Name for the new database that will be created. For the Global Database
Name, type ora92. The same value for SID will automatically be entered for
you. Click Next.
10. The Database File Location screen allows you to select a directory to store
database files. If Directory For Database Files doesn’t show it, set the path
to D:\oracle\oradata. Click Next.
11. The Database Character Set screen asks you which character set should be
used in your database. The default character set should already be selected.
Click Next.
12. The Summary screen provides you with a summary of the installation set-
tings you have selected. Review the settings, and then click Install.
The Install screen shows a progress meter as Oracle is installed. Long pauses
in the progress of the meter are normal.
Note: The entire installation process could take 30 to 45 minutes or more,

depending on your system. You may occasionally see a number of windows
appearing and disappearing quickly throughout the installation process. This is
normal.
About This Course xi

13. Once the software is installed, the Configuration Tools screen will appear.
This screen displays information about the configuration tools that will auto-
matically be launched for you in sequence to guide you through some
additional configuration steps.
You will see the Database Configuration Assistant dialog box appear. The
dialog box will show the steps being taken to create and start the database,
along with a progress meter.
Once the database has been created and started, a new dialog box will
appear asking you to change the passwords for the SYS and SYSTEM users.
Set the password to ora92 for both the SYS and SYSTEM users, and then
click OK.
You will be returned to the Configuration Tools screen of the Oracle Univer-
sal Installer. You will see the installer execute additional configuration tools.
Once these tools have completed executing, the installer will move on to the
End Of Installation screen. This screen provides information about the HTTP
server that was installed with the database. Click Exit. A question box will
appear asking if you really want to exit. Click Yes.
14. After a few moments, the Oracle Enterprise Manager (OEM) Console will
appear. In the left pane of the Network tree, click the plus sign next to Data-
bases to expand the tree.
You will see an icon for ORA92 database. Double-click the ORA92 database
icon. The Database Connect Information dialog box will appear.
In the Username text box, type sys, and in the Password text box, type
ora92. Click the drop-down list for the Connect As entry, and select
SYSDBA. Click OK. After a moment, the Database Connect Information
dialog box will disappear, and the tree below the ORA92 database will
expand.
15. In the ORA92 tree, click the plus sign next to the Security icon to expand
the tree further.
Click the Users icon. The right pane will change to show a list of user
accounts that exist in the database.
16. In the right pane, find the user name RMAN in the list of users. Right-click
the RMAN user name to bring up a command menu. Click Remove.
A dialog box will appear stating that RMAN still owns objects in the data-
base, and asking if you are sure that you want drop the user and the objects
using the CASCADE option. Click Yes.
After a few moments, the RMAN user name will disappear from the list of
users.
17. Choose File→Exit to close the OEM Console.
18. Remember to delete the installation files as specified in the note at step 2.
To install the student files for this class, perform the following procedures:
1. Insert the CD-ROM that accompanies this course into the CD-ROM drive.
xii Oracle9i Database: Fundamentals II

2. Choose Start→Run, enter E:\079176\Data\079176dd.exe into the Open text
box, and click OK.
3. Once the self-extracting WinZip file opens, confirm or change that it will
write your files to the C drive in a folder named 079176.
List of Additional Files

Printed with each lesson is a list of files students open to complete the tasks in
that lesson. Many tasks also require additional files that students do not open, but
are needed to support the file(s) students are working with. These supporting files
are included with the student data files on the course CD-ROM or data disk. Do
not delete these files.
HOW TO USE THIS BOOK

You can use this book as a learning guide, a review tool, and a reference.
As a Learning Guide
Each lesson covers one broad topic or set of related topics. Lessons are arranged
in order of increasing proficiency with Oracle9i; skills you acquire in one lesson
are used and developed in subsequent lessons. For this reason, you should work
through the lessons in sequence.
We organized each lesson into explanatory topics and step-by-step activities. Top-
ics provide the theory you need to master Oracle9i, and activities allow you to
apply this theory to practical hands-on examples.
You get to try out each new skill on a specially prepared sample file. This saves
you typing time and allows you to concentrate on the technique at hand. Through
the use of sample files, hands-on activities, illustrations that give you feedback at
crucial steps, and supporting background information, this book provides you
with the foundation and structure to learn Oracle9i quickly and easily.
As a Review Tool
Any method of instruction is only as effective as the time and effort you are will-
ing to invest in it. For this reason, we encourage you to spend some time
reviewing the book’s more challenging topics and activities.
As a Reference
You can use the Concepts sections in this book as a first source for definitions of
terms, background information on given topics, and summaries of procedures.
About This Course xiii

xiv Oracle9i Database: Fundamentals II
Oracle Networking LESSON
Overview
1
Data Files
Oracle’s networking environment, called Oracle Net, enables connectivity none
between clients and database servers, and also between multiple database
servers, thereby enabling distributed enterprise level database applications. Lesson Time
In this lesson, you will learn about the features provided by Oracle Net and 4 hours, 25 minutes
how to configure your environment to provide optimal connectivity to your
database servers. You will learn how to configure the database server to
accept connections and also how to configure the client to initiate
connections. Additionally, you will learn how to optimize your Oracle Net
configuration to scale your environment to allow dozens, even hundreds, of
connections to the database if necessary.
Objectives
To describe and configure the Oracle Network Environment, you will:
1A Describe the features of the Oracle9i network environment.

Oracle Net provides network connectivity to Oracle databases. You will
learn about the features of Oracle Net, its overall architecture, and the
steps involved in connecting a client to the database server. You will also
learn the additional networking options that can be configured to enhance
network security.
1B Configure the database server to accept incoming network

connections.
Configuring the database server to accept incoming network connections
consists primarily of configuring the listener process. The responsibility
of the listener is to receive incoming connection requests from a variety
of sources and process them accordingly. In this topic, you will learn how
to configure the listener process and how to manage the listener through
the Listener Control (lsnrctl) utility.
1C Configure a client to connect to an Oracle9i database through the

network.
When a client connects to a remote database, a username and password
must be passed to the database. Additionally, the client must be able to
locate the target database on the network. In this topic, you will learn
how to configure the Oracle client to locate and connect to remote
databases.
1D Describe and configure Oracle Shared Server.

In a standard dedicated server configuration, each user that sends a con-
nection request to the listener will connect to the database through a
Lesson 1: Oracle Networking 1

dedicated server process. If you have a high number of concurrent users
online, this can be very costly in resources and impact performance.
Oracle Shared Server is a configuration that allows each server process to
handle multiple connections to user processes. This will allow a higher
number of user processes to connect to the database, while saving on
resources. You will learn the basic architecture of Oracle Shared Server
(OSS), and how to configure and tune an Oracle Shared Server
configuration.
2 Oracle9i Database: Fundamentals II

Topic 1A
Oracle9i Networking Overview
In the early days of the information industry, the very first database systems were
built on stand-alone mainframes. This means that a user must be physically sit-
ting at the machine where the data was stored to log in and retrieve data. It’s
easy to see why this type of configuration would not support multiple users and Client-server Architecture
could not fulfill many of the requirements for a corporate data system. With the
advent of the microcomputer, better known as the personal computer or PC, a
new type of configuration evolved, marrying the microcomputer and the main-
frame and providing the best of both worlds. A user could sit at his or her own client-server
desk and use the PC to log in to the mainframe. This is known as client-server architecture:
A configuration where
architecture or two-tier architecture. The PC acts as the client, while the main- multiple clients connect to a
frame acts as a server. Most often, there would be a single server with multiple single server.
clients connecting to it from various locations, allowing a much larger user base
to access the system simultaneously. Figure 1-1 shows an example of client-
server architecture.
Figure 1-1: Client-server architecture.

The disadvantage to client-server architecture is that each client requires special
software to connect to the server. Companies can have dozens, or even hundreds,
of clients, each requiring manual configuration. Also, if any configurations needed
to be changed or adjusted, each client would have to be changed individually,

requiring many hours of additional work. Also, older mainframe-style servers
could support only a limited number of users before performance started to
degrade significantly, and the rapid-fire development and release of newer ver-
sions of client software made it almost impossible to manage a large number of
clients.
As companies continued to grow, so did the requirements and expectations of
N-tier Architecture their information systems. True scalability became the focus of many software
and hardware manufacturers throughout the industry. Companies now began to
look for systems that could be purchased on a small scale, but that could grow as
the company grows, eliminating the need to replace critical systems as they reach
N-tier configuration: their maximum use. The solution began as a fairly simple one, but revolutionized
A multi-level configuration the way systems are designed and built, separating each component of the system
where each component of a into its own tier. This became known as a multi-tier or N-tier configuration. The
system, such as client, N represents a number, meaning an N-tier architecture can be made up of three,
application, and database, four, or more tiers as requirements dictate. In a 3-tier architecture, the database
resides at its own tier. server itself would be on one tier, a centralized application on the middle tier, and
the client on the third tier. Figure 1-2 shows a database system configured with
an N-tier architecture.
Figure 1-2: N-tier architecture.

In Figure 1-2, the clients use their own computers to connect to a centralized
application that runs on a server. The client is configured with only the minimal
software required to connect to the application, which can be as simple as an
Internet connection and a browser. The application server at the middle tier con-
tains all the program code required to run the application. Users on the client
machines issue simple commands to the application, which connects to the data-
base on the clients’ behalf and returns the data to the clients. More advanced
application servers can combine database requests from multiple clients and send
them to the database server in a single group, thereby reducing network traffic
and increasing performance. As the system grows, additional application servers

can be added to the middle tier to keep up with user demands. Any changes or
upgrades to the application only need to be done to the middle tier, simplifying
software management. This powerful configuration provides full scalability, ease
of maintenance, and superb performance regardless of the volume of data or the
number of users.
To facilitate connections to the Oracle database, either in a client-server or N-tier
architecture, Oracle makes use of its own network communication system called
Oracle Net. Oracle Net is a term that collectively refers to Oracle’s networking
infrastructure that enables clients to connect to servers and for servers to connect
to other servers. Database applications accomplish their tasks in a distributed
environment, meaning that a client may initiate a request to a single server, but
the request may be fulfilled by one, two, or more integrated application and data-
base servers. Oracle Net provides the connectivity between a client and the
database server, or between an application and database server, and provides a
host of features to support the connectivity, stability, and security requirements of
today’s networked database application systems.
Oracle Net Components

Oracle Net has evolved over the years from being just a standard protocol to
being a suite of products and features designed specifically to handle the chal-
lenge of operating database applications on the enterprise level by addressing
scalability, load balancing, failover, distributed transactions, security, and high
availability. Since Oracle Net uses a common network interface between applica-
tions and the database, it can be used with both older and newer applications to
provide access to the database, and basic connection requirements only need a
very simple configuration to get a client machine up and running. The following
list of general Oracle Net features can be used individually or in combinations to
allow Oracle to operate in the most demanding and diverse network
environments.
• Oracle Listener—Brokers connection requests from clients to the database
server. Multiple listeners allow for load balancing, connect-time failover, and
transparent application failover.
• Centralized Names Resolution—A central repository that stores the location
of all available database services. This allows clients to only require a single
address to access any service they need.
• Oracle Connection Manager—Allows for client and server with different pro-
tocols to communicate. Also provides connection concentration and
controlled access to database services based upon IP address.
• Oracle Advanced Security—Allows for single sign-on for authentication and
authorization to multiple database services as well as data encryption and
data checksumming.
• Heterogeneous Connectivity—Allows for clients to use standard Oracle SQL
and procedure calls to seamlessly access non-Oracle data sources via a trans-
parent gateway.

Additional Oracle Net features include dead connection detection and tracing and
diagnostic tools. Oracle Net’s dead connection detection feature automatically
detects abnormally terminated client sessions and handles the rollback and release
dead connection of database resources the session was using (for example, locks and latches).
detection: Oracle Net’s tracing and diagnostic tools will be covered in more detail later in
A feature of Oracle Net that the course.
automatically detects
terminated client sessions
and handles the release of
database resources.
TASK 1A-1
Describe Oracle Net Architecture
1. What are the disadvantages to running a database on a client-server
configuration?
Each client requires special software to connect to the server, each of which
would have to be configured individually. Also, older mainframe-style servers
could support only a limited number of users before performance started to
degrade significantly, and the rapid fire development and release of newer
versions of client software made it almost impossible to manage a large
number of clients.
2. In an N-tier configuration, what is the purpose of the middle tier?

The application server resides at the middle tier and contains all the pro-
gram code required to run the application. Users on client machines issue
simple commands to the application, which connects to the database on the
clients’ behalf and returns the data to the clients.
3. What is the purpose of the Oracle listener?

a. Allows clients to only require a single address to access any service
they need.
b. Allows for clients to use standard Oracle SQL and procedure calls
to seamlessly access non-Oracle data sources.
✓ c. Brokers connection requests from clients to the database server.
d. Allows for a client and server with different protocols to
communicate.

The User Connection Process
There are two connection types in Oracle9i. One way to describe them is that
they are either single-task or two-task. Single-task means that the user and server Single-task and Two-task
processes are one and the same; the user is connected directly to the database, Configurations
and the connection happens in a single task. The request is made and the connec-
tion granted. In a two-task connection, the user and server processes are separate,
usually across a network, and the user must pass a request through the network to
connect to the server. The response is returned with a simple yes or no, and then single-task connection:
the user connects to the database. If an error occurs during the connection process A connection where the
or the connection is lost, then the user must submit the request again. Figure 1-3 client user and server
shows the difference between a single-task connection and a two-task connection. process are one in the same.
single-task connection:
A connection where the
client and server processes
are separate, usually through
a network.
Figure 1-3: Single-task and two-task configurations.

A more detailed connection process is shown in Figure 1-4. In this graphic, you
can see both single-task and two-task connections. The User Connection
Process

Figure 1-4: The user connection process.
In Figure 1-4, the single-task connection is shown by the user process using the
bequeath connection. It’s called the bequeath connection because the connection
request goes directly to the dedicated server process and is handed, or
bequeath connection: bequeathed, a connection. This type of connection is made when the user con-
A single-task database nects to the database from the very same machine where the database resides.
connection where the client
and server reside on the You can also see in Figure 1-4 that a two-task connection requires some addi-
same machine. tional steps. This is because the connection request must be passed through the
network to the database server. Since it is possible, and highly probable, that
there will be both multiple clients and multiple databases residing on the same
network, every connection request must be routed from a client to the proper
Connection Request Path database in a timely fashion. Regardless of networking environment, when a cli-
ent makes a connection request through the network to a remote Oracle database,
there is a certain usual sequence of events that takes place. Figure 1-5 shows the
general flow of a connection request with an explanation of each step.

Figure 1-5: An example of a possible database connection request path.
The following steps are taken to establish a connection between a client and a
database:
1. The user initiates a connection request with a connect string containing user
name, password, and net service name.
2. The net service name is resolved to a connect descriptor that provides the
network location of the appropriate listener process.
3. The connection request is sent to the listener with the service name of the
target database.
4. The listener determines where to direct the connection request based on the
service name received and returns that network address back to the client.
5. The client connects directly to the database server at the network address
given by the listener process.
Step 1: The User Initiates a Connection Request

Whether from a custom application or from a tool such as SQL*Plus, the user
must provide a user name, password, and net service name when requesting a
session with a remote database. A net service name is simply an alias for the des-
tination database the client wishes to connect to. Following is an example connect net service name:
string from someone using a net service name: An alias for a destination
database a client wishes to
sqlplus scott/tiger@dev connect to.
In this example, someone is invoking SQL*Plus from the command line followed
directly by the connect string. The user name being provided is scott followed by
a forward slash and then the password tiger.
If the database were local to the user, this might be all that was necessary to
connect. However, when the database is remote, you need to somehow tell your
client application where it is located on the network. Hence the at symbol (@)
followed by the net service name dev. In and of itself, dev does not give enough connect descriptor:
information to specify a destination service or the means to reach this service. The full connection definition
Instead, this net service name maps to a fully qualified connect descriptor, and is for a net service name.
resolved during the connection process.

Step 2: The Net Service Name is Resolved to a Connect
Descriptor
Since the listener process that knows exactly where each database that it supports
is located, a client needs only to contact the listener to figure out where it should
go to find the target database. The connect descriptor tells the client exactly to
which listener it should send its request, and where that listener is located on the
network. Consider the following connection request:
connect scott/tiger@dev
In this example, the characters after the at symbol (@) make up the net service
name, which in this case is dev. To proceed with the connection request, the
Oracle client must be able to translate this net service name to a network address
where the listener process is located. Oracle9i provides multiple methods of
resolving connect descriptors, and the names resolution method used will be
highly dependent on the business requirements of the environment. In general,
full connect descriptors for all net service names are stored in a specific location,
such as in a file on the local client (tnsnames.ora) or in a centralized database on
the network. To resolve the net service name, the Oracle client would perform a
simple lookup to find the full connect descriptor for the specified net service
name. You will learn about specific names resolution methods later in this lesson.
Whatever method is used to resolve the connect descriptors, most methods store
the information in a similar format. The following is an example connect descrip-
tor for the dev net service name:
dev=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=dev01.company1.com)(PORT=
1521))
)
(CONNECT_DATA=
(SERVICE_NAME=devdb)
)
)
In this example, you can see that using the dev net service name resolves to a
complete connect descriptor. Although it is technically legitimate to pass the
entire connect descriptor at connect-time, typing such a large amount of text to
request a database connection is extremely cumbersome and highly error-prone.
Using the net service name eliminates these issues and simplifies the connect
string that needs to be passed when requesting a database connection.
The ADDRESS entry in the connect descriptor tells the client where on the net-
work it can find an appropriate listener process. In this case, the client would
contact the DEV01.COMPANY1.COM server at port number 1521.

Step 3: The Connection Request is Sent to the Listener
Once the connect descriptor is resolved, the client now has the address of a lis-
tener as well as the network protocol to use to reach it. The listener process,
which is constantly running, listens for client connection requests and then
handles them appropriately. It can be configured to listen for one or more
databases. Depending on your requirements, you can configure a separate listener
for each database on the network, or you can configure a single, centralized lis-
tener to listen for multiple databases.
Upon contacting the listener process at the network location specified by the
ADDRESS entry in the connect descriptor, the client would pass to the listener the Do not confuse the net
information specified by the CONNECT_DATA entry. The CONNECT_DATA tells service name with the
the listener the service name of the database the client would like to connect to service name. The net
and may also include additional connection-specific information required by the service name refers to the
client. A service name may or may not be the actual name of its database; it is connect string that a client
would use to determine
simply another alias which the listener will use to uniquely identify the database
where the appropriate
on the network. Oracle makes use of a database service name to allow multiple listener resides on the
databases on the same network with identical system identifiers (SIDs). For network. The service name
example, you could have two databases on the same network that both have SIDs refers to the target database
called DEV. Since the listener identifies each database by its service name only, and is set by the database’s
and not the SID, the listener process will be able to tell them apart as long as the SERVICE_NAMES
service names are different. initialization parameter.
Step 4: The Listener Determines Request Destination

Once the listener receives a connection request and is passed the service name system identifier:
from the connect descriptor, the listener process will perform a quick lookup in The identifying name for a
its configuration to determine the location on the network where the appropriate database.
database resides. For our example, the client passes the service name DEVDB.
The listener process looks in its configuration settings to determine the location
on the network where the DEVDB database service resides. The database may be
on the same server where the listener is running or may be on a completely dif-
ferent server.
Regardless of where the database resides, the listener process will contact the
target database to retrieve the network address of an existing server process for
that database. If no free server process exists, the listener will instruct the data-
base to spawn a new server process. Once the listener has determined the
network address of the intended server process, which is now known as a service
handler, it will pass that network address back to the client. For the standard
TCP/IP protocol, the network address of the service handler will usually include
the service name of the database and the port number assigned to the server
process.
Step 5: The Client Connects to the Database

Upon receiving the network address of the service handler, the client will com-
municate directly with the server process without further intervention from the
listener. The requested connection has been established and the server process
will interact with the database on behalf of the client. The listener process will
continue listening for other connection requests, and the entire connection process
is now complete.

TASK 1A-2
Identify the Steps in the User Connection Process
1. True or False? Connect descriptors can be specified directly on the con-
nect string instead a net service name.
True. There are several alternatives to supplying a net service name in a
connect string and specifying the connect descriptor instead is technically
legitimate.
2. Why do you think the concept of net service names was invented?
Doesn’t this just add another unnecessary layer to the already complex
process of connecting to a database?
While technically you can bypass net service names, in practice they make
life much simpler. Although some initial configuration is required, net service
names are easy to maintain and can greatly simplify the command string
that needs to be passed at connection time. Consider this connect string
which specifies a connect descriptor directly:
sqlplus scott/tiger@(description=(address=(protocol=tcp)
(host=rnd.acme.org) (port=1521)) (connect_data=(service_name=
dev.acme.org))
A connection request such as this is too cumbersome to use on a regular
basis and is extremely error prone. By storing the full definition of a connect
descriptor, either locally in the tnsnames.ora file or in a centralized naming
server, the connect descriptor can be easily maintained and resolved on
demand when a connection request is initiated.
3. What is the role of the listener in establishing a database connection

using the bequeath method?
Absolutely nothing. When a database connection is established using the
bequeath method, the client contacts the database directly, and the connec-
tion is immediately established with a simple hand-off, or bequeath, to the
server process that will support the user connection. The listener is used
only for connections that are requested through the network.
Oracle Net Layered Architecture

When a client is connected to the database, whether that client be an end user
Oracle Communications machine or an application server, all communications between the client and the
Stack database server must pass through the network stack. The network stack is a
series of layers, one on the client side and one on the server side, that handles all
messages between the client and server. As a message traverses through the layers
from the client to the server and back, each layer fulfills a certain responsibility
network stack: before passing the message to the next layer. Figure 1-6 shows the standard
A series of layers that a Oracle client communication stack. The layers that come into play for each con-
network connection between nection will depending on the type of connection and the connection protocol
a client and server must used.
pass through.

Figure 1-6: A typical Oracle communication stack.
In this figure, the client has established a connection to the database server. When
the client sends a request to database, such as a SELECT statement, the request
must travel down through each of the layers on the client side, across to the
server where the database resides, then up through the stack layers on the server
side to the RDBMS. Each layer in the stack plays a role in ensuring that the
request is sent to the database server properly, performs any character or datatype
conversions as necessary, and ensures that the request reaches the database intact
and uncompromised by malicious individuals or programs. Once the request is
received by the database, the database will perform the action requested, and then
send the results back to the client using the reverse route.
You should also see in Figure 1-6 two optional components: names resolution and
security services. Names resolution is used to resolve net service names to con-
nect descriptors, as described earlier in this lesson. The optional security services
can be configured if a secure connection between the client and the database is
required, such as when the database connection occurs across a wide-area net-
work open to the general public, rather than within a closed-circuit local area
network. These security services provide the ability to encrypt database connec-
tions and also checksum the information being passed so the database server will
know that it received the information in the exact same form as it was sent.
The Standard Oracle Communication Stack Layers

The OCI layer on the client side and the corresponding OPI layer on the database
side perform virtually the same function. The abbreviation OCI stands for Oracle
Call Interface. This is the application program interface Oracle has provided to
allow custom applications to make SQL calls to the database server directly, with- application program
out requiring name resolution. The OPI layer on the database side stands for interface:
Oracle Program Interface and performs the same function in that it provides the An interface provided by a
software vender that accepts
interface for connections on the network to access the database. The main differ- procedural calls from a
ence between the OCI and OPI layers is that the OCI layer is designed to allow custom application to the
interaction with a custom application. Oracle even provides the appropriate proce- vendor’s software.
dural routines in several different programming languages, such as C++ and Java,
to make calls directly to the OCI layer. The OPI layer, on the other hand, is
accessible only by the database and cannot be directly accessed by an application.

The OCI layer is completely optional. If an application developer wishes, he or
she can design an application to make standard Oracle Net connection requests
using net service names. However, doing so will force an additional dependency
on several other components of the Oracle client software, such as the names
resolution mechanisms. By using the OCI, the application can be designed with
as few dependencies as possible, which can provide greater flexibility if the appli-
cation needs to be transported from one machine or network to another.
The presentation layer handles translation between client and servers with differ-
ent codepages and languages, which can occur if the client and server are running
different operating systems. This layer is called the presentation layer because the
client will present its request to the network stack, and the presentation layer will
determine what conversions, if any, will be required for the request to be under-
stood by the receiving server. The specific type of presentation layer used by the
Oracle stack is called Two-Task Common (TTC), which is designed specifically
to handle character and data format conversions between a client and the Oracle
database.
The Oracle Net foundation layer is responsible for establishing and maintaining
the connection between the client application and database server, as well as
exchanging messages between them. This layer makes up the core of Oracle’s
networking functionality and is built on a technology called the Transparent Net-
work Substrate (TNS). The TNS enables direct computer-to-computer connections
regardless of the network protocol used, without requiring additional communica-
tion support from other services or devices. This layer receives client application
requests and resolves all generic computer-level connectivity issues, such as
names resolution, determining which protocol to use for the connection, and han-
dling connection interruptions between the client and database.
Once the Oracle Net foundation layer has determined the appropriate protocol to
use for the client’s request, the request is forwarded to the Oracle protocol sup-
port layer. This layer has the responsibility of mapping TNS functionality to
industry-standard network protocols. This ensures that the proprietary message
format used by Oracle and the TNS component is translated into something that
can be understood by the network and transported to the database server. Cur-
rently, the Oracle protocol support layer can interface with the following
protocols:
• TCP/IP
• TCP/IP with Secure Socket Layer (SSL)
• Named Pipes
As you will notice in Figure 1-6, the combination of the Oracle Net foundation
layer and the Oracle protocol support layer make up what is collectively known
as Oracle Net. While the OCI and Presentation – TTC layers are optional, all
connection requests must be passed through, at a minimum, the Oracle Net foun-
dation layer and Oracle protocol support layer.
The network protocol layer is actually the network itself. Once the Oracle proto-
col support layer has properly translated the request and passed it to the network
protocol layer, it is the responsibility of the components that make up the network
to send the request to the target database. Depending on how the network is con-
figured, the request may be sent directly to the target server, or it may be passed
through several hops from one network device to another, before reaching its final
destination. Once the request reaches the target server, the request is handed over
to the Oracle protocol layer on the target server to be translated back to a stan-
dard TNS request before forwarding it up the database’s communication stack.

If the Oracle client involved in the connection resides on the same machine as the
database, the network protocol layer can be bypassed by using a bequeath con-
nection to the database. However, the use of a net service name will force the use
of the network protocol layer, even if the client is on the same machine as the
database. This means that the connection will be routed through the server’s net-
working components, network card included, to reach the database.
The Java Client Communication Stack

The standard Oracle communication stack is used when the client is connecting to
the database via the TNS layer or by making calls to the OCI interface. However,
Oracle also provides database connectivity to clients that make calls to the data-
base through a JDBC driver. JDBC stands for Java Database Connectivity and is Java Database
an industry standard connectivity interface for applications that make use of Java Connectivity:
programming on the client. An industry standard
connectivity interface for
In order for an application to make calls through JDBC, the client machine must applications that make use of
have the appropriate JDBC driver installed. The JDBC driver is special software Java programming on the
client to connect to a
that accepts standard calls from the client software and passes them to the data-
database source, also known
base through the Java client communication stack. Oracle provides two types of as JDBC.
JDBC drivers, the JDBC OCI driver and the JDBC thin driver. The JDBC OCI
driver behaves much in the same way as the standard OCI interface; the only dif-
ference being that the Java client will pass connection information and database
requests from within Java routines, as opposed to some other language such as Communication Stack for
C++. When connecting to the database using the JDBC OCI driver, the Oracle JDBC OCI Connections
stack will look almost identical to the standard Oracle communication stack; the
only difference is that the client is making calls to the JDBC OCI layer instead of
the standard OCI layer. Figure 1-7 shows the Oracle communication stack for
clients using the JDBC OCI driver. Notice that the only difference between the
stack layers shown here and the layers shown in Figure 1-6 is that the client is
making use of the JDBC OCI driver instead of the standard OCI application
interface.
Figure 1-7: The Oracle communication stack for JDBC OCI connections.
The JDBC thin driver is somewhat different in that it provides database connec-
tivity to very small Java applications, such as Java applets. Using the JDBC thin Communication Stack for
driver, a Java applet can connect directly to the database through Java sockets, JDBC Thin Clients
which bypasses most of the communication stack and can greatly improve con-

nection performance. The only other network support required by the JDBC thin
driver is a lightweight Java implementation of the Presentation – TTC layer and
a Java version of the Oracle Net layers, called JavaNet. Figure 1-8 shows the
Oracle communication stack that is used for JDBC thin clients.
Figure 1-8: The Oracle communication stack for JDBC thin clients.
In this figure, you will see that the communication stack for JDBC thin clients
has fewer layers than the standard Oracle communication stack. The OCI layer is
not used, and the Presentation layer is using a Java implementation of TTC. The
Oracle Net layers have been replaced with JavaNet, which is a Java version of
the Oracle Net components. Both the names resolution and security service com-
ponents have been eliminated, which reduces the amount of network traffic
required to establish and sustain a connection to the database. You should also
see that the only networking protocols supported by the JDBC thin driver is TCP/
IP, which must be used throughout the connection between client and server.
The Web Client Communication Stack

In addition to the Two-Task Common presentation, Oracle also supports HTTP
Communication Stack for
and FTP presentations, which allows Web clients to connect directly to the data-
Web Clients base using a Web browser. For example, a client machine using only a browser
can connect directly to the Oracle database and access the XML DB features of
Oracle9i. The combination of the Web client connectivity and XML DB allow a
client machine to access and manipulate XML documents in the database. Figure
1-9 shows the communication stack for Web clients to access the database.

Figure 1-9: The Oracle communication stack for Web clients.
For this type of connection, the client has only a Web browser and the standard
TCP/IP protocol, both of which are used by most end users to access the Internet.
On the database side, the communication stack makes use of Oracle’s TCP/IP
protocol support and a presentation layer that supports both HTTP and FTP. The
Oracle9i database server itself provides the XML DB features and stores XML
documents right in the database. The only network protocol supported for Web
client connections is TCP/IP.
TASK 1A-3
Describe Oracle Net Layered Architecture
1. In a client-server application connection, in which layer of the Oracle
Net stack are naming resolution methods applied?
a. Oracle Protocol Support
✓ b. Oracle Net Foundation layer
c. Network Protocol
d. Presentation – TTC
2. What is the advantage of developing an application to use the OCI layer

instead of using standard Oracle Net connection requests through net
service names?
Using standard Oracle Net connection requests through net service names
forces an additional dependency on several other components of the Oracle
client software, such as the names resolution mechanisms. By using the OCI,
the application can be designed with as few dependencies as possible, which
can provide greater flexibility if the application needs to be transported from
one machine or network to another.

3. Which layer of the Oracle communication stack is responsible for estab-
lishing and maintaining the connection between the client application
and the database server?
a. Network protocol layer
✓ b. Oracle Net Foundation layer
c. Presentation layer
d. Protocol support layer
4. Describe the communication stack layers that are involved for connect-
ing a JDBC thin client to the database.
Using the JDBC thin driver, a Java applet can connect directly to the data-
base through Java sockets, which bypasses most of the communication stack
and can greatly improve connection performance. The only other network
support required by the JDBC thin driver is a lightweight Java implementa-
tion of the Presentation – TTC layer and a Java version of the Oracle Net
layers, called JavaNet.
Additional Networking Options

In addition to the standard Oracle Net configuration, Oracle supports a wide
range of additional options that can enhance the security and functionality of the
Oracle Net and Oracle database environments. These options provide expanded
scalability, enhanced database connection control, multi-protocol connectivity,
enhanced connection security, and support for connections between Oracle and
non-Oracle databases. Some of these options come readily available with the
basic installation of Oracle, while others must be purchased and licensed
separately.
Connection Manager
In addition to the capabilities and features of Oracle Net, Oracle has included
another networking service, Connection Manager (CMAN). CMAN is design to
support a large number of concurrent users in a 3-tier environment and can
handle more than 1,000 concurrent users. Connection Manager can be installed on
any node that has Oracle Net and more or less functions as a virtual traffic cop
for database connections. Oracle recommends that CMAN be configured on the
middle tier of a 3-tier architecture to take advantage of all the features it
provides. These features include:
• Connection Pooling
• Multi-protocol Connectivity
• Secure Network Access

Connection pooling refers to the technique of managing connections in a specific
way to provide support for a large number of users. This added functionality
works in conjunction with Oracle Shared Server (OSS) and provides increased
scalability and more efficient use of resources. As shown in Figure 1-10, to pool Connection Pooling by
connections CMAN will spawn a set number of connections to the database, and Connection Manager
each individual connection will support requests from multiple clients. As new
connection requests are sent to the database, CMAN will determine which pre-
spawned connection is the least busy and refer the client to that connection. If
CMAN determines that all pooled connections are busy, it can spawn additional connection pooling:
database connections to support the increased workload. By using this technique, The technique of pooling
multiple client connections
the Oracle database can support hundreds of client requests with only a few into a group of fewer
actual connections to the database. database connections.
Figure 1-10: Connection pooling by CMAN.

In Figure 1-10, several clients are connected to the database, but only two actual
connections to the database are necessary. This is because CMAN has pooled all
the client requests and is utilizing the absolute minimum number of connections
to support the existing workload. Each individual connection to the database can
support dozens of actual end users. The CMAN utility has the responsibility of
accepting database requests from the clients, deciding which pooled connection is
the least busy to handle the request, or to spawn a new connection if all existing
connections are too busy. CMAN also has the responsibility of ensuring that the
results of each database requests, such as the result set of a query issued by a
client, is returned to the user that placed the request.
Connection Manager also supports multi-protocol connectivity. That is, your cli-
ents can be using one type of protocol while your server uses another. The
protocol conversion takes place automatically and is completely transparent to the
user. CMAN supports the following protocols: multi-protocol
connectivity:
• APPC (LU6.2) A configuration that supports
• DECnet several different client
protocols to connect to a
• Named Pipes (Microsoft Networking) single database.
• SPX/IPX
• TCP/IP
The protocol conversion can take place in both directions between the client and
server. Connection Manager also provides logging and tracing features to assist in
troubleshooting network problems in a multi-protocol environment.

Connection Manager can provide additional security measures for network
connections. It can be used as a stand-alone utility or in conjunction with Ora-
cle’s Advanced Networking Option. CMAN can also be used for connection
auditing and as a soft firewall for incoming connections. You can configure the
service to decide whether to accept or reject connections based on the origin
and/or destination of the request, or even the database name that the connection
request is intended for. When CMAN is configured to function as a soft firewall,
only those connections that are configured as permissible will be allowed to
connect. In other words, CMAN will always err on the side of caution: unless
you specifically state that a connection from a certain client to a certain database
is allowed, that connection will be immediately refused. That which is not spe-
cifically granted is denied.
Oracle Advanced Security Option

Data security is always a high priority for most companies. The Oracle database
is a major investment, and the data it holds is usually critical to the owning com-
pany’s livelihood and success. The most vulnerable component of the system is
the network. There are three major risks involved when running an Oracle data-
base across a network (as with most databases), and each must be identified and
addressed before the system is considered safe from security breeches. These
risks include:
• Data privacy
• Data integrity
• Authentication
Ensuring data privacy involves protecting data and passwords from theft or dis-
closure to an unauthorized person or entity. User account passwords are stored in
the database in an encrypted form, but they are transmitted through the network
unencrypted during normal operations. Once a security breech occurs in the net-
work, unencrypted data and/or passwords can be easily retrieved by the intruder
and used maliciously for the intruder’s own purposes. To prevent such intrusions,
Oracle Advanced Security provides data encryption capabilities when sending
information across the network. Data encryption involves executing a series of
programs that scramble data to be transmitted using a specific key, which is usu-
ally a long string of seemingly random characters. The receiving system will
unscramble the data using the same key. Special hardware is required to imple-
ment encryption with the Oracle database. Oracle Advanced Security is
compatible with much of the hardware available in the open market and also sup-
ports four of the major encryption algorithms, which are:
• Data Encryption Standard (DES)
• Triple-DES (3DES) encryption
• RC4 from RSA Data Security, Inc (RSA RC4) privacy
• Advanced Encryption Standard (AES)
The DES encryption algorithm has been a standard of the U.S. government for
many years and has been a requirement by law for certain systems in some
industries. Triple-DES encryption is similar to DES but encrypts and decrypts
data with three passes of the algorithm. Each pass through the data can use a dif-
ferent key with a different length. 3DES supports 112- and 168-bit key lengths.
The RC4 algorithm was developed by a company called RSA Data Security, and
uses 40-, 56-, 128-, and 256-bit encryption keys. The AES algorithm is a rela-
tively new encryption standard certified by the Federal Information Processing

Standard (FIPS). This algorithm uses 128-, 192-, and 256-bit key lengths. In gen-
eral, the longer and more complicated the key used to scramble the data, the
harder it will be for an intruder to break the code. Without the proper key, an
intruder would only retrieve a meaningless stream of characters.
Ensuring data integrity involves protecting data from being modified or halted
during transmission. An intruder intercepting data transmissions between a client
and a server can divert the transmission to another location, thereby causing data
disruption. The intruder can also modify the data and place it back in the network checksum:
stream, causing data modification. To ensure data integrity, Oracle Advanced A hash value generated by
Security provides cryptographic checksumming capabilities, which can create a reading a single piece of
data.
digital signature for each packet of data sent to the database across the network.
This process involves using a hash value, called a checksum, which is recorded at
the end of each data packet. When the receiving end reads the packet, the same
hashing algorithm is used to determine if the data had changed between the time
it was sent and the time it was received. While not impossible, it is highly
unlikely that a packet of data can be changed and still have a valid checksum. In
addition to this checksumming, data packets are labeled sequentially in the order
they are sent to hinder reordering of the packets. As the packets are received, the
system checks the order of the packets to ensure the sequence has not been
altered in any way. Both checksumming and sequential labeling provide data
integrity across the network.
Authentication refers to the process of making positive identification of all cli-
ents, hosts, users, and servers prior to allowing data to be transferred across the
network. Within Oracle itself, basic security can be implemented through the use
of privileges and roles. However, any and all efforts to secure data will be in vain
if the need to identify the user is not included in security planning. To ensure
proper security in identifying users, Oracle Advanced Security supports third-
party authentication mechanisms above and beyond those already provided by the
Oracle database system. These third-party products are used to ensure that the
user, client, and server are correctly identified before allowing any data to be
transmitted. There are three main types of these mechanisms, which are:
• Network authentication services
• Token cards
• Biometric devices
Network authentication services provide a secure and centralized method of user
authentication and eliminate the need for clients and hosts to verify identities to
each other. These services also provide the convenience of only requiring one
password per user, even though each user might require access to several secure
areas of the system. The user logs in with a single password, which the service
then uses to authenticate the user based on the specific privileges granted to that
user. The entire process is completely transparent to the client, server, and
applications.
Token cards provide a one-time password method of authentication. An access
card and personal identification number (PIN) is provided to the client. The user
logs on with the card and the PIN to gain access to the system. The token cards
use single-use access codes that change every 60 seconds. Also, to allow easy
identification of card use, no two security cards can ever by encoded with the
same code number.

Biometric authentication methods require the use of special hardware that will
positively identify an individual before allowing access. Identity can be confirmed
using some biological aspect of the individual, such as a fingerprint or retina
pattern. Biometric adapters must be installed on both the client and the server to
allow authentication data to be passed between the two. While at one time this
type of security device was found only in the movies, the falling cost of such
technology is quickly becoming reachable by the general business community.
Heterogeneous Connectivity
In today’s business world, it is common for many companies to take advantage of
database software products from numerous vendors to support various data
systems. It can be greatly beneficial for the company to combine the data from all
heterogeneous of these systems and transform it into top-notch information about all aspects of
connectivity: the company’s operation. However, doing so is not such an easy task. Each sys-
A feature that allows an tem usually stores its data in a different way, accesses the data differently, and
Oracle client to use standard
Oracle SQL and procedure
has different ways to handle errors. Although SQL is an industry-standard query
calls to seamlessly access language, most database products have their own dialect of the language. Even
non-Oracle data sources. simple datatype translations and basic transaction management can be different
from one system to the next. To simplify this seemingly daunting task, Oracle
provides heterogeneous connectivity services to allow clients to use standard
Oracle SQL and procedure calls to seamlessly access non-Oracle data sources.
Oracle provides heterogeneous connectivity through the use of its Oracle Trans-
Oracle Transparent parent Gateway products. A gateway is primarily an interface between the Oracle
Gateways database and another non-Oracle relational database system. Each gateway that
Oracle offers is designed to provide connectivity to a specific database system on
a specific platform. For example, Oracle offers the Oracle Transparent Gateway
for DB2 on IBM RS/6000, which allows the Oracle database to access data on a
DB2 database that is running on an IBM RS/6000 server. For each third-party
database product you want to access, you must install the appropriate gateway.
Figure 1-11 illustrates the use of Oracle Transparent Gateways to access non-
Oracle databases.
Figure 1-11: The use of Oracle Transparent Gateways.

In this figure, the client is accessing the Oracle database using a standard Oracle
Net connection. The Oracle database is configured with four different Transparent
Gateways that allow the database to access the databases from four different
vendors. Using basic Oracle SQL and PL/SQL, the client can query and manipu-
late the data in multiple non-Oracle databases simultaneously and can even
combine the results from all five databases into a single, highly-informative
report. For some very specific situations, Oracle’s flavor of SQL may not be suit-
able to access the foreign database. To address this issue, Oracle provides a pass-
through ability, which allows the user to force a vendor-specific SQL statement to
bypass Oracle’s SQL processor and send the statement straight to the foreign
database. This allows the user to communicate with the foreign database using its
own language, if necessary. Figure 1-12 shows more detail about the architecture
of Oracle’s Heterogeneous Services.
Heterogeneous Services
Architecture
Figure 1-12: Heterogeneous Services architecture.

To access a foreign database, Oracle will send SQL statements from the database,
through the appropriate Transparent Gateway, to a Heterogeneous Services agent.
This agent is comprised of agent generic code and a driver native to the target
database. The agent generic code is used for all Oracle Heterogeneous Service
products and provides a common interface for Oracle to interact with various
non-Oracle systems. The native driver is essentially an API provided by the third-
party vendor that produced the non-Oracle database software. The driver interacts
with the foreign database using its own native language, and returns the results
back through the agent generic code to the gateway.
Accessing foreign databases from within Oracle is much like accessing data
through a database link. A connection qualifier is added to the table name in the
SQL statement. When executing the statement, Oracle uses the connection quali-
fier to determine which gateway to send the statement to. The following
statement provides an example query that accesses an Informix database through
Oracle’s Transparent Gateway.
SELECT name_last, name_first, deptno
FROM emp@infrmx01
WHERE name_last LIKE 'S%';
In this example, the user is querying the EMP table in an Informix database. The
database link, infrmx01, has been defined to access the Transparent Gateway
for Informix. When the query is issued, it is sent from the gateway to the Hetero-
geneous Service agent for that Informix database. The agent queries Informix on
behalf of the user, then returns the results to the Oracle database, which in turn
returns the results to the client.

TASK 1A-4
Identify Additional Networking Options
1. Describe multi-protocol activity. Which protocols does Connection Man-
ager support?
Multi-protocol connectivity is a feature where clients can use one type of
protocol while your server uses another. All protocol conversions are
handled by Connection Manager and is completely transparent to the user.
Connection Manager supports the following protocols:
• APPC (LU6.2)
• DECnet
• Named Pipes (Microsoft Networking)
• SPX/IPX
• TCP/IP
2. You are configuring Connection Manager to decide which connections to

accept and which to reject. Which of the following can you not configure
Connection Manager to consider in deciding on permitting connections?
✓ a. User name
b. Origin
c. Destination
d. SID
3. Describe connection concentration. How can you provide additional sta-

bility with Connection Manager?
Connection concentration refers to the technique of managing connections in
a specific way to provide support for a large number of users. In addition,
multiple connection managers can be configured to run at the same time,
allowing several thousand connections at once.
Additional stability can be provided by configuring multiple connection man-
agers to run simultaneously. If the primary connection manager server has
failed or is otherwise not available, another one will be.

4. If user account passwords are stored in an encrypted form within the
database, why must you worry about an intruder intercepting passwords
across the network?
User account passwords are stored in an encrypted form within the data-
base, but are sent across the network unencrypted when a user logs in. If an
intruder intercepts a password, he or she can use the password to log in
with another person’s credentials.
5. Provide a real-world example where data integrity is compromised by

an intruder intercepting data being transmitted across the network and
diverting it to a different location.
There are many possible situations where this could occur. An example
would be a hacker breaking into a bank’s network and rerouting another
person’s deposits to a different account in an effort to steal the money.
Topic 1B
Basic Oracle Net Server-side Configuration
Configuring the database server to accept incoming network connections consists
primarily of configuring the listener process. The listener is an Oracle program,
separate from the database server, that runs on the server or a middle tier. A lis-
tener is so-called because it “listens” for client connection requests over one or listener:
more addresses on behalf of one or more Oracle database instances. Upon receiv- A constantly running process
ing a connection request from a client, the listener will send the requesting client that listens on the network
for incoming connection
the network address of a prespawned server process where the target database requests.
resides. If there is no prespawned server process available, it will direct the data-
base to spawn a new dedicated server process for the client. The actual server
process that handles the connection request is referred to as a service handler.
Once the listener hands a client process off to either a dispatcher or server pro-
cess, the listener no longer has any part in the communications of that session
and returns to the task of listening for connection requests.
Create a Listener
Listener configuration information is stored in a file called listener.ora, which is
located in the ORACLE_HOME/network/admin directory. This file contains all
the configuration information necessary for a listener to accept connection
requests and direct clients to the proper databases. A single listener.ora file can be
used to configure multiple listeners on a single server. If this file does not exist,
the listener process can still be started, but it will use a default configuration,
which may or may not be correct for the environment. Figure 1-13 shows a
sample listener.ora file.
A Sample listener.ora File

Figure 1-13: A sample listener.ora file.
In this file, there are two main entries, LISTENER and SID_LIST_LISTENER.
The LISTENER entry provides configuration information about the listener itself.
This information tells the listener exactly where it is located and on which port it
global database name: is listening. In this case, the listener is running on the server called ELEMENTK
A database identifier to and is listening on port 1521, which is the default listener port. The SID_LIST_
uniquely identify a single LISTENER entry tells the listener which databases it is listening for. For listener
database on a network.
configuration shown here, the listener is supporting a database with a system
identifier (SID) of ORA92. The global database name (GLOBAL_DBNAME) is
an additional identifier that the listener will use to identify the database on the
network.
For the entries in the listener.ora file, the word LISTENER is actually the name
of the listener process. To support multiple listeners, you must name each listener
differently in the listener.ora file, and all listeners must be listening on different
ports. For example, to add another listener, you might add another entry called
LISTENER1, or even TEST1. You can name a listener anything you want, as
long as all the required entries for the listener exist in the listener.ora file. For a
listener called TEST1, the SID list entry would be named SID_LIST_TEST1.
After a database starts up, it will attempt to dynamically register its presence with
a listener process. It will first look in the default location for a listener with the
default name of LISTENER, at the default of port 1521. You can designate a lis-
tener for the database other than the default one by setting the database’s
LOCAL_LISTENER initialization parameter. If the database finds the listener,
and if the listener is configured to listen for that database, the database will tell
the listener its SID and service names. The service names for a database are set
by its SERVICE_NAMES parameter. The listener will match the database’s SID
with the SID values set in the listener.ora file. When a client process contacts the
listener with a connection request and passes along the service name of the data-
base it wants to connect to, the listener will use the service name to look up the
appropriate SID in its SID list, and pass its network address back to the client.

While the listener.ora file can be edited manually, Oracle recommends using the
graphical front-end tool, Net Manager. Net Manager provides a streamlined inter-
face to simplify configuration of the network environment and is less prone to
error. It aids in the creation and modification of listeners, net service names,
Oracle Names servers, and much more. While working with Net Manager, the
utility simply edits the appropriate configuration files for you and eliminates
much of the guesswork of making network changes. The Net Manager interface
is shown in Figure 1-14.
Figure 1-14: Oracle Net Manager.

On a Windows machine, each listener process requires its own dedicated Win-
dows service. A Windows service is an interface provided by the Windows
operating system to allow a process to interact with other components of the
system. When starting a new listener for the first time, this service will be auto-
matically created for the new listener. Additionally, this service is required to be
running to start the listener. If the service is stopped or disabled, any attempt to
start the listener will result in an error. The Services console can be found in dif-
ferent places depending on which version of Windows is installed. On Windows
2000 Professional, the Services console can be found in Control Panel→
Administrative Tools→Services.

TASK 1B-1
Configuring the Listener Process
Objective: To configure the listener process using the Oracle Net Man-
ager utility.
1. From the desktop, launch the Oracle Net Manager utility by choosing
Start→Programs→Oracle – OraHome92→Configuration And Migration
Tools→Net Manager.
After a moment, the Oracle Net Manager utility will appear.

2. In the left pane, click the plus sign next to the Local icon to expand the
tree.
3. Double-click the Listeners icon to show the listeners that are currently
configured on your system. You should see one listener, named LISTENER,
in the tree.

4. Click the LISTENER icon. You will see the right pane of the window
change to show the configuration information for this listener.
The value for the Host entry

reflects the actual name of
your computer system and
may be different than what is
shown here.
Notice that the Port number for this listener is 1521. You will configure a
new listener for your database, except using a different port so that the two
listeners do not conflict with each other.
5. To add a new listener, choose Edit→Create.
A dialog box will appear asking you to choose a listener name. The name

LISTENER1 should already be chosen for you. Click OK.
The dialog box will disappear, and LISTENER1 will be added to the tree in
the left pane.
6. Notice in the right pane that no configuration information has been

added for the listener. This information tells the listener process which port
number to listen on, and for which databases. You will add this information
now.

In the right pane, click the Add Address button. An Address1 tab will
appear in the right pane.
7. In the Address1 tab, change the value for Port to 1522

8. Change the drop-down list at the top of the right pane to Database
Services.
The right pane will change to show that no database services have been set
up for this listener and that Oracle8i release 8.1 databases will dynamically
register with the listener.
9. Click the Add Database button in the right pane. You will see a Data-
base1 tab appear in the right pane.
10. The information currently displayed in the Database1 tab is incorrect for
your database.

For the Global Database Name, type ora92
For the Oracle Home Directory, type D:\oracle\ora92
For the SID, type ora92
11. To save the listener configuration, choose File→Save Network

Configuration.
To close the utility, choose File→Exit.
Congratulations! You have just configured a new listener process for your

database using the Oracle Net Manager utility.
The Listener Control (lsnrctl) Utility

The Listener Control utility is a simple command line utility that is used to man-
age the listeners configured on the system. When started, the utility provides its
own prompt from which you can issue commands. The command to start the Lis-
tener Control utility from any platform is simply lsnrctl. You can also issue
commands directly via the operating system command line by using the syntax
lsnrctl command listener_name. In this syntax, command is any one
of several commands that can be issued to manage a listener process, and
listener_name is the intended listener that the command is for. If you do not
specify a listener name, it will default to the listener named LISTENER.
The following table lists the Listener Control and the purpose of each.
Listener Control
Command Purpose Commands
change_password Changes the password for the target listener. All commands that cause
changes to the listener require the password.
exit Exits from the Listener Control utility. Identical to the quit
command.
help Displays a list of available commands and short descriptions of those
commands.
quit Exits from the Listener Control utility. Identical to the exit
command.
reload Reloads the target listener using the current configuration in the
listener.ora file. Useful when changing settings and you do not wish to
stop and restart the listener.
save_config Instructs Listener Control to save all new changes back to the listener.
ora file.
services Displays a list of all current database services, instances, and service
handlers for the current listener and their status.
set Used to set a number of different configuration parameters.
show Used to show a number of different configuration parameters.
start Starts the target listener.
status Shows a status summary of the target listener.
stop Stops the target listener.
trace Enables or disables tracing for the target listener.
version Shows the release version of the target listener.
Three of the commands listed in this table, help, set, and show, have
extended command options. When used alone, the help command will display
the list of commands available for the Listener Control utility. To get specific
information about a particular command, you would type:
help command
In this syntax, command is the command you wish to know more about. Listener
Control will display a short description about the specified command.
The set command is used to set a number of different configuration parameters.
Its syntax is:
set config_param new_value

In this syntax, config_param is the configuration parameter you wish to
change, and new_value is the new value you wish to set it to. The show com-
mand syntax is similar, but only the config_param argument is used:
show config_param
The show command will display the current setting of the specified configuration
parameter.
For both the set and show commands, when used alone without a specified
configuration parameter, they will display a list of available configuration
parameters. Most parameters that can be changed with the set command can be
displayed with the show command. The following table lists the configuration
parameters that are available for the set command.
Parameter Description
current_listener Sets the name of the target listener that all subsequent commands will
be set to.
displaymode Sets the amount of output that will be displayed for the services
and status commands. Valid values include RAW, COMPAT,
NORMAL, and VERBOSE. By default, the display mode is
NORMAL.
log_directory The path where the listener log file will be written to.
log_file The name of the listener log file.
log_status Enables or disables listener logging. Valid values include ON and
OFF. By default, the log status is set to ON.
password Specifies the password for the current Listener Control session.
save_config_on_stop Instructs Listener Control to save all unsaved configuration changes for
the current listener back to the listener.ora file when the listener is
stopped using the stop command.
trc_directory Sets the directory path where listener trace files will be written to if
listener tracing is enabled.
trc_file Sets the trace file name that the listener will be writing tracing
information to if listener tracing is enabled.
trc_level Enables listener tracing at the specified trace level. Valid trace levels
include OFF, USER, ADMIN, and SUPPORT. By default, the lis-
tener trace level is OFF.
All configuration parameters that can be changed with the set command can be
displayed with the show command, with the exception of the password
parameter. This parameter is used to set the password for the current Listener
Control session only, but it does not change the password of the listener; this is
done with the change_password command. In other words, the
change_password parameter is used to change the stored password for the
target listener. When the password has been set, all administrative tasks for that
listener will require the password prior to executing the task. To supply that pass-
word, you would use the set password command, which will prompt you for
the password. This password is only validated against the actual listener password
when you attempt to perform an administrative task on the listener, such as stop-
ping it. Only then will the listener compare the value you supplied for the
set password command to the value specified for the change_password
command.

It should be noted that the listener password set by the change_password
command will only protect the listener from unauthorized access through the Lis-
tener Control utility. Since the listener is just a process that runs at the OS level,
any user with enough privileges through the OS can kill the process or stop its
corresponding Windows service. Additionally, since the listener configuration is
stored in a simple text file, it too can be compromised by any privileged user
through the OS. For example, a user with Administrator or root privileges can kill
the listener process, change its configuration in the listener.ora file, and restart it.
It is up to the DBA to coordinate system and database security efforts with the
company’s system, network, and security administrators to avoid such issues.
TASK 1B-2
Using the Listener Control (lsnrctl) Utility
Objective: To use the Listener Control utility to manage the listener
process.
1. From the desktop, choose Start→Run. The Run dialog box will appear.
In the Run text box, type cmd and press Enter. A command window will
appear.

2. At the command prompt, type lsnrctl and press Enter. This will launch the
Listener Control utility.
3. The standard Oracle installation comes with a pre-configured listener

process. However, in the previous activity, you created an additional listener
for your system. You should now determine which listener process you are
working with before proceeding. At the lsnrctl prompt, type show current_
listener and press Enter.
You will see that the name of the listener that you are currently working
with is LISTENER.
4. To see the current configuration of this listener, you will use the status
command. First, you will format the output of this command by setting the
displaymode option to compat, which will minimize the output to a
short summary. At the lsnrctl prompt, type set displaymode compat and
press Enter.
The utility will respond with the message “Service display mode is
COMPAT.”
At the prompt, type status and press Enter. The utility will display a sum-
mary of the configuration of this listener. The uptime and number of service

handlers shown in your output may differ slightly from what is shown here.
5. To switch the listener that you are currently working with to your new lis-
tener, type set current_listener listener1 and press Enter.
The utility will display the message “Current Listener is listener1.”
6. To see the current status of the new listener, type status and press Enter.
Since LISTENER1 is a brand new listener and has never been started before,
the corresponding Windows service for this listener has not yet been created.
Therefore, the lsnrctl utility will return the errors “TNS-12541: TNS:no lis-
tener,” “TNS-12560: TNS:protocol adapter error,” and “TNS-00511: No
listener.”
7. To start the LISTENER1 listener, type start and press Enter.
After a few moments, the utility will respond with a series of errors and
messages. This output shows you that the utility is attempting to find the
Windows service related to this listener, but cannot find it. Once it realizes

that the service does not exist, it automatically creates a new one, and then
starts the listener.
8. To shut down this listener, you would use the stop command. At the lsnrctl
prompt, type stop and press Enter.
The utility will display messages stating that it connected to the listener at
its network address, and that the command completed successfully.
9. Since this listener is not currently running, attempting to request its status
will return an error. At the prompt, type status and press Enter.
The utility will display several error messages, indicating that the listener
could not be reached.
10. To start the listener again, type start and press Enter.
The listener will start, and the utility will display the listener’s current status.

11. The lsnrctl utility also allows you to change the password for a listener to
provide a minimal level of security against unauthorized access. At the
prompt, type change_password and press Enter.
You will be prompted for your old password. Currently, there is no password
for this listener, press Enter.
You will then be prompted for your new password. Type ora92 and press
Enter. For security purposes, the characters you type will not be displayed
on the screen. When prompted to re-enter the new password, type ora92
and press Enter again.
The utility will display the message “Password changed for listener1.”
12. Now that the listener has been given a password, any administrative com-
mands sent to the listener will generate an error if the proper password isn’t
set for the current lsnrctl session. At the prompt, type reload and press
Enter.
Since the proper password has not been set for this lsnrctl session, the utility
will display the error “TNS-01169: The listener has not recognized the
password.”
13. To provide the password for this session, type set password and press
Enter.
The lsnrctl utility will prompt you to enter the password. Type ora92 and
press Enter.
The utility will display the message “The command completed successfully.”
14. Now that the session password has been set, administrative commands will
be allowed. At the prompt, type reload and press Enter.
The utility will display the message “The command completed successfully.”
15. To exit the lsnrctl utility, type exit and press Enter. You will be returned to
the command prompt.
To exit the command window, type exit and press Enter again. The com-
mand window will close.

Configure the Listener Manually
When configuring a new listener, or changing the configuration of an existing
listener, Oracle recommends that you use the Net Manager graphical interface to
avoid human errors. However, since the Net Manager utility simply modifies net-
work configuration files automatically on your behalf, it is a simple task to
bypass the utility and make changes to the appropriate files manually. Doing so
does introduce the possibility of human error, but if done correctly, manually
making changes can be done very quickly and efficiently. When making changes
to existing configurations, it is recommended that you make a backup copy of the
original configuration file prior to making the changes. This will give you a quick
escape window if your change was not successful.
TASK 1B-3
Configuring the Listener Manually
Objective: To configure the listener process manually.
1. From the desktop, choose Start→Run. The Run dialog box will appear.
In the Run text box, type D:\oracle\ora92\network\admin and press Enter.

A window will appear for the D:\oracle\ora92\network\admin folder.

2. Double-click the listener.ora file to open it. If the Open With dialog box
appears, select Notepad from the list of applications, and then click OK.
The listener.ora file will open.
The value for the HOST

parameter may be different
than the one shown here.
3. The simplest way to manually add a listener definition to the listener.ora file
is to copy the definition of an existing listener. In the listener.ora file, high-
light the definition for LISTENER1 listener.

Choose Edit→Copy.
Move the insertion point to the blank line after the last line of the LIS-
TENER1 definition. Press Enter to add a blank line, then choose Edit→
Paste. Add another blank line after the new LISTENER1 definition you
just pasted.
In the definition you just pasted, change the name of the listener to LIS-
TENER2
Change the port number for this listener to 1523

4. You have just added the definition for a new listener, called LISTENER2.
You will now add the ora92 database to the list of databases this listener will
service.
Scroll down through the file to find the entry for SID_LIST_
LISTENER1. This entry defines which databases the LISTENER1 listener
will service. Highlight the entire SID_LIST_LISTENER1 entry. Copy the
entry and paste a new one below it using the same method as the lis-
tener definition.
Change the name of the new entry to SID_LIST_LISTENER2
5. Choose File→Exit. You will be asked if you want to save the changes.
Click Yes. The file will close.
6. Now that you have added the appropriate definitions to the listener.ora file,
you will now use the lsnrctl utility to start the listener.
From the desktop, choose Start→Run. In the Run text box, type cmd and
press Enter.
At the command prompt, type lsnrctl and press Enter. This will launch the
lsnrctl utility.
7. You must first set the current listener to listener2. At the lsnrctl prompt, type
set current_listener listener2 and press Enter. The lsnrctl utility will dis-
play the message “Current Listener is listener2.”
8. At the prompt, type start and press Enter.
Just as in the previous activity, the lsnrctl utility will first display the “Failed
to open service” error message. This indicates that the Windows service for

LISTENER2 has not yet been created. The service will automatically be cre-
ated, and the listener will start.
9. Exit from the lsnrctl utility, and then exit from the command prompt.
Close all open windows.
Topic 1C
Basic Oracle Net Client-side Configuration
To connect to a remote database, the client must specify a user name and pass-
word to the database. However, the database must first be identified and located
on the network. When submitting a connection request, the client specifies an
names resolution alias to represent the intended database, which is resolved to the location on the
method: network where a listener for that database resides. Depending on how the client is
A configured method that is configured, the client will use that alias to perform a lookup, called a names reso-
used to translate a net
service name to the network
lution method, to find the correct network location of the listener.
address where the intended When submitting a connection request, the client will determine which names
database resides.
resolution method to use by looking in its local sqlnet.ora file. This file is found
in the ORACLE_HOME/network/admin folder and contains basic configuration
information for all connections originating from the client. This file can be con-
figured through the Profile icon in the Net Manager utility, or it can be manually
configured. The NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file
provides a list of names resolution methods that the client is configured to use.
The client will first attempt to use the first method listed for this parameter. If the
attempt is unsuccessful, it will attempt to use the next method listed. If all of the
listed methods fail, the connection request fails and the client software will return
an error. Figure 1-15 shows a sample sqlnet.ora file.

Figure 1-15: A sample sqlnet.ora file.
Oracle supports several names resolution methods, each of which are designed to
support different environments and connection requirements. The names resolu- Names Resolution Methods
tion methods supported include:
• Host naming
• Local naming
• Centralized naming
• External naming
For simple connectivity requirements, Oracle provides the host naming resolution,
which is capable of resolving aliases based on the name of the server where the
database is hosted. The host name or IP address of the server is stored in a local
HOSTS file on the client machine or can be determined by a simple Domain host naming:
Names System (DNS) on the network. This method passes the responsibility of A names resolution method
names resolution to the client’s host machine and is generally used for very that uses the client’s HOSTS
file to locate the target
simple network environments with very few clients and very few databases. database on the network.
While it is extremely simple to configure, the disadvantage to host naming is that
many of the more advanced connection capabilities are not available with host
naming. For example, host name resolution is limited only to the TCP/IP proto-
col, while other names resolution methods can support multiple protocols.
Additionally, advanced security features, such as encryption and checksumming
are not available with host naming.
For local naming, which is by far the most commonly used names resolution
method, the client stores a connect descriptor for each database it might connect
to in a configuration file called tnsnames.ora, stored locally in the ORACLE_
HOME/network/admin folder. When requesting a connection to a database, the local naming:
client would look up the connect descriptor in the tnsnames.ora file to determine A names resolution method
the network location of the listener that serves the target database. Unlike host that is used to resolve net
service names by looking up
naming, local naming supports multiple protocols and can use most of the their connect descriptors in a
advanced security options. The disadvantage to local naming is that each client definition file stored locally
machine must be configured individually. For larger network environments, this on the client’s machine.
task can be particularly daunting, especially if there are dozens of databases and
hundreds of clients on the same network.

To alleviate the pain of configuring potentially hundreds of client machines,
Oracle also supports centralized naming, allowing the DBA to configure a single,
centralized repository of connect descriptors. When a client requests a connection
centralized naming: to a database, the specified alias is resolved by contacting the centralized names
A names resolution method resolution system. This system then passes the network location of the target lis-
that stores all the connect tener back to the client. While host naming and local naming can both be
descriptors in a centrally-
located repository. All clients
configured with just the Net Manager utility, centralized naming requires some
needing to resolve connect fairly involved configuration, and may be overkill for some smaller environments.
descriptors contact the However, in larger environments, where connectivity is key and there is a limited
central repository. DBA staff, centralized naming can greatly ease some of the administrative burden
of managing such a complex environment.
External naming is a method that passes the responsibility of names resolution
completely outside of the Oracle environment. With this method, third-party soft-
ware is installed, possibly in a centralized location, to store database connect
external naming: descriptors. External naming is normally used in very large environments where
A names resolution method databases of different software vendors are running, and any of several dozen or
similar to external naming, hundred clients may connect to any database provided by a different vendor. To
except the central repository
is a non-Oracle, third-party
simplify the administration of such an environment, external naming provides a
product. centralized repository for connection information for a variety of databases from
different software vendors. This type of system is generally very expensive to set
up and maintain and is usually only found in the most complex of environments.
TASK 1C-1
Identify Names Resolution Methods
1. Which names resolution method would be best in an environment where
there are several dozen individual Oracle client systems and each client
needs the ability to connect to multiple Oracle databases on the net-
work? Explain your answer.
A centralized naming method would be best for this type of environment. All
connection definitions could easily be stored in a central repository where
connection information can be quickly looked up on demand. This greatly
reduces the maintenance overhead of configuring each client separately,
especially in an environment that is constantly changing, such as when cli-
ents and servers are constantly added, removed, or relocated within the
enterprise.

2. Which names resolution methods can be configured using the Oracle Net
Manager utility? Choose all that apply.
✓ a. Host naming
✓ b. Local naming
c. Centralized naming
d. External naming
3. To configure host naming, which component of a networking environ-

ment has the responsibility of resolving a connect descriptor?
a. The remote host where the application resides.
✓ b. The local host where the client resides.
c. The local host where the database resides.
d. The remote host where the Names server resides.
Configure Host Naming

Host naming is the easiest resolution method to configure, and it provides simple
database connectivity for simple environments. When using the host naming
method, the location of the listener is determined by using the host name of the
server where it resides. The host name or IP address of the server is stored in a DNS:
local HOSTS file on the client machine, or it can be determined by a simple (Domain Names System) A
Domain Names System (DNS) on the network. server that is used to resolve
matching host names to their
For Windows systems, the HOSTS file is stored in the C:\winnt\system32\drivers\ respective IP addresses.
etc or C:\windows\system32\drivers\etc folder, while on Unix systems, it is found
in the /etc directory. To configure host naming, the host name and/or IP address
of the target server is stored along with the alias for the target database. For host
naming, the alias used must be the same as what is specified by the SERVICE_
NAMES initialization parameter of the target database. You would also add the
value HOSTNAME as the first option listed for the NAMES.DIRECTORY_PATH
parameter in the client’s sqlnet.ora file.
When connecting to a database using host naming, the client first looks in its
local sqlnet.ora file to determine which names resolution option to use. Upon
finding that the HOSTNAME value is the first listed, it will look in the HOSTS
file to find the host name or IP address of the target server where the listener
resides. The client would then contact that listener and pass along the specified
alias. The listener would resolve that alias to the location on the network where
the database resides, and pass that information back to the client. The client
would then contact that server directly to connect to the database.

The TNSPING Utility
For testing Oracle Net connections, Oracle provides the tnsping utility. This util-
ity is similar to the standard ping utility, which sends out a small data packet
across the network to a specified server and times how long it takes for the target
tnsping utility: server to respond. The tnsping utility performs the same action with a database
A utility that is used to time alias. It is a command line utility that accepts a database alias, resolves the alias
the round trip of a network using the names resolution methods configured for the client, and attempts to
packet from the client to the
listener and back.
contact the listener at the resolved location. Like the ping utility, it too times how
long it takes for the target to respond.
This utility can be very handy for multiple purposes. It can be used to determine
if your current client configuration is correct. If the configuration is correct, the
ping will succeed. If it is not correct, however, the ping will fail, usually with an
error that can indicate where your configuration is incorrect. The utility can also
be used to help troubleshoot slow network connections. If a user is complaining
that it takes too long to connect to a specific database, you can use the tnsping
utility from the user’s client machine as part of your troubleshooting process. If
the utility is showing abnormally long response times between the client machine
and the listener, it is a good indication of where the problem resides. Figure 1-16
shows a sample output from the tnsping utility.
Figure 1-16: The tnsping utility.

In this figure, the tnsping utility resolved the ora92 alias using host naming. It
then contacted the listener at the host server specified by the client’s HOSTS file,
then returned the total amount of time for the entire process to complete. For this
case, the entire process completed in 220 milliseconds. Notice in the output that
the SID parameter is set to only an asterisk (*), but the HOST parameter is set to
ora92. This is because the Oracle client is not really aiming at a specific data-
base on the host server. Rather, it believes that ora92 is the host server, and is
attempting to connect to any database it might find there. If multiple databases
reside on the target server, the listener will direct the client to connect to the first
database listed in the listener.ora file’s SID_LIST_<LISTENER_NAME> param-
eter for that target server.

TASK 1C-2
Configuring Host Naming
Objective: To configure the Oracle client to use host naming.
1. From the desktop, open the command prompt.
2. At the command prompt, type tnsping ora92 and press Enter.
The output shows the method that was used to resolve the ora92 connect
string. The message “Used TNSNAMES adapter to resolve the alias” indi-
cates that the Oracle Net client used local naming by looking up the ora92
entry in the tnsnames.ora file. You will change the names resolution method
to use HOSTNAME instead of TNSNAMES.
3. Leaving the command open, launch the Oracle Net Manager by choosing
Start→Programs→Oracle – OraHome92→Configuration and Migration
Tools→Net Manager.

After a moment, the Oracle Net Manager utility will appear.
4. In the left pane, to expand the tree, click the plus sign next to the Local
icon. In the tree, click the Profile icon.
The right pane will change to show the names resolution methods configured
for your Oracle Net client. The current settings reflect the parameters that
are currently set in your sqlnet.ora file.

5. In the Selected Methods list box in the right pane, select the HOSTNAME
entry. Click the Promote button twice to move HOSTNAME to the top
of the list.
6. Choose File→Save Network Configuration to save your changes.
7. Choose File→Exit to close the Oracle Net Manager.
8. You will now modify your system’s hosts file to include the ora92 connect
string.
From the desktop, choose Start→Run. In the Run text box, type C:\winnt\
system32\drivers\etc and click OK.
A window for the C:\winnt\system32\drivers\etc folder will appear. Your Windows directory may
be named either winnt or
windows, depending on how
your system was configured.

9. Double-click the hosts file. If the Open With dialog box appears, select
Notepad from the list of applications, and click OK. The hosts file will
open.
10. Move the insertion point to the end of the word localhost. Press Tab,
and then type ora92 and press Enter.
11. Choose File→Exit. You will be asked if want to save the changes. Click
Yes. The hosts file will close.
Close the C:\winnt\system32\drivers\etc window.

12. In the command window, type tnsping ora92 and press Enter.
The output will now show that the HOSTNAME adapter was used to resolve
the alias. You have successfully configured your client to use the host names
resolution method.
13. Exit the command window.
Configure Local Naming

Configuring local naming is slightly more involved than host naming, but pro-
vides much more flexibility and many more options. When local naming is used,
the client requests a connection to a specific database by specifying a user name,
password, and a net service name. The client determines the location of the
appropriate listener by translating the net service name to a complete connect
descriptor stored in the client’s tnsnames.ora file, which is located in the
ORACLE_HOME/network/admin folder. Once the connect descriptor is resolved,
the client can then contact the listener. The advantage over host naming is that
the net service name for a particular database can be anything you want; you are
not limited to what is specified by the SERVICE_NAMES parameter of the target
database. As a matter of fact, you can have several different net services names
that point to the same database if you wish. Local naming also supports the use
of many of the advanced security features of Oracle, such as encryption and
checksumming.
To configure local naming, you would add the value TNSNAMES as the first
entry in the NAMES.DIRECTORY_PATH parameter in the client’s sqlnet.ora file. A Connect Descriptor
You would then add any connect descriptor you want in the client’s tnsnames.ora
file. Each time the client issues a connection request, the client will first look in
the tnsnames.ora file to resolve the connect descriptor. Figure 1-17 shows a
sample tnsnames.ora file.

Figure 1-17: A sample tnsnames.ora file.
In this figure, you will see that the first entry in the file is a connect descriptor
for the ORA92 net service name. To use this net service name, the client would
issue a connect request such as the one shown here:
connect scott/tiger@ora92
When such a request is issued, the client will first look in its sqlnet.ora file to
determine how to resolve the net service name. The NAMES.DIRECTORY_
PATH parameter would specify TNSNAMES as its first option. The client would
then look in its tnsnames.ora file to find the connect descriptor for ORA92. In the
connect descriptor, the HOST and PORT parameters specify the name of the
server and port number, respectively, where the target listener is located. Upon
contacting the listener, the client will pass the value specified by the SERVICE_
NAME parameter, which is ORA92 in this case. The listener would look in its
configuration to find the network location of a database that uses ORA92 as a
service name and pass that network location back to the client. The client would
then connect directly to that database. If the tnsnames.ora file contains multiple
definitions for the same net service name, the first one listed in the file will be
used for names resolution.
As with host naming, local naming can easily be configured using the Net Man-
ager utility. The Profile page is used to specify TNSNAMES for the NAMES.
DIRECTORY_PATH parameter in the sqlnet.ora file, and the Service Naming
section is used to add or change net service names to the tnsnames.ora file. The
Net Manager utility also provides a Net Service Name Wizard to automate and
simplify the process of adding net service names. Of course, the sqlnet.ora and
tnsnames.ora files can be configured manually, if you like. Figure 1-18 shows the
Service Naming section of the Net Manager utility.

Figure 1-18: Local naming configuration using Net Manager.
TASK 1C-3
Configuring Local Naming
Objective: To configure the Oracle client to use local naming.
1. From the desktop, launch the Net Manager utility.
2. You will first configure your client to use local naming as the first names
resolution method.
Click the plus sign next to the Local icon to expand the tree.
Click the Profile icon to display the list of naming methods currently
configured for your client.

3. In the Selected Methods list box in the right pane, select TNSNAMES.
Click the Promote button to move TNSNAMES to the top of the list.
4. You will now add a new net service name for your client.
Double-click the Service Naming icon to display a list of net service

names currently configured for your client.
5. On the toolbar at the far left of the Oracle Net manager window, click the
large plus sign.

The Net Service Name Wizard will appear.
6. In the Net Service Name text box, type localdb and click Next.

7. On the Protocol page, if necessary, select TCP/IP (Internet Protocol) and
click Next.
8. On the Protocol Settings page, you are prompted for the Host Name of the
server where the target database is located. Since the database resides on the
same machine as your client, in the Host Name text box, type localhost
Leave the Port Number to its default of 1521 and click Next.

9. On the Service page, there are two options for the database version,
(Oracle8i or later) Service Name, and (Oracle8 or Previous) SID. The Ser-
vice Name option is already selected for you. In the Service Name text box,
type ora92 and click Next.
10. The Oracle Net Manager utility now has all the information it needs to cre-
ate the new net service name. On the Test page, you can test your new
connection to confirm that your settings were correct. To test your new net
service name, click the Test button.
The Connection Test window will appear showing that the test has started.
After a few moments, the window will show a message that states the con-
nection test was successful.
11. When you are finished looking at the results of the test, click Close to close
the Connection Test window.

In the Net Service Name Wizard window, click Finish to return to the
Oracle Net Manager.
You will see that the localdb net service name has been added to your cli-
ent’s configuration.
Choose File→Exit to close the Oracle Net Manager.
13. You will now use your new localdb net service name to connect to the
database.
From the desktop, choose Start→Programs→Oracle – OraHome92→

Application Development→SQL Plus to launch the SQL*Plus utility.
14. In the Log On dialog box, type system for User Name, ora92 for Pass-
word, and localdb for Host String. Click OK.
After a moment, you will be connected to the ora92 database as the system
user. You have successfully configured your client to locate and connect to

the database using the local names resolution method.
15. At the SQL*Plus prompt, type exit and press Enter to close SQL*Plus.
Troubleshooting Connection Issues

Troubleshooting network problems can sometimes be a daunting and frustrating
ordeal. However, the task of isolating problems and eliminating them can be
greatly simplified by using a checklist. Depending on the problem itself, you
would generally start from the most global possibility to the most local, eliminat-
ing possibilities as you go. Troubleshooting is not so much finding what’s wrong,
as it is eliminating what’s not wrong. Whatever is left is usually the problem.
The situation most commonly experienced with network problems is not being
able to connect with whatever it is you want to connect to, whether it may be
from your client to the database using simple host naming or centralized or exter-
nal naming and Advanced Security Option. However, these situations are often
the symptoms or the consequences of another, root problem. It is the job of the
DBA to track down that problem and resolve it.
Developing a checklist for troubleshooting can greatly reduce the time it takes in
isolating and resolving problems. You can quickly move through the checklist,
ruling out possibilities, to arrive at the core of the problem. You can then take
corrective action to get the connection working as soon as possible. The follow-
ing table provides an example troubleshooting checklist. The checklist you
develop may be more or less extensive and may include other steps to match
your specific requirements.
Item to Check Action

Is the database operational? Check the server to ensure the database is up and running.
Is the problem widespread or related to Verify connectivity from other clients that log in to the same
one workstation or program? server or using the same program. Check with the network
administrators for overall network problems.

Item to Check Action
Can you make a connection from the Verify connectivity using PING and TNSPING. Test
client to the server? connectivity from the client to the database by attempting to
log in.
Are the network protocols and Oracle Ensure all required files exist and are configured correctly.
network protocol adapters installed on
both the client and server?
Is the listener operational and listening Use the lsnrctl utility to check the status of the target
for the target database? listener.
In many cases, connectivity issues are the result of something so blatantly obvi-
ous that it becomes easy to miss. For example, if the database is not up and
running, then no client will be able to connect. However, if only a single user
actually uses that database, that person will probably be the only one complaining
about connection problems. It is almost too easy to jump to conclusions that it is
the client configuration that is incorrect, when it is really the database that has the
problem.
Once you have established that it truly is a single client that is having connection
problems, you can begin to drill down to determine exactly what that client’s Common Errors From
problem is. This is where the tnsping utility becomes extremely useful. All Oracle tnsping
client installations have this utility, and can be used to test connections from the
client to the target listener. Any errors returned from the tnsping utility will usu-
ally lead you straight to the root of the problem. The following table lists three of
the most common errors that tnsping may return.
Error Description
TNS-03505: Failed to resolve name The service name did not match a valid name listed
in the tnsnames.ora file. Typically this results from
an incorrectly entered service name at the
application level.
TNS-12541: No listener Indicates the listener has not been started (or has
failed) on the server. This can also happen if the
actual port the listener is listening on is different
from that listed in the tnsnames.ora file.
TNS-12154: TNS: Could not resolve service Indicates name resolution was not possible. Usually
name results when the tnsnames.ora file is unavailable or
empty. This error is different than TNS-03505 where
resolution was possible but was not successful.
If the steps in your checklist do not lead you to the root of the problem, you can
enable logging and tracing for network connections using Oracle Net.

Oracle Net Logging and Tracing
Oracle log and trace files are used to obtain information on the interaction
between the various network components. The trace files can then be analyzed to
determine the cause of the problems you are having. Logging and tracing provide
Oracle Net logging: a useful means of generating detailed information for every aspect of the connec-
A feature that, when enabled, tion processes. In addition, if the problem cannot be resolved using traditional
allows Oracle to log all means, you can forward the log and trace files to Oracle Support for assistance.
informational entries to a
specified log file for Since logging and tracing can generate huge files in a very short time, Oracle
troubleshooting purposes. recommends that you begin your troubleshooting on the client side only. If you
cannot isolate the problem there, move to the middle tier and try it there. If the
problem is still not resolved, then you should move to the server and enable log-
ging and/or tracing database wide.
Oracle Net tracing:
A feature that, when enabled, When logging is enabled, anytime Oracle Net encounters errors, the error mes-
allows Oracle to write out to sages are written to a log file. The error entries include the number and
a trace file every internal description of the errors in the form of an error stack. The error stack contains a
step taken to establish a
database connection, usually
list of errors that begin at the most general error and drill down to the specific
generates much more error that occurred. The log also contains the date and time the errors were writ-
detailed output than standard ten to the file. By examining the log file, you can determine which errors
logging. occurred and why. The following list is a sample error stack from an Oracle Net
log file:
TNS-12206: TNS: received a TNS error during navigation
TNS-12545: Connect failed because target host or object does not
exist
In this error stack, the error TNS-12206 tells you that a client unsuccessfully
attempted to connect to the host. The error TNS-12545 tells you why it was
unsuccessful.
Log files tend to grow quite large if logging is left enabled for extended periods
of time. You should periodically purge old information in the log files or move
the files to another location for record keeping purposes. Newer entries are
appended to the end of the log file. When you are investigating connection prob-
lems, you would start at the bottom of the file and work your way backwards
until you pinpoint the exact origin of the errors.
The server creates two types of log files. One type is for incoming connections,
the other for the listener process. If no sqlnet.ora file exists on the server, logging
will be disabled. However, the default configuration for the listener is to have
logging enabled.
To enable logging on the server for incoming connections using Net Manager,
you would only need to provide the directory in which to store the log file. This
will assign the directory to the LOG_DIRECTORY_SERVER parameter in the
sqlnet.ora file. The file name of the log will default to sqlnet.log.
To enable logging for the listener process using Net Manager, you would provide
both the directory and file name of the log file. This will automatically configure
required parameters in the listener.ora file. These parameters are:
• LOGGING_listener_name
• LOG_DIRECTORY_listener_name
• LOG_FILE_listener_name

The LOGGING_listener_name parameter is set with the values of ON or OFF,
and enables or disables logging for the listener. The LOG_DIRECTORY_listener_
name and LOG_FILE_listener_name parameters provide the directory and file
name of the log file, respectively. The parameters include the listener name to
allow you to configure logging when you have multiple listeners. By default, lis-
tener logging is enabled, and the log file is stored in the ORACLE_HOME/
network/log folder and is named listener.log. The log file for the listener contains
information about each client connection request and most of the LSNRCTL com-
mands issued to the listener. It will also include date and time information when
the listener was started and stopped.
The client will only generate log files that contain information on connections
requested from that client. These files will contain date and time information for
each connection request and any errors encountered during the connection
process. Client-side logging can also be configured using Net Manager, which
will use the information provided to assign values to the LOG_FILE_CLIENT
and LOG_DIRECTORY_CLIENT parameters in the sqlnet.ora file on the client.
These parameters specify the file name of the log and the directory to store it in.
Trace files include detailed information for analyzing connectivity problems with
Oracle Net. These files include information on the protocol stack and the routines
used within each of the layers to make the connection. Not all layers of the stack
are used for all connections. Therefore, you will not find entries in the trace file
for every layer every time a connection is processed. Each layer may call routines
in one or more of the other layers during the connection process.
Tracing is disabled by default. Since intensive tracing can impact performance, it
is recommended that you enable tracing only when necessary to troubleshoot con-
nection problems that are not resolved through logging. In addition, tracing can
result in very large trace files and will require additional storage space on disk,
more so than logging. You can control the depth of the details generated in the
trace files by providing a trace level. The common levels for tracing are USER,
ADMIN, and SUPPORT. USER level tracing will produce the least detailed infor-
mation, while SUPPORT will provide most detailed. The tracing level most
commonly used by DBAs is ADMIN. The SUPPORT level tracing is usually used
when you need to generate very in-depth, detailed trace files to forward to Oracle
Support when a network problem cannot be resolved by the DBA.
As with logging, tracing can also be configured with the Net Manager utility. For
both the client and the server, you can specify the levels, directories, and file
names of the trace files to be generated. This will automatically configure the
necessary parameters in the sqlnet.ora files. The parameters that will be set for
the client are:
• TRACE_LEVEL_CLIENT
• TRACE_DIRECTORY_CLIENT
• TRACE_FILE_CLIENT
• TRACE_UNIQUE_CLIENT
The TRACE_LEVEL_CLIENT parameter specifies the tracing level, and defaults
to OFF. The TRACE_DIRECTORY_CLIENT parameter specifies the directory to
store the trace files in and defaults to ORACLE_HOME\network\trace. The name
of the log file is determined by the TRACE_FILE_CLIENT parameter, and
defaults to sqlnet.trc. The TRACE_UNIQUE_CLIENT parameter, when set to ON
will ensure that each subsequently generated trace file will have a unique name
from all other trace files in the destination directory. This is done by appending
the process ID (PID) to the end of each file name.

The sqlnet.ora file on the server has identical parameters to handle tracing, with
the exception that each parameter ends with _SERVER. The parameters are:
• TRACE_LEVEL_SERVER
• TRACE_DIRECTORY_SERVER
• TRACE_FILE_SERVER
• TRACE_UNIQUE_SERVER
In addition to the standard connection tracing, you can also use Net Manager to
generate trace files for listener activity on the server. The utility will automati-
cally set the required parameters in the listener.ora file, which function in the
same manner as the incoming connection trace parameters. The tracing param-
eters to set for each listener process are:
• TRACE_DIRECTORY_listener_name
• TRACE_FILE_listener_name
• TRACE_LEVEL_listener_name
TASK 1C-4
Configuring Client and Server Tracing
Objective: To configure tracing for both the client and database server.
1. From the desktop, launch the Oracle Net Manager.
2. Click the plus sign next to the Local icon to expand the tree.
In the tree, click the Profile icon. The right pane will change to show the
current naming methods for your Oracle client.
3. In the right pane, click the drop-down list and select General.

The right pane will change to show additional configuration options for the
client.
4. The Tracing tab is used to enable tracing for both the database server and
the client by automatically adding the pertinent parameters to the sqlnet.ora
file.
If your Oracle client resided on a separate computer from the database

server, then server-side tracing would be configured only on the database
server machine and client side tracing only on the client machine. Since your
database and server both reside on the same machine, you can configure
tracing for both using the same sqlnet.ora file.
In the Client Information section, click the Trace Level drop-down list,
and select Admin.
In the Trace Directory text box, type D:\oracle\ora92\network\trace
In the Trace File text box, type client_trace
The Unique Trace File Name feature instructs the Oracle client to add the
process ID of each database connection to its trace file. This will ensure that
the trace file names will be unique, and will not be overwritten by subse-

quent connections. Check the Unique Trace File Name check box.
In the Server Information section, click the Trace Level drop-down list
and select Admin.
In the Trace Directory text box, type D:\oracle\ora92\network\trace
In the Trace File text box, type server_trace
Choose File→Exit to close the Oracle Net Manager.

6. To see the affects of the tracing, you will now connect to your database. The
entire connection process will generate output to your specified trace files at
the Admin level of detail.
From the desktop, choose Start→Programs→Oracle – OraHome92→

Application Development→SQL Plus.
In the Log On dialog box, type system for User Name, ora92 for Pass-
word, and ora92 for Host String. Click OK.
After a moment, SQL*Plus will connect to your database. Since all you need
is a single connection to generate some basic client and server tracing, you
can simply close the connection. At the SQL*Plus prompt, type exit and
press Enter.
7. From the desktop, choose Start→Run. In the Run text box, type D:\oracle\
ora92\network\trace and click OK.
A window for the D:\oracle\ora92\network\trace folder will appear. You will

see two or three files that end with the filename extension .trc. These are the
trace files that were generated from your SQL*Plus session.
Note: The process ID numbers used in the trace file names on your system
will most likely be different than what is shown here. A trace file that includes
“_1” before the .trc extension is a continuation of the first trace file of the
same name. For example, the contents of the client_trace_508_1.trc file is a
continuation of the contents in the client_trace_508.trc file.
8. Double-click the first client_trace*.trc file. If the Open With dialog box
appears, select Notepad from the list of applications and click OK. The
file will open in a Notepad window.
Take a moment to look through the trace file. Keep in mind that the con-
tent of this file shows what is happening within the Oracle client while
trying to contact the database server and establish a connection.

When you are done looking at the trace file, close the Notepad window.
9. Double-click the server_trace*.trc file. The file will open in a Notepad

window.
Take a moment to look through the trace file. Keep in mind that the con-
tent of this file shows what is happening within the Oracle database server
while trying to establish a connection for an incoming connection request.
When you are done looking at the trace file, close the Notepad window.
Close the D:\oracle\ora92\network\trace folder window.
10. The final file to check is the log file generated by the listener process. This
file is found in the D:\oracle\ora92\network\log folder.
From the desktop, choose Start→Run. In the Run text box, type

D:\oracle\ora92\network\log and click OK to open a window for this
folder.
11. Your system currently has three listener processes configured, therefore you
have three listener log files. As defined in the tnsnames.ora file, the ora92
net service name contacts the default listener, named simply LISTENER, at
port 1521.
Double-click the listener.log file to open it. If the Open With dialog box
appears, select Notepad from the list of applications and click OK. The
file will open in a Notepad window.
The listener process will log all incoming connection requests, including
those that are not honored due to privilege settings or misconfigurations.
Take a moment to browse through this file. See if you can find the exact
moment in time your last connection request contacted the listener.

When you are done looking through the log file, close the Notepad window.
12. Close the D:\oracle\ora92\network\log folder window.
Topic 1D
Oracle Shared Server
The two types of configurations to handle users’ requests for data include single-
task and two-task configurations. In a single-task configuration, the user and
server processes are actually a single, combined process. The one process
A Dedicated Server executes both the application code and the Oracle code, when processing a
Configuration request. Very few systems are capable of handling a single-task configuration.
Two-task is the most commonly found configuration among Oracle setups. The
user process and server process are separate. The user process handles the appli-
cation code, while the server process handles the interaction with the database on
shared server process: behalf of the user process. The server process can be either a dedicated or a
A single server process that shared process. It is considered dedicated because it will serve only a single user
can support database
requests from multiple
process at a time. A shared server process can handle multiple user connections
clients simultaneously. simultaneously. A client/server environment is a common example of a two-task
configuration. The client handles the application or user process, while the server
handles the Oracle code to manipulate data in the database. Figure 1-19 illustrates
a client-server environment with a dedicated server configuration.

Figure 1-19: A dedicated server configuration.
A shared server configuration is a variation of the two-task configuration. Figure
1-20 illustrates the shared server concept, in which Oracle can handle multiple An Oracle Shared Server
connections for multiple clients. In a dedicated server environment, the server Configuration
process must idly wait for data requests from the user process for as long as the
user process is logged in. This can become a waste of resources if the user pro-
cess remains idle for long periods of time. In a shared server environment, you
can save in resource consumption by having several users connect to a single
server process. There are fewer processes that must exist to support the workload,
and those that do exist never remain idle for long.
Figure 1-20: An Oracle shared server configuration.

It is important to note that while a shared server handles multiple connections to
the database, a user process can still request a dedicated server, which is also
shown in Figure 1-20. Some processes require a dedicated server, such as con-
necting to start and stop the database or any other administrative action that
requires the SYSDBA or OSDBA roles. In addition, some user processes, such as
large batch jobs, run much more efficiently with a dedicated server because there
is very little idle time involved with that specific type of workload.
The Connection Process in Oracle Shared Server

Oracle Shared Server requires the use of a listener, of course. In a standard con-
figuration, the listener waits for user processes to make a request, and then passes
the address of the server process back to the user process. The main difference in
dispatcher: OSS is that the listener does not direct the user process straight to the server; all
A background process in a requests from user processes are handled by dispatchers. Upon receiving a con-
shared server configuration nection request, the listener performs a direct hand-off of the connection to a
that accepts database
requests from user processes
dispatcher process. The user and dispatcher processes are then connected, and the
and passes them to shared user will submit all database requests directly to the dispatcher. The dispatcher
server processes. places the request from the user in a request queue in the SGA. The shared server
processes monitor the request queue and pick up any incoming requests. An
available server process will execute the command and place the results into the
dispatcher’s response queue. The dispatcher will then pick up the results and
return them back to the requesting user. Figure 1-21 illustrates how these compo-
nents work together.
Oracle Shared Server

Connection Process
Figure 1-21: The connection process in Oracle Shared Server.

A request for data in a shared server configuration follows this sequence of
events:
1. A user process places a request for a connection to the listener.
2. The listener performs a direct hand-off of the connection to a dispatcher
process.
3. The user process issues a SQL command to the dispatcher process.
4. The dispatcher process places the SQL command in the request queue.
5. The SQL command is picked up by the first available shared server process,
which executes the statement in the database.
6. The shared server process places the results of the SQL command in the
response queue of the requesting dispatcher.
7. The dispatcher picks up the results of the SQL command from the response
queue.
8. The results are returned to the requesting user process.
One way to look at the shared server configuration is to compare it to a
restaurant. A customer (user process) walks in to the restaurant and is greeted by
a host or hostess (listener). The host or hostess leads the customer to a seat,
where he can make his request. A waitress (dispatcher) takes the customer’s
order, writes it on a ticket, and places the ticket on the chef’s ticket holder
(request queue). An available chef (server process) will cook the food in the
kitchen (database), and then place the prepared meal on the counter (response
queue). The waitress (dispatcher, again) picks up the order and delivers it back to
the customer (user process). As the customer eats the meal, the chef can continue
cooking meals for other customers.
This system is obviously much more efficient than having a dedicated chef for
each individual customer that places an order. While in real life this would be
very nice for the customer, it would be very costly for the restaurant. The restau-
rant reduces its cost by having a single chef that can cook for several customers
at once. A single waiter or waitress can pass orders back and forth between the
kitchen and the dining room as needed.
TASK 1D-1
Describing Oracle Shared Server Architecture
1. List and describe the three types of configurations to handle user’s
requests for data.
• Single-task configuration—User and server processes are a single, com-
bined process. Handles both the application code and the Oracle code.
• Two-task configuration—User and server processes are separate. User
process handles application code, while server process handles Oracle
code.
• Shared server configuration—Modified two-task configuration. Each
shared server process is capable of connecting to multiple user pro-
cesses to handle requests to the database.

2. What is the main benefit of using a shared server configuration? Why?
The main benefit of using a shared server configuration is that multiple user
processes can share a single server process, thus reducing the amount of
memory resources consumed. This will help systems that have a larger client
base to allow more users to connect and execute transactions, but still keep-
ing resource consumption low.
3. True or False? Once you have Oracle Shared Server configured on your
system, all connections to the database must use a shared server
processes. Explain your answer.
False. A user process can still request a dedicated server. Some processes
require a dedicated server, such as connecting to start and stop the data-
base, or simply connecting as SYS with the SYSDBA role.

4. How does the role of listener in a shared server configuration differ from
that of a dedicated server configuration?
In a dedicated server configuration, when a user process requests a connec-
tion to the database, the listener provides the user process with the address
of the appropriate server. In a shared server configuration, the listener pro-
vides the user process with the address of an available dispatcher for that
network.
5. Identify and describe the numbered steps in the following picture.

The user process issues a SQL command to the dispatcher process. 3
The shared server process places the results of the SQL command in the
response queue of the requesting dispatcher. 6
The listener performs a direct hand-off of the connection to a dispatcher
process. 2
The dispatcher process places the SQL command in the response queue. 4
The results are returned to the requesting user process. 8
The SQL command is picked up by the first available shared server process,
which executes the statement in the database. 5
A user process places a request for a connection to the listener. 1
The dispatcher picks up the results of the SQL command in the response
queue. 7

Configuring Oracle Shared Server
The majority of tasks required to configure Oracle Shared Server centers on set-
ting various initialization parameters, which take effect when the database is
started up. When shared server is configured, the contents of the SGA and the
PGA: Program Global Area (PGA) differ slightly from what you would find in a dedi-
(Program Global Area) The cated server environment. The PGA is the memory area at the operating system
memory area at the OS level level on the server that stores a user’s session data while the user is logged in. In
on the server that stores a
user’s session data while the
the dedicated server configuration, the PGA consists of:
user is connected to the • Stack space to store information on local variables used by the process or
database. runtime area.
• User session data, to include resource usage and security information such as
a user’s privileges.
• Information on the state of the cursors that contain runtime memory values
for the SQL commands.
In Oracle Shared Server, only the stack space is found within the PGA. The other
information required for a user’s session, the session data and cursor-state infor-
mation, is found in an area of the SGA known as the User Global Area (UGA).
UGA: Each user will have a private User Global Area within the SGA. Because of this
(User Global Area) The extra information stored in the SGA, it is recommended that you increase the size
memory area at the OS level of the SGA to accommodate for the additional processing space required to house
on the server that exists only
in a shared server
the UGAs.
configuration. You would set the following initialization parameters to configure Oracle Shared
Server:
• LOCAL_LISTENER
OSS Configuration • DISPATCHERS
Parameters
• MAX_DISPATCHERS
• SHARED_SERVERS
• MAX_SHARED_SERVERS
LOCAL_LISTENER
The dispatcher processes must be registered with the listener process in order for
the listener to be aware that OSS has been configured for the database. The
LOCAL_LISTENER parameter specifies the service name for the listener, or mul-
tiple listeners, with which the dispatchers must register. The values given to this
parameter in the initialization file must exactly match the service name specified
in the connect descriptor as it is shown in the client’s tnsnames.ora file. For
instance, the following is an example service name shown in the tnsnames.ora
file:
O92SHARED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = elementk)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ora92oss)
)
)

To ensure that OSS will work as expected, this entry must be exactly as Oracle
will expect to find it, including all keywords and spaces. In addition, the
LOCAL_LISTENER parameter must be assigned a value that matches the
SERVICE_NAME parameter in the connect descriptor. For example, the param-
eter must be set as follows:
LOCAL_LISTENER = ora92oss
If the LOCAL_LISTENER parameter is not listed in the parameter file, or is ini-
tialized incorrectly, Oracle will resort to defaults in an attempt to configure the
listener for OSS. First, Oracle will look on port 1521 for any default TCP/IP
listener. If Oracle still cannot find a proper listener, the LOCAL_LISTENER
parameter will default to match the ORACLE_SID parameter. It is for this reason
that you should check and double-check that both the LOCAL_LISTENER
parameter and the tnsnames.ora file are configured correctly. If there is one small
mistake in either location, OSS might not work, and the exact reason will be very
difficult to track down.
DISPATCHERS
The DISPATCHERS parameter specifies the number of dispatchers that are auto-
matically spawned when the database is started up. The default value is null,
which results in no dispatchers spawned at start up. You can also configure the
system to accept connections from multiple network protocols, and assign one or
more dispatchers to each protocol.
For each dispatcher, you can list only one of the following specifications to set
the network protocol:
• PROTOCOL—Specifies the network protocol the dispatcher will use.
• ADDRESS—Specifies the actual network address to listen on.
• DESCRIPTION—Specifies a network description in Oracle Net syntax.
The following is an example of a correct assignment of the DISPATCHERS ini-
tialization parameter:
DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=3)"
For multiple network protocols, the parameter will list each protocol separately,
assigning each one a specific number of dispatchers. The following is an example
of assigning the DISPATCHERS multiple network protocols:
The double right arrow (⇒)
DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=3) ⇒ indicates that the syntax
(PROTOCOL=IPC)(DISPATCHERS=2)" should be typed as if on a
single line. The double right
The DISPATCHERS attribute (shown in parenthesis) indicates the number of dis- arrow is not part of the
patchers to spawn at startup. If this keyword is left uninitialized, or omitted syntax.
completely, the attribute will default to 1 dispatcher to be spawned at startup. You
can also supply additional network attributes to the ADDRESS and DESCRIP-
TION attributes. This is to support the possibility of having a host with multiple
Oracle homes. The additional attributes you can set include, but are not limited
to:
• SESSIONS—The maximum number of network sessions to be supported by
each dispatcher.
• LISTENER—The network name of an address or list of addresses for a
listener.
• SERVICE—The service name for the dispatcher to register with.

When the database starts up, Oracle will spawn the number of dispatchers per
protocol as specified in the DISPATCHERS parameter. Each process will be
named with a d for “dispatcher”, a number, and the database SID. For example, if
a database with the SID ora92 has three TCP dispatchers, they would be named:
ora_d001_ora92
ora_d002_ora92
ora_d003_ora92
An important point to remember is that this parameter does not set an absolute
static number of dispatchers for the database; it only indicates the number of dis-
patchers to start with. Oracle will create addition dispatchers to handle the
connection load if it is deemed necessary. In addition, this parameter can be
dynamically modified for the current instance with the ALTER SYSTEM
command.
MAX_DISPATCHERS
This parameter specifies the overall maximum number of dispatchers that are to
be created for the database. The default value is either 5 or the value of DIS-
PATCHERS, whichever is higher. The following is an example of properly setting
this parameter:
MAX_DISPATCHERS = 3
SHARED_SERVERS
The SHARED_SERVERS parameter specifies the number of shared server pro-
cesses to spawn when the database is started. The following is an example of this
parameter in the initialization file:
SHARED_SERVERS = 3
As with the dispatcher process, these server processes will be spawned at data-
base start up, and named. The name of each process will include an s for “shared
server”, a number, and the database system identifier. If you have specified that
three shared servers for the ora92 database are to be spawned at start up, those
server processes would be named:
ora_s001_ora92
ora_s002_ora92
ora_s003_ora92
The default value for this parameter is 0, which indicates that no shared servers
will be started for the database. Also, you can modify this parameter using the
ALTER SYSTEM command for the current instance.
MAX_SHARED_SERVERS
This parameter specifies the maximum number of shared server processes that are
to be created for the database. The default for this parameter is 20, or two times
SHARED_SERVERS, whichever is higher. The following is an example of set-
ting this parameter in the initialization file:
MAX_SHARED_SERVERS = 10
This parameter cannot be changed dynamically with the ALTER SYSTEM com-
mand for the current instance. It can only be modified in the parameter file or
spfile, which requires the database to be restarted for the parameter to take effect.

TASK 1D-2
Configure Oracle Shared Server
1. Which of the following is found within the PGA in a shared server con-
figuration? Choose all that apply.
a. Cursor-state information
b. User session data
✓ c. Stack space
d. Shared SQL area
2. Where is the user session data stored in a shared server configuration?

a. Temporary tablespace
b. System Global Area (SGA)
c. Program Global Area (PGA)
✓ d. User Global Area (UGA)
3. True or False? All users must share the User Global Area within the
SGA. Explain your answer.
False. Each user will have a private User Global Area within the SGA.
4. Give an example of setting the DISPATCHERS parameter for an

instance on a network that uses TCP protocol. This instance will spawn
five dispatchers at startup.
dispatchers="(PROTOCOL=TCP)(DISPATCHERS=5)"
5. What happens if you set the value of SHARED_SERVERS to 0?

Setting the SHARED_SERVERS parameter to 0 will cause the database to
spawn 0 shared servers at instance startup, which basically disables Oracle
Shared Server.
Monitoring and Tuning Oracle Shared Server

Configuring Oracle Shared Server consists mainly of setting initialization param-
eters to enable the feature and sizing the SGA to accommodate the additional
memory requirements. When monitoring and tuning OSS, you are checking to
ensure you have set those initialization parameters to appropriate values for your
system. You may find that you have to experiment with different combinations of
settings before finding the right configuration for your system’s needs.

There are five data dictionary views used to monitor a shared server
configuration. These views are closely related to the parameters listed in the pre-
vious section. The views are:
• V$CIRCUIT
OSS Data Dictionary Views • V$DISPATCHER
• V$SHARED_SERVER
• V$SHARED_SERVER_MONITOR
• V$QUEUE
V$CIRCUIT
The V$CIRCUIT view contains information about each OSS connection. If there
is a problem with a specific process in the database, you can use this view to
gather information on the specific user.
V$DISPATCHER
You can monitor all your dispatchers with the V$DISPATCHER data dictionary
view. The most important columns in this view are the STATUS, IDLE, and
BUSY columns. The STATUS column has several possible values. The following
table lists those values and their descriptions.
Dispatcher Status Description

WAIT Idle.
SENT Currently sending a message.
RECEIVE Currently receiving a message.
CONNECT Establishing a connection.
DISCONNECT Processing a request to disconnect.
BREAK Processing a break.
OUTBOUND Establishing an outbound connection.
The IDLE and BUSY columns provide the amount of time the dispatcher spent
idle or busy. You would determine the current total busy rate for the dispatchers
of each network by taking the ratio of total time busy to the total time the dis-
patcher existed. The following formula is used to determine the busy rate for
each dispatcher:
busy / (busy + idle)
This formula simply gives you the ratio of time spent busy to the total time the
dispatcher has been up and running. The following query will access
V$DISPATCHER for the total dispatcher busy rate for each protocol configured:
SELECT network,
SUM (busy) / (SUM (busy) + SUM (idle)) * 100 rate
FROM v$dispatcher
GROUP BY network
/
The following shows a sample output from this query, which in this case indi-
cates that only a single dispatcher is configured, and it has a busy rate of just
under 35 percent.
NETWORK RATE
-------------------------------------------------- ------
(ADDRESS=(PROTOCOL=tcp)(HOST=elementk)(PORT=1030)) 34.25

If the current workload as determined by the busy rate is consistently low, you
can consider reducing the number of dispatchers you have to conserve process
memory. If the workload is consistently at 50 percent or above, you should con-
sider adding dispatchers. You can add dispatchers dynamically using the ALTER
SYSTEM command. For example, to increase the number of dispatchers from 1 to
5, for both the current instance and subsequent database restarts, you would use
the following statement:
ALTER SYSTEM
SET DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=5)" SCOPE=BOTH;
Bear in mind that the new dispatchers are only available to subsequent logins.
Users currently logged in will not be able to use the new dispatchers. Also, you
cannot dynamically change the number of dispatchers such that there will be less
dispatchers than specified by DISPATCHERS in the parameter file, or to a num-
ber higher than the MAX_DISPATCHERS parameter.
V$SHARED_SERVER
This view is used to monitor the shared server processes. As with the dispatchers,
you would monitor the shared servers by determining the current workload on the
servers. You would determine the busy rate by using the same formula used for
the dispatcher busy rate. If the total workload of the shared servers exceeds 50
percent, you should add shared servers. Shared server processes can be added by
changing the SHARED_SERVERS parameter. The following is an example of
increasing shared servers from three to five using the ALTER SYSTEM command
for the current instance and all subsequent restarts:
ALTER SYSTEM SET SHARED_SERVERS = 5 SCOPE=BOTH;
V$SHARED_SERVER_MONITOR
The V$SHARED_SERVER_MONITOR view provides information that can be
helpful in deciding the best value for the MAX_SHARED_SERVERS parameter.
The columns found in this view are listed in the following table.
COLUMN DESCRIPTION
MAXIMUM_CONNECTIONS Maximum number of connections that each dispatcher can
support (OS dependent).
MAXIMUM_SESSIONS Highest number of shared server sessions in use at one time
since the instance started.
SERVERS_STARTED Total number of additional shared servers started since instance
startup (above and beyond the specified number at instance start
up).
SERVERS_TERMINATED Total number of shared servers stopped since instance startup.
SERVERS_HIGHWATER The highest number of shared servers since database creation.
The column to watch in this view is SERVERS_HIGHWATER. You should set

the MAX_SHARED_SERVERS parameter to a value above SERVERS_
HIGHWATER to be sure your system can handle more connections than you
would ever expect.

V$QUEUE
The V$QUEUE view provides information on the request and response queues
used by the dispatcher and shared server processes. You would use this view to
determine the average wait time for a connection waiting in the response queue
for dispatcher or shared server processes. The following query will access the
V$QUEUE view and generate this information:
SELECT network,
'DISPATCHER' wait,
DECODE (SUM(totalq),0,'NO RESPONSES',SUM(wait)
/SUM(totalq)) responses
FROM v$queue,
v$dispatcher
WHERE v$queue.TYPE = 'DISPATCHER'
AND v$queue.paddr = v$dispatcher.paddr
GROUP BY network
UNION
SELECT ' ' network,
'SERVERS' wait,
DECODE (totalq,0,'NO RESPONSES',wait/totalq) responses
FROM v$queue
WHERE TYPE = 'COMMON'
ORDER BY 1 desc
/
The following shows a sample output from this query:
Network Waiting For: Responses
---------------------------- ------------ ----------------
(ADDRESS=(PROTOCOL=tcp) DISPATCHER NO RESPONSES
(HOST=elementk)(PORT=1030))
SERVERS NO RESPONSES
This output shows that there are few or no sessions that are currently using
shared server connections, and therefore, there are no waits. If you find that con-
nections are forced to excessively wait in the request or response queues for
dispatchers or shared servers, you should increase the numbers of these processes
accordingly.
TASK 1D-3
Describe Methods to Monitor and Tune Oracle Shared
Server
1. How would you determine whether or not more dispatchers need to be
added to your configuration?
You would determine whether or not you need to add dispatchers by deter-
mining the overall busy rate of the dispatcher processes. You would use the
following formula with values from the IDLE and BUSY columns of the
V$DISPATCHER view:
busy / (busy + idle)
If the results of this formula show that the dispatchers are busy 50 percent
of the time or more, you should add dispatchers.

2. In the parameter file, the DISPATCHERS parameter is set to 5, and the
MAX_DISPATCHERS parameter is set to 20. What value can you
dynamically set the DISPATCHERS parameter using the ALTER
SYSTEM command?
The DISPATCHERS parameter cannot be dynamically set to a value less
than its original value at instance startup or greater than the MAX_
DISPATCHERS parameter. Therefore, using the ALTER SYSTEM command,
you can dynamically set the DISPATCHERS parameter to any value between
5 and 20, inclusive.
3. Which column of the V$SHARED_SERVER_MONITOR view will pro-

vide information to help in setting the MAX_SERVERS parameter?
a. MAXIMUM_CONNECTIONS
b. SERVERS_STARTED
c. MAX_SERVERS
✓ d. SERVERS_HIGHWATER
4. How would you determine if connections were forced to excessively wait

in the request or response queues for available dispatchers or shared
servers? How would you resolve this problem?
You would determine the overall average wait time for connections in the
request and response queues by looking in the V$QUEUE data dictionary
view. If connects are excessively waiting for dispatchers or shared servers,
you would increase the numbers of these processes as needed.
Configuring the Listener for Web Clients

As you learned earlier in this lesson, Web clients can connect directly to the data-
base through the network. This is made possible by communicating with the
database through a specialized communications stack as shown in Figure 1-22
Figure 1-22: The communication stack for Web clients.

In this figure, the client uses a Web browser to connect to the database through
the network. Since the client needs almost no additional configuration, you only
need to configure the database to accept connections from Web clients. This con-
sists mainly of configuring the listener handle Web client connection requests and
configuring at least one dispatcher to act as a service handler for the database.
Figure 1-22 actually shows only a simplified version of the communications
stack; some pieces have been simplified for clarity. When Web clients connect to
a network, they primarily make use of the HTTP or FTP protocols. These proto-
IIOP: cols are both considered Internet Inter-ORB Protocols (IIOP). In general, IIOP is
(Internet Inter-ORB Protocol) a presentation protocol designed to implement CORBA technologies across the
A presentation protocol internet. CORBA stands for Common Object Request Broker Architecture, and
designed to implement
CORBA technologies across
while it sounds fancy, it is really just an attempt to provide an industry-wide stan-
the Internet. dard of accessing various types of data sources through a network. The equivalent
presentation layer on the server side is called General Inter-ORB Protocol
(GIOP). Figure 1-23 illustrates the communications stack configured to support
IIOP and GIOP.
CORBA:
(Common Object Request
Broker Architecture)
Architecture that provides an
industry-wide standard of
accessing various types of
data sources through a
network
The Communications Stack

with the IIOP and GIOP
Layers
Figure 1-23: The communications stack with the IIOP and GIOP layers.
In this figure, the client machine accesses the Internet in general using IIOP pro-
tocols, specifically HTTP or FTP. All requests from the client are sent through the
IIOP presentation layer using industry-standard object requests. The requests are
sent to the database through the network using TCP/IP and are translated by the
database using the standard TCP/IP protocol support layer. The request is then
sent through the database’s GIOP presentation layer to hand off to the database.
To support Web client connections, the database server must have Oracle Shared
Server configured with at least one available dispatcher. The listener can be con-
figured to listen for both traditional database requests and for Web client requests.
The IIOP protocol is used by the client to contact the listener, which is listening
on a specially configured port for Web connections. The listener will hand the
connection off to the appropriate dispatcher that is configured to receive requests
from the GIOP layer.
To configure the GIOP layer on the database side, you would simply include the
PRESENTATION argument with the set value for the DISPATCHERS initializa-
tion parameter. This argument is set to Oracle’s predefined GIOP presentation
layer that is included with the Oracle software. For example, the following shows
the DISPATCHERS parameter correctly configured to support Web client connec-
tions through the GIOP presentation layer.

dispatchers="(address=(protocol=tcp)(host=elementk)) ⇒
(presentation=oracle.aurora.server.SGiopServer)"
In this example, a single dispatcher will be configured with the TCP/IP protocol
on the ELEMENTK server. This dispatcher will be configured to support Web
client requests from the GIOP presentation layer. The presentation layer used
here, oracle.aurora.server.SGiopServer, is the standard presentation
included with the Oracle software. Once the dispatcher is configured, the database
is ready to support database requests from Web clients.
Configuring the listener to listen for Web client connections consists of adding a
new network address to the listener.ora file. This network address must be differ-
ent than the address used to support traditional Oracle Net connections. The
following shows an example listener.ora configured for Web client connections.
LISTENER=
(DESCRIPTION_LIST=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=elementk)(PORT=1521))
)
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=elementk)(PORT=2481))
(PROTOCOL_STACK=(PRESENTATION=GIOP)(SESSION=
RAW))
)
)
In this example, the listener is listening on port 1521 for standard Oracle Net
requests and on 2481 for Web client requests. Port 2481 is the standard port for
Web clients not using Secure Socket Layer (SSL), and 2482 clients using SSL.
The SESSION argument is set to RAW to ensure that the format of the data
packets sent by the client remain in their raw form and are not transformed in
any way until it reaches the TCP/IP protocol support layer on the database side.
Once the listener and dispatcher are configured, connecting to the database is as
simple as navigating to a Web site through the browser. The Web site address
uses the following format:
sess_iiop://hostname:port/service_name
For our example, the Web site address would be formed as shown here:
http://elementk:2481/ora92
When the client issues a connection request to the listener on 2481 using HTTP
or FTP protocols, the listener will identify it as a Web client and pass the connec-
tion to the pre-configured dispatcher through the GIOP presentation layer for the
database. The dispatcher will access the database on behalf of the Web client and
return all results to the client machine.
Web clients can also be configured to directly contact dispatchers at pre-assigned
ports. Each dispatcher can be assigned a port by specifying a host and port num-
ber for the ADDRESS keyword of the DISPATCHERS parameter. For example, a
dispatcher can be configured specifically to listen on port 2481. The client can
navigate directly to that port and completely bypass the listener. In some cases,
this can reduce the amount of time it takes to connect to the database because the
need to contact the listener has been eliminated.

TASK 1D-4
Configure the Listener for Web Clients
1. What is IIOP?
IIOP stands for Inter-ORB Protocol. IIOP is a presentation protocol
designed to implement CORBA technologies across the Internet. CORBA
stands for Common Object Request Broker Architecture, which provides an
industry-wide standard of accessing various types of data sources from a
network.
2. True or False? IIOP connection requests can bypass the listener and
directly contact dispatchers through the network. Explain your answer.
True. IIOP clients can be configured to directly contact dispatchers at pre-
assigned ports. Each dispatcher can be assigned a port by specifying a host
and port number for the ADDRESS keyword of the DISPATCHERS
parameter.
3. Which argument must be included with the DISPATCHERS initializa-

tion parameter to configure the GIOP layer for the database server?
a. ADDRESS
b. CONNECTION
c. LAYER
✓ d. PRESENTATION
Summary
In this lesson, you learned about the features of Oracle Net and how to con-
figure both the Oracle database server and the client to establish connections
to the database. You also learned how to configure Oracle Shared Server to
improve the scalability of the Oracle database and accept large numbers of
concurrent connections. Additionally, you learned about the additional net-
working options that are available for Oracle and the features they provide.

Lesson Review
1A In an N-tier environment, what is the easiest way to scale the environ-
ment to keep up with user demands?
a. Add another tier.
✓ b. Add more application servers.
c. Add more database servers.
d. Add more memory to each client’s machine.
In which situation could you connect to the database with a bequeath

connection?
a. When connecting to the database from a client machine.
b. When connecting to the database from a Java applet.
c. When connecting to the database directly from the Web.
✓ d. When connecting to the database from the same machine where the
database resides.
Which protocols does the Oracle protocol support layer currently sup-
port? Choose all that apply.
✓ a. Named Pipes
✓ b. TCP/IP
✓ c. TCP/IP with SSL
d. UDP
True or False? When using 3DES encryption for database connections,

each pass through the data to be transmitted must use the same key,
which must have a length of 128 bits. Explain your answer.
False. When using 3DES encryption for database connections, each pass
through the data to be transmitted can use a different key with a different
length. 3DES supports 112- and 168-bit key lengths.
1B In which directory is the listener.ora file stored?

✓ a. ORACLE_HOME/network/admin
b. ORACLE_HOME/network/config
c. ORACLE_HOME/rdbms/admin
d. ORACLE_HOME/sqlplus/admin

True or False? The set password command for the Listener Control
utility is used to change the permanent, stored password for the listener.
Explain your answer.
False. The set password command is used to set the password for the
current Listener Control session only, but it does not change the password of
the listener; this is done with the change_password command.
Even if you set an administrative password for the listener, how can the
security and integrity of the listener process be compromised by an
unscrupulous individual?
Since the listener is just a process that runs at the OS level, any user with
enough privileges through the OS can kill the process or stop its correspond-
ing Windows service. Additionally, since the listener configuration is stored
in a simple text file, it too can be compromised by any privileged user
through the OS. A user with Administrator or root privileges can kill the
listener process, change its configuration in the listener.ora file, and restart
it.
1C When submitting a connection request, how does the client determine

which names resolution method to use?
a. By contacting the DNS server.
b. By contacting the listener.
✓ c. By looking in its local sqlnet.ora file.
d. By looking in its local tnsnames.ora file.
In which folder is the HOSTS file stored on a Windows NT system?

a. C:\winnt\network\admin
b. C:\winnt\system32\admin\etc
c. C:\winnt\system32\com
✓ d. C:\winnt\system32\drivers\etc
On which page of the Net Manager utility would you specify

TNSNAMES for the NAMES.DIRECTORY_PATH parameter to be
written to the local sqlnet.ora file?
a. Local
✓ b. Profile
c. Service Identification
d. Service Naming

Describe the cause of the following connection error and the first steps
you would take to resolve it?
• TNS-03505: Failed to resolve name
The service name did not match a valid name listed in the tnsnames.ora file.
Typically this results from an incorrectly entered service name at the appli-
cation level. The first step should be to ensure that the client or application
is using the correct service name, and that the service name has the appro-
priate connect descriptor.
1D What happens after a user process issues a SQL command to the dis-
patcher process?
The dispatcher process places the SQL command in the request queue to be
picked up by the next available shared server process.
Describe the difference in the user’s PGA when connected to a shared

server connection as opposed to a dedicated connection.
In a dedicated server connection, the PGA consists of stack space to store
information on local variables, user session data such as resource usage and
security information, and cursor state information. In a shared server con-
nection, only the stack space is found within the PGA. The other information
is found in an area of the SGA known as the User Global Area (UGA), and
each user will have a private UGA within the SGA.
What query to the V$DISPATCHER view will give you the total dis-
patcher busy rate for each protocol configured?
SELECT network, SUM(busy) / (SUM(busy) + SUM(idle)) * 100
rate
FROM v$dispatcher
GROUP BY network;
How can Web clients be configured to directly contact dispatchers at

pre-assigned ports?
Each dispatcher can be assigned a port by specifying a host and port num-
ber for the ADDRESS keyword of the DISPATCHERS parameter. The client
can navigate directly to that port and completely bypass the listener.

Backup and Recovery LESSON
Overview
2
Data Files
none
Overview
Lesson Time
There are several different types of failures that can affect the Oracle data- 4 hours, 30 minutes
base and its clients, some of which can result in costly downtime or
unavailability of the database. In this lesson, you will learn about the types
of failures Oracle is susceptible to, how to build a solid backup and recov-
ery strategy to protect the database from failures, and how to minimize
downtime in the event that failures occur. Additionally, you will learn the
basics about cold and hot database backup and recovery techniques, and
you’ll explore the mechanisms that Oracle has in place to support these
types of operations.
Objectives
To describe the basic concepts of database backup and recovery in Oracle9i, you
will:
2A Describe the types of failures that may occur in an Oracle9i database

and the features provided to resolve them.
Failures in an Oracle database can be very costly. Every minute of down-
time could translate into tens of thousands of dollars of lost revenue for a
company. You will learn about the types of failures that can occur and
how Oracle reacts to each type of failure.
2B Perform a cold backup of the database, and use that backup to

restore and recover the database after a failure.
Cold backups allow you to create a complete copy of your database that
is guaranteed to be consistent. When recovering the database from a cold
backup, the database will look exactly as it did at the point in time the
database was shut down for the backup. In this topic, you will learn how
to perform a cold backup of the database and how to use that cold
backup to restore and recover the database after a failure.
2C Describe the mechanisms in place to back up and recover an Oracle9i

database with minimal data loss.
Oracle provides mechanisms that allow you to perform backups and
recoveries of the database while the database stays up and running. This
minimizes downtime and can minimize the mean time to recovery. In this
topic, you will learn how to configure your database to support hot back-
ups and learn the process that is used to perform a hot recovery.
Lesson 2: Backup and Recovery Overview 95

Topic 2A
Introduction to Backup and Recovery
There are several different types of failures that can affect the Oracle database
and its clients, some of which can result in costly downtime or unavailability of
the database. These failures can have varying affects on the database, depending
Types of Failures on the scope and severity of the failure. Some types of failures only affect single
users or single transactions, while other failures can affect the availability of the
entire database. The failures that can occur within an Oracle database, ranging
from the least to most severe, include:
• Statement failure
• Transaction failure
• Session failure
• Instance failure
• Media failure
Statement Failure
When statement failure occurs, a single SQL statement, usually a SELECT state-
ment, from a single Oracle client has failed. This type of failure can occur for a
wide variety of reasons. It is possible that the statement issued from the client
was syntactically incorrect, or the statement referenced an object that either didn’t
exist or the user didn’t have privileges to access. Statement failure can also occur
if a statement performs a large amount of sorting in the temporary tablespace,
and the temporary tablespace runs out of space during the operation. This type of
failure usually has no damaging affects on the database, therefore no recovery is
required. The client issuing the statement will simply receive an error stating the
reason why the statement failed.
Transaction Failure
Transaction failure differs from statement failure only in that transaction failure
occurs while a client is in the middle of manipulating the data. The client would
issue a DML statement to perform one or more INSERT, UPDATE, or DELETE
undo segments: operations on the data, and the entire transaction failed. To recover from transac-
Database segments that tion failure, Oracle makes use of undo segments in the database. As a transaction
temporarily hold the original executes, the data that is to be changed is first copied to the undo segments. Once
versions of changed data
from a transaction in case
the transaction is committed, the undo segment the transaction was using is
the transaction needs to be released. If the transaction fails, Oracle will automatically rollback the entire
rolled back and the original transaction using the original copies of the data in the undo segment to return the
version replaced. data to its original state before the transaction started.
Each transaction can consist of one or more DML statements in the database. For
data consistency, Oracle treats every transaction as an atomic unit of work. This
means that the entire transaction is successful or the entire transaction is rolled
back; Oracle does not allow the partial completion of a transaction. A transaction
starts when the first DML statement is issued, and completes when the transaction
is committed. There can be any number of DML operations between the first
DML statement and the commit. For example, the following series of statements
consist of a single transaction, which ends when the COMMIT statement is issued.

INSERT INTO dept VALUES
(10,'Data Quality Assurance');
DELETE FROM emp

WHERE emp_id = 3483;
UPDATE emp
SET salary = salary * 1.1;
COMMIT;
In this example, the transaction starts when the first statement is issued, which is
the INSERT statement that creates a row in the DEPT table. The transaction con-
sists of a total of three DML statements, and is complete when the COMMIT
statement is issued. If the transaction fails at any point after the INSERT state-
ment begins and before the COMMIT is issued, all changes will be rolled back. A
transaction can be committed by either explicit or implicit commits. An explicit
commit occurs when the client issues the COMMIT statement. An implicit commit
occurs when some new activity requires that all transactions within the session be
committed. All DDL statements cause an implicit commit.
A transaction failure can be caused by any number of reasons, but is usually
caused by the shortage of database resources. For example, a long-running trans-
action may generate so much undo information that it causes the undo segment
extent to grow to the point that the tablespace is full. If the undo segment cannot
extend, the transaction will fail. Oracle automatically handles all transaction fail-
ures through the use of the undo segments, so no DBA intervention is necessary.
If a transaction fails, the client issuing the transaction will receive an error stating
why the transaction failed.
Session Failure
Session failure occurs when a client loses its connection to the database com-
pletely, and usually occurs when any component of a database connection, such
as client, server, or network, becomes unavailable. For example, if the client loses
its connectivity to the network, or if the client machine crashes entirely, it will
also have lost contact with the database. Depending on the failure, a trace file
concerning the error may be generated, and the client may either receive an error
back immediately from Oracle that states what the error is, or the error will be
returned the next time the client attempts to access the database. Of course, if the
session failure occurred because the client machine crashed completely, then there
will be no error returned, but the reason for the session failure will be obvious to
the user.
Session failure may actually cause lesser failures, such as the failure of any state-
ments or transactions the client was currently issuing to the database. Statement
failure has no affect on the database, and transaction failure will be rolled back
automatically by Oracle using the undo segments. The only other action that must
occur is releasing any database or system resources consumed by the client con-
nection, such as PGA space in memory and locks and latches in the database.
Such resource “cleanup” is handled by the process monitor (PMON) background
process. If PMON detects that any client has lost connectivity to the database, it
will immediately attempt to release all resources consumed by the failed process,
thus freeing up the resources to be used by other new or existing database
connections.

Instance Failure
Instance failure is the most widespread type of failure that can occur in an Oracle
database. It is equivalent to a crash of the database and affects all sessions cur-
rently connected to the database. If the instance cannot stay up and running for
any reason, the entire SGA is deallocated from memory and the database stops
running, and all sessions connected to the database will immediately fail. When
instance failure occurs, you are guaranteed to have database downtime.
The instance can fail for a variety of reasons. The Oracle instance consists of the
entire System Global Area (SGA) and its set of required background processes.
Five of these background processes, database writer (DBWR), log writer
(LGWR), process monitor (PMON), server monitor (SMON), and checkpoint
(CKPT) are required. If any one of the required background processes fail, the
instance will fail. If the server where the database is running crashes, this will
also result in instance failure.
Instance failure is automatically resolved the next time the instance is started up.
Upon startup, Oracle will detect that the last shutdown of the database was not
clean, and it will attempt to perform instance recovery. This involves rolling for-
ward all transactions that had not yet been written to the datafiles, and rolling
back all transactions that had not yet been committed. All necessary actions taken
by Oracle to accomplish instance recovery will be annotated in the alert log. If
the only failure involved is instance failure, then there should be no damage done
to the database, and unplanned downtime will be the only negative result. Once
instance recovery is complete, the database can be opened to make it available to
users. You will learn more about the mechanisms that Oracle uses to perform
instance recovery later in this lesson.
Media Failure
While instance failure is the most widespread, media failure is actually the most
damaging, and can usually cause the most downtime. Media failure occurs when
a hardware component of the server where the database resides, usually a disk or
disk array, has failed, become damaged, or has become otherwise unavailable.
Media failure may not necessarily cause instance failure, but it may. If the disk
media in question contains the Oracle binary executables, the datafiles of the
SYSTEM tablespace, all copies of the control file, or the current online redo log,
then the instance will fail and will not be able to be restarted until the affected
files were restored and recovered. However, if the disk contains one or more
datafiles of non-SYSTEM tablespaces, then the instance can usually stay up and
running, but Oracle will automatically take the affected datafiles offline. Oracle
will write error messages to the alert log for each of these datafiles at every
attempt to write to them until the datafiles are recovered.
Media failure is considered the most severe type of failure because, while it may
not cause instance failure, it can result in the actual loss of data. Instance recov-
ery is the most widespread failure because it affects all sessions, but can usually
be resolved very quickly by simply restarting the instance. Media failure usually
requires additional steps to restore the database to its original state, and if not
done properly, the loss of data can be permanent and extremely costly. Even if
the instance is up and running, if the core data that an application depends on is
unavailable, the application can no longer function. This is also considered
downtime.

TASK 2A-1
Identify Types of Failures
1. Match the scenario on the left with its type of failure on the right.
d A query fails because the a. Instance failure
user’s desktop lost contact
to the database server
through the network.
c A query fails due to insuf- b. Media failure
ficient sort space in the
TEMP tablespace.
a The host server crashed. c. Statement failure
b A disk volume containing d. Session failure
a control file becomes
corrupted.
2. How does the database server handle session failure?
Any uncommitted transactions initiated by the session are rolled back, and
the process monitor (PMON) background process will deallocate any
resources that were utilized by the failed session, such as memory, locks, and
latches. Depending on the failure itself, Oracle may or may not generate a
trace file containing any details it has about the session and why it failed. In
general, the client that encountered the failed session will return some kind
of error, either immediately when the failure occurs, or at the next attempt to
access the database.
3. How does the database server handle instance failure?

In general, instance failure is resolved immediately once the instance is
restarted. Upon startup, Oracle will detect that the last shutdown of the
database was not clean, and it will attempt to perform instance recovery.
This involves rolling forward all transactions that had not yet been written
to the datafiles and rolling back all transactions that had not yet been
committed. All necessary actions taken by Oracle to accomplish instance
recovery will be annotated in the alert log.
4. How does the database server handle media failure?

Media failure may not necessarily cause instance failure, but it may. If the
disk media in question contains the Oracle binary executables, the datafiles
of the SYSTEM tablespace, all copies of the control file, or the current
online redo log, then the instance will fail, and could not be restarted until
the affected files were restored and recovered. If the disk contained one or
more datafiles of any non-SYSTEM tablespaces, than the instance can usu-
ally stay up and running, but Oracle will automatically take the affected
datafiles offline. Oracle will write error messages to the alert log for each of
these datafiles at every attempt to write to them until the datafiles are
recovered.

Backup and Recovery Basics
Providing a stable and safe database environment consists of two primary objec-
tives: minimizing unplanned downtime and preventing the loss of critical data. To
reach these objectives, you must design and implement a sound backup and
recovery strategy that matches the requirements of the system. It is important to
remember that failure will happen, and you must consider not if, but when, it will
happen. Regardless of how much money you spend on your high-performance
system, or how many backups you take, or how many redundancies you build
into the system, failure will happen. You can only push the limits of hardware so
far for so long before something fails. The best you can hope for is configuring
the system to keep the risk of failure to a minimum and have a recovery plan in
place to recover the database as quickly as possible when a failure does occur.
When designing your backup and recovery strategy, there are two very important
concepts you must take into consideration. These are mean time between failures
(MTBF) and mean time to recovery (MTTR). The mean time between failures
MTBF: refers to the amount of time that you can expect between failures of the database,
(Mean time between failures) the longer the better. You must ask yourself, how long will the database stay
The average amount of time operational until the next failure? Is the MTBF for your system so short that your
that passes between failures
of a system.
24x7 database is crashing twice a day? If it is, backing up your system five times
a day will not increase the amount of time your database stays up. It could be
that your system is experiencing hardware problems, a bug in the operating sys-
tem, or even a bug in the Oracle software. You must investigate the issue to
MTTR: determine why it is failing and take steps to keep your database up for as long as
(Mean time to recovery) The possible.
average amount of time it
takes to recover a system Mean time to recovery refers to the amount of time it takes for you to get your
after a failure. database back up and running, with all of its data, when a failure does occur. A
database that crashes twice a day is an issue. However, if all you have to do is
restart the instance, then you can probably have the database up and running in a
very short time. But let’s say a database experiences failures only once a month,
but when it does, it takes eight hours to recover from it. The MTTR of your data-
base has a direct dependency on how you configured your backups and recoveries
to perform and whether or not you have planned for every possible failure. The
failures that take the longest to recover from are usually the ones you didn’t plan
for. Since you didn’t plan for it, you probably didn’t take the necessary steps
ahead of time to recover from it.
A strong backup and recovery strategy encompasses taking steps to increase
MTBF and decrease MTTR. To increase MTBF, you should analyze your system
on a regular basis to ensure that it is configured in such a way to be resilient to
failure. You should ensure that you have multiple mirrors of the control files, and
that they are all stored on separate disks. If one disk fails, you still have another
valid copy of the current control file. The same goes for redo logs; they should
be mirrored, with each mirror on a separate disk. If you lose a log file member
because of media failure, you still have another copy. You should ensure that the
OS and the Oracle software are both running the latest patches for their versions.
This will help avoid any unexpected bugs when making changes to the system,
such as updating device drivers.
To decrease MTTR, you should find ways to reduce the amount of time to
recover after a failure. This involves determining what steps must be taken for
each type of failure your database is susceptible to, and preparing sufficient steps
ahead of time to recover from them. To keep MTTR at a minimum, you should
have your plan in place and regularly run recovery drills simulating various types

of failures so you will know ahead of time what to do for each scenario. Recov-
ery drills will also help to identify any issues with your recovery process, and
you can revise your recovery plans to take these issues into consideration. The
better prepared you are, the shorter your MTTR.
Hot and Cold Backups and Recoveries

A backup of the database can be performed either while the database is shut
down, known as a cold backup, or while it is up and running, known as a hot
backup. Performing a cold backup is the simplest type of backup, but it requires
that the database be shut down. If the database is shut down cleanly (not with the cold backup:
ABORT option), none of the control files, datafiles, or redo log files are open or A full backup of the database
accessed by an instance, and the database is guaranteed to be in a consistent state. while the database is shut
down.
To perform the backup, you merely have to shut down the database and make
copies of all the data files, control files, and redo log files to another location,
then start the database up again. Recovering the database from a cold backup is
just as simple. You would shut down the database, if it is running, and replace all hot backup:
of the datafiles, control files, and redo log files from their backup copies, then A backup of the database,
start up the database. either full or partial,
performed while the database
While cold backups and recoveries are simple to perform, they provide extremely remains up and running.
limited capabilities. Since the database must be shut down, there is guaranteed
downtime until the backup is complete. If the database is very large, it may take
a very long time to copy all of the datafiles, which may be more than the busi-
ness rules the database can allow. Also, when recovering the database after a Recovering From a Cold
failure, you cannot just copy one or two datafiles from the backup set. You must Backup
restore all of the files from the backup set, which means that you can only
recover the database to the point in time when the cold backup was taken. Figure
2-1 illustrates a recovery from a full backup.
Figure 2-1: Recovering from a cold backup.

In this figure, the database was shut down at 4:00 A.M., and a cold backup was
performed. The database was started up again and continued to operate normally.
At 3:00 P.M., a media failure occurred, and the database lost some datafiles.
Regardless of which datafiles were lost, in order to recover you must restore all
of the files from the cold backup taken at 4:00 A.M. Once the database is started
up again after the restore, the data will look as it did at 4:00 A.M. All changes to
the data that occurred between 4:00 A.M. and 3:00 P.M. will be lost.
Hot backups and recoveries provide much more in the way of flexibility and
capability. The database can stay up and running while a hot backup is per-
formed, which minimizes database downtime. Additionally, you can perform true
point-of-failure recovery. This means that if the database experiences media fail-
ure at 3:00 P.M., as it did in Figure 2-1, you can still recover all changes that
occurred between the last backup and the point in time when the failure occurred.
To keep track of all changes in the database, Oracle uses a sequential numbering
system to assign a system change number (SCN) and timestamp to every
transaction. During the normal operation of the database, the checkpoint process
SCN: (CKPT) will update the control file and the headers of all the datafiles with the
(System Change Number) A latest system change number (SCN) and timestamp on a regular basis. This
sequential numbering system allows Oracle to ensure that all datafiles are kept up to date, using the control file
Oracle uses to track every
change in the database.
as a reference point. If the header of a datafile shows a lower SCN than the con-
trol file, Oracle will assume that the datafile is missing some changes, and will
write an error in the alert log stating that the datafile in question needs recovery.
Any process that attempts to write to the datafile will receive an error and that
transaction will fail.
When performing a hot backup, you would place each tablespace in backup
mode. Doing so causes the checkpoint process to defer updating the datafile head-
ers for that tablespace with the latest SCN. The files will remain open, and their
contents can be updated by Oracle, but you will be allowed to make a copy of
the datafiles while the database is running. Once the copy is complete, the
tablespace can be taken out of backup mode, and CKPT will resume updating the
datafile headers for that tablespace.
In order to perform hot backups, the database must be running in a special mode
Recovery From a Hot called ARCHIVELOG mode. As changes are made to the database, the modified
Backup datablocks are written to the datafiles, but the changes are also recorded in the
redo log. This is normal behavior, even when the database is in
NOARCHIVELOG mode. When the database is running in ARCHIVELOG
mode, the redo log files are regularly copied to another location to archive the
changes. If the database ever suffered media failure, you would only need to
restore the affected datafiles from the last backup, and apply the archived changes
to the datafiles to bring them up to date with the rest of the database. Figure 2-2
illustrates a recovery from a hot backup.

Figure 2-2: Recovery from a hot backup.
In this figure, a hot backup of the database was performed at 4:00 A.M. The data-
base remained open, and each tablespace was placed in hot backup mode as the
data files were copied. The database continued to operate normally until media
failure occurred at 3:00 P.M., which caused the database to lose some datafiles.
Only the affected datafiles were restored from the backup and set back to their
original locations. Then, all archived changes were applied to the datafiles to
bring them up to date with the rest of the database. The database was recovered
to the point in time when the failure occurred, and no changes were lost. Addi-
tionally, the database remained up and running throughout the entire process. The
datafiles that were affected by the media failure were not accessible by users until
they were recovered, but the data in the rest of the database remained available
for general use.
While the mechanisms to make hot backups and recoveries possible add com-
plexity to the database, they allow much more flexibility than cold backups and
recoveries. In addition to the ability to keep the database up and running, you
have the capability of backing up only a tablespace at a time. This allows you to
spread out your backups across multiple sessions if the database is very large. For
example, instead of shutting down the database for four hours to perform a cold
backup, the backup can be broken up across several days where each day you
would back up only one or two tablespaces. Additionally, when performing cold
backups, any media failure requires that you restore the entire backup set from a
the cold backup. With hot backups, only the affected datafiles need to be restored,
which can greatly reduce the mean time to recovery. With cold backups, all
changes between the time the backup was taken and the time the failure occurred
are lost. Whereas with hot backups, these changes can be pulled from the archive
and applied to the affected datafiles.
It is important to note that there is a distinct difference between restore and
recover. When a datafile is lost, such as when media failure occurs, the datafile is
restored from its backup using standard OS commands. When the database is
recovered, archived changes are applied to a restored datafile to bring it up to
date with the rest of the database. You will learn more about the mechanisms that
make hot backups and recoveries possible later in this lesson.

Complete and Incomplete Recoveries
When performing a recovery of the database, you can perform either a complete
or incomplete recovery. In a complete recovery, all of the latest changes to the
database are applied to any datafiles that are not up to date. When a complete
complete recovery: recovery is performed, the contents of the entire database are updated to reflect
A database recovery where the way the database should look at the very instant just before the failure
all changes to the database occurred. This type of recovery is usually desirable in most situations, especially
are recovered right up to the
point of failure.
for a live, transactional database where every transaction must be preserved.
In an incomplete recovery, not all of the latest changes are applied to the database
during recovery. When an incomplete recovery is performed, the state of the data-
base is brought back to some point in time in the past. Any changes to the data
incomplete recovery: after that particular point in time would be lost. This type of recovery would be
A database recovery where desirable if a transaction or series of transactions needed to be undone, such as a
not all changes to the user deleting all the rows in a table and then committing the transaction. In this
database are recovered.
case, the database can be restored to a point in time before the data was deleted.
However, there is one very important caveat regarding recoveries. The Oracle
database is very consistency-minded. The entire database must be consistent at all
times, which means that all datafiles must constantly be at the same SCN and
timestamp. Therefore, when performing an incomplete recovery you must bring
the entire database back to the same point in time. You cannot, however, recover
just a single datafile or tablespace to a different point in time than the rest of the
database. An incomplete recovery is performed using the same mechanisms and
commands as a complete recovery, except with an incomplete recovery, you do
not apply all of the changes that have been archived. You can stop applying the
changes at any point, so long as the headers of all of the datafiles have the same
SCN and timestamp.
TASK 2A-2
Describe Backup and Recovery Basics
1. Define the terms MTBF and MTTR. How do these concepts influence
your backup and recovery strategy?
MTBF stands for mean-time between failures, which indicates how much
time passes between one major failure and the next. MTTR stands for mean-
time to recovery, which indicates the total amount of time required between
a failure and a resolution to that failure.
To improve database uptime and availability, it should be the DBA’s goal to
maximize the amount of time between failures and minimize the amount of
time between a failure and its resolution. The amount of downtime a particu-
lar database can allow will be highly dependent on the business
requirements for that database and will play heavily into the backup and
recovery strategy. A database that can tolerate the occasional failure may
require only a moderate backup and recovery strategy, but a database that
cannot allow any downtime whatsoever will require a very in-depth high
availability and backup and recovery strategy.

2. What is the difference between a restore and a recovery?
When a datafile is lost, such as when media failure occurs, the datafile is
restored from its backup using standard OS commands. When the database is
recovered, archived changes are applied to a restored datafile to bring it up
to date with the rest of the database.
3. What is the difference between a complete and incomplete recovery?

Describe an example situation where each one would be desirable.
In a complete recovery, all of the latest changes to the database are applied
to any datafiles that are not up to date. When a complete recovery is per-
formed, the contents of the entire database are updated to reflect the way the
database should look at the very instant just before the failure occurred. This
type of recovery is usually desirable in most situations, especially for a live,
transactional database where every transaction must be preserved.
In an incomplete recovery, not all of the latest changes are applied to the
database during recovery. When an incomplete recovery is performed, the
state of the database is brought back to some point in time in the past. Any
changes to the data after that particular point in time would be lost. This
type of recovery would be desirable if a transaction or series of transactions
needed to be undone, such as a user deleting all the rows in a table and
then committing the transaction. In this case, the database can be restored to
a point in time before the data was deleted. However, doing so would mean
that the entire database was brought back to that point in time, not just that
one table.
Instance and Media Recovery Structures

Oracle includes a fairly complex set of mechanisms to support instance and
media recovery. These mechanisms are tightly integrated into the operation of the Instance and Media
database and allow Oracle to recover the database from most types of failure. Recovery Structures
Regardless if the database suffered instance failure or media failure, some or all
of the mechanisms play a role in recovery. The primary recovery structures for
the database include:
• Undo segments
• Redo log buffer
• Redo log files
• System Monitor (SMON) process
• Log writer (LGWR) process
• Archiver (ARCH) process
• Checkpoint (CKPT) process
• Database writer (DBWR) process
• Control file
First, you will learn the purpose of each of these mechanisms separately, and then
you will see how they all work together as a seamless system.

Undo Segments
Undo segments are used to rollback, or undo, changes to data and play a critical
In previous versions of role during recovery. When performing DML operations on data, Oracle will store
Oracle, undo segments were the original version of each row of data to be changed in an undo segment. This
known as rollback segments. original version, or before image, is used for multiple purposes, including:
• Data consistency during DML operations.
• Rollback of unwanted changes.
before image: • Rollback of transactions after statement or session failure.
The original version of data
before it was changed by a • Rollback of uncommitted transactions during instance or media recovery.
transaction.
To ensure data consistency during DML operations, such as INSERT, UPDATE,
or DELETE statements, the process executing the statement will acquire a lock on
the rows to be modified, and then the before image is copied into an undo
segment. All changes to the data will take place in the actual datablocks where
the row resides, but the original versions of the rows in the undo segments will
be preserved for the duration of the transaction. If another process tries to query
from those same rows, it will detect that a DML lock has been placed on them,
and will read the before image from the undo segment instead of the changed
version in the original datablocks. Once the DML operation is complete and a
commit is issued, either explicitly or implicitly, the DML locks and the undo seg-
ment are released and the changes are made permanent. This guarantees that no
other user will be able to see the affects of a DML operation until it is
committed. Figure 2-3 illustrates the basic concept of undo segment operation.
Basic Undo Segment

Operation
Figure 2-3: Basic undo segment operation.

In this figure, the UPDATE statement is changing the value of the SALARY col-
umn for the employee with an EMP_ID of 4. The original value of 90000 in the
SALARY column is first copied to an undo segment to preserve it, and then the
change is made in the actual row.
Another use of an undo segment is to cancel a transaction that could not com-
plete for one reason or another. During a rollback operation, Oracle will copy the
before image back to the original datablocks they came from, and then release all
locks on the rows. It could be that a user issued a series of DML statements,
looked at the results, then changed his or her mind and manually rolled back the
changes using the ROLLBACK statement. It could also be that a transaction sim-
ply failed due to either statement or session failure. For example, let’s say a user
executes a large UPDATE statement that makes use of several subqueries. The
subqueries caused extensive sorting in the temporary tablespace, so much so that

the temporary tablespace fills up and Oracle can no longer allocate more sort
space. The statement will fail and will be rolled back using the before image of
the data in the undo segments. When session failure occurs, all transactions that
were currently open by that session will be rolled back.
Rollback segments are also used during instance and media recovery. This is
handled by a roll forward, roll back technique. During recovery, the database is
rolled forward in time, re-enacting all changes to the database from the last
known good state of the database up to the point of failure. During this roll for-
ward, all transactions that had not yet been written to the datafiles will be flushed
to the datafiles. Once the database has been rolled forward to the point of failure,
any uncommitted transactions that exist in the undo segments will be rolled back.
This allows Oracle to ensure that the database will be consistent before allowing
it to be opened for general use.
Redo Log Buffer

The redo log buffer is an area of memory within the SGA. As data is changed,
redo entries are written to the redo log buffer along with their associated SCNs
and timestamps of when the changes occurred. The redo log buffer acts primarily
as an in-memory staging area where Oracle can store the redo information from
each change prior to writing the changes to the redo log files. The redo informa-
tion that is generated from each change is used during the roll forward phase of
database recovery. As the database rolls forward, the redo information is used to
re-enact the changes that had occurred between the last known good state of the
database and the point of failure.
There is some impact to database performance to generate redo information for
changes to the data. In addition to the resources needed to just complete a single
change, Oracle must also take time to generate the redo entries for the change.
While it is not possible to disable redo logging instance wide, you can disable it
at the object level. Most segments in the database, such as tables and indexes,
have a segment attribute that can be set to either LOGGING or NOLOGGING. If it
is set to LOGGING, which is the default, full redo log generation will occur for
each change. Setting the attribute to NOLOGGING will eliminate the redo genera-
tion for the object, which can improve performance slightly. It is important to
remember though, that objects that are set to NOLOGGING will not be recover-
able in the event of a failure. For very large transactions, disabling redo logging
can improve performance, but the performance impact is usually considered a fair
trade off in comparison with recoverability. Without redo logging, it is possible to
lose critical changes to the database in the event of a failure. The following
example shows a CREATE TABLE statement with the NOLOGGING attribute.
CREATE TABLE emp
(
empid NUMBER,
lname VARCHAR2(64),
fname VARCHAR2(64)
)
TABLESPACE hr
NOLOGGING;
Redo Log Files

From time to time, the contents of the redo log buffer are written out to the redo
log files. The redo log files are configured in groups and work in a cyclical fash- The current redo log group
ion, with one redo log group acting as the current group and the others standing is sometimes referred to as
by. Once the redo log buffer is full of changes, they are written out to the current the online redo log group, or
redo log group. Once this group is full, the current log group is switched out and just the online redo log.

the next group in line becomes the current group. This allows Oracle to infinitely
generate redo information without being restricted by the size of a single log file.
As each log file group is switched in as the current log group, Oracle assigns an
ever-increasing log sequence number to the group. This log sequence number is
used to track which log group contains which changes in the event a recovery is
needed.
The redo log files are configured in groups, and each group can have one or more
log file members. All members of a single redo log group capture the same redo
information as it is written from the log buffer to the current redo log group,
allowing each log file member of a single group to act as mirrors of each other.
This provides the ability to separate the log file members of a single group across
multiple disks. If the disk where one log file member resides suffers media failure
and the log file member is lost, Oracle can continue generating changes as long
as at least one other log file member in the group is available. If all members of
the current redo log group are lost, the instance will crash. Figure 2-4 illustrates a
configuration of three redo log groups, each with two log file members.
Redo Log Groups and Their

Members
Figure 2-4: Redo log groups and their log file members.
The minimum redo log configuration is two groups, each group having one log
file member each. For performance reasons, it is recommended that you configure
at least three redo log groups. The size of the log file members can be manually
set when they are created, but should be sized appropriately for your system. Log
file members that are sized too small for a busy system will cause the log files to
fill up very quickly, which results in excessive log switching and can hurt
performance. It is also recommended that you configure at least two members for
each log file group so you can place each member per group on separate disks,
just in case your system experiences media failure where one of your log file
members reside.

System Monitor (SMON) Process
The system monitor (SMON) background process is responsible for initiating
instance recovery after a failure. When the instance is started, Oracle tries to
determine if instance recovery is necessary. If instance recovery is needed,
SMON signals all other background processes to start their specific recovery-
related activities. SMON also has some other non-recovery related duties, such as
periodically cleaning up unused temporary segments in the tablespaces, and coa-
lescing free extents in dictionary-managed tablespaces.
Log Writer (LGWR) Process

It is the job of the log writer (LGWR) background process to read the redo log
entries from the redo log buffer and write them to all members of the current
redo log group. The LGWR process will perform this task when the following
conditions are encountered:
• When a user issues a COMMIT statement.
• Every three seconds, even if no user issued a COMMIT statement.
• When the redo log buffer is at least one-third full.
If LGWR cannot write to the current redo log group, usually when the current
log is full and the logs cannot be switched for some reason, then the instance will
hang until the logs are switched and LGWR can continue writing. This is a
required background process, and as such, if it were to die for any reason would
cause the instance to crash.
Archiver (ARCH) Process

As LGWR writes out changes from the log buffer to the current redo log group,
the redo log group will fill. Once the current log group is full, Oracle switches
the current log group out and the next log group in line becomes the current log
group. If the database is running in ARCHIVELOG mode, the archiver (ARCH) archive log:
process will begin to archive the now-full log group that was just switched out by A copy of a redo log that has
copying it to the location specified by the LOG_ARCHIVE_DEST parameter. The been filled and switched out
as the current log group.
file that is created by the archiver process is called an archive log. Regardless of Archive logs are used to
the number of log file members there are in a log group, only one archive log is apply changes to a backup to
created per group. bring it up to date during
recovery.
The archive process is optional and only exists when the database is running in
ARCHIVELOG mode. When the database is running NOARCHIVELOG mode,
none of the redo log groups are archived as they fill. If all log groups have filled
and switched out, Oracle will begin writing to the first log group again, overwrit-
ing the redo information it once contained. Enabling ARCHIVELOG mode allows
you to make a physical copy of the changes in a log group before its changes are
overwritten. As each archive log is created, it is renamed with the log group’s
latest log sequence number, allowing Oracle to track which archive log contains
which changes for which SCNs. If a database had to be restored from a backup,
the changes stored in the archive logs can be used to roll the database forward to
the point in time when the failure occurred. Even if the database backup was per-
formed weeks or months ago, as long as you kept all of the archive logs since
that backup, you could restore your database right up to the point of failure.

Checkpoint (CKPT) Process
At regular intervals, and when certain conditions exist, the database will perform
a checkpoint. During this checkpoint, all modified datablocks in the buffer cache
are written out to the datafiles. These modified datablocks can hold changes from
both committed or uncommitted transactions. During a checkpoint, the checkpoint
(CKPT) process updates the control file and the headers of all the datafiles with
the current SCN and timestamp. This guarantees that all changes up to the current
SCN will be written to the disk. A checkpoint is triggered by the following condi-
tions:
• Manually with the ALTER SYSTEM CHECKPOINT command.
• A redo log switch, either automatically through normal operations or manu-
ally with the ALTER SYSTEM SWITCH LOGFILE command.
• As determined by the LOG_CHECKPOINT_INTERVAL and LOG_
CHECKPOINT_TIMEOUT initialization parameters.
• When a tablespace is taken offline NORMAL (as opposed to IMMEDIATE).
• At the start of a tablespace-level hot backup.
• When the database is closed properly (using NORMAL, IMMEDIATE, or
TRANSACTIONAL shutdown modes).
A checkpoint is similar to a bookmark for the database. Since all changes prior to
the last checkpoint are guaranteed to be on disk, only changes that were gener-
ated after the last checkpoint are needed for the roll forward phase of instance
recovery. If the database performs checkpoints often, fewer changes will be
needed for the roll forward phase, thereby reducing the amount of time that is
needed to recover the database. If the database performs checkpoints infrequently,
more time will be needed for instance recovery since more changes will need to
be applied during the roll forward phase. The database can be tuned, through a
combination of parameter settings and proper redo log file sizing, to control how
often a checkpoint will perform. Too frequently, checkpointing can affect perfor-
mance, especially if there are many datafiles that CKPT must update. However,
too infrequently, checkpointing can cause extremely slow recovery time in the
event of instance failure. The LOG_CHECKPOINTS_TO_ALERT initialization
parameter can be set to TRUE, which causes Oracle to write an entry in the alert
log for every checkpoint. This information can be extremely useful in determin-
ing how often your database is performing checkpoints. The default value for this
parameter is FALSE.
Database Writer (DBWR) Process

The database writer (DBWR) background process has one job and one job only:
to write modified datablocks from the buffer cache to the datafiles. At every
checkpoint, DBWR will write out all modified datablocks, whether the modifica-
tions were committed or not. If a data modification was committed, the change
was already written to the datafile, so therefore it will not need to be re-created
during the roll forward phase of recovery. If the modification was not committed,
it will be rolled back using the undo segments during the rollback phase of
recovery. DBWR is a required process.

It’s important to note that a transaction is not considered to be committed just
because its changes were written to a datafile. A transaction can be committed
and recovered after a failure, even if the changes never actually made it from the
buffer cache to the datafiles. Conversely, changes that have made it to the
datafiles may or may not be committed. A transaction is only considered commit-
ted when a COMMIT statement for the transaction exists in the redo log files,
regardless of whether or not the changes made it to the datafiles.
Control File
The control file is the single most important file in the database, both for normal
operations and for recovery operations. It contains the current file structure and
the most current SCN for the database, along with a list of the most recent
archive log files that have been generated for the database. A database can have
one or more copies of the control file, which are found at the location specified
by the CONTROL_FILES parameter. The parameter CONTROL_FILE_
RECORD_KEEP_TIME determines how long the information in the control file
will be kept before it is over written with new information. This is particularly
important for the archive log information, which is ever-growing for databases in
ARCHIVELOG mode.
Each copy of the control file contains identical information, but it is recom-
mended that you configure multiple copies to eliminate a single point of failure.
If all copies of the control file (or the only copy) become corrupted or lost, the
database would crash and could not restart until a valid control file exists.
During recovery, Oracle uses the SCN in the control file as a reference point to
determine which datafiles need recovery. If the header of a datafile contains an
SCN that is lower than what is contained in the control file, that datafile will
need to be recovered. As the roll forward phase of recovery begins, Oracle
applies the missing changes to the datafile, and the SCN for that datafile
increments. Once the SCN for that datafile matches that of the control file, the
datafile is considered to be recovered, and once all datafiles are recovered, the
database can then be opened for general use.
Putting it all Together

Each individual structure plays an important role in the database recovery pro-
cess, but it is the combination of all structures working together that provide Instance and Media
Oracle the ability to recover from most types of failures. Figure 2-5 illustrates Recovery Structures
how all the structures work together. The undo segments were left out of the fig-
ure for clarity.

Figure 2-5: Instance and media recovery structures.
When a transaction executes, a server process acting on behalf of a user will
modify data in the buffer cache, and the before images of each row changed are
stored in the undo segments. Additionally, as the changes to the datablocks are
made, an entry for each change is recorded in the log buffer. Once the log buffer
becomes at least one-third full or the user commits the transaction, the log writer
(LGWR) process writes the contents of the log buffer to the current redo log
group. Once the current redo log group becomes full, Oracle performs a log
switch; the current group is rotated out and the next group in line becomes the
current log group. If the database is running in ARCHIVELOG mode, the
archiver (ARCH) process will copy the full redo log group that was switched out
to an archive destination.
To ensure that modified datablocks are written to the datafiles regularly, Oracle
will perform checkpoints at regular intervals and when triggered by specific
conditions. During a checkpoint, the database writer (DBWR) process will write
all modified datablocks from the buffer cache to the datafiles. Additionally, the
checkpoint process (CKPT) will update the control file and the headers of all the
datafiles with the current SCN and timestamp.
During a recovery operation, the sequence of events to recover the database is
almost identical to when the database is operating normally. The only difference
is that the redo information in the redo and archive logs becomes the source of
the changes rather than a user process.
First, Oracle must determine at what point is the last known good state of the
database. In the case of instance failure, the last known good state is the very
latest checkpoint just prior to the failure. All transactions before this point in
time, committed or uncommitted, are guaranteed to be written to the datafiles,
while all transactions after this point in time may exist only in the redo logs
and/or undo segments. In the case of media failure, where datafiles are com-
pletely lost, the last known good state is usually a restored backup of the affected
files.

Once the last known good state of the database is determined, Oracle can begin
the roll forward phase of recovery. During this phase, any transactions not guar-
anteed to be written to the datafiles are re-enacted in the database. To do this,
Oracle pulls the information for the transactions from either the redo log files for
instance recovery, or from the archive logs for media recovery. As the transac-
tions are processed, they are immediately written to the datafiles by DBWR, and
the SCNs of the target datafiles are updated if necessary.
Once the database has been rolled forward from the last known good state up to
the point of failure, Oracle begins the roll back phase of recovery. During this
phase, any transaction that exists in the redo log that does not have a correspond-
ing COMMIT is considered an uncommitted transaction. As a result of the roll
forward phase, the before images for these transactions should already reside in
the undo segments. Since no COMMIT was found for these transactions, the trans-
actions are rolled back. Once the rollback phase is complete, the database has
been recovered and can be opened for general use.
TASK 2A-3
Identify Instance and Media Recovery Structures
1. Which component of the Oracle database is used as the reference point
to determine whether or not the database needs recovery?
✓ a. Control file
b. Data dictionary
c. Redo logs
d. SYSTEM tablespace datafile
2. Which background process updates the datafiles and control files with
the current system change number (SCN)?
✓ a. CKPT
b. DBWR
c. LGWR
d. SMON

3. True or False? A transaction is considered committed when the changed
datablocks are written to the datafiles. Explain your answer.
False. A transaction is considered committed when the redo information has
been written to the redo logs along with its corresponding COMMIT
statement. This will ensure that the transaction can be recovered after any
type of failure, even if a failure occurs before the DBWR process has a
chance to write the changes to the datafiles.
4. What would be the affect on the database if Oracle did not have a
built-in redo logging mechanism?
Without the built-in redo logging mechanism, there would be no record of
the exact transactions that took place when changes to data are made. If a
serious failure in the system requires the database to be restored from
backup, those transactions would not be available to allow a re-enactment of
the changes. The database could only be recoverable to the point in time
when the last database backup was generated, and any changes that
occurred after that point in time would be lost. The ability to log all transac-
tions someplace outside of the datafiles provides the abilities to apply the
latest changes to the database if the datafiles had to be restored from the
last backup, providing the database with true point-of-failure recoverability.
Topic 2B
Cold Backup and Recovery Concepts
Performing a cold backup is as simple as shutting down the database cleanly and
making a copy of the spfile, control file, datafiles, and redo log files. Once the
copies are done, you simply start the database back up. While this method of
backups requires database downtime, it can be used to create a backup that is
guaranteed to be consistent with absolutely no loss of data or transactions.
Prior to shutting down the database, you would need to know the exact names
Finding Files to Backup and locations of all the files you intend to copy. The V$PARAMETER view pro-
vides the locations of the spfile and control files. The following query can be
used to find this information.
SELECT name, value
FROM v$parameter
WHERE name IN ('control_files','spfile');
While a database may have multiple mirrors of the control file, you only need to
backup one of them, since all the mirrors are identical. There is no harm, how-
ever, in backing up all of them. Control files take up very little space, and if one
backup copy is bad, you would still have others you could use to recover from.
The DBA_DATA_FILES view provides a list of all datafiles in the database. It
also provides the sizes of the datafiles, which can be useful in determining
whether or not the location where you intend to store your backup has sufficient
space. The following query can be used to find the names, locations, and sizes of
your datafiles.
SELECT file_name, bytes/1024/1024 mb
FROM dba_data_files;

The DBA_DATA_FILES can also be very useful for dynamically generating the
copy commands that make up your backup script. You would spool the output to
a file and copy the information into your script. A query similar to the following
can create the copy commands for each of your datafiles.
SELECT ('copy '||file_name||' F:\oracle\cold_bup\wkly')
This query is intended for use on a Windows operating system. It can easily be
modified for other operating systems, such as Unix. The output of this query may
look something like this:
('COPY'||FILE_NAME||'F:\ORACLE\COLD_BUP\WKLY')
--------------------------------------------------
copy D:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\UNDOTBS01.DBF
F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\CWMLITE01.DBF
copy D:\ORACLE\ORADATA\ORA92\DRSYS01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\EXAMPLE01.DBF
copy D:\ORACLE\ORADATA\ORA92\INDX01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\ODM01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\TOOLS01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\USERS01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\XDB01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\RMAN01.DBF F:\oracle\cold_bup\wkly
copy D:\ORACLE\ORADATA\ORA92\OEM01.DBF F:\oracle\cold_bup\wkly
The V$LOGFILE view provides the names and locations of all log file members
of all redo log groups. For a cold backup, all log file members should be
included in the backup. The following query can be used to determine the loca-
tion of the redo log files.
SELECT member
FROM v$logfile;
Just as with the DBA_DATA_FILES view, a dynamic SQL query can be used
with V$LOGFILE to dynamically create the copy commands for your backup
script. The following query will do just that.
SELECT ('copy '||member||' F:\oracle\cold_bup\wkly')
FROM v$logfile;
TASK 2B-1
Performing a Cold Database Backup
Objective: To perform a full, cold backup of the database.
1. Before backing up the database, you should identify the files that should be
included in your backup set. The backup set should include the spfile, con-
trol file, datafiles, and redo log files. The names and locations for these files
are found in the V$PARAMETER, DBA_DATA_FILES, and V$LOGFILE
data dictionary view. You will query these views to identify which files
should be backed up.
From the desktop, launch SQL*Plus from the Start menu.

In the Log On dialog box, type sys for User Name, ora92 for Password,
and ora92 as sysdba for Host String. Click OK.
2. You will first query the V$PARAMETER view. This view will give you the
locations of the spfile and control files.
First, format the output of your query by typing the following com-
mands at the SQL*Plus prompt. Press Enter after each command.
COLUMN name FORMAT a15
COLUMN value FORMAT a50
At the prompt, issue the following query:

SELECT name, value
FROM v$parameter
WHERE name IN ('control_files','spfile');
The results of your query will show you the names and locations of the
spfile and control files for your database.
For the spfile name and location, %ORACLE_HOME% is the environment

variable for the location of your Oracle Home directory, and is currently set
to D:\oracle\ora92. The %ORACLE_SID% is the environment variable for
the system identifier (SID) for your database and is currently set to ora92.
Therefore, the name and location of your spfile is D:\oracle\ora92\database\
spfileora92.ora.
The control_files parameter shows that all three of your control files are
located in the D:\oracle\oradata\ora92 folder.
3. You will now query the DBA_DATA_FILES view to determine the names
and locations of all the datafiles that currently exist for your database.
First, format the output of your query with the following command:
COLUMN file_name FORMAT a50

Issue the following query:
SELECT file_name
The output will show the names and locations of all the datafiles in your
database. You will see that all your datafiles are currently stored in the
D:\oracle\oradata\ora92 folder.
4. You will now query the V$LOGFILE view to determine the names and loca-
tions of your redo log files.
First, format the output of your query with the following command:
COLUMN member FORMAT a50

SELECT member
FROM v$logfile;
The output will show the names and locations of the redo logs for your
database. Like your datafiles, all of your redo logs are currently stored in the
D:\oracle\oradata\ora92 folder.
5. Before taking a cold backup of the database, you must first shut it down.
At the SQL*Plus prompt, type shutdown immediate; and press Enter.

After a few moments, the output will state that the database was closed, dis-
mounted, and the instance shut down.
6. Now that you have identified the names and locations of all the files you
need to backup, you will need to identify the location where you will copy
the files to.
Leaving the SQL*Plus window open, choose Start→Run. In the Run text
box, type D:\oracle and click OK. A window for the D:\oracle folder will
appear.
Choose File→New→Folder. Name the new folder cold_bup
7. You will first create a backup of the spfile.
From the D:\oracle folder, double-click the ora92 folder. The window will
change to show the contents of the ora92 folder.
Double-click the database folder. You will see a list of files. Select
SPFILEORA92.ORA. Choose Edit→Copy.
Press Backspace to move back to the ora92 folder. Press Backspace

again to move back to the D:\oracle folder.
Double-click the cold_bup folder to open it.
Choose Edit→Paste.

You will see a copy of your SPFILEORA92.ORA file appear in the cold_bup
folder.
8. You will now create backups of all your control files, datafiles, and redo log
files.
From the cold_bup folder, press Backspace to move back to the D:\oracle
folder.
Double-click the oradata folder. Double-click the ora92 folder.
You will see a list of the control files, datafiles, and redo log files for your
database.
Choose Edit→Select All. All the files in the ora92 folder will be
highlighted.
Choose Edit→Copy.
Press Backspace twice to move back to the D:\oracle folder.
Double-click the cold_bup folder to open it.

Choose Edit→Paste.
A progress meter will appear while the files are copied. It will take a few
minutes to copy all of the files to the backup destination.
Once the file copies are finished, the backup is complete. Close the cold_
bup window.
9. You will now start up the database.
At the SQL*Plus prompt, type startup and press Enter.
After a few moments, the output will show that the instance was started, and
the database was mounted and opened.
10. Type exit and press Enter to close the SQL*Plus window.
Cold Recovery Concepts

When recovering the database from a cold backup, it’s important to remember
that you must restore all files from the cold backup, including the control files
and redo log files, and not just the one or two files that you lost due to media
failure. The current files can be discarded, and the backed up copies are put in
their places. It is recommended that you restore the spfile, even if the original
was not lost. This is because the current spfile may contain parameter assign-
ments that have been changed since the last backup. If the current spfile is used
with the backup copy of the database, the database may not start up correctly, and
if it does, it may not perform as expected. If you can confidently say that no
parameters have changed since the last backup, then you can decide whether or
not you need to restore the spfile.
The DBVerify Utility

Oracle provides a useful utility, called DBVerify, that can be used to determine
whether or not datafiles contain any block corruptions. This command-line utility
can be run against any datafile, regardless if the datafile is currently part of a live
database or if it is just a backup copy of a live datafile. DBVerify scans a datafile

for any corruption, and reports on its findings, which is displayed on the screen,
and can optionally be sent to a log file. You can instruct the utility to scan an
entire datafile or just a portion of the file by specifying starting and ending
datablock numbers. You can even instruct the utility to scan a single segment in
the database.
To use the DBVerify utility, you would run its executable (dbv) from the com-
mand line and pass arguments that specify the name of the datafile you want to
scan, the optional starting and ending datablocks, and the path and file name of
the optional log file. If you do not include starting and ending datablocks,
DBVerify will automatically scan the entire datafile. The arguments that can be
passed to DBVerify are shown in the following table.
Argument Purpose
file The path and file name of the datafile to verify.
start The datablock number to start scanning from. If omitted, DBVerify will start
at the first datablock in the file.
end The datablock number at which to stop scanning. If omitted, DBVerify will
stop after the last datablock in the file.
blocksize The size in bytes of the datablocks in the datafile. The default value is
2048.
logfile The path and file name of the log file to generate. If omitted, no log file
will be generated.
feedback Instructs DBVerify to output a period (.) to the screen for each datablock
verified. The default is 0, which means no feedback is displayed.
parfile Specifies an optional parameter file that contains additional arguments.
userid User name and password of the database user to use when logging into
the target database if you are scanning a segment specified by the
segment_id argument.
segment_id Specifies the segment to scan.
The following example shows DBVerify scanning a datafile for corruption:

C:\>dbv file=d:\oracle\oradata\ora92\users01.dbf blocksize=8192
DBVERIFY: Release 9.2.0.1.0 - Production on Sun Sep 7 20:01:42

2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights

reserved.
DBVERIFY - Verification starting : FILE =

d:\oracle\oradata\ora92\users01.dbf
DBVERIFY - Verification complete
Total Pages Examined : 3200

Total Pages Processed (Data) : 457

Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Processed (Other): 57
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2686
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
C:\>
If any corruption in the file is found, the output would show the number of
blocks data or index blocks that were corrupted. To scan a specific segment in the
database, you would use the following syntax:
dbv userid=username/pwd segment_id=tsn.segfile.segblock
In this syntax, username/pwd specifies the database user and password to log
in to the database with. If you are scanning a specific segment, you must execute
DBVerify from the same machine where the database resides. Therefore, you can-
not specify a connect string for a remote database.
For the segment_id argument, tsn represents the tablespace number,
segfile represents the target file number, and segblock represents the block
number where the header of target segment resides. The values you need to
specify can be determined by querying the appropriate data dictionary views for
the segment in question, such as DBA_TABLES and DBA_SEGMENTS. The
following example shows DBVerify scanning a single segment:
C:\>dbv userid=system/ora92 segment_id=5.5.5897
DBVERIFY: Release 9.2.0.1.0 - Production on Sun Sep 7 20:23:00

2003

reserved.
DBVERIFY - Verification starting : SEGMENT_ID = 5.5.5897
DBVERIFY - Verification complete
Total Pages Examined : 11

Total Pages Processed (Data) : 10
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Processed (Other): 0
Total Pages Processed (Seg) : 1
Total Pages Failing (Seg) : 0
Total Pages Empty : 0
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
C:\>
In this example, a single segment that resides at block number 5897 in datafile 5
of tablespace 5 was scanned for corruption.

The DBVerify utility is extremely useful in determining whether or not the
backup copies of your datafiles are valid. After performing a user-managed
backup of the database, it is recommended that you use DBVerify to scan the
backup copies of all the datafiles to ensure that the copies are valid. If a file is
corrupt, it would be better to know immediately rather than when you restore the
corrupted backup copies after media failure.
TASK 2B-2
Perform a Cold Database Recovery
Objective: To perform a cold recovery of the database using the latest
full, cold backup set.
1. Before performing a cold recovery, you will first simulate disk failure on the
disk where the control files, datafiles, and redo log files reside.
From the desktop, launch SQL*Plus from the Start menu.
2. At the SQL*Plus prompt, type shutdown immediate; and press Enter.
After a few moments, the output will state that the database was closed, dis-
mounted, and the instance shut down.
3. Leaving the SQL*Plus window open, choose Start→Run. In the Run text
box, type D:\oracle\oradata\ora92 and click OK.

A window for the D:\oracle\oradata\ora92 window will open.
4. Choose Edit→Select All. All the files in the window will be selected.
Press Shift+Delete. A question box will appear asking if you are sure you
want to delete these 17 files. Click Yes. All of your control files, datafiles,
and redo log files will be permanently erased from the disk. This simulates
complete disk failure.
5. Switch back to the SQL*Plus window.
After a few moments, you will see the instance start, but a message will

appear stating that Oracle could not identify the control file. The alert log
will contain more information.
6. Choose Start→Run. In the Run text box, type D:\oracle\admin\ora92\

bdump and click OK.
A window for the D:\oracle\admin\ora92\bdump folder will appear.

Some trace files besides the
alert log may exist in the
D:\oracle\admin\ora92\bdump
directory. This is normal.
Double-click the alert_ora92.log file. The alert log will open in a Notepad
window. Scroll to the bottom of the file.
The last several lines in the alert log shows the reason why the database
could not be mounted. The operating system could not find CONTROL01.
CTL file in the D:\oracle\oradata\ora92 directory. Upon further investigation,
you realize that the entire disk where that control file resides has crashed.
Close the alert_ora92.log file.
7. A new disk has been installed, and you will now restore all the necessary
files from your last cold backup. Before doing so, you must first shut down
the instance.
At the SQL*Plus prompt, type shutdown immediate; and press Enter. After
a moment, the output will show that the instance was shut down.
box, type D:\oracle\cold_bup and click OK. A window for the cold_bup
folder will appear.
Select SPFILEORA92.ORA. Choose Edit→Invert Selection. All files

except the SPFILEORA92.ORA file will be selected.
Choose Edit→Copy.
Press Backspace to move back to the D:\oracle folder.
Double-click the oradata folder to open it. In the oradata folder, double-
click ora92 folder to open it.
Choose Edit→Paste. A progress meter will appear while the files are

restored. It will take a few minutes to complete the copies.
Once the copies are complete, close the ora92 window.
9. At the SQL*Plus prompt, type startup and press Enter.
After a few moments, you will see the instance start, and the database mount
and open. You have successfully performed a cold recovery of the database
from the last cold backup.
10. Type exit and press Enter to close the SQL*Plus window.
Topic 2C
Hot Backup and Recovery Concepts
While hot backups are more complicated than cold backups, the ability to back
up the database while it remains up and running provides much more power and
flexibility. With hot backups, you can back up either the entire database or a
single tablespace at a time. This allows you to spread your backups over a longer
period of time, which can be very handy if your database is very large. Addition-
ally, you have the ability to restore just a single tablespace, or even a single

datafile, in the event of a media failure, instead of having to restore the entire
database, which can drastically reduce the MTTR for your database. Most impor-
tantly, hot backups provide the ability to restore the database right up to the point
of failure, with little or no loss of critical data.
To perform hot backups, the database must be running in ARCHIVELOG mode.
When the database is in ARCHIVELOG mode, the redo logs are copied by the
archiver process to an archive destination. If media failure causes the loss of one
or more datafiles, you can restore just those datafiles from the last hot backup,
and then apply the changes stored in the archive logs to the datafiles to bring
them up to date with the rest of the database.
To configure the database in ARCHIVELOG mode, you must first tell Oracle
where to send the archive logs, and what format to use for the archive log file
names. The LOG_ARCHIVE_DEST initialization parameter specifies the archive
log destination, and the LOG_ARCHIVE_FORMAT parameter specifies the file
name format.
The LOG_ARCHIVE_DEST parameter can be set to any valid file system
Environment variables in directory. The value assigned to this parameter can include OS-level environment
Windows are surrounded by variables, as long as the translated string of characters resolves to a directory on
percent signs (%), while the file system that Oracle can find and write to. If this parameter is not set, the
environment variables in archive logs will be written to an OS-dependent default location. It is recom-
Unix are preceded by a mended, however, that you set this parameter explicitly to ensure that you have
dollar sign ($).
complete control over where the files are written to. You can use the ALTER
SYSTEM command to set this parameter for the current instance, in the spfile for
future restarts, or both. The following is an example of the ALTER SYSTEM
command to set the LOG_ARCHIVE_DEST parameter for both the current
instance and future restarts:
ALTER SYSTEM SET log_archive_dest='%ORACLE_BASE%\oradata\archive'
SCOPE=BOTH;
In this example, the LOG_ARCHIVE_DEST parameter is set to the oradata\
archive subdirectory under the directory specified by the %ORACLE_BASE%
environment variable, which is set at the OS level. If the %ORACLE_BASE%
parameter is set to D:\oracle, then the archive log destination will become
D:\oracle\oradata\archive.
Optionally, you can configure multiple archive log destinations. To configure mul-
tiple archive log destinations, you would not use the LOG_ARCHIVE_DEST
parameter, but instead use a series of LOG_ARCHIVE_DEST_n parameters,
where n is a sequential number to uniquely identify each archive destination.
Oracle can support up to 10 archive log destinations, each with its own archiver
process. To configure two archive log destinations, you would configure the
LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2 parameters, as shown
in the following example:
ALTER SYSTEM set log_archive_dest_1 =
'location=D:\oracle\oradata\archive\' SCOPE = BOTH;
ALTER SYSTEM set log_archive_dest_2 =
'location=E:\oracle\oradata\archive\' SCOPE = BOTH;
Notice that the first archive destination is set to the D drive, while the second
destination is set to the E drive. Also, the syntax for this parameter is slightly
different than the LOG_ARCHIVE_DEST parameter. For any of the LOG_
ARCHIVE_DEST_n parameters, you must include the keyword LOCATION to
specify the path where archive logs will be sent. Additionally, the LOG_

ARCHIVE_DEST parameter must be set to null if any of the LOG_ARCHIVE_
DEST_n parameters are set. For example, you cannot set both LOG_ARCHIVE_
DEST and LOG_ARCHIVE_DEST_2. If you want multiple archive destinations,
you must use only the LOG_ARCHIVE_DEST_n parameters.
For each archive destination that is configured, Oracle will automatically spawn a
new archiver process, up to the maximum number of archiver processes specified
by the LOG_ARCHIVE_MAX_PROCESSES parameter. For example, if you
configure five archive log destinations, and you have specified five or more for
the LOG_ARCHIVE_MAX_PROCESSES parameter, Oracle will spawn exactly
five archivers. However, if you only specify two for the LOG_ARCHIVE_MAX_
PROCESSES, Oracle will only spawn two archivers, regardless of the number of
archive destinations you have configured. If less archive processes are spawned
than there are archive destinations configured, Oracle will attempt to double up
the workload on some of the archivers. For performance reasons, you should set
LOG_ARCHIVE_PROCESSES to at least the number of archive destinations you
have configured.
The LOG_ARCHIVE_FORMAT parameter is used to specify the file name for-
mat for the archive logs. This parameter uses variables to ensure that each LOG_ARCHIVE_FORMAT
archive log has a unique name to avoid overwriting existing archive logs. The Pattern Variables
following table lists the four pattern variables and their usage.
Pattern Variable Usage

%s The log sequence number of the redo log that the archive log was generated
from.
%S The same as %s, but fixed length and left-padded with zeros. The fixed length
is OS dependent.
%t The thread number. Will always have a value of 1, except when the instance is
part of a Real Application Cluster (RAC) configuration.
%T The same as %t, but fixed length and left-padded with zeros. The fixed length is
OS dependent.
The LOG_ARCHIVE_FORMAT parameter can be set only in the spfile and can
be assigned any combination of four pattern variables plus any additional envi-
ronment variables or literal characters you wish to include. For example, the
following is an ALTER SYSTEM command to set the LOG_ARCHIVE_
FORMAT parameter using the %S pattern variable and the $ORACLE_SID
environment variable in a Unix environment.
ALTER SYSTEM SET log_archive_format='log_$ORACLE_SID_%S.arc'
SCOPE=SPFILE;
In this example, if the $ORACLE_SID variable was set to ora92, and the log
sequence number of the redo log being archived was 17, the name of the archive
log to be generated would be log_ora92_00017.arc. Including the $ORACLE_SID
environment variable can be useful to identify exactly which database a list of
archive logs came from. This can be handy if you have several databases
archiving their log files to the same or similar directory structure. The default
LOG_ARCHIVE_FORMAT parameter is OS dependent.
Another parameter which can be set is the LOG_ARCHIVE_START parameter.
This parameter accepts only the values TRUE or FALSE and is optional, but it is
highly recommended that you set it. If this LOG_ARCHIVE_START is left set to
its default of FALSE, the archiver process will only archive the redo logs when
told to do so by the ALTER SYSTEM ARCHIVE LOG ALL command. This

means that the DBA must constantly monitor the database and manually archive
the redo logs with the ALTER SYSTEM ARCHIVELOG ALL command when it
becomes necessary to do so. If Oracle does not archive the logs, then it cannot
perform the log switch, and the database will completely freeze up until it can. If
this parameter is set to TRUE, then the archiver process will automatically archive
redo logs as they are switched out. This parameter can only be set for future
restarts in the spfile.
Just setting the LOG_ARCHIVE_DEST, LOG_ARCHIVE_FORMAT, and LOG_
ARCHIVE_START parameters does not yet mean the database is in
ARCHIVELOG mode. To determine whether or not the database is in archive log
mode, you can issue the command ARCHIVE LOG LIST from the SQL*Plus
prompt. To use this command, you must log in to the database as either SYS or
another user that has SYSDBA privileges. The output of this command indicates
whether the database is in ARCHIVELOG or NOARCHIVELOG mode, whether
or not the automatic archiving is enabled, and the log archive destination. It also
shows the log sequence numbers of the current log group, the next log group to
be archived, and the oldest log sequence number from all log groups. Figure 2-6
shows the output of the ARCHIVE LOG LIST command for a database that has
the appropriate parameters set, but is still in NOARCHIVELOG mode.
Figure 2-6: The output from the ARCHIVE LOG LIST command.
After setting the appropriate parameters, you can then enable ARCHIVELOG
mode. First, the database must be shut down cleanly, meaning that the instance
must not have been aborted either through instance failure or the SHUTDOWN
ABORT command. The database must then be started up using the STARTUP
MOUNT command. Once in the mount mode, you would enable archive logging
by issuing the ALTER DATABASE ARCHIVELOG command. Once this com-
mand is executed, you can open the database for general use. It is recommended
that once you enable ARCHIVELOG mode that you manually switch the redo
logs a few times to ensure that the logs are archiving, and that they are being
archived to the correct location. The following sample output shows the sequence
of events to enable ARCHIVELOG mode for a database.

SQL> connect sys/ora92 as sysdba
Connected.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination D:\oracle\oradata\archive
Oldest online log sequence 37
Current log sequence 39
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 135338868 bytes

Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> archive log list

Database log mode Archive Mode
Automatic archival Enabled
Archive destination D:\oracle\oradata\archive
Oldest online log sequence 37
Next log sequence to archive 39
Current log sequence 39
SQL>
Once the database is in ARCHIVELOG mode, you can begin performing hot
backups. Upon opening the database, Oracle will spawn the ARCH process to
handle copying the redo logs to the archive destination specified by the LOG_
ARCHIVE_DEST or LOG_ARCHIVE_DEST_n parameters as they are filled and
switched out. The archive logs will be named using the naming pattern specified
by the LOG_ARCHIVE_FORMAT parameter. If the LOG_ARCHIVE_START
parameter is set, Oracle will automatically archive the redo logs without requiring
intervention from the DBA.

TASK 2C-1
Configuring Archivelog Mode
Objective: To configure the database in archivelog mode to enable the
ability to perform hot backups.
1. From the desktop, launch SQL*Plus from the Start menu.
2. Before changing the configuration of the database, you should determine the
current configuration.
At the SQL*Plus prompt, type ARCHIVE LOG LIST; and press Enter.
The output will show that the database is currently in No Archive Mode.
The log sequence numbers Currently, hot backups cannot be performed for this database.
for your system may be
slightly different than what is
shown here.
3. You will now modify the appropriate initialization parameters to configure

the database to support archive log mode. These parameters include LOG_
ARCHIVE_DEST and LOG_ARCHIVE_START. You will leave LOG_
The double right arrow (⇒) ARCHIVE_FORMAT at its default setting. At the prompt, issue the
indicates that the command following commands.
is intended to be typed on a
single line. ALTER SYSTEM SET log_archive_dest= ⇒
'D:\oracle\ora92\database\archive' ⇒
SCOPE=spfile;
ALTER SYSTEM SET log_archive_start=TRUE SCOPE=spfile;

Oracle will respond with the message “System Altered” after each command.
4. You must now restart the database to have these changes take affect.
At the prompt, type shutdown immediate; and press Enter.
After a moment, the output will show that the database has been closed and
dismounted, and the instance shut down.
5. You must bring the database up to the mount stage to enable ARCHIVELOG
mode.
At the prompt, type startup mount and press Enter.
After a moment, you will see that the instance is started and the database is
mounted.
6. To enable ARCHIVELOG mode, type ALTER DATABASE

ARCHIVELOG; and press Enter.
Oracle will display the message “Database altered.”
7. You can now open the database for general use.
At the prompt, type ALTER DATABASE OPEN; and press Enter.

After a moment, Oracle will display the message “Database altered.”
8. To verify that the database is indeed in ARCHIVELOG mode with automatic

archiving enabled, type ARCHIVE LOG LIST; and press Enter.
The output will show you that the database is in ARCHIVELOG mode, that
automatic archiving is enabled, and that full redo logs will be archived to the
D:\oracle\ora92\database\archive folder.
9. To verify that your settings are correct, you will force a log switch. This will
cause the archiver process to copy the current online redo log to the archive
log destination.
At the prompt, type ALTER SYSTEM SWITCH LOGFILE; and press

Enter.
Oracle will display the message “System altered.”
box, type D:\oracle\ora92\database\archive and click OK. A window for
the D:\oracle\ora92\database\archive folder will open.
You will see a single archive log file. This shows that you have indeed con-
figured the database in ARCHIVELOG mode with the proper settings. Hot

backups can now be performed for this database.
Close the archive window.
11. At the SQL*Plus prompt, type exit and press Enter to close SQL*Plus.
Hot Recovery Concepts

One of the most important aspects of database recovery is recognizing when
recovery is necessary. Many times a media failure will be discovered by a user
while simply attempting to access data in a datafile that has become corrupted or
no longer exists. Other times, such as when one or more datafiles of the SYS-
TEM tablespace experience a failure, the instance will just crash. You must
remember that the mean time to recovery refers to the amount of time it takes to
recover the database after a failure and not the discovery of the failure. It is
entirely possible for media failure to occur and go unnoticed for hours or days.
Of course, if no users try to access a file that has suffered media failure, then no
users have been affected by the failure. However, if a user discovers media failure
before the DBA does, it is essentially too late.
One of the most important files that the DBA should be monitoring on a regular
basis is the alert log, which is located in the directory specified by the
BACKGROUND_DUMP_DEST parameter. Oracle writes a steady stream of
information to this file, which includes entries for database startups and shut-
downs, major ALTER SYSTEM and ALTER DATABASE commands, and any
internal errors or media issues the database encounters. If media failure were to
occur, Oracle would immediately write entries concerning the failure to the alert
log.
Depending on the failure and its related errors, Oracle may also write to the alert
log for the paths and file names of any additional traces files that may have been
generated. These trace files usually include more detailed information about errors
than what is included in the alert log. Some background process may also gener-
ate trace files. If a required background process fails, the instance will crash, and
the background process will generate a trace file that includes the related errors

that caused the process to fail. In some cases, media failure might cause the
instance to crash, while in other cases, instance failure might cause a datafile to
become corrupted due to DBWR partially writing datablocks at the moment of
failure. Either way, the alert log and trace files are a great place to start monitor-
ing for and researching media failure.
If the instance is still up and running after media failure, another place you can
The V$RECOVER_FILE look to determine which files need recovery is the data dictionary. The
Columns V$RECOVER_FILE view lists all datafiles that need recovery and why. The fol-
lowing table lists the columns of this view and their descriptions.
Column Description
FILE# File ID number.
ONLINE Left over from previous versions of Oracle and is obsolete. Will
always show the same value as ONLINE_STATUS column.
ONLINE_STATUS Online status of the datafile.
ERROR Reason why the datafile needs recovery. Will be null if the reason is
unknown.
CHANGE# SCN where recovery must start.
TIME Time of the starting recovery SCN.
The most important column of this view is the ERROR column, which tells you
exactly why the file needs recovery. For example, if this column shows the value
'FILE NOT FOUND', then either the file was accidentally deleted from the file
system, or the entire disk where the file resides has gone offline or crashed. The
FILE# column lists only the ID number of each datafile that needs recovery. You
can use the file ID to look up the actual path and name of the file in the
V$DATAFILE view. The file ID also resides in the DBA_DATA_FILES view, but
this view is only available while the database is open; the V$DATAFILE view is
available when the database is in the mounted state.
Once you have determine why a datafile needs recovery, you can decide what
steps to take next. If the datafile exists but is simply offline due to other errors,
then you can simply begin the recovery process to bring the file up to date with
the rest of the database, and then bring the datafile or tablespace online. If the file
is completely missing, then you must first restore it from a hot backup before
initiating recovery. If the entire disk where the file resides is damaged or unus-
able, then you must restore the datafile to a different location.
Once the datafiles in question are in place, you can begin the recovery process
with the RECOVER command. You can perform the recovery at the datafile,
tablespace, or database levels. If you issue the RECOVER DATAFILE command,
only the specified datafile will be recovered, while RECOVER TABLESPACE
command will recover all datafiles that make up the specified tablespace. If you
issue the RECOVER DATABASE command, all datafiles in the database that need
recovery will be recovered. In most cases, using the RECOVER DATABASE com-
mand is easiest for a large database since it will cause Oracle to automatically
recover all datafiles that need recovery without having to list each datafile or
tablespace separately.
During the recovery process, Oracle will compare the SCN in the control file
with the SCNs in the datafiles being recovered. If any datafile SCNs are lower
than what is shown in the control file, then Oracle will determine where the redo
information necessary for recovery resides, either in the current online redo log or
an archived log. If the redo information resides in the current online redo log,

Oracle will automatically apply the changes without requiring interaction with the
DBA. If the redo information has already been archived, Oracle will use the
CHANGE# column of the V$RECOVER_FILE view along with the
V$ARCHIVED_LOG view to determine which archive log contains the change,
and then prompt the DBA for the path and location of that log. As a convenience,
Oracle will suggest the name and location of the archive log’s last known
location. If the file still resides there, the DBA can accept the suggestion and
apply that archive log. If the file has been moved to another location, then the file
must either be restored to its original location or the DBA must specify the
archive log’s current location.
Oracle begins the roll forward phase of recovery by applying the changes from
the redo information to the target datafiles. After each change is applied, Oracle
will compare the datafile’s SCNs with what is listed in the control file. If all
changes in the current archive log have been applied but the datafile still needs
recovery, Oracle will prompt for the next archive log in the sequence. This pro-
cess repeats until all available redo information has been applied to the affected
datafiles. When the SCNs of the datafiles match that of the control files, and only
then, will Oracle consider the datafiles recovered. Once the roll forward phase is
complete, Oracle will perform the rollback phase by rolling back all recovered
transactions that were executed just prior to the media failure but not yet commit-
ted when the failure occurred. Since those transactions were not committed, any
changes from those transactions will be lost.
Hot Recovery Restrictions

There are two very important rules for hot recovery that you must remember. The
first rule is that you can only perform a complete recovery when performing a hot
recovery of the database, regardless of at which level it is performed. The entire
database must be in a consistent state, meaning all datafile headers must show the
same SCN that is shown in the control file. You cannot recover a datafile or
tablespace to a different point in time than the rest of the database. If you attempt
to bring a tablespace online after performing an incomplete recovery (by not
applying all the redo or archive logs), then Oracle will return an error. The
tablespace or datafile cannot be brought back online until it is completely
recovered.
The second rule refers to the situations in which hot recoveries can be performed.
The database can remain open in most hot recovery scenarios, but the SYSTEM
tablespace must always be online. If something were to happen to cause the SYS-
TEM tablespace to come offline, such as media failure where the SYSTEM
datafiles reside, the instance would immediately crash. As such, it is impossible to
perform a hot recovery for the datafiles of the SYSTEM tablespace. You will
need to restore the datafile from backup if they are missing, then start up the
database and bring it to the mount state. Only then can you perform a recovery of
the SYSTEM tablespace.

TASK 2C-2
Describe Hot Database Recovery
1. Where could the DBA look to determine which files have been affected
by media failure? Choose all that apply.
✓ a. Alert log
b. Core dump file
✓ c. Trace files
✓ d. V$RECOVER_FILE
2. True or False? It is possible to perform a recovery of the SYSTEM

tablespace while the database is up and running. Explain your answer.
False. If the SYSTEM tablespace requires recovery, then the database must
be down and cannot be opened until the tablespace is recovered.
3. A user issues an UPDATE statement to change the values in the EMP

table that resides in the USERS tablespace. While the statement was
running, the disks that hold the datafiles for the USERS tablespace
failed. Once the USERS datafiles are restored, you begin a recovery of
the tablespace. Upon completion of the recovery, what has become of the
changes made by the UPDATE statement?
During recovery, Oracle will apply all changes found in the redo log or
archive logs to the datafiles being recovered. At the end of the recovery,
Oracle will determine that there is no COMMIT statement associated with
the changes and will, therefore, rollback the transaction.
Summary
In this lesson, you learned about the types of failures that may occur in an
Oracle9i database and the features provided to resolve them. You also
learned how to create a cold backup of the database and how to use that
backup to restore the database after a failure. Finally, you learned about the
mechanisms in place to back up and recover an Oracle9i database with
minimal data loss.

Lesson Review
2A Which database component plays the biggest role in handling transac-
tion failure?
a. Database buffer cache
b. Log writer
c. Redo log buffer
✓ d. Undo segment
What advantages does performing hot backups have over performing

cold backups?
Cold backups require that the database be shut down during the backup pro-
cess while hot backups allow the database to be up and running.
Additionally, you have the capability of backing up only a tablespace at a
time, which allows you to spread out the backups across multiple sessions if
the database is very large. With cold backups, any media failure requires
that you restore the entire backup, while a hot backup only requires that the
missing files be restored. Also, after a database is recovered from a cold
backup, the contents of the database will look exactly as it did when the
backup was performed, while a hot backup can recover the database right
up to the point of failure.
Each redo log group in your database consists of two redo log file
members. What will happen if media failure causes the loss of one log
file member of one log file group?
In this scenario, the Oracle database will stay up an running. Since each log
file member in a single group contains the same information, Oracle will be
able to keep generating changes and switching redo logs as long as at least
one redo log member is available in each group. The primary purpose of
multiplexing the redo log files is to ensure the database is durable enough to
withstand losing a single log file member without crashing.
2B Which data dictionary views could you use to determine the names and
locations of the files that you need to back up as part of a full, cold
database backup? Choose all that apply.
✓ a. DBA_DATA_FILES
b. DBA_TABLESPACES
✓ c. V$PARAMETER
✓ d. V$LOGFILE
True or False? When restoring the database from a cold backup, you
must restore only the files that were lost due to media failure. Explain
your answer.
False. You must restore all files from the cold backup, including the control
files and redo log files, not just the files that were lost due to media failure.

2C You have properly set the LOG_ARCHIVE_DEST and LOG_
ARCHIVE_FORMAT initialization parameters, and you have properly
enabled ARCHIVELOG mode while the database was in MOUNT state,
but Oracle is not archiving any redo logs. In fact, the database is com-
pletely frozen. Why?
Even though ARCHIVELOG mode has been set and a valid path and file
name pattern has been specified for the archive logs, Oracle will not auto-
matically archive the redo logs unless the LOG_ARCHIVE_START
parameter is set to TRUE. If Oracle cannot archive the filled redo logs, it
cannot perform a log switch, and the database will freeze up until it can.
The DBA must either manually archive the redo logs with the ALTER
DATABASE ARCHIVELOG ALL command or set the LOG_ARCHIVE_
START parameter to TRUE and restart the instance.
What is the most important column of the V$RECOVER_FILE view?

✓ a. ERROR
b. FAILURE_REASON
c. ONLINE_STATUS
d. TIME

User-managed Backup and LESSON
Recovery
3
Data Files
bup_status.sql
Overview get_trace.sql
User-managed backup and recovery of the Oracle database involves manu- hot_backup_database.
ally performing all the steps required to create a valid database backup, as sql
well as all the steps to perform a recovery in the event of media failure. restore_database.sql
Earlier in the course, you learned that performing a cold backup simply logfiles.sql
involves making copies of all necessary Oracle files while the database is
Lesson Time
shut down. Since cold backups are fairly straight-forward, this lesson will
focus on performing hot backups and recoveries. In this lesson, you will 6 hours, 30 minutes
learn how to perform backups of the tablespaces and control file, and how
to perform both complete and incomplete recoveries under various media
failure scenarios. Finally, you will learn about the special backup and recov-
ery considerations for read-only tablespaces and also how to recover the
database if the instance crashes while a hot backup is running.
Objectives
To perform user-managed backups and recoveries of the database, you will:
3A Perform user-managed hot backups of the database.

A user-managed full database backup consists of manually backing up all
critical database files, including the control file, spfile, password file, and
the datafiles of all the tablespaces. In this topic, you will learn the steps
necessary to manually perform a full database backup. You will also learn
how to recover the database in the event of instance failure while a data-
base backup is running.
3B Perform a complete recovery of the database after a failure.

There are two types of recovery, complete and incomplete. During a com-
plete recovery, the database is recovered up to the point in time when the
media failure occurred, which guarantees that there will be no loss of
changes to the data. In this topic, you will learn how to perform a com-
plete recovery.
3C Perform incomplete recoveries of the database to recover from vari-

ous failure scenarios.
During an incomplete recovery, the database is recovered to a point in
time prior to the point in failure, which usually results in the loss of
changes to the data. An incomplete recovery may be required under cer-
tain circumstances, or it can be performed intentionally for a specific
purpose. In this topic, you will learn how to perform incomplete recover-
ies and when you would need to perform one.
Lesson 3: User-managed Backup and Recovery 141
Topic 3A
User-managed Backups
A database backup set includes the control file, spfile, password file, and the
datafiles of all the tablespaces. The spfile and password file can both be backed
up any time using OS-level commands, even if the database is up and running.
You will learn how to back up the control file later in this topic. This section will
focus on backing up the datafiles that make up the Oracle tablespaces.
To perform a backup of the database manually, you would back up each
ALTER TABLESPACE Syntax tablespace individually, first placing each one into backup mode and then copying
their datafiles using OS-level commands. Once the datafiles are copied, you
would take the tablespaces out of backup mode. The ALTER TABLESPACE
command is used to place a tablespace in or out of backup mode, as shown in the
backup mode: following syntax:
A special mode for
ALTER TABLESPACE tablespace_name [BEGIN|END] BACKUP;
tablespaces that allows them
to be copied while the The database must be configured in ARCHIVELOG mode to place tablespaces
database is up and running. into hot backup mode. If the database is running in NOARCHIVELOG mode,
and you issue the ALTER SYSTEM command to place a tablespace in hot backup
mode, Oracle will return an error.
Since the backups are performed at the tablespace level, you can schedule the
tablespace backups in a round-robin fashion, backing up one tablespace at a time.
You would place a tablespace in backup mode, copy its datafiles, and then take it
out of backup mode, repeating the process for each tablespace sequentially. This
can be especially handy if your database is so large that you cannot back up all
the datafiles during a single scheduled maintenance window. You can perform
backups of one or two tablespaces a night, and perhaps over a period of one
week, the entire database would be backed up.
Once a tablespace is in hot backup mode, you would copy the tablespace’s
datafiles using OS-level commands. The following example script can be run
from the SQL*Plus prompt to perform a user-managed hot backup of the
tablespaces.
connect sys as sysdba
ALTER TABLESPACE SYSTEM BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF f:\dbbackup
ALTER TABLESPACE SYSTEM END BACKUP;
ALTER TABLESPACE UNDOTBS1 BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\UNDOTBS01.DBF f:\dbbackup
ALTER TABLESPACE UNDOTBS1 END BACKUP;
ALTER TABLESPACE EXAMPLE BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\EXAMPLE01.DBF f:\dbbackup
ALTER TABLESPACE EXAMPLE END BACKUP;
ALTER TABLESPACE INDX BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\INDX01.DBF f:\dbbackup

ALTER TABLESPACE INDX END BACKUP;
ALTER TABLESPACE TOOLS BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\TOOLS01.DBF f:\dbbackup
ALTER TABLESPACE TOOLS END BACKUP;
ALTER TABLESPACE USERS BEGIN BACKUP;

host copy D:\ORACLE\ORADATA\ORA92\USERS01.DBF f:\dbbackup
ALTER TABLESPACE USERS END BACKUP;
exit
There is one small but very important difference between a tablespace in hot
backup mode and a tablespace not in hot backup mode. While a tablespace is in
hot backup mode, all changes to datablocks that are stored in the tablespace are
still written from the buffer cache to the datafiles by the DBWR process when
checkpoints occur. However, the checkpoints are deferred for tablespaces in hot
backup mode. That is to say that CKPT does not update the headers of the
datafiles of a tablespace while that tablespace is in hot backup mode. The
datafiles will still contain the SCN that was current at the point in time when the
tablespace was placed in hot backup mode. Since the control file tracks the cur-
rent SCN for the entire database, once a tablespace is taken out of hot backup
mode, Oracle simply advances the tablespace’s datafile headers to the latest
checkpoint to bring them up to date with the rest of the database. While the
tablespace is in hot backup mode, its datafiles may be changing while the OS is
copying them, which creates an inconsistent copy of the files. However, this is
easily rectified during Oracle’s recovery mechanisms when the backup datafiles
are restored and recovered.
The V$BACKUP data dictionary view shows which datafiles are currently in hot
backup mode and the SCN and timestamp of the tablespace the last time it was
placed in hot backup mode. The following table shows the columns of the
V$BACKUP view and their descriptions.
Column Description
FILE# The file ID number.
STATUS Current status of the datafile. Values include ACTIVE if the datafile is in hot
backup mode, or NOT ACTIVE if the datafile is not in hot backup mode.
CHANGE# The SCN of the datafile when it was last placed in hot backup mode.
TIME The timestamp of the datafile when it was last placed in hot backup mode.
Since the V$BACKUP view contains only the file number of each datafile, it is
much easier to identify the tablespaces and their datafiles by joining this view
with the V$DATAFILE and V$TABLESPACE views to provide a complete listing
of tablespaces with their datafiles. The following is an example query of these
three views showing the backup status of all the tablespaces and their datafiles.

SELECT
t.name tablespace_name,
f.name file_name,
b.status
FROM
v$backup b,
v$datafile f,
v$tablespace t
WHERE
b.file# = f.file# and
f.ts# = t.ts#;
TASK 3A-1
Hot Backup Tablespaces
Objective: To perform hot backups of the tablespaces.
1. Before beginning the tablespace hot backup, you will create a folder to store
the backed up datafiles.
From the desktop, choose Start→Run. In the Run text box, type D:\oracle
and click OK. A window for the D:\oracle directory will open.
Choose File→New→Folder. Name the new folder hot_bup
2. Leaving the D:\oracle window open, launch SQL*Plus from the Start
menu.
3. Before setting any tablespaces to backup mode, you should determine the
current backup status of the tablespaces.
At the prompt, type edit C:\079176\bup_status.sql and press Enter.
The bup_status.sql script will open. This script queries from the

V$BACKUP, V$DATAFILE, and V$TABLESPACE data dictionary views.
Close the bup_status.sql script.
At the prompt, type @C:\079176\bup_status.sql and press Enter to execute

the script.
The output will show that none of the tablespaces are currently in backup
mode.
4. You will back up the EXAMPLE and SYSTEM tablespaces. At the prompt,
issue the following commands:
ALTER TABLESPACE example BEGIN BACKUP;
ALTER TABLESPACE system BEGIN BACKUP;

After each command, Oracle will display the message “Tablespace altered.”
5. Type @C:\079176\bup_status.sql and press Enter.
You will see that the values in the STATUS column for EXAMPLE and
SYSTEM tablespaces have changed to ACTIVE. You can now begin backing
up the datafiles for these tablespaces.
6. Switch to the D:\oracle folder.
Double-click the oradata folder to open it, and then double-click the
ora92 folder.
Select EXAMPLE01.DBF, and then, while holding the Ctrl button, select
SYSTEM01.DBF as well.

Choose Edit→Copy.
Press Backspace twice to move back to the D:\oracle folder. Double-click

the hot_bup folder to open it.
Choose Edit→Paste to begin copying the datafiles to your hot backup

folder.
A status bar will appear while the files are copied. It will take a few
moments until the copies are complete.
Once the copies are complete, close the hot_bup window.
7. At the SQL*Plus prompt, disable backup mode for the EXAMPLE and
SYSTEM tablespaces with the following commands:
ALTER TABLESPACE example END BACKUP;
ALTER TABLESPACE system END BACKUP;
Oracle will display the message “Tablespace altered” after each command.
8. At the prompt, type @C:\079176\bup_status.sql and press Enter.
The output will show that the EXAMPLE and SYSTEM tablespaces are no
longer in backup mode.
9. At the prompt, type exit and press Enter.

Backing Up the Control File
As you learned earlier, the control file contains information about the database
critical to its operation, such as the datafile and redo log file layout and the cur-
rent system change number. Without the control file, the database simply cannot
operate, which is why you should configure the database with multiple copies of
the control file, as specified by the CONTROL_FILES initialization parameter.
However, if media failure were to cause the loss of all copies of the control file,
it will be very difficult and time consuming to recover the database.
In addition to multiplexing the control file, you should also back up the control
file. This should be done on a regular schedule and any time the physical struc-
ture of the database changes, such as adding datafiles or tablespaces. Oracle
provides two methods of backing up the control file, both of which can be used
while the database is up and running. You can back up the control file by creating
an image copy or by creating a trace file that contains the CREATE
CONTROLFILE command that can be used to re-create the control file.
To create an image copy of the control file, you would use the ALTER
DATABASE command with the BACKUP CONTROLFILE option and specify the
name and path of the backup control file you want to create. Even if your data-
base contains multiple copies of the control file, you only need to create a single
backup since all of the current copies are identical. The following is an example
of the ALTER DATABASE command used to create an image copy of the control
file.
ALTER DATABASE BACKUP CONTROLFILE TO 'F:\dbbackup\control.bak';
In this example, Oracle will read from one of the live control files to create a
single backup control file called control.bak in the F:\dbbackup directory. This
single backup control file can be used to restore all copies of the control file if
they are lost. If a previously-created backup control file already exists in the
backup location with the same name as the backup you are trying to create,
Oracle will return an error. However, you can force Oracle to overwrite the previ-
ous backup by including the REUSE keyword with the ALTER DATABASE
command, as shown in the following example.
ALTER DATABASE BACKUP CONTROLFILE TO 'F:\dbbackup\control.bak'
REUSE;
To create a trace file that contains the CREATE CONTROLFILE command, you
would specify the keyword TRACE with the ALTER DATABASE BACKUP
CONTROLFILE command instead of a path and file name. For example, the
following command will generate a trace file that contains the appropriate com-
mands to re-create the control file.
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
In this example, Oracle will create a trace file in the directory specified by the
USER_DUMP_DEST parameter. This trace file will contain the necessary com-
mands required to re-create the control files and get the database up and running
in the event that media failure causes the loss of all copies of the current control
file. Figure 3-1 shows an example control file trace file generated by the ALTER
DATABASE BACKUP CONTROLFILE command.

Figure 3-1: A control file trace file.
The trace file can be extremely useful when it is necessary to re-create the control
file if you do not have a valid backup control file you can restore from. To
re-create the control file, you would start the database in the nomount state, and
then execute the CREATE CONTROLFILE command. If the command is very
lengthy, such as when you have a very large database with numerous datafiles,
the trace file can be extremely useful in getting the database up and running again
with as minimal down time as possible. Without the trace file, you would need to
know the exact names and locations of all your log files and datafiles.
When a session creates a trace file, either through a command or some other
session-specific error, Oracle writes the file to the directory specified by the
USER_DUMP_DEST parameter. The file will be named using an OS-specific
naming convention, but usually includes the name of the database and the current
session’s OS-level process ID. The name of the trace file could be something like
ora92_ora_2636.trc. This naming convention is used to reduce the possi-
bility of an existing trace file being written to by another session.
If the USER_DUMP_DEST contains a large number of trace files, it could be
very difficult to locate the trace file generated by your session when you issued
the ALTER DATABASE command. It is possible, however, to piece together the
path and location of the trace file you just generated by querying from the data
dictionary. The following query will provide the name and path of the trace file
that would be generated for the current session. Every session would generate the
same directory path, but with a different file name, depending on the process ID
for that session.
SELECT a.VALUE||'\'||LOWER(d.name)||'_ora_'||b.spid||'.trc' AS
file_name
FROM v$parameter a, v$process b, v$session c, v$database d
WHERE a.name = 'user_dump_dest' AND
b.addr = c.paddr AND
c.TYPE = 'USER' AND
c.audsid = USERENV('SESSIONID' ) AND
c.username IS NOT NULL;

The V$PARAMETER view contains the value set for the USER_DUMP_DEST
parameter, and the V$DATABASE view contains the name of the database. The
V$SESSION view contains the session IDs for all sessions connected to the data-
base, along with the memory address for the session’s corresponding OS-level
process. The USERENV function can be used to determine various pieces of
information about the current session. In this case, it is being used to determine
the session ID for the current session. This session ID is matched up to the
AUDSID column of the V$SESSION view. Once the current session is found, the
query matches the memory address of the session’s OS-level process in
V$SESSION to the corresponding process in V$PROCESS. That view is used to
find the server process ID in the SPID column of the V$PROCESS view. All the
pieces are finally put together in the select list in the form of a path and file name
where you could find the trace file generated by the current session. The follow-
ing shows sample output from this query:
ORA92> @get_trace.sql
FILE_NAME
------------------------------------------------
D:\oracle\admin\ora92\udump\ora92_ora_2636.trc
With a little creativity, this query can be used within a backup script to back up
the control file to trace, then automatically find the trace file and copy it to the
backup location along with the rest of the backup datafiles and control files.
TASK 3A-2
Objective: To perform backups of the control file using multiple methods.
1. Launch SQL*Plus from the Start menu and log in as sys.
2. You will first back up the control file to a standard image copy.
At the prompt, issue the following command:

ALTER DATABASE BACKUP CONTROLFILE TO ⇒
'D:\oracle\hot_bup\control.bak';

3. Choose Start→Run. In the Run text box, type D:\oracle\hot_bup and click
OK.
You will see three files. The *.DBF files are backups of datafiles you created
earlier in this lesson. The CONTROL.BAK file is the backup copy of the
control file. Close the hot_bup window.
4. You will now generate a trace file that can be used as a script to re-create
the control file.
At the SQL*Plus prompt, issue the following command:


5. To determine the current path and file name of the trace file that was gener-
ated, type @C:\079176\get_trace.sql and press Enter.
Oracle will display the path and file name of the trace file that was
generated. The file name on your system may be different from what is
shown here.
6. Choose Start→Run. In the Run text box, type D:\oracle\admin\ora92\

udump and click OK. A window for the udump folder will appear.
Oracle generates trace files

for a variety of reasons. Your
udump folder may contain
many more trace files than
what is shown here. This is
normal and to be expected.
7. The udump folder will contain one or more trace files. Find and open the
file that was identified by the get_trace.sql script.
The trace file contains a SQL script that can be edited and used to re-create
the control file in the event that all control files for the database are lost.
Take a few moments to browse through the file and see its contents.

Close the trace file when you are done reading it.
8. At the prompt, type exit and press Enter.
Read-only Tablespaces
In Oracle, tablespaces can be set to a read-only status, which guarantees that the
tablespace will not be written to for any reason. A tablespace is set to read-only Setting a Tablespace to
or read-write with the ALTER TABLESPACE command, as shown in the follow- Read-only or Read-write
ing syntax.
ALTER TABLESPACE tablespace_name READ [ONLY|WRITE];
When the ALTER TABLESPACE command is issued to set a tablespace to read-
only, a checkpoint is issued, and the datafile headers for that tablespace are
updated one last time with the latest SCN from the control file. The datafiles are
then frozen, and any process that tries to write to the tablespace will receive an
error. The STATUS column of the DBA_TABLESPACES view indicates which
tablespaces are set to read-only.
Once a tablespace is in read-only mode, the datafiles for that tablespace need to
be backed up only once. Since the datafiles are guaranteed to remain static, there
is no need to include these datafiles in every database backup. Additionally, you
do not need to place a read-only tablespace into backup mode; you can simply
use any appropriate OS-level command to make a copy of the datafiles. Once the
tablespace is set back to read-write mode, you should immediately back up the
tablespace, then resume including the tablespace in regular database backups.
It’s important to note that any time you change the status of a tablespace from
read-write to read-only, or vice versa, that you back up the control file. This
ensures that your latest control file backup contains the most current status infor-
mation about all tablespaces in the database. If you place a tablespace in read-
only and you do not back up the control file, loss of the control file at a later

point will make a recovery very difficult, since Oracle will have no way of know-
ing which tablespaces are supposed to be read-only. Additionally, when the
control file is backed up as a trace file, the trace file contains all the correct com-
mands needed to recover the database, including any read-only tablespaces.
TASK 3A-3
Identify Backup Considerations for Read-only
Tablespaces
1. How many times must you back up a read-only tablespace? Explain
your answer.
A tablespace in read-only mode only requires to be backed up once, as long
as that backup occurs after the tablespace was placed in read-only mode.
Once the tablespace is placed in read-write mode, it should be backed up
immediately. All future backups of the tablespace should follow the same
logic as all other tablespaces. If the tablespace is placed in read-only mode
again, only one backup of the tablespace after that point in time is
necessary.
2. Why is it important to immediately backup the control file after setting

a tablespace from read-write to read-only, or vice versa?
The control file is read during recovery to determine the current status of all
datafiles in the database. If a media failure occurs that results in the loss of
all copies of the current control file, you must recover using a backup con-
trol file. If you place a tablespace in read-only and you do not back up the
control file, loss of the control file at a later point will make a recovery very
diffıcult, since Oracle will have no way of knowing which tablespaces are
supposed to be read-only.
Resolving a Failed Hot Backup

If the database experiences instance failure when one or more tablespaces are in
backup mode, then the backup is considered a failed hot backup. However, the
validity of your backup files will depend on when the instance failure occurred. If
instance failure occurred after the files have completed copying but before you
had the chance to issue the ALTER TABLESPACE...END BACKUP commands,
then the backup copies are valid, and they can be used to restore and recover the
database in the event of media failure. However, if the instance crashed while
you were still in the process of copying the files, then those copies will be
invalid, and you must discard those copies and back up the database again.
When a tablespace is placed in hot backup mode, checkpoints are deferred for
that tablespace, which means that the datafile headers will not contain the most
current SCN from the control file. If the instance were to crash with the
tablespace in hot backup mode, then the files will still contain the old SCN. Upon
restarting the instance, Oracle will detect the old SCN in the affected datafiles,

and will assume that the datafiles need recovery. However, since the data in the
tablespace is actually current, you only need to take the tablespace out of backup
mode. This will cause Oracle to checkpoint the tablespace’s datafiles and advance
the SCNs in the datafile headers to match that of the control file.
The V$BACKUP view lists which datafiles are currently in backup mode. This
view can be queried while the database is in the mount state. You can take the Resolving a Failed Backup
datafiles of a tablespace out of backup mode using any one of three possible
statements. You can take a single datafile out of backup mode using the ALTER
DATABASE DATAFILE command, as shown in the following syntax.
ALTER DATABASE DATAFILE 'path_and_file_name' END BACKUP;
In this example, only a single datafile is being taken out of backup mode. If the
specified datafile is the only one in the tablespace, then the entire tablespace will
be taken out of backup mode. If the tablespace contains multiple datafiles, then
only the specified datafile will be taken out of backup mode, but no others will
be affected. This command can only be used if the database is in the mounted
state, but not open. If you issue this command while the database is open, then
Oracle will return an error.
If the tablespace contains many datafiles, it will probably be much easier to take
the entire tablespace out of backup mode with the ALTER TABLESPACE
command. With this command, as shown in the following example, all datafiles
belonging to the specified tablespace will be taken out of backup mode.
ALTER TABLESPACE tablespace_name END BACKUP;
The simplest method, of course, is to take all datafiles of all tablespaces out of
backup mode with a single command. This can be done with the ALTER
DATABASE END BACKUP command. This command takes all tablespaces out of
backup mode simultaneously and eliminates the time-consuming need to specify
each tablespace or datafile individually.
If you are not sure whether any tablespaces were in hot backup mode at the time
the instance failure occurred, you can also resolve the problem by simply per-
forming a standard recovery by issuing the RECOVER DATABASE command.
Oracle will perform its normal recovery operations by rolling the database for-
ward to the point of failure using the redo log information, then rollback any
uncommitted transactions. After the recovery is complete, which should be very
quickly, the database can be opened as usual. Once the database is opened, you
should immediately determine whether your database backup set is valid. If it is
not, or if you are not sure, then you should immediately discard that backup set
and create a new one.
TASK 3A-4
Resolve a Failed Hot Backup
Objective: To resolve a failed hot backup in the event of failure while a
tablespace is in backup mode.
1. You will first simulate instance failure while a hot backup is in progress.
This can be done by issuing the SHUTDOWN ABORT command while
tablespaces are in backup mode.
Launch SQL*Plus from the Start menu and log in as sys.

2. Before setting any tablespace to backup mode, you should determine the
current statuses of the tablespaces.
At the SQL*Plus prompt, type @C:\079176\bup_status.sql and press Enter.
The output will show that no tablespaces are currently in backup mode.
3. You will now put several tablespaces in backup mode.
At the prompt, issue the following commands. After each command, Oracle
will display the message “Tablespace altered.”
ALTER TABLESPACE system BEGIN BACKUP;
ALTER TABLESPACE undotbs1 BEGIN BACKUP;
ALTER TABLESPACE example BEGIN BACKUP;
ALTER TABLESPACE tools BEGIN BACKUP;
ALTER TABLESPACE users BEGIN BACKUP;

4. To confirm which tablespaces are currently in backup mode, execute the
bup_status.sql script again by typing @C:\079176\bup_status.sql and
pressing Enter.
The output will show that the SYSTEM, UNDOTBS1, EXAMPLE, TOOLS,
and USERS tablespaces are now in backup mode.
5. To simulate instance failure, type shutdown abort and press Enter.
Oracle will simply display the message “ORACLE instance shut down.”
6. Since the instance was aborted while several tablespaces were in backup
mode, the tablespaces will not be consistent with the rest of the database
upon startup. This means that any attempt to open the database without
addressing this issue will fail.
At the prompt, type startup and press Enter.
The output will show that Oracle was able to start the instance and mount
the database, but could not open the database because the tablespaces that
were in backup mode at the time of the failure require some sort of
recovery.
7. To resolve the failed hot backup, you will take all tablespaces out of hot
backup mode with a single command.
At the prompt, type ALTER DATABASE END BACKUP; and press Enter.

8. You can now open the database.
Type ALTER DATABASE OPEN; and press Enter.
After a few moments, Oracle will display the message “Database altered.”
9. To confirm that all tablespaces have been taken out of backup mode, type
@C:\079176\bup_status.sql and press Enter.
The output will show that no tablespaces are currently in backup mode. To
resolve a hot backup after a failure, you would take the tablespaces out of
backup mode while the database is mounted but not open. The ALTER
DATABASE END BACKUP command can be used to take all tablespaces out
of backup mode simultaneously.
10. Exit SQL*Plus.

Topic 3B
User-managed Complete Recovery
During a complete recovery, the database is recovered up to the point in time
when the media failure occurred, which guarantees that there will be no loss of
changes to the data. A complete recovery should be the goal of most database
recovery scenarios, if it is at all possible. When performing a user-managed com- A Restored Datafile
plete recovery, you must first manually restore any datafiles that have been lost
due to media failure. This can be done through simple OS-level commands to
copy backup datafiles to their original locations. If a tablespace has multiple
datafiles, and only one is lost due to media failure, you only need to restore the
missing datafile. This allows you to restore only those files you need, which can
drastically reduce your mean time to recovery. Figure 3-2 illustrates a datafile that
has been restored from backup after a media failure.
Figure 3-2: A datafile that has been restored after media failure.
In this figure, the INDX_01.DBF datafile was restored from backup. The SCN
stored in the header of this datafile (328644) indicates the last SCN that was writ-
ten to the datafile when the INDX tablespace was put into backup mode just prior
to the datafile being backed up. Since the control file shows a later SCN
(454143), upon recovery, Oracle will determine that the newly-restored datafile is
missing some changes that need to be applied in order to bring it up to date with
the rest of the database.
The actual database recovery is initiated with the RECOVER command from
SQL*Plus and can be performed at the file, tablespace, or database levels, known The RECOVER command
as recovery targets. If recovery is performed at the file level, only the target is identical to the ALTER
datafile is recovered, while if the recovery is performed at the tablespace level, all DATABASE RECOVER
restored datafiles that make up the target tablespace are recovered. If the recovery command.

is performed at the database level, all restored datafiles in the database that
require recovery are recovered. Naturally, a database-level recovery requires the
least amount of keystrokes and can be very convenient if multiple datafiles have
been lost across several tablespaces. The following shows the syntax of the
RECOVER command.
RECOVER {DATABASE |
TABLESPACE tablespace_name |
DATAFILE 'path_and_file_name'};
If you wish to recover multiple tablespaces, you can list the specific tablespaces
separated by commas, and the same technique can be used for datafiles. However,
you cannot include both the TABLESPACE and DATAFILE options within a
single RECOVER command. If you wish to perform such an operation, you must
do so with separate RECOVER commands.
The RECOVER command can be used with the DATABASE option if the database
is mounted but not open. The RECOVER command can be executed with
TABLESPACE or DATAFILE options while the database remains up and running,
providing the ability to perform hot recoveries, but the target of the recovery
must be offline to perform the recovery. For example, if you intend to recover a
tablespace, you must take the entire tablespace offline using the ALTER
TABLESPACE command. If you intend to recover a single datafile, you must
either bring that single datafile offline using the ALTER DATABASE DATAFILE
command or bring the entire tablespace offline. The tablespace or datafile that is
being recovered will be unavailable while the recovery is being performed, but
the rest of the database can stay operational during the recovery process. The fol-
lowing statements provide examples of the ALTER TABLESPACE and ALTER
DATABASE DATAFILE commands to bring recovery targets offline.
ALTER TABLESPACE example OFFLINE;
ALTER DATABASE DATAFILE 'D:\oracle\oradata\ora92\indx_01.dbf'
OFFLINE;
Upon initiating recovery, Oracle will compare the SCN for the recovery target
with the database’s latest SCN in the control file. If Oracle finds any datafiles in
the recovery target that have an SCN lower than what is shown in the control
file, it will determine that those datafiles need recovery. Oracle will use a
datafile’s SCN to find the redo information necessary to recover by looking in the
V$LOG and V$LOG_HISTORY data dictionary views. If Oracle determines that
the only changes needed for recovery reside in the current online redo log, those
changes will automatically apply those changes to restore the file.
If Oracle determines that any of the changes reside in archive logs, Oracle will
immediately prompt the DBA for the name and location of the archive log that
contains the earliest required SCN. It will also suggest the path and file name of
that archive log as it was last known to Oracle at the time the log was archived.
This path and file name may or may not be valid, depending on whether or not
the archive log has been moved to reclaim storage space. If the path and file
name are valid, the DBA can simply press Enter to accept the suggestion, or the
DBA can type in the true path and file name. If Oracle finds the specified file, it
will read from the file and apply the necessary changes to the restored datafile. If
all the changes found in the archive log have been applied, but the datafiles still
need recovery, Oracle will prompt for the next archive log in the sequence. The
entire process will repeat until all datafiles in the database have been recovered to
the point where their SCNs match what is shown in the control file.

To simplify the process of specifying archive logs, you can include the FROM
clause with the RECOVER command to provide a specific directory path where
the required archive logs can be found. This path can be, and usually is, different
from the archive log destination where the logs were originally archived to. If the
FROM clause is omitted, Oracle will automatically assume that the archive logs
will be found in the location specified by the LOG_ARCHIVE_DEST or LOG_
ARCHIVE_DEST_1 parameters. You can also supply the AUTOMATIC option
which instructs Oracle to find and apply all necessary archive logs found in the
specified location. This eliminates the need to manually type the path and file
name for each archive log that needs to be applied. The following RECOVER
command illustrates the use of the FROM clause and AUTOMATIC option to
recover the entire database.
RECOVER DATABASE AUTOMATIC FROM 'D:\oracle\oraarch';
In this example, Oracle will initiate the recovery of all datafiles in the database
that require recovery. Oracle will look for the required archive logs in the
D:\oracle\oraarch directory and will automatically apply them as they are found.
If a required archive log is not found in the specified location, Oracle will halt
the recover and prompt the DBA for the correct file name and location again.
While performing the recovery, the DBA can specify the AUTO option at any
point to instruct Oracle to automatically apply all archive logs found in the speci-
fied location. For example, the DBA can issue the RECOVER DATABASE
command and allow Oracle to suggest at least the first archive log it needs to
perform the recovery. Upon seeing the location and file name of the required
archive log, the DBA may see that the location and file name is valid and can
specify the AUTO option instead of just pressing Enter. This instructs Oracle to
accept the suggested archive log and continue applying all required archive logs
found in that same location.
Only when the database is recovered to a consistent state, meaning the headers of
all datafiles show the same SCN, will Oracle consider the database recovered and
will display the message “Media recovery complete.” Once media recovery is
complete, the DBA can bring the recovery target online, whether the target be a
datafile, a tablespace, or the entire database. The following example shows the
output from an automatic database recovery using the RECOVER DATABASE
AUTOMATIC command.
SQL> RECOVER DATABASE AUTOMATIC;
ORA-00279: change 64688 generated at 01/26/03 19:20:58 needed

for thread 1
ORA-00289: suggestion : /oracle/oradata/oraaarch/ora92_1_903.arc
ORA-00280: change 64688 for thread 1 is in sequence #903
Log applied.
ORA-00279: change 64695 generated at 01/26/03 19:24:05 needed
for thread 1
ORA-00289: suggestion : /oracle/oradata/oraarch/ora92_1_904.arc
ORA-00280: change 64695 for thread 1 is in sequence #904
ORA-00278: log file "/oracle/oradata/oraarch/arcr_1_903.arc" no
longer needed for this recovery
Log applied.
Media recovery complete.

In this example, Oracle searched the location specified by the LOG_ARCHIVE_
DEST or LOG_ARCHIVE_DEST_1 parameters for the required archive logs.
Upon finding the necessary logs, Oracle automatically applied the archive logs to
all datafiles that needed recovery, and displayed the message “Media recovery
complete” once all datafiles in the database were consistent with the control file.
The database can now be opened with the ALTER DATABASE OPEN command.
TASK 3B-1
Recover a Tablespace After a Failure
Objective: To recover a tablespace after a failure.
1. Earlier in this lesson, you performed a hot backup of the EXAMPLE

tablespace. In this activity, you will simulate the loss of the datafile that
makes up this tablespace, and then perform a restore and recovery of the
datafile from the hot backup.
Launch SQL*Plus from the Start menu and log in as sys.
2. At the prompt, issue the following query:

SELECT table_name, tablespace_name
FROM dba_tables
WHERE owner='OE';
The output shows a list of tables owned by the user OE. All of the tables are
stored in the EXAMPLE tablespace.
3. You will create a new table in the OE schema, and store it in the
EXAMPLE tablespace. At the prompt, issue the following command:
CREATE TABLE oe.test_recovery
( col1 NUMBER(5) )
TABLESPACE example;

Oracle will display the message “Table created.” Remember, this table did
not exist when the EXAMPLE tablespace was backed up.
4. To insert a row into this table, issue the following statements:

INSERT INTO oe.test_recovery VALUES (5);
COMMIT;
Oracle will display the messages “1 row created” and “Commit complete.”
To see the row of data you just inserted into the test table, issue the follow-
ing query:
SELECT *
FROM oe.test_recovery;
The output will show the value 5 in the COL1 column. This row did not
exist when the EXAMPLE tablespace was backed up.
5. To see the complete list of tables owned by OE, issue the following query
again:
FROM dba_tables
WHERE owner='OE';

The output will show that the TEST_RECOVERY table is currently stored in
the EXAMPLE tablespace.
6. The redo information generated by the CREATE TABLE and INSERT state-
ments were stored in the current online redo log. If you force a log switch,
the current redo log will be archived to be used in the event that a recovery
is necessary any time in the future.

Enter.
Issue the statement a second time to switch the logs again.
7. You will now simulate loss of the datafile that makes up the EXAMPLE
tablespace.
First, determine the name of the EXAMPLE datafile by issuing the fol-
lowing query:
SELECT file_name
FROM dba_data_files
WHERE tablespace_name='EXAMPLE';
The output shows that the EXAMPLE tablespace is made up of the

EXAMPLE01.DBF datafile, which is found in the D:\oracle\oradata\ora92
folder.
8. To shut down the database, type shutdown immediate and press Enter.
The output will show that the database was closed and dismounted, and the
instance shut down.
box, type D:\oracle\oradata\ora92 and click OK. A window for the
D:\oracle\oradata\ora92 folder will appear.
In the list of datafiles, select EXAMPLE01.DBF and press Shift+Delete. A

question box will appear asking if you are sure you want to delete the
EXAMPLE01.DBF file. Click Yes.
Your database just suffered a loss of the EXAMPLE01.DBF datafile.
10. Leaving the ora92 window open, switch back to the SQL*Plus window.
The output will show the instance start and the database mount. However,
the database will not open because it cannot find the EXAMPLE01.DBF
datafile.
11. You will now restore the datafile from backup, and perform a complete
recovery of the database using the redo information stored in the online and
archived redo logs.
Switch back to the ora92 window.
Press the Backspace key twice to move back to the D:\oracle folder.
Double-click the hot_bup folder to open it.

The folder will contain the backup copies of the control file, and the
example and system datafiles.
12. Select EXAMPLE01.DBF. Choose Edit→Copy.
Press the Backspace key to move back to the D:\oracle folder.
Double-click the oradata folder to open it. Double-click the ora92 folder
to open it.
Choose Edit→Paste to paste a copy of the datafile in the ora92 folder.
A progress meter will appear while the EXAMPLE01.DBF file is copied.

Once the copy is complete, close the ora92 folder.
13. Now that the EXAMPLE01.DBF datafile has been restored, you must now
recover the database.
At the prompt, type RECOVER DATABASE; and press Enter.

The log sequence number
shown on your system may Oracle detects that the changes needed to recover this datafile have been
be different from what is archived already, and prompts you for the name and path of the required
shown here. archive log.
To accept the suggested archive log, press Enter. If Oracle prompts for
additional logs, keep pressing Enter to accept the suggested logs. After
each log, Oracle will display the message “Log applied.”
Once all archived changes have been applied to the database, Oracle will

display the message “Media recovery complete.”
14. The EXAMPLE tablespace has been recovered, and you may now open the
database.
At the prompt, type ALTER DATABASE OPEN; and press Enter.
15. To ensure that your TEST_RECOVERY table has been recovered, issue the
following query once more:
FROM dba_tables
WHERE owner='OE';
The output will show that your TEST_RECOVERY table is there.
16. To ensure that your data is intact, issue the following query:
SELECT *
FROM oe.test_recovery;

The output will show that the row you inserted into the TEST_RECOVERY
table has also been recovered.
17. You have just perform a user-managed complete recovery of your database.
Exit from SQL*Plus.
Trial Recovery
Occasionally, a database recovery may fail in mid-operation for one reason or
another, such as block corruption in the backup sets or archive logs. This requires
that the entire operation be restarted, and can be very time-consuming, especially
trial recovery: if the database is very large, and can increase your mean time to recovery. In
A test recovery of the order to avoid this problem, Oracle provides the ability to execute a trial recovery
database that is used to to determine if a problem will be encountered during an actual recovery. The trial
determine whether or not a
real recovery will be
recovery is much faster than an actual recovery, and if any problems are reported
successful. during trial recovery, those problems can be dealt with ahead of time.
To execute a trial recovery, you would simply include the option TEST with the
RECOVER command. The recovery process will appear to execute as normal,
prompting for archive logs as it proceeds, except that no changes are actually
written to the datafiles. All changes from the archive logs are stored only in the
database buffers, but will be rolled back at the end of the trial recovery. All errors
that are encountered during trial recovery are recorded in the alert log. The TEST
option can be included with any type of recovery that can be performed with the
RECOVER command. The following statement shows an example RECOVER com-
mand with the TEST option.
RECOVER DATABASE TEST;
If the trial recovery detects only a few corrupted blocks, you can choose to pro-
ceed with the actual recovery, and direct the recovery process to allow those
corruptions. This is done with the ALLOW n CORRUPTION clause of the
RECOVER command. The n specifies the number of corrupt blocks to allow dur-
ing the recovery. To recover a database and allow three corrupt blocks (found
during trial recovery), you would issue the following command.
RECOVER DATABASE ALLOW 3 CORRUPTION;
It’s important to note that the ALLOW n CORRUPTION clause is provided only
as a means to move past a block corruption issue to finish the recovery process.
Since you have instructed Oracle to allow those block corruptions during the
recovery process, the corruptions will still exist when you bring the recovery tar-
get online. Any subsequent attempts to access those datablocks through normal
database operations will result in an error and will need to be rectified. Block
corruption can be handled multiple ways, which you will learn about later in the
course.

TASK 3B-2
Perform a Trial Recovery
Objective: To perform a trial recovery.
1. In this activity, you will simulate the loss of a datafile, and then perform a
trial recovery of the tablespace. This will allow you to determine if the
recovery will encounter corruption issues without actually performing the
recovery.
Launch SQL*Plus from the Start menu, and log in as sys.
2. Take the EXAMPLE tablespace offline by issuing the following state-

ment:
ALTER TABLESPACE example OFFLINE;
Oracle will display the message “Tablespace altered.”
3. Leaving the SQL*Plus window open, open a window to the D:\oracle\

oradata\ora92 folder.
In the list of datafiles, select EXAMPLE01.DBF and press Shift+Delete. A

question box will appear asking if you are sure you want to delete the
EXAMPLE01.DBF file. Click Yes.
Your database just suffered a loss of the EXAMPLE01.DBF datafile.
4. Leaving the ora92 folder open, switch back to the SQL*Plus window.
At the prompt, issue the following statement:

ALTER TABLESPACE example ONLINE;

Oracle will display error messages stating that the EXAMPLE01.DBF
datafile could not be identified.
5. You will now restore the datafile from the hot backup of the database you
created earlier.
Switch back to the ora92 folder.
Navigate to the D:\oracle\hot_bup folder.
Copy the EXAMPLE01.DBF backup datafile from the D:\oracle\hot_bup

folder to the D:\oracle\oradata\ora92 folder. It may take a few moments
for the copy to complete.
Close the ora92 folder.
6. You will now run a trial recovery of the EXAMPLE tablespace. This will
help to identify potential problems that might arise during an actual
recovery. At the SQL*Plus prompt, issue the following command:
RECOVER TABLESPACE example TEST;
Oracle will return several messages.
The first message listed, starting from the bottom, states that test recovery
cannot apply redos that may modify the control file. This means that the trial
recovery successfully completed. The recovery started with the earliest
If you do not receive the last required entry in the redo logs, and stopped when it reached the last known
two errors and instead entry in the redo log. If any more redo entries were applied, the datafile
receive the following error,
would contain a later SCN than the control file, and the controlfile would
“ORA-10570: Test recovery
complete,” then issue the have to be modified to support it, which is not allowed in trial recovery.
following command before
moving on with this activity: The next message, stating that the test recovery was canceled due to errors,
CONNECT sys as is purely informational. The third message from the bottom states the SCN
sysdba. range that was tested during the trial recovery. This range starts from the
earliest known redo entry required for the data file that was restored, and
ends with the current SCN known to the control file.
The final message states that the test recovery did not corrupt any data
block. This means that the trial recovery was successful in that it did not
encounter any corrupted data blocks during the recovery process. If a block

was found to be corrupted, the DBA could optionally skip that corrupted
block and move on with the recovery using the ALLOW n CORRUPTION
clause of the RECOVER command. The trial recovery provides a way for the
DBA to identify those suspect blocks prior to running an actual recovery.
7. Before bringing the EXAMPLE tablespace back online, you must first per-
form an actual recovery of the tablespace. At the SQL*Plus prompt, issue
the following command:
RECOVER TABLESPACE example;
After a moment, Oracle will display the message “Media recovery

complete.”
8. Bring the tablespace back online by typing the following command at

the SQL*Plus prompt:
ALTER TABLESPACE example ONLINE;
9. Exit from SQL*Plus.
Restoring Datafiles to New Locations

Many times when media failure occurs, the original location where a datafile was
located is no longer available, such as when a disk fails. Under these circum- Renaming a Datafile in
stances, you must restore the datafile to a new location. Once the file is restored, Oracle
you would rename the file within Oracle using the ALTER DATABASE
RENAME FILE command. The command does not actually rename the file, but
rather changes Oracle’s internal pointer to the file so Oracle can find it in its new
location. The following example illustrates the use of this command to change
Oracle’s pointer to the INDX01.DBF datafile.
ALTER DATABASE RENAME FILE
'F:\oracle\oradata\ora92\indx01.dbf'
TO
'G:\oracle\oradata\ora92\indx01.dbf';
In this example, the F disk has failed and is no longer available. Because of this,
the INDX01.DBF datafile was restored to the G disk. The ALTER DATABASE
RENAME FILE command is used to change Oracle’s pointer to this new
location. Once the file is restored, you can perform recovery as normal, then
bring the recovery target online.

Recovering a Datafile Without a Backup
One of the most difficult tasks a DBA can face is recovering a lost datafile that
has not yet been backed up. It could be that a datafile was recently added to a
tablespace, but the DBA had not yet had a chance to back up the datafile or for-
got to add the datafile to the backup routine. Under most circumstances, a media
failure would be disastrous and would almost certainly require the tablespace to
be dropped and re-created, which guarantees the loss of data. However, it is pos-
sible to recover a lost datafile without a valid backup if all three of the following
conditions exist:
• The database is running in ARCHIVELOG mode.
• All archive logs that have been generated since the datafile was created are
available.
• A valid control file is available, meaning the current control file or a valid
backup control file that was created after the datafile was added to the
database.
To perform this recovery, you must first bring the affected tablespace offline with
the IMMEDIATE option. If you do not include this option, Oracle will attempt to
perform a checkpoint as the tablespace goes offline, but will fail since a datafile
is missing. The following example shows the use of the IMMEDIATE option with
the ALTER TABLESPACE command.
ALTER TABLESPACE indx OFFLINE IMMEDIATE;
Once the tablespace is offline, you will create a new, empty datafile to take the
Creating an Empty Datafile
place of the missing datafile. You will then apply to the new datafile all of the
archive logs that have been generated by the database since the original datafile
was created. To create the empty datafile, you would use the ALTER
DATABASE CREATE DATAFILE command, and specify both the original file
name and the new file name, as shown in the following example.
ALTER DATABASE CREATE DATAFILE
'D:\oracle\oradata\ora92\indx01.dbf'
AS
'F:\oracle\oradata\ora92\indx01.dbf';
In this example, the D disk has crashed, causing the loss of the INDX01.DBF
datafile, but there was no valid backup of the datafile. A new, empty datafile is
created on the F disk, and Oracle automatically changes its pointer for the
INDX01.DBF datafile to point to the new datafile. Essentially, this command has
just restored the INDX01.DBF datafile, and datafile recovery can now begin using
normal recovery commands. As Oracle recovers the datafile, all archive logs that
have been generated since the original datafile was created will be applied to the
new datafile to bring it up to date with the rest of the database.

TASK 3B-3
Restore Datafiles to New Locations
Objective: To restore datafiles to new locations in the event that the origi-
nal location is no longer available.
1. You will first simulate the loss of the disk where the EXAMPLE01.DBF
datafile is stored.
Launch SQL*Plus and log in as sys.
2. At the prompt, issue the following query:

SELECT file_name
FROM dba_data_files
The output will show that the EXAMPLE01.DBF datafile is currently stored
in the D:\oracle\oradata\ora92 folder.
3. To shut down the database, type shutdown immediate and press Enter.
The output will show that the database has been closed and dismounted, and
the instance shut down.

Delete the EXAMPLE01.DBF datafile from this folder.
5. Leaving the ora92 window open, switch back to the SQL*Plus window.
The output will show that the instance was started and the database opened,

but the database could not be opened. This is because the
EXAMPLE01.DBF datafile could not be found. Your database just suffered
the loss of a disk that contained one of its datafiles.
6. The original disk with the EXAMPLE01.DBF datafile was lost, therefore,
you must restore the datafile to a new location. Since it is assumed that your
system has only a single disk, you will simulate restoring the datafile by cre-
ating a new folder on the D drive.
Switch back to the ora92 folder.
In the oradata folder, create a new folder called new_loc
7. In the D:\oracle\hot_bup folder, copy the EXAMPLE01.DBF backup

datafile to the D:\oracle\oradata\new_loc folder.
Once the file is copied, close the new_loc window.
8. Before recovering the database, you must change Oracle’s internal pointer to
the EXAMPLE01.DBF datafile. This is done with the ALTER DATABASE
RENAME FILE command.

ALTER DATABASE RENAME FILE
'D:\ORACLE\ORADATA\ORA92\EXAMPLE01.DBF'
TO
'D:\ORACLE\ORADATA\NEW_LOC\EXAMPLE01.DBF';

9. You will now recover the database using the redo information stored in the
archived redo logs.
At the prompt, type RECOVER DATABASE and press Enter.
Oracle detects that the changes needed to recover this datafile have been
archived already, and prompts you for the name and path of the required
archive log.
To accept the suggested archive log, press Enter. If Oracle prompts for
additional logs, keep pressing Enter to accept the suggested logs. After
each log, Oracle will display the message “Log applied.”
Once all archived changes have been applied to the database, Oracle will
display the message “Media recovery complete.”
10. To open the database, type ALTER DATABASE OPEN; and press Enter.
11. To verify location of the EXAMPLE01.DBF datafile, issue the following

query again:
SELECT file_name
FROM dba_data_files
The output will show that the EXAMPLE01.DBF datafile is now stored in
the D:\oracle\oradata\new_loc folder, instead of the D:\oracle\oradata\ora92
folder. You have successfully restored a datafile to a new location and recov-

ered the database after the loss of a disk.
Topic 3C
User-managed Incomplete Recovery
When an incomplete recovery is performed, the database is recovered to a point
in time prior to the point of failure. This is done by not applying all redo infor-
mation to the database, from either the archive logs or the current online redo
Incomplete Recovery log. An incomplete recovery may be required, and in some cases desired, in cer-
Scenarios tain situations, which include:
• Loss of all copies of the current control file.
• Loss of current redo log group.
• A gap in the archive log sequence during normal recovery.
• Intentional point-in-time recovery.
As you learned earlier, the SCN recorded in the control file is considered the
most current SCN for the database and is used as a reference point during data-
base recovery. If the headers of any datafiles contain SCNs that are lower than
that of the control file, then Oracle determines that those files require recovery.
During recovery, the SCNs in the target datafiles are incremented as changes from
the redo or archive logs are applied. Only when the SCNs in the target datafiles
match the SCN in the control file will Oracle consider the datafiles recovered.
Losing the current control file means that you have lost that reference point, and
Oracle will not know when the datafiles are completely recovered. In this case,
you must apply all available redo information to the datafiles, but since Oracle
has no idea when to stop recovering the datafiles, Oracle will never know when
the recovery is done. Such an operation is considered an incomplete recovery.
Another situation in which you may need to perform an incomplete recovery is
losing part or all of the redo stream. If media failure causes the loss of the cur-
rent online redo log group, the LGWR will not be able to write the redo log
buffer out to that redo log group, and will summarily terminate the instance.
Upon restarting the instance, instance recovery will begin, and Oracle will
attempt to begin the roll forward phase of recovery using the redo information
from the current redo log group. Since that group is no longer there, any changes
it may have contained, committed or uncommitted, will be lost. You must termi-
nate the recovery and open the database without applying those missing changes.

In addition to losing the current redo log group, a missing archive log could
result in a situation where an incomplete recovery is required just to get the data-
base open and running again. If media failure causes the loss of any part of the
database, such as a datafile, you would restore the datafile from backup as nor-
mal, then start applying the archived redo logs to recover the datafile. However, if
an archive log is missing, you will not be able to move on to the next one in the
sequence. The recovery must halt, and any changes contained in the missing
archive log, and all archive logs that were generated after the missing log, could
not be applied and would be lost.
An incomplete recovery may be necessary or desired if you wish to intentionally
bring the contents of the database back to a certain point in time. It could be that
a user accidentally deleted or truncated all the rows in a large table, and you
want to recover this table without having to manually reload its contents. It could
also be that you wish to undo a large number of changes that occurred to the
database, such as in a development environment, where you want to keep a single
version of the database as a test case for a project. In this case, you would restore
all the datafiles from a hot backup, then recover the database by applying the
archive logs as normal, but stop when the database has reached the targeted point
in time. In such a scenario, it’s important to remember that you cannot recover
only part of the database, such as a single datafile or tablespace, to a different
point in time than the rest of the database. You must bring the entire database
back to the same point in time by restoring all of its datafiles from backup, then
rolling forward.
Incomplete Recovery Commands

During a user-managed incomplete recovery, you can perform cancel-based, time-
based, or change-based recovery. This is done by including the UNTIL clause Incomplete Recovery
with the RECOVER command, which tells Oracle when to stop applying redo Commands
information to the database. The following syntax shows the RECOVER command
with the UNTIL clause.
RECOVER DATABASE UNTIL {CANCEL | TIME date | CHANGE n}
In this syntax, CANCEL indicates that you want Oracle to continually apply
archive logs until you issue the CANCEL command. Prior to applying an archive
log to the database, Oracle will prompt you for the name and location of the
required archive log, along with a suggested name and location. At this point, you
have the option of accepting the suggestion, supplying a different name and loca-
tion for the log, or issuing the CANCEL command. Upon issuing the CANCEL
command, Oracle will stop applying the archive logs and terminate recovery. The
following example shows a RECOVER command for cancel-based recovery:
RECOVER DATABASE UNTIL CANCEL;
The TIME option allows you to specify a specific date and time to recover the
database to. The date and time you specify must be a point in time after the data-
base backup set was generated, but before the current time. In other words, if the
last database backup completed today at 4:15 A.M., and the time is currently 3:00
P.M., then the only valid date and time you could specify would be between 4:15
A.M. and 3:00 P.M. today. When specifying the TIME option, Oracle will apply
all redo information from the archive logs necessary to recover the database to
the point in time specified. After the recovery is finished and the database is

opened, its contents will look exactly as it did at the time you specified in the
RECOVER command. All changes to the database that occurred after your speci-
fied time will be lost. When specifying the date and time for time-based recovery,
you must use the following date format, regardless of the default date format for
your database:
'YYYY-MM-DD:HH24:MI:SS'
The following example shows a RECOVER command for time-based recovery:
RECOVER DATABASE UNTIL TIME '2003-05-04:13:25:00';
Change-based recovery is the most precise type of incomplete recovery that you
can perform. For change-based recovery, you would specify the exact SCN that
you wish to stop the recovery at. Oracle will recover the database to the SCN just
prior to, but not including, the SCN specified in the RECOVER command. For
example, if the SCN specified in the RECOVER command is 43987, then the data-
base will be recovered to the SCN 43986. The SCN specified must be higher than
the highest SCN shown in your backup datafiles and, of course, must also be
lower than the highest SCN ever generated by your database, because Oracle can-
not restore the database up to a change that has not happened yet. The following
example shows a RECOVER command for change-based recovery:
RECOVER THE DATABASE UNTIL CHANGE 43987;
Repercussions of Incomplete Recovery

Prior to attempting an incomplete recovery, either intentionally or as a result of a
failure, it is important to understand the repercussions of performing such a
recovery. As stated earlier, an incomplete recovery results in the loss of changes
to the database. However, the pitfalls do not end there.
After performing an incomplete recovery, the control file must be updated with
the new current SCN for the database. All changes that had occurred after this
new current SCN must be invalidated so they can never be applied to the
database. In order to ensure both of these things happen, you must open the data-
base using the RESETLOGS option after an incomplete recovery. Doing so will
update the control file with the new SCN, and will set the log sequence numbers
for the redo log groups back at 1. The following example shows the command to
open the database and reset the logs after an incomplete recovery:
ALTER DATABASE OPEN RESETLOGS;
The RESETLOGS option can only be used after an incomplete recovery, specifi-
cally with RECOVER command that includes the UNTIL clause. If you attempt to
open the database with this option after a complete recovery, Oracle will return
incarnation: an error.
A new version of a database
created when the database is When opening the database with the RESETLOGS option, you have essentially
opened with the RESETLOGS created a new incarnation of the database. This new incarnation is a completely
option. different version of the database from its original version prior to the recovery.
While it may contain mostly the same data, you have basically caused the data-
base to shift to a new timeline in its life. Figure 3-3 illustrates this concept.
RESETLOGS Creates a New
Database Incarnation

Figure 3-3: RESETLOGS creates a new database incarnation.
In the timeline at the top half of this figure, the database has been operating nor-
mally, and a hot backup was performed when the current log sequence number
was 3000. The database continued to operate normally until media failure caused
the database to crash at log sequence 4500. The timeline in the bottom half of the
figure shows the steps that were taken to get the database up and running again.
The DBA restored the database from the hot backup, which means the database
looked the way it did at log sequence 3000, and then performed a recovery of the
database using the RECOVER command. However, during the recovery, the DBA
realized that there was a gap in the archive logs. Since essential redo information
was missing, the recovery could not proceed to the next archive log. The DBA
performed an incomplete recovery and was forced to open the database using the
RESETLOGS option. Upon opening the database with RESETLOGS, the control
file was updated with the new SCN and the log sequence number was reset back
to 1. Because the database is now a new incarnation of its old self, the archive
logs generated between the missing log and log sequence 4500 are now useless.
These logs can never be applied to the new incarnation of the database. Addition-
ally, all backups of the database created prior to the log reset are also useless.
Because of this, it is essential that you immediately create a new full backup after
opening the database with the RESETLOGS option. If you do not, and another
media failure occurs, you are almost guaranteed to lose all changes to the data-
base that had occurred after the log reset, and you will be right back to square
one.

TASK 3C-1
Describe Incomplete Recovery Concepts
1. Which of the following failures would require an incomplete recovery?
Choose all that apply.
✓ a. Loss of all copies of the current control file.
b. Loss of the Oracle executable.
c. Loss of the SYSTEM datafile.
✓ d. Loss of the current redo log group.
2. What are the three types of user-managed incomplete recovery that can
be performed for an Oracle9i database?
✓ a. Cancel-based
✓ b. Change-based
c. Commit-based
✓ d. Time-based
3. Why should you immediately perform a full back up of the database

after opening the database using the RESETLOGS option?
Upon opening the database using the RESETLOGS option, you have essen-
tially created a new incarnation of the database. Any backups that were
generated before the point in time when the RESETLOGS option was issued
cannot be used to recover the current incarnation of the database. To be
able to perform a complete recovery of the database in its current incarna-
tion, you should ensure that you have a full backup of the database that was
generated after the RESETLOGS option was issued.
4. Define the word incarnation in terms of the Oracle database.

When opening the database with the RESETLOGS option, you have created
a new incarnation of the database. This new incarnation is a completely dif-
ferent version of the database from its original version prior to the recovery.
This causes the database to shift to a new timeline in its life. All backups
and archive logs from the old incarnation that were generated after the point
in time when the RESETLOGS option was issued will be invalidated and
cannot be used to restore or recover the new incarnation of the database.
Loss of Control File

If media failure causes the loss of all copies of the current control file, the
instance will immediately crash. However, the database can be recovered using a
backup copy of the file or a newly created control file using the script stored in a
control file backup trace file. Either one will require an incomplete recovery and
a RESETLOGS to get the database open again.

To recover using a backup control file, you would simply restore the backup file
to all locations indicated by the CONTROL_FILES initialization parameter. Since
all copies of the current control file are identical, you can use a single backup
copy to restore all the original copies. If the original locations of the control files
are unavailable, such as when a disk completely fails, you can simply restore the
backup control file to new locations and change the assigned value for the
CONTROL_FILES parameter to point to the new locations.
Once all copies of the control files are restored, you would bring the database up
to the mount state, then initiate an incomplete recovery. The backup control file
will not have the most current SCN for the database, so you must specify in the
RECOVER command that you are performing the recovery using a backup control
file to instruct Oracle to ignore the SCN listed in the newly-restored control files.
Additionally, since Oracle will not know when to stop applying redo information
to the database, you must also indicate the stopping point for recovery yourself
using cancel-based, time-based, or change-based recovery. To apply all available
changes to the database, it is recommended that you use cancel-based recovery.
This will ensure that Oracle will attempt to continue recovering the database
indefinitely. Once Oracle runs out of changes to apply, meaning there are no more
archive logs or redo logs that have changes the database needs, Oracle will stop
the recovery with an error. The following command illustrates the use of the
RECOVER command to perform cancel-based recovery with a backup control file.
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
During the roll forward phase of recovery, Oracle will prompt for the necessary Cancel-based Recovery
archive logs to recover the database. Once Oracle prompts for an archive log that With Backup Control File
has not yet been generated, you would cancel the recovery using the CANCEL
command, and Oracle will display the message “Media recovery cancelled.” You
can then open the database using the RESETLOGS option.
Occasionally, when Oracle prompts for an archive log that has not yet been gen-
erated, and you issue the CANCEL command, Oracle may return the following
error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would
get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF'
While this error may initially be somewhat confusing, it simply means that
Oracle believes there are more changes that can be applied to the database, even
though you have applied all available archive logs. It is possible that the current
online redo log contains the missing changes, but Oracle did not have a chance to
archive this log prior to the media failure that caused the instance to crash. If you
get this error after stopping the recovery, you can simply start the recovery again,
and specify the current online redo log instead of an archive log. Oracle will read
the log and apply any changes it contains to the database. If you do not know
which log group was current when the database crashed, you could initiate recov-
ery, and then specify the first log group. If Oracle returns an error stating that it
could not find the changes it needed, you would simply initiate recovery again
and specify the second log group. You would repeat this process until Oracle
found the changes it needed to recover the database.

Once the database has been recovered using all available redo information, you
would open the database with the RESETLOGS option. You must remember that
this creates a new incarnation of the database, which invalidates all previous data-
base backups. It is recommended that you perform a full database backup,
including the control files, immediately after opening the database with the
RESETLOGS option.
To recover the database using a control file backup trace file, you would perform
all of the steps as using a standard backup control file, but with some additional
steps. The control file backup trace file contains the CREATE CONTROLFILE
command that can be used to manually re-create the control file in the event that
all copies of the control file are lost. First, you would need to edit the trace file to
remove any unnecessary comments, and possibly tailor the CREATE
CONTROLFILE command to suit your needs. Then you would start up the
database in the nomount state, which is required when manually creating the con-
trol file. You would then execute the CREATE CONTROLFILE command in the
trace file, which can be done by executing the edited trace file like a normal SQL
script, as shown in the following example.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 135338868 bytes

Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
SQL>
SQL> @D:\oracle\hot_bup\control.trc
When executing the CREATE CONTROLFILE command, Oracle will automati-
cally re-create a copy of the control file in each location specified by the
CONTROL_FILES initialization parameter. If a location specified by this param-
eter cannot be reached, such as a disk not being available, Oracle will return an
error and no control file will be created. Once the control files have been
re-created, you can initiate incomplete recovery using the same process that is
used with a standard backup control file copy.
TASK 3C-2
Recovering After Loss of Control File
Objective: To recover the database after a complete loss of all copies of
the current control file.
Note: The control file is critical to the operation of the Oracle database. Use
extreme caution and follow the directions in this activity very carefully. Failure to
do so may result in the complete loss or corruption of the current control files
and/or the backup control file, which may render your database useless. It is rec-
ommended that you read through the entire activity first before actually beginning
the activity on a live database.
1. You will first simulate the loss of all copies of the current control file.

2. Force a log switch by issuing the following command:
ALTER SYSTEM SWITCH LOGFILE;
3. Create a new backup copy of the current control file by issuing the fol-
lowing command:
ALTER DATABASE BACKUP CONTROLFILE TO
'D:\oracle\hot_bup\control.bak' REUSE;
4. To shut down the database, type shutdown immediate; and press Enter.
5. After the database is shut down, leave SQL*Plus open, and choose Start→
Run. In the Run text box, type D:\oracle\oradata\ora92 and click OK. A
window for the D:\oracle\oradata\ora92 folder will appear.
Delete all three control files from the folder. The files are named
CONTROL01.CTL, CONTROL02.CTL, and CONTROL03.CTL. Be careful
not to delete any other files in this folder.
6. Switch back to the SQL*Plus window.
The instance will start, but the database will not mount, and Oracle will dis-
play the message “ORA-00205: error in identifying controlfile, check alert
log for more info.”

admin\ora92\bdump folder from the Run text box.
Open the alert_ora92.log file, and scroll to the very bottom. The alert log
will show that the CONTROL01.CTL control file could not be found.
When you are done looking at the alert log, close Notepad and the window
for the bdump folder.
8. You will now use your backup control file to restore all three of the current
control files.
Open a window to the D:\oracle\hot_bup folder from the Run text box.
Copy the CONTROL.BAK file into the D:\oracle\oradata\ora92 folder.
Rename the CONTROL.BAK file to CONTROL01.CTL
Copy the CONTROL.BAK file into the D:\oracle\oradata\ora92 folder

two more times. Rename the new copies to CONTROL02.CTL and
CONTROL03.CTL respectively.
Once you have restored all three of your control files, the ora92 folder

should look similar to what is shown here. Close the ora92 window.
9. You will now mount the database and perform an incomplete database
recovery.
At the prompt, type ALTER DATABASE MOUNT; and press Enter.
10. To begin recovery, issue the following command:

Oracle will determine the SCN that is required for recovery, and will ask for
the archive log that contains that change.
11. Press Enter to accept the suggested archive log.
One of two possibilities may occur. Oracle will either find the suggested
archive log, apply it to the database, and ask for another log, or it will dis-
play a message stating that the specified archive log could not be found. If
the specified archive log is found and applied, press Enter again to apply
the next archive log. Keep pressing Enter repeatedly until Oracle dis-

plays the message that the archive log could not be found.
12. After failing to find the last archive log, Oracle may also display the follow-
ing messages:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS
would get error below
ORA-01152: file 1 was not restored from a sufficiently old
backup
If these messages are not displayed, then skip the remainder of this step
and go to step 13 to continue.
The ORA-01547 and ORA-01152 errors occur because the very last changes
that need to be applied to the database are still in the current redo log and
have not yet been archived. You will begin the recovery again, and you will
specify the online redo log for recovery instead of an archive log.


Again, Oracle will detect the SCN required for recovery and suggest an
archive log.
Instead of pressing Enter to accept the suggested archive log, type

D:\oracle\oradata\ora92\redo01.log and press Enter.
If Oracle states that it needs changes generated later than what is contained
in REDO01.LOG, then issue the RECOVER DATABASE USING
BACKUP CONTROLFILE UNTIL CANCEL; command again. This time,
specify D:\oracle\oradata\ora92\redo02.log as the archive log to apply. If
necessary, repeat the process again for the D:\oracle\oradata\ora92\
redo03.log.
Once all the required changes have been applied to the database, Oracle will
display the messages “Log applied” and “Media recovery complete.”

13. The database has been recovered, so you can now open the database. But
since you performed an incomplete recovery, you must open the database
with the RESETLOGS option.
At the prompt, type ALTER DATABASE OPEN RESETLOGS; and press

Enter.
After a few moments, Oracle will display the message “Database altered.”
You have just recovered from a complete loss of all copies of the current
control file.
14. To see the current log sequence number, type ARCHIVE LOG LIST; and
press Enter.
Your system may show that The output will show that the current log sequence number has been reset to
the oldest online log 1. Also, the oldest online log sequence has been set to 1, which means that
sequence number has been all archive log history has been removed from the control file.
set to 0, instead of 1.
15. Since you now have a new incarnation of the database, the previous control
file backup is useless. You should immediately back up the control file in
case there is another failure in the near future.

ALTER DATABASE BACKUP CONTROLFILE TO
'D:\oracle\hot_bup\control.bak' REUSE;

Loss of the Current Online Log Group
Losing a redo log group as a result of media failure can have different affects on
the database, depending on which group was lost. If a non-active redo log group
was lost, meaning a log group that has already been archived, there will be no
immediate affect on the database, and there will probably be no loss of data. The
log writer process will continue to write redo information from the log buffer to
the current log group without a problem. However, once the current log group
fills and Oracle attempts to switch the logs, if the next log group in the sequence
cannot be found, the instance will crash.
If media failure results in the loss of the current redo log group, the instance will
crash immediately. Although the changes written to the current log group may Recovery After Loss of
have been committed, Oracle will not have had the chance to archive those Current Redo Log Group
changes. All changes stored in the current log group will be permanently lost
with no hope of recovery. Your only recourse is to perform a point in time recov-
ery of the database to bring the entire database back in time to the moment just
before any of those lost changes were actually generated. Figure 3-4 illustrates
this concept.
Figure 3-4: Recovery after loss of the current redo log group.
In the top part of this figure, the database has been operating normally, perform-
ing log switches and archiving the logs as usual. Then, a media failure occurred
causing the loss of the current redo log group, which happened to be log
sequence 25. The instance crashed and all changes in this log group were perma-
nently lost.
The bottom part of Figure 3-4 shows the steps that were taken to recover the
database. The last full hot backup was restored, and the archive logs were applied
to recover the datafiles. However, the database can only be recovered to the point
in time just prior to log sequence 25 becoming the current log group, which
means you can only recover up to and including log sequence 24.

For loss of the current redo log group, it is recommended that you perform
cancel-based recovery to ensure that all available redo information is applied to
the database. Once all available redo information has been applied, you must
open the database with the RESETLOGS option. When the RESETLOGS com-
mand is issued, Oracle will reset the log sequence number to 1, and automatically
re-create any missing archive logs in the correct location using the information
found in the control file. This will ensure that the new incarnation of the database
can remain up and running.
TASK 3C-3
Recover From the Loss of the Current Online Log Group
Objective: To recover the database from the loss of the current online
redo log group.
1. To recover the database from the loss of the current online redo log group,
you must have a full hot backup of the database available. You will create
this backup now.
2. At the prompt, type @C:\079176\hot_backup_database.sql and press Enter.

This will launch a script that will perform a hot backup of all tablespaces,
and store the datafile copies in the D:\oracle\hot_bup folder. A blank com-
mand prompt window will appear as the datafiles are copied to the
destination folder.
It will take several minutes for the hot backup to complete. Once it’s com-
plete, the command prompt window will disappear, you will be returned to
the SQL*Plus prompt, and Oracle will display the message “Backup
complete.”

3. To demonstrate the affect of losing the current online redo log, you will cre-
ate a table with a single row, force a log switch, then add another row to the
table. You will then simulate the loss of the current redo log group. All
changes that occurred before the log switch can be recovered, but all
changes stored in the current group will be lost.
To determine which redo log group is the current group, type @C:\079176\
logfiles.sql and press Enter. The log sequence number
shown in your output may be
The STATUS column in the output will show which log group is the current different from what is shown
group. Additionally, the SEQ# column will show the log sequence number of here.
each group. The sequence number increments infinitely, and is used to iden-
tify the log file once it is archived. In the example shown here, the current
log group is log group 2, with a log sequence number of 2.
4. You will now create a small table.

CREATE TABLE test_log_fail (col1 VARCHAR2(5));
Oracle will display the message “Table created.”
Insert a row into the table with the following statements:

INSERT INTO test_log_fail VALUES('A');
COMMIT;
The redo information generated from the CREATE TABLE and INSERT
statements was first stored in redo log buffer, then written to the current redo
log group.
5. You will now force a log switch. The current online redo log will be
archived, and Oracle will switch to the next log group.

Enter.
To see which log group is now current, type @C:\079176\logfiles.sql and

press Enter.
The output will show that Oracle has switched to the next redo log group.
The redo log that contains the CREATE TABLE command and INSERT
statement has been archived. In this example, log group 3 is now the current
log group, which also has a log sequence number of 3. Log group 2 has
been archived.
6. You will now insert another row into the table.
At the prompt, issue the following statements:

INSERT INTO test_log_fail VALUES('B');
COMMIT;
7. At the prompt, type @C:\079176\logfiles.sql and press Enter.
The redo information for the CREATE TABLE command and the first
INSERT statement is stored in log group 2, which has been archived. The
redo information for the last row inserted was stored in the current online
log group, which is now log group 3. Losing the current online log group
will mean that all changes stored in that log group are permanently lost.
However, all changes in the previous group can be recovered from the
archive log.
Make a note of which log group is current, along with its log sequence
The group number of the number from SEQ# column.
current log group may be
different from the log
sequence number. This is
normal.

8. You will now simulate the loss of the current online redo log group.
At the prompt, type shutdown abort and press Enter.
Oracle will display the message “ORACLE instance shut down.”
9. Leaving SQL*Plus open, open a window to the D:\oracle\oradata\ora92

folder from the Run text box.
In the ora92 folder, find the redo log file of the current online redo log
group. In the used example here, the file would be REDO03.LOG. Select
REDO03.LOG.
Choose File→Rename. Change the .LOG extension to .OLD
A question box will appear asking if you are sure you want to change the
file extension. Click Yes.
The output will show that the instance was started and the database
mounted, but the database could not be opened because Oracle could not
find the current online redo log group.

11. To recover from this type of loss, you must restore all datafiles from backup
and perform an incomplete recovery up to the last archive log that was
generated. All changes stored in the current log group will be lost.
To perform a full restore of all datafiles, type @C:\079176\restore_database.

sql and press Enter.
A blank command prompt will appear while the backed up datafiles are cop-
ied to their original locations. The restore will take a few minutes to
complete.
Once the restore is complete, the command prompt will disappear, and
Oracle will display the message “Database restored.”
12. You will now perform the incomplete recovery of the database. At the
prompt, issue the following command:
RECOVER DATABASE UNTIL CANCEL;
Oracle will detect which archive log contains the changes needed for
recovery. You will apply all archive logs up to, but not including, the log
sequence number of the current log group, which you should have made
note of in step 7 from the SEQ# column of the logfiles.sql output. In the
example used here, the current log sequence number was 3.
Press Enter to accept the suggested archive logs until Oracle asks for the
log sequence number of the current log group. Do not press Enter for
the current log group. Instead, type CANCEL and press Enter.
Oracle will display the message “Media recovery cancelled.”

13. The database has been recovered to include all available changes. The cur-
rent online redo log group is no longer available, therefore its changes will
be lost.
At the prompt, type ALTER DATABASE OPEN RESETLOGS; and press

Enter.
After several moments, Oracle will display the message “Database altered.”
14. To see which changes were recovered and which were lost, you will now
query from the TEST_LOG_FAIL table.
At the prompt, type SELECT * FROM test_log_fail; and press Enter.
The output will show that only the first row, containing the value A, was
recovered. The second row, containing the value B, which was only stored in
the current online redo log group, was lost.
16. In the ora92 folder, you will see your original redo log file that you renamed
with the .OLD extension. However, you will also see that Oracle automati-
cally created a new file for the current online redo log when the ALTER
DATABASE OPEN RESETLOGS command was issued.
Close the ora92 window.

Read-only Tablespaces
There are some special considerations that you must take into account when
recovering a database that contains read-only tablespaces. Depending on the cir-
cumstances involved with the recovery, you may need to perform some extra
steps in order to recover after media failure. The recovery steps will be deter-
mined by whether you are recovering the database using the current control file
or a backup control file.
When you are using the current control file for recovery, recovering a database
Read-only Tablespace that contains read-only tablespaces is identical to performing any standard data-
Recovery With Current base recovery after media failure. You would simply take the following steps:
Control File 1. Restore only the lost datafiles from backup.
2. Mount the database.
3. Recover the database.
4. Open the database.
As long as you are using the current control file as the reference point, this
simple recovery can be done for any tablespaces in the database, regardless of
whether the tablespace is in read-write or in read-only. It can even be done if a
tablespace changed from read-write to read-only, or vice versa, after the last
backup was performed. The current control file will know which tablespaces are
in read-only and when they were set to read-only. The recovery process will
handle applying all redo information to the appropriate datafiles. If the status of a
tablespace had changed since the last backup, such as a read-only tablespace
being set to read-write, Oracle will know to apply the pertinent redo information
to the tablespace at the right point in time during recovery.
Things become increasingly more difficult if you must recover the database using
a backup control file. Chances are, if you have to restore your control file from
backup, the entire database is down and will need recovery after you have
restored the control file. The steps you take to perform the recovery will depend
on whether the status of the tablespaces in question have changed since the last
backup (from read-only to read write, and so on), and what the backup control
file knows about the tablespaces that need the recovery.
If a tablespace was in read-only at the time the last backup was taken, and the
tablespace was still in read-only at the point of failure, and you are recovering
with a backup control file, then you only have one additional step to take to per-
form a recovery of the database. The steps you would take are as follows:
1. Restore all datafiles and the control file from backup.
3. Take all read-only datafiles offline.
4. Perform cancel-based, time-based, or change-based incomplete recovery with
the USING BACKUP CONTROLFILE clause.
5. Open the database using the RESETLOGS option.
In this case, you are including the USING BACKUP CONTROLFILE, UNTIL,
and RESETLOGS options only because you are recovering the database with a
backup control file. However, the main difference between this recovery and a
recovery using the current control file is that you must take the datafiles from any
read-only tablespaces offline during the recovery. This is because the

RESETLOGS option causes Oracle to update the headers of all datafiles while
opening the database. If a read-only tablespace is left online, the ALTER
DATABASE OPEN RESETLOGS command will fail since Oracle cannot write to
the read-only datafiles. Once the database has been opened, you can then bring
the read-only tablespaces online.
If the status of a tablespace had changed after its last backup but before the
media failure, and you are recovering with a backup control file, then the recov-
ery process will be slightly different. If the tablespace was in read-write mode
during the last backup, but had changed to read-only mode prior to the media
failure, then you would follow these steps to recover the database:
1. Restore all datafiles and control file from backup.
In this case, both the control file and the tablespace in question were backed up
while the tablespace was still in read-write mode. This means that after restoring
the backup control file, Oracle will read the newly-restored control file and
believe that the tablespace is currently in read-write mode. Although this
tablespace was in read-only at the point of failure, you should leave this
tablespace online so Oracle can apply its changes for the period of time while the
tablespace was in read-write mode. During the roll forward phase of recovery,
Oracle will apply all pertinent redo information to the tablespace up to the point
in time that the tablespace was put in read-only. After this point in time, there
will be no more redo information that needs to be applied to that tablespace
because no changes in the tablespace could have occurred. However, Oracle will
not set the tablespace back to read-only until after the database is opened with the
RESETLOGS option.
In the final scenario, the tablespace was in read-only mode at the time of the
database backup, but was set to read-write mode prior to the point of failure, and
you are recovering the database using the backup control file. In this case, the
backup control file only knows that the tablespace was in read-only. Once the
control file is restored and the database is mounted, Oracle will believe the
tablespace is still in read-only and will not try to apply any redo information
from the archive logs to the tablespace. Therefore you should not use this backup
control file to recover the tablespace. You should only use a backup control file
that was created at a point in time after the tablespace was set to read-write. This
will allow Oracle to apply the pertinent redo information to recover the
tablespace. To perform a recovery in this scenario, you would take the following
steps:
1. Restore all datafiles from backup.
2. Restore the backup control file that was generated after the tablespace in
question was set to read-write.

If you do not have a backup control file from after the tablespace was set to read
only, you will need to re-create the control file manually using the commands
found in the control file backup trace file. In this case, you will need to edit the
trace file to indicate that the tablespace in question is currently in read-write
mode. You would then take the following steps to perform the recovery:
2. Start up the databases in the nomount state.
3. Execute the CREATE CONTROLFILE command found in the control file
backup trace file to re-create the control file.
In this case, you are manually re-creating the control file, which gives you the
opportunity to tell Oracle exactly what you want it to know about the tablespaces.
By editing the trace file, you take out any information that would indicate that the
tablespace in question is currently in read-only mode. This enables Oracle to
write to the tablespace so it can apply the necessary redo information to its
datafiles. However, re-creating the control file should only be used as an absolute
last resort when recovering the database. You should take sufficient steps to pro-
tect the control file against media failure by multiplexing it across multiple disks.
You should also maintain the habit of backing up the control file every time the
structure of the database changes, such as adding tablespaces or datafiles, or when
the status of a tablespace changes from read-write to read-only or vice versa.
TASK 3C-4
Identify Recovery Considerations for Read-only
Tablespaces
1. The USERS tablespace was placed in read-only mode at 4:00 P.M. The
last backup of the control file and the USERS datafiles occurred at 5:00
P.M. A disk failure results in the loss of all the datafiles of the USERS
tablespace and all copies of the control file. How would you recover
from this failure?
Since the current control file is lost, you must use the backup control file for
this recovery. Since the control file was backed up after the tablespace was
placed in read-only mode, the backup control file knows that the USERS
tablespace is in read-only mode. You only need to restore the backup control
file and the USERS datafiles, take the USERS datafiles offline, and perform a
standard database recovery, then open the database using the RESETLOGS
option. Once the database is open, you can bring the USERS tablespace
back online to make it available for use.

2. When performing a recovery of the database using a backup control file,
why must all read-only datafiles first be taken offline?
Recovering the database using the backup control file consists of an incom-
plete recovery, and will require opening the database with the RESETLOGS
option. When the RESETLOGS option is specified with the ALTER
DATABASE OPEN command, Oracle will write updated information to the
headers of all datafiles. If any datafiles of read-only tablespaces are online,
Oracle will also attempt to update the headers of these files, but the process
will fail, causing the ALTER DATABASE OPEN command to fail as well.
Taking read-only datafiles offline will ensure that Oracle does not try to
write to the files, and the ALTER DATABASE OPEN command will
succeed.
3. Given the following scenario, which control file would you use to recover
the EXAMPLE tablespace? Explain your answer.
• A full, hot backup was executed at 10:00 A.M. All tablespaces were in
read-write mode at that time, with the exception of the EXAMPLE
tablespace, which was in read-only mode.
• The hot backup included all datafiles, a standard backup of the control
file, and a backup of the control file to trace.
• The EXAMPLE tablespace was placed in read-write mode at 1:00 P.M.
• The database suffered media failure at 3:00 P.M., which resulted in the
loss of all copies of the current control file and all the datafiles of the
EXAMPLE tablespace.
In this scenario, as in most recovery scenarios, the ideal solution is to use
the current control file, since it will contain the most current information
about all datafiles in the database. However, since the current control file is
not available in this case, this is not an option.
The backup control file that was created at 10:00 A.M. only contains infor-
mation about the datafiles as they existed at that point in time. Since the
EXAMPLE tablespace was in read-only mode at the time the backup was
taken, the backup control file will reflect that information. If the backup con-
trol file is used for recovery, the EXAMPLE tablespace will be treated as if
it’s still in read-only mode, and none of the transactions that occurred in
that tablespace after it was set to read-write mode will be recovered.
Since there is currently no control file, current or backup, that contains the
information that the EXAMPLE tablespace was ever in read-write mode, the
only other option is to create a new control file by using the script stored in
the control file backup trace file generated at 10:00 A.M. The script can be
modified to reflect the existing configuration of the database and can be used
to create a new control file that will allow the full recovery of the
EXAMPLE tablespace.

Tablespace Point-in-Time Recovery
As you learned earlier, you cannot recover just a single datafile or tablespace to a
different point in time than the rest of the database. There may be some occa-
sions, however, where you may want to do just that. You may need to bring a
single tablespace back to a certain point in time, say just before a user dropped a
critical table, but you want to preserve the current changes in all other
tablespaces.
This type of operation is not possible within a single database. You can perform
this type of recovery by using a hot backup of the original database to create a
clone database. This clone database is created by restoring the hot backup of the
clone database: original database to a different location, possibly on a different server, and per-
A database created by forming a cancel-based, time-based, or change-based recovery. You have the
restoring and recovering the option of restoring the entire backup if you like. At a minimum, however, you
hot backup of another
database to another location.
must restore the following files:
• All backup copies of the datafiles of the affected tablespace you wish to
recover.
• All backup copies of the datafiles of the SYSTEM tablespace taken from the
same backup set as the affected tablespace datafiles previously listed.
• A parameter file.
• Some form of the control file from the original database (backup control file
or control file trace file).
• All archive logs generated that include the time the backup in question was
performed until the point in time to which you wish to recover the affected
tablespace.
Figure 3-5 illustrates the concept of creating a clone database from a database hot
backup.
Tablespace Point-in-Time
Recovery
Figure 3-5: Cloning a database for tablespace point-in-time recovery.

In this figure, a hot backup of the database was performed, which included the
control file, all datafiles, and the archive logs. This backup also included the
parameter file, which has been excluded for clarity. The backup files were
restored to another server, essentially creating a clone database that is identical to
the original database. The archive logs were applied to clone database to perform
a point-in-time recovery. The recovery was stopped at the precise moment where
the DBA wanted to recover the database to, using the BACKUP CONTROLFILE
and UNTIL TIME options.
Once the database is restored to the point in time desired, you would open the
clone database with the RESETLOGS option, and then use one of several methods
to move the data in the target tablespace back over to the original database. For
example, you can use the export and import utilities, transportable tablespaces,
the SQL*Plus COPY command, or pull the data from the clone back to the origi-
nal database through a database link. The method you use will be dependent on
the amount of data you wish to capture and how fast you need to get it back to
the original database. In most cases, transportable tablespaces is the fastest and
easiest method to use if you want to move entire tablespaces back to the original
database.
TASK 3C-5
Describe Tablespace Point-in-Time Recovery
1. Is it possible to recover a tablespace to a different point in time than
that of the rest of the database? Explain your answer.
Technically, it is not possible to recover a tablespace to a different point in
time than that of the rest of the database. Oracle will only consider a
tablespace recovered when it is consistent with the rest of the database. If
you stop a tablespace recovery before it becomes consistent with the data-
base, Oracle will return an error when you attempt to bring the tablespace
online.
2. When cloning a database for the purpose of performing a tablespace

point-in-time recovery, at a minimum, what files from the original data-
base are required?
The files you would need to clone the original database include:
• All backup copies of the datafiles of the affected tablespace you wish to
recover.
• All backup copies of the datafiles of the SYSTEM tablespace taken from
the same backup set as the affected tablespace datafiles previously
listed.
• A parameter file.
• Some form of the control file from the original database (backup control
file or control file trace file).
• All archive logs generated that include the time the backup in question
was performed until the point in time to which you wish to recover the
affected tablespace.

Summary
In this lesson, you learned how to perform a user-managed full hot backup
of the database and how to use that backup to perform a user-managed com-
plete recovery of the database after a failure. Additionally, you learned how
to perform a user-managed incomplete recovery to recover the database after
various failure scenarios, such as loss of the control file or the current redo
log group.
Lesson Review
3A What happens internally in the database when a tablespace is placed in
hot backup mode?
While a tablespace is in hot backup mode, all changes to datablocks that are
stored in the tablespace are still written from the buffer cache to the datafiles
by the DBWR process when checkpoints occur. However, the checkpoints are
deferred for tablespace in hot backup mode. This means that CKPT does not
update the headers of the datafiles of a tablespace while that tablespace is
in hot backup mode. When the tablespace is taken out of hot backup mode,
Oracle simply advances the tablespace’s datafile headers to the latest check-
point to bring them up to date with the rest of the database.
What happens when the following command is issued?

Oracle will generate a trace file in the directory specified by the USER_
DUMP_DEST parameter. This trace file will contain the necessary
commands required to re-create the control files and get the database up and
running in the event that media failure causes the loss of all copies of the
current control file.
If the instance crashes while a tablespace is in hot backup mode, why

will Oracle assume the tablespace requires recovery upon instance
startup?
When a tablespace is placed in hot backup mode, checkpoints are deferred
for that tablespace, which means that the datafile headers will not contain
the most current SCN from the control file. If the instance were to crash with
the tablespace in hot backup mode, then the files will still contain the old
SCN. Upon restarting the instance, Oracle will detect the old SCN in the
affected datafiles, and will assume that the datafiles need recovery.
3B What is wrong with the following command?

RECOVER TABLESPACE example, DATAFILE
'D:\oracle\oradata\ora92\users01.dbf;'
You cannot include both the TABLESPACE and DATAFILE options within a
single RECOVER command.

True or False? Even if you include the ALLOW n CORRUPTION clause
with the RECOVER command, the block corruptions will still exist in the
datafiles after the recovery is complete. Explain your answer.
True. The ALLOW n CORRUPTION clause is provided only as a means to
move past a block corruption issue to finish the recover process. The corrup-
tions will still exist when you bring the recovery target online. Any
subsequent attempts to access those datablocks through normal database
operations will result in an error.
What step must you take from within Oracle after restoring a datafile to
a location that is different from its original location?
a. Bring the tablespace online.
✓ b. Change Oracle’s internal pointer to the file.
c. Bring the tablespace offline.
d. Recover the tablespace
3C The current time is 8:15 A.M. The last hot backup of your database was
completed today at 6:30 A.M. Which one of the following times is valid
to use for an incomplete recovery?
a. 7:15 P.M.
b. 8:38 A.M.
c. 8:25 P.M.
✓ d. 8:14 A.M.
You have restored the control file from backup and applied all archive
logs that were generated between the point in time the backup was
taken and the point of failure. However, when issuing the CANCEL com-
mand, Oracle returned the following error. Why? How would you
resolve it?
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS
would get error below
ORA-01152: file 1 was not restored from a sufficiently old
backup
This error is caused by Oracle believing that there are more changes that
can be applied to the database, even though you have applied all available
archive logs. It is possible that the current online redo log contains the miss-
ing changes, but Oracle did not have a chance to archive this log prior to
the media failure that caused the instance to crash. To work through this
error, the recovery can be started again and the current online redo log
group can be specified for recovery instead of an archive log. If the current
log group contains the changes, Oracle will apply them to the database.

Which type of user-managed incomplete recovery is recommended for
media failure that causes the loss of the current redo log group?
a. Change-based recovery
b. Time-based recovery
✓ c. Cancel-based recovery
d. Manual-based recovery
You are performing a recovery of a database that contains a read-only

tablespace. The tablespace was read-write during the last hot backup,
but was set to read-only prior to the point of failure. You are perform-
ing the recovery with a backup control file. At what point during the
recovery process will Oracle put the tablespace back in read-only.
a. When the ALTER TABLESPACE command is found in the archive
logs during recovery.
✓ b. When the database is opened with the RESETLOGS option after
recovery.
c. Just prior to starting recovery.
d. None of these; the tablespace will remain offline throughout the
entire process.

Recovery Manager Backups LESSON
Overview
4
Data Files
Manually performing all backup and recovery operations for the database is none
considered user-managed backup and recovery. However, Oracle provides a
powerful utility called Recovery Manager, better known as RMAN, which Lesson Time
provides the capability to create a centralized solution to handle all backup 7 hours
and recovery operations for all Oracle databases in a single environment. In
this lesson, you will learn about the features RMAN provides and its archi-
tecture and process flow. You will also learn how to configure RMAN, how
to use it to perform server-managed hot and cold backups, and how to main-
tain its centralized information repository.
Objectives
To perform backups of the database using RMAN, you will:
4A Describe the RMAN environment and the basic steps RMAN uses to
back up and recover an Oracle9i database.
RMAN provides a powerful, centralized solution to simplify backup and
recovery operations for all Oracle databases in an environment. In this
topic, you will learn about the features of RMAN, its centralized informa-
tion repository, and the process flow RMAN uses to perform backups and
recoveries. You will also learn about the different types of backup sets
that RMAN creates and how to decide which type of backup set to use
for various backup and recovery strategies.
4B Configure the RMAN environment, and prepare a database for

RMAN backups.
Before you can take advantage of the backup and recovery capabilities
that RMAN provides, you must first configure the RMAN environment.
This includes preparing the RMAN repository and the target databases. In
this topic, you will learn how to set up the RMAN components, and how
to configure RMAN to begin backing up and recovering databases.
4C Back up the database using RMAN.

RMAN provides a wealth of options to choose from when backing up a
target database. You can perform hot and cold backups, image copy back-
ups, and incremental hot backups. You can also back up the archive logs
and automatically delete them from the disk after they are backed up. In
this topic, you will learn how to perform all of these backups using the
RMAN utility.
Lesson 4: Recovery Manager Backups 205

4D Maintain and manage the RMAN recovery catalog.
The RMAN recovery catalog provides RMAN with a wealth of
capabilities. In this topic, you will learn how to create and manage
backup and recovery scripts in the recovery catalog and how to generate
RMAN reports and lists about target databases and their backups. You
will learn how to add backup information about user-managed backups to
the recovery catalog and also how to delete obsolete backups and purge
their related entries from the catalog. Finally, you will learn how to
backup the recovery catalog itself using various techniques.

Topic 4A
RMAN Architecture
The Recovery Manager utility, better known as RMAN, is a powerful utility that
provides a comprehensive suite of features to simplify all Oracle backup and
recovery operations for an environment. It can be installed and configured on any
server on the network and can perform cold and hot backups and recoveries of RMAN Features
any and all Oracle databases on that same network, regardless of which platform
the target database is installed on. This allows the DBA to configure a single,
centralized backup and recovery solution.
RMAN maintains its own centralized repository to store backup and recovery
information for all databases in the environment that RMAN supports. It has its
own command-line interface to perform all operations, or it can be invoked from
the Oracle Enterprise Manager graphical interface. Using the command-line inter- MML:
face, the DBA can create and execute backup and recovery scripts and can store (Media-management layer)
them in RMAN’s repository for use at any time. Backup and recovery jobs can Third-party backup utilities
that can integrate with RMAN
be scheduled using any third-party scheduling utility to execute these stored to help perform backup and
scripts. With OEM, the DBA can easily configure custom backup and recovery recoveries of the database.
jobs and can schedule them to execute using OEM’s scheduling features, which
eliminates the need to even write RMAN scripts. RMAN can also be configured
to work with third-party backup utilities, collectively called the media-
management layer (MML), such as Legato Networker or Veritas NetBackup. For
these utilities, RMAN would initiate a backup or restore job and make custom
calls to an application program interface (API). The API would instruct the MML
utility to back up files directly from disk to tape or restore files from tape to disk.
RMAN would maintain all information about each backup and recovery operation
in its own repository, regardless if RMAN performed the operation itself, or if the
operation was performed by an MML utility.
To provide maximum power and flexibility, RMAN has several configuration
parameters that can be set globally for all backup and recovery operations for the
environment, and several target-specific parameters that can be set to customize
operations based on the target being backed up or recovered. The DBA can also
configure certain conditions that allow RMAN to optimize certain backup and
recovery operations. For example, the DBA can instruct RMAN to back up all
datafiles that have not been backed up since a certain date or time using a single
command. This is especially useful if multiple datafiles have been added to a
database, but a full backup was already created for that database just recently.
Instead of backing up the entire database again, the DBA can instruct RMAN to
backup these new datafiles in a single operation without having to list each file
separately.
To minimize the size of the backup files created for a database backup, RMAN
will only back up datablocks in each datafile that have changed since the datafile
was created. For example, let’s say a new tablespace was created with a single
datafile that was sized to 50 megabytes. If only 10 megabytes of the datafile were
ever allocated to segments, such as tables and indexes, then only those 10 mega-
bytes are added to the backup. Any datablocks within the file that have never
changed will not be added to the backup. It’s important to note that datablocks
that have changed may or may not have data in them. If a table was created that
allocated 20 megabytes in the file, then the table was subsequently dropped, those
20 megabytes of datablocks will be empty, but will be considered changed
datablocks. Those blocks will be added to the backup set even if they are empty.

To minimize the impact on a target database during a hot backup, RMAN does
not have to put tablespaces into backup mode. This can greatly reduce the
amount of redo information the target database would generate while the
tablespaces were in backup mode. Additionally, RMAN can perform incremental
backups of datafiles, which allows RMAN to back up only those datablocks
which have actually changed since the last time the database was backed up. This
can greatly reduce the amount of time it takes to back up a very large and active
database. Hot incremental backups can be performed on databases that are run-
ning in ARCHIVELOG mode, and cold incremental backups can be performed on
databases running in NOARCHIVELOG mode.
Performing restore and recovery operations is where RMAN shows its real power.
During a user-managed restore and recovery, the DBA would need to determine
exactly which files were lost and need recovery and which backup copies are
valid to use for recovery. The DBA would also need to identify and locate the
appropriate archive logs a recovery operation will need, all of which takes time.
RMAN can automatically inspect the target of the recovery and within seconds
determine which files need to be restored, then look in its repository to locate
where in the backup location those files reside, automatically restore them, and
then identify, locate, and restore all archive logs required to perform the recovery.
This entire operation can be performed with a single command from the DBA.
Additionally, RMAN can automatically detect datablock corruption, either within
a live datafile or within a backup datafile, and take steps to correct the problem,
all while keeping the live datafile online.
RMAN also has the ability to automatically clone an entire database from a hot
backup of an original database with a few simple commands. This allows the
DBA to easily duplicate a database one or more times from a single database. It
also provides RMAN with the capability to automatically perform tablespace
point-in-time recoveries of the original database. With a few simple commands
and some minor preparation, the DBA can use RMAN to create a clone of the
original database, recover the clone database to a specific point in time, and pre-
pare the clone to create a transportable tablespace set to copy the recovered data
back to the original database. All operations for tablespace point-in-time recovery
are handled automatically by RMAN and can easily be repeated multiple times if
necessary.
TASK 4A-1
List and Describe RMAN Features
1. How can RMAN be used to simplify the automation of database backup
procedures?
Using the command-line interface, the DBA can create and execute backup
and recovery scripts and can store them in RMAN’s repository for use at
any time. Backup and recovery jobs can be scheduled using any third-party
scheduling utility to execute these stored scripts. With OEM, the DBA can
easily configure custom backup and recovery jobs and schedule them to
execute using OEM’s scheduling features, which eliminates the need to even
write RMAN scripts.

2. True or False? Every database in an environment requires its own
RMAN configuration to allow backing up that database with RMAN.
False. RMAN can be installed and configured on any server on the network
and can perform cold and hot backups and recoveries of any and all Oracle
databases on that same network, regardless of which platform the target
database is installed on. This allows the DBA to configure a single, central-
ized backup and recovery solution.
3. What feature does RMAN provide to reduce the amount of time it takes
to perform a backup of a large database?
RMAN can perform incremental backups of datafiles, which allows RMAN to
back up only those datablocks which have actually changed since the last
time the database was backed up. This can greatly reduce the amount of
time it takes to back up a very large and active database. Hot incremental
backups can be performed on databases that are running in ARCHIVELOG
mode, and cold incremental backups can be performed on databases running
in NOARCHIVELOG mode.
4. How does RMAN simplify the restore and recovery process of a data-
base that has experienced media failure?
RMAN can automatically inspect the recovery target and, within seconds,
determine which files need to be restored, then look in its repository to
locate where in the backup location those files reside, automatically restore
them, and then identify, locate, and restore all archive logs required to per-
form the recovery. This entire operation can be performed with a single
command from the DBA.
The RMAN Repository

At the core of the RMAN architecture is the RMAN repository, which RMAN
uses to store all pertinent information about each database in the environment it The RMAN Repository
supports. For each database, the repository includes the database’s current physi-
cal structure, such as the names and locations of all datafiles, control files, and
archive logs. It also includes the entire backup and recovery history for each
database, which includes the names and locations of all backup sets, and informa-
tion about every incarnation of each database if the database was ever opened
with the RESETLOGS option. Figure 4-1 illustrates the concept of the RMAN
repository.

Figure 4-1: The RMAN repository.
In this figure, RMAN connects to each target database in the environment to per-
form backup and recovery operations. All information pertaining to each target
database and its backups and recoveries are stored in the RMAN repository.
RMAN requires the repository to perform almost all of its operations, and this
repository can be decentralized by storing RMAN information in each target data-
base’s control file, or it can be centralized in a single database schema known as
the recovery catalog.
The Control File as the Repository

When using the control file of each target database as the repository, each control
file holds only the pertinent backup and recovery information for its own
database. Using the control file may be ideal for smaller environments where
there are only a few databases that need to be backed up. The control file con-
tains the following information to support RMAN operations:
• Basic information about the database, such as the database name and data-
base incarnations.
• Basic RMAN configuration parameters specific for that target database.
• Names and locations of redo log groups and their file members.
• Names of tablespaces and names and locations of their datafiles.
• Archive log history.
• Names and locations of backup files.
• Information about corruptions found in backup files.

The control file may expand to hold the information necessary to support RMAN
information. How much it grows will depend on how often the database generates
archive logs, how often the target database is backed up, and the size of the tar-
get database. To limit the size of the control file, Oracle stores both non-circular
reuse records and circular reuse records. Noncircular reuse records are kept in the
control file indefinitely and are used to store information about the database itself,
datafiles, and online redo logs. This information is critical to the operation of the
database and is never overwritten.
Circular reuse records are continuously generated by the target database and con-
tain information that is not critical for database operation. This information
includes the log sequence number history, archive log history and datafile backup
information. These records are considered circular because Oracle will overwrite
the information after a specific period of time, which can be set to restrict the
growth of the control file by the CONTROL_FILE_RECORD_KEEP_TIME
intialization parameter. The default value for this parameter is 7, which means
that any circular reuse records that are older than seven days are eligible for
overwriting. Prior to writing any new information to a circular reuse record in the
control file, Oracle will first look to see if any older records have expired. If they
have, Oracle will reuse those records by overwriting the old information. If no
record is expired, Oracle will expand the size of the control file to accommodate
the new records. Any time the control file must be expanded, Oracle will make an
entry in the alert log. The higher the value you set for the CONTROL_FILE_
RECORD_KEEP_TIME parameter, the more information Oracle will keep in the
control file, and the larger the control file may grow. The lower the value, the less
information Oracle will keep in the control file, which causes Oracle to overwrite
information more often. The value you choose for this parameter will depend on
the requirements of your backup and recovery strategy. If you need to keep
backup and recovery information longer, you can increase this parameter. You
should not need to worry about the overall size of the control file; even if you
keep backup information for several weeks, the control file will still stay rela-
tively small compared to most datafiles. The V$CONTROLFILE_RECORD_
SECTION data dictionary view provides a current listing of all the information in
the control file. The following example query shows a typical output from this
view.
SQL> SELECT type, record_size, records_used
2 FROM v$controlfile_record_section;
TYPE RECORD_SIZE RECORDS_USED
-------------------- ----------- ------------
DATABASE 192 1
CKPT PROGRESS 4084 0
REDO THREAD 104 1
REDO LOG 72 3
DATAFILE 180 13
FILENAME 524 17
TABLESPACE 68 14
TEMPORARY FILENAME 56 1
RMAN CONFIGURATION 1108 5
LOG HISTORY 36 57
OFFLINE RANGE 56 7
ARCHIVED LOG 584 65
BACKUP SET 40 33
BACKUP PIECE 736 33

BACKUP DATAFILE 116 53
BACKUP REDOLOG 76 0
DATAFILE COPY 660 4
BACKUP CORRUPTION 44 0
COPY CORRUPTION 40 0
DELETED OBJECT 20 15
PROXY COPY 852 0
BACKUP SPFILE 36 30
DATABASE INCARNATION 56 2
23 rows selected.
The Recovery Catalog as the Repository

Instead of using a decentralized method of storing the RMAN repository, RMAN
also allows you to create a centralized repository in a standard Oracle database
schema, which is called the recovery catalog. It is recommended that the recov-
recovery catalog: ery catalog, rather than control files, be used as the repository in all the simplest
A database schema that can of backup and recovery environments. The contents of the recovery catalog
act as the backup and include:
recovery information
repository for RMAN. • Stored backup and recovery scripts.
• RMAN persistent configuration settings, some of which are target database
specific.
• Backup and recovery history of each target database.
• Backup retention policies for each target database.
• Names and locations of all current control files and datafiles for each target
database.
• Names and locations of all backups generated for each target database.
• Names, locations, and SCN ranges of all archive logs for each target
database.
The recovery catalog contains all of the same backup and recovery related infor-
mation as the control file, but has several advantages over using the target
databases’ control files. A single recovery catalog can store backup and recovery
information for all Oracle databases in the environment, and the information for
each target database in a location independent from the target database itself. If
the target database’s control file is unavailable due to media failure, then RMAN
cannot be used to recover that database. The recovery catalog stores information
about all incarnations of each target database, which allows you to recover a
database from any incarnation of that database. Since the recovery catalog con-
tains a complete history for each target database, historical lists and reports can
be generated from the recovery catalog about each database and their backups.
The recovery catalog also contains self-configuration information for the RMAN
utility, such as global configuration parameters that RMAN will use for every
backup and recovery operation for all target databases. It may also contain con-
figuration parameters that are specific to each target database, allowing the DBA
to customize backup and recovery operations per database. Additionally, the
recovery catalog can be used as a convenient location to store RMAN backup and
recovery scripts, which can be executed from within RMAN itself simply by
passing the name of the script.

TASK 4A-2
Describe the RMAN Repository and its Contents
1. True or False? The RMAN utility requires a repository to store backup
information for each database it backs up. Explain your answer.
True. RMAN must be able to store and retrieve backup information for all
databases it backs up. This information is used during backup and recovery
operations to determine which files need to be backed up or restored. This
repository can either reside in a centralized database schema known as the
recovery catalog, or decentralized in the control files of the target databases.
2. Which initialization parameter specifies how long backup and recovery

information will be stored in the control file?
a. ARCHIVE_LAG_TARGET
✓ b. CONTROL_FILE_RECORD_KEEP_TIME
c. FAST_START_MTTR_TARGET
d. TIMED_STATISTICS
3. Name three or more types of information stored in the RMAN recovery

catalog.
RMAN stores an extensive amount of information in the recovery catalog,
and includes, but is not limited to:
• Stored backup and recovery scripts.
• RMAN persistent configuration settings, some of which are target data-
base specific.
• Backup and recovery history of each target database.
• Backup retention policies for each target database.
• Names and locations of all current control files and datafiles for each
target database.
• Names and locations of all backups generated for each target database.
• Names, locations, and SCN ranges of all archive logs for each target
database.
RMAN Process Flow

Regardless of whether the target database’s control file or the recovery catalog is
used as the repository, RMAN uses a standard set of processes to perform
backup, restores, and recoveries of the target database. If the recovery catalog is
used, the target database must first be registered with the recovery catalog, which
is done manually by the DBA when preparing RMAN to support that target.
Upon registering with the recovery catalog for the first time, RMAN will read all
the necessary information about the target database, such as names and locations
of all files and archive log history, and load that information into the recovery
catalog.

Prior to most backup and recovery operations, RMAN will resynchronize the
recovery catalog with the target database to obtain the most current information
about the target to keep the recovery catalog up to date. If the control file is used
as the repository, registration and resynchronization of the target database is not
necessary, since a control file will contain only the information for its own data-
base and will already be up to date. When resynchronizing the recovery catalog,
RMAN will automatically determine whether it needs to perform a partial or full
resync with the target database. During a partial resync, RMAN will read the
control file of the target database to update the catalog with only data that has
changed since the last backup or recovery operation. During a full resync, RMAN
will update all configuration entries for the target database, which includes file
names and locations and the archive log history.
The RMAN utility must have a valid Oracle user account and password for each
target database it supports, and the account must have the SYSDBA role. RMAN
uses this account to log in to the target database to read from the data dictionary
and control file and to start up and shut down the database during backup and
recovery operations. The user can be named anything you want, but it is recom-
mended that you use the same user name for all target databases for simplicity,
even if the passwords are different for each database.
The Backup Process Flow

RMAN can perform both cold and hot backups of the target database and can do
so when using either the control file or the recovery catalog as the RMAN
repository. While a hot backup allows the database to stay up and running, an
RMAN cold backup of the database requires that the database be mounted but not
opened. As long as RMAN’s account for the target database has the SYSDBA
role, you can shut down, mount, or open the target database right from within
RMAN.
Regardless of whether you are performing a hot or cold backup, or whether you
RMAN Backup Process are using the control file or recovery catalog as the repository, RMAN follows
Flow these steps to perform a database backup:
1. Connect to the target database and the repository.
2. Shut down the target database and start up in mount mode, if performing a
cold backup.
3. Allocate a communication channel.
4. Issue a backup command, which can specify one or more datafiles, a
tablespace, the entire database, the control file, or the archive logs.
5. Locate the target files specified by the backup command.
6. Copy the target files to the backup location.
7. Update the entries in the repository.
8. Deallocate the communications channel.
For step one, RMAN connects to the target database using its assigned user
account. If the control file is used as the repository, this is the only connection
that is needed, since all the information RMAN needs can be read out of the data
dictionary or directly from the control file. If the recovery catalog is used as the
repository, RMAN connects to the database where the repository is located using
its assigned user account.
If RMAN is performing a cold backup, it will execute step two, which is to shut
down the database and start it back up in mount mode. If RMAN is performing a
hot backup, the database can stay up and running.

For all backup and recovery operations, RMAN must allocate a communication
channel. This communication channel is a dedicated connection to the target data-
base and is used to perform the work of copying files to the backup destination,
restoring files, and performing recovery of the target database. This connection is communication channel:
additional to the initial connection to the database, which is used solely to update A dedicated connection
the repository with the latest backup and recovery information for the target. between RMAN and the
target database
When the channel is allocated for backups, it includes the backup destination
where the backups are to be created.
Once a channel has been allocated, the backup command can be issued for step
four. This backup command can specify one or more datafiles, one or more
tablespaces, the entire database, or the control file. The command can also
include one, a range, or all archive logs to backup. You can instruct RMAN to
backup just the archive logs or perform any other type of backup and include the
archive logs with it. If Oracle has been configured to archive the redo logs to
multiple destinations, RMAN will only include one copy of each archive log in
the backup set. RMAN can also accept further instructions to delete the archive
logs from the source location to remove them from disk after they have been
backed up. This provides a convenient method of automatically removing backed
up archive logs so the DBA doesn’t have to do it manually.
Once the backup command is issued, RMAN will proceed to step five, which
involves looking in its repository to find the paths and file names of the files it
must back up. RMAN will verify that the specified files indeed exist in that loca-
tion, and then proceed to step six, which is to copy target files to the backup
destination specified in the channel configuration. As the backup command is
executed, RMAN will perform step seven, which is to update the repository with
the information about the newly created backup set. Once the backup operation is
complete, the communication channel is automatically deallocated, meaning the
Oracle session in the target database for that channel is automatically
disconnected.
The Restore Process Flow

RMAN can restore lost files while the target database is either up or down. If the
recovery catalog is used as the repository, then RMAN can restore the control file RMAN Restore Process
of the target database. However, if the control file is used as the repository, then Flow
RMAN will only be able to restore lost datafiles of the target database, but not a
lost control file. When performing a restore operation, RMAN follows these
steps:
1. Connect to the target database and the repository.
2. Shut down the target database and start up in mount mode, if performing a
cold restore.
3. Allocate a communication channel.
4. Check the repository to determine the correct current configuration of the
target database.
5. Compare the repository’s version of the target database’s configuration to the
files that actually exist to determine which files are missing.
6. Find the backup files in their backup location.
7. Copy the backup files from their backup location to their original location, if
it is still available, or to an alternative location if the original location is not
available.
8. Update the entries in the repository.
9. Deallocate the communications channel.

Regardless of whether the control file or recovery catalog is used as the reposi-
tory, RMAN will first determine what the correct configuration of the database is
supposed to be by looking in the repository. It will then compare the list of files
in what it believes to be the correct configuration to the list of files that actually
exist on the target database’s file system. If any files are missing, RMAN will
automatically locate backups of those files in the backup location and copy them
back to their original location on the file system. If the original location on the
file system is not available due to media failure, the DBA must specify a new
location where the files will go. Most of the restore process will be handled auto-
matically, which can greatly reduce mean time to recovery. RMAN will not
restore any archive logs during the restore process unless specifically told to do
so. The necessary archive logs can be restored automatically during the actual
database recovery process, which is usually more efficient, since RMAN can
determine exactly which archive logs it will need for recovery.
The Recovery Process Flow

RMAN can perform any type of recovery, including datafile, tablespace, or whole
database recoveries. It can also perform complete or incomplete recoveries. When
performing database recovery, RMAN simply issues the same RECOVER com-
mands the DBA would when performing user-managed recovery. The difference
is that RMAN will automatically determine which archive logs, if any, are neces-
sary to perform the recovery, and automatically find and restore them from
backup as needed. RMAN can optionally delete all archive logs it restores as they
are applied to the database to keep disk usage at a minimum. Also RMAN will
automatically handle any read-only tablespace issues, such as taking the read-only
datafiles offline prior to recovery, and bringing them back online after recovery.
The automatic management of archive logs and read-only tablespaces can greatly
simplify the recovery process and reduce mean time to recovery. Once the recov-
ery is complete, RMAN can open the database, including the RESETLOGS option
if necessary, and update the repository with the most up to date information about
the target database.
TASK 4A-3
Describe the RMAN Process Flow
1. After connecting to both the target database and the repository, what
must RMAN do before performing any backup or recovery operations
on the target database?
a. Verify all control files and datafiles.
b. Update the repository.
c. Backup the control file.
✓ d. Allocate a channel.

2. How many server processes are invoked for each channel allocated
between RMAN and a target database?
a. Zero.
✓ b. One.
c. Two.
d. The number is dynamic based on the number of datafiles to be
backed up.
3. Exactly what does RMAN do when it performs a resync with a target

database?
When resynchronizing the recovery catalog, RMAN will automatically deter-
mine whether it needs to perform a partial or full resync with the target
database. During a partial resync, RMAN will read the control file of the
target database to update the catalog with only data that has changed since
the last backup or recovery operation. During a full resync, RMAN will
update all configuration entries for the target database, which includes file
names and locations and the archive log history.
Image Copies and Backup Sets

When backing up the Oracle database, RMAN takes datafiles, control files, spfile,
and archive log files as input and creates some sort of output which will be stored
in the backup destination. The type of output generated will be determined by the
commands the DBA issues to RMAN and can be either image copies or backup image copy:
sets. Image copies are standard bit-for-bit copies of the target files created in the A type of backup file created
same way a file is copied by the OS. For each input file to be backed up, a single by RMAN which is a bit-for-
bit image of the original file.
output file is created. Since image copies created by RMAN are exactly identical
to their originals, they can be restored either automatically by RMAN or manu-
ally through OS-level commands.
Backup sets are slightly more complex. A backup set is a logical object which
consists of one or more physical backup pieces. As RMAN reads in the input RMAN Backup Sets
files to be backed up, RMAN will mesh the files together to create the backup
set. The backup set will be broken down into one or more pieces depending on
how you have the backup operation configured. Figure 4-2 illustrates this
concept. backup set:
A logical object created by
RMAN that contains multiple
backup pieces. Each backup
piece contains one or more
original files from the target
database.

Figure 4-2: RMAN creating a backup set.
In this figure, RMAN is backing up a database that consists of four datafiles.
RMAN meshes the files together to create a single, logical backup set, then splits
the set into two backup pieces, which are RMAN-specific files that are stored in
the backup location. The information about the backup set and the names and
locations of the backup pieces are stored in the RMAN repository.
The number of backup sets and the number of pieces per set are determined by
the way RMAN is configured for that particular backup. By default, each backup
set consists of exactly one backup piece, but the backup piece can contain any
number of original Oracle files. For example, a database can contain 10 datafiles,
but RMAN can back these up into a single backup set that contains one backup
piece, which in turn contains all 10 datafiles. If RMAN creates multiple pieces
within a backup set, a single backed up file can span multiple pieces within that
set, but a single backed up file cannot span multiple backup sets. Additionally,
control files may be included in a backup set with datafiles, but archive logs
cannot. For example, a backup set can contain datafiles or archive logs, but not
both. If you include archive logs with a database backup in one command,
RMAN will automatically create one backup set for the datafiles and one backup
set for the archive logs.

TASK 4A-4
Describe How RMAN Creates Image Copies and Backup
Sets
1. True or False? Image copies of datafiles can be restored either automati-
cally by RMAN or manually through OS-level commands. Explain your
answer.
True. Image copies are standard bit-for-bit copies of the target files created
in the same way a file is copied by the OS. For each input file to be backed
up, a single output file is created. These files can be restored automatically
by RMAN or manually through OS-level commands.
2. You are performing a backup operation that will include datafiles, the
control file, and archive logs, and you are not creating image copies.
What is the minimum number of backup sets that will be created for
this operation?
a. 1
✓ b. 2
c. 3
d. 4
3. True or False? If your backup set is 100 GB, but you only need to
restore a 5 MB file, you will still need to read through the entire 100 GB
backup set to find that small datafile. Explain your answer.
True. As RMAN resends the input files to be backed up, RMAN will mesh the
files together to create the backup set. When recovering from a backup set,
RMAN requires that all pieces of the set be available to read from, even
though you may only need to restore a small datafile from it.
Topic 4B
Configuring the RMAN Environment
Prior to using RMAN to back up target databases, each target database must have
an available user account on the target that RMAN can use to log in with. For
simplicity, it is recommended that the user accounts on each database have the
same user names, even if each account uses a different password. Additionally,
the RMAN utility must have access to at least one Oracle Net service name per
remote target database that RMAN supports.
If you are using the control file of the target database as the RMAN repository,
then no additional configuration is necessary. You would simply invoke RMAN
and issue the CONNECT command with the TARGET keyword to specify the user
name, password, and connect string for the target database. The syntax of the
CONNECT command that uses the control as the repository is:
connect target username/password@connectstring

Just as in the SQL language, RMAN commands are not case-sensitive. An
example RMAN session that uses the control file as the repository is shown in
Figure 4-3.
Figure 4-3: Using the control file as the RMAN repository.

Alternatively, you can invoke RMAN and connect to the target database in a
RMAN Connecting to Target
single command. For example, the following command issued from the command
Database Using the Control prompt invokes RMAN and automatically connects to the ORA92 database using
File the rman user account:
rman target rman/buprec@ora92 nocatalog
In this example, the NOCATALOG keyword indicates that you are not specifying
connection information for an RMAN recovery catalog. Therefore, RMAN will
default to using the control file of the target database as the repository, as shown
in Figure 4-4.
Figure 4-4: Invoking RMAN and connecting in a single command.

Once you have connected to the target database, you can start using RMAN to
perform all backup and recovery operations for the target database. RMAN will
use the control file as the repository to store backup and recovery information
relevant to the current target.

TASK 4B-1
Using the Control File as the RMAN Repository
Objective: To use RMAN to connect to the target database using the con-
trol file as the RMAN repository.
1. You will first create a database user, called rman, which the RMAN utility
will use to connect to the database.
2. At the prompt, issue the following commands:

CREATE USER rman IDENTIFIED BY buprec
DEFAULT TABLESPACE tools;
GRANT connect TO rman;
Oracle will display the messages “User created” and “Grant succeeded.”
Exit from SQL*Plus.
3. Open a command prompt from the Start menu.
To simultaneously launch RMAN and connect to the target database and

repository, issue the following command at the command prompt:
The output will show that you have connected to the specified target data-
base, which is currently the ORA92 database. The output will also show that
you are currently using the control file of the target database instead of the

recovery catalog as the RMAN repository.
4. To see the current datafile layout for the target database, type report
schema; and press Enter.
The output will show the names and sizes of all the datafiles in each
tablespace of the ORA92 database.
5. At the prompt, type exit and press Enter to exit from the RMAN utility
and return to the command prompt.
Exit from the command prompt.
Create the Recovery Catalog

Before connecting to and using the recovery catalog as the RMAN repository, the
recovery catalog must be created within a user schema in a database. It is recom-
mended that you store the recovery catalog in a database independent from the
target databases you wish to back up. If a failure occurs that renders the target
database inoperable, your recovery catalog will also be unavailable.
The user name of the database account you use for RMAN is unimportant, but
the account must at least have the RECOVERY_CATALOG_OWNER role, or an
equivalent set of privileges, prior to creating the catalog. Additionally, the data-
base objects that make up the recovery catalog will be created in the default
tablespace you assign to the user. Therefore it is recommended that you create a

dedicated tablespace to store the recovery catalog in, and assign only the RMAN
user to it. The RMAN user must also be given sufficient storage quota in the
tablespace where the recovery catalog will be created. An empty recovery catalog
is usually no more than 15 MB, depending on the default storage settings for the
tablespace where the catalog is created, but will grow depending on the number
of target databases the catalog supports and how often the targets are backed up.
In general, a 100 MB tablespace is recommended to start with, and you should
give the RMAN user an unlimited quota on this tablespace.
To connect to the database where the recovery catalog is located, you would
include either the RCVCAT or CATALOG keywords, which are interchangeable,
with the CONNECT command, and the user name, password, and connect string
for the database. The first time you connect to the repository database, RMAN
will display a message that the recovery catalog is not installed, as shown in Fig-
ure 4-5.
Figure 4-5: Initial RMAN connection to the recovery catalog database.

Once connected to the repository database, you would create the recovery catalog
by simply issuing the CREATE CATALOG command. When this command is Creating the RMAN
issued, RMAN will automatically create all the objects that make up the recovery Recovery Catalog
catalog. If a recovery catalog already exists in the database for the specified user,
RMAN will return an error. Figure 4-6 shows the output from the CREATE
CATALOG command.
Figure 4-6: The CREATE CATALOG command.

Once the recovery catalog is created, you can connect to any target database
simultaneously with the recovery catalog to begin backup and recovery operations
for that target. A single RMAN command can invoke RMAN and connect to both
the target and recovery catalog. The order in which you specify the catalog and
target connection information is unimportant; you can either specify the recovery
catalog connection information first or the target database connection information
first. However, you must specify correct user names passwords and connect
strings for both. An example RMAN session connecting to both the recovery
catalog and a target database is shown in Figure 4-7.
Figure 4-7: RMAN connecting to both target and recovery catalog databases.
In this example, the recovery catalog is located in the database specified by the
RECCAT connect string, and the target database is specified by the ORA92 con-
nect string. The user name rman with the password buprec was used for both
locations.
TASK 4B-2
Creating the Recovery Catalog
Objective: To create the RMAN recovery catalog to store the RMAN
repository inside the database.
1. While it is not advisable to store your recovery catalog in the same database
that must be backed up, for the purpose of this course, you will create a
tablespace in the ORA92 database to store the RMAN recovery catalog.
2. At the prompt, issue the following command:

CREATE TABLESPACE rman DATAFILE
'D:\oracle\oradata\ora92\rman01.dbf' SIZE 100M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128k;
After a few moments, Oracle will display the message “Tablespace created.”

3. You will now configure the rman database user to support the creation of the
recovery catalog. This includes setting the user’s default tablespace, setting
the user’s quota on that tablespace, and granting the appropriate privileges
required to create and own the recovery catalog.
At the prompt, issue the following commands:

ALTER USER rman
DEFAULT TABLESPACE rman
QUOTA UNLIMITED ON rman;
GRANT recovery_catalog_owner TO rman;
Oracle will display the messages “User altered” and “Grant succeeded.”
4. Leaving the SQL*Plus window open, open a command prompt from the
Start menu.
You will now launch RMAN, and simultaneously connect to the target data-
base and the database where the recovery catalog is stored. For this course,
both refer to the ORA92 database. At the command prompt, issue the fol-
lowing command:
rman rcvcat rman/buprec@ora92 target rman/buprec@ora92
The RMAN utility will launch and, after a moment, it will connect to the
ORA92 database as both the target and the recovery catalog database.
RMAN will also display a message stating that the recovery catalog is not
installed.
5. To create the recovery catalog, type create catalog; and press Enter.

After several moments, RMAN will display the message “recovery catalog
created.”
6. To exit from the RMAN utility, type exit and press Enter.
Close the command prompt.
7. You will now query the data dictionary to see a list of the tables that were
created in the RMAN schema.
At the SQL*Plus prompt, issue the following commands to format the

output of your query:
set pages 50
COLUMN table_name FORMAT a30
COLUMN tablespace_name FORMAT a15

FROM dba_tables
WHERE owner='RMAN';
The output will show that 30 tables have been created in the RMAN
schema. These tables make up the main storage structures of the RMAN
recovery catalog. You may have to scroll up to see all of the output.

Register a Target Database
Once the recovery catalog is created, each database to be supported must be reg-
istered with the recovery catalog. When registering a target database, RMAN
reads basic information about the database from the data dictionary, such as the
database name, Oracle version, and incarnation and loads it into the recovery
catalog. RMAN then performs a full resync with the target database to load the
recovery catalog with the target database’s datafile and control file layout, archive
log history, and other pertinent backup and recovery information.
To register a target database with the recovery catalog, you would first invoke
RMAN and connect to both the recovery catalog and the target database, then Registering a Database with
issue the REGISTER DATABASE command. The output from this command is the Recovery Catalog
shown in Figure 4-8.
Figure 4-8: The REGISTER DATABASE command.
TASK 4B-3
Registering a Target Database
Objective: To register a target database in the RMAN recovery catalog.
1. You will first launch RMAN, and connect to both the recovery catalog and
the target database simultaneously.
Open a command prompt from the Start menu.


The output will show that you have connected to both the target database
and the recovery catalog database.
2. To generate a list of the tablespaces that currently make up the target data-
base, type report schema; and press Enter.
RMAN will display an error message stack. The errors state that the target
database is not found in the recovery catalog. Before performing any opera-
tions with RMAN against a target database while using the recovery catalog
as the repository, you must first register the database with the recovery
catalog.
3. To register the target database with the recovery catalog, type register data-
base; and press Enter.
The output will show that the database has been registered with the recovery
catalog, and a full resync was completed.
4. Now that the metadata information about the target database is now stored in
the recovery catalog, you will be able to generate a list of the tablespaces
that currently make up the target database.
At the prompt, type report schema; and press Enter.
RMAN will display a report of the database schema. This report consists of
all the datafiles in the database, and the size of each one. The report will
also show which datafiles contain rollback segments. This information may

be important during a recovery of those datafiles.
5. To exit from the RMAN utility, type exit and press Enter.
RMAN will display the message “Recovery Manager complete.”
Close the command prompt.
RMAN Configuration Parameters

The RMAN utility allows you to set default configuration parameters that persist
across all RMAN sessions for a particular recovery catalog. These persistent RMAN Configuration
configurations help simplify the management of backup and restore operations by Parameters
minimizing the amount of text required for execution. The configuration param-
eters are stored in the recovery catalog and are initialized each time the RMAN
utility is started. Any changes to the configuration parameter values will be stored
in the recovery catalog and will be used for each subsequent RMAN session until
the parameter is changed again. All configuration settings can be modified by
using the CONFIGURE command from the RMAN prompt. Any configuration
settings specified in an RMAN script will override the default settings provided
by the CONFIGURE command. The configuration settings that can be modified
include:
• Retention policy
• Channel configuration and allocation
• Control file management
• Backup optimization
• Tablespace exclusions
Specifying a retention policy sets the maximum number of backup sets to main-
tain in the recovery catalog. This retention policy can be specified as the number
of backups or as the number of days’ worth of backups. As new backup sets are
created, older sets are marked as obsolete. You can then execute the DELETE retention policy:
OBSOLETE command to automatically find and delete all backup sets that are The policy used by RMAN to
marked obsolete. In this way, you will limit the amount of disk space consumed determine which database
backups in its recovery
for backups, and still keep a minimum number of current backups on hand. To catalog are still valid.
set the retention policy to maintain five sets of current backups, you would issue
the following command at the RMAN prompt:
CONFIGURE RETENTION POLICY TO REDUNDANCY 5;

To set the retention policy to maintain 30 days’ worth of current backups, you
would issue the following command at the RMAN prompt:
CONFIGURE RETENTION POLICY TO RECOVER WINDOW OF 30 DAYS;
The CONFIGURE command also allows you to specify default settings for your
channel configurations. The channel configurations you can set include the device
type and the directory and file name convention you wish to use for your backup
sets. The channel configuration settings you specify will be used to automatically
allocate and use channels for all backup and restore operations as necessary. To
configure the default channel settings for RMAN, you could issue any one of the
following commands at the RMAN prompt:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'D:\oracle\oradata\ora92\ora92_bak\%d_%s_%p.bak';
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
The first command sets the default device type to disk. This will ensure that
RMAN assumes that all backup and restore operations will occur on the local
disk unless otherwise specified. If you want the backups to be sent to a backup
tape device that is attached to the server where the target database resides, you
would use TYPE 'sbt_tape'.
The second command sets the directory and file name format for all backup sets
that will be sent to the disk. The last command sets the number of channels to
allocate for backup and restore operations. In this case, RMAN will automatically
allocate four channels for all backup and restore operations that occur on the
local disk.
If you include the FORMAT option, you can specify the directory path and file
name pattern to use when creating backup sets. The file name pattern can include
pattern variables to allow RMAN to generate the file name. Some of the available
file name pattern variables are shown in the following table.
Variable Usage
%d Specifies the name of the target database.
%D Specifies the current day of the month using the format DD.
%F Combines the database identifier (DBID), day, month, year, and a sequential
number into a unique and repeatable generated name.
%M Specifies the month number using the format MM.
%p Specifies the backup piece number within a single backup set. The first set will
automatically use the value 1, and the value is incremented for each subsequent
piece in the set.
%s Specifies the backup set number. This number is actually stored in the control
file of the target database and is incremented for each backup set created for
%t Specifies the timestamp of the backup set.
%T Specifies a full year, month, and date using the format YYYYMMDD.
%u Instructs RMAN to generate a unique name for each output file.
%U Shorthand for %u_%p_%c. This combination guarantees uniqueness for all
backup sets generated for a single target database.
%Y Specifies the current year using the format YYYY.

If you specify a file name pattern but do not use any pattern variables, every
backup set RMAN generates for the target database will have the same name, and
will probably overwrite older backup sets. If you do not specify a file name pat-
tern at all, by default RMAN will use the %U pattern variable.
The RMAN utility also provides a simplified way to manage controlfile backups
with a control file autobackup feature. When this feature is enabled, RMAN will
automatically include the control file in every backup operation. Control file
autobackup is enabled by issuing the following command:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
To set the path and file name of the backed up control file, you would issue the
following command:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'%F';
For this command, you can specify any path and file name you like, but it must
include at least the %F substitution variable. The %F variable will automatically
add an identifying tag to the file name in the following format:
c-IIIIIIIIII-YYYYMMDD-QQ
In this format, c stands for control file, and IIIIIIIIII represents the data-
base identifier of the database that the control file belongs to. The YYYYMMDD
notation represents the year, month, and date the control file backup occurred, and
QQ represents the backup control file sequence number. The backup control file
sequence number is a hexadecimal number which starts at 00 and has a maximum
of FF (256), and increments each time the control file is backed up. Once the
value of FF is reached, the control file sequence number recycles back to 00. If
you do not include at least the %F substitution variable, RMAN will return an
error.
If you specified the format for backup control files to be 'ORA_%F.bak', the
file name of your backup control file might look something like this:
ORA_c_1776372340_20020801-49.bak
Another default setting you can enable is backup optimization. When this param-
eter is set to ON, RMAN will bypass any files that have already been backed up
to the same device and that have not changed since their last backup. This can
shorten the time it takes to perform a full database backup by skipping any files
that do not need to be backed up. This setting applies to archive log backups, as
well as datafile backups. To set this parameter, you would issue the following
command:
CONFIGURE BACKUP OPTIMIZATION ON;
Another method of decreasing the time it takes for backing up a database is to
specify tablespaces that you do not want to back up. If you can set default
tablespace exclusions with the CONFIGURE command, the tablespaces you
specify will be skipped for all backup and restore operations. This is useful if you
have large tablespaces that do not contain critical data that you do not wish to
back up. This parameter can be set with the following command:
CONFIGURE EXCLUDE FOR TABLESPACE users;
If you wish to exclude more than one tablespace, you must list each tablespace
separately with a new CONFIGURE command for each. The specified tablespaces
are added to the list of excluded tablespaces, and the list is not overwritten. Addi-
tionally, a tablespace exclusion is target database-specific, meaning that a

tablespace that has been added to the exclusion list will only be excluded from
future backups of the target database RMAN is currently connected to. In the
example shown here, the USERS tablespace will be excluded for all future back-
ups of the current target database. If RMAN connects to another database that
also has a USERS tablespace, the exclusion will not apply for that database
unless the DBA specifically adds the tablespace to the exclusion list.
To set any RMAN configuration parameter back to its original default, you can
just add the CLEAR keyword to the end of each command. The following com-
mands will set each of the previously mentioned configuration parameters back to
their default values:
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE DEFAULT DEVICE TYPE CLEAR;
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
CLEAR;
CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE users CLEAR;
In this syntax, the command CONFIGURE CHANNEL DEVICE TYPE DISK
CLEAR will reset the degree of parallelism back to one, meaning only one
channel will be allocated for each backup and restore operation. Also, when
specifying the CLEAR keyword for the CONFIGURE EXCLUDE FOR
TABLESPACE command, only that tablespace is removed from the list of
excluded tablespaces. You must specify each tablespace separately for each one
you want to remove from the excluded list.
To see any of your backup configuration settings, you can use the SHOW
command. With this command, you can specify any individual parameter, or you
can specify SHOW ALL to list all configuration parameters. It’s important to note
that the SHOW ALL command may or may not actually show all persistent con-
figuration parameters. Many configuration parameters have default values, and if
the DBA has not changed a parameter’s value from its default, more than likely
the SHOW ALL command will not list it. The SHOW ALL command primarily
provides a list of all parameters that have been explicitly set by the DBA. Figure
4-9 shows the output of the SHOW ALL command.
Figure 4-9: The SHOW ALL command.

TASK 4B-4
Set the RMAN Configuration Parameters
Objective: To set the RMAN configuration parameters in preparation of
performing RMAN backups of the target database.
1. You will first connect to the recovery catalog and the target database.
Open a command prompt from the Start menu.

RMAN will launch and connect to both the recovery catalog and the target
database.
2. To see the current settings of the configuration parameters, type show all;
and press Enter.
The output will show all configuration parameters that are currently set for
RMAN. This list is not all inclusive; if a parameter currently has no setting,
it will not appear in the list.
3. You will set some configuration parameters to tailor the RMAN environment
for your system. The changes you will make include:
• Destination path and file name format for backup sets.
• Control file autobackup.
• Backup control file path and file name format.
• Backup optimization.
• Tablespace exclusions.
To set the destination path and file name format for backup sets, issue the
following command at the RMAN prompt:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'D:\oracle\rman_bup\%d_%s_%p';
The output will show that RMAN stored the new parameter setting, and per-

formed a full resync of the recovery catalog.
You should notice that RMAN accepts the path and format setting even
though the D:\oracle\rman_bup folder does not yet exist. However, if the
path specified is still invalid when RMAN attempts to perform a backup, the
backup will fail. Therefore, you will create the D:\oracle\rman_bup folder
now.
Open a window to the D:\oracle folder. Choose File→New→Folder.

Name the new folder rman_bup
Close the D:\oracle window.
4. You will now configure RMAN to automatically include the control file in
all backups. This includes enabling control file autobackup, as well as setting
the path and file name format for the backed up control file.
At the prompt, issue the following commands. After each command,

RMAN will store the new parameter setting and perform a full resync of the
catalog.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'D:\oracle\rman_bup\%F';
5. Certain RMAN features can help reduce the amount of time required to back
up the entire database, such as backup optimization and excluding non-
critical tablespaces. You will enable backup optimization to direct RMAN to
bypass datafiles that have already been backed up and have not changed
since the last backup. You will also set an exclusion for the EXAMPLE
tablespace.
At the prompt, issue the following commands. After each command,

RMAN will store the new parameter setting and perform a full resync of the
catalog.
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE EXCLUDE FOR TABLESPACE example;
6. To confirm all of your configuration changes, type show all; and press
Enter.
The output will show that the path and file name format for backup sets and
the control file have been set. You will also see that control file autobackup
has been enabled. Backup optimization has been enabled, and the
EXAMPLE tablespace will be excluded from all backups.
These parameter settings will be used for all future backups of this target
database until the settings are changed again.
7. Your RMAN environment is now ready to begin performing database

backups.
Exit from RMAN and the command prompt.

Topic 4C
RMAN Backups
When performing a user-managed cold database backup, the database is shut
down completely and file copies are executed through OS-level commands. How-
ever, for RMAN cold backups, the database must be shut down then started in
the mount state. This allows RMAN to log in to the database and read pertinent
information from the data dictionary and control file to update the RMAN
repository. However, the connection RMAN uses will only be able to see the very
basics of the data dictionary, but it will not be able to see its own schema objects.
If the recovery catalog is stored in an independent database, you can use the
recovery catalog for the cold backup. However, if the recovery catalog is stored
in the target database, then the recovery catalog will be unavailable during the
backup, which means you must use the target database’s control file as the
RMAN repository.
The DBA can shut down and mount the target database right from within the
RMAN utility by issuing standard SHUTDOWN and STARTUP commands. This
allows the DBA to perform all backup and recovery activities from a single util-
ity and even write RMAN scripts that can handle all operations from within
RMAN itself. Figure 4-10 shows the RMAN utility shutting down and mounting
Figure 4-10: Shutting down and mounting the target database from within RMAN.
Once the database is mounted, the backup can begin. During the backup process,
The BACKUP Command
RMAN will apply all persistent configuration parameters to the current operation,
unless the parameters are explicitly overridden for the operation. If the parameters
are set appropriately, then the set of commands to initiate a cold database backup
may simply consist of just the BACKUP command that specifies the target to back
up, such as one or more datafiles, one or more tablespaces, the entire database,
the control file, or one or more archive logs. The following command will back
up the entire database to the backup location specified by the default channel con-
figuration parameter:

BACKUP DATABASE;
Regardless of the actual backup target or whether the operation is a hot or cold
backup, there are some steps that are always executed during an RMAN backup.
First, RMAN must allocate a communications channel. This channel is a database
connection to the target database that allows RMAN to read the data dictionary
information about the backup target, such as the names and locations of datafiles.
It is through this channel that the actual backup work is done, such as reading
from the source files and writing to the pieces of the backup set that is to be
created.
Another operation that is always performed for every backup is a backup of the
spfile. Regardless of the backup operation you are performing, RMAN will
always locate and include the spfile with each and every backup set created. This
is to ensure that the spfile can always be restored even if a media failure causes a
total loss of the most critical files in the database. A database with all its datafiles
that cannot be restarted is even more worthless than a database that has lost all of
its datafiles but has retained the spfile. The lost datafiles can be restored, and the
instance restarted with the latest backup copy of the spfile. Without this backup
copy, you will have to manually re-create a standard parameter file to start the
database with, which may not include all the necessary parameters and settings to
get the database back to the configuration it had at the point of failure. This can
create performance problems in the recovered database and possibly increase your
mean time to recovery while you try to determine which parameters are incorrect.
If control file autobackup is enabled, a backup copy of the control file is always
created for each and every backup operation. The control file backup that is cre-
ated from a control file autobackup operation will always be contained within its
own backup set. For example, if you execute the BACKUP DATABASE com-
mand, RMAN will create one or more backup sets to store the database backup
in, and will also create an additional backup set to store the control file backup
copy generated by the control file autobackup feature. Even if your command
includes the control file in its backup target, such as using the INCLUDING
CONTROLFILE clause, or even just the BACKUP CURRENT CONTROLFILE
command, RMAN will still create one backup set for the specified target and
another backup set for the control file autobackup. This means that if you enable
control file autobackup, and your backup target includes a control file, RMAN
will end up backing up the control file twice during the operation. This is not
necessarily a bad thing, since the control file is relatively small, and having more
backups is better than not having enough backups.
After the channel is allocated, RMAN will determine which files are to be
included in the backup set, then locate those files on the file system. Using the
FILESPERSET and MAXPIECESIZE parameters, RMAN will determine the
number of backup sets to create and the number of backup pieces within each set.
If these parameters have not been set, RMAN will default to creating one backup
set that contains a single backup piece. That backup piece will contain all files
for the backup target. Once the backup operation is complete, RMAN deallocates
the communication channel and then updates its repository with the information
relevant to the operation it just completed.
RMAN will automatically generate an identifying tag for each backup it creates.
A tag acts as the name of the backup, which can be used to find specific backups
in the repository if necessary. By default, RMAN generates backup tags using the
following format:
TAGYYYYMMDDTHHMMSS

In this format, YYYYMMDD indicates the year, month, and date that the backup
was started. The time the backup was started is indicated by the characters that
follow the T after the date. For example, a backup that was started on May 15,
2003 at 8:15 A.M. exactly will be labelled with the following tag:
TAG20030515T081500
RMAN allows you to optionally specify your own tags for backups when they
are executed. This is done by including the keyword TAG with the BACKUP
command. Tags are not case sensitive and must be 30 characters or less. A tag for
a single backup set will apply to all pieces within that backup set. Additionally,
tags can be reused without overwriting previous tags. For example, a backup cre-
ated last week may have the tag 'FULL_WEEKLY', while a new backup this
week can also have the same tag. The following command will create a full
backup of the database and override the default tag with the label
MONDAY_HOT_BACKUP:
BACKUP DATABASE TAG MONDAY_HOT_BACKUP;
Creating RMAN Image Copies

When using RMAN to create image copy backups of datafiles, RMAN uses the
same step-by-step process it uses to create backup sets. Just like backup sets,
RMAN can create hot or cold image copies and can use them to automatically
restore and recover the database in the event of a failure. The only difference is
that the output files of image copies are not backup sets that consist of backup
pieces. Rather, the output files are exact copies, bit-for-bit, of the original target
files. RMAN still allocates a channel, backs up the control file if control file
autobackup is enabled, backs up the spfile, and updates the repository.
To create image copy backups, you would use the COPY command instead of
The COPY Command using the BACKUP command. With a single COPY command, you would list one
or more input files and the respective output paths and file names of the image
copies to create. You can use this command to create image copies of datafiles,
control files, and archive logs, all of which can be included in a single COPY
command. The syntax for the COPY command can be somewhat complex, but a
simplified version is shown here:
COPY FILE_TYPE 'input_file' TO 'output_file' [,...];
In this syntax, FILE_TYPE refers to the type of input file you are copying,
which can be DATAFILE, ARCHIVELOG, or CURRENT CONTROLFILE. The
'input_file' argument specifies the file that is to be copied. This argument
can be specified as an absolute path and file name enclosed in single quotes or as
a datafile ID number, which can be determined from the data dictionary of the
target database. If file_type is CURRENT CONTROLFILE, then there is no
need to include the 'input_file' argument. The 'output_file' specifies
the path and file name of the image copy to be created from the input file. The
following list of commands shows some example COPY commands to create
image copies of files in the target database:

COPY
DATAFILE 'D:\oracle\oradata\ora92\system01.dbf' TO
'D:\oracle\backup\copies\system01.bak';
COPY
DATAFILE 2 TO 'D:\oracle\backup\copies\undo01.bak',
DATAFILE 5 TO 'D:\oracle\backup\copies\example01.bak;
COPY
CURRENT CONTROLFILE TO 'D:\oracle\backup\copies\control01.bak',
DATAFILE 1 TO 'D:\oracle\backup\copies\system01.bak';
COPY
ARCHIVELOG 'D:\oracle\oradata\ora92\oraarch\ORA92_3833.arc' TO
'D:\oracle\backup\copies\ORA92_3833_arc.bak';
In the first COPY command, an image copy of the SYSTEM01.DBF datafile is
created in the D:\oracle\backup\copies folder. The input file is specified with an
absolute path and file name of the datafile. In the second example, multiple
datafiles are to be copied and are listed by their ID numbers, which can be deter-
mined from the data dictionary. In the third example, the COPY command
includes both the current control file and the SYSTEM01.DBF datafile. In the last
example, a single archive log is being copied from its original location to the ’D:\
oracle\backup\copies folder.
TASK 4C-1
Performing Cold Database Backups Using RMAN
Objective: To perform a full, cold backup of the database using RMAN,
and to back up the database by creating image copies.
1. To perform a cold database backup using RMAN, the database must be in

the mount stage, but not opened. Also, since your recovery catalog resides in
the database that will be backed up, the recovery catalog will be unavailable
for this operation. Therefore, you will use the control file as the RMAN
repository.
Open a command prompt.
At the command prompt, issue the following command:


The RMAN utility will launch and connect to the target database using the
control file as the repository.
2. At the RMAN prompt, type shutdown immediate; and press Enter.
The output will show that the database was closed and dismounted, and the
database shut down.
Type startup mount; and press Enter.
The output will show that the Oracle instance was started, and the database
mounted.
3. To see the current settings of the RMAN configuration parameters, type

show all; and press Enter.
The output will show RMAN’s current configuration for this target database,
some of which you had set in an earlier activity. You will see that datafiles
will be backed up to the D:\oracle\rman_bup folder. You will also see that

the control will be automatically backed up, also with the destination of
D:\oracle\rman_bup.
4. Since all the necessary configuration parameters are already set, you simply
need to issue the backup command to perform a full, cold backup.
At the prompt, type backup database; and press Enter.
You will see RMAN begin the backup process. First RMAN allocates a
channel, then generate a list of datafiles to be included in the backup set.
Once the datafiles are backed up, RMAN will automatically back up the
control file and spfile. The entire backup process may take several minutes
to complete.
5. Leaving the RMAN window open, open a window to the D:\oracle\rman_

bup folder.
The folder contains two files. The first file is the backup copy of the control
file, and has a name that begins with the letter C, followed by a string of The names of the files you
numbers. As indicated by the configuration parameters, the control file will see on your system may not
automatically be backed up for each backup of the database. The other file is be the same as those shown
here.

named ORA92_1_1, and is the RMAN backup set containing the cold
backup of the database.
6. Leaving the rman_bup window open, switch back to the RMAN window.
You will now create an image copy of the datafile that makes up the USERS
The output of the schema tablespace. To determine the name and location of the USERS datafile, type
report may be wider than report schema; and press Enter.
your window, which causes
longer lines of text to wrap The output will show a list of the datafiles in the target database. Find the
to the next line.
datafile for the USERS tablespace. Make note of the file number of that
datafile, which is found in the first column of the report. In the example
shown here, the file number of the USERS datafile is 9.
7. To create an image copy of the USERS datafile, issue the following com-
mand, making sure to substitute the file number of your USERS datafile
from the schema report:
copy datafile 9 to 'D:\oracle\rman_bup\users_img.dbf';
You will see RMAN begin the copy process. First, RMAN allocates a chan-
nel, then copies the USERS01.DBF datafile to the D:\oracle\rman_bup
folder, and names the copy USERS_IMG.DBF. Once the file is copied,

RMAN then automatically backs up the control file and spfile.
8. Leaving the RMAN window open, switch back to the D:\oracle\rman_bup

window.
You will see two new files in the folder. The first new file is USERS_IMG.
DBF, which is the image copy of the USERS01.DBF datafile. The other new
file is another backup copy of the control file, which was automatically gen-
erated by RMAN.
Close the rman_bup window and switch back to the RMAN prompt.
9. You will now open the database to make it available for general use.
At the RMAN prompt, type alter database open; and press Enter.
RMAN will display the message “database opened.”
10. Exit from both RMAN and the command prompt.
RMAN Hot Backups

The only real difference between an RMAN cold backup and an RMAN hot
backup is that the database remains open and available during a hot backup.
Since RMAN does not have to put tablespaces in backup mode, which is required
for a user-managed hot backup, there will be little or no impact on database per-

formance while the backup is executing. Like the RMAN cold backup, the
RMAN hot backup is initiated with the BACKUP command. If the persistent con-
figuration parameters are set appropriately, then the only option that needs to be
included with this command is the backup target, such as DATAFILE,
TABLESPACE, DATABASE, or ARCHIVELOG. When executing the backup,
RMAN will allocate a channel, locate the files to backup and add them to the
backup set, backup the control file if control file autobackup is enabled, backup
the spfile, then deallocate the channel. Once the operation is complete, RMAN
will update the repository with all pertinent information about the backup set it
just created.
TASK 4C-2
Perform a Hot Backup of the Database Using RMAN
Objective: To perform a hot backup of the database using RMAN.
1. In your environment, the recovery catalog is contained in the target database.

Since a hot backup is performed while the database is open, the recovery
catalog is available. Therefore, you will connect to the target database and
the recovery catalog simultaneously.
Open a command prompt. At the prompt, issue the following command:

The connection
specifications for the target rman target rman/buprec@ora92 rcvcat rman/buprec@ora92
database and recovery
catalog can be listed in any The output will show that RMAN has connected to both the target database
order at the RMAN prompt. and the recovery catalog.
2. Since the RMAN environment is already configured, you simply have to

issue the backup command.
At the RMAN prompt, type backup database; and press Enter.
You will see RMAN begin the backup process. With the exception of
excluded datafiles, all datafiles, the control file, and the spfile were included
in the backup. While this backup is occurring, the database remains open
and available to users with very little or no impact to performance. The

backup may take several minutes to complete.
RMAN Incremental Hot Backups

To decrease the amount of time it takes to perform a hot backup of a large data-
base, RMAN provides the ability to perform incremental backups of the database.
When performing a standard full backup of the database, RMAN adds each
datafile to the backup set and backs up all datablocks within each datafile that incremental backup:
have changed since the datafile was created. This could potentially mean that an A backup of the database
entire datafile could be backed up if the datafile was very full at any point in its that includes only the
datablocks that have changed
lifetime. since a previous incremental
When performing incremental hot backups, RMAN will only back up datablocks backup instead of all
datablocks that contain data.
that have changed since the last incremental backup. For example, let’s say a new
tablespace was created that consisted of a single datafile sized at 50 MB, 45 of
which have been allocated to tables and indexes during the lifetime of the
datafile. During a standard RMAN hot backup, RMAN will back up all 45 MB,
regardless of whether any of those datablocks have actually been modified for a
long time. During an incremental RMAN hot backup, RMAN will only back up
the datablocks in the file that have changed since the last backup. Let’s say a hot
backup of the datafile was performed two days ago, and since then, only 1 MB of
those 45 allocated have actually changed. During the next incremental hot
backup, only that one changed megabyte worth of datablocks will be backed up,
instead of all 45. This can greatly reduce the amount of time and storage space
required to perform a backup of the database.
RMAN can create incremental backups by using backup levels, ranging from 0 to
8. The backup increment level is specified with the BACKUP command when the
backup is executed. Each higher backup level backs up less and less data from
the database. An incremental level 0 backup is identical to a standard full hot
backup of the database. However, you cannot perform an incremental level 1
backup of a database that has only been backed up using a standard hot backup.
In order to perform incremental backups of a database, you must have performed
at least one incremental level 0 backup. This level 0 backup stands as the
baseline for all future incremental backups. If you attempt to perform a level 1
incremental backup of a database that does not have a level 0 incremental
backup, RMAN will automatically perform a level 0 incremental backup instead.

By definition, the default behavior of an incremental backup behaves in this man-
ner:
• A level n incremental backup in which n is greater than zero backs up either
all blocks changed after the most recent backup at level n or lower.
To put this in plain English, consider these examples:
• A level 0 incremental backup backs up all datablocks that contain data or
have ever contained data.
• A level 1 incremental backup backs up all datablocks that have changed
since the last level 1 backup or the last level 0 backup, whichever was more
recent.
• A level 2 incremental backup backs up all datablocks that have changed
since the last level 2 backup, or the last level 1 backup, or the last level 0
backup, whichever was more recent.
The same behavior is repeated throughout all eight incremental levels. Figure
4-11 illustrates the concept of incremental backups that are performed throughout
a single week using various incremental levels.
RMAN Incremental Backups
Figure 4-11: RMAN Incremental Backups

In this figure, incremental backups are performed daily. On Sunday, an incremen-
tal level 0 backup is performed, which backs up all datablocks that have ever
contained data. On Monday, an incremental level 3 backup is performed, which
backs up all datablocks that have changed since the last level 3 or lower backup
was performed, as shown by the first arrow from the top. In this case, the last
incremental backup performed at level 3 or lower was the level 0 backup per-
formed on Sunday, so the only blocks that were backed up were those that
changed between Sunday and Monday.

On Tuesday, another incremental level 3 backup is performed, which again backs
up all datablocks that have changed since the last level 3 or lower backup was
performed. Except in this case, the last level 3 or lower backup was performed on
Monday, so only the blocks that were changed between Monday and Tuesday are
actually backed up, as indicated by the second arrow from the top.
On Wednesday, an incremental level 2 backup is performed, which backs up all
datablocks that have changed since the last level 2 or lower backup was
performed. In this case, the last incremental backup performed at level 2 or lower
was the level 0 backup performed on Sunday. All datablocks that changed
between Sunday and Wednesday were backed up, as indicated by the third arrow
from the top. This backup included datablocks that were also included in the
backups performed Monday and Tuesday.
On Thursday, an incremental level 3 backup is performed, which backs up all
datablocks that have changed since the last level 3 or lower backup was
performed. In this case, the last incremental backup performed at level 3 or lower
was the incremental level 2 backup performed on Wednesday. Another incremen-
tal level 3 backup is performed on Friday, backing up all datablocks that have
changed since the level 3 backup on Thursday.
On Saturday, an incremental level 1 backup is performed, which backs up all
datablocks that have changed since the last level 1 or lower backup. In this case,
the last incremental backup performed at level 1 or lower was the level 0 backup
performed on the previous Sunday. All datablocks that have changed since that
Sunday are included in this backup, which includes datablocks that have been
backed up one or more times throughout the week.
Finally, on Sunday, another incremental level 0 backup is performed, backing up
all datablocks that have ever contained data. This new level 0 backup will serve
as the baseline backup for the following week.
Restoring and Recovering From an Incremental Backup

Restoring and recovering a database from an incremental backup is slightly dif-
ferent than restoring and recovering from a standard backup. If media failure
causes the loss of a datafile, you would still issue the RESTORE and RECOVER
commands through RMAN, however RMAN takes some different steps. RMAN
will first restore the datafile from the last incremental level 0 backup of that
datafile, regardless of how long ago that was. Then it will apply the latest incre-
mental 1 backup to that newly restored datafile, almost in the same fashion that
archive logs are applied to the database. All datablocks that are found in the level
1 backup are written to the restored datafile to replace the older version of the
blocks. RMAN will then apply the latest incremental 2 backup to the datafile,
then the latest increment level 3, and so on.
For our example in Figure 4-11, if media failure causes the loss of a datafile on
Friday after Friday’s backup, the incremental level 0 backup from the first Sun-
day is restored. RMAN will then attempt to apply the latest level 1 backup to that
newly-restored datafile. Since no level 1 backup exists, RMAN will move to the
latest level 2 backup, which was performed on Wednesday. Since this level 2
backup contains all the same datablocks that were backed up on Monday and
Tuesday, there is no need to restore those backups at all. After applying the
changes found in that backup, RMAN will apply the last two level 3 backups that

were performed on Thursday and Friday. Once RMAN has applied all incremen-
tal backups in order, RMAN will start applying any archive logs that were
generated after the incremental level 3 backup on Friday. This entire process is
much faster than trying to restore and apply all the archive logs since the level 0
backup was performed.
It’s important to note that incremental backups really only save time during back-
ups, but not during recoveries. While restoring incremental backups and applying
them to the datafiles is faster than applying archive logs, RMAN must still restore
the level 0 backup from the backup set, then restore and apply all incremental
backups from the last level 1 forward, then restore and apply all the archive logs
generated since the latest backup. The total time for this operation will take about
the same as using standard backups and just using the archive logs for recovery.
In reality, the only savings you gain is the amount of time it takes to perform the
incremental backups, but incremental backups will not necessarily reduce your
mean time to recovery.
TASK 4C-3
Perform Incremental Hot Backups using RMAN
Objective: To perform incremental hot backups using RMAN.
1. Before performing hot backups in true increments, you must first perform a
level 0 incremental hot backup.
Open a command prompt. Launch RMAN and connect with the follow-
ing command:
rman target rman/buprec@ora92 rcvcat rman/buprec@ora92
You will see RMAN launch and connect to both the target database and the
recovery catalog.
2. Perform a level 0 incremental backup by issuing the following com-

mand:
backup incremental level 0 database;
The output will show RMAN allocate a channel, determine which files to
include in the backup set, back up the datafiles, then back up the control file
and spfile. A level 0 incremental hot backup is very similar to a basic full
hot backup. All the datafiles, with the exception of any datafiles specified by

the EXCLUDE parameter, are included in the backup set.
3. In the output, find the line that starts with the words “piece handle”. This
line tells you the name of the file that was generated from this backup set.
Make a note of the name of the file that was generated. In the example
shown in step 2, the file name is ORA92_13_1.
Open a window to the D:\oracle\rman_bup folder.
In the rman_bup window, if you cannot see the sizes of the individual files,
choose View→Details. The contents of the window will change to show the
full details of its files.
Find the file that was just generated from your level 0 backup. The size
of the file, as shown in the Size column, should be relatively large. As
shown in the example here, the ORA92_13_1 file is 397,000 kilobytes.
4. A level 1 incremental hot backup will back up only the datablocks that have
changed since the last level 1 or level 0 hot backup. To show this, you will
create a table in the USERS tablespace, which must modify datablocks. Only
modified datablocks of this tablespace will actually be backed up.

Leaving the rman_bup window open, launch SQL*Plus and log in as sys.
Create a table in the USERS tablespace by issuing the following com-

mand:
CREATE TABLE test_inc (col1 NUMBER)
TABLESPACE users;
Exit from SQL*Plus.
5. Switch back to the RMAN window.
Perform an incremental level 1 hot backup of the database by issuing

the following command:
backup incremental level 1 database;
The output will look almost identical to that of the level 0 hot backup you
just performed. Although it looks as if RMAN is adding all the datafiles to
the backup set, it is really just examining the datafiles to determine if any
blocks have changed. RMAN will back up only those datablocks that have

changed since the last incremental hot backup at level 1 or below.
6. In the RMAN output, find the line that starts with the words “piece
handle” to determine the name of the file that was just generated. In the
example shown here, that file name is ORA92_15_1.
Switch to the rman_bup window. Find the file that was just generated
by your level 1 incremental backup. The size of this file should be much
smaller than the file generated by your level 0 incremental backup in step 2.
In the example shown here, the level 0 backup piece, file ORA92_13_1, is
397,000 KB, while the level 1 backup piece, ORA92_15_1, is only 1,048
KB. Only the datablocks that were modified by your CREATE TABLE com-
mand in step 4 were included in the backup set, resulting in a much smaller
backup piece.
Incremental hot backups provide a way to drastically reduce the amount of

resources, including time and disk space, required to successfully back up a
critical database.
7. Close the rman_bup window.

Exit from both the RMAN utility and the command prompt.
Backing Up the Archive Logs

RMAN provides the ability to back up the archive logs that are generated by a
target database. To back up archive logs, the BACKUP ARCHIVELOG command
is used, which accepts a filtering condition to choose which archive logs you
want to back up. You can specify a single archive log, a range of archive logs, or
all archive logs generated by the database that are still in the file system. The
range of archive logs can specify date and time of generation, log sequence num-
bers, SCN, or by file name pattern using the same type of character wildcards
used in the WHERE clause of SQL statements. You can also optionally include the
DELETE ALL INPUT clause, which instructs RMAN to delete the backed up
archive logs from the file system after the backup operation is complete. The fol-
lowing statements are examples of the BACKUP command to perform various
backup operations on different sets of archive logs:
BACKUP ARCHIVELOG ALL;
Backing Up Archive Logs
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
BACKUP ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';
BACKUP ARCHIVELOG FROM SCN = 52456 DELETE ALL INPUT;
BACKUP ARCHIVELOG LIKE 'ARC0003%.001;

In the first example, all archive logs that the target database has generated and
that still reside on the file system are backed up. In the second example, all
archive logs are backed up and then deleted from the file system afterwards. In
the third example, only archive logs between 30 days ago and 7 days ago are
backed up. In the fourth example, all archive logs that contain the specified SCN
or higher are backed up and then deleted afterwards. In the final example, all
archive logs that match the specified pattern are backed up. If a BACKUP
ARCHIVELOG command executes but finds no logs that meet the specified filter
criteria, RMAN does not return any errors, but instead simply does not create a
backup set, does not delete any files, and does not make any entries in the
repository.
Archive logs can also be backed up during any other type of backup by including
the PLUS ARCHIVE log option with the BACKUP command. For example, to
back up the entire database along with all archive logs, then delete the archive
logs afterwards, you would issue the following command:
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;

TASK 4C-4
Backing Up the Archive Logs
Objective: To back up the archive logs using RMAN.
1. Open a window to the D:\oracle\ora92\database\archive folder.
You should see a list of archive logs that have been generated by your
database. You will use RMAN to back up these archive logs, and then delete The number of archive logs
them from the system after the backup automatically. and their details on your
system may be different than
what is shown here.
2. Leaving the archive folder open, open a command prompt, and then
launch RMAN with the following command:
RMAN will launch and connect to both the target database and the recovery
catalog.
3. At the RMAN prompt, back up and delete the archive logs by issuing the
following command:
backup archivelog all delete all input;
The output will show that RMAN archived the current redo log, then allo-
cated a channel and generated a list of archive logs to include in the backup The number of archive logs
shown in the D:\oracle\ora92\
database\archive folder may
not match the number of
archive logs added to the
RMAN backup set. This is
because some of the archive
logs were rendered useless
when you opened the
database with the
RESETLOGS option ear-
lier in the course. RMAN
detects this and excludes
the unneeded archive logs
from the backup.

set. RMAN then added each archive log to the backup set, and deleted the
archive logs from the file system.
4. Exit from RMAN and the command prompt.
In the database window, you will see that the backed up archive logs have
been deleted from this folder. They were backed up by RMAN to the
D:\oracle\rman_bup folder, and then removed from the file system. Any
archive logs still in this folder are left over from an earlier ALTER
DATABASE OPEN RESETLOGS command.
5. Delete all remaining archive logs from the database folder.
Close the database window.
Topic 4D
RMAN Catalog Maintenance and Management
Since the RMAN recovery catalog consists of basic tables within the database,
RMAN provides the ability to store frequently used backup and recovery scripts
right in the catalog. Creating, maintaining, and executing stored scripts is
extremely easy and can greatly reduce the maintenance overhead of managing
these scripts using other methods, such as in standard text files in the file system.
RMAN scripts are created and managed right from the RMAN prompt. To create
a script, you would use the CREATE SCRIPT command, provide a script name,
and list the script commands within a set of curly braces. You do not need to add
a semicolon after the closing curly brace to terminate the command. The follow-
ing example creates a stored script to perform a full hot backup of the target
database:
RMAN> CREATE SCRIPT full_hot_backup
2> {
Creating an RMAN Stored
3> BACKUP DATABASE PLUS ARCHIVELOG;
Script 4> }

A useful feature of managing scripts with RMAN is that RMAN automatically
checks the scripts for syntax errors at creation time. If RMAN finds a syntax
error anywhere in the CREATE SCRIPT command, it will immediately return an
error and the script will not be created. Finding an error when the script is cre-
ated is better than finding an error at execution time, especially if the script is to
run unattended on a schedule.
To view the contents of a stored script from the RMAN prompt, you would use
the PRINT SCRIPT command and specify the script name. Unlike the
CREATE SCRIPT command, this command does require the semicolon to indi-
cate that the command is complete. The contents of the specified script will be
displayed right from the RMAN prompt, as shown in this example:
RMAN> PRINT SCRIPT full_hot_backup;
Displaying an RMAN
printing stored script: full_hot_backup
{ Stored Script
BACKUP DATABASE PLUS ARCHIVELOG;
}
If you need to change a script that is already stored in the catalog, you would use
the REPLACE SCRIPT command and include the script’s full syntax just as you
would if you were creating a new script, as shown in the following example:
RMAN> REPLACE SCRIPT full_hot_backup
2> {
Replacing an RMAN Stored
3> BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
4> } Script
In this example, the full_hot_backup script that was already stored in the recov-
ery catalog was replaced with a new set of commands.
To delete a stored script, you would use the DELETE SCRIPT command and
specify the name of the script you would like to delete, along with a terminating
semicolon. You must be very careful with this command; once executed, the
specified script is deleted immediately without further prompting from the DBA,
and there is no way to roll back the operation. The following example deletes the
full_hot_backup script:
RMAN> DELETE SCRIPT full_hot_backup;
deleted script: full_hot_backup

To execute a script from the RMAN prompt, you would issue the RUN command
with a set of curly braces, within which you would include the EXECUTE
SCRIPT command. The following command will execute the full_hot_backup
script:
RMAN> RUN {EXECUTE SCRIPT full_hot_backup;}
The RUN command is extremely flexible. You can include any number of com-
mands within its curly braces, such as several backup commands, and even
executing several stored scripts in succession.
When managing scripts from the RMAN prompt, RMAN simply adds, modifies,
and deletes the scripts within tables in the recovery catalog. As such, RMAN pro-
vides two recovery catalog-related views that can be used to view RMAN stored
scripts using standard SQL statements. The RC_STORED_SCRIPT view provides
the complete list of scripts that are stored within the catalog, and the
RC_STORED_SCRIPT_LINE provides a complete line-by-line listing of each

script. When querying from these views, it’s important to remember that the
name of the script is case sensitive and will be stored in the exact case you used
in the CREATE SCRIPT command. The following example shows a query to the
RC_STORED_SCRIPT line to bring up a list of all stored scripts in the recovery
catalog:
SQL> SELECT script_name
2 FROM rc_stored_script
3 ORDER BY script_name;
SCRIPT_NAME
------------------------------------------------
backup_archive_logs
backup_control_file
full_cold_backup
full_hot_backup
SQL>
The following example shows a query to the RC_STORED_SCRIPT_LINE view
to bring up the contents of the full_hot_backup script:
SQL> SELECT text
2 FROM rc_stored_script_line
3 WHERE script_name='full_hot_backup';
TEXT
-----------------------------------------------------
{
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
}
SQL>
It’s important to note that a stored script is only valid for the target database you
are currently connected to. In other words, if RMAN is connected to the ORA92
database as the target, and you execute the CREATE SCRIPT command, the
script you create can only be run against the ORA92 database. However, because
RMAN scripts are stored in tables within RMAN’s schema, it is very easy to add
or reassign RMAN scripts for other databases using basic SQL commands against
the RC_STORED_SCRIPT and RC_STORED_SCRIPT_LINE views from the
SQL*Plus prompt.
TASK 4D-1
Creating, Using, and Managing RMAN Scripts
Objective: To create, use, and manage RMAN scripts to simplify database
backups.
1. You will create an RMAN script to perform a full, hot backup of the
database. The script will be stored in the recovery catalog.
Open a command prompt, and launch RMAN with the following com-
mand:

catalog.
2. Your RMAN script will be named full_hot_backup, and will only back up
the database. Since all the essential configuration parameters are already set,
your script only needs to contain the BACKUP DATABASE command.
At the RMAN prompt, create the full_hot_backup script by issuing the

following command:
create script full_hot_backup
{
BACKUP DATABASE;
}
RMAN will display the message “created script full_hot_backup.” The script
is now stored in the recovery catalog and can be viewed through the
RC_STORED_SCRIPT and RC_STORED_SCRIPT_LINE views.
3. To see the contents of any RMAN script, you would issue the PRINT
SCRIPT command.
At the prompt, type print script full_hot_backup; and press Enter.
The output will show the contents of the full_hot_backup script.
4. After looking at the script, you decide that you want the script to also back
up the archive logs, then delete them from the file system afterwards. You
also want to tag the backup set for easy identification later. To change the
script, you would use the REPLACE SCRIPT command.

replace script full_hot_backup
{
BACKUP TAG test_script
DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
}
RMAN will display the message “replaced script full_hot_backup.”
5. To see the changed content of your script, type print script full_hot_
backup; and press Enter.
The output will show the new content of your script.
6. To execute a stored RMAN script, you would issue the RUN command, and
enclose the EXECUTE SCRIPT command, and the script name, inside a set
of brackets.
Execute your full_hot_backup script by issuing the following command:

run {execute script full_hot_backup;}
You will see RMAN execute the full hot backup as specified in the script.
The backup will include all datafiles except those specified by the EXCLUDE
parameter, the archive logs, the control file, and the spfile. Additionally, all
archive logs will be deleted from the file system after they are backed up.

7. You have decided that you no longer need the full_hot_backup script. You
will delete it using the DELETE SCRIPT command.
At the prompt, type delete script full_hot_backup; and press Enter.
RMAN will display the message “deleted script: full_hot_backup.”
RMAN Reports and Lists

RMAN provides a powerful reporting and listing capability that can be executed
right from the RMAN prompt. All information displayed in RMAN reports and
lists come directly from the recovery catalog. The LIST command is used to pro-
vide various lists of backups based on the backup history of the target database,
while the REPORT command is used to display information on just about every-
thing else that RMAN knows about the target database, such as the current layout
of the database, datafiles that need to be backed up, and so on.
The REPORT Command

There are four main options that can be used with the REPORT command, which
are listed in the following table. The REPORT Command
Options
Option Description
SCHEMA Reports on the layout of the target database, such as datafile names
and locations and their sizes.
UNRECOVERABLE Provides a report on the datafiles that have had unrecoverable
operations perform on their contents, such as tables that have the
NOLOGGING attribute set.
NEED BACKUP Provides a report about the datafiles that need to be backed up to
maintain the backup retention or redundancy policy set by the DBA.
OBSOLETE Reports on the database and archive log backups that can be deleted
because they have passed their retention or redundancy policy set by
the DBA.
The SCHEMA option can be used to report on the current layout of the target
database or the layout of the target at a specified point in time. You can specify
an alternate point in time with the AT clause along with a date and time string, a
specific SCN, or a log sequence number. Consider the following examples:
REPORT SCHEMA;
REPORT SCHEMA AT TIME '15-JAN-2003 08:00:00';
REPORT SCHEMA AT SCN=45614;
REPORT SCHEMA AT SEQUENCE=15 THREAD=1;

In the first example, the REPORT SCHEMA command generates a report based on
the current layout of the target database. In the second example, the command
generates a report based on how the layout of the database looked on January 15,
2003 at 8:00 A.M. The third command generates a report based on how the lay-
out of the database looked at change number 45614, while the last command
generates a report on how the database looked when redo log sequence 15 was
first opened. Specifying an alternate point in time with the REPORT SCHEMA
command can provide valuable information if you need to determine when the
layout of the target database had changed.
The UNRECOVERABLE option generates a list of datafiles that have had unrecov-
erable operations performed against their contents. For example, let’s say the
TOOLS tablespace contains a table that has its logging attribute set to
NOLOGGING. Since no DML operation against this table will generate redo infor-
mation, the datafiles of the TOOLS tablespace will have changes to data that
cannot be recovered using archive logs. The REPORT UNRECOVERABLE com-
mand can be used to determine which datafiles are affected. The DBA can either
decide to enable logging for objects in those tablespaces or to back up those
datafiles more frequently.
The NEED BACKUP option is used to generate a report of datafiles that need
backing up to maintain the retention policy set by the DBA. For example, if the
DBA has set a backup retention policy of seven days using the CONFIGURE
command, the REPORT NEED BACKUP command will report on the datafiles
that need to be backed up because they currently require more than seven day’s
worth of archive logs if the current backup copy were restored. Creating new
backups of those datafiles will result in fewer archive logs that need to be applied
if the live datafiles were restored from the new backups. The OBSOLETE option
is used to generate a report of datafiles that can be deleted because they are no
longer needed to satisfy the retention or redundancy policy set by the DBA.
The LIST Command

The LIST command is used to generate lists of backups that have been per-
formed for the target database and to list each incarnation of the target database,
which indicates each time the RESETLOGS option has been used with the
ALTER DATABASE OPEN command.
To generate a list of backups that have been performed for the target database,
you would simply include the BACKUP option with the LIST command. The
LIST BACKUP command by itself will instruct RMAN to generate a full list of
The LIST BACKUP all known backups for the target database, which will include all datafiles, control
Command Options files, archive logs, and spfiles. To filter the output, you can specify the type of
backup you wish to list with the BACKUP option. The following types of backups
can be listed with the LIST BACKUP command:
• TABLESPACE
• DATAFILE
• CONTROLFILE
• SPFILE
• ARCHIVELOG
The TABLESPACE option allows you to specify a single tablespace that you
want to generate your list for. The list will include all backups of any datafiles
that make up the specified tablespace. The following command will list all back-
ups of the SYSTEM tablespace:
LIST BACKUP OF TABLESPACE system;

You can also generate a list of a specific backup by including the TAG clause
with the LIST BACKUP command. This will generate a list of any backups with
the specified tag and will show all files included in each backup. The following
command lists all backups with the tag 'full_nightly':
LIST BACKUP TAG 'full_nightly';
When listing all backups of a single datafile, you would specify the current full
path and file name for that datafile. RMAN will list all backups for that datafile,
even if the file had been moved or renamed during its lifetime. The following
command will list all backups of the SYSTEM01.DBF datafile, currently found in
the D:\oracle\oradata\ora92 folder:
LIST BACKUP OF DATAFILE 'D:\oracle\oradata\ora92\system01.dbf';
The CONTROLFILE option will display a list of all backups of the control file,
regardless if the backup was performed by itself, included with a full database
backup, or by the control file autobackup feature. The same logic is applied to the
SPFILE option. With this option, all backups of the SPFILE will be listed,
regardless of whether the backups were performed manually or automatically. The
following two commands will list all control file and spfile backups, respectively:
LIST BACKUP OF CONTROLFILE;
LIST BACKUP OF SPFILE;

The COPY option will generate a list for all image copies that have been created
for the target database. When used alone, the LIST COPY command will gener-
ate a list that includes image copies of all file types, including datafiles, control
files, and archive logs. To filter the output, you can specify the file type with the
LIST COPY command, as shown in the following examples:
LIST COPY OF DATAFILE 'D:\oracle\oradata\ora92\system01.dbf';
LIST COPY OF ARCHIVELOG ALL;
LIST COPY OF CONTROLFILE;

The LIST ARCHIVELOG command is used to list backups of archive logs and
can include a filter to specify a single archive log, a range of archive logs, a file
name pattern, or all archive logs. This option accepts same filtering logic that can
be used for archive log backups. The following command lists backups of archive
logs using different filters:
LIST BACKUP OF ARCHIVELOG ALL;
LIST BACKUP OF ARCHIVELOG LIKE

'D:\oracle\oradata\oraarch\ora_0003%.arc';
LIST BACKUP OF ARCHIVELOG FROM SEQUENCE=15;

The LIST INCARNATION command will generate a list of all known incarna-
tions of all databases with entries in the recovery catalog. This list will show you
the date, time, the reset SCN for each time a database has been opened with the
RESETLOGS option. To filter the output to a single database, you can specify the
database name using the OF DATABASE clause, as shown in this example, which
will list only the incarnations for the ORA92 database:
LIST INCARNATION OF DATABASE 'ora92';

TASK 4D-2
Generate RMAN Reports and Lists
Objective: To generate RMAN reports and lists to extract backup infor-
mation from the recovery catalog.
1. Open a command prompt, then launch RMAN with the following com-
mand:
RMAN will launch and connect to both the target database and recovery
catalog.
2. To see a report of the current layout of the database, type report schema;
and press Enter.
The output will show a list of datafiles that currently exist in the ORA92
database. This information is very important when designing a backup and
recovery strategy for your database.
3. To generate a list of all backups of all files generated by RMAN for the tar-
get database, type list backup; and press Enter.
RMAN will generate a long list of backups that were generated. This list
The output may be so long will include all files that were backed up, including datafiles, control files,
that it will scroll up beyond
the maximum limit of the
command prompt, and you
may not be able to see all of
it. This is normal.

archive logs, and the spfile. You may have to scroll up to see all of the
output.
4. Since the LIST BACKUP command alone may generate more information
than can be easily read, you can filter the output based on the type of file
backed up.
To see a list of backed up datafiles only, type list backup of database; and
press Enter.
The output will show a list of all backup copies of the datafiles, but will not
include control files, archive logs, or the spfile.
5. To generate a list of backups of just the control file, type list backup of
controlfile; and press Enter.

The output will show a list of backup copies of the control file only.
6. To generate a list of archive logs that have been backed up, type list backup
of archivelog all; and press Enter.
The output will show only information about backup copies of archive logs
and which backup sets they belong to.
7. To generate a list of backups created as image copies, type list copy; and
press Enter.
The output will show only information about image copies that were gener-
ated by RMAN.
8. Earlier in this lesson, you generated an RMAN script to perform a full, hot
backup of the database. In that script, you specified a tag name for that
backup set, called test_script. You can generate a list of backup sets by their
tag name.
At the prompt, type list backup tag test_script; and press Enter.

The output will show all the information about the backup set that was gen-
erated from your RMAN script. The backup set was easily identified by the
tag test_script.
9. RMAN uses the RETENTION POLICY configuration parameter to deter-

mine which datafiles are in need of backing up and which backups are no
longer needed for recovery.
To determine the current retention policy for the target database, type show
retention policy; and press Enter.
The output will show that the current retention policy is set to 1, which
means that RMAN is configured to maintain exactly one backup copy of all
critical database files. To comply with the retention policy, any backup cop-
ies other than the most current one will be considered obsolete. Also, any
files that have not been backed up, or files whose last backup is older than
the current full backup, will be considered in need of a backup.
10. To determine which datafiles are in need of backing up to comply with the
retention policy, type report need backup; and press Enter.
The output will show that the EXAMPLE01.DBF datafile is in need of

backup. This file has been excluded from all backups, as specified by the
EXCLUDE parameter. Because of this, the file is in need of backup to com-
ply with the retention policy.
11. To determine which backups are obsolete and can be deleted, type report
obsolete; and press Enter.

The output will show a list of backup sets and backed up control files that
are no longer necessary to comply with the retention policy. You may have
to scroll up to see all of the output. These files can be deleted and purged
from the recovery catalog. You will learn how to do this in the next task.
Crosscheck and Delete Backup Sets

Over time, the backup entries in the recovery catalog may differ slightly than
what is actually stored on disk or on backup tape. This may be caused by older
backup files being manually deleted with OS-level commands, backup tapes being
crosscheck: overwritten by the media manager, or by media failure where the backup files
A process of validating reside. To help keep the recovery catalog up to date and purge old entries,
recovery catalog entries RMAN provides the CROSSCHECK command to identify backup entries that are
against the backup files that
actually exist in the file
no longer valid.
system. The CROSSCHECK command only executes against backup entries for the current
target database, and can be used to validate any type of backup that can be cre-
ated with the BACKUP or COPY commands, as shown in the following examples:
CROSSCHECK BACKUP;
Crosschecking Backups
CROSSCHECK BACKUP OF CONTROLFILE;
and Copies
CROSSCHECK BACKUP OF TABLESPACE system;
CROSSCHECK BACKUP OF DATAFILE

'D:\oracle\oradata\ora92\tools01.dbf';
CROSSCHECK COPY OF CONTROLFILE;
CROSSCHECK COPY OF DATAFILE

'D:\oracle\oradata\ora92\tools01.dbf';
In the first example, all backups of all types for the target database are validated
against the actual backup files that exist in their backup locations. The second
example crosschecks all backups of the control file. The third example
crosschecks all backups of the system tablespace, while the fourth example
crosschecks a single datafile. The last two examples crosscheck image copies of
the control file and a single datafile, respectively.

You can also specify specific backups with the CROSSCHECK command, such as
by tag, by backup set number, or backup piece number. This allows you to iden-
tify a single backup entry in the recovery catalog if you need to. Some examples
of these crosschecks are shown here:
CROSSCHECK BACKUP TAG full_weekly;
CROSSCHECK BACKUPSET 433,434,435,436;
CROSSCHECK BACKUPPIECE 887,888,889;

In the first example, RMAN will crosscheck all backups with the tag full_weekly.
In the second example, backup sets with the ID numbers listed will be
crosschecked. When crosschecking complete backup sets, all backup pieces
within each set are automatically crosschecked. In the last example, only specific
backup pieces are crosschecked.
When RMAN crosschecks a backup or image copy, it will compare its entries in
the recovery catalog to the list of files that actually exist in the file system. If any
of the files are not found on the file system, the related entries are marked as
EXPIRED in the recovery catalog. RMAN will not consider any expired backups
or image copies as valid backups for restore and recovery operations in the event
of a media failure.
After executing the CROSSCHECK command, you can issue the LIST EXPIRED
command, which will generate a list of all expired backups in the recovery
catalog. The DELETE EXPIRED command can be executed to purge all expired
backup entries from the recovery catalog. This command does not delete any files
from the file system.
Delete Existing and Obsolete Backups

While the CROSSCHECK command together with the DELETE EXPIRED com-
mand can identify backup entries in the recovery catalog for which the physical
backup files no longer exist, the DELETE command, with other appropriate
options, can be used to delete valid backups, including the physical files in the
backup locations and all recovery catalog entries. Any backup that can be created
with the BACKUP and COPY commands can be deleted with the DELETE com-
mand, as shown in the following examples:
DELETE BACKUP;
Deleting Backups and
DELETE BACKUP OF TABLESPACE system;
Copies
DELETE BACKUP OF DATAFILE 'D:\oracle\oradata\ora92\system01.dbf';
DELETE BACKUP TAG full_weekly;
DELETE BACKUPSET 364,383,838;
DELETE COPY OF DATAFILE 'D:\oracle\oradata\ora92\example01.dbf';

The first example is actually a very powerful one. All backups for the current
target database will be deleted, regardless of the file type of the backup, including
datafiles, control files, archive logs, and spfiles. The second example deletes all
backups for the SYSTEM tablespace, while the third example deletes all backups
of only a single datafile. The fourth example deletes all backups with the tag
full_weekly, while the fifth example deletes all listed backup sets. The final
example deletes all image copies of the EXAMPLE01.DBF datafile.

When executing the DELETE BACKUP or DELETE COPY commands, RMAN
will first list all backups it has found in the recovery catalog that meet the crite-
ria, then prompt the DBA for confirmation before actually proceeding with the
operation. When deleting the recovery catalog entries and backup files, if any
recovery catalog entries are found that do not have corresponding backup files on
the file system, the entries are deleted without error. Any backup files that do not
have a valid entry in the recovery catalog are ignored, because RMAN has no
way of knowing what those files are.
If you need to remove the entries about a backup from the recovery catalog, but
you want to retain the backup files, then you have two options. You can move or
rename the files then use the DELETE command to purge the catalog entries. The
other option is to use the CHANGE command with the UNCATALOG option. This
command can be used to delete recovery catalog entries while ignoring the corre-
sponding files in the backup locations. The following example illustrates the use
of this command:
CHANGE BACKUPSET 832 UNCATALOG;
In this example, the recovery catalog entries for backup set 832 will be purged
from the catalog. The backup pieces that make up this backup set, however, will
be left untouched where they are stored. This provides the DBA a convenient
way of cleaning up the recovery catalog even if the backup files must be kept for
any reason.
If the DBA has configured a retention policy for backups with the CONFIGURE
RETENTION POLICY, then the REPORT OBSOLETE command can be used to
generate a report of all backups that can be deleted because they are no longer
needed to comply with the retention policy. For example, if the retention policy is
set to a redundancy of three backups per datafile, the REPORT OBSOLETE com-
mand will report on any backup that is no longer needed since three backups for
that datafile already exist that are more recent. The DELETE OBSOLETE com-
mand can be used to delete all obsolete backups in the recovery catalog. This
command will purge all recovery catalog entries as well as remove their related
backup files from the backup locations.
To make a specific backup exempt from the retention policy, you can use the
CHANGE...KEEP command, as shown in the following example:
CHANGE BACKUPSET 243 KEEP;
In this example, the backup set with ID number 243 will be exempt from the
retention policy, meaning that the REPORT OBSOLETE and DELETE
OBSOLETE will not consider this backup as obsolete, even if its existence defies
the retention policy. To make a backup comply with the retention policy, you
would use the UNKEEP option with the CHANGE command, as shown in this
example:
CHANGE BACKUPSET 243 UNKEEP;

TASK 4D-3
Crosschecking and Deleting Backup Sets
Objective: To crosscheck backup sets against the recovery catalog and
delete expired and obsolete backups.
1. You will first delete a backup set from the file system manually, and then
update the recovery catalog using the CROSSCHECK and DELETE
commands.
Open a window to the D:\oracle\rman_bup folder.
Find the backup set file with the highest backup set ID. The backup set
ID is indicated by the number immediately following the database name
ORA92. In the example shown here, that file is ORA92_21_1.
Select the backup file with the highest backup set ID and press
Shift+Delete. A question box will appear asking if you are sure you want to
delete the file. Click Yes.
2. Leaving the rman_bup window open, open a command prompt, and then
catalog.
3. To validate the backup entries in the recovery catalog, type crosscheck

backup; and press Enter.
You will see RMAN allocate a channel, then compare each backup entry in Your results will vary
the recovery catalog against what actually exists on disk. Towards the end of depending on the number of
the output, you will see that the file you deleted could not be found on the archive logs.

disk, and was therefore marked as EXPIRED in the recovery catalog.
4. Since the backup set is no longer available on disk, the related entries for
that backup set in the recovery catalog can be purged.
At the prompt, type delete expired backup; and press Enter.
RMAN will allocate a channel, display a list of entries found to be expired

in the recovery catalog, and then ask you if you really want to delete the
listed objects. Type YES and press Enter.
The output will show that the expired backup was deleted, which means that
the recovery catalog entries related to the expired backup set were purged
from the catalog.
5. Obsolete backups are backups that are no longer needed according to the
configured retention policy.
To see a list of obsolete backups, type report obsolete; and press Enter.

The output will show a list of all backup copies that are no longer necessary
as determined by the retention policy.
6. The DELETE OBSOLETE command will automatically purge all obsolete

backup entries from the recovery catalog and remove the related files from
disk, if they exist.
At the prompt, type delete obsolete; and press Enter.
The output will show a list of files that RMAN has determined are obsolete,
and asks if you really want to delete the objects. Type YES and press
Enter.

You will see RMAN allocate a channel, then delete each obsolete backup.
7. Switch back to the rman_bup window.
You will see that the folder contains only a few files. One of these files is
the current backup of the control file. The other files contain a complete set
of backed up datafiles and archive logs that would be required to perform a
complete recovery in the event of a failure. RMAN had deleted all other
backup sets, which were no longer needed according to the retention policy.
8. Close the rman_bup window.
Exit from both RMAN and the command prompt.
Catalog OS-level Database Backups

If a user-managed database backup was performed using the ALTER
TABLESPACE...BEGIN BACKUP and standard OS-level copy commands,
these backups can still be cataloged in RMAN’s recovery catalog. This lets the
DBA take advantage of many of RMAN’s capabilities, even if RMAN did not

create the backup. To generate catalog entries for a user-managed backup, you
would use the CATALOG command and specify the full path and name of the file
to catalog. This command can be used to catalog image copies of datafiles, con-
trol files, and archive logs. The CATALOG command accepts three different
options, DATAFILECOPY, CONTROLFILECOPY, or ARCHIVELOG. You can
specify multiple files of the same type to catalog within a single command, but
you cannot mix file types within a single command. If you need to catalog differ-
ent file types, you must list each type of file with separate CATALOG commands.
Since only RMAN can create its own proprietary backup sets with backup pieces,
the CATALOG command can only generate catalog entries for image copies of
files created by OS-level commands. Additionally, you can only catalog backup
files that were generated by the target database you are currently connected to.
This is because RMAN will associate the newly-cataloged backup files with the
current target database. If you attempt to catalog a backup file that originated
from a different database, RMAN will return an error. The following examples
illustrate the use of the CATALOG command:
CATALOG DATAFILECOPY 'D:\oracle\hot_bup\system01.dbf';
The CATALOG Command
CATALOG CONTROLFILECOPY 'D:\oracle\hot_bup\control.bak';
CATALOG ARCHIVELOG
'D:\oracle\oradata\ora92\archive\ARC_0003.ARC';
Once the information about manually created backups have been cataloged in the
recovery catalog, RMAN can immediately consider those backup files as candi-
dates for restore if necessary.
TASK 4D-4
Cataloging OS-level Database Backups
Objective: To catalog database backups that were performed through OS
commands with the recovery catalog.
1. Earlier in the course, you had performed a user-managed full cold backup of
the database and stored the backed up files in the D:\oracle\cold_bup folder.
Open a window to the D:\oracle\cold_bup folder.
These files were created through the use of standard operating system com-
mands and are not currently listed in the recovery catalog. You will use
RMAN to create entries for some of these files in the recovery catalog so the
backup can be restored by RMAN if necessary.
Close the cold_bup window.
2. Open a command prompt, and launch RMAN with the following com-
mand:
catalog.
3. To generate a list of image copies currently registered in the recovery cata-

log, type list copy of database; and press Enter.

No image copies are currently registered in the recovery catalog, therefore
RMAN will not return any output.
4. Register the backup copies of the SYSTEM, USERS, and TOOLS

datafiles with the following commands:
catalog datafilecopy 'D:\oracle\cold_bup\system01.dbf';
catalog datafilecopy 'D:\oracle\cold_bup\users01.dbf';
catalog datafilecopy 'D:\oracle\cold_bup\tools01.dbf';
After each datafile, RMAN will return the message “cataloged datafile copy”
and display the file name, record id, and a stamp ID to uniquely identify the
file in the recovery catalog.
5. To confirm that the backup files have been registered with the recovery cata-
log, type list copy of database; and press Enter.
While in this activity you are The output will show that you have successfully cataloged the datafiles of
only cataloging some of the the SYSTEM, USERS, and TOOLS tablespaces with the recovery catalog. If
files of a cold backup, you
the need arises, RMAN will be able to locate, restore, and recover these
must remember that all files
of a cold backup must be backup datafiles in the event of a disk failure or file corruption.
available in order to recover
and restore the database with
that backup, including the
datafiles and the control file.

Backup and Restore Validation
No backup and recovery strategy is complete without testing the capabilities and
soundness of its routines. RMAN provides a feature to validate its backup and
restore capabilities. This is done by including the VALIDATE option with the
specific BACKUP or RESTORE command you wish to test. This option can be
included with any backup or restore operation RMAN can perform, as shown in
the following examples:
BACKUP VALIDATE DATABASE;
Backup and Restore
RESTORE VALIDATE DATABASE;
Validation
When validating a backup or restore operation, RMAN does not actually perform
the operation. Instead, RMAN acts out the process, but does not generate backup
sets, restore datafiles, nor make entries in the recovery catalog. It simply checks
for file existence and availability of channel resources. For example, let’s say you
issued the following command:
BACKUP VALIDATE TABLESPACE system;
RMAN will act out the process of backing up the SYSTEM tablespace, but will
not actually do so. It will simply allocate the channel, ensure that the SYSTEM
tablespace exists in the target database, locate its files, then attempt to reach the
backup destination. If RMAN encounters any errors during the process, such as
not being able to reach the backup destination because of an invalid configura-
tion, RMAN will report the errors.
During a restore validation, RMAN will attempt to find a valid backup that exists
in its backup location and act out the process of restoring the file without actually
doing so. RMAN will immediately terminate the operation if any part of the vali-
dation fails, such as not finding a valid backup for the specified target. For
example, let’s say you issued the following command:
RESTORE VALIDATE TABLESPACE sales;
If no SALES tablespace exists in the target database, or if the tablespace exists
but has never been backed up, RMAN will return an error. The VALIDATE fea-
ture can be extremely useful if you need to determine whether or not your backup
and recovery strategy is sound and will work when necessary.
TASK 4D-5
Validate Backup and Restore Operations
Objective: To ensure that a specified backup or restore operation can suc-
ceed as expected.
1. You will perform validation checks to ensure that the database can be
backed up and restored using the existing RMAN configuration.
Open a command prompt and launch RMAN with the following com-
mand:
catalog.

2. At the RMAN prompt, type backup validate database; and press Enter.
The output will look very similar to a standard backup, except RMAN does
not actually perform the backup. RMAN acts out the backup process but
does not generate a backup set, nor does it record any information to the
recovery catalog. If any issues are found during the process, such as a chan-
nel configuration for a backup tape that does not exist, messages would be
included in the output to provide information about the issues.
3. Once the backup validation is complete, type restore validate database; and
press Enter.
The output will show that RMAN starts the validation of the datafile backup
set, and acts out a full restore of the database using the latest full backup. If
any issues are found during the process, messages would be included in the
output to provide information about the issues. In this case, RMAN has
reported that there is no backup or image copy of datafile 5 found to restore.
This is because the EXAMPLE01.DBF datafile has been excluded from all
database backups. This information could be critical when determining if the
current database backups are sufficient to recover from a major failure.

Backing Up the Recovery Catalog
Because the RMAN recovery catalog exists in a standard schema within an
Oracle database, you should take sufficient measures to safeguard the database
against failures. If the database where the recovery catalog is lost, you will not be
able to use RMAN or its backups to restore or recover any database that RMAN
supports. However, backing up the recovery catalog poses an interesting
challenge.
If you use RMAN with the recovery catalog to back up the recovery catalog data-
base, and the recovery catalog database subsequently suffered media failure, you
would not be able to restore the database from the backup you generated. This is
because RMAN would need to log in to the recovery catalog to restore the
backup, but the recovery catalog would not be available because the database is
down. To avoid this paradox, there are multiple techniques that you could use to
create a valid backup of the recovery catalog database that you could actually
restore from.
Since the recovery catalog database itself is just like any other Oracle database,
stored inside an Oracle database, any backup method could be used to back up
this database. However, the key to this scenario is not the backup of the database,
but the ability to restore the database using whatever backup you create. You
could use the Oracle export utility to export the recovery catalog on a regular
basis, or you could use manually scripted hot backups. However, these solutions
ultimately defeat the purpose of using RMAN in the first place, which is to sim-
plify and improve the backup and recovery process for all Oracle databases in an
environment.
One technique is to set up two or more RMAN recovery catalogs in different
databases. With this configuration, each recovery catalog can share the load of Multiple Recovery Catalogs
backing up the databases in the environment, and also each recovery catalog can for Cross-backups
be used to back up the other. Figure 4-12 illustrates this concept.
Figure 4-12: Using multiple RMAN recovery catalogs to perform backups.

In this figure, two RMAN recovery catalogs have been configured. Each recovery
catalog acts as the RMAN repository for half of the databases in the environment.
Additionally, each catalog is used to back up the other. If media failure causes the
loss of one catalog, the other RMAN configuration can be used to restore and
recover it.
While this configuration may be ideal for larger environments, it may not be a
viable solution for smaller environments. There may not be enough target data-
bases that need backing up to justify the cost of setting up to independent servers,
each with its own RMAN configuration. Another solution is to use the RMAN
utility to perform the backups, but use the control file of the database where the
recovery catalog resides as the RMAN repository for that one database. In addi-
tion, you would use RMAN to create image copies of the database’s datafiles,
rather than RMAN backup sets. Using this technique, RMAN can still be used to
back up the database, but if some sort of failure causes the database to become
unavailable, you will not be dependent on the recovery catalog to restore it. Addi-
tionally, if the recovery catalog database uses its control file, you will be able to
use RMAN to perform the recovery since its repository is gone. However, since
you backed up the database using image copies, you can simply use OS-level
commands to restore the control file and any other datafiles that were lost. Figure
4-13 illustrates this technique of backing up the recovery catalog database.
Backing Up a Single
Recovery Catalog
Figure 4-13: Using RMAN to back up a single recovery catalog database.

In this figure, a single RMAN configuration is being used to back up all the criti-
cal Oracle databases in the environment, using the recovery catalog as the
repository. However, for the backup of the recovery catalog database itself, the
database’s control file is used as the RMAN repository, and image copies are cre-
ated from the database’s datafiles, control file, and archive logs. Using this
technique, the recovery catalog database can be restored from most media
failures. If a datafile is lost, RMAN can restore the datafile from the image copy
while using the control file as the repository. If the control file is lost, you cannot
use RMAN to restore it since the repository is also lost, but you can restore the
control file manually since it is just an image copy. Once the control file is
restored, you can continue with the recovery manually, or you can optionally
switch back to RMAN to perform the recovery.

TASK 4D-6
List and Describe Methods to Back Up the Recovery
Catalog
1. You have created a database that will house the RMAN recovery
catalog. This database will also house the repositories for Oracle Enter-
prise Manager and several of its add-on components, such as the
Performance Manager, the Change Manager, and Oracle Expert. Discuss
some of the ways that this database could be backed up, and identify the
method that you think would work best.
Because the database itself is just like any other Oracle database, any
backup method could be used to back up this database. However, the key to
this scenario is not the backup of the database, but the ability to restore the
database using whatever backup you create. You should ensure that a recov-
ery of the database does not depend on the recovery catalog that is housed
inside the database itself. If the database is unavailable, then so is this
repository.
Some of the most favored options include:
• Manually scripted hot backups.
• RMAN hot backups creating image copies of all datafiles, using the
control file as the repository.
• Multiple RMAN repositories, each one backing up another.
The best solution will be the one that fits the requirements best. In the simple
scenario given, with no other information, the best strategy might be to use
RMAN to create hot backups consisting of image copies of the database. To
eliminate the dependency on the recovery catalog, you would use the control
file as the repository. This strategy provides the ease of RMAN’s backup
management features, and allows you to restore the datafiles of any of the
tablespaces, provided that the database is up and accessible. This will also
allow you to manually restore the datafiles and/or control file manually in
the event that the current control file is lost.
2. What benefit would you gain by performing logical backups of the

recovery catalog using Oracle’s export utility, in addition to standard
physical backups of the recovery catalog database?
If the server where the recovery catalog database is completely lost, you can
quickly import the recovery catalog contents to any Oracle database of a
compatible version. This may be quicker than rebuilding the lost server and
restoring the database where the recovery catalog originally resided. While
storing the recovery catalog on another database that may be a potential
target database for backups may not be a preferred long term solution, this
may provide a short term solution to allow backups and recoveries of pro-
duction databases until the original RMAN server is rebuilt.

Summary
In this lesson, you learned about the basic features of Recovery Manager
(RMAN), and the basic steps RMAN uses to back up and recover an Oracle
database. You also learned how to configure the RMAN environment, and
how to prepare a database for RMAN backups. You learned how to perform
database backups with RMAN to create both backup sets and image copies
of critical files. Finally, you learned how to maintain, manage, and back up
the RMAN recovery catalog.
Lesson Review
4A Your database has a 30 megabytes datafile that was completely full.
After truncating several tables, the volume in the datablock dropped
down to 12 megabytes. How many megabytes of this datafile will be
backed up by RMAN.
a. 12
b. 26
✓ c. 30
d. The file will not be backed up.
Which of the following can be stored in the repository when using the
recovery catalog as a repository, but not with the control file?
a. Target-specific configuration parameter settings.
✓ b. Stored scripts.
c. Information about corruptions in backup files.
d. Complete archive log history.
What is the purpose of the communication channel between RMAN and

the target database?
The communication channel is a dedicated connection to the target database
and is used to perform the work of copying files to their backup destination,
restoring files, and performing recovery of the target database.
4B What command would you use to invoke RMAN and connect to both
the target database and recovery catalog simultaneously?
rman target username/password@db1 catalog
username/password@db2

From which prompt would you execute the appropriate commands to
create the recovery catalog?
a. Command prompt
b. Listener control
✓ c. RMAN prompt
d. SQL*Plus prompt
What information about the target database is loaded into the recovery
catalog when the database is first registered with the catalog? Choose all
that apply.
a. Control file layout
✓ b. Database name
✓ c. Incarnation information
✓ d. Oracle version
True or False? Setting the EXCLUDE parameter for the INDX tablespace
will cause the tablespace to be excluded from all backups of all data-
bases supported by that repository. Explain your answer.
False. A tablespace exclusion is target database-specific, meaning that a
tablespace that has been added to the exclusion list will only be excluded
from future backups of the target database RMAN is currently connected to.
Each database will have its own tablespace exclusion list.
4C For an RMAN cold database backup, why does the database have to be
in the mount state?
This allows RMAN to log in to the database and read pertinent information
from the data dictionary and control file to update the RMAN repository.
True or False? When performing a database backup of a database using

RMAN, RMAN must put each tablespace into backup mode before
backing up each one.
False. RMAN does not have to put tablespaces in backup mode. It simply
connects to the target database and starts backing up files, which reduces
the performance impact on the target database.
A level 0 incremental backup was performed on Tuesday, and a level 3

incremental backup was performed on Wednesday. If a level 2 incre-
mental backup is performed on Thursday, the backup will include
datablocks that have changed since what day?
a. Monday
✓ b. Tuesday
c. Wednesday
d. Since the database was created

What command would you use to back up all archive logs that have
been generated since June 1, 2003?
BACKUP ARCHIVELOG FROM TIME '01-JUN-2003';
4D True or False? RMAN checks the syntax of a stored script at run time.
False. RMAN checks the syntax of a stored script when the script is created.
The tablespaces in your database all have logging enabled by default.

However, a user executed a DDL command with the NOLOGGING option.
How could you determine which datafiles were affected by this opera-
tion?
a. Issue the LIST UNRECOVERABLE command at the RMAN
prompt.
✓ b. Issue the REPORT UNRECOVERABLE command at the RMAN
prompt.
c. Look in the V$RECOVER_FILE data dictionary view.
d. Look in the V$UNRECOVERABLE data dictionary view.
When the CROSSCHECK command is executed, what does RMAN

delete? Choose all that apply.
a. Obsolete backup pieces.
b. Redundant backups.
c. Repository entries.
✓ d. None of the above.
True or False? The CATALOG command can be used to recatalog a

backup set if the information about the backup set has been purged
from the recovery catalog. Explain your answer.
False. The CATALOG command will only generate catalog entries for
backup files created from a user-managed backup, which essentially are
image copies. It cannot be used to catalog a backup set that is in RMAN’s
proprietary format.
True or False? When an operation is executed with the VALIDATE

option, RMAN does not need to allocate a communication channel since
no files are actually backed up or restored. Explain your answer.
False. During a validation operation, RMAN acts out all steps that are
required to perform the operation, including allocating a channel, but does
not actually backup or restore any datafiles.

Your environment has a single RMAN recovery catalog database. This
database is backed up by RMAN using the control file as the repository
and by creating image copies of all database files. Give a brief summary
of how you would recover this database in each of the following failure
scenarios:
• Loss of a data file
• Loss of the control file
• Loss of a datafile—The image copy of the datafile can be restored auto-
matically by RMAN, which can also perform the database recovery.
• Loss of the control file—The image copy of the control file needs to be
restored manually. The database recovery can then be handled manually
or by RMAN.

Recovery Manager LESSON
Recoveries
5
Data Files
logfiles.sql
Overview
Lesson Time
The power of RMAN is easily realized when performing a recovery for a 3 hours
database that has suffered media failure. RMAN can easily handle restoring
files and performing complete and incomplete recoveries in various failure
scenarios. In this lesson, you will learn how to use RMAN to restore lost
files from backup and perform complete recoveries. You will also learn how
to perform RMAN incomplete recoveries when a complete recovery is not
possible. Finally, you will learn about the mechanisms RMAN provides to
support RMAN-managed tablespace point-in-time recovery.
Objectives
To perform complete and incomplete recoveries of the database using RMAN,
you will:
5A Perform a complete recovery of the database with RMAN.

To perform a complete recovery of a database, you would first restore
any lost files and then apply all changes from the archive logs to restored
datafiles to bring them up to date with the rest of the database. In this
topic, you will learn how to restore a datafile from backup and perform
complete recoveries using RMAN.
5B Perform an incomplete recovery of the database with RMAN.

Performing an incomplete database recovery with RMAN is very similar
to performing a user-managed incomplete recovery with only some minor
differences. In this topic, you will learn how to perform incomplete
recoveries of the database in various failure scenarios, such as loss of the
control file or the current redo log.
Lesson 5: Recovery Manager Recoveries 285

Topic 5A
RMAN Complete Recovery
Before attempting to perform recovery on a database that has suffered media fail-
ure, you must first restore any lost files from backup. One of the most powerful
features of RMAN is its ability to quickly determine which files need to be
restored, locate the backup copies in the backup locations, and restore them to
their original locations. RMAN even provides the ability to restore files to new
locations if the original file locations are no longer available.
The RESTORE command is used to restore files from backup. This command
accepts a wide range of options and can be used to restore from any set of
backup files that can be created with the BACKUP command. For example, if you
issue the RESTORE DATABASE command, RMAN will automatically scan all
control files and datafiles to determine which files need to be restored, then locate
the appropriate backup files and restore them. If you issue the RESTORE
TABLESPACE command and specify a tablespace name, RMAN will restore any
datafiles that are missing for that tablespace. Any datafiles that do not need to be
restored will not be touched, unless you also include the FORCE option. If this
option is included, all datafiles for the specified recovery target are restored,
regardless if the file already exists in the file system. For example, if you issue
the following command, RMAN will restore all datafiles for the EXAMPLE
tablespace, even if only one was missing:
RESTORE FORCE TABLESPACE example;
RMAN does not necessarily restore all specified files from the same backup set.
When determining which backup to use to restore the specified files, RMAN will
immediately try to extract the files from their last known backup. However, if
that operation fails for any reason, RMAN will automatically try to extract the
files from a previous backup. It will keep trying older and older backups until it
determines that there is no valid backup file that can restore the specified file, at
which point it will return an error. During a successful restore operation, it is
completely possible that RMAN will restore one file from one backup set and
another file from a different backup set. You must remember that restoring files
only replaces lost files with their backup copies. It does not, however, apply
archive logs to roll the database forward to the point of failure.
Restore Files to New Locations with RMAN

If the original location of a datafile is no longer available due to media failure,
then you must restore the datafile to a new location. To do this with RMAN, you
would follow these steps
• Provide RMAN with the new paths and file names you want to restore the
files to.
• Restore the lost files to their new locations.
• Rename the files in the target database’s control file to point to their new
locations.
• Recover the files.
• Bring the recovered files or tablespaces online.

To provide RMAN with the new paths and file names you want to restore the lost
files to, you would use the SET NEWNAME command. With this command, you
would indicate the file you want restored by specifying either the file ID number
or full path and file name of the file’s original location. You would also include
the full path and file name of its new location. The following example will pro-
vide RMAN with the new location and file name where datafile 28 will be
restored to:
SET NEWNAME FOR DATAFILE 28 TO
'F:\oracle\oradata\newdisk\sales05.dbf';
The SET NEWNAME command only instructs RMAN where to restore the file to,
but it does not actually restore the file, nor does it change the target database’s
internal pointers to the file. After issuing the SET NEWNAME command, you
would restore the files to their new locations by issuing the RESTORE command.
Once the datafiles are restored, you must issue the SWITCH command, which is
equivalent to the ALTER DATABASE RENAME FILE command for the target
database. The SWITCH command accepts either the file ID number of the file you
are restoring, its full path and file name, or the ALL option, which adjusts all of
the target database’s internal pointers for all datafiles you have specified with the
SET NEWNAME command. The following example changes all internal pointers
for the target database to the newly restored datafiles that were specified with
SET NEWNAME commands:
SWITCH DATAFILE ALL;
Once all missing files have been restored to their new location and the target
database’s internal pointers have been set to point to the newly-restored files, you
can begin recovery.
All the commands for this entire operation must be executed from within the
curly braces of a RUN block. If you attempt to issue the SET NEWNAME or
SWITCH commands directly at the RMAN prompt, you will receive an error. The
following example will perform the entire operation of restoring lost datafiles,
renaming them in the target database, recovering the files, then bringing them
online:
RUN
{
Restoring a File to a New
SQL 'alter tablespace sales offline immediate';
SET NEWNAME FOR DATAFILE 28 TO Location
'F:\oracle\oradata\newdisk\sales05.dbf';
RESTORE TABLESPACE sales;
SWITCH DATAFILE ALL;
RECOVER TABLESPACE sales;
SQL 'alter tablespace sales online;'
}
In this example, RMAN will first bring the SALES tablespace offline with the
IMMEDIATE option. This is because one of the tablespace’s datafiles,
SALES05.DBF, has been lost due to media failure. The IMMEDIATE option
brings the tablespace offline without issuing a checkpoint on its datafiles, which
would cause an error due to the missing file. The SET NEWNAME command pro-
vides RMAN with the new path and file name where the backup datafile will be
restored to, and then the RESTORE command actually restores the file. The
SWITCH DATAFILE ALL command changes the target database’s pointers for
datafile 28 to its new path and file name. The RECOVER command performs
recovery for the SALES tablespace, and the final command brings it back online.

TASK 5A-1
Restoring Files with RMAN
Objective: To restore lost files from backup using RMAN.
1. Before attempting to restore datafiles, you will ensure that you have one
good, hot backup of the database. You will perform this backup with RMAN
while using the target database control file as the RMAN repository.
mand:
RMAN will launch and connect to the target database and will use the con-
trol file as the RMAN repository.
2. You will perform a backup of all datafiles in the database, including the
EXAMPLE datafile. Currently, the EXAMPLE table is excluded from all
backups, as specified by the EXCLUDE parameter.
To change the EXCLUDE parameter to stop excluding the EXAMPLE

tablespace from backups, issue the following command:
CONFIGURE EXCLUDE FOR TABLESPACE 'EXAMPLE' CLEAR;
After a moment, RMAN will display the message “tablespace EXAMPLE

will be included in future whole database backups”, and that the old RMAN
configuration parameters were successfully deleted.
3. You will now perform the full, hot backup. The backup will include all
datafiles, the control file, the spfile, and all archive logs. You will also delete
the archive logs from the file system after they have been backed up.
Your results may vary
depending on the number of At the RMAN prompt, issue the following command:
archive logs.
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
You will see RMAN begin the backup process. It will take a few minutes for
the backup to complete.

Once the backup is complete, exit from both RMAN and the command
prompt.
4. You will now simulate the loss of all datafiles, then restore them from your
backup using RMAN.
To shut down the database, type shutdown immediate; and press Enter.
You will see Oracle close and dismount the database, then shut down the
instance.

You will delete all Oracle datafiles from this folder. You will not delete the
control files, the redo log files, or the TEMP01.DBF file. Select the follow-
ing files to delete:
• CWMLITE01.DBF
• DRSYS01.DBF
• INDX01.DBF
• ODM01.DBF
• RMAN01.DBF
• SYSTEM01.DBF
• TOOLS01.DBF
• UNDOTBS01.DBF
• USERS01.DBF
• XDB01.DBF
Delete the selected files, and only these files, from the folder. Be careful

not to delete any files other than what is listed here.
You will see Oracle start the instance and mount the database, but the data-
base will not open because it cannot file the SYSTEM01.DBF datafile. You
have simulated the loss of all datafiles in the database.
Exit from the SQL*Plus window.
7. You will use RMAN to restore all the datafiles from the last backup.
Open a command prompt, and then launch RMAN with the following
command:

RMAN will launch and connect to the target database using the control file
as the RMAN repository.
8. To restore the datafiles from the last backup, type restore database; and
press Enter.
RMAN will determine the type of recovery that is required and which
backup copies of the datafiles should be used to restore the database. RMAN
will then extract those files from the appropriate backup set and restore them
to their original locations.
9. Once the restore is complete, exit from both RMAN and the command
prompt.
Switch back to the ora92 window.

You will see that the datafiles you deleted earlier have all been restored by
RMAN.
Although the datafiles have been restored, you must remember that restoring
datafiles only involves copying the datafiles from their backup locations to
their original locations. It does not, however, recover the database to roll
forward changes contained in the archive logs. The database will remain in
an unusable state until the recovery is performed. You will do this in the
next activity.
10. Close the ora92 window.
Performing Complete Recovery

To perform a recovery with RMAN, you would use the RECOVER command, just
as you would during a user-managed recovery. The main difference between an
RMAN recovery and a user-managed recovery is that RMAN will automatically
determine where the required archive logs are stored, restore them from backup if
necessary, and apply them to the database. Whereas with user-managed recovery,
you would need to perform all those activities manually.
The RECOVER command can be used to perform recoveries on the entire data-
base, one or more tablespaces, or one or more datafiles, as shown in the
following syntax statements:
RECOVER DATABASE;
The RECOVER Command
RECOVER TABLESPACE tablespace_name [,...];
RECOVER DATAFILE 'path_and_file_name' [,...];

If you are performing a full database recovery, the database must be mounted but
not open. If you are performing a tablespace or datafile recovery, the database
may be open, but all datafiles related to the recovery must be taken offline before
starting the recovery. You can bring the datafiles offline right from the RMAN
prompt using the SQL command, and including the appropriate ALTER
DATABASE DATAFILE command within single quotes, as shown in this
example:
RMAN> SQL 'alter database datafile 12 offline';
sql statement: alter database datafile 12 offline

As the recovery process proceeds, RMAN will identify which archive logs need
to be restored and applied, and then apply them to roll the recovery target for-
ward to bring it up to date with the control file. After the recovery is complete,
the recovered datafiles will still be offline, but they can be brought back online by
specifying the SQL command with the appropriate ALTER DATABASE
DATAFILE or ALTER TABLESPACE command in single quotes. If you are
performing a full database recovery, you can simply open the database right from
the RMAN prompt by issuing the ALTER DATABASE OPEN command. In the
following example, datafile 12 is being brought online after it has been recovered:
RMAN> SQL 'alter database datafile 12 online';
sql statement: alter database datafile 12 online

An additional feature of the RECOVER command is the ability to delete archive
logs immediately after they have been restored and applied to the database. Each
archive log that needs to be applied is restored from backup, applied to the data-
base, and then immediately deleted before the next archive log is restored. This
feature is extremely handy if you have a limited amount of disk space to work
with during a recovery operation. The following command will instruct RMAN to
recover the entire database and delete all restored archive logs after they are
applied to the database:
RECOVER DATABASE DELETE ARCHIVELOG;
TASK 5A-2
Perform a Complete Recovery
Objective: To perform a complete recovery after restoring the database
from backup.
1. Launch SQL*Plus and log in as sys.
At the SQL*Plus prompt, type ALTER DATABASE OPEN; and press

Enter.

Oracle will return an error stating that the SYSTEM01.DBF datafile needs
media recovery.
2. In the previous task, you simulated the loss of all datafiles in the database,
then restored all the datafiles from the last backup. Since the backup copy
was valid and all archive logs since the backup was performed are available,
you will be able to perform a complete recovery. You will perform this
recovery using RMAN.
Exit from the SQL*Plus window.
mand:
as the RMAN repository.
3. When performing a database recovery with RMAN, the RMAN utility will
determine the type of recovery required, and will automatically extract any
necessary archive logs from the appropriate backup set, and apply their con-
tents to the database.
At the RMAN prompt, type recover database; and press Enter.
RMAN will allocate a channel, and then perform the recovery.
4. Once the recovery is complete, you must open the database to make it avail-
able for general use.

At the RMAN prompt, type ALTER DATABASE OPEN; and press Enter.
After a moment, RMAN will display the message “database opened.”
5. Exit from the RMAN utility and the command prompt.
Block Media Recovery

From time to time, datablocks within the datafiles may become corrupted for one
reason or another. If you are working with a user-managed backup and recovery
strategy, the only recovery option available would be to restore the entire datafile
from backup and perform a recovery. This can be very time-consuming if the file BMR:
requiring recovery was large, and may be difficult to justify for only a few (Block Media Recovery) A
datablocks of corruption. However, RMAN provides the ability to recover indi- feature that allows RMAN to
recover only corrupt blocks
vidual data blocks with its Block Media Recovery (BMR) feature. When in a datafile, rather than the
performing a user-managed recovery on a datafile, the tablespace to which that entire datafile.
datafile belongs will be unavailable until recovery is complete. With BMR, you
can recover individual data blocks while the affected tablespace remains online.
Block corruption errors are usually written to the alert log. You can also find
information about corrupted data blocks in the V$BACKUP_CORRUPTION,
V$COPY_CORRUPTION, and V$DATABASE_BLOCK_CORRUPTION views.
When a block corruption is found, you can execute the BLOCKRECOVER com-
mand from the RMAN prompt. The syntax of the BLOCKRECOVER command is
as follows:
BLOCKRECOVER DATAFILE d1 BLOCK b1[,b2...]
[DATAFILE d2 BLOCK b3[,b4...]]...
Block Media Recovery
You can specify as many datafiles and data blocks as necessary to repair the (BMR)
corruptions. To repair the corruption of block number 3833 in the D:\oracle\
oradata\ora92\users01.dbf datafile, you would issue the following command:
BLOCKRECOVER DATAFILE 'D:\oracle\oradata\ora92\users01.dbf
BLOCK 3833;
You can optionally specify the CORRUPTION LIST option with the
BLOCKRECOVER command. This option will instruct RMAN to perform block
media recovery on all datablocks that are listed as corrupt in the V$DATABASE_
BLOCK_CORRUPTION view. This can reduce the amount of text the DBA must
type at the RMAN prompt to perform the recovery. The following example
recovers all known corrupted datablocks in the database:
BLOCKRECOVER CORRUPTION LIST;

When the BLOCKRECOVER command is issued, RMAN will locate the last non-
incremental backups of the specified datafiles and rebuild only the specified
datablocks in the live datafiles based on the information found in the backups.
RMAN will then restore and apply all necessary archive logs to bring the affected
datablocks up to date with the rest of the database. The entire operation can be
performed with the database and the affected datafiles online. However, there are
some restrictions to block media recovery, which include:
• BMR can be performed only from RMAN.
• The corrupted blocks are not available until the block has been successfully
recovered.
• Only a complete recovery of a data block is allowed; incomplete recovery is
not available.
• BMR is available only from a full backup; it is not available from incremen-
tal backups.
By taking advantage of block media recovery, the DBA can address datablock
corruptions in the database and take steps to resolve the issue without taking a
single datafile offline.
TASK 5A-3
Describe Block Media Recovery
1. True or False? Block media recovery can be performed from both the
RMAN utility and the SQL*Plus prompt. Explain your answer.
False. Block media recovery is only available from within the RMAN utility.
2. Which data dictionary views could be queried to determine which

datablocks were found to be corrupted during a backup operation?
Choose all that apply.
✓ a. V$BACKUP_CORRUPTION
b. V$BLOCK_CORRUPTION
✓ c. V$COPY_CORRUPTION
d. V$CORRUPTION
3. You want to recover the corrupted datablock number 107734 in the

D:\oracle\oradata\ora92\oem01.dbf datafile. What would be the com-
mand to perform this operation?
BLOCKRECOVER DATAFILE
'D:\oracle\oradata\ora92\oem01.dbf'BLOCK 107734;
4. True or False? During BMR, if RMAN discovers that a copy of the

datablock in question resides in the last incremental hot backup, RMAN
will automatically recover the datablock using that backup copy.
False. BMR is available only from a full backup; it is not available from
incremental backups.

Topic 5B
RMAN Incomplete Recovery
Performing an incomplete database recovery with RMAN is very similar to per-
forming a user-managed incomplete recovery. Both methods require the following
steps:
2. Restore the appropriate backup files.
3. Recover the database, but stop the recovery before all changes are applied.
4. Open the database with the RESETLOGS option.
For user-managed recoveries, all of these steps must be handled manually, includ-
ing determining which backup files need to be restored, locating and restoring
those files, and applying the appropriate archive logs up to the point in time that
you want to stop the recovery. RMAN simplifies the process by providing the
ability to automatically determine which backup files are necessary for the opera-
tion, restoring them, and then restoring and applying all appropriate archive logs
to recover the database to the specified point in time.
To perform an incomplete recovery with RMAN, you would first determine the
point in time you wish to recover the database to. For user-managed incomplete
recovery, you can specify the point in time as a true date and time or as a spe-
cific SCN. You can recover to an arbitrary point in time by issuing the CANCEL
command while applying archive logs to simply stop the recovery at any point.
For RMAN incomplete recovery, you can still specify the recovery point in time
as a date and time or a specific SCN, however the CANCEL option is unavailable.
As an alternative, you can specify the actual log sequence number you want to
stop the recovery at. Once RMAN has recovered the database through all archive
log sequence numbers previous to the specified log sequence number, it will stop
the recovery. RMAN will not recover the changes stored in the specified archive
log sequence number, but all changes previous to it. The command in the follow-
ing example illustrates an incomplete recovery to a specified log sequence
number:
RECOVER DATABASE UNTIL LOG SEQUENCE 291 THREAD 1;
In this example, the database will be recovered up to, but not including, log
sequence 291. Specifying the log sequence number is only available for incom-
plete recoveries from within RMAN. Conversely, the CANCEL option is only
available for user-managed recoveries, and cannot be used from within RMAN.
In RMAN, there are two options available for specifying the point in time to
recover the database to. You can either include the UNTIL clause with the
RECOVER database command, or you can issue the stand-alone SET UNTIL
command. The SET UNTIL command uses similar syntax as the UNTIL clause,
but it is specified before the RESTORE and RECOVER commands are issued and
must be specified within the curly braces of a RUN block. This is usually more
convenient, because it allows RMAN to choose the correct backup set to restore
for the recovery operation. Consider this example:
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE UNTIL TIME '15-AUG-2003 10:15:00';

In this example, the RESTORE command causes RMAN to restore the last known
good backup of the database. The RECOVER command then tells RMAN to
recover the database to a specific point in time. However, it is possible that the
specified recover time is earlier than the last known good backup. If this is the
case, then RMAN will return an error when attempting to perform the recovery.
You can still use the UNTIL clause if you know the exact backup set you wish to
use for recovery. You would simply include either a backup set ID number or a
backup set tag with the RESTORE command. However, the SET UNTIL clause
allows RMAN to make this decision for you, which can simplify the restore and
recovery process. Consider this example, which makes use of the SET UNTIL
command:
RUN
{
The SET UNTIL Command
SET UNTIL TIME '15-AUG-2003 10:15:00';
RESTORE DATABASE;
RECOVER DATABASE;
}
In this example, the SET UNTIL command specifies the recovery point in time
before the RESTORE command is issued. This allows RMAN to select the most
appropriate backup to perform the recover. When the RECOVER command is
issued, Oracle can roll the database forward from the time the older backup was
taken to the specified recovery point in time without issue. Once the database is
recovered to the specified point in time, you would open the database with the
RESETLOGS option.
There is one other minor difference in syntax to specify the recovery point in
time within RMAN rather than for user-managed recovery. In user-managed
recovery, when specifying a specific SCN as the recovery point in time, you
would use the keyword CHANGE, as shown in the following example:
RECOVER DATABASE UNTIL CHANGE 39392;
In RMAN, you would use the keyword SCN instead of CHANGE, as shown in the
following two examples:
SET UNTIL SCN 39382;
RECOVER DATABASE UNTIL SCN 39382;

RMAN incomplete recovery can be used to restore and recover a database to a
specific point in time, which may be necessary after certain types of media fail-
ure, such as loss of the control file or the current redo log group.
Loss of Control File

As you learned earlier, if a database loses all copies of its control file, the data-
base will immediately crash. If you have a valid backup of the control file, the
database can be recovered fairly quickly. If the backup control file was created
manually, you would need to manually restore the file to its original location and
perform an incomplete recovery of the database. However, RMAN can simplify
the process by automating many of the steps that need to be performed for this
type of recovery.
When the RESTORE command is issued, RMAN will restore all necessary files
for a database, including datafiles and all copies of the control file, and will
restore these files from the most appropriate backup set for the specified recovery
operation. RMAN will also handle restoring and applying all necessary archive
logs to roll the database forward to the point of failure.
Since you would be recovering the database using backup control file, Oracle will
not know when to stop applying recovery since the control file’s SCN will not be
the most current one. For user-managed recovery, you can easily issue the
CANCEL command once Oracle requests an archive log that has not yet been
generated. However, the CANCEL command is not available within RMAN.
Instead, you can specify the last known log sequence number as the recovery
point in time. Since the target database is down, you will not be able to log in to
the database to determine the sequence number, but you can look in the target
database’s alert log for informational entries about the latest log switch that was
performed. The following example shows the alert log entry for the latest redo
log switch that occurred in the target database prior to the media failure:
Thu Aug 05 11:26:56 2003
Thread 1 advanced to log sequence 67
Current log# 3 seq# 67 mem# 0:
D:\ORACLE\ORADATA\ORA92\REDO03.LOG
Thu Aug 05 11:26:56 2003
ARC0: Evaluating archive log 2 thread 1 sequence 66
ARC0: Beginning to archive log 2 thread 1 sequence 66
Creating archive destination LOG_ARCHIVE_DEST_1:
'D:\ORACLE\ORADATA\ARCHIVE\LOG_00066.ARC'
ARC0: Completed archiving log 2 thread 1 sequence 66
In this example, the last archived log sequence was sequence 66. This means that
the log group that was the current group when the media failure occurred has a
sequence number of 67. For an incomplete recovery with RMAN, you could
specify the recovery point in time to the next higher sequence number, which is
68. RMAN will recover the database up to, but not including, the specified
sequence number. If the last redo log for the recovery has not yet been archived,
as in this case where log sequence number 67 is still the current group, RMAN
will automatically use the current redo log group to apply the latest changes to
the database after all archive logs have been applied. The following example
shows the set of commands that can be used to recover the database after loss of
the control file:
STARTUP NOMOUNT;
RESTORE CONTROLFILE;
RECOVER DATABASE UNTIL SEQUENCE 68 THREAD 1;
If the recovery catalog is used, and the catalog is stored in a database that is
independent from the target database, then restoring the control file and recover-
ing the target database is very simple and can use the commands shown. RMAN
will use the information in the recovery catalog to determine which backup con-
trol file to restore. However, if the target database’s control file is used as the
repository, then the recovery becomes slightly more difficult. The control file is
lost, which means RMAN has no repository for the target database. However, it
is still possible to use RMAN for the recovery.
If you have configured control file autobackups with the CONFIGURE command,
and have at least one control file autobackup that was created no more than the
number of days specified by CONTROL_FILE_RECORD_KEEP_TIME, then
you can restore the control file from its autobackup. Even without the repository,
you would just need to tell RMAN which database you are recovering, and
RMAN will scan the backup location specified by the channel configuration for
any control file autobackup copies for the specified database. To tell RMAN

which database you are recovering, you would specify the database ID number
(DBID) with the SET DBID command. You can determine the DBID for the tar-
get database by looking at the file name of a control file autobackup for the target
database. Consider the following example set of commands:
SET DBID 1808973453
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
In this example, the first command tells RMAN the DBID of the database you
are trying to recover. This allows RMAN to search for the correct control file in
the backup location to restore. The database is then started in the nomount state.
The RESTORE command tells RMAN to restore the last known good control file
autobackup for the specified DBID. RMAN will scan the backup location for a
control file autobackup that contains the specified DBID, going back the number
of days specified by the CONTROL_FILE_RECORD_KEEP_TIME parameter,
and restore a copy to all locations specified by the target database’s CONTROL_
FILES parameter. The database is then mounted and recovered up to, but not
including, log sequence 68. Once the recovery is complete, the database is
opened with the RESETLOGS option. If no valid control file autobackup is found
that was created within the number of days specified by CONTROL_FILE_
RECORD_KEEP_TIME, then RMAN will not restore any files and will return an
error.
TASK 5B-1
Describe Recovery with RMAN After Loss of Control
File
1. Which one of the following statements is true?
a. Cancel-based recovery is unavailable for user-managed recovery,
and change-based recovery is unavailable for RMAN recovery.
✓ b. Sequence-based recovery is unavailable for user-managed recovery,
and cancel-based recovery is unavailable for RMAN recovery.
c. Cancel-based recovery is unavailable for user-managed recovery,
and sequence-based recovery is unavailable for RMAN recovery.
d. Change-based recovery is unavailable for user-managed recovery,
and time-based recovery is unavailable for RMAN recovery.

2. You are performing a restore and recovery of a database that has lost
all copies of the current control file. You are using RMAN without a
recovery catalog. What command would you issue to tell RMAN which
target database is being restored?
a. SET DATABASE
✓ b. SET DBID
c. REGISTER DATABASE
d. RESET DATABASE
3. If the target database is down, how could you determine the correct
value to specify for the SET DBID command?
a. By looking at the name of the backup sets generated by RMAN.
✓ b. By looking at the name of the control file autobackup.
c. By looking at the name of the spfile autobackup.
d. By opening the backup control file in a text editor.
Loss of the Current Redo Log Group

As you learned earlier, losing the current redo log due to media failure will
immediately cause the database to crash and you are guaranteed to lose any
changes to the data that were stored in the current log group. However, you can
use RMAN to easily recover the database after this type of failure to get it up
and running again. Using RMAN to recover the database after a loss of the cur-
rent redo log is almost identical to a user-managed recovery in the same scenario.
If you have been using the target database’s control file as the RMAN repository,
and if the control file is still intact after the media failure, you can still use it as
the repository for this recovery. Loss of the current redo log group requires the
following steps to recover the database:
2. Recover the database up to but not including the lost redo log.
3. Open the database with the RESETLOGS option.
You must restore all datafiles from backup, because you cannot roll the database
back in time; you can only roll it forward from the last known good backup.
When rolling the database forward during recovery, RMAN will automatically
restore and apply all required archive logs to perform the recovery, but will not
try to apply the current redo log group. Upon opening the database, RMAN will
automatically re-create any redo log file members that are missing due to the
media failure. The following set of commands can be used to perform the data-
base recovery in this scenario:
STARTUP MOUNT;
RESTORE DATABASE;

In this example, RMAN will first restore all datafiles from the last known good
backup. The RECOVER command specifies the log sequence number at which to
stop the recovery. In this case, the current redo log group had a log sequence
number of 67, which can be determined by looking in the alert log for the last
log switch. By specifying this log sequence number with the RECOVER com-
mand, you instruct RMAN to recover the database up to, but not including, this
sequence number. Once the recovery is complete, RMAN will open the database
with the RESETLOGS option and re-create any redo log file members that were
lost. You must remember that any changes that were stored in the current redo
log group will be lost.
You could optionally use the SET UNTIL clause prior to restoring the datafiles
to allow RMAN to search for and restore the most appropriate backup of the
datafiles if the latest backup was created after the point in time you wish to
recover to. The following example shows a RUN block that could perform this
operation:
RUN
{
STARTUP MOUNT;
SET UNTIL SEQUENCE 67 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
In this example, the database is mounted and the recovery point in time is set by
the sequence number of the current redo log group. The RESTORE command
tells RMAN to restore the most appropriate datafiles to perform the point-in-time
recovery, and the RECOVER command instructs RMAN to restore and apply all
necessary archive logs with the exception of the current redo log group. The data-
base is then opened with the RESETLOGS option. Any missing redo log files are
automatically re-created and any changes that were in the current redo log group
at the time of the failure will be lost.
TASK 5B-2
Using RMAN to Recover After Loss of the Current Redo
Log
Objective: To perform an incomplete recovery using RMAN from the
loss of the current online redo log group
1. You will first simulate the loss of the current online redo log.
To force a log switch, type ALTER SYSTEM SWITCH LOGFILE; and

press Enter.

2. To determine which redo log group is the current group, type @C:\079176\
logfiles.sql and press Enter.
The STATUS column in the output will show which log group is the current
group, and the SEQ# column will show the log sequence number of each
group. In the example shown here, the current log group is log group 3, with
a log sequence number of 7.
3. You will now create a small table.

CREATE TABLE test_rman_redo (col1 VARCHAR2(5));
Insert a row into the table with the following statements:

INSERT INTO test_rman_redo VALUES('A');
COMMIT;
The redo information generated from the CREATE TABLE and INSERT

statements was first stored in redo log buffer, and then written to the current
redo log group.
4. You will now force a log switch. The current online redo log will be
archived, and Oracle will switch to the next log group.

It is normal for the redo log Enter.
groups to sometimes switch
out of sequence from their Oracle will display the message “System altered.”
log group numbers.
To see which log group is now current, type @C:\079176\logfiles.sql and
press Enter.
The output will show that Oracle has switched to the next redo log group.
The redo log that contains the CREATE TABLE and INSERT statements has
been archived. In this example, log group 1 is now the current log group,
which also has a log sequence number of 8. Log group 3 has been archived.
5. You will now insert another row into the table.
At the prompt, issue the following statements:

INSERT INTO test_rman_redo VALUES('B');
COMMIT;
6. At the prompt, type @C:\079176\logfiles.sql and press Enter.
The redo information for the CREATE TABLE and the first INSERT state-
ments is stored in log group 3, which has been archived. The redo
information for the last row inserted was stored in the current online log
group, which is now log group 1. Losing the current online log group will
mean that all changes stored in that log group are permanently lost. How-

ever, all changes in the previous group can be recovered from the archive
log. Make a note of which log group is the current group, along with its
log sequence number from the SEQ# column. In this example, the log
sequence number for the current online redo log group is 8.
7. You will now simulate the loss of the current online redo log group.
At the prompt, type shutdown abort and press Enter.
Oracle will display the message “ORACLE instance shut down.”
8. Leaving SQL*Plus open, open a window to the D:\oracle\oradata\ora92

folder.
In the ora92 folder, delete the redo log file that corresponds with the cur-
rent online redo log group for your database. In the example here, the file
would be REDO01.LOG. Be careful to delete the correct file, and only
that file.
Close the ora92 window.
9. At the SQL*Plus prompt, type startup and press Enter.
The output will show that the instance was started and the database
mounted, but the database could not be opened because Oracle could not
find the current online redo log group.
10. To recover from this type of loss, you must restore all datafiles from backup
and perform an incomplete recovery up to the last archive log that was
generated. All changes stored in the current log group will be lost. You will
restore and recover the database using RMAN.
Leaving the SQL*Plus window open, open a command prompt and


for the RMAN repository.
11. To perform a full restore of the database, type restore database; and press
Enter.
RMAN will allocate a channel and begin the restore process. All backup
copies of the datafiles will be extracted from the backup set and restored to
their original locations, overwriting the existing datafiles. It will take a few
minutes for the restore to complete.
12. You will now use RMAN to perform an incomplete recovery of the
database. Since the failure occurred due to loss of the current online redo
log, the most efficient method of recovery is to specify the log sequence
number of the current online log group as the stopping point during recovery
using the UNTIL SEQUENCE option of the RECOVER command.
To recover the database until the current log sequence number, issue the
following command. For the x, specify the log sequence number of the
current online redo log group for your database, which you determined
in step 6. In this example, the log sequence number for the current redo log
group is 8.
recover database until sequence x thread 1;
RMAN will determine the archive logs and their locations that are needed to
perform the specified recovery. RMAN will then extract any archive logs
from the latest backup set, if necessary, then apply the contents of the logs
to roll the database forward. All logs that are available are applied to the
database, with the exception of the log that normally would have been gen-
erated when the current online log group was archived.
Once the database has been recovered to the specified log sequence number,

RMAN will display the message “media recovery complete.”
13. The database has been recovered to include all available changes. The cur-
rent online redo log group is no longer available, therefore its changes will
be lost.
At the RMAN prompt, type alter database open resetlogs; and press Enter.
After a few moments, RMAN will display the message “database opened.”
Exit from both the RMAN utility and the command prompt.
14. When you opened the database with the RESETLOGS option, you created a
new incarnation of the database, and all backups of the previous incarnation
of the database are now useless for recovery. You should immediately per-
form another full, cold backup of the database in case there is some sort of
failure in the near future.
At the RMAN prompt, type shutdown immediate; and press Enter.
At the prompt, type startup mount; and press Enter.
After a moment, RMAN will report that the instance has started and the
database was mounted.
To back up the database, type backup database; and press Enter.
A full, cold backup of the database will begin. It will take several minutes
for the backup to complete.
15. Once the cold backup is complete, you will also create an image copy of the
control file. This will allow you to recover the database if the recovery cata-
log is not available.
At the RMAN prompt, issue the following command:

copy current controlfile to 'D:\oracle\rman_bup\control.bak';

RMAN will create an image copy of the control file in the D:\oracle\rman_
bup folder.
Type alter database open; and press Enter.
After a moment, RMAN will display the message “database opened.”
Exit from both the RMAN utility and the command prompt window.
16. At the SQL*Plus prompt, type Connect sys@ora92 as sysdba and press
Enter. Type ora92 for the password and press Enter.
17. To see which changes were recovered and which were lost, you will now
query from the TEST_RMAN_REDO table.
At the SQL*Plus prompt, type SELECT * FROM test_rman_redo; and

press Enter.
The output will show that only the first row, containing the value A, was
recovered. The second row, containing the value B, which was only stored in
the current online redo log group, was lost.
18. You have successfully performed an incomplete recovery of the database

using RMAN with the UNTIL SEQUENCE option.
After performing an incomplete recovery and opening the database using the
RESETLOGS option, all information about tempfiles belonging to any tem-
porary tablespaces are lost. You will add the tempfile back to your temporary
tablespace.

ALTER TABLESPACE temp ADD TEMPFILE
'D:\oracle\oradata\ora92\temp01.dbf' REUSE;
Tablespace Point-in-Time Recovery

One of the most involved recovery scenarios is performing a tablespace point-in-
time recovery. This type of recovery is performed to recover a single tablespace
to a different point in time than the rest of the database, and cannot be done with
a single database. You would need to create a clone of the original database,
recover the clone database to the specific point in time, then move the newly

recovered data back to the original database. Performing this recovery manually
requires quite a bit of preparation and configuration ahead of time and involves
many hands-on steps to complete. RMAN greatly simplifies a tablespace point-in-
time recovery by automating a majority of the most tedious and error prone steps
of the process.
To perform a tablespace point-in-time recovery, RMAN takes the following
actions:
• Creates a clone of the target database using a minimal set of files.
• Recovers the clone database to the specified point in time.
• Opens the clone database with the RESETLOGS option.
• Performs a transportable tablespace export of the tablespace that is being
recovered from the clone database.
• Shuts down the clone database.
• Renames the original datafiles in the target database to point to the newly-
recovered clone datafiles.
• Imports the transportable tablespace back into the target database.
The clone database is created by restoring the necessary files from a hot backup
of the original database. When creating the clone, RMAN only restores the abso-
lute minimum files necessary to get the clone up and running with only the
tablespace to be recovered. This minimizes the number of files that need to be
restored and can greatly reduce the amount of time and space needed for the
recovery, especially if the target database has many large tablespaces. For the
purposes of the recovery process, the files to be restored are grouped into the fol-
lowing file sets:
• Auxiliary set—Consists of the minimum set of files to make the clone data-
base a fully operational database, which includes the control file and the
datafiles of the SYSTEM and UNDO tablespaces.
• Recovery set—Consists of all datafiles for the tablespace that is to be
recovered.
Once restored, RMAN performs a recovery of the clone database to the specified
point in time using the appropriate archive logs, and then it opens the database
with the RESETLOGS option. RMAN then uses the transportable tablespace fea-
ture of Oracle’s export and import utilities to move the tablespace back to the
target database. You will learn more about transportable tablespaces in detail in
the next lesson. For now, this lesson will focus on the overall steps required to
perform the tablespace point-in-time recovery.
While RMAN performs most of the steps required to perform a tablespace point-
in-time recovery, there are some minor preparations that need to be done
manually before invoking RMAN. These steps include:
• Create a new directory to store the files of the auxiliary and recovery sets.
• Make a copy of the parameter file from the original database to be used to
start the clone database.
• Set up the operating system environment to support the clone database.
• Configure the Oracle Net environment to accept connection requests for the
clone.

After making a copy of the target database’s parameter file, and renaming it
appropriately, there are several parameter additions and changes that need to be
made. The new parameter settings for the clone database allow the clone to reside
on the same system as the target database without conflict. The modified clone
parameter file should contain the parameters shown in the following table.
Parameter Description
lock_name_space Set to the new name of the clone database.
db_file_name_convert Specifies the directory path where the auxiliary file set will be
restored to.
log_file_name_convert Specifies the directory path where the redo logs will be re-
created when the clone is opened with the RESETLOGS
option.
control_files Specifies the directory path and file names where the control
files will be restored to.
log_archive_start Must be set to FALSE, since the clone must be running in
NOARCHIVELOG mode.
The LOCK_NAME_SPACE parameter provides a new name for the clone

instance to allow it to start up along side the target instance. The value you
specify for the LOCK_NAME_SPACE parameter should be different than the
INSTANCE_NAME parameter in the target database. It’s important to note that
while the LOCK_NAME_SPACE parameter in the clone should be different than
the INSTANCE_NAME parameter in the target, the DB_NAME parameter on
both databases must be identical.
The DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT param-
eters should include the original directory path where the files reside for the
target database along with the new directory path where they will reside for the
clone database. You can list any number of directory path conversions as neces-
sary for each parameter. For example, if your target database has datafiles of the
SYSTEM and UNDO tablespaces and the log file members of the redo logs
spread out across five directories, you would list each original directory along
with a conversion directory so RMAN will know where to restore datafiles and to
re-create the redo log files for the clone database to use. The following example
shows these two parameters with appropriate settings:
db_file_name_convert =
('D:\oracle\oradata\ora92\','D:\oracle\oradata\clonedb\')
log_file_name_convert =
('D:\oracle\oradata\ora92\','D:\oracle\oradata\clonedb\')
Its very important to note that the DB_FILE_NAME_CONVERT parameter only
specifies the new directory path where the datafiles of the auxiliary set will be
restored to, namely the SYSTEM and UNDO tablespace datafiles. For the recov-
ery set, RMAN will attempt to restore the datafiles to their original locations.
Therefore, you must first issue the SET NEWNAME command during the RMAN
session to restore the files of the recovery to the new clone location. You must
not however, issue the SWITCH command. Doing so will instruct RMAN to
change the target database’s internal pointer for the original datafiles.
The CONTROL_FILES parameter for the clone database should be changed so
that RMAN will not overwrite the target database’s control files when restoring
the backup control file for the clone. This parameter should be set with full direc-
tory path and file names for each control file you want to use for the clone.

The clone database must be running in NOARCHIVELOG mode. RMAN will
handle setting the clone to NOARCHIVELOG mode before opening it, but the
LOG_ARCHIVE_START parameter must set to FALSE before beginning the
recovery process.
In addition to the parameters listed here, you may want to consider changing
some other parameter values for resource usage and performance reasons. Since
the parameter file for the clone database is a copy of the parameter file for the
original database, memory allocation parameters such as SHARED_POOL_SIZE
and DB_CACHE_SIZE will be the same for both the clone and the target. Since
you are not expecting any sort of user load on the clone database, you can shrink
the values for these parameters to the absolute minimum requirements necessary
to start the instance. This can greatly reduce the memory consumption required to
have both databases up and running on the same server and will hopefully avoid
any negative performance impacts if the target database is still in use.
The steps needed to configure the operating system to support the clone database
depends on the platform the database is running. If you are running on a Win-
dows system, for example, you would need to ensure that the appropriate
Windows service is created for the new instance. For Unix systems, you would
need to set the appropriate environment variables, such as $ORACLE_HOME
and $ORACLE_SID.
To configure the Oracle Net environment to accept connection requests for the
clone database, you would need to add connect descriptors to your names resolu-
tion method. For example, if you are using local naming, you would need to add
an entry to the tnsnames.ora file on the server. You will also need to make an
entry in the listener.ora file and reload this listener to ensure that the listener can
properly route connection requests from RMAN to the clone.
Once the environment is configured to support the clone database, you can invoke
RMAN and connect to all databases involved in the recovery, which include the
recovery catalog, the target database, and the clone database. To connect to the
recovery catalog and target database, you would use the standard syntax you have
used throughout this course. Once RMAN is invoked and connected to both the
recovery catalog and target database, you would issue another command to con-
nect to the clone database. The following is an example of the commands to use
to connect to all three databases:
C:\>rman target rman/buprec@ora92 target rman/buprec@ora92
Recovery Manager: Release 9.2.0.1.0 - Production

reserved.
connected to target database: ORA92 (DBID=1808973453)
RMAN>connect clone rman/buprec@clonedb

Once connected to all three databases, you must first allocate a special clone
channel that is used to restore the datafiles for the clone database, as shown in
this example:
ALLOCATE CLONE CHANNEL C1 TYPE DISK;

In this example, the clone channel was allocated to restore all files from a disk
location. Even if the datafiles of the recovery and auxiliary sets will be restored
from tape, RMAN will replicate the current control file from the original database
to create the control file for the auxiliary database. Since this control file resides
on disk, at least one channel of type DISK must be allocated, even if you must
allocate another channel to restore the datafiles from type. If this is the case, your
channel allocations may look like this:
ALLOCATE CLONE CHANNEL C2 TYPE 'SBT_TAPE'
Once the channel is allocated, you only need to provide RMAN with the paths
and file names where you want the datafiles of the recovery set to be restored to.
This is done with the SET NEWNAME command, as shown in the following
example:
SET NEWNAME FOR DATAFILE 5 to
'D:\oracle\oradata\clonedb\example01.dbf';
After specifying the new paths and file names, you do not need to issue the
RESTORE command. You would simply issue the RECOVER TABLESPACE
command, which instructs RMAN to first restore all files of the auxiliary set and
all datafiles for the specified tablespace. The auxiliary set will be restored to the
directory specified by the DB_FILE_NAME_CONVERT and CONTROL_FILES
parameters on the clone database. The RECOVER command also includes the
point in time that you want to restore the clone database to. The following
example shows a complete set of commands to perform the recovery of the clone
database:
RUN
{
RMAN Tablespace Point-in-
Time Recovery SET NEWNAME FOR DATAFILE 5 to
'D:\oracle\oradata\clonedb\example01.dbf';
RECOVER TABLESPACE example UNTIL SEQUENCE 68 THREAD 1;
}
In this example, the clone channel is allocated and the new path and file name for
lone datafile in the EXAMPLE tablespace is specified. The RECOVER command
instructs RMAN to recover the EXAMPLE tablespace up to but not including log
sequence 68. Once this RUN block is executed, RMAN will perform the follow-
ing steps:
1. Allocate the clone channel.
2. Restore the control files to the clone location.
3. Restore the datafiles of the SYSTEM and UNDO tablespaces to the clone
location.
4. Restore the datafiles of the tablespace to be recovered to the clone location.
5. Mount the clone database.
6. Recover the clone database to the point in time specified.
7. Open the clone database with the RESETLOGS option.
8. Create a transportable tablespace export of the tablespace to be recovered.
9. Shut down the clone database.
10. Rename the datafiles of the EXAMPLE tablespace in the target database to
point to the newly-recovered clone EXAMPLE datafiles.
11. Import the transportable tablespace into the target database.

Once the datafiles are imported into the target database, the tablespace is consid-
ered to be recovered. However, the datafiles of the recovered tablespace will still
reside in the location where they were restored to, most likely in the clone
directory. After the recovery operation, RMAN will leave the recovered
tablespace offline in the target database to allow you to copy the datafiles back to
their original locations and rename them within Oracle before bringing them
online. This will help avoid confusion by having live datafiles stored in a strange
location.
TASK 5B-3
Describe Tablespace Point-in-Time Recovery Using
RMAN
1. What is the difference between the recovery set and the auxiliary set?
The recovery set contains all the datafiles of the associated tablespace that
is to be recovered. The auxiliary set contains the minimum number of
datafiles from the primary database to be restored for the clone database to
make the clone fully operational, which includes the control file, the system
tablespace datafiles, and the undo segment tablespace datafiles. The auxil-
iary set does not include any of the datafiles of the associated tablespace to
be recovered.
2. True or False? The DB_FILE_NAME_CONVERT parameter specifies

the new names and locations to where RMAN will restore the files
included in the recovery and auxiliary sets. Explain your answer.
False. The DB_FILE_NAME_CONVERT parameter specifies the new name
and location to where RMAN will restore the files included in the auxiliary
set only. To specify the new names and locations for the files included in the
recovery set, you would include the SET NEWNAME FOR DATAFILE com-
mand in your RMAN script just prior to beginning the recovery process.
3. All of your backup copies are stored on tape. However, when perform-
ing tablespace point-in-time recovery with RMAN, you must still
allocate at least one channel of type DISK. Why?
The datafiles of the recovery and auxiliary sets will be restored from tape,
but RMAN will replicate the current control file from the original database
to create the control file for the auxiliary database. Since this file resides on
disk, a channel of type DISK must be allocated.

4. Once the clone database has been restored and recovered, what type of
export will RMAN perform to copy the recovered tablespace back to the
original database?
a. Conventional path, full database export
b. Direct path, full database export
c. Direct path, tablespace-level export
✓ d. Transportable tablespaces
5. Once the RMAN tablespace point-in-time recovery is complete, in what

state will RMAN leave the recovered tablespace in the original data-
base?
a. ONLINE
b. RECOVER
✓ c. OFFLINE
d. READ ONLY
Summary
In this lesson, you learned how to perform both complete and incomplete
recoveries with RMAN. You learned how to restore lost files, including
datafiles, control files, archive logs, and the spfile. You also learned how to
recover the database to the point of failure and to alternative points in time
using the RMAN utility. Finally, you learned how to use RMAN to perform
a tablespace point-in-time recovery by creating a clone database, recovering
that clone to a specific point in time, and transferring the recovered
tablespace back to the original database.
Lesson Review
5A Which RMAN command is equivalent to the ALTER DATABASE
RENAME FILE command?
a. CREATE DATAFILE...AS
b. RESET DATAFILE
c. SET NEWNAME
✓ d. SWITCH
What command would you use to perform a recovery of the USERS

tablespace and delete each restored archive log after it is applied?
RECOVER TABLESPACE users DELETE ARCHIVELOG;

Which clause of the BLOCKRECOVER command can be specified to
recover all datablocks shown in the V$DATABASE_BLOCK_
CORRUPTION view?
a. ALL
b. ALL KNOWN CORRUPTIONS
c. COMPLETE
✓ d. CORRUPTION_LIST
5B Why is it usually better to issue the SET UNTIL command rather than
include the UNTIL command during an RMAN incomplete recovery?
If the UNTIL command is used, RMAN will try to restore the last known
good backup of the recovery target, which may have been created after the
point in time specified by the UNTIL clause. If you issue the SET UNTIL
command before the RESTORE command, RMAN will automatically choose
the most appropriate backup of the recovery target and avoid potential
errors during recovery.
Your database has suffered a loss of all copies of the current control file.
By looking in the alert log for the last redo log switch, you have deter-
mined that the current log sequence number for the database was 32.
When using RMAN to perform an incomplete recovery, what log
sequence number should you specify for the UNTIL clause?
a. 31
✓ b. 32
c. 33
d. None, RMAN will automatically determine when to stop the recov-
ery
Your database has suffered a loss of the current redo log group. By look-
ing in the alert log for the last redo log switch, you have determined
that the current log sequence number for the database was 32. When
using RMAN to perform an incomplete recovery, what log sequence
number should you specify for the UNTIL clause?
✓ a. 31
b. 32
c. 33
d. None, RMAN will automatically determine when to stop the recov-
ery

Which files make up the auxiliary set for an RMAN tablespace point-in-
time recovery? Choose all that apply.
a. Archive logs to perform the recovery.
✓ b. Control file.
✓ c. Datafiles of the SYSTEM tablespace.
d. Datafiles of the tablespace to be recovered.
✓ e. Datafiles of the UNDO tablespace.

Loading and Moving Data LESSON
Overview
6
Data Files
Oracle provides several utilities to load and unload data in and out of the inventory.dat
database. For example, the SQL*Loader utility is used to bulk load data listplan.sql
from flat ASCII files into the database. The export utility is used to export item_ext.sql
data from the database into a file in binary format, which can then be
final_setup.pif
imported back into the same database or another database. In this lesson,
you will learn how to use these utilities to load, unload, and move data in Lesson Time
large volumes. 4 hours
Objectives
To move data around quickly and easily using Oracle-provided utilities, you will:
6A Quickly bulk-load data into the database.

Occasionally, you may find the need to bulk load data into the database.
With Oracle9i, there are multiple methods available, such as the
SQL*Loader utility and external tables, to do just that. You will learn
how to use SQL*Loader to quickly load simple files containing data in
ASCII format into the database. You will also learn how to create exter-
nal tables to access data in files outside of the database through table-like
structures from within the database.
6B Import and export data in and out of the database.

The export and import utilities provide the capability to export data from
the database to a file in binary format, and import it back to the same
database or to another database. They also provide the ability to move
entire tablespaces between databases by transporting only the tablespace
metadata from the data dictionary. You will learn how these utilities
work, and you will perform multiple types of exports and imports.
Lesson 6: Loading and Moving Data 317

Topic 6A
Load Data into the Database
The SQL*Loader utility is a command line utility that allows you to bulk load
data stored in simple text files into the database. As simple as the utility is, it
comes with powerful data parsing capabilities that enable the utility to read from
flat files regardless of the format of the data. The utility allows you to load from
multiple datafiles simultaneously or load into multiple tables simultaneously. You
can load data based on a set of conditions similar to a WHERE clause of a
SELECT statement, and you can manipulate the data as it loads using Oracle’s
built-in SQL functions.
SQL*Loader also comes with comprehensive error reporting capabilities. Any
The SQL*Loader Utility records that do not meet the certain conditions you specify, or records that violate
constraints, can be extracted to separate files to be dealt with individually. You
can configure the utility to cease loading if a specified number of errors are
encountered, and you can continue a load that had not completed due to a system
or utility failure. Figure 6-1 illustrates how SQL*Loader loads data into the
database.
Figure 6-1: The SQL*Loader utility.

As shown in Figure 6-1, SQL*Loader will read the data from the datafiles. The
control file shown here is different from the database’s control file. The
SQL*Loader control file is more or less a configuration file that is created by
hand and contains a list of parameters that tell SQL*Loader how to load the data.
The control file lists the names and locations of the datafiles that contain the data,
the columns of the target table, any SQL functions to use while loading, and any
other SQL*Loader options you would like to use for the load. You can optionally
specify the name and location of a log file, which records all screen output during

the loading. You can also specify names and locations of bad and discard files
where the utility will place data that cannot or will not be loaded. The bad file
will contain any data that could not be loaded due to some type of error. These
errors could be mismatched datatype, a value that is too large for the target col-
umn, or any other Oracle-related error. If no errors are encountered, the file is not
created. The discard file will contain any rows of data that do not meet the condi-
tions specified in the control file. This allows conditional loading of data, but
extracts the rows that do not meet the specified criteria.
Types of Loads
SQL*Loader supports two methods of loading data: conventional path and direct
path. In conventional path loading, SQL*Loader reads the data from the flat file
and generates standard INSERT statements to pass to the database. This method
of loading provides maximum flexibility because Oracle functions, such as conventional path load:
UPPER or TO_CHAR, can be applied to the data prior to inserting it into a table. A method of loading data
In direct path loading, SQL*Loader reads the data from the flat file, but bypasses into Oracle using standard
SQL calls.
the SQL processing engine of the database and stores the data directly in the tar-
get table. Because the SQL processing engine has been bypassed, Oracle
functions cannot be used against the data while it is loading, but the speed and
performance of direct path loads is often far superior than conventional path direct path load:
loads. The decision to use one over the other will depend on the requirements of A method of loading data
the data to be loaded. You will learn how to use both loading methods later in into Oracle that writes
this topic. directly to the datablocks in
the datafiles, bypassing the
The SQL*Loader Control File SQL processing engine.
The SQL*Loader control file is a simple text file that can easily be created by
hand. The control file contains the names and locations of the datafiles where the
data is stored and the format the data is stored in within the datafiles. It also
specifies the name of target table and the columns where the data will be loaded
to. Any Oracle functions to apply on the data while loaded would be listed for
each column. The control file also contains any options that are to be used during
loading. Additionally, the control file could also contain the actual data that is to
be loaded. The data must be listed at the end of the file after all other control file
contents. This allows simple maintenance and ease of management when dealing
with multiple datafiles.
Since SQL*Loader is such a powerful utility, the control file syntax allows a long
list of available commands and options. Shown here is the basic syntax for a Refer to the Oracle9i Utilities
SQL*Loader control file. manual for a complete list of
SQL*Loader control file
[RECOVERABLE | UNRECOVERABLE] options and keywords.
[CONTINUE] LOAD DATA
INFILE file_name[,...]
BADFILE file_name
DISCARDFILE file_name
FIELDS
TERMINATED BY [WHITESPACE | 'string']
ENCLOSED BY 'string'
OPTIONALLY ENCLOSED BY ' string'
TRAILING NULLCOLS
[INSERT | APPEND | REPLACE | TRUNCATE]
INTO TABLE table_name
WHEN (conditions)
(column_list)
[BEGIN DATA]

In this syntax, the [RECOVERABLE | UNRECOVERABLE] option specifies
whether or not the SQL*Loader run will generate redo information into the redo
logs. Disabling redo log information will greatly speed up the loading process,
but since no redo information was recorded, the load will not be recoverable in
the case of instance or media failure. If this clause is omitted, the current load
will default to RECOVERABLE.
The [CONTINUE] LOAD DATA keywords starts the main control file command.
The optional keyword CONTINUE can be specified to continue a load that had
not completed due to some failure, such as instance or media failure. The
INFILE clause lists the names and locations of the source datafiles. SQL*Loader
will load from the datafiles listed in the INFILE clause in the sequential order.
The BADFILE clause specifies the name and location of the bad file to be gener-
ated, if necessary. All rows of data that cause an error during the load will be
copied from the datafile into the bad file. As SQL*Loader is running, it will dis-
play on the screen, and record in the log file if specified, any errors that occur
during the load. After examining the errors, you can edit the bad file to modify
the data and rerun SQL*Loader to load these rows. If no errors are encountered
during a load, no bad file is generated. If the BADFILE clause is omitted, no bad
file will be generated even if there are errors.
There are two types of text files that can be read by SQL*Loader, fixed-width
and delimited. In a fixed-width datafile, all columns of data are separated evenly
in a fixed-width. In a delimited datafile, all fields are separated by some specific
character that is not read as data. The FIELDS clause specifies how the columns
of data are separated in a delimited text file. You will learn more about datafile
formats later in this lesson.
The TRAILING NULLCOLS options tell SQL*Loader how to handle any table
columns that do not have corresponding data in the datafile. For example, let’s
say the target table contains 12 columns, but your text file contains eight columns
of data. By including the TRAILING NULLCOLS clause, you instruct
SQL*Loader to load the eight columns of data into the first eight columns of the
table, and leave the last four columns of the table null. This clause is only valid
if the target columns that are to remain null do not have NOT NULL constraints
defined on them.
The [INSERT | APPEND | REPLACE | TRUNCATE] clause specifies how
to handle the target table during the load. The INSERT option can only be used
to load data into an empty table, and the APPEND option will add the data to the
table without disturbing any existing data. The REPLACE option will execute an
unconditional DELETE command on the table, while the TRUNCATE command
truncates the table prior to loading. While both the REPLACE and TRUNCATE
options will completely remove all data from the table, the TRUNCATE option is
generally much faster than REPLACE. The INTO TABLE clause lists the target
table the data will be loaded into.
The conditions to load data are specified in the WHEN clause. The WHEN clause
contains relational comparisons similar to those used in the WHERE clause of
SQL statements. All data that meets the criteria specified in the WHEN clause is
loaded, while any data not meeting the criteria is discarded. If a discard file is
specified with the DISCARDFILE clause, all discarded rows are copied into the
discard file.
The columns_list clause lists the columns of the table where the rows are to
be loaded. You can optionally apply Oracle functions to each of the columns
listed in the column list. The data in the datafile will be loaded into the columns
based on sequential order. For example, the first column of data will be loaded

into the first column in the column list, the second column of data into the sec-
ond column listed, and so on. All columns in the datafile must be tied to a
specific table column. Table columns cannot be skipped in the control file, but
you can leave off any columns at the end of the table that will not receive data.
For example, if the datafile has 10 columns of data, you must list the first 10 col-
umns of the table. The last two columns can be omitted only if you include the
TRAILING NULLCOLS clause.
The BEGIN DATA clause tells SQL*Loader that all contents in the file after that
point is data, and is intended to be loaded into the target table. This clause can be
optionally used if you decide to load the data from the control file itself, and can
be very useful if only a relatively small number of rows is to be loaded. If the
BEGIN DATA clause is included, you must list the INFILE clause as
INFILE *.
The following shows an example of the contents of a SQL*Loader control file.
UNRECOVERABLE
LOAD DATA
INFILE 'd:\sqlldr\employee.txt'
BADFILE 'd:\sqlldr\bad\employee.bad'
TRUNCATE
INTO TABLE employee
FIELDS
TERMINATED BY ","
OPTIONALLY ENCLOSED BY '|'
TRAILING NULLCOLS
(
emp_id,
last_name,
first_name,
ssn,
dept_no
)
As shown in this example, the data in the EMPLOYEE.TXT file will be loaded
into the EMPLOYEE table and will not produce redo log information. If any
rows cause errors during loading, they will be copied to the EMPLOYEE.BAD
file that will be created in the d:\sqlldr\bad directory. Prior to loading the data, the
EMPLOYEE table will be truncated. The fields in the EMPLOYEE.TXT file are
separated by commas and might also be enclosed by a single pipe (|). Any col-
umns at the end of the table that are not going to be loaded with data will remain
null.
Datafile Formats
SQL*Loader can read two different types of datafile formats, fixed-width and
delimited. In a fixed-width datafile, the columns of all rows in the file are set at a
fixed-width, much like a spreadsheet. To load the data, you would include in the
control file the starting position and ending position of each column in the
datafile. Figure 6-2 shows a sample datafile in a fixed-width format.

Figure 6-2: A fixed-width format datafile.
In a delimited datafile, each field is separated by some identifying character,
called a delimiter. As SQL*Loader reads the file, it will know where each column
stops and another starts when it encounters the delimiter. The most common
delimiters used are the comma and the pipe (|). When creating datafiles to be
loaded with SQL*Loader, it is recommended that you choose a character that can
easily be differentiated from actual data. For example, if the data you are loading
contains names and address, you should not use a comma-delimited file because
there is a good chance the data itself may include commas.
Although a fixed-width datafile looks much cleaner, it is actually easier to create
a control file for a delimited file; you only need to specify the character used as
the delimiter. When loading data from a fixed-width datafile, you omit the
FIELDS clause, and specify start and stop positions for each column instead.
Although this sounds simple, your start and stop positions must be exact or the
load will fail. If the datafile is extremely large, such as 500 MB or more, you
may not have enough physical memory to open the file and look at the data to
confirm column positions. Shown here are the contents of a control file with
specifications to load a fixed-width datafile.
UNRECOVERABLE
LOAD DATA
INFILE 'd:\sqlldr\employee.txt'
BADFILE 'd:\sqlldr\bad\employee.bad'
TRUNCATE
INTO TABLE employee
(
emp_id POSITION(1:6),
last_name POSITION(8:28),
first_name POSITION(30:50),
ssn POSITION(52:61),
dept_no POSITION(63:68)
)

In this example, each column is specified with a position to tell SQL*Loader
where in the datafile the column starts and stops. For example, the LAST_NAME
column begins at the 8th position from the left side of the file, and ends at the
28th position from the left side of the file.
SQL*Loader Commands
SQL*Loader is a command line utility and, therefore, comes with several argu-
ments that can be passed to the utility when executed. The entire SQL*Loader
command is entered at the command prompt with all arguments on a single line,
and each argument is assigned a value. The table shown here provides a list of
valid arguments with a description of appropriate values for each.
Argument Description
userid The Oracle user name and password to execute the load with. This user must
have INSERT privileges on the target table.
control The name of the control file to use for the load, including full path and file
name.
bad The path and file name of the bad file where rows that cause errors will be
stored.
data The path and file name of the datafile to load from.
discard The path and file name of the file to store discarded rows.
discardmax The maximum number of rows allowed to be discarded. Once this limit is
reached, the load is terminated. This argument defaults to allow all discards.
skip The number of rows in the datafile to skip starting from the first row. This is
useful when you must continue a previous load that failed. The default is 0.
load The number of rows to load. The default is all rows.
errors The maximum number of errors to allow before terminating the load. The
default is 50.
rows The number of rows in a conventional path bind array, or the number of
rows between saves in a direct path load. For conventional path, the default
is 64, for direct path the default is all rows.
bindsize The size of the conventional path bind array in bytes.
silent Suppress all screen-displayed messages during run. Useful for loads run
from a batch file or script.
direct Use direct path. Default is FALSE.
parfile The path and file name of an option parameter file that contains command
line arguments.
parallel Perform parallel load (multiple datafiles into a single table). Default is
FALSE.
file The name of the tablespace datafile to first start loading the data. The table
may extend out of this datafile if necessary.
readsize Size of the read buffer in bytes.
You may have noticed that several arguments have the same purpose as portions
of the control file syntax. This is the case, and you have a choice of listing those
arguments in the command line, or as clauses in the control file. If the arguments
appear in both the command line and control file, the arguments in the command
line will take precedence. The following example shows a sample SQL*Loader
command, complete with arguments.

sqlldr userid=system/ora92 control=d:\sqlldr\sample.ctl ⇒
log=d:\sqlldr\sample.log bad=d:\sqlldr\sample.bad ⇒
discard=d:\sqlldr\sample.dis discardmax=1000 rows=100 ⇒
bindsize=10240
In this example, the load will be run as the user SYSTEM and will use the
instructions found in the SAMPLE.CTL control file. This control file specifies the
name of the datafile to load from and the name of the target table to load to. All
screen output will be recorded in the SAMPLE.LOG log file, and if any rows
cause errors, they will be stored in the SAMPLE.BAD bad file. If any rows do
not meet the criteria specified by the control file’s WHEN clause, these rows will
be copied to the SAMPLE.DIS discard file, and the maximum number of discards
allowed will 1000. The number of rows to load into the bind array is 100, and
the bind array will be 10240 bytes, or 10 MB.
TASK 6A-1
Using SQL*Loader
Objective: To quickly load data into the database using SQL*Loader.
1. The inventory.dat file contains 5000 rows of sample inventory data that you
will load into the a table in the database.
Open a window to the C:\079176 folder. Double-click the inventory.dat

file to open it. A caution window will appear to warn you about opening a
*.dat file. Click Open With. Select Notepad from the list of applications
and click OK.
The inventory.dat file will open in a Notepad window. The contents of this
file are in a delimited format, with each field terminating with a comma. You
will load the contents of this file into a table in the database. When you are

done looking at the contents, close the inventory.dat file.
2. You will first create the ITEM table where the data will be stored.
Leaving the C:\079176 window open, launch SQL*Plus and log in as sys.
At the SQL*Plus prompt, issue the following command to create the

ITEM table:
CREATE TABLE item
(
item_id NUMBER(12,0),
vendor_id NUMBER(12,0),
item_name VARCHAR2(64),
descr VARCHAR2(1000),
unit VARCHAR2(5),
retail_price NUMBER(8,2),
qty_on_hand NUMBER(8,0)
)
TABLESPACE users;

3. You will now create the control file for SQL*Loader to load this data.
Leaving SQL*Plus open, choose File→Programs→Accessories→Notepad.

This will launch the Notepad application.
4. In this control file, you will specify that the data to be loaded is located in
the file C:\079176\inventory.dat. You will direct the utility to automatically
create a bad file called C:\079176\inventory.bad to catch any rows that cause
errors. You will also specify that each field in the datafile is terminated by a
comma.
In Notepad, type the following lines:

LOAD DATA
INFILE 'C:\079176\inventory.dat'
BADFILE 'C:\079176\inventory.bad'
INSERT
INTO TABLE item
FIELDS TERMINATED BY ','
(
ITEM_ID,
VENDOR_ID,
ITEM_NAME,
DESCR,
UNIT,
RETAIL_PRICE,
QTY_ON_HAND
)
Once you have completed the contents of the file, save the file to the
C:\079176 directory. Change the Save As Type to ALL Files, and name
the file INVENTORY.CTL

5. Open a command prompt.
At the command prompt, launch SQL*Loader to load the

INVENTORY.DAT file into the database. Use the following command: The double arrow (⇒)
indicates that command
sqlldr USERID='sys/ora92@ora92 as sysdba' ⇒ should be typed on a single
control=c:\079176\inventory.ctl ⇒ line and is not part of the
log=c:\079176\inventory.log syntax.
Once you press Enter, SQL*Loader will execute and load all the data from
the INVENTORY.DAT file into the ITEM table. You will see the output
from the utility scroll by as it loads rows of data. Once you are finished
looking at the output, exit from the command prompt.
6. Once the load is complete, you should check the SQL*Loader log and bad
files to see if any errors were encountered that caused rows to be rejected.
Switch back to the C:\079176 window. You will see that a bad file was not
generated, which means that no rows were rejected during the load. Open
the INVENTORY.LOG file.
The log file contains a summary of the activity that took place during the
load. Take a moment to look through the file. Once you are done looking at

the file, close the Notepad window and the C:\079176 folder.
7. You will now confirm that all 5000 rows have indeed been loaded into the
ITEM table.
At the SQL*Plus prompt, issue the following query:

SELECT COUNT(*)
FROM item;
The output will show that the ITEM table now contains all 5000 rows from
the INVENTORY.DAT file.
8. You can query the ITEM table to see some of its contents.
First, format the output of your query with the following commands:

COLUMN item_name FORMAT a25
COLUMN descr FORMAT a30
SET LINES 132 PAGES 30

The list of items shown in
SELECT * the output may not be listed
FROM item in the same order that is
WHERE rownum<=20; shown here.
The output will show that the ITEM table now contains the rows of data
from the INVENTORY.DAT file.
Direct Load Inserts

Standard SQL allows you to issue an INSERT statement that can retrieve data
from a table using a standard query and load the rows into another table. A direct
load insert provides the capability to perform the same task and bypass the SQL
processing engine to perform a direct-path mode, much in the same way that direct load insert:
SQL*Loader performs a direct path load. This can greatly reduce the amount of A method of loading data
resources consumed to process the statement, which can significantly increase its from one table to another
using a direct path load.
performance.
To perform a direct load insert, you would simply include the APPEND hint
immediately after the INSERT keyword in the statement. This instructs the
Oracle optimizer to append the result set of the query directly to the target table
without having to pull the target datablocks into the buffer cache first. A direct
load insert can only be performed on INSERT statements that contain a subquery.
If you include the APPEND hint with a standard, single-row insert, the hint will
be ignored and Oracle will perform a standard insert.
While a single insert statement can only insert rows into a single table, the query
you specify can be any valid SELECT statement, which may include any number
of tables. This provides the capability to combine values from multiple tables,
perform calculations, and summarize data as necessary. The hint is specified as a

special comment within the statement itself. The APPEND keyword is enclosed
inside a set of comment brackets, namely slashes and asterisks, and must include
a plus sign (+) as well. When formed properly, a hint can influence Oracle’s
optimizer to generate a slightly different execution plan than it normally would
without the hint. A properly formed hint would look like this:
/*+ APPEND */
If Oracle determines that the action specified by the hint is simply not possible,
or is missing the plus sign, it will ignore the hint as a simple comment and make
its own determination of how to execute the statement.
Direct Load Inserts
The following is an example INSERT statement that will perform a direct load
insert.
INSERT /*+ APPEND */ INTO monthly_results
SELECT TO_CHAR(a.trans_date,'MON'), a.item_name,
SUM(b.final_price)
FROM transactions a, orders b
WHERE a.order_id = b.order_id
GROUP BY TO_CHAR(a.trans_date,'MON');
In this example, the APPEND hint is properly included after the INSERT
keyword. The SELECT statement performs a join of the TRANSACTIONS and
ORDERS tables. The results are appended to the end of the MONTHLY_
RESULTS table, without needing to pull the target datablocks into the buffer
cache first.
TASK 6A-2
Loading Data Using Direct Load Inserts
Objective: To load data into a table with a direct load insert.
To see the difference between a direct load insert and a conventional insert,
you will look at the differences between the execution plans of each type of
statement. You will first need to create the PLAN_TABLE, which will hold
the execution plan generated by the EXPLAIN PLAN command.
At the SQL*Plus prompt, type @D:\oracle\ora92\rdbms\admin\utlxplan.sql

and press Enter.
Oracle will display the message “Table created.” You can now generate
execution plans with the EXPLAIN PLAN command.
2. You will create an empty table, called ITEM_DIRECT, with a structure iden-
tical to that of the ITEM table. This table will serve the target of our direct
load insert.

At the prompt, create the ITEM_DIRECT table by issuing the following
command:
CREATE TABLE item_direct
TABLESPACE users AS
SELECT *
FROM item
WHERE 0=1;
To verify that the ITEM and ITEM_DIRECT tables are identical, issue the
following commands:
DESCRIBE item
DESCRIBE item_direct
The output will show that the two tables are indeed identical.
3. You will now generate an execution plan for a conventional INSERT state-
ment which reads all the rows from the ITEM table and inserts them into the
ITEM_DIRECT table.

EXPLAIN PLAN FOR
INSERT INTO item_direct
SELECT *
FROM item;
Oracle will display the message “Explained.”
4. To see the execution plan you just created, type @C:\079176\listplan.sql

and press Enter.

The execution plan will show a simple insert statement, and a simple table
access of the ITEM table.
5. You will now generate an execution plan for a direct load INSERT state-
ment to read all the rows from the ITEM table, and append them to the
ITEM_DIRECT table.
To clear out the plan table, type TRUNCATE TABLE plan_table; and
press Enter.
Oracle will display the message “Table truncated.”

EXPLAIN PLAN FOR
INSERT /*+ APPEND */ INTO item_direct
SELECT *
FROM item;
Oracle will display the message “Explained.”
6. To see the new execution plan you just created, type @C:\079176\listplan.
sql and press Enter.
The output will show a different execution plan for this INSERT statement
than the previous statement. This execution plan shows an INSERT state-
ment and a table access of the ITEM table, just as before, but this time the

option LOAD AS SELECT is also included. This indicates a direct load
insert into the target table.
7. You will now execute the direct load insert into the ITEM_DIRECT table.

INSERT /*+ APPEND */ INTO item_direct
SELECT *
FROM item;
Oracle will display the message “5000 rows created.” Type COMMIT; and
press Enter.
External Tables
Oracle9i provides a feature that enables you to access external data using stan-
dard SQL as if you were querying a table or a view. You can create external
tables, which are table-like structures that direct Oracle to read the data from
external files and return it to the calling user. Creating and using external tables external table:
eliminates the need to use a separate process that loads the data into the database A table-like structure in
before processing it. Oracle provides the clause ORGANIZATION EXTERNAL Oracle that accesses an
external flat file containing
for the CREATE TABLE command to define external tables. data.
The definition of an external table looks very much like a combination of the
standard CREATE TABLE syntax and a SQL*Loader controlfile. The CREATE
TABLE command includes the logical structure of the table, meaning the columns
and their data types. It also includes the location where the external file can be
found and the information about how the data is formatted in the file. When the
external table is accessed, thefile that contains the data is read sequentially to
fetch the data into the buffer cache. External tables are read-only tables, and you
cannot generate indexes on them. Also, you must take extra care to ensure the
security of the data because any user that has sufficient privileges through the
operating system can open and read the datafile.

Before creating external tables, you must first ensure that the Oracle database has
the appropriate privileges to read from the directory where the file resides in the
operating system. You must then create a special object called a directory within
the Oracle database. The directory specifies the path where the external file
resides. The syntax to create a directory is shown here.
CREATE OR REPLACE DIRECTORY dir_name AS 'os_path';
In this syntax, dir_name is the name assigned to the directory from within the
Oracle database. This name can be any character string up to 30 characters in
length and cannot start with a number or special character. The os_path specifies
the full directory path in the file system. The following command will create a
directory called ETL_LOAD that references the C:\etl\weekly directory on the
server location within the host file system external to the database.
CREATE OR REPLACE DIRECTORY etl_load AS 'C:\etl\weekly';
You can create as many directories as you like, and any valid directory can con-
tain multiple text files for use by external tables. Additionally, just like
SQL*Loader, external tables provide a way to handle invalid data that might be
found in the datafile. If a row of data fails validation for any reason, such as a
character found in a column that is supposed to contain only numbers, the row
will be rejected. You can direct Oracle to send rejected rows to a bad file, which
can reside in its own directory or in the same directory as the datafile. You can
also specify a log file that will capture any informational messages generated by
Oracle when the file is accessed.
Once the required directories are created, the owner of the table and any users
that need to access the external table will need privileges on the directory. The
owner and all other users will need at least the READ privilege on the directory
that contains the datafile. They will also need at least the WRITE privilege on the
directories that will contain the bad and log files. To grant these privileges, you
would use the standard GRANT command, which is shown here.
GRANT {READ | WRITE} ON dir_name TO user_name;
The CREATE TABLE command contains many clauses and keywords to support
external tables. To illustrate its use effectively, we will look at an example
CREATE TABLE statement for an external table, which is shown here.
CREATE TABLE DISTRICT.STORES_EXT
( STORE_ID NUMBER(12,0),
REGION_ID NUMBER(12,0),
MGR_NAME VARCHAR2(64),
MGR_PHONE VARCHAR2(25),
STORE_TYPE VARCHAR2(5)
)
ORGANIZATION EXTERNAL
( TYPE ORACLE_LOADER
DEFAULT DIRECTORY dat_dir
ACCESS PARAMETERS
( RECORDS DELIMITED BY NEWLINE
LOGFILE log_dir:'stores_%p.log'
BADFILE bad_dir:'stores_%p.bad'

( store_id,
region_id,
mgr_name,
mgr_phone,
store_type
)
)
LOCATION ('stores.dat')
)
REJECT LIMIT UNLIMITED
PARALLEL (DEGREE 4);
In this syntax, you can see that the command looks like a hybrid between the
CREATE TABLE command and a SQL*Loader control file. The first half pro-
vides the column names and their data types. The second half specifies how to
handle the file containing the data.
The clause that tells Oracle that the table is an external table is
ORGANIZATION EXTERNAL. The TYPE clause specifies the access driver, Although the default access
which is the utility that is to be used to access the external data and pass it to the driver for external tables,
Oracle database. The default for this clause is ORACLE_LOADER. Currently, ORACLE_DRIVER, behaves
ORACLE_LOADER is the only value allowed for the TYPE clause. It is expected very much like SQL*Loader,
that future versions of Oracle may allow additional types of access drivers to it is actually not SQL*Loader.
access the external files. The access driver is a
completely different utility
The DEFAULT DIRECTORY clause specifies the directory to look in to find the that was designed to look
datafile. This directory must first be created with the CREATE DIRECTORY and act like SQL*Loader.
statement prior to creating the external table. The ACCESS PARAMETERS clause
contains a list of access driver-specific commands to access the data. For the
ORACLE_LOADER access driver, you can use a syntax very similar to the column
listing in a SQL*Loader control file.
Within the ACCESS PARAMETERS clause, you would specify how the data in
the external file is formatted. These parameters are not read by the Oracle
database. Instead, they are passed to the access driver, which uses them to deter-
mine how to read the data in the text file. In our example, the RECORDS
DELIMITED BY NEWLINE clause indicates that each record is terminated by a
carriage return. Also, the FIELDS TERMINATED BY clause specifies how the
fields in a single record are separated. In our example, the fields are separated by
commas.
The LOGFILE and BADFILE clauses specify the directories and file names to
use for the output log file and badfile, respectively. As stated earlier, all users that
need to access an external table must have write privileges on these directories.
This holds true even if no errors are encountered, and the bad file remains empty.
In the file names for these files, you can optionally specify variables to dynami-
cally create file names for each log generated. In our example, the variable %p
indicates that the OS process ID for the user will be used as part of thefile name.
This will ensure that previously generated files will not be overwritten.
The LOCATION clause lists the name of the external file that contains the data.
You can even specify multiple file names if the data spans multiple files. When
accessing an external table that is made up of multiple files, the files will be read
sequentially in the order specified by the LOCATION clause.
The REJECT LIMIT clause specifies how many data access errors are allowed
before a query is terminated. For example, if the REJECT LIMIT is set to 100,
then 100 data access errors will be allowed. The 101st data access error will
return an error to the user, and the query will be terminated. The value of

UNLIMITED states that an unlimited number of errors will be allowed. Access
errors can occur when there is some sort of conversion error on the data in the
file, such as when a character is found in a piece of data that is mapped to a
NUMBER data type, or when a character string from the text is wider than its cor-
responding column data type will allow.
It is important to remember that you cannot create indexes on external tables, and
because the files are read sequentially, every pass through an external table will
be equivalent to a full-table scan. You can, however, specify a PARALLEL clause,
which allows you to set the degree of parallelism for an external table just as you
would for a normal table. This will enable parallel execution for all queries that
access the table. It is recommended that you set the PARALLEL clause to a value
that is at least equal to the number of text files you have. This will allow you to
place your text files on separate disks and balance the I/O throughput, while
allowing parallel access to the data.
Once an external table is created, you can query the table by using basic SQL
statements and access its data as you would with any normal table; you can even
join an external table with other tables or views. You can also use data loading
commands, such as CREATE TABLE...AS SELECT or a direct-load insert, to
query from the external table and load its data into another location within the
database. Such processing provides a powerful feature that can load data from a
flat file into the database and easily specify filter conditions to narrow down the
data that will be loaded.
TASK 6A-3
Creating and Accessing External Tables
Setup: To create and access external tables to read and load data from
outside the database.
1. You will first create the directories that will hold the datafile, the log file,
and the bad file. The three directories will be called data, log, and bad,
respectively.
In the C:\079176 directory, create the data, log, and bad directories.
2. You will use the inventory.dat file as the data source for your external table.
Move or copy the inventory.dat file into the data directory.
Before you can access the file, you must first tell Oracle where this file is
located. This is done by creating a directory within the database that points
to the actual path where the file is located. You must also create directories
to tell Oracle where to create the log and bad files.
To create these directories, issue the following commands at the prompt:

CREATE OR REPLACE DIRECTORY dat_dir AS 'C:\079176\data';
CREATE OR REPLACE DIRECTORY log_dir AS 'C:\079176\log';
CREATE OR REPLACE DIRECTORY bad_dir AS 'C:\079176\bad';

After each command, Oracle will display the message “Directory created.”
4. You will now create the external table. This table will have the following
structure.
COLUMN DATATYPE
item_id NUMBER(12,0)
vendor_id NUMBER(12,0)
item_name VARCHAR2(64)
descr VARCHAR2(1000)
unit VARCHAR2(5)
retail_price NUMBER(8,2)
The following information will be used to create the external table:

• The external table will be called ITEM_EXT.
• The inventory.dat file is located in the dat_dir directory.
• All records in the inventory.dat file are terminated by a newline
character.
• Each field in the inventory.dat file is delimited by a comma (,).
• Any log information will be directed to the log_dir directory into a file
called itemext_%p.log.
• Any log information will be directed to the log_dir directory into a file
called itemext_%p.log.
• In the names of the log and bad files, %p indicates the process ID of
the user session attempting to access the table.

Create the ITEM_EXT table by issuing the following command from the
prompt:
The syntax for this CREATE CREATE TABLE item_ext
TABLE command is (
somewhat lengthy. If you item_id NUMBER(12,0),
have problems typing in the vendor_id NUMBER(12,0),
entire command, you can item_name VARCHAR2(64),
find the exact command in descr VARCHAR2(1000),
the C:\079176\item_ext.sql unit VARCHAR2(5),
file. retail_price NUMBER(8,2),
)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY dat_dir
ACCESS PARAMETERS
(
RECORDS DELIMITED BY NEWLINE
LOGFILE log_dir:'itemext_%p.log'
BADFILE bad_dir:'itemext_%p.bad'
(
item_id,
vendor_id,
item_name,
descr,
unit,
retail_price,
qty_on_hand
)
)
LOCATION ('inventory.dat')
)
REJECT LIMIT UNLIMITED;
Oracle will return the message “Table created.”

5. To bring up a description of the ITEM_EXT table, type DESCRIBE item_
ext and press Enter.
Oracle will display the column layout of the ITEM_EXT table. You will see
that it looks identical to a typical Oracle table.
6. Now that the external table has been created, you can query from it just like
any other table.
To see the total number of rows in the table, issue the following query:
SELECT COUNT(*)
FROM item_ext;
The output will show that there are 5000 rows in the ITEM_EXT table.
7. To find how many items were purchased from each vendor, issue the follow-
ing query:
SELECT vendor_id, COUNT(item_id)
FROM item_ext
GROUP BY vendor_id;

Oracle will display the number of items that have been purchased per
vendor.
8. Since an external table can be queried just like any other table, this becomes
a convenient and powerful method for loading data into the database. You
will query from the table and direct the data to be loaded into another table.
You will create a new table based on the data from the ITEMS_EXT exter-
nal table. This new table will be called HIGHER_ITEMS, and will contain
only items that have a retail price that is greater than 40 dollars.

CREATE TABLE higher_items
TABLESPACE users
AS
SELECT *
FROM item_ext
WHERE retail_price > 40;
9. To see how many rows exist in your new table, issue the following query:
SELECT COUNT(*)
FROM higher_items;

The output will show that only 2728 of 5000 rows were loaded into the
HIGHER_ITEMS table.
10. To see the lowest retail price of the items in this table, issue the following
query:
SELECT MIN(retail_price)
FROM higher_items;
Oracle will display the lowest retail price that exists in the HIGHER_ITEMS
table. Only the items with a retail price greater than 40 dollars were
retrieved from the ITEMS_EXT external table and loaded into the HIGHER_
ITEMS table.
External tables provide a very convenient method of accessing data that is

external to the Oracle database. They can be queried like any other table,
and can even be joined with other tables and views. External tables also pro-
vide a simple but flexible method of loading data into the Oracle database,
which can be invaluable in data warehousing environments.
11. Exit from SQL*Plus and close all open windows.
Topic 6B
The Export and Import Utilities
The export and import utilities are command line executables that allow you to
quickly reorganize data in a database or to move data from one database to
another. The flat file created by the export utility is in binary format and can only
be read by Oracle’s import utility, but it can be imported into another database,
even if the target database resides on another operating system. This comes in
especially useful if you need to quickly move an entire database from one plat-
form to another.

The Export Utility
There are five levels of exports, which are table, user, tablespace, transportable
Types of Exports
tablespace, and full. The privileges granted to a user dictate which export the user
is allowed to perform. For example, any user can perform a table-level export of
a single table in their own schema, while a full export requires the user to at least
have the EXP_FULL_DATABASE role. This role provides the user with enough
permissions to read from all objects in the database.
A table-level export is an export of one or more tables. This type of export can
be used to quickly move large tables from one database to another, or from one
schema to another. When doing a table-level export, you can specify any table
from any user’s schema that you have the privileges to access. Additionally, you
can export a combination of tables from different schemas at the same time. The
export utility even provides a table name pattern-matching feature, by using the
percent sign (%) with the TABLES argument, similar to the pattern matching that
can be used in the WHERE clause of a SQL statement. For example, if you wish
to export all the tables in the database that have names beginning with the string
‘FACT’, you could use the following export command:
exp userid=system/oracle@ora92 file=d:\oracle\testexp.dmp ⇒
tables=fact%
Unlike the WHERE clause of a SQL statement, the only wildcard supported for the
TABLES argument is the percent sign; the underscore (_) is not supported. How-
ever, you can include any number of percent signs in any position of the table
name. All accessible tables that have a name matching the pattern are exported to
the file. The import utility supports the same pattern matching functionality with
the TABLES argument. All the tables that have a name matching the specified
pattern will be imported into the target database.
The export utility also provides the capability of exporting only subsets of data
during a table-level export. This is done by including a set of conditions with the
QUERY argument of the export command. Only the data that satisfies the query
will be exported. If you are exporting multiple tables simultaneously, the same
conditions will apply to all tables.
A user-level export is an export of an entire user’s schema. All objects owned by
the user, such as tables, indexes, constraints, and sequences, will be exported to
the export file. In a user-level export, you can export more than one user at a
time by specifying each source user in the export command. However, you can-
not mix export modes. For example, you cannot export a single table from one
user’s schema and another user’s schema in its entirety. A single export must be
done in one mode only. You can, however, export a single table from one
schema, and all the tables from another schema. The disadvantage in doing this is
that you will be missing all other objects and privileges from both users.
A tablespace-level export will export all objects stored in one or more
tablespaces, as specified by the TABLESPACES argument. As long as you have
sufficient privileges on the objects, the contents of the specified tablespaces are
exported to the export file. Additionally, any indexes that belong to the tables in
the exported tablespaces are exported as well, regardless of which tablespaces the
indexes are stored in. This type of export is slightly different than a transportable
tablespace export, in which no data from the source tablespace is actually
exported. The export utility exports only the required information from data dic-
tionary relevant to the source tablespaces. The datafiles that make up the
tablespace are then copied to the target database, and the data dictionary informa-
tion is imported back in. You will learn more about transportable tablespace later
in this lesson.

A full database export will export everything in the database, with the exception
of the SYS schema. All users, including their privileges and objects, are exported
into the export file. This requires the EXP_FULL_DATABASE role or an equiva-
lent set of privileges. When exporting the entire database, you cannot selectively
choose tables or users; it’s all or nothing.
Like SQL*Loader, the export utility also provides both conventional and direct
path exports. During a conventional-path export, the export utility generates stan-
dard SELECT commands to read data from the source objects, which are
processed by the SQL processing engine in the database. A direct-path export will
bypass the SQL processing engine and write directly to the export file, which can
greatly improve the speed of the export.
The export command comes with a list of available arguments that can be passed
at the command line. These arguments dictate the type of export and import per-
formed, and specify other options while executing. The following table shows a
list of some of the available export arguments and valid values for each.
Argument Value
userid User name and password of the user executing the utility. Must be the first
argument passed at the command line.
buffer Size of the data buffer in bytes.
file Path and file name of the export file to create.
compress Indicates that each object to be exported will later be imported into a single
extent. The default is Y, to indicate that objects will be compressed.
grants Indicates whether user privileges will be included in the export. The default
is Y.
indexes Indicates whether indexes will be included in the export. The default is Y.
rows Indicates whether rows of data will be included in the export. The default is
Y. If set to N, then only the structure of the objects will be exported.
contraints Indicates whether constraints will be included in the export. The default is
Y.
log Path and file name of the log file to record screen output.
direct Indicates whether the export should be done in direct mode.
feedback Sets the number of rows to use for feedback. For every row exported, the
utility will display a dot (.) to the screen to show its progress. The default
is 0.
filesize Sets the maximum size of the export file. When the size of the first file
grows to this size, and if multiple files are listed by the file argument,
the export utility will automatically begin writing to the next file. If multiple
files are not listed, the export will halt with an error.
query Lists the conditions to filter the data prior to exporting.
full Indicates whether to perform a full database export. The default is N. Can-
not be used in conjunction with owner, tables, or
tablespaces.
owner Lists the users to export for a user-level export. Cannot be used in
conjunction with full, tables, or tablespaces.
tables Lists the tables to export for a table-level export. Cannot be used in
conjunction with full or owner.
recordlength Specifies the length of the file record in bytes. The default is operating
system dependent.
parfile Path and file name of optional parameter file to hold export parameters.

Argument Value
consistent Indicates whether constraint-checking should occur during export to keep
the tables in the export file consistent. The default is Y.
triggers Indicates whether triggers should be included in the export. The default is
Y.
The export utility also provides a help screen that can be accessed by running
export utility with only the help=y argument. The help screen will display a list
of all available arguments with their descriptions. The following shows a sample
export command to take a user-level export of the user Scott.
exp userid=sys/oracle file=d:\export\scott.dmp ⇒
log=d:\export\scott.log direct=y feedback=1000 owner=scott
In this example, Scott’s entire schema will be exported into the SCOTT.DMP
export file. The export will be performed in direct mode and will display a dot
for every 1000 rows exported. An export file should never be opened or edited.
Doing so could corrupt the file, which will render it useless. The only recourse
for dealing with a corrupted export file is to take another export.
TASK 6B-1
Exporting the Database
Objective: To export the contents of the database using the export utility.
1. You will first perform a full database export. You will perform the export in
direct mode, and the export file will be named exp_ora92_full.dmp.
Open a command prompt. At the prompt, issue the following command

as if it was a single line of input:
exp userid='sys/ora92@ora92 as sysdba' ⇒
file=C:\079176\exp_ora92_full.dmp ⇒
log=C:\079176\exp_ora92_full.log full=y direct=y
Once you press Enter, the export will begin. You will see the window fill
with informational messages as the utility processes each step of the export.
All objects in the database, except for those owned by SYS, will be exported

to the exp_ora92_full.dmp file. It will take a few minutes for the export to
complete.
2. You will now perform an export of just a single schema. The schema you
will use for this export is OE, which is the user for the order entry example
schema.
At the prompt, issue the following command as if it was a single line of

input:
file=C:\079176\exp_ora92_oe_schema.dmp ⇒
log=C:\079176\exp_ora92_oe_schema.log owner=oe direct=y
Once you press Enter, the export will begin. This time, only the objects
owned by the OE user will be exported to the exp_ora92_oe_schema.dmp
file. It will take a few minutes for the export to complete.
3. You will perform an export of only those objects that reside in the
EXAMPLE tablespace. All objects in this tablespace, regardless of which
user owns them, will be exported to the exp_ora92_example_ts.dmp file. The
export will also include any indexes on the tables in the EXAMPLE
tablespace, even if those indexes are stored in a different tablespace.

input:
file=C:\079176\exp_ora92_example_ts.dmp ⇒
log=C:\079176\exp_ora92_example_ts.log ⇒
tablespaces=example direct=y
Once you press Enter, the export will begin. All objects in the EXAMPLE
tablespace will be exported. It will take a few minutes for the export to
complete.
4. You will now perform an export of only a single table. The table you will
use is the SCOTT.EMP table.

input:
file=C:\079176\exp_ora92_scott_emp.dmp ⇒
log=C:\079176\exp_ora92_scott_emp.log ⇒
tables=scott.emp direct=y

Once you press Enter, the Scott’s EMP table will be exported to the file. The
export should complete fairly quickly.
5. You will now perform an export of several tables owned by the SH user, all
of which have names that begin with the letter C.

input:
file=C:\079176\exp_ora92_wildcard.dmp ⇒
log=C:\079176\exp_ora92_wildcard.log tables=SH.C% direct=y
Once you press Enter, all the tables owned by SH that begin with the letter
C will be exported.
The export utility provides a wide variety of features to allow DBAs and
users a powerful method of extracting data from an Oracle database. The
utility can export the entire database, one or more users’ schemas, the con-
tents of a tablespace, one or more specific tables, or even a list of tables that
match a certain naming pattern.
6. Exit from the command prompt.

The Import Utility
Like the export utility, the import utility also provides five modes of import.
Depending on his or her privileges, a user can perform a table-level, user-level,
tablespace-level, transportable tablespace, or full import. However, any mode of
import can be performed on an export file created from any mode of export, with
the exception of the tablespace-level export.
For example, an export file created from a full database export can be used to
import only a single user’s schema or even a single table. Only a subset of the
data contained in the export file will be imported. An export file created from a
table-level export can be used for a full import. A full import on any export file
results in the entire contents of the file being imported. If a table-level export is
used for a full import, only the tables owned by the specified user will be
imported. Figure 6-3 represents an export file that contains a full database export,
and is used for a table level import. A tablespace-level export can only be
imported with a tablespace-level import. The import utility does not provide a
direct-path import.
A Full Export Used for a

Table-level Import
Figure 6-3: A full export used for a table-level import.

The import utility provides many of the same arguments as the export utility. The
following table shows a list of available arguments for the import utility.
Argument Value
userid User name and password of the user executing the utility. Must be the
first argument passed at the command line.
buffer Size of the data buffer in bytes.
file Path and file name of the file to import from.
show Instructs the import utility to only show the contents of the source file.
No data will be imported. The default is N.
ignore Specifies whether to ignore create errors during import due to the
object already existing. The default is N.
grants Indicates whether user privileges will be imported. The default is Y.
indexes Indicates whether indexes will be imported. The default is Y.
rows Indicates whether rows of data will be imported. The default is Y. If set
to N, then only the structure of the objects will be imported.
contraints Indicates whether constraints will be imported. The default is Y.
log Path and file name of the log file to record screen output.
commit Specifies whether to send a COMMIT command each time all the data
in the import buffer has been written to the datafiles. The default is N.

Argument Value
feedback Sets the number of rows to use for feedback. For every row imported,
the utility will display a dot (.) to the screen to show its progress. The
default is 0.
destroy Clear the contents of the target datafiles prior to importing the data. The
default is N.
full Indicates whether to import all the contents of the entire file. The default
is N. Cannot be used in junction with fromuser, touser, or
tables.
fromuser Specifies the name of the schema to import. Can be used in
conjunction with touser and tables to transfer objects from one
schema to another. Cannot be used in conjunction with full.
touser Specifies the name of the target schema that will receive the imported
objects. Can be used in conjunction with fromuser and tables
to transfer objects from one schema to another. Cannot be used in
conjunction with full.
tables Lists the tables to import for a table-level import. Cannot be used in
conjunction with full, but can be used with fromuser and
touser.
recordlength Specifies the length of the file record in bytes. The default is operating
system dependent.
parfile Path and file name of optional parameter file to hold import parameters.
statistics Specifies how to handle object statistics while importing. Possible
values include ALWAYS, RECALCULATE, NONE, and SAFE. The
default is ALWAYS.
indexfile Path and file name of a script file that can be generated to contain the
CREATE commands to create all tables and indexes in the import
file. No data will be imported when this argument is specified.
Like the export utility, the import utility also provides a help screen that can be
accessed by passing the argument help=y at the command line. The following
shows a sample import command to perform a full import.
imp userid=sys/oracle file=d:\import\scott.dmp ⇒
log=d:\import\scott.log feedback=1000 full=y
In this example, the entire contents of the SCOTT.DMP file will be imported into
the database. All screen output will be recorded in the SCOTT.LOG file, and the
utility will generate a dot for every 1000 rows imported to show its progress.
Once the tables are imported, the utility will pass the appropriate commands to
Oracle to enable any referential integrity constraints on the tables. If any con-
straints cannot be enabled for any reason, such as a foreign key that references a
table that does not exist, the import utility will display a warning to the screen,
but will continue with the import. Additionally, any PL/SQL packages, proce-
dures, and functions that are included in an export file, namely a full or user-level
export, will be automatically created and compiled at the end of the import
process. If compiling these objects are subject to any errors, the objects are still
created, but are left in an invalid state. The import utility will display a warning
message about the error and continue its process.

TASK 6B-2
Importing Data into the Database
Objective: To import data from an export file into the database.
1. In the previous task, you performed several exports from the database, one
of which was a full database export. From that full export, you will perform
a table level import to import a single table from the HR schema into the
SCOTT schema. The table you will import is called JOB_HISTORY.
First, you will confirm that Scott does not currently own a table called JOB_
HISTORY.
At the SQL*Plus prompt, issue the following query:

SELECT table_name
FROM dba_tables
WHERE owner='SCOTT';
The output will show that Scott owns four tables, but none of them are
named JOB_HISTORY.
2. Leaving the SQL*Plus window open, open a command prompt.

input:
imp userid='sys/ora92@ora92 as sysdba' ⇒
file=C:\079176\exp_ora92_full.dmp ⇒
log=C:\079176\imp_ora92_job_hist.log ⇒
fromuser=hr touser=scott tables=job_history
Once you press Enter, the import will begin. The import utility will find the
JOB_HISTORY table almost immediately and import it from the HR schema
into the SCOTT schema.
After a few moments however, the utility will display several error messages

when attempting to enable constraints on the table.
The JOB_HISTORY table was imported into Scott’s schema, but several
foreign key constraints could not be enabled because they reference tables
that Scott does not currently own. However, the final message in the output,
which states “Import terminated successfully with warnings,” indicates that
the table was imported even though some warnings were raised during the
process.
Exit from the command prompt.
3. You will now confirm that the JOB_HISTORY table does indeed exist in
Scott’s schema.
At the SQL*Plus prompt, type / and press Enter.
Your previous query will execute again. This time, the output will show that
Scott now owns a table called JOB_HISTORY.

Transportable Tablespaces
In the previous topic, you learned how to export data from the database and
import it back in again. You learned about full, table, user, tablespace-level
exports and imports. A transportable tablespace export is a special kind of export
that does not actually export any data. The metadata in the data dictionary that is transportable
relevant to the tablespaces you are transporting are exported into a dictionary file. tablespace:
The datafiles that make up the tablespaces are then copied over to the target data- An Oracle feature that allows
you to copy an entire
base and the dictionary file is imported. This feature can only be used between tablespace from one
two databases that reside on compatible operating systems. database to another by
simply exporting the
Transportable tablespaces provide several advantages over other methods of mov-
tablespace metadata from the
ing data, including other types of exports and imports. Generally, using data dictionary.
transportable tablespaces is much faster than a standard export and import. This is
because only the tablespace metadata must be exported, instead of the tablespace
contents. The tablespace metadata is usually very small in size, while the
tablespace itself could be gigabytes in size.
There are some limitations to consider when moving data with transportable
tablespaces. Both the source and target databases must have identical block sizes The COMPATIBLE
and must be of the same character set. You cannot transport a tablespace into a initialization parameter on
database where a tablespace of the same name already exists. Also, tablespaces both the source and target
being transported cannot contain replication objects or function-based indexes. databases must be set to 8.1
The owners of the objects in a tablespace to be transported must already exist in or higher.
the target database. Only the tablespace metadata will be moved over and not the
user metadata.
The steps to transport tablespaces from one database to another are fairly simple.
They are:
1. Select a set of tablespaces that are self-contained (for example, have no
dependencies on objects in tablespaces not included in the set).
2. Create the dictionary file using the export utility.
3. Copy the datafiles and export file to the server where the target database
resides.
4. Import the dictionary file into the target database.
In step 1, you must choose a set of tablespaces that are self-contained. This
means that objects within the tablespaces to be transported have no dependencies
on other objects that do not reside in a tablespace included in the set. For
example, let’s say you wanted to transport the INVENTORY_DATA and
INVENTORY_INDEXES tablespaces together. The INVENTORY_INDEXES
tablespace contains an index on the EMPLOYEE table that resides in the
EMPLOYEE tablespace. In this scenario, the INVENTORY_DATA and
INVENTORY_INDEXES tablespaces could not be transported together. This
stands to reason, since once the tablespaces are moved over, you would have an
index without an associated table.
The issue of integrity constraints can play a role in determining if a tablespace set
is self-contained. If you decide to transport the tablespaces with constraints
enabled, and one or more tables have referential constraints to tables outside the
tablespace set, then the transport will not be allowed. If you decide you want to
transport the tablespaces anyway, you can do so with the constraints disabled.
However, be very careful when doing this, as this could lead to an inconsistent
set of data in the tablespaces being transported.

To determine if a tablespace set is self contained, you would use the DBMS_TTS
package. This package contains the TRANSPORT_SET_CHECK procedure,
which is passed the list of tablespace names. You would also specify whether or
not you want to transport the tablespaces with constraints enabled or disabled.
Once this procedure is executed, you can query the TRANSPORT_SET_ VIOLA-
TIONS view to see if there are any dependency violations. If this view returns no
rows, then the tablespace set is self-contained. If there are violations, this view
will show detailed descriptive information about which objects caused the
violations. The following shows a sample statement to execute the
TRANSPORT_SET_CHECK procedure to determine if the INVENTORY_DATA
and INVENTORY_INDEXES tablespaces are self-contained.
EXECUTE
dbms_tts.transport_set_check('inventory_data,inventory_indexes',TRUE)
In this example, the names of the tablespaces are passed together as a single
argument enclosed in single quotes. The value TRUE is also passed to specify
that the tablespaces are to be transported with constrains enabled.
After the TRANSPORT_SET_CHECK procedure is complete, querying the
TRANSPORT_SET_VIOLATIONS view will show dependency violations if any.
The following shows a sample output from this view.
VIOLATIONS
----------------------------------------
Constraint SYS.FK_ITEM_VENDOR_ID between
table SYS.ITEM in tablespace
INVENTORY_DATA and table SYS.VENDOR in
tablespace VENDOR
This output shows that the ITEM table in INVENTORY_DATA has a foreign key
constraint to a table that resides in a tablespace not included in the tablespace set.
If you leave the constraints enabled, you will not be allowed to transport this set
of tablespaces.
Once you have determined that a set of tablespaces are self-contained, you must
set the tablespaces to read-only with the ALTER TABLESPACE command. This
is to ensure that the tablespace remains self-contained during the transporting
process. The syntax to set a tablespace in read-only mode is shown here.
ALTER TABLESPACE tablespace_name READ ONLY;
Once the tablespaces are set to read-only, you can use the export utility to create
the dictionary file that contains the required tablespace metadata. The following
shows an example export command to transport the INVENTORY_DATA and
INVENTORY_INDEXES tablespaces.
exp transport_tablespace=y tablespaces=(inventory_data,⇒
inventory_indexes) constraints=n file=d:\export\inv_tts.dmp
Notice in this example that the command includes the argument
constraints=n. This specifies that the tablespace will be transported without
referential integrity constraints. This is because we found a dependency violation
between the ITEM and VENDOR tables. Once this command is issued, the
export utility will prompt for a user name and password. A tablespace-level
export can only be done by a user with the SYSDBA role. Once logged in, the
export utility will export the metadata and generate the dictionary file. After the
dictionary file is created, the tablespaces can be set back to read-write. While this
is not required to transport tablespaces, the data will not be modifiable by users
while the tablespace is read-only.

The datafiles and dictionary file can now be transported over to the target system.
You can place the datafiles in any directory you like; you will specify their new
locations as part of the import process. Once copied over, the import utility is
used to import the dictionary file into the target database. The following shows a
sample import command to “plug-in” our inventory tablespaces.
imp transport_tablespace=y datafiles=þ
'd:\oracle\oradata\ora92\inv_data01.dbf',⇒
'd:\oracle\oradata\ora92\inv_indx01.dbf' ⇒
tablespaces=inventory_data,inventory_indexes ⇒
file=d:\import\inv_tts.dmp
As shown in this example, the datafiles are stored in the d:\oracle\oradata\ora92
directory on the target server. The file argument lists the path and file name of the
dictionary file that contains the tablespace metadata. Once the metadata is
imported, the tablespaces are now part of the new database. The tablespaces are
initially imported as read-only, and can be set to read-write if necessary.
TASK 6B-3
Transporting a Tablespace
Objective: To transport a tablespace using the export and import utilities.
1. The transportable tablespace feature was designed to provide a way to move

a tablespace between two databases fairly quickly. Since you only have a
single database on your system, you will simulate this behavior by generat-
ing a transportable tablespace set for the RMAN tablespace, dropping the
tablespace, then importing it back in.
To determine the current status of the RMAN tablespace, issue the follow-
ing query:
SELECT tablespace_name, status
FROM dba_tablespaces
WHERE tablespace_name='RMAN';

The output will show that the RMAN tablespace is currently online and
available for general use.
2. Before transporting a set of tablespaces, you must ensure that the tablespace
set is self-contained. This is done with the TRANSPORT_SET_CHECK pro-
cedure of the DBMS_TTS package.

EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('RMAN')
Oracle will display the message “PL/SQL procedure successfully

completed.”
3. If the TRANSPORT_SET_CHECK procedure finds any issues with the list

of tablespaces specified that would prevent you from transporting the
tablespaces together, it populates the TRANSPORT_SET_VIOLATIONS
view with pertinent information about those issues.
To determine if any issues were discovered, issue the following query:

SELECT *
FROM transport_set_violations;
Oracle will display the message “no rows selected.” This indicates that there
are no dependencies between the objects in the RMAN tablespace and

objects in other tablespaces, so the RMAN tablespace can be transported.
4. Before transporting a tablespace, the tablespace must be in read-only mode.
At the prompt, type ALTER TABLESPACE rman READ ONLY; and press
Enter.
To confirm that the tablespace is in read-only mode, issue the following

query again:
The output will show that the RMAN tablespace is indeed in read-only
mode. The tablespace is now ready for transport.
5. Leaving the SQL*Plus window open, open a command prompt.
At the prompt, generate a transportable tablespace export file by issuing

the following command as if it was a single input line:
file=C:\079176\tts_ora92_rman.dmp ⇒
log=C:\079176\tts_ora92_rman.log ⇒
transport_tablespace=y tablespaces=rman
Once you press Enter, the export utility will begin to extract the metadata
information for the RMAN tablespace and it’s contents. However, no data
from the tables in the RMAN tablespace will be exported.
Once the export is complete, the tts_ora92_rman.dmp file contains all the
information necessary to import the RMAN tablespace into another database.
The export file and all datafiles for the tablespace can be copied to another
server, and the tablespace can be imported.
6. Because your system has only one database, you will assume that the
datafile and export file have both been copied to another system, and you are
about to import the tablespace into another database. However, before
importing the tablespace, you must first drop the existing RMAN tablespace
from the database.
Leaving the command prompt open, switch back to the SQL*Plus window.
At the SQL*Plus prompt, type DROP TABLESPACE rman INCLUDING

CONTENTS; and press Enter.

Oracle will display the message “Tablespace dropped.”
To confirm that the RMAN tablespace has been dropped, issue the following
query again:
Oracle will display the message “no rows selected.” The RMAN tablespace
no longer exists in the database.
7. You will now use the export file you just created to import the RMAN
tablespace into the database.
Switch back to the command prompt.
At the command prompt, issue the following command as if it were a

single input line:
imp userid='sys/ora92@ora92 as sysdba' ⇒
file=C:\079176\tts_ora92_rman.dmp ⇒
log=C:\079176\ts_ora92_rman_imp.log ⇒
transport_tablespace=y tablespaces=rman ⇒
datafiles=D:\oracle\oradata\ora92\rman01.dbf
Once you press Enter, the import process will begin. The output may look as
if individual tables were being imported, however only the metadata con-

cerning those tables are imported into the data dictionary.
Once the import is done, the last line of the output will state “Import termi-
nated successfully without warnings.” Close the command prompt.
8. You will now confirm that the RMAN tablespace has been imported as
expected.
At the SQL*Plus prompt, issue the following query again:

The output will show that the RMAN tablespace has been imported and is
currently still set to read-only.
9. To set the tablespace back into read-write mode, type ALTER

TABLESPACE rman READ WRITE; and press Enter.
10. You have successfully transported a tablespace from one database to another.
Exit from SQL*Plus.

Apply Your Knowledge 6-1 Suggested Time:
2 hours
LAB: Table Recovery After User Error
Objective: To recover a table after a user accidentally deletes all the rows
in a table.
See Additional Instructor
Setup: Open a window to the C:\079176 folder. Double-click the file Notes.
named final_setup. A blank command prompt window will
appear for several moments, then disappear. Close the
C:\079176 window.
You are the DBA for a database that currently supports an application that
has been in development for several weeks, and the application is scheduled
to go live tomorrow. However, a developer calls you to say that he has acci-
dentally deleted all 50,000 rows from the SH.CUSTOMERS table, and
committed the transaction. He states that the contents of the table are abso-
lutely critical for the application and must be recovered at all costs.
Your task is to recover the contents of SH.CUSTOMERS table. You may use
any skills and techniques you have learned throughout this course, as well as
any resources available on your system. The recovery of the
SH.CUSTOMER table contents is of the highest priority; the content of any
other user tables in the database is irrelevant. Your first steps should include
making a list of possible recovery methods, and identifying which method is
best for this scenario.
While attempting to recover the table, you may encounter other issues with
the system. These issues may involve any aspect of the system, including the
operating system, disk media, Oracle installation, datafiles, and/or client and
server configurations. If you do encounter any other issues, you should
research, identify, and resolve those issues as quickly as possible so you can
move towards your immediate goal of recovering the table.
Once you believe that you have successfully recovered the

SH.CUSTOMERS table, be sure to issue a query to ensure that all 50,000
rows have indeed been recovered. If your recovery was not successful, or if
you lose the database completely, consult your instructor for further
direction.
Summary
In this lesson, you learned how to move large volumes of data quickly by
using Oracle-provided utilities. You learned how to use SQL*Loader to bulk
load data from flat ASCII files into the database. You also learned how to
perform direct-load inserts from one table to another, and you learned how
to create external tables to access data outside of the database through a
table-like structure inside the database. You learned to use the export utility
to export data from the database into a binary file, and then import it back
in using the import utility. Finally, you learned how to move entire
tablespaces by using Oracle’s transportable tablespace feature.

Lesson Review
6A While loading data with SQL*Loader, if a row causes an error, which
file is the row copied to?
a. Discard file
✓ b. Bad file
c. Recycle bin
d. Exceptions file
True or False? SQL functions can be applied to data while it is being

loaded with a conventional path using SQL*Loader. Explain your
answer.
True. During conventional path loading, SQL*Loader will generate a stan-
dard INSERT statement to pass to the database to load each row, which can
include SQL functions. During a direct path mode, the SQL processing
engine is bypassed, and the data is inserted directly into the target table.
Therefore, SQL functions are not allowed during a direct path load.
When loading data with SQL*Loader, which control file option can be
used to load data in to an empty table? Choose all that apply.
✓ a. INSERT
✓ b. APPEND
✓ c. REPLACE
✓ d. TRUNCATE
If the data to be loaded resides in the same file as the control file syntax,
how should the INFILE clause be specified?
a. INFILE=true
✓ b. INFILE *
c. INFILE
d. It should be omitted
Your SQL*Loader control file contains the BADFILE clause, and the
command you are using at the command prompt contains the BAD
argument. Which one will be used to determine the name and location
of the bad file?
✓ a. The command line
b. The control file
c. Both will be ignored
d. An error will be returned

True or False? To improve the performance of a query that executes
against an external table, you can add an index that supports the WHERE
clause of the query. Explain your answer.
False. You cannot create an index on an external table. If performance
becomes a factor, you can execute the query in parallel.
6B True or False? You can export tables from multiple schemas

simultaneously. Explain your answer.
True. By performing a table-level export, you can export a combination of
tables from different schemas at the same time.
True or False? A transportable tablespace export will export all objects

that exist in a single tablespace.
False. For a transportable tablespace export, no data from the source
tablespace is actually exported. The export utility exports only the required
information from the data dictionary relevant to the tablespace.
The following export command results in an error. Why?

exp userid=sys/oracle file=d:\oracle\sample.exp ⇒
direct=y owner=james tables=order,item,billing ⇒
recordlength=10240
The owner argument is used for a user-level export, while the tables
argument is used for a table-level export. These two arguments cannot be
used together.
Which procedure of the DBMS_TTS package is used to determine if a

set of tablespaces is self-contained?
a. TRANSPORTABLE_TABLESPACE
b. IS_SELF_CONTAINED
✓ c. TRANSPORT_SET_CHECK
d. TRANSPORT_SET_VALID
True or False? The datafiles of a tablespace that are being transported

do not need to reside in the same directory structure on the target
server as on the source server. Explain your answer.
True. The datafiles can be stored anywhere on the target server. The new
locations of the datafiles are specified as part of the import process.

ADDITIONAL INSTRUCTOR NOTES
LESSON 6
Topic 6B
The final_setup file launches the go.exe executable. This executable makes changes to the state of the system
which will cause the students to encounter several issues while attempting to recover the SH.CUSTOMERS table.
The go.exe executable makes the following changes:
• All rows in the SH.CUSTOMERS table are deleted, and commit is issued.
• The instance is aborted with the SHUTDOWN ABORT command.
• All copies of the current control file are deleted.
• The EXAMPLE01.DBF datafile is deleted.
• The primary listener is stopped.
In order to bring the database to a state where the SH.CUSTOMERS table can be recovered, the students must:
1. Restart the listener.
2. Manually restore all copies of the control file from the control file image copy created in Task 5B-2, step 15.
3. Use RMAN to restore the EXAMPLE01.DBF datafile from the backup set created in Task 5B-2, step 14. This
must be done while RMAN is connected to the control file as the repository.
Once the students have reached this point, the best course of action is to perform a tablespace point-in-time
recovery of the database to the SCN just prior to the DELETE statement that was issued to delete all the rows
from the SH.CUSTOMERS table. That would ensure that all data, including the most recent transactions, have
been recovered with the exception of the DELETE statement. In the current environment, the furthest the students
are expected to get is to restore the database to the last log sequence number prior to the current redo log. The
students would get extra kudos if they mention using the LogMiner utility to extract the last transactions from
the current redo log, although they are not expected to perform this task.
After restoring the datafiles, if the students perform an incomplete recovery using all redo logs, and open the
database with the RESETLOGS option, they will notice that the SH.CUSTOMERS table is still empty. This is
because the redo information related to the DELETE statement is included in the current redo log file.
If some students seem to have difficulty performing a tablespace point-in-time recovery, it is acceptable to apply
all redo information, including the current redo log, open the database with the RESETLOGS option, then import
the SH.CUSTOMERS table from either the exp_ora92_full.dmp or exp_ora92_wildcard.dmp export files created in
Task 6B-2. Although this will not guarantee that the latest transactions are included in the restored table, the
table can be restored to its last known good state, and any outstanding transactions can either be manually
applied, or extracted from the redo and archive logs using LogMiner and then applied. To reiterate, it is not
expected that the students use LogMiner to extract and apply redo information, but if it is at least mentioned,
this is considered a bonus.
Additional Instructor Notes 365

GLOSSARY
application program interface client-server architecture
An interface provided by a software vender A configuration where multiple clients con-
that accepts procedural calls from a custom nect to a single server.
application to the vendor’s software.
clone database
archive log A database created by restoring and recov-
A copy of a redo log that has been filled ering the hot backup of another database to
and switched out as the current log group. another location.
Archive logs are used to apply changes to
a backup to bring it up to date during cold backup
recovery. A full backup of the database while the
database is shut down.
backup mode
A special mode for tablespaces that allows communication channel
them to be copied while the database is up A dedicated connection between RMAN
and running. and the target database
backup set complete recovery

A logical object created by RMAN that A database recovery where all changes to
contains multiple backup pieces. Each the database are recovered right up to the
backup piece contains one or more original point of failure.
files from the target database.
connect descriptor
before image The full connection definition for a net ser-
The original version of data before it was vice name.
changed by a transaction.
connection pooling
bequeath connection The technique of pooling multiple client
A single-task database connection where connections into a group of fewer database
the client and server reside on the same connections.
machine.
conventional path load
BMR A method of loading data into Oracle using
(Block Media Recovery) A feature that standard SQL calls.
allows RMAN to recover only corrupt
CORBA
blocks in a datafile, rather than the entire
(Common Object Request Broker Architec-
datafile.
ture) Architecture that provides an industry-
centralized naming wide standard of accessing various types of
A names resolution method that stores all data sources through a network
the connect descriptors in a centrally-
crosscheck
located repository. All clients needing to
A process of validating recovery catalog
resolve connect descriptors contact the cen-
entries against the backup files that actually
tral repository.
exist in the file system.
checksum
dead connection detection
A hash value generated by reading a single
A feature of Oracle Net that automatically
piece of data.
detects terminated client sessions and
handles the release of database resources.
Glossary 367
GLOSSARY
direct load insert hot backup
A method of loading data from one table to A backup of the database, either full or
another using a direct path load. partial, performed while the database
remains up and running.
direct path load
A method of loading data into Oracle that IIOP
writes directly to the datablocks in the (Internet Inter-ORB Protocol) A presenta-
datafiles, bypassing the SQL processing tion protocol designed to implement
engine. CORBA technologies across the Internet.
dispatcher image copy

A background process in a shared server A type of backup file created by RMAN
configuration that accepts database requests which is a bit-for-bit image of the original
from user processes and passes them to file.
shared server processes.
incarnation
DNS A new version of a database created when
(Domain Names System) A server that is the database is opened with the
used to resolve matching host names to RESETLOGS option.
their respective IP addresses.
incomplete recovery
external naming A database recovery where not all changes
A names resolution method similar to to the database are recovered.
external naming, except the central reposi-
tory is a non-Oracle, third-party product. incremental backup
A backup of the database that includes only
external table the datablocks that have changed since a
A table-like structure in Oracle that previous incremental backup instead of all
accesses an external flat file containing datablocks that contain data.
data.
Java Database Connectivity
global database name An industry standard connectivity interface
A database identifier to uniquely identify a for applications that make use of Java pro-
single database on a network. gramming on the client to connect to a
database source, also known as JDBC.
heterogeneous connectivity
A feature that allows an Oracle client to listener
use standard Oracle SQL and procedure A constantly running process that listens on
calls to seamlessly access non-Oracle data the network for incoming connection
sources. requests.
host naming local naming

A names resolution method that uses the A names resolution method that is used to
client’s HOSTS file to locate the target resolve net service names by looking up
database on the network. their connect descriptors in a definition file
stored locally on the client’s machine.

GLOSSARY
MML Oracle Net tracing
(Media-management layer) Third-party A feature that, when enabled, allows Oracle
backup utilities that can integrate with to write out to a trace file every internal
RMAN to help perform backup and recov- step taken to establish a database connec-
eries of the database. tion, usually generates much more detailed
output than standard logging.
MTBF
(Mean time between failures) The average PGA
amount of time that passes between failures (Program Global Area) The memory area at
of a system. the OS level on the server that stores a
user’s session data while the user is con-
MTTR nected to the database.
(Mean time to recovery) The average
amount of time it takes to recover a system recovery catalog
after a failure. A database schema that can act as the
backup and recovery information repository
multi-protocol connectivity for RMAN.
A configuration that supports several differ-
ent client protocols to connect to a single retention policy
database. The policy used by RMAN to determine
which database backups in its recovery
N-tier configuration catalog are still valid.
A multi-level configuration where each
component of a system, such as client, SCN
application, and database, resides at its own (System Change Number) A sequential
tier. numbering system Oracle uses to track
every change in the database.
names resolution method
A configured method that is used to trans- shared server process
late a net service name to the network A single server process that can support
address where the intended database database requests from multiple clients
resides. simultaneously.
net service name single-task connection

An alias for a destination database a client A connection where the client user and
wishes to connect to. server process are one in the same.
network stack system identifier

A series of layers that a network connec- The identifying name for a database.
tion between a client and server must pass
through. tnsping utility
A utility that is used to time the round trip
Oracle Net logging of a network packet from the client to the
A feature that, when enabled, allows Oracle listener and back.
to log all informational entries to a speci-
fied log file for troubleshooting purposes.
Glossary 369
GLOSSARY
transportable tablespace
An Oracle feature that allows you to copy
an entire tablespace from one database to
another by simply exporting the tablespace
metadata from the data dictionary.
trial recovery
A test recovery of the database that is used
to determine whether or not a real recovery
will be successful.
UGA
(User Global Area) The memory area at the
OS level on the server that exists only in a
shared server configuration.
undo segments
Database segments that temporarily hold
the original versions of changed data from
a transaction in case the transaction needs
to be rolled back and the original version
replaced.

INDEX
3DES encryption definition, 101-103
See: Advanced Security Option complete recovery
See: recovery
A connect descriptor, 9, 10
Advanced Security Option Connection Manager
3DES encryption, 20-22 connection pooling, 18-20
DES encryption, 20-22 multi-protocol connectivity, 18-20
RC4 algorithm, 20-22 connection pooling
archive logs See: Connection Manager
backing up with RMAN, 252-254 connection process
ARCHIVELOG mode See: user connection process
configuring, 127-135 control file, 111, 210-212, 298-300, 209-213
archiver (ARCH) process, 109 Also see: RMAN
loss of, 180-188
B CORBA, 87-90
backup
cold, 114-120
D
cold, RMAN, 236-243 database writer (DBWR) process, 110-111
control file, 148-153 DES encryption
hot, 127-135 See: Advanced Security Option
hot, RMAN, 243-245 direct load inserts, 329-333
read-only tablespaces, 153-154 dispatcher process, 76-77, 81-82
resolving failed hot backup, 154-158
RMAN, 236-243 E
user-managed, 142-147 export
backup sets types, 342-344
See: RMAN external naming
bequeath connection See: names resolution methods
See: user connection process external tables, 333-341
block corruption, 168-171
Also see: block media recovery F
Block Media Recovery failures
See: BMR instance failure, 98
block media recovery (BMR), 295-296 media failure, 98
Also see: RMAN session failure, 97
BMR, 295-296 statement, 96
transaction failure, 96-97
C
centralized naming G
See: names resolution methods GIOP, 87-90
checkpoint (CKPT) process, 110
client-server architecture, 3-6
cold backup
H
heterogeneous connectivity, 22-23
Index 371
INDEX
host naming creating manually, 42-46
See: names resolution methods Also see: Listener Control utility (lsnrctl)
hot backup Listener Control utility (lsnrctl), 35-41
definition, 101-103 local naming
HTTP/FTP presentations See: names resolution methods
See: layered architecture log writer (LGWR) process, 109
logging
I Oracle Net, 66-68
IIOP, 87-90 lsnrctl
image copies See: Listener Control utility (lsnrctl)
See: RMAN
import M
types, 348-352 media failure
incomplete recovery See: failures
See: recovery media recovery
incremental backups See: recovery
See: RMAN MTBF, 100-105
inserts MTS
direct load, 329-333 See: Oracle Shared Server
instance failure MTTR, 100-105
See: failures multi-protocol connectivity
instance recovery See: Connection Manager
See: recovery Multi-threaded Server
See: Oracle Shared Server
J
Java client communication stack N
See: layered architecture N-tier architecture, 3-6
Java thin client, 15-16 names resolution methods
JDBC, 15-16 centralized naming, 46-49
external naming, 46-49
L host naming, 46-49
layered architecture local naming, 46-49, 55-64
Java client communication stack, 15-16 net service name, 9, 10
OCI layer, 13-15 networking
OPI layer, 13-15 client-side configuration, 46-49
Oracle communication stack, 13-15 server-side configuration, 25-35
Oracle communications stack, 12-18 troubleshooting, 64-74
Web client communication stack, 16-17 Also see: tnsping utility
Listener Control utility (lsnrctl), 35-41 Web client configuration, 87-90
listener process, 11 Also see: layered architecture
configuring for Web clients, 87-90
Also see: layered architecture
creating, 25-27

INDEX
O , 171-176
RMAN
Oracle communications stack
architecture, 207-209
See: layered architecture
archive logs, 252-254
Oracle Net
backup sets, 217-219
components, 5-6
backup validation, 275-276
logging, 66-68
backups, 236-243
tracing, 66-68
block media recovery (BMR), 295-296
Oracle Shared Server, 74-80
cataloging OS-level backups, 272-274
configuring, 80-83
complete recovery, 286-292
monitoring and tuning, 83-87
configuration parameters, 229-235
OSS
configuring, 219-222
See: Oracle Shared Server
crosscheck, 266-272
deleting backup sets, 266-272
R hot backups, 243-245
RC4 algorithm image copies, 217-219, 238-239
See: Advanced Security Option incomplete recovery, 297-301
read-only tablespaces, 196-199 incremental backups, 245-252
recovery lists, 259-266
cold, 114-120, 127-135 loss of control file, 298-300
complete, 104 loss of current log group, 301-308
complete, RMAN, 286-292 process flow, 213-217
hot, 135-138 recovery catalog, 212, 222-226, 254-259, 277-279
incomplete, 104, 177-178 registering a database, 227-229
incomplete, repercussions, 178-179 reports, 259-266
incomplete, RMAN, 297-301 repository, 209-213
loss of control file, 180-188, 298-300 restore, 286-287
loss of current log group, 189-196, 301-308 restore validation, 275-276
no backup, 172 tablespace point-in-time recovery, 308-314
read-only tablespaces, 196-199
structures, 105-114 S
trial recovery, 168-171
session failure
user-managed, 142-147
See: failures
user-managed, complete, 159-168
shared server process, 76-77, 82
user-managed, incomplete, 176-180
single-task connection
recovery catalog
See: user connection process
See: RMAN
SQL*Loader, 318-329
backing up, 277-279
commands, 323-324
stored scripts, 254-259
control file, 319-321
redo log, 301-308
datafile formats, 321-323
loss of current group, 189-196
statement failure
redo log buffer, 107
See: failures
redo log files, 107-108
system monitor (SMON) process, 109
restoring datafiles
Index 373
INDEX
T
tablespace point-in-time recovery
RMAN, 308-314
user-managed, 200-201
tnsping utility, 50
tracing
Oracle Net, 66-68
transaction failure
See: failures
transparent gateway, 22-23
transportable tablespaces, 353-361
Also see: export
Also see: import
trial recovery, 168-171
Also see: block media recovery
TSPITR
See: tablespace point-in-time recovery
two-task connection
See: user connection process
U
undo segments, 106-107
user connection process, 7-12
bequeath connection, 7-12
Oracle Shared Server, 76-77
W
Web client communication stack
See: layered architecture
Web client configuration, 87-90

Oracle 9i DBA Fund - II

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle 9i DBA Fund - II

Uploaded by

Copyright:

Available Formats

INSTRUCTOR’S EDITION

ii Oracle9i Database: Fundamentals II

LESSON 1: ORACLE NETWORKING

Topic 1B Basic Oracle Net Server-side Configuration . . . . . . . . . . . . . . 25

Topic 1C Basic Oracle Net Client-side Configuration . . . . . . . . . . . . . . 46

Topic 1D Oracle Shared Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

iv Oracle9i Database: Fundamentals II

LESSON 2: BACKUP AND RECOVERY OVERVIEW

Topic 2B Cold Backup and Recovery Concepts. . . . . . . . . . . . . . . . . . . .114

Topic 2C Hot Backup and Recovery Concepts . . . . . . . . . . . . . . . . . . . .127

LESSON 3: USER-MANAGED BACKUP AND RECOVERY

Topic 3B User-managed Complete Recovery . . . . . . . . . . . . . . . . . . . . .159

Topic 3C User-managed Incomplete Recovery. . . . . . . . . . . . . . . . . . . .176

LESSON 4: RECOVERY MANAGER BACKUPS

Topic 4B Configuring the RMAN Environment . . . . . . . . . . . . . . . . . . . .219

Topic 4C RMAN Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236

Topic 4D RMAN Catalog Maintenance and Management . . . . . . . . . . . .254

vi Oracle9i Database: Fundamentals II

LESSON 5: RECOVERY MANAGER RECOVERIES

Topic 5B RMAN Incomplete Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . .297

LESSON 6: LOADING AND MOVING DATA

Topic 6B The Export and Import Utilities . . . . . . . . . . . . . . . . . . . . . . .341

Additional Instructor Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365

• Describe and configure the Oracle Network Environment.

COURSE SETUP INFORMATION

About This Course ix

Insert the Oracle9i (9.2.0.1.0) Enterprise Edition CD in the CD-ROM drive.

x Oracle9i Database: Fundamentals II

7. The Database Configuration screen asks you to select a database suited to

Note: The entire installation process could take 30 to 45 minutes or more,

About This Course xi

17. Choose File→Exit to close the OEM Console.

xii Oracle9i Database: Fundamentals II

List of Additional Files

HOW TO USE THIS BOOK

About This Course xiii

1A Describe the features of the Oracle9i network environment.

1B Configure the database server to accept incoming network

1C Configure a client to connect to an Oracle9i database through the

1D Describe and configure Oracle Shared Server.

Lesson 1: Oracle Networking 1

2 Oracle9i Database: Fundamentals II

Figure 1-1: Client-server architecture.

Lesson 1: Oracle Networking 3

Figure 1-2: N-tier architecture.

4 Oracle9i Database: Fundamentals II

Oracle Net Components

Lesson 1: Oracle Networking 5

2. In an N-tier configuration, what is the purpose of the middle tier?

3. What is the purpose of the Oracle listener?

6 Oracle9i Database: Fundamentals II

Figure 1-3: Single-task and two-task configurations.

Lesson 1: Oracle Networking 7

8 Oracle9i Database: Fundamentals II

Step 1: The User Initiates a Connection Request

Lesson 1: Oracle Networking 9

10 Oracle9i Database: Fundamentals II

Step 4: The Listener Determines Request Destination

Step 5: The Client Connects to the Database

Lesson 1: Oracle Networking 11

3. What is the role of the listener in establishing a database connection

Oracle Net Layered Architecture

12 Oracle9i Database: Fundamentals II