11g workshop 2 studentguide 1

Oracle Database 11g: Administration Workshop IIVolume I Student Guide

D50079GC10 Edition 1.0 D53298

November 2007

al rn nte eI cl ra O

nly eO Us AI O &

AuthorsTom Best James Spiller James Womack Maria Billings

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

Technical Contributors and ReviewersSharath Bhujani Timothy Chien Al Flournoy Andy Fortunak Gerlinde Frenzen Joel Goodman Magnus Isaksson Pete Jones Donna Keesling Pierre Labrousse Gwen Lazenby Jerry Lee Hakan Lindfors Isabelle Marchand Srinivas Putrevu Andreas Reinhardt Ira Singer

EditorsArijit Ghosh Amitha Narayan Atanu Raychaudhuri

Graphic DesignerRajiv Chandrabhanu

Publishers

Nita Brozowski Giri Venugopal


nly eO Us AI O &

Contents

1


Database Architecture and ASM Objectives 1-2 The Oracle Database 1-3 Oracle Database Architecture: Overview 1-4 Connecting to the Database 1-5 Oracle Database Server Structures 1-6 Oracle Memory Architecture 1-7 Process Architecture 1-9 Process Structures 1-10 Database Storage Architecture 1-12 Logical and Physical Database Structures 1-14 Tablespaces and Data Files 1-16 SYSTEM and SYSAUX Tablespaces 1-17 Segments, Extents, and Blocks 1-18 Database Architecture: Summary of Structural Components 1-19 Automatic Storage Management: Review 1-20 ASM: General Architecture 1-22 Creating an ASM Instance 1-23 ASM Instance Initialization Parameters 1-24 Starting Up an ASM Instance 1-25 SYSASM Role 1-26 Accessing an ASM Instance 1-27 Using Enterprise Manager to Manage ASM Users 1-28 Shutting Down an ASM Instance 1-29 ASM Storage: Concepts 1-30 ASM Disk Group 1-31 Failure Group 1-33 Disk Group Mirroring 1-34 Disk Group Dynamic Rebalancing 1-35 Managing Disk Groups 1-36 Creating and Dropping Disk Groups 1-37 Adding Disks to Disk Groups 1-38 ASM Disk Group Compatibility 1-39 ASM Disk Group Attributes 1-41 Using Enterprise Manager to Edit Disk Group Attributes 1-42

nly eO Us AI O &

iii

Miscellaneous ALTER Commands 1-43 ASMCMD Utility 1-44 ASM Scalability and Performance 1-46 Summary 1-48 Practice 1 Overview: Database Architecture and ASM 1-49 2 Configuring for Recoverability Objectives 2-2 Purpose of Backup and Recovery Functionality 2-3 Typical Backup and Recovery Tasks 2-4 Oracle Backup and Recovery Solutions 2-6 Using Recovery Manager 2-7 Types of RMAN Commands 2-9 Job Commands: Example 2-10 Configuring Your Database for Backup and Recovery Operations 2-11 ARCHIVELOG Mode 2-12 Configuring ARCHIVELOG Mode 2-13 Configuring Archive Log Destinations 2-15 Guaranteeing Archive Log Success 2-17 Specifying a Backup Destination 2-19 Specifying a Retention Policy 2-21 A Recovery Window Retention Policy: Example 2-23 Using a Flash Recovery Area 2-24 Defining a Flash Recovery Area 2-26 Defining a Flash Recovery Area Using Enterprise Manager 2-27 Flash Recovery Area Space Management 2-28 Flash Recovery Area Space Usage 2-30 Monitoring the Flash Recovery Area 2-32 Benefits of Using a Flash Recovery Area 2-33 Summary 2-34 Practice 2 Overview: Configuring for Recoverability 2-35

al rn nte eI cl ra O3

nly eO Us AI O &

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

Managing Target Database Records in the Recovery Catalog 3-10 Registering a Database in the Recovery Catalog 3-11 Using Enterprise Manager to Register a Database 3-12 Registering a Duplicated Database 3-15 Changing the DBID of a Database 3-16 Unregistering a Target Database from the Recovery Catalog 3-17 Cataloging Additional Backup Files 3-18 Recovery Catalog Resynchronization: Concepts 3-20 Manually Resynchronizing the Recovery Catalog 3-21 Using RMAN Stored Scripts 3-22 Creating RMAN Stored Scripts 3-23 Executing RMAN Stored Scripts 3-24 Displaying RMAN Stored Script Information 3-25 Updating and Deleting RMAN Stored Scripts 3-26 Backing Up the Recovery Catalog 3-27 Re-Creating an Unrecoverable Recovery Catalog 3-28 Exporting and Importing the Recovery Catalog 3-29 Upgrading the Recovery Catalog 3-30 Dropping the Recovery Catalog 3-31 Using a Virtual Private Catalog 3-32 Creating an RMAN Virtual Private Catalog 3-34 Summary 3-36 Practice 3 Overview: Using the RMAN Recovery Catalog 3-37 4 Configuring Backup Specifications Objectives 4-2 Using RMAN to Create Backups 4-3 Backup Destinations 4-4 Configuring Persistent Settings for RMAN 4-5 Using Enterprise Manager to Configure RMAN Settings 4-6 Control File Autobackups 4-7 Managing Persistent Settings 4-9 Configuring Devices for Backup 4-10 Configuring and Allocating Channels for Use in Backups 4-12 Configuring Backup Optimization 4-13 Summary 4-15 Practice 4 Overview: Configuring Backup Specifications 4-16

al rn nte eI cl ra O5 Using RMAN to Create Backups Objectives 5-2 Creating Backup Sets 5-3

nly eO Us AI O &

v


Creating Image Copies 5-4 Creating a Whole Database Backup 5-6 Saving Backup Space with Unused Block Compression 5-8 RMAN Backup Types 5-9 Fast Incremental Backup 5-11 Enabling Fast Incremental Backup 5-12 Monitoring Block Change Tracking 5-13 Creating Duplexed Backup Sets 5-14 Creating Duplexed Backup Sets Using CONFIGURE BACKUP COPIES 5-15 Creating Duplexed Backup Sets Using BACKUP COPIES 5-16 Creating Backups of Backup Sets 5-17 Backing Up Read-Only Tablespaces 5-18 Archival Backups: Concepts 5-19 Creating Archival Backups with EM 5-21 Creating Archival Backups with RMAN 5-22 Managing Archival Database Backups 5-23 Multisection Backups: Overview 5-24 Creating RMAN Multisection Backups 5-25 Compressing Backups 5-26 Encrypting Backups 5-27 Backing Up Recovery Files 5-29 Using a Media Manager 5-30 Performing Proxy Copies 5-32 Creating an Oracle-Suggested Backup 5-33 Managing Backups: Reporting 5-34 Managing Backups: Dynamic Performance Views 5-36 Using Enterprise Manager to View Backup Reports 5-37 Managing Backups: Cross-Checking and Deleting 5-38 Summary 5-39 Practice 5 Overview: Creating Backups 5-40

Performing User-Managed Backup and Recovery Objectives 6-2 Restoring and Recovering 6-3 Causes of File Loss 6-4 Critical Versus Noncritical 6-5 Losing a TEMPFILE 6-6 Recovering from a TEMPFILE Loss 6-7 Log Group Status: Review 6-8 Recovering from the Loss of a Redo Log Group 6-9 Clearing a Log File 6-10vi

nly eO Us AI O &


Re-Creating Indexes 6-11 Recovering from a Lost Index Tablespace 6-13 Authentication Methods for Database Administrators 6-14 Re-Creating a Password Authentication File 6-15 Comparing Complete and Incomplete Recovery 6-17 Complete Recovery Process 6-18 Incomplete Recovery Process 6-19 Types of Backup and Recovery Practices 6-21 Performing a User-Managed Backup of the Database 6-22 The Need for Backup Mode 6-23 Identifying Files to Manually Backup 6-24 Manually Backing Up a NOARCHIVELOG Database 6-25 Manually Backing Up an ARCHIVELOG Database 6-26 Backing Up the Control File 6-27 Performing User-Managed Complete Database Recovery: Overview 6-28 Performing Complete Closed Database Recovery: Overview 6-29 Identifying Recovery-Related Files 6-30 Restoring Recovery-Related Files 6-31 Applying Redo Data 6-33 Performing Complete Open Database Recovery 6-34 Performing User-Managed Incomplete Recovery: Overview 6-36 Choosing an Incomplete Recovery Method 6-37 Performing User-Managed Incomplete Recovery 6-38 Performing User-Managed Incomplete Recovery: Steps 6-40 User-Managed Time-Based Recovery: Example 6-41 User-Managed Cancel-Based Recovery: Example 6-43 Recovering a Read-Only Tablespace 6-45 Recovering NOLOGGING Database Objects 6-46 Recovering from the Loss of All Control File Copies: Overview 6-47 Recovering the Control File to the Default Location 6-48 Summary 6-49 Practice 6 Overview: Performing User-Managed Recovery 6-50

nly eO Us AI O &

Using RMAN to Perform Recovery Objectives 7-2 Using RMAN RESTORE and RECOVER Commands 7-3 Performing Recovery Using Enterprise Manager 7-4 Performing Complete Recovery: Loss of a Noncritical Data File in ARCHIVELOG Mode 7-5 Performing Complete Recovery: Loss of a System-Critical Data File in ARCHIVELOG Mode 7-6vii

Recovering Image Copies 7-7 Recovering Image Copies: Example 7-8 Performing a Fast Switch to Image Copies 7-10 Using SET NEWNAME for Switching Files 7-11 Performing Restore and Recovery of a Database in NOARCHIVELOG Mode 7-12 Creating Restore Points 7-13 Performing Incomplete Recovery 7-14 Performing Recovery with a Backup Control File 7-16 Restoring the Server Parameter File from the Control File Autobackup 7-17 Restoring the Control File from Autobackup 7-18 Using Incremental Backups to Recover a Database in NOARCHIVELOG Mode 7-20 Restoring and Recovering the Database on a New Host 7-21 Preparing to Restore the Database to a New Host 7-22 Restoring the Database to a New Host 7-23 Performing Disaster Recovery 7-27 Summary 7-29 Practice 7 Overview: Using RMAN to Perform Recovery 7-30 8 Using RMAN to Duplicate a Database Objectives 8-2 Using RMAN to Create a Duplicate Database 8-3 Using a Duplicate Database 8-4 Creating a Duplicate Database 8-5 Creating an Initialization Parameter File for the Auxiliary Instance 8-6 Specifying Parameters for Control File Naming 8-7 Starting the Instance in NOMOUNT Mode 8-9 Ensuring That Backups and Archived Redo Log Files Are Available 8-10 Allocating Auxiliary Channels 8-11 Using the RMAN DUPLICATE Command 8-12 Understanding the RMAN Duplication Operation 8-13 Specifying Options for the DUPLICATE Command 8-14 Using EM to Clone a Database 8-15 Cloning a Running Database 8-16 Cloning a Database from a Backup 8-20 Summary 8-21 Practice 8 Overview: Using RMAN to Duplicate a Database 8-22 Performing Tablespace Point-in-Time Recovery Objectives 9-2 Tablespace Point-in-Time Recovery (TSPITR): Concepts 9-3


nly eO Us AI O &

viii

Tablespace Point-in-Time Recovery (TSPITR): Terminology 9-4 Tablespace Point-in-Time Recovery: Architecture 9-5 When to Use TSPITR 9-7 Preparing for TSPITR 9-8 Determining the Correct Target Time 9-9 Determining the Tablespaces for the Recovery Set 9-10 Identifying Objects That Will Be Lost 9-11 Performing Basic RMAN TSPITR 9-12 Performing Fully Automated TSPITR 9-13 Using Enterprise Manager to Perform TSPITR 9-14 RMAN TSPITR Processing 9-15 Performing RMAN TSPITR with an RMAN-Managed Auxiliary Instance 9-17 Performing RMAN TSPITR Using Your Own Auxiliary Instance 9-18 Troubleshooting RMAN TSPITR 9-19 Summary 9-21 Practice 9 Overview: Performing TSPITR 9-22 10 Monitoring and Tuning RMAN Objectives 10-2 Parallelization of Backup Sets 10-3 Monitoring RMAN Sessions 10-5 Monitoring RMAN Job Progress 10-7 Interpreting RMAN Message Output 10-9 Using the DEBUG Option 10-10 Interpreting RMAN Error Stacks 10-11 Tuning RMAN 10-12 RMAN Multiplexing 10-14 Allocating Disk Buffers: Example 10-15 Allocating Tape Buffers 10-16 Comparing Synchronous and Asynchronous I/O 10-18 Monitoring RMAN Job Performance 10-20 Asynchronous I/O Bottlenecks 10-21 Synchronous I/O Bottlenecks 10-22 Tape Backup Speed 10-23 Tape Subsystem Performance Rules 10-25 Controlling Tape Buffer Size with BLKSIZE 10-26 Channel Tuning 10-27 Tuning the BACKUP Command 10-29 Tuning RMAN Backup Performance 10-31 Setting LARGE_POOL_SIZE 10-32 Tuning RMAN Tape Streaming Performance Bottlenecks 10-33ix


nly eO Us AI O &

Summary 10-35 Practice 10 Overview: Monitoring and Tuning RMAN 10-36 11 Using Flashback Technology Objectives 11-2 Flashback Technology 11-3 Transactions and Undo 11-4 Guaranteeing Undo Retention 11-5 Preparing Your Database for Flashback 11-6 Flashback Drop and the Recycle Bin 11-8 Recycle Bin 11-9 Restoring Tables from the Recycle Bin 11-11 Recycle Bin: Automatic Space Reclamation 11-12 Recycle Bin: Manual Space Reclamation 11-13 Bypassing the Recycle Bin 11-14 Querying the Recycle Bin 11-15 Querying Data from Dropped Tables 11-16 Using Flashback Technology to Query Data 11-17 Flashback Query 11-18 Flashback Query: Example 11-19 Flashback Version Query 11-20 Using Enterprise Manager to Perform Flashback Version Query 11-21 Flashback Version Query: Considerations 11-22 Flashback Transaction Query 11-23 Using Enterprise Manager to Perform Flashback Transaction Query 11-24 Flashback Transaction Query: Considerations 11-25 Flashback Transaction 11-26 Prerequisites 11-27 Flashing Back a Transaction 11-28 Possible Workflow 11-29 Viewing Data 11-30 Flashback Transaction Wizard 11-31 Choosing Other Back-out Options 11-35 Final Steps Without EM 11-37 Summary 11-38 Practice 11 Overview: Performing Flashback Database 11-39 12 Additional Flashback Operations Objectives 12-2 Flashback Table: Overview 12-3 Flashback Table 12-4


nly eO Us AI O &

x

Enabling Row Movement on a Table 12-5 Performing Flashback Table 12-6 Flashback Table: Considerations 12-7 Flashback Database 12-8 Flashback Database Architecture 12-9 Configuring Flashback Database 12-10 Configuring Flashback Database Using EM 12-11 Flashback Database: Examples 12-13 Performing Flashback Database Using EM 12-14 Excluding Tablespaces from Flashback Database 12-17 Flashback Database Considerations 12-18 Guaranteed Restore Points 12-19 Flashback Database and Guaranteed Restore Points 12-20 Monitoring Flashback Database 12-22 Monitoring Flashback Database with EM 12-24 Flashback Data Archive 12-25 Flashback Data Archive Process 12-26 Flashback Data Archive Scenario 12-27 Viewing Flashback Data Archives 12-29 Flashback Data Archive DDL Restrictions 12-30 Summary 12-31 Practice 12 Overview: Working with Flashback Database 12-32 13 Diagnosing the Database Objectives 13-2 Automatic Diagnostic Workflow 13-3 Automatic Diagnostic Repository 13-4 The ADR Command-Line Tool, ADRCI 13-5 The V$DIAG_INFO View 13-6 Location for Diagnostic Traces 13-7 Viewing the Alert Log Using Enterprise Manager 13-8 EM Support Workbench: Overview 13-9 Support Workbench and Oracle Configuration Manager 13-10 EM Support Workbench Roadmap 13-11 Viewing Critical Error Alerts in Enterprise Manager 13-12 Viewing Problem Details 13-13 Viewing Incident Details 13-14 Creating a Service Request 13-16 Packaging and Uploading Diagnostic Data to Oracle Support 13-17 Tracking the SR 13-18 Implementing Repairs 13-19xi


nly eO Us AI O &

Closing Incidents and Problems 13-20 Incident Packaging Configuration 13-21 Custom Packaging: Creating a New Package 13-22 Custom Packaging: Manipulating an Incident Package 13-23 Custom Packaging: Finalizing an Incident Package 13-24 Custom Packaging: Generating a Package 13-25 Custom Packaging: Uploading a Package 13-26 Viewing and Modifying Incident Packages 13-27 Health Monitor: Overview 13-28 Running Health Checks Manually: EM Example 13-29 Running Health Checks Manually: PL/SQL Example 13-30 Viewing HM Reports Using the ADRCI Utility 13-31 What Is Block Corruption? 13-32 Block Corruption Symptoms: ORA-01578 13-33 How to Handle Corruption 13-34 Verifying Block Integrity in Real Time: DB_BLOCK_CHECKING 13-35 Block Media Recovery 13-36 Prerequisites for Block Media Recovery 13-37 The RECOVER...BLOCK Command 13-38 Data Recovery Advisor 13-39 Data Recovery Advisor: RMAN Command-Line Interface 13-40 Listing of Data Failures 13-41 Advising on Repair 13-43 Executing Repairs 13-44 Classifying (and Closing) Failures 13-45 Data Recovery Advisor Views 13-46 Summary 13-47 Practice 13 Overview: Diagnosing the Database 13-48 14 Managing Memory Objectives 14-2 Memory Management: Overview 14-3 Oracle Memory Structures 14-4 Buffer Cache 14-6 Using Multiple Buffer Pools 14-8 Shared Pool 14-10 Large Pool 14-11 Java Pool 14-12 Redo Log Buffer 14-13 Automatic Memory Management: Overview 14-14 Oracle Database Memory Parameters 14-15xii


nly eO Us AI O &

Automatic Memory Parameter Dependency 14-16 Enabling Automatic Memory Management with EM 14-18 Monitor Automatic Memory Management 14-19 Monitoring Automatic Memory Management 14-20 Automatic Shared Memory Management: Overview 14-21 How ASMM Works 14-22 Enabling Automatic Shared Memory Management 14-23 Behavior of Autotuned SGA Parameters 14-24 Behavior of Manually Tuned SGA Parameters 14-25 Using the V$PARAMETER View 14-26 Modifying the SGA_TARGET Parameter 14-27 Disabling ASMM 14-28 Manually Resizing Dynamic SGA Parameters 14-29 Program Global Area (PGA) 14-30 Automatic PGA Memory Management 14-32 PGA Management Resources 14-33 Using the Memory Advisor to Size the SGA 14-34 Efficient Memory Usage: Guidelines 14-36 Memory Tuning Guidelines for the Library Cache 14-38 Summary 14-40 Practice 14 Overview: Using AMM to Correct a Memory Allocation Problem 14-41 15 Managing Database Performance Objectives 15-2 Tuning Activities 15-3 Performance Planning 15-4 Instance Tuning 15-6 Performance Tuning Methodology 15-7 Performance Monitoring 15-8 Performance Tuning Data 15-9 Optimizer Statistics Collection 15-10 Oracle Wait Events 15-12 System Statistics 15-13 Monitoring Session Performance 15-15 Displaying Session-Related Statistics 15-16 Displaying Service-Related Statistics 15-17 Troubleshooting and Tuning Views 15-18 Dictionary Views 15-19 Automatic Workload Repository 15-20 SQL Tuning 15-22 SQL Advisors 15-23xiii


nly eO Us AI O &

Automatic SQL Tuning Results 15-24 Implement Automatic Tuning Recommendations 15-25 SQL Tuning Advisor: Overview 15-26 Using the SQL Tuning Advisor 15-27 SQL Tuning Advisor Options 15-28 SQL Tuning Advisor Recommendations 15-29 Using the SQL Tuning Advisor: Example 15-30 SQL Tuning Advisor: Identifying Duplicate SQL 15-31 SQL Access Advisor: Overview 15-32 Typical SQL Access Advisor Session 15-33 Workload Source 15-34 Recommendation Options 15-35 Reviewing Recommendations 15-37 Database Replay 15-38 System Architecture: Capture 15-39 System Architecture: Processing the Workload 15-40 System Architecture: Replay 15-41 The Big Picture 15-42 Workloads Supported 15-43 Using Enterprise Manager for Workload Capture 15-44 Using Enterprise Manager for Workload Replay 15-45 Summary 15-46 Practice 15 Overview: Monitor Instance Performance 15-47 16 Space Management Objectives 16-2 Space Management: Overview 16-3 Free Space Management Within Segments 16-4 Types of Segments 16-5 Allocating Extents 16-6 Block Space Management 16-7 Row Chaining and Migration 16-8 Proactive Tablespace Monitoring 16-9 Thresholds and Resolving Space Problems 16-10 Monitoring Tablespace Space Usage 16-11 Shrinking Segments 16-12 Results of Shrink Operation 16-13 Reclaiming Space Within ASSM Segments 16-14 Segment Advisor: Overview 16-15 Segment Advisor 16-16 Implementing Recommendations 16-17xiv


nly eO Us AI O &

Automatic Segment Advisor 16-18 Manual Segment Shrink Using EM 16-19 Shrinking Segments Using SQL 16-20 Managing Resumable Space Allocation 16-21 Using Resumable Space Allocation 16-22 Resuming Suspended Statements 16-24 What Operations are Resumable? 16-26 Transporting Tablespaces 16-27 Concept: Minimum Compatibility Level 16-28 Minimum Compatibility Level 16-29 Transportable Tablespace Procedure 16-30 Determining the Endian Format of a Platform 16-31 Transportable Tablespaces with Enterprise Manager 16-33 Transporting Databases 16-36 Database Transportation Procedure: Source System Conversion 16-37 Database Transportation Procedure: Target System Conversion 16-38 Database Transportation: Considerations 16-39 Summary 16-40 Practice 16 Overview: Managing Storage 16-41 17 Managing Resources Objectives 17-2 Database Resource Manager: Overview 17-3 Database Resource Manager: Concepts 17-4 Why Use Resource Manager 17-5 Accessing Resource Plans 17-7 Default Maintenance Resource Manager Plan 17-8 Example: DEFAULT_PLAN 17-9 Creating a New Resource Plan 17-10 Creating Consumer Groups 17-11 Assigning Users to Consumer Groups 17-12 Specifying Resource Plan Directives 17-13 Resource Allocation Methods for Resource Plans 17-14 Comparison of EMPHASIS and RATIO 17-15 Active Session Pool Mechanism 17-17 Setting the Active Session Pool 17-18 Specifying Thresholds: Execution Time Limit 17-20 Setting Idle Timeouts 17-21 Resource Consumer Group Mapping 17-22 Activating a Resource Plan 17-24 Database Resource Manager Information 17-25xv


nly eO Us AI O &

Monitoring the Resource Manager 17-26 Summary 17-29 Practice 17 Overview: Using the Resource Manager 17-30 18 Automating Tasks with the Scheduler Objectives 18-2 Simplifying Management Tasks 18-3 A Simple Job 18-4 Key Components and Steps 18-5 1. Creating a Program 18-6 2. Creating and Using Schedules 18-7 3. Creating and Running a Job 18-8 4. Monitoring a Job 18-9 Using a Time-Based or Event-Based Schedule 18-10 Creating a Time-Based Job 18-11 Persistent Lightweight Jobs 18-13 Choosing the Right Job 18-14 Creating a Single Lightweight Job 18-16 Creating an Event-Based Schedule 18-17 Creating Event-Based Schedules with Enterprise Manager 18-18 Creating an Event-Based Job 18-19 Event-Based Scheduling 18-20 Creating Complex Schedules 18-22 Creating Job Chains 18-23 Example of a Chain 18-25 1. Creating a Chain Object 18-26 2. Defining Chain Steps 18-27 3. Defining Chain Rules 18-28 4. Starting the Chain 18-29 Monitoring Job Chains 18-30 Summary 18-31 Practice 18 Overview: Automating Tasks with the Scheduler 18-32 19 Administering the Scheduler Objectives 19-2 Advanced Scheduler Features 19-3 Job Classes 19-4 Creating a Job Class 19-6 Windows 19-7 Creating a Window 19-8 Prioritizing Jobs Within a Window 19-10xvi


nly eO Us AI O &

Creating an Array of Lightweight Jobs 19-11 Creating Lightweight Jobs 19-12 Viewing Lightweight Jobs in Dictionary 19-14 PL/SQL APIs 19-15 Generic Scheduler Data Dictionary Views 19-16 Summary 19-18 20 Globalization Objectives 20-2 Globalization Support Features 20-3 What Every DBA Needs to Know 20-4 What Is a Character Set? 20-5 Understanding Unicode 20-7 How Are Character Sets Used? 20-9 Problems to Avoid 20-10 Another Sample Problem 20-11 Choosing Your Character Set 20-12 Database Character Sets and National Character Sets 20-13 Obtaining Character Set Information 20-14 Specifying Language-Dependent Behavior 20-15 Specifying Language-Dependent Behavior for the Session 20-16 Language- and Territory-Dependent Parameters 20-17 Specifying Language-Dependent Behavior 20-19 Linguistic Searching and Sorting 20-20 Using Linguistic Searching and Sorting 20-22 Case- and Accent-Insensitive Search and Sort 20-24 Support in SQL and Functions 20-25 Linguistic Index Support 20-26 Customizing Linguistic Searching and Sorting 20-27 Implicit Conversion Between CLOB and NCLOB 20-29 NLS Data Conversion with Oracle Utilities 20-30 NLS Data Conversion with Data Pump 20-32 The Language and Character Set File Scanner (LCSSCAN) 20-33 Setting the Database Time Zone 20-34 Summary 20-35 Practice 20 Overview: Using Globalization Support 20-36

al rn nte eI cl ra OA Practices and Solutions Index

nly eO Us AI O &

xvii


nly eO Us AI O &

Database Architecture and ASM

Copyright 2007, Oracle. All rights reserved.


nly eO Us AI O &

ObjectivesAfter completing this lesson, you should be able to: Describe the Oracle Database architecture Describe Automatic Storage Management (ASM) Set up initialization parameter files for ASM and database instances Start up and shut down ASM instances Administer ASM disk groups



nly eO Us AI O &

Oracle Database 11g: Administration Workshop II 1 - 2

The Oracle DatabaseThe Oracle Relational Database Management System (RDBMS) is a database management system that provides an open, comprehensive, integrated approach to information management.


The Oracle Database A database is a collection of data treated as a unit. The purpose of a database is to store and retrieve related information. An Oracle Database reliably manages a large amount of data in a multiuser environment so that many users can concurrently access the same data. This is accomplished while delivering high performance. At the same time, the database prevents unauthorized access and provides efficient solutions for failure recovery.


nly eO Us AI O &


Oracle Database Architecture: OverviewInstanceSMON PMON Others

SGA Database buffer cache PGA Server processDBWn CKPT

Shared pool Library cache Data dictionary cacheLGWR ARCn

Redo log buffer

User process

Data files

Control files Database

Online redo log files

Archived log files


Oracle Database Architecture An Oracle Database consists of an instance and its associated databases. The instance consists of memory structures and background processes. Every time an instance is started, a shared memory area called the System Global Area (SGA) is allocated and the background processes are started. The database consists of both physical structures and logical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting access to logical storage structures.


nly eO Us AI O &


Connecting to the Database Connection: Communication between a user process and an instance Session: Specific connection of a user to an instance through a user process

USER

SQL> Select

User

Session

Connection


Connecting to the Database Connection and session are closely related to user process but are very different in meaning. A connection is a communication pathway between a user process and an Oracle Database instance. A communication pathway is established using available interprocess communication mechanisms (on a computer that runs both the user process and Oracle Database) or network software (when different computers run the database application and Oracle Database, and communicate through a network). A session represents the state of a current user login to the database instance. For example, when a user starts SQL*Plus, the user must provide a valid username and password, and then a session is established for that user. A session lasts from the time the user connects until the time the user disconnects or exits the database application. In the case of a dedicated connection, the session is serviced by a permanent dedicated process. The session is serviced by an available server process selected from a pool, either by the middle tier or by the Oracle shared server architecture. Multiple sessions can be created and exist concurrently for a single Oracle Database user using the same username. For example, a user with the username/password of HR/HR can connect to the same Oracle Database instance several times.


nly eO Us AI O &


Oracle Database Server StructuresMemory structuresInstance SGA Database buffer cache Shared pool Library cache Data dict. cachePMON ARCn Others

User process

Server process

Redo log buffer

Processes

DBWn

CKPT

LGWR

SMON

Database

Storage structures

Data files

Control files



Database Structures After starting an instance, the Oracle software associates the instance with a specific database. This is called mounting the database. The database is then ready to be opened, which makes it accessible to authorized users. Multiple instances can execute concurrently on the same computer, each accessing its own physical database. You can look at the Oracle Database architecture as various interrelated structural components. An Oracle instance uses memory structures and processes to manage and access the database. All memory structures exist in the main memory of the computers that constitute the database server. Processes are jobs that work in the memory of these computers. A process is defined as a thread of control or a mechanism in an operating system that can run a series of steps.


nly eO Us AI O &


Oracle Memory Architecture

Server process 1

PGA

Server process 2

PGA

Background process

PGA

Shared SQL area Library cache Redo log buffer Database buffer cache Java pool Streams pool

Data Dictionary cache Other

SGA

Shared pool I/O Buffer Response queue Free memory Request queue

Large pool


Oracle Memory Structures Oracle Database creates and uses memory structures for various purposes. For example, memory stores program code being run, data shared among users, and private data areas for each connected user. Two basic memory structures are associated with an instance: The System Global Area (SGA) is a group of shared memory structures, known as SGA components, that contain data and control information for one Oracle Database instance. The SGA is shared by all server and background processes. Examples of data stored in the SGA include cached data blocks and shared SQL areas. The Program Global Areas (PGAs) are memory regions that contain data and control information for a server or background process. A PGA is nonshared memory created by Oracle Database when a server or background process is started. Access to the PGA is exclusive to the server process. Each server process and background process has its own PGA.


nly eO Us AI O &


Oracle Memory Structures (continued) The SGA is the memory area that contains data and control information for the instance. The SGA includes the following data structures: Database buffer cache: Caches blocks of data retrieved from the database Redo log buffer: Caches redo information (used for instance recovery) until it can be written to the physical redo log files stored on the disk Shared pool: Caches various constructs that can be shared among users Large pool: Is an optional area that provides large memory allocations for certain large processes, such as Oracle backup and recovery operations, and I/O server processes Java pool: Is used for all session-specific Java code and data within the Java Virtual Machine (JVM) Streams pool: Is used by Oracle Streams to store information required by capture and apply When you start the instance by using Enterprise Manager or SQL*Plus, the amount of memory allocated for the SGA is displayed. A Program Global Area (PGA) is a memory region that contains data and control information for each server process. An Oracle server process services a clients requests. Each server process has its own private PGA that is created when the server process is started. Access to the PGA is exclusive to that server process, and the PGA is read and written only by the Oracle code acting on its behalf. With the dynamic SGA infrastructure, the size of the database buffer cache, the shared pool, the large pool, the Java pool, and the Streams pool changes without shutting down the instance. The Oracle database uses initialization parameters to create and configure memory structures. For example, the SGA_TARGET parameter specifies the total size of the SGA components. If you set SGA_TARGET to 0, Automatic Shared Memory Management is disabled.


nly eO Us AI O &


Process Architecture User process: Is started when a database user or a batch process connects to Oracle Database

Database processes Server process: Connects to the Oracle instance and is started when a user establishes a session Background processes: Are started when an Oracle instance is started InstanceSGA Database buffer cache Shared pool Library cache Data dictionary cache

PGAUser process Server process DBWn

Redo log buffer

Background processesCKPT LGWR SMON PMON ARCn Others


Process Architecture The processes in an Oracle Database system can be categorized into two major groups: User processes that run the application or Oracle tool code. Oracle Database processes that run the Oracle database server code. They include server processes and background processes. When a user runs an application program or an Oracle tool such as SQL*Plus, Oracle Database creates a user process to run the users application. Oracle Database also creates a server process to execute the commands issued by the user process. In addition, the Oracle server also has a set of background processes for an instance that interact with each other and with the operating system to manage the memory structures and asynchronously perform I/O to write data to disk, and perform other required tasks. The process structure varies for different Oracle Database configurations, depending on the operating system and the choice of Oracle Database options. The code for connected users can be configured as a dedicated server or a shared server. With dedicated server, for each user, the database application is run by a user process that is served by a dedicated server process that executes Oracle database server code. A shared server eliminates the need for a dedicated server process for each connection. A dispatcher directs multiple incoming network session requests to a pool of shared server processes. A shared server process serves any client request.


nly eO Us AI O &


Process Structures

Server

Server

Server

Server

Server

Server n processesSGA Database buffer cache Shared pool Redo log buffer Library cache Data dict. cache

SGA

CKPT

RECO

PMON

SMON

DBWn

LGWR

ARCn

Others

Oracle background processesCopyright 2007, Oracle. All rights reserved.

Process Structures Server Processes Oracle Database creates server processes to handle the requests of user processes connected to the instance. In some situations when the application and Oracle Database operate on the same computer, it is possible to combine the user process and corresponding server process into a single process to reduce system overhead. However, when the application and Oracle Database operate on different computers, a user process always communicates with Oracle Database through a separate server process. Server processes created on behalf of each users application can perform one or more of the following tasks: Parsing and running SQL statements issued through the application Reading necessary data blocks from data files on disk into the shared database buffers of the SGA, if the blocks are not already present in the SGA Returning results in such a way that the application can process the information Background Processes To maximize performance and accommodate many users, a multiprocess Oracle Database system uses some additional Oracle Database processes called background processes. An Oracle Database instance can have many background processes.


nly eO Us AI O &


Process Structures (continued) Background Processes (continued) The background processes commonly seen in non-RAC non-ASM environments can include the following: Database Writer process (DBWn) Log Writer process (LGWR) Checkpoint process (CKPT) System Monitor process (SMON) Process Monitor process (PMON) Recoverer process (RECO) Job Queue processes Archiver processes (ARCn) Queue Monitor processes (QMNn) Other background processes may be found in more advanced configurations such as RAC. See the V$BGPROCESS view for more information about the background processes. On many operating systems, background processes are created automatically when an instance is started.


nly eO Us AI O &


Database Storage Architecture

Control files

Data files


Parameter file

Backup files

Archived redo log files

Password file

Alert log and trace filesCopyright 2007, Oracle. All rights reserved.

Oracle Database Storage Architecture The files that constitute an Oracle database are organized into the following: Control files: Contain data about the database itself (that is, physical database structure information). These files are critical to the database. Without them, you cannot open data files to access the data within the database. Data files: Contain the user or application data of the database, as well as metadata and the data dictionary Online redo log files: Allow for instance recovery of the database. If the database server crashes and does not lose any data files, then the instance can recover the database with the information in these files. The following additional files are important to the successful running of the database: Parameter file: Is used to define how the instance is configured when it starts up Password file: Allows sysdba/sysoper/sysasm to connect remotely to the database and perform administrative tasks Backup files: Are used for database recovery. You typically restore a backup file when a media failure or user error has damaged or deleted the original file. Archived redo log files: Contain an ongoing history of the data changes (redo) that are generated by the instance. Using these files and a backup of the database, you can recover a lost data file. That is, archive logs enable the recovery of restored data files.


nly eO Us AI O &


Oracle Database Storage Architecture (continued) Trace files: Each server and background process can write to an associated trace file. When an internal error is detected by a process, the process dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, whereas other information is for Oracle Support Services. Alert log file: These are special trace entries. The alert log of a database is a chronological log of messages and errors. Each instance has one alert log file. Oracle recommends that you review this periodically.


nly eO Us AI O &


Logical and Physical Database StructuresLogical Database Physical

Schema

Tablespace

Data file

Segment

Extent

Oracle data block

OS block


Logical and Physical Database Structures The database has logical structures and physical structures. Tablespaces A database is divided into logical storage units called tablespaces, which group related logical structures together. For example, tablespaces commonly group all of an applications objects to simplify some administrative operations. You may have a tablespace for application data and an additional one for application indexes. Databases, Tablespaces, and Data Files The relationship among databases, tablespaces, and data files is illustrated in the slide. Each database is logically divided into one or more tablespaces. One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace. If it is a TEMPORARY tablespace, then instead of a data file, the tablespace has a temporary file.


nly eO Us AI O &


Logical and Physical Database Structures (continued) Schemas A schema is a collection of database objects that are owned by a database user. Schema objects are the logical structures that directly refer to the databases data. Schema objects include such structures as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. In general, schema objects include everything that your application creates in the database. Data Blocks At the finest level of granularity, an Oracle databases data is stored in data blocks. One data block corresponds to a specific number of bytes of physical database space on the disk. A database uses and allocates free database space in Oracle data blocks. Extents The next level of logical database space is called an extent. An extent is a specific number of contiguous data blocks (obtained in a single allocation) that are used to store a specific type of information. Segments The level of logical database storage above an extent is called a segment. A segment is a set of extents allocated for a certain logical structure. For example, the different types of segments include: Data segments: Each nonclustered, non-index-organized table has a data segment with the exception of external tables, global temporary tables, and partitioned tables where each table has one or more segments. All of the tables data is stored in the extents of its data segment. For a partitioned table, each partition has a data segment. Each cluster has a data segment. The data of every table in the cluster is stored in the clusters data segment. Index segments: Each index has an index segment that stores all of its data. For a partitioned index, each partition has an index segment. Undo segments: One UNDO tablespace is created per database instance that contains numerous undo segments to temporarily store undo information. The information in an undo segment is used to generate read-consistent database information and, during database recovery, to roll back uncommitted transactions for users. Temporary segments: Temporary segments are created by the Oracle database when a SQL statement needs a temporary work area to complete execution. When the statement finishes execution, the temporary segments extents are returned to the instance for future use. Specify a default temporary tablespace for every user or a default temporary tablespace, which is used databasewide. The Oracle database dynamically allocates space. When the existing extents of a segment are full, additional extents are added. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on the disk.


nly eO Us AI O &


Tablespaces and Data Files Tablespaces consist of one or more data files. Data files belong to only one tablespace.

Data file 1

Data file 2

USERS tablespace


Tablespaces and Data Files A database is divided into logical storage units called tablespaces, which can be used to group related logical structures together. Each database is logically divided into one or more tablespaces. One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace. Note: You can also create bigfile tablespaces. These tablespaces can have only a single file, which is often very large. The file may be any size up to maximum that the row ID architecture will permit. The maximum size is the block size for the tablespace times 2 to the 36th power, or 128 TB for a 32 KB block size. The traditional smallfile tablespaces (which are the default) usually contain multiple data files, but the files cannot be as large. For more information about the bigfile tablespaces, see the Database Administrators Guide.


nly eO Us AI O &


SYSTEM and SYSAUX Tablespaces The SYSTEM and SYSAUX tablespaces are mandatory tablespaces. They are created at the time of database creation. The SYSTEM tablespace is used for core functionality (for example, data dictionary tables). The auxiliary SYSAUX tablespace is used for additional database components (such as the Enterprise Manager Repository).


SYSTEM and SYSAUX Tablespaces Each Oracle database must contain a SYSTEM tablespace and a SYSAUX tablespace. They are automatically created when the database is created. The system default is to create a smallfile tablespace. You can also create bigfile tablespaces, which enable the Oracle database to manage ultralarge files (up to 8 exabytes in size). A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is always online when the database is open. It stores tables that support the core functionality of the database, such as the data dictionary tables. The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX tablespace stores many database components, and it must be online for the correct functioning of all database components. Note: The SYSAUX tablespace may be taken offline to do tablespace recovery, whereas this is not possible for SYSTEM tablespace. Neither of them may be made read-only.


nly eO Us AI O &


Segments, Extents, and Blocks Segments exist within a tablespace. Segments are made up of a collection of extents. Extents are a collection of data blocks. Data blocks are mapped to disk blocks.

Segment

Extents

Data blocks

Disk blocks


Segments, Extents, and Blocks Database objects, such as tables and indexes, are stored as segments in tablespaces. Each segment contains one or more extents. An extent consists of contiguous data blocks, which means that each extent can exist only in one data file. Data blocks are the smallest unit of I/O in the database. When the database requests a set of data blocks from the operating system (OS), the OS maps this to an actual file system or disk block on the storage device. Because of this, you need not know the physical address of any of the data in your database. This also means that a data file can be striped or mirrored on several disks. The size of the data block is defined by the DB_BLOCK_SIZE parameter. The default size of 8 KB is adequate for most databases. If your database supports a data warehouse application that has large tables and indexes, then a larger block size may be beneficial. If your database supports a transactional application where reads and writes are random, then specifying a smaller block size may be beneficial. The maximum block size depends on your OS. You can have tablespaces with a nonstandard block size. For details, see the Database Administrators Guide.


nly eO Us AI O &


Database Architecture: Summary of Structural Components Memory structures: System Global Area (SGA): Database buffer cache, redo buffer, and various pools Program Global Area (PGA)

Process structures: User process and server process Background processes: SMON, PMON, DBWn, CKPT, LGWR, ARCn, and so on

Storage structures: Logical: Database, schema, tablespace, segment, extent, and Oracle block Physical: data files, control files, and redo log files


Database Architecture: Summary of Structural Components In this lesson, you learned, at a high level, about the structural components of Oracle Database: memory, process, and storage structures. More details are covered in the following lessons.


nly eO Us AI O &


Automatic Storage Management: Review Portable and high-performance cluster file system Manages Oracle database files Data spread across disks to balance load Application Integrated mirroring across Database disks Solves many storage File system management challengesVolume manager

ASM

Operating system


Automatic Storage Management: Review Automatic Storage Management (ASM) provides a vertical integration of the file system and the volume manager that is specifically built for the Oracle database files. ASM can provide management for single SMP machines, or across multiple nodes of a cluster for Oracle Real Application Clusters (RAC) support. A single ASM instance can provide support for many Oracle databases simultaneously. ASM distributes I/O load across all available resources to optimize performance while removing the need for manual I/O tuning. ASM helps DBAs to manage a dynamic database environment by allowing them to increase the database size without having to shut down the database to adjust the storage allocation. ASM can maintain redundant copies of data to provide fault tolerance, or it can be built on top of vendor-supplied reliable storage mechanisms. ASM may use virtual raw volumes provided in a storage area network (SAN) environment or zero-padded files on a network attached storage (NAS) filer in addition to using local raw devices. Data management is done by selecting the desired reliability and performance characteristics for classes of data rather than with human interaction on a per file basis. ASM capabilities save DBAs time by automating manual storage and thereby increasing their ability to manage larger databases and more of them with increased efficiency.


nly eO Us AI O &


Automatic Storage Management: Review (continued) ASM divides files into allocation units (AUs) and spreads the AUs for each file evenly across all the disks. ASM uses an index technique to track the placement of each AU. When your storage capacity changes, ASM does not restripe all of the data, but moves an amount of data proportional to the amount of storage added or removed to evenly redistribute the files and maintain a balanced load across the disks. This is done while the database is up. You can increase the speed of a rebalance operation, or lower it to reduce the impact on the I/O subsystem. ASM provides mirroring protection without the need to purchase a third-party Logical Volume Manager. One unique advantage of ASM is that the mirroring is applied on a file basis, rather than on a volume basis. Therefore, the same disk group can contain a combination of files protected by mirroring, along with those that are not protected at all. ASM supports data files, log files, control files, archive logs, temp files, archive log files, SPFILEs, RMAN backup sets, and other Oracle database file types. ASM supports Real Application Clusters and eliminates the need for a Cluster Logical Volume Manager or a Cluster File System.


nly eO Us AI O &


ASM: General Architecture

DB instance SID=SALESDBW0 ASMB FG RBAL

ASM instance SID=+ASMGMON

RBAL ARB0

ARBA

ASM disks

ASM disks

ASM disks

ASM disks

ASM disks

ASM disks

ASM disk group 1

ASM disk group 2


ASM: General Architecture To use ASM, you must start a special instance, called an ASM instance, before you start your database instance. ASM instances do not mount databases, instead they manage the metadata needed to make ASM files available to ordinary database instances. Both ASM instances and database instances have access to some common set of disks called disk groups. Database instances access the contents of ASM files directly, communicating with an ASM instance only to get information about the layout of these files. An ASM instance starts several background processes specific to ASM. One process coordinates rebalance activity for disk groups. It is called RBAL. The second one performs the actual rebalance AU movements. There can be many of these at a time, and they are called ARB0, ARB1, and so forth. The GMON process, or Group Monitor, is used for partner and status table, and node membership. An ASM instance also has some of the same background processes as a database instance, including SMON, PMON, LGWR, DBWR, and CKPT. Each database instance using ASM has two extra background processes called ASMB and RBAL. RBAL performs global opens of the disks in the disk groups. At database instance startup, ASMB connects as a foreground process to the ASM instance. Communication between the database and the ASM instance is performed via this bridge. This includes physical file changes such as data file creation and deletion. Over this connection, periodic messages are exchanged to update statistics and to verify that both instances are healthy.


nly eO Us AI O &


Creating an ASM Instance


Creating an ASM Instance You create an ASM instance by running the Database Configuration Assistant (DBCA). On the first page, select the Configure Automatic Storage Management option, and then follow the steps. The ASM instance is created and started for you. Then you are guided through the process of defining disk groups for the instance. As part of the ASM instance creation process, the DBCA automatically creates an entry into the oratab file. This entry is used for discovery purposes. On the Windows platform where a services mechanism is used, the DBCA automatically creates an Oracle Service and the appropriate registry entry to facilitate the discovery of ASM instances. In addition, you are prompted to run the localconfig script that configures Cluster Synchronization Services to manage the ASM instance. When an ASM instance is configured, the DBCA creates an ASM instance parameter file and an ASM instance password file. If you were to create an ASM-enabled database, the DBCA determines whether an ASM instance already exists on your host. If ASM instance discovery returns an empty list, the DBCA creates a new ASM instance.


nly eO Us AI O &


ASM Instance Initialization Parameters

INSTANCE_TYPE = ASM DB_UNIQUE_NAME = +ASM ASM_POWER_LIMIT = 1 ASM_DISKSTRING = '/dev/rdsk/*s2', '/dev/rdsk/c1*' ASM_DISKGROUPS = dgroupA, dgroupB SPFILE = '+DATA/ORCL/orclspfile.ora_1'


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


nly eO Us AI O &


Starting Up an ASM Instance

$ export ORACLE_SID='+ASM' $ sqlplus /nolog SQL> CONNECT / AS sysasm Connected to an idle instance. SQL> STARTUP; Total System Global Area 284565504 Fixed Size 1299428 Variable Size 258100252 ASM Cache 25165824 ASM diskgroups mounted

bytes bytes bytes bytes


Starting Up an ASM Instance ASM instances are started similarly to database instances except that the initialization parameter file contains the entry INSTANCE_TYPE=ASM. When this parameter is set to the value ASM, it informs the Oracle executable that an ASM instance is starting, not a database instance. Also, the ORACLE_SID variable must be set to the ASM instance name. When the ASM instance starts up, the mount stage attempts to mount the disk groups specified by the ASM_DISKGROUPS initialization parameter rather than mounting a database, as is done with non-ASM instances. Other STARTUP clauses have comparable interpretation for ASM instances as they do for database instances. OPEN is invalid for an ASM instance. NOMOUNT starts up the ASM instance without mounting the database.


nly eO Us AI O &


SYSASM Role SYSASM role to manage ASM instances avoids overlap between DBAs and storage administratorsSQL> CONNECT / AS SYSASM SQL> CREATE USER ossysasmusername IDENTIFIED by passwd; SQL> GRANT SYSASM TO ossysasmusername; SQL> CONNECT ossysasmusername / passwd AS SYSASM; SQL> DROP USER ossysasmusername;

For ASM instances, SYSDBA will be deprecated in the future: Oracle Database 11g Release 1 behaves as in 10g In future releases SYSDBA privileges restricted in ASM instances


SYSASM Role

The SYSASM role is specifically intended for performing ASM administration tasks. Using the SYSASM role instead of the SYSDBA role improves security by separating ASM administration from database administration. In Oracle Database 11g Release 1, the OS group for SYSASM and SYSDBA is the same, and the default installation group for SYSASM is dba. In a future release, separate groups will have to be created, and SYSDBA users will be restricted in ASM instances. Currently, as a member of the dba group you can connect to an ASM instance using the first statement in the slide. You can also use the combination of CREATE USER and GRANT SYSASM SQL statements from an ASM instance to create a new SYSASM user. This is possible as long as the name of the user is an existing OS username. These commands update the password file of each ASM instance, and do not need the instance to be up and running. Similarly, you can revoke the SYSASM role from a user using the REVOKE command, and you can drop a user from the password file using the DROP USER command. The V$PWFILE_USERS view includes a new column called SYSASM that indicates whether the user can connect with SYSASM privileges (TRUE) or not (FALSE). Note: In Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA, warnings are written in the corresponding alert.log file.


nly eO Us AI O &


Accessing an ASM InstanceAs SYSASM or SYSDBAASM instance

As SYSOPER

All operations

Limited operations Disk group

Disk group

Storage system


Accessing an ASM Instance ASM instances do not have a data dictionary, so the only way to connect to one is by using OS authentication, that is, SYSASM, SYSDBA, or SYSOPER. To connect remotely, a password file must be used. Users who connect to the ASM instance with the SYSASM or SYSDBA privileges have administrative access to all disk groups in the system. The SYSOPER privilege is supported in ASM instances and limits the set of allowable SQL commands to the minimum required for basic operation of an already configured system. The following commands are available to SYSOPER users: STARTUP/SHUTDOWN ALTER DISKGROUP MOUNT/DISMOUNT ALTER DISKGROUP ONLINE/OFFLINE DISK ALTER DISKGROUP REBALANCE ALTER DISKGROUP CHECK SELECT all V$ASM_* views All other commands, such as CREATE DISKGROUP, ADD/DROP/RESIZE DISK, and so on, require the SYSASM or SYSDBA privilege and are not allowed with the SYSOPER privilege.


nly eO Us AI O &


Using Enterprise Manager to Manage ASM Users


Using Enterprise Manager to Manage ASM Users Enterprise Manager allows you to manage the users who access the ASM instance through remote connection (using password file authentication). These users are reserved exclusively for the ASM instance. You have this functionality only when you are connected as the SYSASM user. It is hidden if you connect as SYSDBA or SYSOPER users. When you click the Create button, the Create User page is displayed. When you click the Edit button the Edit User page is displayed. By clicking the Delete button, you can delete the created users. Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.


nly eO Us AI O &


Shutting Down an ASM Instance

Database instance A 2

Database instance B

ASM instance 3 SHUTDOWN NORMAL 1 1


Shutting Down an ASM Instance When you attempt to shut down an ASM instance in the NORMAL, IMMEDIATE, or TRANSACTIONAL modes, it succeeds only if there are no database instances connected to the ASM instance. If there is at least one connected instance, you receive the following error:ORA-15097: cannot SHUTDOWN ASM instance with connected RDBMS instance

If you perform a SHUTDOWN ABORT on the ASM instance, it shuts down, and it will require recovery at the time of the next startup. Any connected database instances will also eventually shut down, reporting the following error: In a singleASM instance configuration, if the ASM instance fails while disk groups are open for update, then after the ASM instance reinitializes, it reads the disk groups log and recovers all transient changes. With multiple ASM instances sharing disk groups, if one ASM instance fails, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of a database instance does not affect ASM instances. The ASM instance should be started automatically whenever the host is rebooted. The ASM instance is expected to use the automatic startup mechanism supported by the underlying operating system. Note that file system failure usually crashes a node.Oracle Database 11g: Administration Workshop II 1 - 29


nly eO Us AI O &

ORA-15064: communication failure with ASM instance

ASM Storage: ConceptsASM disk group Data file ASM file

Database

Tablespace

Segment File-system file or raw device

ASM disk

Extent

Allocation unit

Oracle block

Physical block


ASM Storage: Concepts ASM does not eliminate any existing database functionality. Existing databases are able to operate as they always have. New files may be created as ASM files, whereas existing ones are administered in the old way or can be migrated to ASM. The diagram depicts the relationships that exist between the various storage components inside an Oracle database. On the left and center parts of the diagram, you can find the relationships that exist in previous releases. The right part of the diagram shows you the new concepts introduced by ASM in Oracle Database 10g. However, these new concepts are used only to describe file storage, and do not replace any existing concepts such as segments and tablespaces. With ASM, database files can now be stored as ASM files. At the top of the new hierarchy, you can find what are called ASM disk groups. Any single ASM file is contained in only one disk group. However, a disk group may contain files belonging to several databases, and a single database may use storage from multiple disk groups. As you can see, one disk group is made up of ASM disks, and each ASM disk belongs to only one disk group. Also, ASM files are always spread across all the ASM disks in the disk group. ASM disks are partitioned in allocation units (AUs) of one megabyte each. An AU is the smallest contiguous disk space that ASM allocates. ASM does not allow physical blocks to be split across AUs. Note: This graphic deals with only one type of ASM file: data file. However, ASM can be used to store other database file types.


nly eO Us AI O &


ASM Disk Group Is a pool of disks managed as a logical unit Partitions total disk space into uniform sized units Spreads each file evenly across all disks Uses coarse- or fine-grain striping on the basis of file type Administers disk groups, not files

ASM instance

Disk group


ASM Disk Groups A disk group is a collection of disks managed as a logical unit. Storage is added and removed from disk groups in units of ASM disks. Every ASM disk has an ASM disk name, which is a name common to all nodes in a cluster. The ASM disk name abstraction is required because different hosts can use different names to refer to the same disk. An ASM file can begin with 1 MB extents and as the file size increases, the extent size also increases to 8 MB and 64 MB at a predefined number of extents. Therefore, the size of extent map defining a file can be smaller by a factor of 8 and 64 depending on the size of the file. The initial extent size is equal to the AU size and it increases by the 8 and 64 factor at predefined thresholds. This is automatic for newly created files after the COMPATIBLE.ASM and COMPATIBLE.RDBMS parameters have been advanced to 11.1 ASM always spreads files evenly across all the disks in a disk group. This is called coarse striping. That way, ASM eliminates the need for manual disk tuning. However, disks in a disk group should have similar size and performance characteristics to obtain optimal I/O. For most installations, there is only a small number of disk groupsfor instance, one disk group for a work area, and one for a recovery area. For files, such as log files, that require low latency, ASM provides fine-grained (128 KB) striping. Fine striping stripes each AU.


nly eO Us AI O &


ASM Disk Groups (continued) Fine striping breaks up medium-sized I/O operations into multiple smaller I/O operations that execute in parallel. While the number of files and disks increase, you have to manage only a constant number of disk groups. From a database perspective, disk groups can be specified as the default location for files created in the database. Note: Each disk group is self-describing, containing its own file directory and disk directory.


nly eO Us AI O &


Failure Group

Controller 16 5 4 3 2 1 1 1 7 7 7 13 13 13

Controller 2

Controller 3

1 1 1

7 7 7

13 13 13

1 1 1

7 7 7

13 13 13

Failure group 1

Failure group 2 Disk group ACopyright 2007, Oracle. All rights reserved.

Failure group 3

Failure Group A failure group is a set of disks, inside one particular disk group, sharing a common resource whose failure needs to be tolerated. An example of a failure group is a string of SCSI disks connected to a common SCSI controller. A failure of the controller leads to all the disks on its SCSI bus becoming unavailable, although each of the individual disks is still functional. What constitutes a failure group is site specific. It is largely based upon failure modes that a site is willing to tolerate. By default, ASM assigns each disk to its own failure group. When creating a disk group or adding a disk to a disk group, administrators may specify their own grouping of disks into failure groups. After failure groups are identified, ASM can optimize file layout to reduce the unavailability of data due to the failure of a shared resource.


nly eO Us AI O &


Disk Group Mirroring Mirror at AU level Mix primary and mirror AUs on each disk External redundancy: Defers to hardware mirroring Normal redundancy: Two-way mirroring At least two failure groups

High redundancy: Three-way mirroring At least three failure groups


Disk Group Mirroring ASM has three disk group types that support different types of mirroring: External redundancy: Do not provide mirroring. Use an external-redundancy disk group if you use hardware mirroring or if you can tolerate data loss as the result of a disk failure. Failure groups are not used with these types of disk groups. Normal-redundancy: Support two-way mirroring High-redundancy: Provide triple mirroring ASM does not mirror disks; rather, it mirrors AUs. As a result, you need only spare capacity in your disk group. When a disk fails, ASM automatically reconstructs the contents of the failed disk on the surviving disks in the disk group by reading the mirrored contents from the surviving disks. This spreads the I/O hit from a disk failure across several disks. When ASM allocates a primary AU of a file to one disk in a disk group, it allocates a mirror copy of that AU to another disk in the disk group. Primary AUs on a given disk can have their mirror copies on one of several partner disks in the disk group. ASM ensures that a primary AU and its mirror copy never reside in the same failure group. If you define failure groups for your disk group, ASM can tolerate the simultaneous failure of multiple disks in a single failure group.


nly eO Us AI O &


Disk Group Dynamic Rebalancing Automatic online rebalance whenever storage configuration changes Only move data proportional to storage added No need for manual I/O tuning Online migration to new storage Configurable load on system using ASM_POWER_LIMITCopyright 2007, Oracle. All rights reserved.

Disk Group Dynamic Rebalancing With ASM, the rebalance process is very easy and happens without any intervention from the DBA or system administrator. ASM automatically rebalances a disk group whenever disks are added or dropped. However, rebalancing will be delayed when disk groups are dropped because of errors. By using index techniques to spread AUs on the available disks, ASM does not need to restripe all of the data, but instead needs to only move an amount of data proportional to the amount of storage added or removed to evenly redistribute the files and maintain a balanced I/O load across the disks in a disk group. With the I/O balanced whenever files are allocated and whenever the storage configuration changes, the DBA never needs to search for hot spots in a disk group and manually move data to restore a balanced I/O load. However, because the database needs to resync cached ASM metadata, rebalances will have less impact if done in quiet periods. It is more efficient to add or drop multiple disks at the same time so that they are rebalanced as a single operation. This avoids unnecessary movement of data. With this technique, it is easy to achieve online migration of your data. All you need to do is add the new disks in one operation and drop the old ones in one operation. You can control how much of a load the rebalance operation has on the system by setting the ASM_POWER_LIMIT parameter. Its range of values is 1 through 11. The lower the number, the lighter the load; a higher setting has more of a load and finishes sooner.


nly eO Us AI O &


Managing Disk Groups

CREATE DISKGROUP ASM instance

DROP DISKGROUP

Database instance ALTER DISKGROUP


Managing Disk Groups The main goal of an ASM instance is to manage disk groups and protect their data. ASM instances also communicate file layout to database instances. In this way, database instances can directly access files stored in disk groups. There are several disk group administrative commands. They all require the SYSASM or SYSDBA privilege and must be issued from an ASM instance. You can add new disk groups. You can also modify existing disk groups to add new disks, remove existing ones, and perform many other operations. You can remove existing disk groups.


nly eO Us AI O &


Creating and Dropping Disk Groups

CREATE DISKGROUP dgroupA NORMAL REDUNDANCY FAILGROUP controller1 DISK '/devices/A1' NAME diskA1 SIZE 120G FORCE, '/devices/A2', '/devices/A3' FAILGROUP controller2 DISK '/devices/B1', '/devices/B2', '/devices/B3';

DROP DISKGROUP dgroupA INCLUDING CONTENTS;


Creating and Dropping Disk Groups Assume that ASM disk discovery identified the following disks in the /devices directory: A1, A2, A3, B1, B2, and B3. Also, assume that disks A1, A2, and A3 are on a separate SCSI controller from disks B1, B2, and B3. The first example in the slide illustrates how to configure a disk group called DGROUPA with two failure groups: CONTROLLER1 and CONTROLLER2. The example also uses the default redundancy characteristic, NORMAL REDUNDANCY, for the disk group. You can optionally provide a disk name and size for the disk. If you do not supply this information, ASM creates a default name and attempts to determine the size of the disk. If the size cannot be determined, an error is returned. FORCE indicates that a specified disk should be added to the specified disk group even though the disk is already formatted as a member of an ASM disk group. Using the FORCE option for a disk that is not formatted as a member of an ASM disk group returns an error. As shown by the second statement in the slide, you can delete a disk group along with all its files. To avoid accidental deletions, the INCLUDING CONTENTS option must be specified if the disk group still contains any files besides internal ASM metadata. The disk group must be mounted in order for it to be dropped. After ensuring that none of the disk group files are open, the group and all its drives are removed from the disk group. Then the header of each disk is overwritten to eliminate the ASM formatting information.


nly eO Us AI O &


Adding Disks to Disk Groups

ALTER DISKGROUP dgroupA ADD '/dev/rdsk/c0t4d0s2' NAME '/dev/rdsk/c0t5d0s2' NAME '/dev/rdsk/c0t6d0s2' NAME '/dev/rdsk/c0t7d0s2' NAME

DISK A5, A6, A7, A8;

ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';

Disk formatting

Disk group rebalancing


Adding Disks to Disk Groups This example shows how to add disks to a disk group. You execute an ALTER DISKGROUP ADD DISK command to add the disks. The first statement adds four new disks to the DGROUPA disk group. The second statement demonstrates the interactions of discovery strings. Consider the following configuration: /devices/A1 is a member of disk group DGROUPA. /devices/A2 is a member of disk group DGROUPA. /devices/A3 is a member of disk group DGROUPA. /devices/A4 is a candidate disk. The second command adds A4 to the DGROUPA disk group. It ignores the other disks, even though they match the discovery string, because they are already part of the DGROUPA disk group. As shown by the diagram, when you add a disk to a disk group, the ASM instance ensures that the disk is addressable and usable. The disk is then formatted and rebalanced. The rebalance process is time consuming because it moves AUs from every file onto the new disk. Note: Rebalancing does not block any database operations. The main impact that a rebalance process has is on the I/O load on the system. The higher the power of the rebalance, the more I/O load it puts on the system. Thus less I/O bandwidth is available for database I/Os.


nly eO Us AI O &


ASM Disk Group Compatibility Compatibility of each disk group is separately controllable: ASM compatibility controls ASM metadata on-disk structure RDBMS compatibility controls minimum consumer client level Useful with heterogeneous environments

Setting disk group compatibility is irreversible.

DB instance

ASM disk group

ASM instance

COMPATIBLE >= COMPATIBLE.RDBMS CREATE TABLESPACE hrapps DATAFILE '+DGROUP1' SIZE 10M; Tablespace created.

$ export ORACLE_SID=+ASM $ asmcmd ASMCMD> ls -l DGROUP1/ORCL/DATAFILE Type Redund Striped Time DATAFILE MIRROR COARSE OCT 05 21:00:00 DATAFILE MIRROR COARSE OCT 05 21:00:00 ASMCMD>

Sys Y Y

Name HRAPPS.257.570923611 TBSASM.256.570922917


ASMCMD Utility ASMCMD is a command-line utility that you can use to view and manipulate files and directories within ASM disk groups. ASMCMD can list the contents of disk groups, perform searches, create and remove directories and aliases, display space utilization, and more. ASMCMD works with ASM files, directories, and aliases. Every file created in ASM gets a system-generated file name, otherwise known as a fully qualified file name. This is the same as a complete path name in a local file system. As in other file systems, an ASM directory is a container for files, and an ASM directory can be part of a tree structure of other directories. The fully qualified file name represents a hierarchy of directories in which the plus sign (+) represent the root directory.ASMCMD> ls -l +DGROUP1/ORCL/DATAFILE Type Redund Striped Time DATAFILE MIRROR COARSE OCT 05 21:00:00

You can create your own directories as subdirectories of the system-generated directories using the ASMCMD mkdir command:ASMCMD> mkdir +dgroup1/sample/mydir


nly eO Us AI O &Sys Y

Name HRAPPS.257.570923611


ASMCMD UtilityUser created directories Templates Disk group compatibility Disk group name Disk names and failure groups

md_backupfull

repair/remap

$ asmcmd help

md_restore

nodg

newdg

lsdsk

ASMCMD> md_backup b /tmp/dgbackup070222 g admdsk1 g asmdsk2 ASMCMD> md_restore t full g asmdsk1 i backup_file ASMCMD> lsdsk -k DATA *_0001


ASMCMD Utility (continued) ASMCMD can perform ASM metadata backup and restore functionality. This provides the ability to re-create a preexisting ASM disk group with the exact same template and alias directory structure. The lsdsk command lists ASM disk information. This command can run in two modes: connected and non-connected. In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk information. In non-connected mode, ASMCMD scans disk headers to retrieve disk information, using an ASM disk string to restrict the discovery set. The connected mode is always attempted first. Bad block repair is a new feature that runs automatically on normal- or high-redundancy disk groups. When a normal read from an ASM disk group fails with an I/O error, ASM attempts to repair that block by reading from the mirror copy and write to it and by relocating it if the copy failed to produce a good read. This whole process happens automatically only on blocks that are read. It is possible that some blocks and extents on an ASM disk group are seldom read. One prime example is the secondary extents. The ASMCMDs repair command is designed to trigger a read on these extents, so the resulting failure in I/O can start the automatic block repair process. One can use the ASMCMDs repair interface if the storage array returns an error on a physical block, then the ASMCMD repair can initiate a read on that block to trigger the repair.


nly eO Us AI O &


ASM Scalability and Performance Extent size grows automatically according to file size. ASM support variable extents size to: Raise maximum possible file size Reduce memory utilization in shared pool

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


ASM Scalability and Performance ASM Variable Size Extents is an automated feature that enables ASM to support larger file size while improving memory usage efficiency. An ASM file begins with an extent equal to one AU. As the file size increases, the extent size also increases to 8 AU and then to 64 AU at a predefined number of extents. The size of the extent map that defines a file can be smaller by a factor of 8 and 64 depending on the file size. The initial extent size is equal to the allocation unit size and it increases by a factor of 8 and 64 at predefined thresholds. Fewer extent pointers are needed to describe the file and less memory is required to manage the extent maps in the shared pool, which would have been prohibitive in large file configurations. Extent size can vary both across files and within files. Variable size extents also enable you to deploy Oracle databases using ASM storage that are several hundred TB even several PB in size. The management of variable size extents is completely automated and does not require manual administration. However, external fragmentation may occur when a large number of non-contiguous small data extents have been allocated and freed, and no additional contiguous large extents are available. A defragmentation operation is integrated as part of the rebalance operation. So, as a DBA, you always have the possibility to defragment your disk group by executing a rebalance operation.


nly eO Us AI O &


ASM Scalability and Performance (continued) ASM imposes the following limits: 63 disk groups in a storage system 10,000 ASM disks in a storage system 4 petabyte maximum storage for each ASM disk 40 exabyte maximum storage for each storage system 1 million files for each disk group Maximum files sizes depending on the redundancy type of the disk groups used: 140 PB for external redundancy (value currently greater than possible database file size), 42 PB for normal redundancy, and 15 PB for high redundancy


nly eO Us AI O &


SummaryIn this lesson, you should have learned how to: Describe the Oracle Database architecture Describe Automatic Storage Management (ASM) Set up initialization parameter files for ASM and database instances Start up and shut down ASM instances Administer ASM disk groups



nly eO Us AI O &


Practice 1 Overview: Database Architecture and ASMThis practice covers the following topics: Creating and starting an ASM instance Creating and using ASM disk groups Managing an ASM instance Dynamic disk group rebalancing



nly eO Us AI O &



nly eO Us AI O &

Configuring for Recoverability



nly eO Us AI O &

ObjectivesAfter completing this lesson, you should be able to: Invoke RMAN and set and list simple configurations Configure your database in ARCHIVELOG mode Configure multiple archive log file destinations to increase availability Specify a retention policy Configure the Flash Recovery Area Describe the benefits of using the Flash Recovery Area



nly eO Us AI O &


Purpose of Backup and Recovery FunctionalityBackup and recovery functionality is needed for the following: Data protection Media failure User errors Application errors

Data preservation Data transfer


Purpose of Backup and Recovery Functionality You need to be able to recover when there are problems introduced into your database. When you have taken backups of your database, you are protecting against problems such as media failure, user errors, and application errors. Media errors cause data problems by failing at the hardware level; a bad controller or disk drive can introduce either subtle or obvious errors. Users can also cause data errors, simply by issuing commands that should not be issued. Those same types of errors can be caused by an application with a bug. Backup provides for preservation of data also. You may want to create a copy of the database as of a specifically meaningful point in time, and store for a long term. This could be for possible future restoration, or simply to meet compliance regulations. You can also use backup and recovery tools to move data to other databases, and even in other locations. A backup of the database is an efficient way to do this: back up the database and restore it at another location.


nly eO Us AI O &


Typical Backup and Recovery TasksTo be able to recover from data loss problems with minimal down time, you should be prepared to do the following: Configure the database for recoverability. Define a backup schedule. Plan and test different types of failure scenarios. Monitor and troubleshoot the backup and recovery environment. Restore data from backups. Recover transactions to a desired point in tim

11g workshop 2 studentguide 1

Documents