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

3 6 7 12 12 17 18 24

Topic 1B

25 28 35 37 42 42

Topic 1C

46 48 49 51 55 57 64 68

Topic 1D

74 77 80 83 83 86

Oracle9i Networking Overview . . . . . . . . . . . . . . . . . . . . . . . . Task 1A-1 Describe Oracle Net Architecture . . . . . . . . . . . . . . . . . . . . The User Connection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1A-2 Identify the Steps in the User Connection Process . . . . . . . . Oracle Net Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1A-3 Describe Oracle Net Layered Architecture . . . . . . . . . . . . . . . Additional Networking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1A-4 Identify Additional Networking Options . . . . . . . . . . . . . . . . Basic Oracle Net Server-side Configuration . . . . . . . . . . . . . . Task 1B-1 Configuring the Listener Process . . . . . . . . . . . . . . . . . . . . The Listener Control (lsnrctl) Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1B-2 Using the Listener Control (lsnrctl) Utility . . . . . . . . . . . . . . Configure the Listener Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1B-3 Configuring the Listener Manually . . . . . . . . . . . . . . . . . . .

Basic Oracle Net Client-side Configuration . . . . . . . . . . . . . . Task 1C-1 Identify Names Resolution Methods . . . . . . . . . . . . . . . . . . Configure Host Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1C-2 Configuring Host Naming . . . . . . . . . . . . . . . . . . . . . . . . . Configure Local Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1C-3 Configuring Local Naming . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting Connection Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1C-4 Configuring Client and Server Tracing . . . . . . . . . . . . . . . . . Oracle Shared Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1D-1 Describing Oracle Shared Server Architecture . . . . . . . . . . . . Configuring Oracle Shared Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task 1D-2 Configure Oracle Shared Server. . . . . . . . . . . . . . . . . . . . . . Monitoring and Tuning Oracle Shared Server . . . . . . . . . . . . . . . . . . . . Task 1D-3 Describe Methods to Monitor and Tune Oracle Shared Server. .

iv

Oracle9i Database: Fundamentals II

Configuring the Listener for Web Clients . . . . . . . . . . . . . . . . . . . . . . . 87 Task 1D-4 Configure the Listener for Web Clients. . . . . . . . . . . . . . . . . 90 Lesson Review 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

CONTENTS

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 Backing Up the Recovery Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Task 4D-6 List and Describe Methods to Back Up the Recovery Catalog . 279 Lesson Review 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

CONTENTS

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 This course introduces the concepts of Oracle9i® network configuration and database backup and recovery. You will learn how to configure the Oracle9i network 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 Oracleprovided utilities. This course helps prepare students for Oracle’s exam, Oracle9i Database: Fundamentals II (1Z0-032).

ABOUT THIS COURSE

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 hardware 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.

This course will normally refer to the D:\oracle drive. In reality, you may be using the D drive, the E drive, or some other drive letter. If your Oracle partition is declared as a letter other than D, you will need to replace the references in this manual with your respective drive letter.

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 least two partitions. One partition should be designated as the C drive for the operating system software. The system drive should be at least 2 GB in size and formatted as either FAT or NTFS. The second partition should be designated as the D drive and reserved for the Oracle installation. This drive needs to be at least 8 GB and formatted as either FAT or NTFS.

2.

Once the computer’s operating system is fully installed and configured, start Windows 2000 Professional and log on as Administrator. 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 Welcome screen displayed on the screen. Click Install/Deinstall Products, and the Oracle Universal Installer will begin loading.

3. x

Oracle9i Database: Fundamentals II

Once the installer loads, you will see the Welcome screen. Click Next.

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 window 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 listen 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 settings 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 automatically 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 Universal 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 Databases 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 database, 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. xii

Oracle9i Database: Fundamentals II

Insert the CD-ROM that accompanies this course into the CD-ROM drive.

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. Topics 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 willing 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

1 Overview Oracle’s networking environment, called Oracle Net, enables connectivity between clients and database servers, and also between multiple database servers, thereby enabling distributed enterprise level database applications. In this lesson, you will learn about the features provided by Oracle Net and 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.

Data Files none Lesson Time 4 hours, 25 minutes

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 connection 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 sitting 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 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 mainframe and providing the best of both worlds. A user could sit at his or her own desk and use the PC to log in to the mainframe. This is known as client-server architecture or two-tier architecture. The PC acts as the client, while the mainframe acts as a server. Most often, there would be a single server with multiple 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 clientserver architecture.

Client-server Architecture

client-server architecture: A configuration where multiple clients connect to a single server.

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,

Lesson 1: Oracle Networking

3

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 versions of client software made it almost impossible to manage a large number of clients. N-tier Architecture

N-tier configuration: A multi-level configuration where each component of a system, such as client, application, and database, resides at its own tier.

As companies continued to grow, so did the requirements and expectations of 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 their maximum use. The solution began as a fairly simple one, but revolutionized the way systems are designed and built, separating each component of the system into its own tier. This became known as a multi-tier or N-tier configuration. The N represents a number, meaning an N-tier architecture can be made up of three, four, or more tiers as requirements dictate. In a 3-tier architecture, the database 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 contains all the program code required to run the application. Users on the client machines issue simple commands to the application, which connects to the database 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

4

Oracle9i Database: Fundamentals II

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 database 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 challenge 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 applications 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 protocols 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 transparent gateway.

Lesson 1: Oracle Networking

5

dead connection detection: A feature of Oracle Net that automatically detects terminated client sessions and handles the release of database resources.

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 of database resources the session was using (for example, locks and latches). Oracle Net’s tracing and diagnostic tools will be covered in more detail later in the course.

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 program 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.

6

Oracle9i Database: Fundamentals II

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 processes are one and the same; the user is connected directly to the database, and the connection happens in a single task. The request is made and the connection 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 the user connects to the database. If an error occurs during the connection process or the connection is lost, then the user must submit the request again. Figure 1-3 shows the difference between a single-task connection and a two-task connection.

Single-task and Two-task Configurations

single-task connection: A connection where the client user and server 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

Lesson 1: Oracle Networking

7

Figure 1-4: The user connection process.

bequeath connection: A single-task database connection where the client and server reside on the same machine.

Connection Request Path

8

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 bequeathed, a connection. This type of connection is made when the user connects to the database from the very same machine where the database resides. You can also see in Figure 1-4 that a two-task connection requires some additional 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 database in a timely fashion. Regardless of networking environment, when a client 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.

Oracle9i Database: Fundamentals II

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 destination database the client wishes to connect to. Following is an example connect string from someone using a net service name: sqlplus scott/tiger@dev

net service name: An alias for a destination database a client wishes to 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 information to specify a destination service or the means to reach this service. Instead, this net service name maps to a fully qualified connect descriptor, and is resolved during the connection process.

connect descriptor: The full connection definition for a net service name.

Lesson 1: Oracle Networking

9

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 descriptor 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 network it can find an appropriate listener process. In this case, the client would contact the DEV01.COMPANY1.COM server at port number 1521.

10

Oracle9i Database: Fundamentals II

Step 3: The Connection Request is Sent to the Listener Once the connect descriptor is resolved, the client now has the address of a listener 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 listener 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 information specified by the CONNECT_DATA entry. The CONNECT_DATA tells the listener the service name of the database the client would like to connect to and may also include additional connection-specific information required by the client. A service name may or may not be the actual name of its database; it is simply another alias which the listener will use to uniquely identify the database on the network. Oracle makes use of a database service name to allow multiple databases on the same network with identical system identifiers (SIDs). For example, you could have two databases on the same network that both have SIDs called DEV. Since the listener identifies each database by its service name only, and not the SID, the listener process will be able to tell them apart as long as the service names are different.

Do not confuse the net service name with the service name. The net service name refers to the connect string that a client would use to determine where the appropriate listener resides on the network. The service name refers to the target database and is set by the database’s SERVICE_NAMES initialization parameter.

Step 4: The Listener Determines Request Destination Once the listener receives a connection request and is passed the service name from the connect descriptor, the listener process will perform a quick lookup in its configuration to determine the location on the network where the appropriate 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 different server.

system identifier: The identifying name for a database.

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 database 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 communicate 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.

Lesson 1: Oracle Networking

11

TASK 1A-2 Identify the Steps in the User Connection Process 1.

True or False? Connect descriptors can be specified directly on the connect 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 connection 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 Oracle Communications Stack

network stack: A series of layers that a network connection between a client and server must pass through.

12

When a client is connected to the database, whether that client be an end user machine or an application server, all communications between the client and the 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 before passing the message to the next layer. Figure 1-6 shows the standard Oracle client communication stack. The layers that come into play for each connection will depending on the type of connection and the connection protocol used.

Oracle9i Database: Fundamentals II

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 connect 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 network open to the general public, rather than within a closed-circuit local area network. These security services provide the ability to encrypt database connections 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, without requiring name resolution. The OPI layer on the database side stands for Oracle Program Interface and performs the same function in that it provides the interface for connections on the network to access the database. The main difference between the OCI and OPI layers is that the OCI layer is designed to allow interaction with a custom application. Oracle even provides the appropriate procedural 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.

application program interface: An interface provided by a software vender that accepts procedural calls from a custom application to the vendor’s software.

Lesson 1: Oracle Networking

13

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 application needs to be transported from one machine or network to another. The presentation layer handles translation between client and servers with different 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 understood 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 Network Substrate (TNS). The TNS enables direct computer-to-computer connections regardless of the network protocol used, without requiring additional communication 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 handling 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 support 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. Currently, 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 foundation layer and Oracle protocol support layer. The network protocol layer is actually the network itself. Once the Oracle protocol 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 configured, 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 standard TNS request before forwarding it up the database’s communication stack. 14

Oracle9i Database: Fundamentals II

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 connection 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 networking 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 database through a JDBC driver. JDBC stands for Java Database Connectivity and is an industry standard connectivity interface for applications that make use of Java programming on the client. In order for an application to make calls through JDBC, the client machine must have the appropriate JDBC driver installed. The JDBC driver is special software that accepts standard calls from the client software and passes them to the database through the Java client communication stack. Oracle provides two types of 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 difference being that the Java client will pass connection information and database requests from within Java routines, as opposed to some other language such as C++. When connecting to the database using the JDBC OCI driver, the Oracle 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.

Java Database Connectivity: An industry standard connectivity interface for applications that make use of Java programming on the client to connect to a database source, also known as JDBC.

Communication Stack for JDBC OCI Connections

Figure 1-7: The Oracle communication stack for JDBC OCI connections. The JDBC thin driver is somewhat different in that it provides database connectivity to very small Java applications, such as Java applets. Using the JDBC thin driver, a Java applet can connect directly to the database through Java sockets, which bypasses most of the communication stack and can greatly improve con-

Communication Stack for JDBC Thin Clients

Lesson 1: Oracle Networking

15

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 components 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 Communication Stack for Web Clients

16

In addition to the Two-Task Common presentation, Oracle also supports HTTP and FTP presentations, which allows Web clients to connect directly to the database 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.

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

17

3.

Which layer of the Oracle communication stack is responsible for establishing 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 connecting a JDBC thin client to the database. Using the JDBC thin driver, a Java applet can connect directly to the database 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 implementation 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

18

•

Multi-protocol Connectivity

•

Secure Network Access

Oracle9i Database: Fundamentals II

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 connections CMAN will spawn a set number of connections to the database, and each individual connection will support requests from multiple clients. As new connection requests are sent to the database, CMAN will determine which prespawned 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 database connections to support the increased workload. By using this technique, the Oracle database can support hundreds of client requests with only a few actual connections to the database.

Connection Pooling by Connection Manager

connection pooling: The technique of pooling multiple client connections into a group of fewer 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 clients 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: • APPC (LU6.2) •

DECnet

•

Named Pipes (Microsoft Networking)

•

SPX/IPX

•

TCP/IP

multi-protocol connectivity: A configuration that supports several different client protocols to connect to a single database.

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.

Lesson 1: Oracle Networking

19

Connection Manager can provide additional security measures for network connections. It can be used as a stand-alone utility or in conjunction with Oracle’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 specifically 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 company’s livelihood and success. The most vulnerable component of the system is the network. There are three major risks involved when running an Oracle database 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 disclosure 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 network, 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 usually a long string of seemingly random characters. The receiving system will unscramble the data using the same key. Special hardware is required to implement encryption with the Oracle database. Oracle Advanced Security is compatible with much of the hardware available in the open market and also supports 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 different 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 relatively new encryption standard certified by the Federal Information Processing

20

Oracle9i Database: Fundamentals II

Standard (FIPS). This algorithm uses 128-, 192-, and 256-bit key lengths. In general, 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 stream, causing data modification. To ensure data integrity, Oracle Advanced Security provides cryptographic checksumming capabilities, which can create a 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.

checksum: A hash value generated by reading a single piece of data.

Authentication refers to the process of making positive identification of all clients, 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 thirdparty 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.

Lesson 1: Oracle Networking

21

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

heterogeneous connectivity: A feature that allows an Oracle client to use standard Oracle SQL and procedure calls to seamlessly access non-Oracle data sources.

Oracle Transparent Gateways

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 of these systems and transform it into top-notch information about all aspects of the company’s operation. However, doing so is not such an easy task. Each system usually stores its data in a different way, accesses the data differently, and has different ways to handle errors. Although SQL is an industry-standard query language, most database products have their own dialect of the language. Even 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 Transparent Gateway products. A gateway is primarily an interface between the Oracle 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 nonOracle databases.

Figure 1-11: The use of Oracle Transparent Gateways.

22

Oracle9i Database: Fundamentals II

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 manipulate 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 suitable to access the foreign database. To address this issue, Oracle provides a passthrough 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 thirdparty 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 qualifier 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 Heterogeneous 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.

Lesson 1: Oracle Networking

23

TASK 1A-4 Identify Additional Networking Options 1.

Describe multi-protocol activity. Which protocols does Connection Manager 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)

2.

•

DECnet

•

Named Pipes (Microsoft Networking)

•

SPX/IPX

•

TCP/IP

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 stability 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 managers to run simultaneously. If the primary connection manager server has failed or is otherwise not available, another one will be.

24

Oracle9i Database: Fundamentals II

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 database, 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 listener is so-called because it “listens” for client connection requests over one or more addresses on behalf of one or more Oracle database instances. Upon receiving a connection request from a client, the listener will send the requesting client the network address of a prespawned server process where the target database resides. If there is no prespawned server process available, it will direct the database 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 process, the listener no longer has any part in the communications of that session and returns to the task of listening for connection requests.

listener: A constantly running process that listens on the network for incoming 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

Lesson 1: Oracle Networking

25

Figure 1-13: A sample listener.ora file.

global database name: A database identifier to uniquely identify a single database on a network.

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 is listening. In this case, the listener is running on the server called ELEMENTK and is listening on port 1521, which is the default listener port. The SID_LIST_ LISTENER entry tells the listener which databases it is listening for. For listener 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 listener 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 database 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.

26

Oracle9i Database: Fundamentals II

While the listener.ora file can be edited manually, Oracle recommends using the graphical front-end tool, Net Manager. Net Manager provides a streamlined interface 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 Windows 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 automatically 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 different 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.

Lesson 1: Oracle Networking

27

TASK 1B-1 Configuring the Listener Process Objective: To configure the listener process using the Oracle Net Manager 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.

28

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

29

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

30

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

31

In the right pane, click the Add Address button. An Address1 tab will appear in the right pane.

7.

32

Oracle9i Database: Fundamentals II

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 Database1 tab appear in the right pane.

10. The information currently displayed in the Database1 tab is incorrect for your database. Lesson 1: Oracle Networking

33

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 34

Oracle9i Database: Fundamentals II

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 manage 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 Listener 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. Command

Purpose

change_password

Changes the password for the target listener. All commands that cause changes to the listener require the password. Exits from the Listener Control utility. Identical to the quit command. Displays a list of available commands and short descriptions of those commands. Exits from the Listener Control utility. Identical to the exit command. 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. Instructs Listener Control to save all new changes back to the listener. ora file. Displays a list of all current database services, instances, and service handlers for the current listener and their status. Used to set a number of different configuration parameters. Used to show a number of different configuration parameters. Starts the target listener. Shows a status summary of the target listener. Stops the target listener. Enables or disables tracing for the target listener. Shows the release version of the target listener.

exit help quit reload

save_config services set show start status stop trace version

Listener Control Commands

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

Lesson 1: Oracle Networking

35

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 command 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

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 listener trace level is OFF. current_listener

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 password, 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 stopping 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.

36

Oracle9i Database: Fundamentals II

It should be noted that the listener password set by the change_password command will only protect the listener from unauthorized access through the Listener 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.

Lesson 1: Oracle Networking

37

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 summary of the configuration of this listener. The uptime and number of service

38

Oracle9i Database: Fundamentals II

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 listener, 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 listener,” “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

Lesson 1: Oracle Networking

39

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.

40

Oracle9i Database: Fundamentals II

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 commands 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 command window will close. Lesson 1: Oracle Networking

41

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 network 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.

42

Oracle9i Database: Fundamentals II

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, highlight the definition for LISTENER1 listener.

Lesson 1: Oracle Networking

43

Choose Edit→Copy.

Move the insertion point to the blank line after the last line of the LISTENER1 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 LISTENER2 Change the port number for this listener to 1523

44

Oracle9i Database: Fundamentals II

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 listener 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 display 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

Lesson 1: Oracle Networking

45

LISTENER2 has not yet been created. The service will automatically be created, 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

names resolution method: A configured method that is used to translate a net service name to the network address where the intended database resides.

46

To connect to a remote database, the client must specify a user name and password to the database. However, the database must first be identified and located on the network. When submitting a connection request, the client specifies an alias to represent the intended database, which is resolved to the location on the network where a listener for that database resides. Depending on how the client is configured, the client will use that alias to perform a lookup, called a names resolution method, to find the correct network location of the listener. When submitting a connection request, the client will determine which names 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 configured 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.

Oracle9i Database: Fundamentals II

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 resolution 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 Names System (DNS) on the network. This method passes the responsibility of names resolution to the client’s host machine and is generally used for very simple network environments with very few clients and very few databases.

Names Resolution Methods

host naming: A names resolution method that uses the client’s HOSTS file to locate the target 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 protocol, 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 client would look up the connect descriptor in the tnsnames.ora file to determine the network location of the listener that serves the target database. Unlike host naming, local naming supports multiple protocols and can use most of the advanced security options. The disadvantage to local naming is that each client machine must be configured individually. For larger network environments, this task can be particularly daunting, especially if there are dozens of databases and hundreds of clients on the same network.

local naming: A names resolution method that is used to resolve net service names by looking up their connect descriptors in a definition file stored locally on the client’s machine.

Lesson 1: Oracle Networking

47

centralized naming: A names resolution method that stores all the connect descriptors in a centrallylocated repository. All clients needing to resolve connect descriptors contact the central repository.

external naming: A names resolution method similar to external naming, except the central repository is a non-Oracle, third-party product.

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 to a database, the specified alias is resolved by contacting the centralized names resolution system. This system then passes the network location of the target listener back to the client. While host naming and local naming can both be configured with just the Net Manager utility, centralized naming requires some fairly involved configuration, and may be overkill for some smaller environments. However, in larger environments, where connectivity is key and there is a limited 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 software is installed, possibly in a centralized location, to store database connect descriptors. External naming is normally used in very large environments where databases of different software vendors are running, and any of several dozen or hundred clients may connect to any database provided by a different vendor. To simplify the administration of such an environment, external naming provides a 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 network? 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 clients and servers are constantly added, removed, or relocated within the enterprise.

48

Oracle9i Database: Fundamentals II

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 environment 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 local HOSTS file on the client machine, or it can be determined by a simple Domain Names System (DNS) on the network. For Windows systems, the HOSTS file is stored in the C:\winnt\system32\drivers\ 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.

DNS: (Domain Names System) A server that is used to resolve matching host names to their respective IP addresses.

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.

Lesson 1: Oracle Networking

49

The TNSPING Utility

tnsping utility: A utility that is used to time the round trip of a network packet from the client to the listener and back.

For testing Oracle Net connections, Oracle provides the tnsping utility. This utility 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 server to respond. The tnsping utility performs the same action with a database alias. It is a command line utility that accepts a database alias, resolves the alias using the names resolution methods configured for the client, and attempts to 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 database 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_ parameter for that target server.

50

Oracle9i Database: Fundamentals II

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” indicates 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.

Lesson 1: Oracle Networking

51

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.

52

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

53

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. 54

Oracle9i Database: Fundamentals II

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 provides 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. 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.

A Connect Descriptor

Lesson 1: Oracle Networking

55

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 Manager 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.

56

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

57

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.

58

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

59

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.

60

Oracle9i Database: Fundamentals II

9.

On the Service page, there are two options for the database version, (Oracle8i or later) Service Name, and (Oracle8 or Previous) SID. The Service 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 create 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 connection test was successful.

11. When you are finished looking at the results of the test, click Close to close the Connection Test window. Lesson 1: Oracle Networking

61

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 client’s configuration.

12. Choose File→Save Network Configuration to save your changes. 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→

62

Oracle9i Database: Fundamentals II

Application Development→SQL Plus to launch the SQL*Plus utility.

14. In the Log On dialog box, type system for User Name, ora92 for Password, 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

Lesson 1: Oracle Networking

63

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, eliminating 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 external 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 following 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.

64

Item to Check

Action

Is the database operational? Is the problem widespread or related to one workstation or program?

Check the server to ensure the database is up and running. Verify connectivity from other clients that log in to the same server or using the same program. Check with the network administrators for overall network problems.

Oracle9i Database: Fundamentals II

Item to Check

Action

Can you make a connection from the client to the server?

Verify connectivity using PING and TNSPING. Test connectivity from the client to the database by attempting to log in. Ensure all required files exist and are configured correctly.

Are the network protocols and Oracle network protocol adapters installed on both the client and server? Is the listener operational and listening for the target database?

Use the lsnrctl utility to check the status of the target listener.

In many cases, connectivity issues are the result of something so blatantly obvious 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 problem is. This is where the tnsping utility becomes extremely useful. All Oracle 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 usually 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. 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. Indicates name resolution was not possible. Usually 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.

TNS-12541: No listener

TNS-12154: TNS: Could not resolve service name

Common Errors From tnsping

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.

Lesson 1: Oracle Networking

65

Oracle Net Logging and Tracing

Oracle Net logging: A feature that, when enabled, allows Oracle to log all informational entries to a specified log file for troubleshooting purposes.

Oracle Net tracing: A feature that, when enabled, allows Oracle to write out to a trace file every internal step taken to establish a database connection, usually generates much more detailed output than standard logging.

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 a useful means of generating detailed information for every aspect of the connection processes. In addition, if the problem cannot be resolved using traditional means, you can forward the log and trace files to Oracle Support for assistance. Since logging and tracing can generate huge files in a very short time, Oracle 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 logging and/or tracing database wide. When logging is enabled, anytime Oracle Net encounters errors, the error messages are written to a log file. The error entries include the number and description of the errors in the form of an error stack. The error stack contains a list of errors that begin at the most general error and drill down to the specific error that occurred. The log also contains the date and time the errors were written to the file. By examining the log file, you can determine which errors 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 problems, 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

66

•

LOG_DIRECTORY_listener_name

•

LOG_FILE_listener_name

Oracle9i Database: Fundamentals II

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, listener 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 commands 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 connection 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 information, 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. Lesson 1: Oracle Networking

67

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 automatically set the required parameters in the listener.ora file, which function in the same manner as the incoming connection trace parameters. The tracing parameters 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. 68

Oracle9i Database: Fundamentals II

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-

Lesson 1: Oracle Networking

69

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

5.

Choose File→Save Network Configuration to save your changes. Choose File→Exit to close the Oracle Net Manager.

70

Oracle9i Database: Fundamentals II

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 Password, 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 content of this file shows what is happening within the Oracle client while trying to contact the database server and establish a connection.

Lesson 1: Oracle Networking

71

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 content 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

72

Oracle9i Database: Fundamentals II

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.

Lesson 1: Oracle Networking

73

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

A Dedicated Server Configuration

shared server process: A single server process that can support database requests from multiple clients simultaneously.

74

The two types of configurations to handle users’ requests for data include singletask and two-task configurations. In a single-task configuration, the user and server processes are actually a single, combined process. The one process executes both the application code and the Oracle code, when processing a 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 application code, while the server process handles the interaction with the database on behalf of the user process. The server process can be either a dedicated or a shared process. It is considered dedicated because it will serve only a single user process at a time. A shared server process can handle multiple user connections 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.

Oracle9i Database: Fundamentals II

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 connections for multiple clients. In a dedicated server environment, the server 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 process 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.

An Oracle Shared Server Configuration

Figure 1-20: An Oracle shared server configuration.

Lesson 1: Oracle Networking

75

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 connecting 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

dispatcher: A background process in a shared server configuration that accepts database requests from user processes and passes them to shared server processes.

Oracle Shared Server requires the use of a listener, of course. In a standard configuration, 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 OSS is that the listener does not direct the user process straight to the server; all requests from user processes are handled by dispatchers. Upon receiving a connection request, the listener performs a direct hand-off of the connection to a dispatcher process. The user and dispatcher processes are then connected, and the user will submit all database requests directly to the dispatcher. The dispatcher 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 components work together.

Oracle Shared Server Connection Process

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

76

Oracle9i Database: Fundamentals II

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 restaurant 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, combined 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 processes to handle requests to the database.

Lesson 1: Oracle Networking

77

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 keeping 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 database, or simply connecting as SYS with the SYSDBA role.

78

Oracle9i Database: Fundamentals II

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 connection to the database, the listener provides the user process with the address of the appropriate server. In a shared server configuration, the listener provides 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

Lesson 1: Oracle Networking

79

Configuring Oracle Shared Server

PGA: (Program Global Area) The memory area at the OS level on the server that stores a user’s session data while the user is connected to the database.

UGA: (User Global Area) The memory area at the OS level on the server that exists only in a shared server configuration.

OSS Configuration Parameters

The majority of tasks required to configure Oracle Shared Server centers on setting various initialization parameters, which take effect when the database is started up. When shared server is configured, the contents of the SGA and the Program Global Area (PGA) differ slightly from what you would find in a dedicated server environment. The PGA is the memory area at the operating system level on the server that stores a user’s session data while the user is logged in. In the dedicated server configuration, the PGA consists of: • Stack space to store information on local variables used by the process or 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 information, is found in an area of the SGA known as the User Global Area (UGA). Each user will have a private User Global Area within the SGA. Because of this extra information stored in the SGA, it is recommended that you increase the size of the SGA to accommodate for the additional processing space required to house the UGAs. You would set the following initialization parameters to configure Oracle Shared Server: • LOCAL_LISTENER •

DISPATCHERS

•

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 multiple 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) ) )

80

Oracle9i Database: Fundamentals II

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 parameter must be set as follows: LOCAL_LISTENER = ora92oss

If the LOCAL_LISTENER parameter is not listed in the parameter file, or is initialized 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 automatically 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 initialization 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: DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=3) ⇒ (PROTOCOL=IPC)(DISPATCHERS=2)"

The DISPATCHERS attribute (shown in parenthesis) indicates the number of dispatchers to spawn at startup. If this keyword is left uninitialized, or omitted completely, the attribute will default to 1 dispatcher to be spawned at startup. You can also supply additional network attributes to the ADDRESS and DESCRIPTION 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.

The double right arrow (⇒) indicates that the syntax should be typed as if on a single line. The double right arrow is not part of the syntax.

Lesson 1: Oracle Networking

81

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 dispatchers 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 DISPATCHERS, 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 processes 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 database 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 setting this parameter in the initialization file: MAX_SHARED_SERVERS = 10

This parameter cannot be changed dynamically with the ALTER SYSTEM command 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.

82

Oracle9i Database: Fundamentals II

TASK 1D-2 Configure Oracle Shared Server 1.

Which of the following is found within the PGA in a shared server configuration? 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) ✓

3.

d. User Global Area (UGA)

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 parameters 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.

Lesson 1: Oracle Networking

83

There are five data dictionary views used to monitor a shared server configuration. These views are closely related to the parameters listed in the previous 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 SENT RECEIVE CONNECT DISCONNECT BREAK OUTBOUND

Idle. Currently sending a message. Currently receiving a message. Establishing a connection. Processing a request to disconnect. Processing a break. 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 dispatcher 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 indicates 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

84

Oracle9i Database: Fundamentals II

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 consider 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 number 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). Highest number of shared server sessions in use at one time since the instance started. Total number of additional shared servers started since instance startup (above and beyond the specified number at instance start up). Total number of shared servers stopped since instance startup. The highest number of shared servers since database creation.

MAXIMUM_SESSIONS SERVERS_STARTED

SERVERS_TERMINATED SERVERS_HIGHWATER

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.

Lesson 1: Oracle Networking

85

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: ---------------------------- -----------(ADDRESS=(PROTOCOL=tcp) DISPATCHER (HOST=elementk)(PORT=1030)) SERVERS

Responses ---------------NO RESPONSES 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 connections 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 determining 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.

86

Oracle9i Database: Fundamentals II

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 provide information to help in setting the MAX_SERVERS parameter? a. MAXIMUM_CONNECTIONS b. SERVERS_STARTED c. MAX_SERVERS ✓

4.

d. SERVERS_HIGHWATER

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 database 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.

Lesson 1: Oracle Networking

87

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 consists 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.

IIOP: (Internet Inter-ORB Protocol) A presentation protocol designed to implement CORBA technologies across the Internet.

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 protocols are both considered Internet Inter-ORB Protocols (IIOP). In general, IIOP is a presentation protocol designed to implement CORBA technologies across the internet. CORBA stands for Common Object Request Broker Architecture, and while it sounds fancy, it is really just an attempt to provide an industry-wide standard 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 protocols, 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 configured 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 initialization 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 connections through the GIOP presentation layer. 88

Oracle9i Database: Fundamentals II

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 different 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 connection 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 number 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.

Lesson 1: Oracle Networking

89

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 preassigned 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 initialization 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 configure 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 networking options that are available for Oracle and the features they provide.

90

Oracle9i Database: Fundamentals II

Lesson Review 1A In an N-tier environment, what is the easiest way to scale the environment 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 support? 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

Lesson 1: Oracle Networking

91

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 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. 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

92

Oracle9i Database: Fundamentals II

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 application 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 appropriate connect descriptor.

1D What happens after a user process issues a SQL command to the dispatcher 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 connection, 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 dispatcher 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 number for the ADDRESS keyword of the DISPATCHERS parameter. The client can navigate directly to that port and completely bypass the listener.

Lesson 1: Oracle Networking

93

94

Oracle9i Database: Fundamentals II

Backup and Recovery Overview

LESSON

2 Data Files none

Overview 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. In this lesson, you will learn about the types of failures Oracle is susceptible to, how to build a solid backup and recovery 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.

Lesson Time 4 hours, 30 minutes

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 downtime 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 backups 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

Types of Failures

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 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 statement, 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

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.

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 operations on the data, and the entire transaction failed. To recover from transaction failure, Oracle makes use of undo segments in the database. As a transaction executes, the data that is to be changed is first copied to the undo segments. Once the transaction is committed, the undo segment the transaction was using is released. If the transaction fails, Oracle will automatically rollback the entire transaction using the original copies of the data in the undo segment to return the 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.

96

Oracle9i Database: Fundamentals II

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 consists 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 statement 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 transaction 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 failures 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 completely, 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 statements 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 connection, 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.

Lesson 2: Backup and Recovery Overview

97

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 currently 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 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. 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 recovery 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.

98

Oracle9i Database: Fundamentals II

TASK 2A-1 Identify Types of Failures 1.

Match the scenario on the left with its type of failure on the right. d

c

a b

2.

A query fails because the user’s desktop lost contact to the database server through the network. A query fails due to insufficient sort space in the TEMP tablespace. The host server crashed. A disk volume containing a control file becomes corrupted.

a.

Instance failure

b.

Media failure

c. Statement failure d. Session failure

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 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.

Lesson 2: Backup and Recovery Overview

99

Backup and Recovery Basics Providing a stable and safe database environment consists of two primary objectives: 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.

MTBF: (Mean time between failures) The average amount of time that passes between failures of a system.

MTTR: (Mean time to recovery) The average amount of time it takes to recover a system after a failure.

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 refers to the amount of time that you can expect between failures of the database, the longer the better. You must ask yourself, how long will the database stay operational until the next failure? Is the MTBF for your system so short that your 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 system, or even a bug in the Oracle software. You must investigate the issue to determine why it is failing and take steps to keep your database up for as long as possible. Mean time to recovery refers to the amount of time it takes for you to get your 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 database 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

100

Oracle9i Database: Fundamentals II

of failures so you will know ahead of time what to do for each scenario. Recovery 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 ABORT option), none of the control files, datafiles, or redo log files are open or accessed by an instance, and the database is guaranteed to be in a consistent state. 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 of the datafiles, control files, and redo log files from their backup copies, then start up the database. While cold backups and recoveries are simple to perform, they provide extremely 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 business rules the database can allow. Also, when recovering the database after a failure, you cannot just copy one or two datafiles from the backup set. You must 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.

cold backup: A full backup of the database while the database is shut down.

hot backup: A backup of the database, either full or partial, performed while the database remains up and running.

Recovering From a Cold Backup

Figure 2-1: Recovering from a cold backup.

Lesson 2: Backup and Recovery Overview

101

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 performed, which minimizes database downtime. Additionally, you can perform true point-of-failure recovery. This means that if the database experiences media failure 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.

SCN: (System Change Number) A sequential numbering system Oracle uses to track every change in the database.

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 (CKPT) will update the control file and the headers of all the datafiles with the latest system change number (SCN) and timestamp on a regular basis. This allows Oracle to ensure that all datafiles are kept up to date, using the control file as a reference point. If the header of a datafile shows a lower SCN than the control 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 headers 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.

Recovery From a Hot Backup

102

In order to perform hot backups, the database must be running in a special mode called ARCHIVELOG mode. As changes are made to the database, the modified 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.

Oracle9i Database: Fundamentals II

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 database 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. Additionally, 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 complexity 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. Lesson 2: Backup and Recovery Overview

103

Complete and Incomplete Recoveries

complete recovery: A database recovery where all changes to the database are recovered right up to the point of failure.

incomplete recovery: A database recovery where not all changes to the database are recovered.

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 recovery is performed, 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, 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 meantime 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 particular 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.

104

Oracle9i Database: Fundamentals II

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 performed, 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 database and allow Oracle to recover the database from most types of failure. 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

Instance and Media Recovery Structures

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.

Lesson 2: Backup and Recovery Overview

105

Undo Segments In previous versions of Oracle, undo segments were known as rollback segments.

before image: The original version of data before it was changed by a transaction.

Undo segments are used to rollback, or undo, changes to data and play a critical role during recovery. When performing DML operations on data, Oracle will store the original version of each row of data to be changed in an undo segment. This original version, or before image, is used for multiple purposes, including: • Data consistency during DML operations. •

Rollback of unwanted changes.

•

Rollback of transactions after statement or session failure.

•

Rollback of uncommitted transactions during instance or media recovery.

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 segment 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 column 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 complete 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 simply 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

106

Oracle9i Database: Fundamentals II

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 forward, 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 information 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 generation for the object, which can improve performance slightly. It is important to remember though, that objects that are set to NOLOGGING will not be recoverable 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 fashion, with one redo log group acting as the current group and the others standing by. Once the redo log buffer is full of changes, they are written out to the current redo log group. Once this group is full, the current log group is switched out and

The current redo log group is sometimes referred to as the online redo log group, or just the online redo log.

Lesson 2: Backup and Recovery Overview

107

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.

108

Oracle9i Database: Fundamentals II

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 recoveryrelated activities. SMON also has some other non-recovery related duties, such as periodically cleaning up unused temporary segments in the tablespaces, and coalescing 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) process will begin to archive the now-full log group that was just switched out by copying it to the location specified by the LOG_ARCHIVE_DEST parameter. The file that is created by the archiver process is called an archive log. Regardless of the number of log file members there are in a log group, only one archive log is created per group. 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, overwriting 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 performed 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.

archive log: A copy of a redo log that has been filled and switched out as the current log group. Archive logs are used to apply changes to a backup to bring it up to date during recovery.

Lesson 2: Backup and Recovery Overview

109

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 conditions: • Manually with the ALTER SYSTEM CHECKPOINT command. •

A redo log switch, either automatically through normal operations or manually 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 generated 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 performance, 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 determining 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 modifications 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.

110

Oracle9i Database: Fundamentals II

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 committed 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 recommended 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 process, but it is the combination of all structures working together that provide Oracle the ability to recover from most types of failures. Figure 2-5 illustrates how all the structures work together. The undo segments were left out of the figure for clarity.

Instance and Media Recovery Structures

Lesson 2: Backup and Recovery Overview

111

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 completely lost, the last known good state is usually a restored backup of the affected files.

112

Oracle9i Database: Fundamentals II

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 guaranteed 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 transactions 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 corresponding 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 transactions 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

Lesson 2: Backup and Recovery Overview

113

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 transactions 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. Finding Files to Backup

Prior to shutting down the database, you would need to know the exact names and locations of all the files you intend to copy. The V$PARAMETER view provides 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, however, 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;

114

Oracle9i Database: Fundamentals II

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') FROM dba_data_files;

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 F:\oracle\cold_bup\wkly copy D:\ORACLE\ORADATA\ORA92\DRSYS01.DBF F:\oracle\cold_bup\wkly copy D:\ORACLE\ORADATA\ORA92\EXAMPLE01.DBF F:\oracle\cold_bup\wkly 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 location 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, control 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. Lesson 2: Backup and Recovery Overview

115

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 commands 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

116

Oracle9i Database: Fundamentals II

Issue the following query: SELECT file_name FROM dba_data_files;

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 locations of your redo log files. First, format the output of your query with the following command: COLUMN member FORMAT a50

Issue the following query: 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.

Lesson 2: Backup and Recovery Overview

117

After a few moments, the output will state that the database was closed, dismounted, 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.

118

Oracle9i Database: Fundamentals II

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. Lesson 2: Backup and Recovery Overview

119

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 assignments 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

120

Oracle9i Database: Fundamentals II

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 command 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 start

The path and file name of the datafile to verify. The datablock number to start scanning from. If omitted, DBVerify will start at the first datablock in the file. The datablock number at which to stop scanning. If omitted, DBVerify will stop after the last datablock in the file. The size in bytes of the datablocks in the datafile. The default value is 2048. The path and file name of the log file to generate. If omitted, no log file will be generated. Instructs DBVerify to output a period (.) to the screen for each datablock verified. The default is 0, which means no feedback is displayed. Specifies an optional parameter file that contains additional arguments. 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. Specifies the segment to scan.

end blocksize logfile feedback parfile userid

segment_id

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. reserved.

All rights

DBVERIFY - Verification starting : FILE = d:\oracle\oradata\ora92\users01.dbf

DBVERIFY - Verification complete Total Pages Examined : 3200 Total Pages Processed (Data) : 457

Lesson 2: Backup and Recovery Overview

121

Total Total Total Total Total Total Total Total Total

Pages Pages Pages Pages Pages Pages Pages Pages Pages

Failing (Data) : Processed (Index): Failing (Index): Processed (Other): Processed (Seg) : Failing (Seg) : Empty : Marked Corrupt : Influx :

0 0 0 57 0 0 2686 0 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 cannot 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 Copyright (c) 1982, 2002, Oracle Corporation. reserved.

All rights

DBVERIFY - Verification starting : SEGMENT_ID = 5.5.5897

DBVERIFY - Verification complete Total Total Total Total Total Total Total Total Total Total Total

Pages Pages Pages Pages Pages Pages Pages Pages Pages Pages Pages

Examined : Processed (Data) : Failing (Data) : Processed (Index): Failing (Index): Processed (Other): Processed (Seg) : Failing (Seg) : Empty : Marked Corrupt : Influx :

11 10 0 0 0 0 1 0 0 0 0

C:\>

In this example, a single segment that resides at block number 5897 in datafile 5 of tablespace 5 was scanned for corruption.

122

Oracle9i Database: Fundamentals II

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. In the Log On dialog box, type sys for User Name, ora92 for Password, and ora92 as sysdba for Host String. Click OK.

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, dismounted, 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.

Lesson 2: Backup and Recovery Overview

123

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. At the SQL*Plus prompt, type startup and press Enter. After a few moments, you will see the instance start, but a message will

124

Oracle9i Database: Fundamentals II

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 Lesson 2: Backup and Recovery Overview

125

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.

8.

Leaving the SQL*Plus window open, choose Start→Run. In the Run text 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, doubleclick ora92 folder to open it. Choose Edit→Paste. A progress meter will appear while the files are

126

Oracle9i Database: Fundamentals II

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. Close all open windows.

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. Additionally, you have the ability to restore just a single tablespace, or even a single

Lesson 2: Backup and Recovery Overview

127

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 importantly, 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. Environment variables in Windows are surrounded by percent signs (%), while environment variables in Unix are preceded by a dollar sign ($).

The LOG_ARCHIVE_DEST parameter can be set to any valid file system directory. The value assigned to this parameter can include OS-level environment variables, as long as the translated string of characters resolves to a directory on the file system that Oracle can find and write to. If this parameter is not set, the archive logs will be written to an OS-dependent default location. It is recommended, however, that you set this parameter explicitly to ensure that you have 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 multiple 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_

128

Oracle9i Database: Fundamentals II

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 format for the archive logs. This parameter uses variables to ensure that each archive log has a unique name to avoid overwriting existing archive logs. The 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. The same as %s, but fixed length and left-padded with zeros. The fixed length is OS dependent. The thread number. Will always have a value of 1, except when the instance is part of a Real Application Cluster (RAC) configuration. The same as %t, but fixed length and left-padded with zeros. The fixed length is OS dependent.

%S %t %T

LOG_ARCHIVE_FORMAT Pattern Variables

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 environment 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 Lesson 2: Backup and Recovery Overview

129

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 command 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.

130

Oracle9i Database: Fundamentals II

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 Fixed Size 453492 Variable Size 109051904 Database Buffers 25165824 Redo Buffers 667648 Database mounted. SQL> alter database archivelog;

bytes bytes bytes bytes bytes

Database altered. SQL> alter database open; Database altered. SQL> archive log list Database log mode Automatic archival Archive destination Oldest online log sequence Next log sequence to archive Current log sequence SQL>

Archive Mode Enabled D:\oracle\oradata\archive 37 39 39

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.

Lesson 2: Backup and Recovery Overview

131

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. In the Log On dialog box, type sys for User Name, ora92 for Password, and ora92 as sysdba for Host String. Click OK.

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. Currently, hot backups cannot be performed for this database.

The log sequence numbers for your system may be slightly different than what is shown here.

3. The double right arrow (⇒) indicates that the command is intended to be typed on a single line.

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_ ARCHIVE_FORMAT at its default setting. At the prompt, issue the following commands. ALTER SYSTEM SET log_archive_dest= ⇒ 'D:\oracle\ora92\database\archive' ⇒ SCOPE=spfile; ALTER SYSTEM SET log_archive_start=TRUE SCOPE=spfile;

132

Oracle9i Database: Fundamentals II

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.

Lesson 2: Backup and Recovery Overview

133

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.”

10. Leaving the SQL*Plus window open, choose Start→Run. In the Run text 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 configured the database in ARCHIVELOG mode with the proper settings. Hot

134

Oracle9i Database: Fundamentals II

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 SYSTEM 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 shutdowns, 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 generate 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

Lesson 2: Backup and Recovery Overview

135

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 monitoring for and researching media failure. The V$RECOVER_FILE Columns

If the instance is still up and running after media failure, another place you can look to determine which files need recovery is the data dictionary. The V$RECOVER_FILE view lists all datafiles that need recovery and why. The following table lists the columns of this view and their descriptions. Column

Description

FILE# ONLINE

File ID number. Left over from previous versions of Oracle and is obsolete. Will always show the same value as ONLINE_STATUS column. Online status of the datafile. Reason why the datafile needs recovery. Will be null if the reason is unknown. SCN where recovery must start. Time of the starting recovery SCN.

ONLINE_STATUS ERROR CHANGE# TIME

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 unusable, 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 command 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, 136

Oracle9i Database: Fundamentals II

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 process 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 committed 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 SYSTEM 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.

Lesson 2: Backup and Recovery Overview

137

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

2.

✓

c. Trace files

✓

d. V$RECOVER_FILE

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.

138

Oracle9i Database: Fundamentals II

Lesson Review 2A Which database component plays the biggest role in handling transaction 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 process 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.

Lesson 2: Backup and Recovery Overview

139

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 completely 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 automatically 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

140

Oracle9i Database: Fundamentals II

User-managed Backup and Recovery Overview User-managed backup and recovery of the Oracle database involves manually performing all the steps required to create a valid database backup, as well as all the steps to perform a recovery in the event of media failure. Earlier in the course, you learned that performing a cold backup simply involves making copies of all necessary Oracle files while the database is shut down. Since cold backups are fairly straight-forward, this lesson will focus on performing hot backups and recoveries. In this lesson, you will 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 recovery considerations for read-only tablespaces and also how to recover the database if the instance crashes while a hot backup is running.

LESSON

3 Data Files bup_status.sql get_trace.sql hot_backup_database. sql restore_database.sql logfiles.sql Lesson Time 6 hours, 30 minutes

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 database 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 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. In this topic, you will learn how to perform a complete recovery.

3C

Perform incomplete recoveries of the database to recover from various 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 certain circumstances, or it can be performed intentionally for a specific purpose. In this topic, you will learn how to perform incomplete recoveries 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. ALTER TABLESPACE Syntax

backup mode: A special mode for tablespaces that allows them to be copied while the database is up and running.

To perform a backup of the database manually, you would back up each 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 following syntax: ALTER TABLESPACE tablespace_name [BEGIN|END] BACKUP;

The database must be configured in ARCHIVELOG mode to place tablespaces 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

142

Oracle9i Database: Fundamentals II

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 current 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# STATUS

The file ID number. 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. The SCN of the datafile when it was last placed in hot backup mode. The timestamp of the datafile when it was last placed in hot backup mode.

CHANGE# TIME

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.

Lesson 3: User-managed Backup and Recovery

143

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. In the Log On dialog box, type sys for User Name, ora92 for Password, and ora92 as sysdba for Host String. Click OK.

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

144

Oracle9i Database: Fundamentals II

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;

Lesson 3: User-managed Backup and Recovery

145

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.

146

Oracle9i Database: Fundamentals II

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.

Lesson 3: User-managed Backup and Recovery

147

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 current 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 structure 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 database 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';

Backing Up the Control File

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 previous 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 commands 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 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. Figure 3-1 shows an example control file trace file generated by the ALTER DATABASE BACKUP CONTROLFILE command.

148

Oracle9i Database: Fundamentals II

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

Lesson 3: User-managed Backup and Recovery

149

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 database, 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 following 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 Backing Up the Control File 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';

150

Oracle9i Database: Fundamentals II

Oracle will display the message “Database altered.”

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: ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Lesson 3: User-managed Backup and Recovery

151

Oracle will display the message “Database altered.”

5.

To determine the current path and file name of the trace file that was generated, 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.

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.

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.

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. 152

Oracle9i Database: Fundamentals II

Close the trace file when you are done reading it.

8.

At the prompt, type exit and press Enter. Close all open windows.

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 or read-write with the ALTER TABLESPACE command, as shown in the following syntax.

Setting a Tablespace to Read-only or Read-write

ALTER TABLESPACE tablespace_name READ [ONLY|WRITE];

When the ALTER TABLESPACE command is issued to set a tablespace to readonly, 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 information about all tablespaces in the database. If you place a tablespace in readonly and you do not back up the control file, loss of the control file at a later

Lesson 3: User-managed Backup and Recovery

153

point will make a recovery very difficult, since Oracle will have no way of knowing 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 commands 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 control 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,

154

Oracle9i Database: Fundamentals II

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 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.

Resolving a Failed Backup

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 performing a standard recovery by issuing the RECOVER DATABASE command. Oracle will perform its normal recovery operations by rolling the database forward 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. Lesson 3: User-managed Backup and Recovery

155

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 ALTER ALTER ALTER ALTER

156

Oracle9i Database: Fundamentals II

TABLESPACE TABLESPACE TABLESPACE TABLESPACE TABLESPACE

system BEGIN BACKUP; undotbs1 BEGIN BACKUP; example BEGIN BACKUP; tools BEGIN BACKUP; 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. Lesson 3: User-managed Backup and Recovery

157

Oracle will display the message “Database altered.”

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.

158

Oracle9i Database: Fundamentals II

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 complete 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.

A Restored Datafile

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 written 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 as recovery targets. If recovery is performed at the file level, only the target datafile is recovered, while if the recovery is performed at the tablespace level, all restored datafiles that make up the target tablespace are recovered. If the recovery

The RECOVER command is identical to the ALTER DATABASE RECOVER command.

Lesson 3: User-managed Backup and Recovery

159

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 following 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.

160

Oracle9i Database: Fundamentals II

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 specified 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.

Lesson 3: User-managed Backup and Recovery

161

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;

162

Oracle9i Database: Fundamentals II

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 following 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: SELECT table_name, tablespace_name FROM dba_tables WHERE owner='OE';

Lesson 3: User-managed Backup and Recovery

163

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 statements 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. At the prompt, type ALTER SYSTEM SWITCH LOGFILE; and press Enter. Oracle will display the message “System altered.” 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 following query: SELECT file_name FROM dba_data_files WHERE tablespace_name='EXAMPLE';

The output shows that the EXAMPLE tablespace is made up of the

164

Oracle9i Database: Fundamentals II

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.

9.

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 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. At the prompt, type startup and press Enter. 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. Lesson 3: User-managed Backup and Recovery

165

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 be different from what is shown here.

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

166

Oracle9i Database: Fundamentals II

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. After a moment, Oracle will display the message “Database altered.”

15. To ensure that your TEST_RECOVERY table has been recovered, issue the following query once more: SELECT table_name, tablespace_name 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;

Lesson 3: User-managed Backup and Recovery

167

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. Close all open windows.

Trial Recovery

trial recovery: A test recovery of the database that is used to determine whether or not a real recovery will be successful.

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 if the database is very large, and can increase your mean time to recovery. In order to avoid this problem, Oracle provides the ability to execute a trial recovery to determine if a problem will be encountered during an actual recovery. The trial recovery is much faster than an actual recovery, and if any problems are reported 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 command with the TEST option. RECOVER DATABASE TEST;

If the trial recovery detects only a few corrupted blocks, you can choose to proceed 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 during 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 target 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.

168

Oracle9i Database: Fundamentals II

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 statement: 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;

Lesson 3: User-managed Backup and Recovery

169

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.

If you do not receive the last two errors and instead receive the following error, “ORA-10570: Test recovery complete,” then issue the following command before moving on with this activity: CONNECT sys as sysdba.

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 required entry in the redo logs, and stopped when it reached the last known entry in the redo log. If any more redo entries were applied, the datafile would contain a later SCN than the control file, and the controlfile would have to be modified to support it, which is not allowed in trial recovery. The next message, stating that the test recovery was canceled due to errors, is purely informational. The third message from the bottom states the SCN 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

170

Oracle9i Database: Fundamentals II

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

Oracle will display the message “Tablespace altered.”

9.

Exit from SQL*Plus. Close all open windows.

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 circumstances, you must restore the datafile to a new location. Once the file is restored, 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.

Renaming a Datafile in Oracle

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. Lesson 3: User-managed Backup and Recovery

171

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 forgot 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 possible 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;

Creating an Empty Datafile

Once the tablespace is offline, you will create a new, empty datafile to take the 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.

172

Oracle9i Database: Fundamentals II

TASK 3B-3 Restore Datafiles to New Locations Objective: To restore datafiles to new locations in the event that the original 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 WHERE tablespace_name='EXAMPLE';

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.

4.

Leaving the SQL*Plus window open, open a window to the D:\oracle\ oradata\ora92 folder. Delete the EXAMPLE01.DBF datafile from this folder.

5.

Leaving the ora92 window open, switch back to the SQL*Plus window. At the prompt, type startup and press Enter. The output will show that the instance was started and the database opened, Lesson 3: User-managed Backup and Recovery

173

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 creating 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. At the SQL*Plus prompt, issue the following command: ALTER DATABASE RENAME FILE 'D:\ORACLE\ORADATA\ORA92\EXAMPLE01.DBF' TO 'D:\ORACLE\ORADATA\NEW_LOC\EXAMPLE01.DBF';

174

Oracle9i Database: Fundamentals II

Oracle will display the message “Database altered.” 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. Oracle will display the message “Database altered.” 11. To verify location of the EXAMPLE01.DBF datafile, issue the following query again: SELECT file_name FROM dba_data_files WHERE tablespace_name='EXAMPLE';

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-

Lesson 3: User-managed Backup and Recovery

175

ered the database after the loss of a disk.

12. Exit from SQL*Plus.

Topic 3C User-managed Incomplete Recovery

Incomplete Recovery Scenarios

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 information to the database, from either the archive logs or the current online redo log. An incomplete recovery may be required, and in some cases desired, in certain 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 database 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 current 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 terminate the recovery and open the database without applying those missing changes.

176

Oracle9i Database: Fundamentals II

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 database 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 normal, 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, timebased, or change-based recovery. This is done by including the UNTIL clause with the RECOVER command, which tells Oracle when to stop applying redo information to the database. The following syntax shows the RECOVER command with the UNTIL clause.

Incomplete Recovery Commands

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 location 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 database 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

Lesson 3: User-managed Backup and Recovery

177

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 specified 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 database 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 cannot 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 database 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;

incarnation: A new version of a database created when the database is opened with the RESETLOGS option.

The RESETLOGS option can only be used after an incomplete recovery, specifically 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 an error. When opening the database with the RESETLOGS option, you have essentially created a new incarnation of the database. This new incarnation is a completely 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 database to shift to a new timeline in its life. Figure 3-3 illustrates this concept.

RESETLOGS Creates a New Database Incarnation

178

Oracle9i Database: Fundamentals II

Figure 3-3: RESETLOGS creates a new database incarnation. In the timeline at the top half of this figure, the database has been operating normally, 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. Additionally, 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 database that had occurred after the log reset, and you will be right back to square one.

Lesson 3: User-managed Backup and Recovery

179

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.

✓ 2.

d. Loss of the current redo log group.

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

✓ 3.

d. Time-based

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 essentially 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 incarnation, 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 different 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.

180

Oracle9i Database: Fundamentals II

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 archive logs to recover the database. Once Oracle prompts for an archive log that 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.

Cancel-based Recovery With Backup Control File

Occasionally, when Oracle prompts for an archive log that has not yet been generated, 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 recovery, 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.

Lesson 3: User-managed Backup and Recovery

181

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 database 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 control 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 Fixed Size 453492 Variable Size 109051904 Database Buffers 25165824 Redo Buffers 667648 SQL> SQL> @D:\oracle\hot_bup\control.trc

bytes bytes bytes bytes bytes

When executing the CREATE CONTROLFILE command, Oracle will automatically re-create a copy of the control file in each location specified by the CONTROL_FILES initialization parameter. If a location specified by this parameter 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 recommended 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. Launch SQL*Plus and log in as sys.

182

Oracle9i Database: Fundamentals II

2.

Force a log switch by issuing the following command: ALTER SYSTEM SWITCH LOGFILE;

Oracle will display the message “System altered.” 3.

Create a new backup copy of the current control file by issuing the following command: ALTER DATABASE BACKUP CONTROLFILE TO 'D:\oracle\hot_bup\control.bak' REUSE;

Oracle will display the message “Database altered.” 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. At the prompt, type startup and press Enter. The instance will start, but the database will not mount, and Oracle will display the message “ORA-00205: error in identifying controlfile, check alert log for more info.”

Lesson 3: User-managed Backup and Recovery

183

7.

Leaving the SQL*Plus window open, open a window to the D:\oracle\ 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

184

Oracle9i Database: Fundamentals II

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. After a moment, Oracle will display the message “Database altered.”

10. To begin recovery, issue the following command: RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

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 display 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-

Lesson 3: User-managed Backup and Recovery

185

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 following 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 ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF'

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. At the prompt, issue the following command: RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

186

Oracle9i Database: Fundamentals II

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.”

Lesson 3: User-managed Backup and Recovery

187

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 oldest online log sequence number has been set to 0, instead of 1.

The output will show that the current log sequence number has been reset to 1. Also, the oldest online log sequence has been set to 1, which means that all archive log history has been removed from the control file.

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. At the prompt, issue the following command: ALTER DATABASE BACKUP CONTROLFILE TO 'D:\oracle\hot_bup\control.bak' REUSE;

Oracle will display the message “Database altered.” 16. Exit from SQL*Plus. Close all open windows.

188

Oracle9i Database: Fundamentals II

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 have been committed, Oracle will not have had the chance to archive those 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 recovery 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.

Recovery After Loss of Current Redo Log Group

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, performing 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 permanently 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.

Lesson 3: User-managed Backup and Recovery

189

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 command 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. Launch SQL*Plus and log in as sys.

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 command 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 complete, the command prompt window will disappear, you will be returned to the SQL*Plus prompt, and Oracle will display the message “Backup complete.”

190

Oracle9i Database: Fundamentals II

3.

To demonstrate the affect of losing the current online redo log, you will create 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 STATUS column in the output will show which log group is the current group. Additionally, the SEQ# column will show the log sequence number of each group. The sequence number increments infinitely, and is used to identify 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.

The log sequence number shown in your output may be different from what is shown here.

You will now create a small table. At the prompt, issue the following command: 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;

Oracle will display the messages “1 row created” and “Commit complete.” 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.

Lesson 3: User-managed Backup and Recovery

191

At the prompt, type ALTER SYSTEM SWITCH LOGFILE; and press Enter. Oracle will display the message “System altered.” 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;

Oracle will display the messages “1 row created” and “Commit complete.” 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.

The group number of the current log group may be different from the log sequence number. This is normal.

192

Oracle9i Database: Fundamentals II

Make a note of which log group is current, along with its log sequence number from SEQ# column.

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.

10. Leaving the ora92 folder open, switch back to the SQL*Plus window. At the 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.

Lesson 3: User-managed Backup and Recovery

193

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 copied 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.”

194

Oracle9i Database: Fundamentals II

13. The database has been recovered to include all available changes. The current 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.

15. Exit from SQL*Plus. 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 automatically created a new file for the current online redo log when the ALTER DATABASE OPEN RESETLOGS command was issued. Close the ora92 window.

Lesson 3: User-managed Backup and Recovery

195

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 circumstances involved with the recovery, you may need to perform some extra steps in order to recover after media failure. The recovery steps will be determined by whether you are recovering the database using the current control file or a backup control file. Read-only Tablespace Recovery With Current Control File

When you are using the current control file for recovery, recovering a database that contains read-only tablespaces is identical to performing any standard database recovery after media failure. You would simply take the following steps: 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 perform a recovery of the database. The steps you would take are as follows: 1. Restore all datafiles and the control file from backup. 2.

Mount the database.

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

196

Oracle9i Database: Fundamentals II

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 recovery 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.

2.

Mount the database.

3.

Perform cancel-based, time-based, or change-based incomplete recovery with the USING BACKUP CONTROLFILE clause.

4.

Open the database using the RESETLOGS option.

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.

3.

Mount the database.

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.

Lesson 3: User-managed Backup and Recovery

197

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: 1.

Restore all datafiles from backup.

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.

4.

Mount the database.

5.

Perform cancel-based, time-based, or change-based incomplete recovery with the USING BACKUP CONTROLFILE clause.

6.

Open the database using the RESETLOGS option.

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 protect 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.

198

Oracle9i Database: Fundamentals II

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 incomplete 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 information 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 control 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.

Lesson 3: User-managed Backup and Recovery

199

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 occasions, 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.

clone database: A database created by restoring and recovering the hot backup of another database to another location.

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 original database to a different location, possibly on a different server, and performing a cancel-based, time-based, or change-based recovery. You have the option of restoring the entire backup if you like. At a minimum, however, you 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.

200

Oracle9i Database: Fundamentals II

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 original 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 database, 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 database 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.

Lesson 3: User-managed Backup and Recovery

201

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 complete 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 checkpoint to bring them up to date with the rest of the database. What happens when the following command is issued? ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

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.

202

Oracle9i Database: Fundamentals II

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 corruptions 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 command, 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 ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORA92\SYSTEM01.DBF'

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 missing 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.

Lesson 3: User-managed Backup and Recovery

203

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 performing 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.

204

Oracle9i Database: Fundamentals II

Recovery Manager Backups

LESSON

4 Overview Manually performing all backup and recovery operations for the database is considered user-managed backup and recovery. However, Oracle provides a powerful utility called Recovery Manager, better known as RMAN, which provides the capability to create a centralized solution to handle all backup and recovery operations for all Oracle databases in a single environment. In this lesson, you will learn about the features RMAN provides and its architecture 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 maintain its centralized information repository.

Data Files none Lesson Time 7 hours

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 information 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 backups, 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.

206

Oracle9i Database: Fundamentals II

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 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 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 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 mediamanagement 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.

RMAN Features

MML: (Media-management layer) Third-party backup utilities that can integrate with RMAN to help perform backup and recoveries of the database.

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 megabytes 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. Lesson 4: Recovery Manager Backups

207

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 running 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 prepare 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.

208

Oracle9i Database: Fundamentals II

2.

True or False? Every database in an environment requires its own RMAN configuration to allow backing up that database with RMAN. Explain your answer. 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, centralized 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 database 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 perform 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 supports. For each database, the repository includes the database’s current physical 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 information 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.

The RMAN Repository

Lesson 4: Recovery Manager Backups

209

Figure 4-1: The RMAN repository. In this figure, RMAN connects to each target database in the environment to perform 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 database’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 contains the following information to support RMAN operations: • Basic information about the database, such as the database name and database incarnations.

210

•

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.

Oracle9i Database: Fundamentals II

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 target 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 contain 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 relatively 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

Lesson 4: Recovery Manager Backups

211

BACKUP DATAFILE BACKUP REDOLOG DATAFILE COPY BACKUP CORRUPTION COPY CORRUPTION DELETED OBJECT PROXY COPY BACKUP SPFILE DATABASE INCARNATION

116 76 660 44 40 20 852 36 56

53 0 4 0 0 15 0 30 2

23 rows selected.

The Recovery Catalog as the Repository

recovery catalog: A database schema that can act as the backup and recovery information repository for RMAN.

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 recovery catalog, rather than control files, be used as the repository in all the simplest of backup and recovery environments. The contents of the recovery catalog include: •

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 information 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 contains 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 configuration 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.

212

Oracle9i Database: Fundamentals II

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 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.

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.

Lesson 4: Recovery Manager Backups

213

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 database 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 recommended 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. RMAN Backup Process Flow

Regardless of whether you are performing a hot or cold backup, or whether you are using the control file or recovery catalog as the repository, RMAN follows 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. 214

Oracle9i Database: Fundamentals II

For all backup and recovery operations, RMAN must allocate a communication channel. This communication channel is a dedicated connection to the target database 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 additional to the initial connection to the database, which is used solely to update the repository with the latest backup and recovery information for the target. When the channel is allocated for backups, it includes the backup destination where the backups are to be created.

communication channel: A dedicated connection between RMAN and the target database

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 location, 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 of the target database. However, if the control file is used as the repository, then 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.

RMAN Restore Process Flow

Lesson 4: Recovery Manager Backups

215

Regardless of whether the control file or recovery catalog is used as the repository, 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 automatically, 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 commands the DBA would when performing user-managed recovery. The difference is that RMAN will automatically determine which archive logs, if any, are necessary 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 recovery 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. ✓

216

Oracle9i Database: Fundamentals II

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 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.

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 sets. 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. Since image copies created by RMAN are exactly identical to their originals, they can be restored either automatically by RMAN or manually 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 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.

image copy: A type of backup file created by RMAN which is a bit-forbit image of the original file.

RMAN Backup Sets

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.

Lesson 4: Recovery Manager Backups

217

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.

218

Oracle9i Database: Fundamentals II

TASK 4A-4 Describe How RMAN Creates Image Copies and Backup Sets 1.

True or False? Image copies of datafiles can be restored either automatically 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

Lesson 4: Recovery Manager Backups

219

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. RMAN Connecting to Target Database Using the Control File

Alternatively, you can invoke RMAN and connect to the target database in a single command. For example, the following command issued from the command prompt invokes RMAN and automatically connects to the ORA92 database using 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.

220

Oracle9i Database: Fundamentals II

TASK 4B-1 Using the Control File as the RMAN Repository Objective: To use RMAN to connect to the target database using the control 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. Launch SQL*Plus and log in as sys.

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: rman target rman/buprec@ora92 nocatalog

The output will show that you have connected to the specified target database, 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

Lesson 4: Recovery Manager Backups

221

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 recommended 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 database 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 222

Oracle9i Database: Fundamentals II

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 Figure 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 issued, RMAN will automatically create all the objects that make up the recovery 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.

Creating the RMAN Recovery Catalog

Figure 4-6: The CREATE CATALOG command. Lesson 4: Recovery Manager Backups

223

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 connect 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. Launch SQL*Plus and log in as sys.

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.”

224

Oracle9i Database: Fundamentals II

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 database and the database where the recovery catalog is stored. For this course, both refer to the ORA92 database. At the command prompt, issue the following 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. Lesson 4: Recovery Manager Backups

225

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

Issue the following query: SELECT table_name, tablespace_name 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.

8.

226

Oracle9i Database: Fundamentals II

Exit from SQL*Plus.

Register a Target Database Once the recovery catalog is created, each database to be supported must be registered 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 issue the REGISTER DATABASE command. The output from this command is shown in Figure 4-8.

Registering a Database with the Recovery Catalog

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. At the prompt, issue the following command: rman rcvcat rman/buprec@ora92 target rman/buprec@ora92

Lesson 4: Recovery Manager Backups

227

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 database, 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 operations 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 database; 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

228

Oracle9i Database: Fundamentals II

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 configurations help simplify the management of backup and restore operations by minimizing the amount of text required for execution. The configuration parameters 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 maintain 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 OBSOLETE command to automatically find and delete all backup sets that are marked obsolete. In this way, you will limit the amount of disk space consumed for backups, and still keep a minimum number of current backups on hand. To set the retention policy to maintain five sets of current backups, you would issue the following command at the RMAN prompt:

RMAN Configuration Parameters

retention policy: The policy used by RMAN to determine which database backups in its recovery catalog are still valid.

CONFIGURE RETENTION POLICY TO REDUNDANCY 5;

Lesson 4: Recovery Manager Backups

229

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 %D %F

Specifies the name of the target database. Specifies the current day of the month using the format DD. Combines the database identifier (DBID), day, month, year, and a sequential number into a unique and repeatable generated name. Specifies the month number using the format MM. 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. 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 the target database. Specifies the timestamp of the backup set. Specifies a full year, month, and date using the format YYYYMMDD. Instructs RMAN to generate a unique name for each output file. Shorthand for %u_%p_%c. This combination guarantees uniqueness for all backup sets generated for a single target database. Specifies the current year using the format YYYY.

%M %p

%s

%t %T %u %U %Y

230

Oracle9i Database: Fundamentals II

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 pattern 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 database 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 parameter 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. Additionally, a tablespace exclusion is target database-specific, meaning that a Lesson 4: Recovery Manager Backups

231

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 backups 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 commands will set each of the previously mentioned configuration parameters back to their default values: CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE CLEAR; CONFIGURE CONFIGURE

RETENTION POLICY CLEAR; DEFAULT DEVICE TYPE CLEAR; CHANNEL DEVICE TYPE DISK CLEAR; CONTROLFILE AUTOBACKUP CLEAR; CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK BACKUP OPTIMIZATION CLEAR; 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 configuration 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.

232

Oracle9i Database: Fundamentals II

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. At the prompt, issue the following command: rman rcvcat rman/buprec@ora92 target rman/buprec@ora92

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 perLesson 4: Recovery Manager Backups

233

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 noncritical 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,

234

Oracle9i Database: Fundamentals II

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.

Lesson 4: Recovery Manager Backups

235

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. However, 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 utility 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 the target database.

Figure 4-10: Shutting down and mounting the target database from within RMAN. The BACKUP Command

236

Once the database is mounted, the backup can begin. During the backup process, 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 configuration parameter:

Oracle9i Database: Fundamentals II

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 created from a control file autobackup operation will always be contained within its own backup set. For example, if you execute the BACKUP DATABASE command, 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

Lesson 4: Recovery Manager Backups

237

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 created 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. The COPY Command

To create image copy backups, you would use the COPY command instead of 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:

238

Oracle9i Database: Fundamentals II

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 determined 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: rman target rman/buprec@ora92 nocatalog

Lesson 4: Recovery Manager Backups

239

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

240

Oracle9i Database: Fundamentals II

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 numbers. As indicated by the configuration parameters, the control file will automatically be backed up for each backup of the database. The other file is

The names of the files you see on your system may not be the same as those shown here.

Lesson 4: Recovery Manager Backups

241

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 tablespace. To determine the name and location of the USERS datafile, type report schema; and press Enter.

The output of the schema report may be wider than your window, which causes longer lines of text to wrap to the next line.

The output will show a list of the datafiles in the target database. Find the 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 command, 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 channel, 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,

242

Oracle9i Database: Fundamentals II

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 generated 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 perLesson 4: Recovery Manager Backups

243

formance while the backup is executing. Like the RMAN cold backup, the RMAN hot backup is initiated with the BACKUP command. If the persistent configuration 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 database and recovery catalog can be listed in any order at the RMAN prompt.

rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

The output will show that RMAN has connected to both the target database 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

244

Oracle9i Database: Fundamentals II

backup may take several minutes to complete.

3.

Exit from both RMAN and the command prompt.

RMAN Incremental Hot Backups To decrease the amount of time it takes to perform a hot backup of a large database, 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 have changed since the datafile was created. This could potentially mean that an entire datafile could be backed up if the datafile was very full at any point in its lifetime. When performing incremental hot backups, RMAN will only back up datablocks 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.

incremental backup: A backup of the database that includes only the datablocks that have changed since a previous incremental backup instead of all datablocks that contain data.

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.

Lesson 4: Recovery Manager Backups

245

By definition, the default behavior of an incremental backup behaves in this manner: •

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 incremental 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 performed on Sunday, so the only blocks that were backed up were those that changed between Sunday and Monday.

246

Oracle9i Database: Fundamentals II

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 incremental 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 different 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 incremental 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 Sunday 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

Lesson 4: Recovery Manager Backups

247

were performed on Thursday and Friday. Once RMAN has applied all incremental 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 backups, 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 following 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 command: 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

248

Oracle9i Database: Fundamentals II

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. Lesson 4: Recovery Manager Backups

249

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 command: CREATE TABLE test_inc (col1 NUMBER) TABLESPACE users;

Oracle will display the message “Table created.” 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

250

Oracle9i Database: Fundamentals II

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 command 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.

Lesson 4: Recovery Manager Backups

251

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 numbers, 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 following 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;

252

Oracle9i Database: Fundamentals II

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 them from the system after the backup automatically.

2.

The number of archive logs and their details on your system may be different than what is shown here.

Leaving the archive folder open, open a command prompt, and then launch RMAN with the following command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

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 allocated 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 earlier in the course. RMAN detects this and excludes the unneeded archive logs from the backup.

Lesson 4: Recovery Manager Backups

253

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 following example creates a stored script to perform a full hot backup of the target database: Creating an RMAN Stored Script

254

RMAN> CREATE SCRIPT full_hot_backup 2> { 3> BACKUP DATABASE PLUS ARCHIVELOG; 4> }

Oracle9i Database: Fundamentals II

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 created 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 indicate 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 Stored Script

printing stored script: full_hot_backup { 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> { 3> BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT; 4> }

Replacing an RMAN Stored Script

In this example, the full_hot_backup script that was already stored in the recovery 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 commands 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 provides 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

Lesson 4: Recovery Manager Backups

255

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 command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

256

Oracle9i Database: Fundamentals II

RMAN will launch and connect to both the target database and the recovery 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.

Lesson 4: Recovery Manager Backups

257

At the prompt, issue the following 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.

258

Oracle9i Database: Fundamentals II

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.”

8.

Exit from RMAN and the command prompt.

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 provide 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 everything 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. Option

Description

SCHEMA

Reports on the layout of the target database, such as datafile names and locations and their sizes. Provides a report on the datafiles that have had unrecoverable operations perform on their contents, such as tables that have the NOLOGGING attribute set. Provides a report about the datafiles that need to be backed up to maintain the backup retention or redundancy policy set by the DBA. 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.

UNRECOVERABLE

NEED BACKUP OBSOLETE

The REPORT Command Options

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;

Lesson 4: Recovery Manager Backups

259

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 layout 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 unrecoverable 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 information, the datafiles of the TOOLS tablespace will have changes to data that cannot be recovered using archive logs. The REPORT UNRECOVERABLE command 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 performed 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.

The LIST BACKUP Command Options

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 all known backups for the target database, which will include all datafiles, control 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 backups of the SYSTEM tablespace: LIST BACKUP OF TABLESPACE system;

260

Oracle9i Database: Fundamentals II

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 generate 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 incarnations 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';

Lesson 4: Recovery Manager Backups

261

TASK 4D-2 Generate RMAN Reports and Lists Objective: To generate RMAN reports and lists to extract backup information from the recovery catalog. 1.

Open a command prompt, then launch RMAN with the following command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

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.

The output may be so long 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.

262

Oracle9i Database: Fundamentals II

To generate a list of all backups of all files generated by RMAN for the target database, type list backup; and press Enter. RMAN will generate a long list of backups that were generated. This list will include all files that were backed up, including datafiles, control files,

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.

Lesson 4: Recovery Manager Backups

263

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 generated 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.

264

Oracle9i Database: Fundamentals II

The output will show all the information about the backup set that was generated from your RMAN script. The backup set was easily identified by the tag test_script.

9.

RMAN uses the RETENTION POLICY configuration parameter to determine 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 copies 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 comply with the retention policy.

11. To determine which backups are obsolete and can be deleted, type report obsolete; and press Enter.

Lesson 4: Recovery Manager Backups

265

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.

12. Exit from RMAN and the command prompt.

Crosscheck and Delete Backup Sets

crosscheck: A process of validating recovery catalog entries against the backup files that actually exist in the file system.

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 overwritten by the media manager, or by media failure where the backup files reside. To help keep the recovery catalog up to date and purge old entries, RMAN provides the CROSSCHECK command to identify backup entries that are no longer valid. 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 created with the BACKUP or COPY commands, as shown in the following examples: CROSSCHECK BACKUP;

Crosschecking Backups and Copies

CROSSCHECK BACKUP OF CONTROLFILE; 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.

266

Oracle9i Database: Fundamentals II

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 identify 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 command 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 command, as shown in the following examples: DELETE BACKUP; Deleting Backups and Copies

DELETE BACKUP OF TABLESPACE system; 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.

Lesson 4: Recovery Manager Backups

267

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 criteria, 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 corresponding 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 command 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 command 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;

268

Oracle9i Database: Fundamentals II

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 launch RMAN with the following command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

RMAN will launch and connect to both the target database and recovery 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 the recovery catalog against what actually exists on disk. Towards the end of the output, you will see that the file you deleted could not be found on the

Your results will vary depending on the number of archive logs.

Lesson 4: Recovery Manager Backups

269

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.

270

Oracle9i Database: Fundamentals II

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.

Lesson 4: Recovery Manager Backups

271

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 272

Oracle9i Database: Fundamentals II

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, control 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 different 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 candidates 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 commands 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 command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

RMAN will launch and connect to both the target database and recovery catalog. 3.

To generate a list of image copies currently registered in the recovery catalog, type list copy of database; and press Enter. Lesson 4: Recovery Manager Backups

273

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. While in this activity you are only cataloging some of the files of a cold backup, you must remember that all files of a cold backup must be available in order to recover and restore the database with that backup, including the datafiles and the control file.

The output will show that you have successfully cataloged the datafiles of the SYSTEM, USERS, and TOOLS tablespaces with the recovery catalog. If the need arises, RMAN will be able to locate, restore, and recover these backup datafiles in the event of a disk failure or file corruption.

6.

274

To confirm that the backup files have been registered with the recovery catalog, type list copy of database; and press Enter.

Oracle9i Database: Fundamentals II

Exit from both RMAN and the command prompt.

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 Validation

RESTORE VALIDATE DATABASE;

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 configuration, 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 validation 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 feature 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 succeed 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 command: rman target rman/buprec@ora92 rcvcat rman/buprec@ora92

RMAN will launch and connect to both the target database and the recovery catalog. Lesson 4: Recovery Manager Backups

275

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 channel 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.

4.

Exit from both RMAN and the command prompt. Close all open windows.

276

Oracle9i Database: Fundamentals II

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 database, 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 simplify 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 backing up the databases in the environment, and also each recovery catalog can be used to back up the other. Figure 4-12 illustrates this concept.

Multiple Recovery Catalogs for Cross-backups

Figure 4-12: Using multiple RMAN recovery catalogs to perform backups.

Lesson 4: Recovery Manager Backups

277

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 databases 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 addition, 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. Additionally, 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 critical 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 created 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.

278

Oracle9i Database: Fundamentals II

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 Enterprise 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 recovery 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 production databases until the original RMAN server is rebuilt.

Lesson 4: Recovery Manager Backups

279

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

280

Oracle9i Database: Fundamentals II

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 databases 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 incremental 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

Lesson 4: Recovery Manager Backups

281

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. Explain your answer. 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 operation? 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.

282

Oracle9i Database: Fundamentals II

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 automatically 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.

Lesson 4: Recovery Manager Backups

283

284

Oracle9i Database: Fundamentals II

Recovery Manager Recoveries

LESSON

5 Data Files logfiles.sql

Overview The power of RMAN is easily realized when performing a recovery for a 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.

Lesson Time 3 hours

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 failure, 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.

286

•

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.

Oracle9i Database: Fundamentals II

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 provide 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 { SQL 'alter tablespace sales offline immediate'; SET NEWNAME FOR DATAFILE 28 TO 'F:\oracle\oradata\newdisk\sales05.dbf'; RESTORE TABLESPACE sales; SWITCH DATAFILE ALL; RECOVER TABLESPACE sales; SQL 'alter tablespace sales online;' }

Restoring a File to a New Location

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 provides 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.

Lesson 5: Recovery Manager Recoveries

287

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. Open a command prompt, and launch RMAN with the following command: rman target rman/buprec@ora92 nocatalog

RMAN will launch and connect to the target database and will use the control 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. Your results may vary depending on the number of archive logs.

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. At the RMAN prompt, issue the following command: 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.

288

Oracle9i Database: Fundamentals II

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. Launch SQL*Plus and log in as sys. 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.

5.

Leaving the SQL*Plus window open, open a window to the D:\oracle\ oradata\ora92 folder. 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 following 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

Lesson 5: Recovery Manager Recoveries

289

not to delete any files other than what is listed here.

6.

Leaving the ora92 folder open, switch back to the SQL*Plus window. At the SQL*Plus prompt, type startup and press Enter. You will see Oracle start the instance and mount the database, but the database 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 target rman/buprec@ora92 nocatalog

290

Oracle9i Database: Fundamentals II

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.

Lesson 5: Recovery Manager Recoveries

291

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 database, 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' [,...];

292

Oracle9i Database: Fundamentals II

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 forward 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 database, 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.

Lesson 5: Recovery Manager Recoveries

293

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. Open a command prompt, and launch RMAN with the following command: rman target rman/buprec@ora92 nocatalog

RMAN will launch and connect to the target database using the control file 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 contents to the database. At the RMAN prompt, type recover database; and press Enter. RMAN will allocate a channel, and then perform the recovery.

4. 294

Oracle9i Database: Fundamentals II

Once the recovery is complete, you must open the database to make it available 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 requiring recovery was large, and may be difficult to justify for only a few datablocks of corruption. However, RMAN provides the ability to recover individual data blocks with its Block Media Recovery (BMR) feature. When performing a user-managed recovery on a datafile, the tablespace to which that datafile belongs will be unavailable until recovery is complete. With BMR, you can recover individual data blocks while the affected tablespace remains online.

BMR: (Block Media Recovery) A feature that allows RMAN to recover only corrupt blocks in a datafile, rather than the entire datafile.

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 command from the RMAN prompt. The syntax of the BLOCKRECOVER command is as follows: BLOCKRECOVER DATAFILE d1 BLOCK b1[,b2...] [DATAFILE d2 BLOCK b3[,b4...]]...

You can specify as many datafiles and data blocks as necessary to repair the corruptions. To repair the corruption of block number 3833 in the D:\oracle\ oradata\ora92\users01.dbf datafile, you would issue the following command:

Block Media Recovery (BMR)

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;

Lesson 5: Recovery Manager Recoveries

295

When the BLOCKRECOVER command is issued, RMAN will locate the last nonincremental 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 incremental 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 command 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. Explain your answer. False. BMR is available only from a full backup; it is not available from incremental backups.

296

Oracle9i Database: Fundamentals II

Topic 5B RMAN Incomplete Recovery Performing an incomplete database recovery with RMAN is very similar to performing a user-managed incomplete recovery. Both methods require the following steps: 1. Mount the database. 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, including 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 operation, 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 specific 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 following 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 incomplete 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';

Lesson 5: Recovery Manager Recoveries

297

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: The SET UNTIL Command

RUN { ALTER DATABASE MOUNT; 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 failure, 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 database 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. 298

Oracle9i Database: Fundamentals II

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; ALTER DATABASE MOUNT; RECOVER DATABASE UNTIL SEQUENCE 68 THREAD 1; ALTER DATABASE OPEN RESETLOGS;

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 recovering 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 control 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

Lesson 5: Recovery Manager Recoveries

299

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 target 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; ALTER DATABASE MOUNT; RECOVER DATABASE UNTIL SEQUENCE 68 THREAD 1; ALTER DATABASE OPEN RESETLOGS;

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.

300

Oracle9i Database: Fundamentals II

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 current 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: 1. Restore all datafiles from backup. 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 database recovery in this scenario: STARTUP MOUNT; RESTORE DATABASE; RECOVER DATABASE UNTIL SEQUENCE 67 THREAD 1; ALTER DATABASE OPEN RESETLOGS;

Lesson 5: Recovery Manager Recoveries

301

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 command, 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; ALTER DATABASE OPEN RESETLOGS; }

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 database 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. Launch SQL*Plus and log in as sys. To force a log switch, type ALTER SYSTEM SWITCH LOGFILE; and press Enter.

302

Oracle9i Database: Fundamentals II

Oracle will display the message “System altered.”

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. At the prompt, issue the following command: CREATE TABLE test_rman_redo (col1 VARCHAR2(5));

Oracle will display the message “Table created.” Insert a row into the table with the following statements: INSERT INTO test_rman_redo VALUES('A'); COMMIT;

Oracle will display the messages “1 row created” and “Commit complete.” The redo information generated from the CREATE TABLE and INSERT

Lesson 5: Recovery Manager Recoveries

303

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. At the prompt, type ALTER SYSTEM SWITCH LOGFILE; and press Enter.

It is normal for the redo log groups to sometimes switch out of sequence from their log group numbers.

Oracle will display the message “System altered.” 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;

Oracle will display the messages “1 row created” and “Commit complete.” 6.

At the prompt, type @C:\079176\logfiles.sql and press Enter. The redo information for the CREATE TABLE and the first INSERT statements 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-

304

Oracle9i Database: Fundamentals II

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 current 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 launch RMAN with the following command: rman target rman/buprec@ora92 nocatalog

Lesson 5: Recovery Manager Recoveries

305

RMAN will launch and connect to the target database using the control file 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 generated when the current online log group was archived. Once the database has been recovered to the specified log sequence number,

306

Oracle9i Database: Fundamentals II

RMAN will display the message “media recovery complete.”

13. The database has been recovered to include all available changes. The current 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 perform 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 catalog is not available. At the RMAN prompt, issue the following command: copy current controlfile to 'D:\oracle\rman_bup\control.bak';

Lesson 5: Recovery Manager Recoveries

307

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 temporary tablespaces are lost. You will add the tempfile back to your temporary tablespace. At the SQL*Plus prompt, issue the following command: ALTER TABLESPACE temp ADD TEMPFILE 'D:\oracle\oradata\ora92\temp01.dbf' REUSE;

Oracle will display the message “Tablespace altered.” 19. Exit from SQL*Plus.

Tablespace Point-in-Time Recovery One of the most involved recovery scenarios is performing a tablespace point-intime 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

308

Oracle9i Database: Fundamentals II

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-intime 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 newlyrecovered 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 absolute 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 following file sets: • Auxiliary set—Consists of the minimum set of files to make the clone database 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 feature 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 pointin-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.

Lesson 5: Recovery Manager Recoveries

309

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 db_file_name_convert

Set to the new name of the clone database. Specifies the directory path where the auxiliary file set will be restored to. Specifies the directory path where the redo logs will be recreated when the clone is opened with the RESETLOGS option. Specifies the directory path and file names where the control files will be restored to. Must be set to FALSE, since the clone must be running in NOARCHIVELOG mode.

log_file_name_convert

control_files log_archive_start

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 parameters 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 necessary 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 recovery 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 directory path and file names for each control file you want to use for the clone.

310

Oracle9i Database: Fundamentals II

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 Windows 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 resolution 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 connect 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 Copyright (c) 1995, 2002, Oracle Corporation. reserved.

All rights

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;

Lesson 5: Recovery Manager Recoveries

311

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 C1 TYPE DISK; 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: RMAN Tablespace Point-inTime Recovery

RUN { ALLOCATE CLONE CHANNEL C1 TYPE DISK; 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 following 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. 312

Oracle9i Database: Fundamentals II

Once the datafiles are imported into the target database, the tablespace is considered 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 auxiliary 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 command in your RMAN script just prior to beginning the recovery process.

3.

All of your backup copies are stored on tape. However, when performing 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.

Lesson 5: Recovery Manager Recoveries

313

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 ✓

5.

d. Transportable tablespaces

Once the RMAN tablespace point-in-time recovery is complete, in what state will RMAN leave the recovered tablespace in the original database? 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;

314

Oracle9i Database: Fundamentals II

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 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 recovery

Your database has suffered a loss of the current redo log group. By looking 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 recovery

Lesson 5: Recovery Manager Recoveries

315

Which files make up the auxiliary set for an RMAN tablespace point-intime 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.

✓

316

Oracle9i Database: Fundamentals II

e. Datafiles of the UNDO tablespace.

Loading and Moving Data

LESSON

6 Overview

Data Files inventory.dat listplan.sql item_ext.sql final_setup.pif

Oracle provides several utilities to load and unload data in and out of the database. For example, the SQL*Loader utility is used to bulk load data from flat ASCII files into the database. The export utility is used to export data from the database into a file in binary format, which can then be 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 large volumes.

Lesson Time 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 external 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. The SQL*Loader Utility

SQL*Loader also comes with comprehensive error reporting capabilities. Any 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 318

Oracle9i Database: Fundamentals II

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 column, 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 conditions 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 UPPER or TO_CHAR, can be applied to the data prior to inserting it into a table. In direct path loading, SQL*Loader reads the data from the flat file, but bypasses the SQL processing engine of the database and stores the data directly in the target 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 loads. The decision to use one over the other will depend on the requirements of the data to be loaded. You will learn how to use both loading methods later in this topic.

The SQL*Loader Control File

conventional path load: A method of loading data into Oracle using standard SQL calls.

direct path load: A method of loading data into Oracle that writes directly to the datablocks in the datafiles, bypassing the 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 SQL*Loader control file. [RECOVERABLE | UNRECOVERABLE] [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]

Refer to the Oracle9i Utilities manual for a complete list of SQL*Loader control file options and keywords.

Lesson 6: Loading and Moving Data

319

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 generated, 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 display 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 320

Oracle9i Database: Fundamentals II

into the first column in the column list, the second column of data into the second 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 columns 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 columns 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.

Lesson 6: Loading and Moving Data

321

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) )

322

Oracle9i Database: Fundamentals II

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 arguments 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. The name of the control file to use for the load, including full path and file name. The path and file name of the bad file where rows that cause errors will be stored. The path and file name of the datafile to load from. The path and file name of the file to store discarded rows. 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. 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. The number of rows to load. The default is all rows. The maximum number of errors to allow before terminating the load. The default is 50. 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. The size of the conventional path bind array in bytes. Suppress all screen-displayed messages during run. Useful for loads run from a batch file or script. Use direct path. Default is FALSE. The path and file name of an option parameter file that contains command line arguments. Perform parallel load (multiple datafiles into a single table). Default is FALSE. The name of the tablespace datafile to first start loading the data. The table may extend out of this datafile if necessary. Size of the read buffer in bytes.

control bad data discard discardmax skip load errors rows

bindsize silent direct parfile parallel file readsize

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.

Lesson 6: Loading and Moving Data

323

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

324

Oracle9i Database: Fundamentals II

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;

Lesson 6: Loading and Moving Data

325

Oracle will display the message “Table created.”

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

326

Oracle9i Database: Fundamentals II

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: sqlldr USERID='sys/ora92@ora92 as sysdba' ⇒ control=c:\079176\inventory.ctl ⇒ log=c:\079176\inventory.log

The double arrow (⇒) indicates that command should be typed on a single line and is not part of the 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

Lesson 6: Loading and Moving Data

327

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:

328

Oracle9i Database: Fundamentals II

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

Issue the following query: The list of items shown in the output may not be listed in the same order that is shown here.

SELECT * FROM item WHERE rownum<=20;

The output will show that the ITEM table now contains the rows of data from the INVENTORY.DAT file.

9.

Exit from SQL*Plus.

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 SQL*Loader performs a direct path load. This can greatly reduce the amount of resources consumed to process the statement, which can significantly increase its performance.

direct load insert: A method of loading data from one table to another using a direct path load.

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 Lesson 6: Loading and Moving Data

329

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. 1.

Launch SQL*Plus and log in as sys. 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.

330

Oracle9i Database: Fundamentals II

You will create an empty table, called ITEM_DIRECT, with a structure identical 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;

Oracle will display the message “Table created.” 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 statement which reads all the rows from the ITEM table and inserts them into the ITEM_DIRECT table. At the prompt, issue the following command: 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. Lesson 6: Loading and Moving Data

331

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 statement 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.” At the prompt, issue the following command: 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 statement and a table access of the ITEM table, just as before, but this time the

332

Oracle9i Database: Fundamentals II

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. At the prompt, issue the following command: INSERT /*+ APPEND */ INTO item_direct SELECT * FROM item;

Oracle will display the message “5000 rows created.” Type COMMIT; and press Enter.

8.

Exit from SQL*Plus.

External Tables Oracle9i provides a feature that enables you to access external data using standard 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 eliminates the need to use a separate process that loads the data into the database before processing it. Oracle provides the clause ORGANIZATION EXTERNAL for the CREATE TABLE command to define external tables.

external table: A table-like structure in Oracle that accesses an external flat file containing 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.

Lesson 6: Loading and Moving Data

333

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 contain 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 FIELDS TERMINATED BY ',' LOGFILE log_dir:'stores_%p.log' BADFILE bad_dir:'stores_%p.bad'

334

Oracle9i Database: Fundamentals II

( 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 provides 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, which is the utility that is to be used to access the external data and pass it to the Oracle database. The default for this clause is ORACLE_LOADER. Currently, ORACLE_LOADER is the only value allowed for the TYPE clause. It is expected that future versions of Oracle may allow additional types of access drivers to access the external files. The DEFAULT DIRECTORY clause specifies the directory to look in to find the datafile. This directory must first be created with the CREATE DIRECTORY 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.

Although the default access driver for external tables, ORACLE_DRIVER, behaves very much like SQL*Loader, it is actually not SQL*Loader. The access driver is a completely different utility that was designed to look and act like SQL*Loader.

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 determine 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 dynamically 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 Lesson 6: Loading and Moving Data

335

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 corresponding 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.

3.

Launch SQL*Plus and log in as sys. 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';

336

Oracle9i Database: Fundamentals II

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 vendor_id item_name descr unit retail_price qty_on_hand

NUMBER(12,0) NUMBER(12,0) VARCHAR2(64) VARCHAR2(1000) VARCHAR2(5) NUMBER(8,2) NUMBER(8,0)

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.

Lesson 6: Loading and Moving Data

337

Create the ITEM_EXT table by issuing the following command from the prompt: The syntax for this CREATE TABLE command is somewhat lengthy. If you have problems typing in the entire command, you can find the exact command in the C:\079176\item_ext.sql file.

CREATE TABLE item_ext ( 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) ) 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' FIELDS TERMINATED BY ',' ( 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.”

338

Oracle9i Database: Fundamentals II

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 following query: SELECT vendor_id, COUNT(item_id) FROM item_ext GROUP BY vendor_id;

Lesson 6: Loading and Moving Data

339

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 external 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. At the prompt, issue the following command: CREATE TABLE higher_items TABLESPACE users AS SELECT * FROM item_ext WHERE retail_price > 40;

Oracle will display the message “Table created.”

9.

To see how many rows exist in your new table, issue the following query: SELECT COUNT(*) FROM higher_items;

340

Oracle9i Database: Fundamentals II

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 provide 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 platform to another.

Lesson 6: Loading and Moving Data

341

The Export Utility Types of Exports

There are five levels of exports, which are table, user, tablespace, transportable 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. However, 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 cannot 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 dictionary relevant to the source tablespaces. The datafiles that make up the tablespace are then copied to the target database, and the data dictionary information is imported back in. You will learn more about transportable tablespace later in this lesson. 342

Oracle9i Database: Fundamentals II

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 equivalent 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 standard 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 performed, 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. Size of the data buffer in bytes. Path and file name of the export file to create. 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. Indicates whether user privileges will be included in the export. The default is Y. Indicates whether indexes will be included in the export. The default is Y. 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. Indicates whether constraints will be included in the export. The default is Y. Path and file name of the log file to record screen output. Indicates whether the export should be done in direct mode. 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. 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. Lists the conditions to filter the data prior to exporting. Indicates whether to perform a full database export. The default is N. Cannot be used in conjunction with owner, tables, or tablespaces. Lists the users to export for a user-level export. Cannot be used in conjunction with full, tables, or tablespaces. Lists the tables to export for a table-level export. Cannot be used in conjunction with full or owner. Specifies the length of the file record in bytes. The default is operating system dependent. Path and file name of optional parameter file to hold export parameters.

buffer file compress grants indexes rows contraints log direct feedback

filesize

query full

owner tables recordlength parfile

Lesson 6: Loading and Moving Data

343

Argument

Value

consistent

Indicates whether constraint-checking should occur during export to keep the tables in the export file consistent. The default is Y. Indicates whether triggers should be included in the export. The default is Y.

triggers

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 344

Oracle9i Database: Fundamentals II

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: exp userid='sys/ora92@ora92 as sysdba' ⇒ 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.

Lesson 6: Loading and Moving Data

345

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_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. 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_scott_emp.dmp ⇒ log=C:\079176\exp_ora92_scott_emp.log ⇒ tables=scott.emp direct=y

346

Oracle9i Database: Fundamentals II

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. 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_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 contents 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.

Lesson 6: Loading and Moving Data

347

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. Size of the data buffer in bytes. Path and file name of the file to import from. Instructs the import utility to only show the contents of the source file. No data will be imported. The default is N. Specifies whether to ignore create errors during import due to the object already existing. The default is N. Indicates whether user privileges will be imported. The default is Y. Indicates whether indexes will be imported. The default is Y. 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. Indicates whether constraints will be imported. The default is Y. Path and file name of the log file to record screen output. 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.

buffer file show ignore grants indexes rows contraints log commit

348

Oracle9i Database: Fundamentals II

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. Clear the contents of the target datafiles prior to importing the data. The default is N. 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. 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. 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. 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. Specifies the length of the file record in bytes. The default is operating system dependent. Path and file name of optional parameter file to hold import parameters. Specifies how to handle object statistics while importing. Possible values include ALWAYS, RECALCULATE, NONE, and SAFE. The default is ALWAYS. 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.

destroy full

fromuser

touser

tables

recordlength parfile statistics

indexfile

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 constraints 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, procedures, 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.

Lesson 6: Loading and Moving Data

349

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. Launch SQL*Plus and log in as sys. 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.

350

Oracle9i Database: Fundamentals II

Leaving the SQL*Plus window open, open a command prompt.

At the prompt, issue the following command as if it was a single line of 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

Lesson 6: Loading and Moving Data

351

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.

4.

352

Oracle9i Database: Fundamentals II

Exit from SQL*Plus.

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 relevant to the tablespaces you are transporting are exported into a dictionary file. The datafiles that make up the tablespaces are then copied over to the target database and the dictionary file is imported. This feature can only be used between two databases that reside on compatible operating systems. Transportable tablespaces provide several advantages over other methods of moving data, including other types of exports and imports. Generally, using 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 and must be of the same character set. You cannot transport a tablespace into a database where a tablespace of the same name already exists. Also, tablespaces being transported cannot contain replication objects or function-based indexes. The owners of the objects in a tablespace to be transported must already exist in the target database. Only the tablespace metadata will be moved over and not the user metadata.

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.

The COMPATIBLE initialization parameter on both the source and target databases must be set to 8.1 or higher.

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.

Lesson 6: Loading and Moving Data

353

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_ VIOLATIONS 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.

354

Oracle9i Database: Fundamentals II

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 generating a transportable tablespace set for the RMAN tablespace, dropping the tablespace, then importing it back in. Launch SQL*Plus and log in as sys. To determine the current status of the RMAN tablespace, issue the following query: SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name='RMAN';

Lesson 6: Loading and Moving Data

355

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 procedure of the DBMS_TTS package. At the prompt, issue the following command: 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

356

Oracle9i Database: Fundamentals II

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. Oracle will display the message “Tablespace altered.”

To confirm that the tablespace is in read-only mode, issue the following query again: SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name='RMAN';

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

Lesson 6: Loading and Moving Data

357

the following command as if it was a single input line: exp userid='sys/ora92@ora92 as sysdba' ⇒ 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.

358

Oracle9i Database: Fundamentals II

Oracle will display the message “Tablespace dropped.”

To confirm that the RMAN tablespace has been dropped, issue the following query again: SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name='RMAN';

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-

Lesson 6: Loading and Moving Data

359

cerning those tables are imported into the data dictionary.

Once the import is done, the last line of the output will state “Import terminated 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: SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name='RMAN';

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. Oracle will display the message “Tablespace altered.”

10. You have successfully transported a tablespace from one database to another. Exit from SQL*Plus.

360

Oracle9i Database: Fundamentals II

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. Setup: Open a window to the C:\079176 folder. Double-click the file named final_setup. A blank command prompt window will appear for several moments, then disappear. Close the C:\079176 window.

See Additional Instructor Notes.

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 accidentally deleted all 50,000 rows from the SH.CUSTOMERS table, and committed the transaction. He states that the contents of the table are absolutely 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 6: Loading and Moving Data

361

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 standard 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

362

Oracle9i Database: Fundamentals II

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.

Lesson 6: Loading and Moving Data

363

364

Oracle9i Database: Fundamentals II

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

366

Oracle9i Database: Fundamentals II

GLOSSARY application program interface An interface provided by a software vender that accepts procedural calls from a custom application to the vendor’s software. archive log A copy of a redo log that has been filled and switched out as the current log group. Archive logs are used to apply changes to a backup to bring it up to date during recovery. backup mode A special mode for tablespaces that allows them to be copied while the database is up and running. 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. before image The original version of data before it was changed by a transaction. bequeath connection A single-task database connection where the client and server reside on the same machine. BMR (Block Media Recovery) A feature that allows RMAN to recover only corrupt blocks in a datafile, rather than the entire datafile. centralized naming A names resolution method that stores all the connect descriptors in a centrallylocated repository. All clients needing to resolve connect descriptors contact the central repository. checksum A hash value generated by reading a single piece of data.

client-server architecture A configuration where multiple clients connect to a single server. clone database A database created by restoring and recovering the hot backup of another database to another location. cold backup A full backup of the database while the database is shut down. communication channel A dedicated connection between RMAN and the target database complete recovery A database recovery where all changes to the database are recovered right up to the point of failure. connect descriptor The full connection definition for a net service name. connection pooling The technique of pooling multiple client connections into a group of fewer database connections. conventional path load A method of loading data into Oracle using standard SQL calls. CORBA (Common Object Request Broker Architecture) Architecture that provides an industrywide standard of accessing various types of data sources through a network crosscheck A process of validating recovery catalog entries against the backup files that actually exist in the file system. dead connection detection A feature of Oracle Net that automatically detects terminated client sessions and handles the release of database resources. Glossary

367

GLOSSARY direct load insert A method of loading data from one table to another using a direct path load. direct path load A method of loading data into Oracle that writes directly to the datablocks in the datafiles, bypassing the SQL processing engine. dispatcher A background process in a shared server configuration that accepts database requests from user processes and passes them to shared server processes. DNS (Domain Names System) A server that is used to resolve matching host names to their respective IP addresses. external naming A names resolution method similar to external naming, except the central repository is a non-Oracle, third-party product. external table A table-like structure in Oracle that accesses an external flat file containing data. global database name A database identifier to uniquely identify a single database on a network. heterogeneous connectivity A feature that allows an Oracle client to use standard Oracle SQL and procedure calls to seamlessly access non-Oracle data sources. host naming A names resolution method that uses the client’s HOSTS file to locate the target database on the network.

368

Oracle9i Database: Fundamentals II

hot backup A backup of the database, either full or partial, performed while the database remains up and running. IIOP (Internet Inter-ORB Protocol) A presentation protocol designed to implement CORBA technologies across the Internet. image copy A type of backup file created by RMAN which is a bit-for-bit image of the original file. incarnation A new version of a database created when the database is opened with the RESETLOGS option. incomplete recovery A database recovery where not all changes to the database are recovered. incremental backup A backup of the database that includes only the datablocks that have changed since a previous incremental backup instead of all datablocks that contain data. Java Database Connectivity An industry standard connectivity interface for applications that make use of Java programming on the client to connect to a database source, also known as JDBC. listener A constantly running process that listens on the network for incoming connection requests. local naming A names resolution method that is used to resolve net service names by looking up their connect descriptors in a definition file stored locally on the client’s machine.

GLOSSARY MML (Media-management layer) Third-party backup utilities that can integrate with RMAN to help perform backup and recoveries of the database. MTBF (Mean time between failures) The average amount of time that passes between failures of a system. MTTR (Mean time to recovery) The average amount of time it takes to recover a system after a failure. multi-protocol connectivity A configuration that supports several different client protocols to connect to a single database. N-tier configuration A multi-level configuration where each component of a system, such as client, application, and database, resides at its own tier. names resolution method A configured method that is used to translate a net service name to the network address where the intended database resides.

Oracle Net tracing A feature that, when enabled, allows Oracle to write out to a trace file every internal step taken to establish a database connection, usually generates much more detailed output than standard logging. PGA (Program Global Area) The memory area at the OS level on the server that stores a user’s session data while the user is connected to the database. recovery catalog A database schema that can act as the backup and recovery information repository for RMAN. retention policy The policy used by RMAN to determine which database backups in its recovery catalog are still valid. SCN (System Change Number) A sequential numbering system Oracle uses to track every change in the database. shared server process A single server process that can support database requests from multiple clients simultaneously.

net service name An alias for a destination database a client wishes to connect to.

single-task connection A connection where the client user and server process are one in the same.

network stack A series of layers that a network connection between a client and server must pass through.

system identifier The identifying name for a database.

Oracle Net logging A feature that, when enabled, allows Oracle to log all informational entries to a specified log file for troubleshooting purposes.

tnsping utility A utility that is used to time the round trip of a network packet from the client to the listener and back.

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.

370

Oracle9i Database: Fundamentals II

INDEX 3DES encryption See: Advanced Security Option

A Advanced Security Option 3DES encryption, 20-22 DES encryption, 20-22 RC4 algorithm, 20-22 archive logs backing up with RMAN, 252-254 ARCHIVELOG mode configuring, 127-135 archiver (ARCH) process, 109

B backup cold, 114-120 cold, RMAN, 236-243 control file, 148-153 hot, 127-135 hot, RMAN, 243-245 read-only tablespaces, 153-154 resolving failed hot backup, 154-158 RMAN, 236-243 user-managed, 142-147 backup sets See: RMAN bequeath connection See: user connection process block corruption, 168-171 Also see: block media recovery Block Media Recovery See: BMR block media recovery (BMR), 295-296 Also see: RMAN BMR, 295-296

C centralized naming See: names resolution methods checkpoint (CKPT) process, 110 client-server architecture, 3-6 cold backup

definition, 101-103 complete recovery See: recovery connect descriptor, 9, 10 Connection Manager connection pooling, 18-20 multi-protocol connectivity, 18-20 connection pooling See: Connection Manager connection process See: user connection process control file, 111, 210-212, 298-300, 209-213 Also see: RMAN loss of, 180-188 CORBA, 87-90

D database writer (DBWR) process, 110-111 DES encryption See: Advanced Security Option direct load inserts, 329-333 dispatcher process, 76-77, 81-82

E export types, 342-344 external naming See: names resolution methods external tables, 333-341

F failures instance failure, 98 media failure, 98 session failure, 97 statement, 96 transaction failure, 96-97

G GIOP, 87-90

H heterogeneous connectivity, 22-23

Index

371

INDEX host naming See: names resolution methods hot backup definition, 101-103 HTTP/FTP presentations See: layered architecture

I IIOP, 87-90 image copies See: RMAN import types, 348-352 incomplete recovery See: recovery incremental backups See: RMAN inserts direct load, 329-333 instance failure See: failures instance recovery See: recovery

J Java client communication stack See: layered architecture Java thin client, 15-16 JDBC, 15-16

L layered architecture Java client communication stack, 15-16 OCI layer, 13-15 OPI layer, 13-15 Oracle communication stack, 13-15 Oracle communications stack, 12-18 Web client communication stack, 16-17 Listener Control utility (lsnrctl), 35-41 listener process, 11 configuring for Web clients, 87-90 Also see: layered architecture creating, 25-27

372

Oracle9i Database: Fundamentals II

creating manually, 42-46 Also see: Listener Control utility (lsnrctl) Listener Control utility (lsnrctl), 35-41 local naming See: names resolution methods log writer (LGWR) process, 109 logging Oracle Net, 66-68 lsnrctl See: Listener Control utility (lsnrctl)

M media failure See: failures media recovery See: recovery MTBF, 100-105 MTS See: Oracle Shared Server MTTR, 100-105 multi-protocol connectivity See: Connection Manager Multi-threaded Server See: Oracle Shared Server

N N-tier architecture, 3-6 names resolution methods centralized naming, 46-49 external naming, 46-49 host naming, 46-49 local naming, 46-49, 55-64 net service name, 9, 10 networking client-side configuration, 46-49 server-side configuration, 25-35 troubleshooting, 64-74 Also see: tnsping utility Web client configuration, 87-90 Also see: layered architecture

INDEX O Oracle communications stack See: layered architecture Oracle Net components, 5-6 logging, 66-68 tracing, 66-68 Oracle Shared Server, 74-80 configuring, 80-83 monitoring and tuning, 83-87 OSS See: Oracle Shared Server

R RC4 algorithm See: Advanced Security Option read-only tablespaces, 196-199 recovery cold, 114-120, 127-135 complete, 104 complete, RMAN, 286-292 hot, 135-138 incomplete, 104, 177-178 incomplete, repercussions, 178-179 incomplete, RMAN, 297-301 loss of control file, 180-188, 298-300 loss of current log group, 189-196, 301-308 no backup, 172 read-only tablespaces, 196-199 structures, 105-114 trial recovery, 168-171 user-managed, 142-147 user-managed, complete, 159-168 user-managed, incomplete, 176-180 recovery catalog See: RMAN backing up, 277-279 stored scripts, 254-259 redo log, 301-308 loss of current group, 189-196 redo log buffer, 107 redo log files, 107-108 restoring datafiles

, 171-176 RMAN architecture, 207-209 archive logs, 252-254 backup sets, 217-219 backup validation, 275-276 backups, 236-243 block media recovery (BMR), 295-296 cataloging OS-level backups, 272-274 complete recovery, 286-292 configuration parameters, 229-235 configuring, 219-222 crosscheck, 266-272 deleting backup sets, 266-272 hot backups, 243-245 image copies, 217-219, 238-239 incomplete recovery, 297-301 incremental backups, 245-252 lists, 259-266 loss of control file, 298-300 loss of current log group, 301-308 process flow, 213-217 recovery catalog, 212, 222-226, 254-259, 277-279 registering a database, 227-229 reports, 259-266 repository, 209-213 restore, 286-287 restore validation, 275-276 tablespace point-in-time recovery, 308-314

S session failure See: failures shared server process, 76-77, 82 single-task connection See: user connection process SQL*Loader, 318-329 commands, 323-324 control file, 319-321 datafile formats, 321-323 statement failure See: failures system monitor (SMON) process, 109

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

374

Oracle9i Database: Fundamentals II