Oracle New Features - sg1

Oracle Database 11g: New Features for Administrators
Volume I Student Guide
D50081GC21 Edition 2.1 October 2009 D63697
Oracle Internal & Oracle Academy Use Only
Authors
Christian Bauwens Maria Billings Mark Fuller Peter Fusek Richard Green Christine Jeal Donna Keesling Deidre Matishak James Spiller Jenny Tsai Jean-Francois Verrier James Womack Marcie Young
Copyright 2009, 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
Maqsood Alam Kalyan Bitra John Boyle Harald Van Breederode Sharath Bhujani Immanuel Chan Timothy Chien Edward Choi Jacco Draaijer Al Flournoy Steve Fogel Andy Fortunak Gerlinde Frenzen Greg Gagnon GP Gongloor Joel Goodman Hansen Han Uwe Hesse Sunil Hingorani Magnus Isaksson Susan Jang Martin Jensen Dominique Jeunot Pete Jones Yash Kapani Pierre Labrousse Richard.W.Lewis Hakan Lindfors Russ Lowenthal Kurt Lysy Isabelle Marchand Silvia Marrone Heejin Park Srinivas Putrevu Jagannath Poosarla Surya Rekha Tim Shetler Eric Siglin Ranbir Singh Jeff Skochil George Spears Kesavan Srinivasan Birgitte Taagholt Glenn Tripp Branislav Valny Anthony Woodell
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.
Editors
Aju Kumar Amitha Narayan
Publishers
Sujatha Nagendra Michael Sebastian Almeida Jobi Varghese
Technical Contributors and Reviewers
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:
Contents
Oracle Grid Infrastructure Objectives 1-2 Oracle Grid Infrastructure 1-3 Automatic Storage Management Technology Stack 1-4 Oracle Grid Infrastructure and Oracle Database Installation: System Requirements 1-5 Preparing the Operating System 1-6 Setting Environment Variables 1-7 Checking the System Requirements 1-8 Defining Ownership of OS Devices for ASM 1-9 Installation Scenario 1-10 Part One: Installing the Oracle Grid Infrastructure for Stand-Alone Server 1-11 Selecting Product Languages 1-12 Creating an ASM Disk Group 1-13 Defining ASM Passwords 1-14 Defining Privileged Operating System Groups 1-15 Specifying Installation Location 1-16 Creating Inventory 1-17 Performing Prerequisite Checks 1-18 Verifying Installation Summary Data 1-19 Monitoring Installation Progress 1-20 Executing root Configuration Scripts 1-21 Executing Configuration Assistants 1-22 Finishing the Installation 1-23
iii
Introduction Overview I-2 Oracle Database Innovation I-3 Enterprise Grid Computing I-4 Oracle Database 11g: Focus Areas I-5 Management Automation I-7 Self-Managing Database: The Next Generation I-8 Suggested Additional Courses I-9 Further Information I-10 Suggested Schedule I-11
Installation Enhancements Objectives 2-2 Oracle Database 11g Installation: Changes 2-3 Part Two: Installing the Oracle Database Software 2-6 Choosing the Type of Installation 2-7 Choosing Grid Installation Options 2-8 Choosing Language Settings 2-9 Choosing the Database Edition 2-10 Specifying Installation Location 2-11 Choosing Operating System Groups 2-12 Performing Prerequisite Checks 2-13 Installation Summary Page 2-14 Install Product Page 2-15
iv
Configuring the FRA Disk Group 1-24 Oracle Local Registry 1-25 Quiz 1-27 Practice 1-1: Overview 1-28 ASM Files and Volumes 1-29 ASM Dynamic Volume Manager (ADVM) Concepts 1-30 ASM Dynamic Volume Striping 1-31 ADVM Restrictions 1-32 Creating an ASM Dynamic Volume 1-33 Managing ASM Dynamic Volumes 1-35 Using SQL to Manage ASM Dynamic Volumes 1-36 Extending ASMCMD for ASM Dynamic Volumes 1-38 ASM Cluster File System (ACFS) 1-39 ACFS Architecture 1-40 Using Enterprise Manager to Manage ACFS 1-41 Linux/UNIX File System APIs 1-42 Linux/UNIX Extensions 1-43 Windows File System APIs 1-44 Windows Extensions 1-45 ACFS Platform-Independent Commands 1-46 ASM Cluster File System Limitations 1-47 Creating an ASM Cluster File System 1-48 ACFS Snapshots 1-49 Administering Oracle ACFS Snapshots 1-50 Quiz 1-51 Summary 1-52 Practice 1-2: Overview 1-53
Oracle Restart Objectives 3-2 Oracle Restart 3-3 Oracle Restart Process Startup 3-5 Controlling Oracle Restart 3-6 Choosing the Correct SRVCTL Utility 3-8 Oracle Restart Configuration 3-9 Using the SRVCTL Utility 3-10 Obtaining Help for the SRVCTL Utility 3-11 Starting Components by Using the SRVCTL Utility 3-12 Stopping Components by Using the SRVCTL Utility 3-13 Viewing Component Status 3-14 Displaying the Oracle Restart Configuration for a Component 3-15 Manually Adding Components to the Oracle Restart Configuration 3-16 Quiz 3-17 Summary 3-18 Practice 3-1: Overview 3-19 ASM Enhancements Objectives 4-2 Without ASM Fast Mirror Resync 4-3
v
Installation Finish Page 2-16 Quiz 2-17 Practice 2-1: Overview 2-18 Oracle Database 11g Release 2 Upgrade Paths 2-19 Deprecated Features in Oracle Database 11g Release 1 and Release 2 2-20 Initialization Parameter Information 2-21 Practice 2-2: Overview 2-23 Practice 2-3: Overview 2-24 Direct NFS Client: Overview 2-25 Direct NFS Configuration 2-27 Monitoring Direct NFS 2-29 Online Patching: Overview 2-30 Installing an Online Patch 2-31 Benefits of Online Patching 2-32 Conventional Patching and Online Patching 2-33 Online Patching Considerations 2-34 Quiz 2-36 Summary 2-37 Practice 2-4: Overview 2-38
ASM Fast Mirror Resync: Overview 4-4 Using Enterprise Manager to Perform Fast Mirror Resync 4-5 Setting Up ASM Fast Mirror Resync 4-7 ASM Preferred Mirror Read: Overview 4-9 ASM Preferred Mirror Read: Setup 4-10 Enterprise Manager ASM Configuration Page 4-11 ASM Preferred Mirror Read: Best Practice 4-12 Quiz 4-13 ASM Scalability and Performance Enhancements 4-14 ASM Scalability in Oracle Database 11g 4-16 SYSASM Privilege 4-17 Using Enterprise Manager to Manage ASM Users 4-18 ASM Disk Group Compatibility 4-19 ASM Disk Group Attributes 4-21 Using Enterprise Manager to Edit Disk Group Attributes 4-22 Enhanced Disk Group Checks 4-23 Restricted Mount Disk Group for Fast Rebalance 4-24 Mount Force Disk Group 4-25 Forcing Disk Group Drop 4-27 ASMCMD Extensions in Oracle Database 11g Release 1 4-28 ASMCMD Command Extensions 4-30 ASMCMD Extensions: Example 4-31 Quiz 4-32 ASM ACLs 4-33 ASM ACLs Prerequisites 4-34 Managing ASM ACLs by Using SQL Commands 4-36 Managing ASM ACLs by Using SMCMD Commands 4-37 Managing ASM ACLs by Using Enterprise Manager 4-38 ASM Intelligent Data Placement 4-40 Managing ASM Intelligent Data Placement Examples 4-41 Managing ASM Intelligent Data Placement 4-42 ASM Intelligent Data Placement Best Practices 4-44 Viewing ASM Intelligent Data Placement Information 4-45 Quiz 4-47 Summary 4-48 Practice 4: Overview 4-49 5 Storage Enhancements Objectives 5-2 Supporting 4 KB Sector Disks 5-3
vi
Using 4 KB Sector Disks 5-4 Specifying the Disk Sector Size 5-5 Using the SECTOR_SIZE Clause 5-6 Creating a Database with 4 KB Sector Disks 5-7 Specifying BLOCKSIZE 5-8 Determining Your Log File Block Size 5-9 Performing an Offline Migration to 4 KB Disks 5-10 Quiz 5-12 Table Compression: Overview 5-13 Table Compression Concepts 5-14 Compressing Table Data 5-15 Using OLTP Compression 5-17 Using the Compression Advisor 5-18 Viewing Table Compression Information 5-19 SQL Access Advisor: Overview 5-20 SQL Access Advisor: Usage Model 5-21 Possible Recommendations 5-22 Using SQL Access Advisor 5-23 SQL Access Advisor: PL/SQL Procedure Flow 5-24 SQL Access Advisor: PL/SQL Example 5-25 Temporary Tablespace Shrink 5-26 DBA_TEMP_FREE_SPACE 5-27 Tablespace Option for Creating Temporary Table 5-28 Segment Creation on Demand 5-29 Creating Tables Without Segments 5-30 Controlling Deferred Segment Creation 5-31 Restrictions and Exceptions 5-32 Additional Automatic Functionality 5-33 Quiz 5-34 Summary 5-35 Practice 5: Overview 5-36 6 Data Warehouse and Partitioning Enhancements Objectives 6-2 Preprocessing Data for ORACLE_LOADER Access Driver in External Tables 6-3 Windows Example 6-4 Example of Preprocessing 6-5 EXECUTE Privilege for Directory Objects 6-7 Security Implications 6-8 Securing the ORACLE_LOADER Access Driver 6-10
vii
Considerations and Usage Notes 6-12 Quiz 6-13 Review: Degree of Parallelism (DOP) 6-14 Review: PARALLEL Clause 6-16 Goal: Simplifying Parallel Execution 6-17 Automatic Degree Of Parallelism Determination 6-18 Summary of Changes to Parameters 6-19 Using PARALLEL_MIN_TIME_THRESHOLD 6-20 Using PARALLEL_DEGREE_POLICY 6-21 Using PARALLEL_DEGREE_LIMIT 6-23 Using PARALLEL_FORCE_LOCAL 6-25 Changes to Existing Parameters 6-26 Parallel Hints Are Now at the Statement Level 6-27 Implication of Statement-Level Parallel Hints 6-28 EXPLAIN PLAN Enhancements 6-29 Enhanced Explain Plan Example 6-30 In-Memory Parallel Query 6-31 Quiz 6-32 Oracle Partitioning 6-33 Partitioning Enhancements 6-34 Interval Partitioning 6-35 Interval Partitioning: Example 6-36 Moving the Transition Point: Example 6-37 System Partitioning 6-39 System Partitioning: Example 6-40 System Partitioning: Guidelines 6-41 System-Managed Indexes for List Partitioning 6-42 Virtual ColumnBased Partitioning 6-43 Virtual ColumnBased Partitioning: Example 6-44 Reference Partitioning 6-45 Reference Partitioning: Benefit 6-46 Reference Partitioning: Example 6-47 Composite Partitioning Enhancements 6-48 Range-Range Partitioning: Example 6-49 Summary 6-50 Practice 6: Overview 6-51 7 Oracle SecureFiles Objectives 7-2 Managing Enterprise Information 7-3
viii
Security and Networking Enhancements Objectives 8-2 Secure Password Support 8-3 Automatic Secure Configuration 8-4 Password Configuration 8-5 Enable Built-in Password Complexity Checker 8-6 Managing Default Audits 8-7 Audited Privileges 8-8 Setting Security Parameters 8-9 Setting Database Administrator Authentication 8-11 Quiz 8-12 Transparent Data Encryption 8-13 Hardware Security Module 8-14 Using Tablespace Encryption 8-15 Tablespace Encryption New Features 8-16 Tablespace Master Key Re-Key 8-17 Quiz 8-18 Enterprise Manager Security Management 8-19 Using RMAN Security Enhancements 8-20
ix
Issues with Existing LOB Implementation 7-4 Oracle SecureFiles 7-5 Enabling SecureFiles Storage 7-6 SecureFiles: Storage Options 7-7 SecureFiles: Advanced Features 7-8 Creating SecureFiles 7-9 Creating SecureFiles Using Enterprise Manager 7-10 Shared I/O Pool 7-11 Altering SecureFiles 7-12 Quiz 7-13 What Is SecureFile Compression? 7-14 Compression Modes 7-15 Creating a SecureFile LOB with LOW Compression 7-16 Configuration Parameters 7-17 Quiz 7-18 Accessing SecureFiles Metadata 7-19 Migrating to SecureFiles 7-20 SecureFiles Migration: Example 7-21 SecureFiles Monitoring 7-22 Summary 7-23 Practice 7: Overview 7-24
Managing Fine-Grained Access to External Network Services 8-21 Supporting IPv6 Address Notification 8-23 Connecting to the Oracle Database 8-24 IPv6 Supported in Java Interfaces 8-25 Summary 8-26 Practice 8: Overview 8-27 9 SQL Performance Analyzer Objectives 9-2 Challenges Faced by DBAs When Performing Changes 9-3 Change Is the Only Constant 9-4 Change Management in Oracle Database 11g 9-5 Lifecycle of Change Management 9-6 SQL Performance Analyzer: Overview 9-8 SQL Performance Analyzer: Use Cases 9-9 Using SQL Performance Analyzer 9-10 Step 1: Capture SQL Workload 9-11 Step 2: Transport to a Test System 9-12 Step 3: Build Before Change Performance Data 9-13 Step 4: Implement Planned Change and Step 5: Build After-Change Performance Data 9-14 Step 6: Compare and Analyze Performance and Step 7: Tune Regressed SQL 9-15 Quiz 9-16 Accessing SQL Performance Analyzer 9-17 Using Enterprise Manager to Access SQL Performance Analyzer 9-18 SQL Performance Analyzer: PL/SQL Example 9-19 Tuning Regressed SQL Statements 9-21 Testing Database Upgrades: Oracle9i Database and Oracle Database 10g Release 1 9-22 Testing Database Upgrades: Oracle Database 10g Release 2 and Later Releases 9-25 SQL Performance Analyzer: Data Dictionary Views 9-28 Summary 9-29 Practice 9: Overview 9-30
10 SQL Plan Management Objectives 10-2 SQL Plan Management: Overview 10-3 SQL Plan Baseline: Architecture 10-4 Loading SQL Plan Baselines 10-6 Evolving SQL Plan Baselines 10-7
x
11 Database Replay Objectives 11-2 Why Use Database Replay? 11-3 Using Database Replay 11-4 The Big Picture 11-5 System Architecture: Capture 11-6 System Architecture: Preprocessing the Workload 11-7 System Architecture: Replay 11-8 Prechange Production System 11-9 Supported Workloads 11-10 Capture Considerations 11-11 Replay Considerations 11-12 Replay Options 11-14 Workload Replay Filters 11-16 Replay Analysis 11-18 Quiz 11-20 Database Replay Workflow in Enterprise Manager 11-21 Accessing Database Replay 11-22 Packages and Procedures 11-23 Database Replay: PL/SQL Example 11-24 Data Dictionary Views: Database Replay 11-26 Calibrating Replay Clients 11-27 Summary 11-28 Practice 11: Overview 11-29 12 Automatic SQL Tuning Objectives 12-2 SQL Tuning in Oracle Database 10g 12-3
xi
Viewing Important Baseline SQL Plan Attributes 10-8 Important Baseline SQL Plan Attributes 10-9 SQL Plan Selection 10-10 Quiz 10-12 Possible SQL Plan Manageability Scenarios 10-13 SQL Performance Analyzer and SQL Plan Baseline Scenario 10-14 Loading a SQL Plan Baseline Automatically 10-15 Purging SQL Management Base Policy 10-16 Enterprise Manager and SQL Plan Baselines 10-17 Using the MIGRATE_STORED_OUTLINE Functions 10-18 Summary 10-19 Practice 10: Overview 10-20
13 Intelligent Infrastructure Enhancements Objectives 13-2 Using New and Enhanced Automatic Workload Repository Views 13-3 Comparative Performance Analysis with AWR Baselines 13-4 Automatic Workload Repository Baselines 13-5 Moving Window Baseline 13-6 Baseline Display Options 13-7 Baseline Templates 13-8 Creating AWR Baselines 13-9 DBMS_WORKLOAD_REPOSITORY Package 13-10 Generate a Baseline Template for a Single Time Period 13-11 Creating a Repeating Baseline Template 13-12 Baseline Views 13-13 Quiz 13-14 Performance Monitoring and Baselines 13-15 Defining Alert Thresholds Using Static Baseline 13-17 Using Enterprise Manager to Quickly Configure Adaptive Thresholds 13-18 Practice 13-1: Overview 13-19 Maintenance Windows 13-20 Default Maintenance Plan 13-21 Automated Maintenance Task Priorities 13-22 Controlling Automatic Maintenance Tasks 13-23 Quiz 13-24 Important I/O Metrics for Oracle Databases 13-25
xii
Automatic SQL Tuning in Oracle Database 11g 12-4 Summary of Automation in Oracle Database 11g 12-5 Selecting Potential SQL Statements for Tuning 12-6 Maintenance Window Timeline 12-7 Automatic Tuning Process 12-8 Controlling the Automatic SQL Tuning Task 12-10 Example: Controlling the Automatic SQL Tuning Task 12-11 Automatic SQL Tuning Task 12-12 Configuring Automatic SQL Tuning 12-13 Automatic SQL Tuning Result Summary 12-14 Quiz 12-15 Automatic SQL Tuning: Fine Tune 12-16 Using the PL/SQL Interface to Generate Reports 12-18 Automatic SQL Tuning Considerations 12-19 Summary 12-20 Practice 12: Overview 12-21
14 Diagnosability Enhancements Objectives 14-2 Oracle Database 11g Fault Management 14-3 Ease Diagnosis: Automatic Diagnostic Workflow 14-4 Automatic Diagnostic Repository 14-5 ADRCI: The ADR Command-Line Tool 14-7 V$DIAG_INFO 14-8 Location for Diagnostic Traces 14-9 Viewing the Alert Log Using Enterprise Manager 14-10 Viewing the Alert Log Using ADRCI 14-11 Quiz 14-13 Problems and Incidents 14-14 Incident Packaging Service (IPS) 14-17 Incident Packages 14-18 Enterprise Manager Support Workbench: Overview 14-20 Enterprise Manager Support Workbench Roadmap 14-21 View Critical Error Alerts in Enterprise Manager 14-22 Package and Upload Diagnostic Data to Oracle Support 14-23
xiii
I/O Calibration and Enterprise Manager 13-27 I/O Calibration and the PL/SQL Interface 13-28 I/O Statistics: Overview 13-30 I/O Statistics and Enterprise Manager 13-32 Practices 13-2 and 13-3: Overview 13-34 Resource Manager Enhancements 13-35 Resource Manager Enhancements: Database Consolidation 13-36 Fixed Policy CPU Resource Management 13-37 Limiting CPU Utilization 13-38 Resource Manager Enhancements: Server Consolidation 13-39 Instance Caging 13-40 Instance Caging Examples 13-41 Enabling Instance Caging 13-42 Monitoring Instance Caging 13-43 Quiz 13-44 Resource Manager: Changes to DBMS_RESOURCE_MANAGER 13-45 Resource Manager: New Enterprise Manager Interface 13-46 Resource Plans Created by Default 13-47 Default Plan 13-48 I/O Resource Limit Thresholds 13-49 Resource Manager Statistics 13-50 Summary 13-51
15 Real-Time SQL Monitoring Objectives 15-2 SQL Monitoring 15-3 SQL Monitoring in Oracle Database 11g Release 2 15-5 SQL Monitoring with Enterprise Manager Database Control 15-6 Monitored SQL Executions 15-7 SQL Monitoring List 15-8 Monitored SQL Execution Details 15-9 SQL Execution Details for Parallel Queries 15-10 Details for Parallel Execution 15-11 Activity Details for Parallel Execution 15-12 Viewing Session Details 15-13 SQL Details 15-14 Viewing the SQL Monitoring Report 15-15 Quiz 15-16 Summary 15-17 Practice 15-1: Overview 15-18 16 Performance Enhancements Objectives 16-2 Using the DBMS_ADDM Package 16-3 Advisor Named Findings and Directives 16-6
xiv
Track the SR and Implement Repairs 14-24 Creating User-Reported Problems 14-25 Enterprise Manager Support Workbench for ASM 14-26 Invoking IPS Using ADRCI 14-27 Quiz 14-29 Health Monitor: Overview 14-30 Running Health Checks Manually: Enterprise Manager Example 14-32 Running Health Checks Manually: PL/SQL Example 14-33 Viewing HM Reports Using the ADRCI Utility 14-34 SQL Repair Advisor: Overview 14-35 Accessing the SQL Repair Advisor Using Enterprise Manager 14-36 Viewing, Disabling, or Removing a SQL Patch 14-37 Using SQL Repair Advisor from PL/SQL: Example 14-38 Using the SQL Test Case Builder 14-39 Quiz 14-40 Summary 14-41 Practice 14: Overview 14-42
Modified Advisor Views 16-7 New ADDM Views 16-8 Quiz 16-9 Review: Oracle Database 10g SGA Parameters 16-10 Review: Oracle Database 10g PGA Parameters 16-11 Oracle Database Memory Advisors 16-13 Automatic Memory Management: Overview 16-15 Oracle Database 11g Memory Parameters 16-17 Automatic Memory Parameter Dependency 16-18 Enabling Automatic Memory Management 16-20 Monitoring Automatic Memory Management 16-21 DBCA and Automatic Memory Management 16-23 Quiz 16-24 DB Smart Flash Cache Overview 16-25 Using DB Smart Flash Cache 16-26 DB Smart Flash Cache Architecture Overview 16-27 Configuring DB Smart Flash Cache 16-28 Sizing DB Smart Flash Cache 16-30 Specifying DB Smart Flash Cache for a Table 16-31 Statistic Preferences: Overview 16-32 Using New Statistic Preferences Features 16-33 Setting Global Preferences with Enterprise Manager 16-34 Partitioned Tables and Incremental Statistics: Overview 16-35 Hash-Based Sampling for Column Statistics 16-37 Multicolumn Statistics: Overview 16-39 Expression Statistics: Overview 16-41 Deferred Statistics Publishing: Overview 16-42 Deferred Statistics Publishing: Example 16-44 Quiz 16-45 Locking Enhancements 16-46 Identify Foreground and Background Process Events 16-47 Summary 16-48 Practice 16: Overview 16-49 17 Application Performance Enhancements Objectives 17-2 Online Redefinition Enhancements 17-3 Fine-Grained Dependency Management 17-4 Minimizing Dependent Recompilations 17-5 More Precise Dependency Metadata 17-6 Managing Dependencies 17-7
xv
17-35
18 Backup and Recovery Enhancements Objectives 18-2 Using New SET NEWNAME Clauses 18-3 Substitution Variables for SET NEWNAME 18-4 Using SET NEWNAME FOR DATABASE 18-5 Using SET NEWNAME FOR TABLESPACE 18-6 Performance Enhancements 18-7 Improved Block Corruption Detection 18-8 Using New Settings for Binary Compression 18-9 Using New Compression Algorithm Settings 18-10 Optimized Backups 18-11
xvi
Usage Guidelines to Reduce Invalidation 17-9 Invisible Index: Overview 17-10 Invisible Indexes: Examples 17-11 Adaptive Cursor Sharing: Overview 17-12 Adaptive Cursor Sharing: Architecture 17-13 Adaptive Cursor Sharing Views 17-15 Interacting with Adaptive Cursor Sharing 17-16 SQL Query Result Cache: Overview 17-17 Setting Up SQL Query Result Cache 17-18 Managing the SQL Query Result Cache 17-19 Using the RESULT_CACHE Hint 17-20 In-Line View: Example 17-21 Using Table Annotation to Control Result Caching 17-22 Using the DBMS_RESULT_CACHE Package 17-23 Viewing SQL Result Cache Dictionary Information 17-24 SQL Query Result Cache: Considerations 17-25 Quiz 17-27 OCI Client Query Cache 17-28 Using Client-Side Query Cache 17-29 PL/SQL Function Cache 17-30 Using PL/SQL Function Cache 17-31 PL/SQL Function Cache: Considerations 17-32 PL/SQL and Java Native Compilation Enhancements 17-33 Setting Up and Testing PL/SQL Native Compilation 17-34 Recompiling the Entire Database for PL/SQL Native Compilation Summary 17-37 Practice 17: Overview 17-38
Parallel Backup and Restore for Very Large Files 18-13 Using RMAN Multisection Backups 18-14 Quiz 18-15 Duplicating a Database 18-16 Performing Active Database Duplication 18-17 The RMAN DUPLICATE Command 18-18 Creating a Standby Database with the DUPLICATE Command 18-19 Enhancements to Database Duplication 18-20 Targetless DUPLICATE 18-21 Using Targetless DUPLICATE 18-22 DUPLICATE [SKIP] TABLESPACE Enhancements 18-24 Using RMAN to Create Archival Backups 18-25 Managing Archival Database Backups 18-26 Creating Archival Backups 18-27 Easier Recovery from Loss of Server Parameter File 18-28 TSPITR Enhancements and Modifications 18-29 Identifying Relationships that Span Recovery Set Boundaries 18-30 Using Image Copies for Faster TSPITR Performance 18-31 Quiz 18-32 Managing Recovery Catalogs 18-33 The IMPORT CATALOG Command 18-35 Creating and Using Virtual Private Catalogs 18-37 Using RMAN Virtual Private Catalogs 18-38 Quiz 18-40 Summary 18-41 Practice 18: Overview Using RMAN Enhancements 18-42 19 Flashback Technology, LogMiner, and Data Pump Enhancements Objectives 19-2 Flashback Data Archive: Overview 19-3 Flashback Data Archive: Architecture 19-5 Preparing Your Database 19-6 Flashback Data Archive: Workflow 19-10 Using Flashback Data Archive 19-11 Configuring a Default Flashback Data Archive 19-12 Filling the Flashback Data Archive Space 19-13 Maintaining Flashback Data Archives 19-14 Flashback Data Archive: Examples 19-15 Flashback Data Archive: DDL Restrictions 19-16 Using New DUPLICATE Command Options 18-23
xvii
20 Data Recovery Advisor Objectives 20-2 Repairing Data Failures 20-3 Data Recovery Advisor 20-4 Assessing Data Failures 20-7 Data Failures 20-8 Data Failure: Examples 20-9 Data Recovery Advisor RMAN Command-Line Interface 20-10 Listing Data Failures 20-11 Advising on Repair 20-13 Executing Repairs 20-14 Classifying (and Closing) Failures 20-15 Quiz 20-16 Data Recovery Advisor Views 20-17 Best Practice: Proactive Checks 20-18 Setting Parameters to Detect Corruption 20-19 Summary 20-21 Practice 20: Overview Repairing Failures 20-22
xviii
Flashback Data Archive: Supporting Transparent Schema Evolution 19-17 Flashback Data Archive: Supporting Full Schema Evolution 19-18 Viewing Flashback Data Archives 19-19 Guidelines and Usage Tips 19-20 Quiz 19-21 Flashback Transaction Backout 19-22 Prerequisites 19-23 Flashing Back a Transaction 19-24 Using the Flashback Transaction Wizard 19-25 Using the DBMS_FLASHBACK.TRANSACTION_BACKOUT Procedure 19-26 Viewing a Dependency Report 19-27 Viewing Flashback Transaction Metadata 19-28 Quiz 19-29 Flashback Database Enhancements 19-30 Using LogMiner 19-31 Review: Data Pump Export and Import 19-32 Migration with Data Pump Legacy Mode 19-33 Data Pump Legacy Mode 19-34 Managing File Locations 19-36 Quiz 19-37 Summary 19-38 Practice 19: Overview Using Flashback Technology 19-39
Appendix A: Practices and Solutions Appendix B: Scheduler Enhancements Objectives B-2 Lightweight Jobs B-3 Choosing the Right Job B-4 Scheduler Email Notification: Overview B-5 Using Scheduler Email Notification B-6 Setting the email_server Attribute B-7 Using ADD_JOB_EMAIL_NOTIFICATION B-9 Using REMOVE_JOB_EMAIL_NOTIFICATION B-11 Email Notification: New Dictionary Views B-12 Scheduler File Watcher: Overview B-13 Creating a File Watcher and an Event-Based Job B-14 Step 1: Creating a Scheduler Credential Object B-15 Step 2: Creating a File Watcher B-16 Using DBMS_SCHEDULER.CREATE_FILE_WATCHER B-17 Step 3: Creating a Scheduler Program Object B-18 Using the SCHEDULER_FILEWATCHER_RESULT Object Type B-20 Using the SCHEDULER_FILEWATCHER_REQUEST Object Type B-21 Step 4: Creating an Event-Based Job that References the File Watcher B-22 Step 5: Enabling the Objects B-23 Enabling File Arrival Events from Remote Systems B-24 Using DBMS_SCHEDULER.DROP_FILE_WATCHER B-25 File Watcher: Changes to Existing DBMS_SCHEDULER Procedures B-26 File Watcher: Changes to Existing Attributes B-27 File Watcher: New Dictionary Views B-28 File Watcher: New Columns in Existing Views B-29 Scheduler Remote Database Jobs: Overview B-30 Using CREATE_DATABASE_DESTINATION B-31 Using DROP_DATABASE_DESTINATION B-32 Creating Remote Database Jobs: Configuration B-33 Setting Up the Database for Remote Jobs B-34 Creating Remote Database Jobs B-35 Scheduler Multiple Destination Jobs: Overview B-36 Scheduler Multiple Destination Jobs: Terminology B-37 Scheduler Multiple Destination Job States B-38 Creating Multiple Destination Jobs B-39
xix
Setting the email_sender Attribute B-8
Using Destination Groups for Multiple Destination Jobs B-40 Using CREATE_GROUP B-41 Using ADD_GROUP_MEMBER B-42 Using DROP_GROUP B-43 Using REMOVE_GROUP_MEMBER B-44 Modifications to Existing DBMS_SCHEDULER Procedures B-45 Multiple Destination Jobs: New Dictionary Views B-46 Multiple Destination Jobs: New Columns in Existing Dictionary Views B-47 Summary B-48 Appendix C: Oracle Secure Backup Cloud Module Objectives C-2 Oracle Database Backup in the Cloud C-3 Introducing Oracle Secure Backup Cloud Module C-4 Advantages of Backing Up to the Cloud C-5 What Is Amazon Simple Storage Service (S3)? C-6 Installing the Oracle Secure Backup Cloud Module C-7 Summary C-8
xx
Introduction
Copyright 2009, Oracle. All rights reserved.
Overview
This course focuses on those features of Oracle Database 11g that are applicable to database administration. Previous experience with Oracle databases (particularly Oracle Database 10g) is required for a full understanding of many of the new features. Hands-on practices emphasize functionality rather than test knowledge.
Overview This course is designed to introduce you to the new features of Oracle Database 11g that are applicable to the work usually performed by database administrators and related personnel. The course does not attempt to provide every detail about a feature or cover aspects of a feature that were available in previous releases (except when defining the context for a new feature or comparing past behavior with current behavior). Consequently, the course is most useful to you if you have administered other versions of Oracle databases, particularly Oracle Database 10g. Even with this background, you should not expect to be able to implement all of the features discussed in the course without supplemental reading, especially the Oracle Database 11g documentation. The course consists of instructor-led lessons and demonstrations, plus many hands-on practices that enable you to see for yourself how certain new features behave. As with the course content in general, these practices are designed to introduce you to the fundamental aspects of a feature. They are not intended to test your knowledge of unfamiliar syntax or to provide an opportunity for you to examine every nuance of a new feature. The length of this course precludes such activity. Consequently, you are strongly encouraged to use the provided scripts to complete the practices rather than struggle with unfamiliar syntax.
Oracle Database 11g: New Features for Administrators I - 2
Oracle Database Innovation

Audit Vault
Database Vault
Secure Enterprise Search Grid Computing Automatic Storage Mgmt Self Managing Database
XML Database Oracle Data Guard Real Application Clusters Flashback Query Virtual Private Database
Built-in Java VM Partitioning Support Built-in Messaging Object Relational Support Multimedia Support
Data Warehousing Optimizations Parallel Operations Distributed SQL & Transaction Support Cluster and MPP Support Multi-version Read Consistency Client/Server Support Platform Portability Commercial SQL Implementation
continuing with
Oracle Database 11g
Oracle Database Innovation As a result of its early focus on innovation, Oracle has maintained the lead in the industry with a large number of trend-setting products. Continued emphasis on Oracles key development areas has led to a number of industry firstsfrom the first commercial relational database, to the first portable tool set and UNIX-based client/server applications, to the first multimedia database architecture.
Enterprise Grid Computing
SMP dominance
RAC clusters for availability
Grids of low-cost hardware and storage
Managing change across the enterprise
Enterprise Grid Computing Oracle Database 10g was the first database designed for grid computing. Oracle Database 11g consolidates and extends Oracles unique ability to deliver the benefits of grid computing. Oracle Infrastructure grids fundamentally changed the way data centers look and operate, transforming data centers from silos of isolated system resources to shared pools of servers and storage. Oracles unique grid architecture enables all types of applications to scale out server and storage capacity on demand. By clustering low-cost commodity server and storage modules on Infrastructure grids, Oracle Database 11g enables customers to improve their user service levels, reduce their down time, and make more efficient use of their IT resources while still increasing the performance, scalability, and security of their business applications. Oracle Database 11g furthers the adoption of grid computing by offering: Unique scale-out technology with a single database image Lower server and storage costs Increased availability and scalability
Oracle Database 11g: Focus Areas

Manageability Availability Performance Business intelligence and data warehousing Security
Oracle Database 11g: Focus Areas The Oracle Infrastructure grid technology enables information technology systems to be built out of pools of low-cost servers and storage that deliver the highest quality of service in terms of manageability, high availability, and performance. With Oracle Database 11g, the existing grid capabilities are extended in the areas listed in the slide, thereby making your databases more manageable. Manageability: New manageability features and enhancements increase DBA productivity, reduce costs, minimize errors, and maximize quality of service through change management, additional management automation, and fault diagnosis. Availability: New high-availability features further reduce the risk of down time and data loss, including further disaster recovery offerings, important high-availability enhancements to Automatic Storage Management, support for online database patching, improved online operations, and more. Performance: Many innovative new performance capabilities are available, including SecureFiles, compression for OLTP, Real Application Clusters optimizations, SQL Query Result Cache, TimesTen enhancements, and more.
Oracle Database 11g: Focus Areas

Information management
Content management XML Oracle Text Spatial Multimedia and medical imaging PL/SQL .NET PHP SQL Developer
Application development

Oracle Database 11g: Focus Areas (continued) The Oracle Infrastructure grid provides the additional functionality required to manage all the information in the enterprise with robust security, information life-cycle management, and integrated business intelligence analytics to support fast and accurate business decisions at the lowest cost.
Management Automation
Auto-tuning
Advisory Instrumentation
Management Automation Oracle Database 11g continues the effort begun in Oracle9i Database and carried on through Oracle Database 10g to dramatically simplify and ultimately, fully automate the tasks that DBAs must perform. What is new in Oracle Database 11g is Automatic SQL Tuning with self-learning capabilities. Other new capabilities include automatic, unified tuning of both SGA and PGA memory buffers, and new advisors for partitioning, database repair, streams performance, and space management. Enhancements to Oracle Automatic Database Diagnostic Monitor (ADDM) give it a better global view of performance in Oracle Real Application Clusters (RAC) environments and improved comparative performance analysis capabilities.
Recovery
Replication
Memory
Apps/SQL
Schema
Storage
Backup
RAC
Self-Managing Database: The Next Generation
Manage fault
Self-Managing Database: The Next Generation Self-management is an ongoing goal for Oracle Database. Oracle Database 10g marked the beginning of a major effort to make the database easy to use. With Oracle Database 10g, the focus for self-managing was on performance and resources. Oracle Database 11g adds two important axes to the overall self-management goal: change management and fault management.
Manage change
Manage performance and resources
Suggested Additional Courses

Oracle 11g: RAC and Grid Foundation Administration Oracle 11g: RAC and Grid Foundation Overview Seminar Oracle Database 11g: Data Guard Administration Oracle Database 11g: New Features for Data Guard Seminar Oracle Database 11g: New Features for Streams Seminar
Suggested Additional Courses For more information about the key grid computing technologies used by the Oracle products, you can obtain additional training from Oracle University.
Further Information
For more information about topics that are not covered in this course, refer to the following: Oracle Database 11g: New Features Overview Seminar Oracle Database 11g: Change Management Seminar Oracle Database 11g: New Features eStudies
Oracle By Example series: Oracle Database 11g

http://www.oracle.com/technology/obe/demos/admin/dem os.html http://www.oracle.com/technology/obe/start/index.html
Oracle OpenWorld events

http://www.oracle.com/openworld/index.html
http://www.oracle.com/education/library A comprehensive series of self-paced online courses covering all new features in detail
Suggested Schedule
Topic Installation Manage Storage Manage Security Manage Change Manage Performance and Resources Manage Availability Lessons Days 1 2 3 3 3, 4 and 5 5
I, 1 - 3
4-7 8 9 - 11 12 - 17 18 - 20
Suggested Schedule The lessons in this guide are arranged in the order in which you will probably study them in the class. The lessons are grouped into topic areas, but they are also organized by other criteria, including the following: A feature is introduced in an early lesson and then referenced in later lessons. Topics alternate between difficult and easy to facilitate learning. Lessons are supplemented with hands-on practices throughout the course to provide regular opportunities for you to explore what you are learning. If your instructor teaches the class in the sequence in which the lessons are printed in this guide, the class should run approximately as shown in the schedule. Your instructor, however, may vary the sequence of the lessons for a number of reasons, including: Customizing material for a specific audience Covering a topic in a single day instead of splitting the material across two days Maximizing the use of course resources (such as hardware and software)
Oracle Grid Infrastructure

Objectives
Oracle Database 11g: New Features for Administrators 1 - 2
After completing this lesson, you should be able to: Install Oracle Grid Infrastructure for a stand-alone server and create an ASM disk group Use the ASM Configuration Assistant (ASMCA) to create an ASM disk group Create and manage ASM Dynamic Volumes Create and manage an ASM Cluster File System
11.2
Standardized infrastructure software Eliminates need for thirdparty solutions Includes:

Automatic Storage Management (ASM) ASM Cluster File System (ACFS) ACFS Snapshots Oracle Clusterware Oracle Restart
Applications Middleware Database

Oracle Grid Infrastructure The Oracle Grid Infrastructure includes: Automatic Storage Management (ASM), ASM Cluster File System (ACFS), ACFS Snapshots, Oracle Clusterware, and Oracle Restart. These components are installed into the Grid Infrastructure home using the Oracle Universal Installation (OUI) tool.
EM
11.2
Automatic Storage Management Technology Stack

Previous Releases of ASM
Application Database
Database Application
Oracle Database 11g Release 2 ASM

Application Database ACFS ASM/ADVM Operating System
3rd Party FS
ASM
Operating System
ASM
Automatic Storage Management Technology Stack The graphics in the slide illustrate the software stack for previous versions of ASM and ASM in Oracle Database 11g Release 2. Previous Releases of ASM refers to Oracle Database 10g and Oracle Database 11g Release 1. Previously, ASM sat on top of the operating system, which provided the drivers to access the storage devices. The database sits on top of ASM, and applications on top of the database. In the Oracle 11g Release 2 Automatic Storage Management stack, ASM still sits on the operating system (OS) level and includes the ASM Dynamic Volume Manager (ADVM). At the same level as the database there is the ASM Cluster File System (ACFS), and the possibility of third-party file systems built on ASM.
11.2
Oracle Grid Infrastructure and Oracle Database Installation: System Requirements

Memory requirements:
1 GB for the database instance with Database Control 1.5 GB for the ASM instance and Oracle Restart
Disk space requirements:
Operating system (see documentation)
Oracle Grid Infrastructure and Oracle Database Installation: System Requirements A standard database installation can be completed on a computer with 1 GB of RAM and 1.5 GB of swap space or larger. A standard Oracle Grid Infrastructure for stand-alone server installation requires a minimum of 1.5GB RAM. Note: Oracle Restart enables Oracle components to be automatically restarted after a hardware or software failure, or whenever your database host computer restarts. Additional information on Oracle Restart is provided later in this lesson and in the lesson titled "Oracle Restart." The amount of swap space required is dependent on the amount of RAM. Please see the OS-specific installation guide for more details. Depending on the activity level of the machine on which you are installing the Oracle Database software, the standard installation can complete in 20 minutes or less. Some installation details: Oracle Database 11g ships two seed database templates. Duplicated files are removed. Many other products and demonstrations are installable from additional CDs. The hardware requirements listed in the slide are minimal requirements across all platforms. Your installation may have additional requirements (especially disk space). Note: An Enterprise Edition installation type that includes a standard seed database is referred to as a standard installation.
3 GB of swap space (based on 2GB RAM) 1 GB of disk space in the /tmp directory Between 1.5 GB and 3.8 GB for the Oracle software 1.7 GB for the preconfigured database (optional) 2.4 GB for the fast recovery area (optional)
11.2
Preparing the Operating System

Create the required operating system groups and users: Groups:
oinstall dba
Optional groups (for separation of duty across multiple users):

oper asmdba asmoper asmadmin
Users:
Software owner, usually oracle Can create multiple users for multiple product installations
Preparing the Operating System There are steps that need to be performed by the systems administrator for the hardware you are using for your Oracle installation. Refer to your operating system-specific installation documentation for detailed information on the operating system configuration details and commands. One of the required steps is to create the necessary operating system groups and users. The two required operating system groups are: oinstall and dba. If you are implementing separation of duty across multiple user accounts, other groups that should be created are: oper, asmdba, asmoper, and asmadmin. You need at least one operating system user to act as the owner of your Oracle installation. In most cases the oracle user is configured for this purpose. If you want to have a true separation of duty then you can have separate owners for each of your Oracle products.
Setting Environment Variables

Oracle environment variables: ORACLE_BASE: Base of the Oracle directory structure. Recommendation is to set this before installation. ORACLE_HOME: The environment in which Oracle products run. Not required before installation if ORACLE_BASE is set. ORACLE_SID: Not required before installation, but useful after for ease of interaction with a particular instance. NLS_LANG: Optional environment variable that controls language, territory, and client character set settings
Setting Environment Variables There are many Oracle environment variables involved in each Oracle environment. Those mentioned here are important to the successful installation and use of an Oracle database. None of these are required to be set, but you can avoid future problems by setting them. ORACLE_BASE: Specifies the base of the Oracle directory structure for Optimal Flexible Architecture (OFA) that is recommended by Oracle Support. Use is optional; if used, it can facilitate future installations and upgrades. Set this to a directory path, as shown in the following example:
/u01/app/oracle ORACLE_HOME: The environment in which Oracle products run. It is not required before
installation if ORACLE_BASE is set. The OUI can use the ORACLE_BASE setting to determine the recommended ORACLE_HOME for your installation. Having this environment variable makes maintenance and management of Oracle software easier. Set to a directory path, as shown in the following example:
/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_SID: The system identifier for an Oracle instance, such as orcl for a database or +ASM for an ASM instance. It is not required before installation, but is useful for ease NLS_LANG: Optional environment variable that controls language, territory, and client
of interaction with a particular instance.
character set settings as in the following example:

AMERICAN_DENMARK.WE8MSWIN1252
For more information about valid languages, territories, character sets, and language support, see the Oracle Database Globalization Support Guide.
Checking the System Requirements
11.2 update
Checking the System Requirements The Oracle Universal Installer automates most of the prerequisite checks to verify the following: Minimum temporary space requirements for installation and configuration are checked. Those requirements are validated during the installation process. 64-bit installations are prevented from being installed into Oracle homes with 32-bit software already installed (and vice versa). Oracle Grid Infrastructure 11g and Oracle Database 11g is certified against several versions of the Linux platform, as well as other platforms. All required OS patches are installed. All required system and kernel parameters are set correctly. The DISPLAY environment variable is set and the user has sufficient permissions to display to the specified DISPLAY. The system has a sufficient swapping set. The Oracle home for the new installation either is empty or is one of a handful of supported releases on top of which Oracle Database 11g can be installed. The installation process also verifies that those releases are registered in the Oracle inventory.
Adequate temporary space 64-bit versus 32-bit issues Correct operating system (OS) OS patch level System packages System and kernel parameters X Server permissions Sufficient swapping ORACLE_HOME status
11.2
Defining Ownership of OS Devices for ASM
The operating system devices that are being used for ASM disks need to be owned by the Grid Infrastructure user and the OSASM group. For Oracle ASMLib drivers:
Defining Ownership of OS Devices for ASM The operating system devices that are being used for ASM disks need to be owned by the Grid Infrastructure user and the OSASM group. The suggested name for the account is grid, and the suggested name for the group is asmadmin. Most installations will probably use oracle:oinstall as the user:group owners for all Oracle software. In this case, the ownership of the ASM disks will be oracle:oinstall. Note that the owner of the Grid Infrastructure software must be the owner of the ASM disks. Note: In previous versions of Oracle ASM, the account and group was defined to be oracle and dba respectively. With separation of job roles and ASM being moved to the Grid Infrastructure home instead of the original Oracle Database home directory, the values have now changed.
# /etc/init.d/oracleasm configure .. Default user to own the driver interface []: grid Default group to own the driver interface []: asmadmin ..
11.2
Installation Scenario
The installation scenario being presented in this course is divided into two parts: Part One: Install Oracle Grid Infrastructure for standalone server (Lesson 1) Part Two: Install Oracle Database software (Lesson 2)
Installation Scenario As part of the Oracle Grid Infrastructure installation, the steps to configure the ASM disk groups are shown and Oracle Restart is configured. The Oracle Grid Infrastructure is installed first so that the database created after the Oracle Database software installation will be able to use the ASM disk groups and be automatically registered with Oracle Restart.
11.2
Part One: Installing the Oracle Grid Infrastructure for Stand-Alone Server
Part One: Installing the Oracle Grid Infrastructure for Stand-Alone Server To install the Oracle Grid Infrastructure software by using OUI, log on to your computer as a member of the administrative group that is authorized to install the Oracle Grid Infrastructure software, and create and manage the database. Insert the distribution CD for the clusterware into your CD drive, or navigate to the Oracle clusterware staging location. From that location, enter ./runInstaller to start the Oracle Universal Installer (OUI). The Select Installation Option page is displayed. Select the Install and Configure Grid Infrastructure for a Standalone Server option and click Next.
11.2
Selecting Product Languages
Selecting Product Languages The Select Product Languages page is displayed. To add a language to the installation, click the language to highlight it and then use the right-arrow button to move it the Selected Languages list. Multiple languages can be selected by pressing and holding the Ctrl key while selecting them with the mouse. Click the Next button to proceed with the installation.
11.2
Creating an ASM Disk Group
Creating an ASM Disk Group The Create ASM Disk Group page is displayed. The Oracle Grid Infrastructure includes support for ASM and Oracle Restart. The OUI will not proceed unless an ASM disk group is created. Enter the name of the first ASM disk group to be created in the Disk Group Name field. If the Add Disks section is not populated with candidate disks, then click the Change Discovery Path button, and enter the disk discovery path to the ASM disks. Oracle recommends that you create two disk groups for most environments. The OUI is only capable of creating a single ASM disk group at this time. You may create the recommended second ASM disk group after the installation using the ASM Configuration Assistant (ASMCA) utility or the SQL*Plus utility. Click the Next button to proceed with the installation. Note: Devices appear in the list for the example due to ASMLib being configured. ASMLib is only for Linux platforms. There is a default discovery path specific to each operating system. If the default discovery path does not locate any devices, you can click the Change Discovery Path button and define the actual path.
11.2
Defining ASM Passwords
Defining ASM Passwords The Specify ASM Password page is displayed. Passwords must be supplied for two accounts: the SYS account and the ASMSNMP account. The option to use different passwords for the accounts or the option to use the same password for the accounts is presented. The ASM instance does not contain a data dictionary such as an Oracle database, so the only authentication methods are operating system authentication and password file authentication. The SYS account will be added to the password file (orapw+ASM on Linux) and granted the SYSDBA, SYSOPER, and SYSASM privileges. The ASMSNMP account will be added to the password file and granted only the SYSDBA privilege. After entering appropriate passwords, click the Next button to proceed with the installation. Note: The ASMSNMP user is created to provide monitoring of the ASM instance through Enterprise Manager. ASMSNMP has limited access and capabilities.
11.2
Defining Privileged Operating System Groups
Defining Privileged Operating System Groups The Privileged Operating System Groups page is displayed. The OUI utility provides suggested default values for the following groups if the current user is an operating system member of the groups: ASM Database Administrator (OSDBA) Group: asmdba ASM Instance Operator (OSOPER) Group: asmoper ASM Instance Administrator (OSASM) Group: asmadmin Because this installation is for a stand-alone server, it is common practice to use the same operating system group for all three, such as dba (as shown in the slide). Click the Next button to proceed with the installation. Click Yes in response to the warning that appears because you use the same operating system group for OSDBA, OSOPER, and OSASM. Note: Because the Oracle Database server logs in to the ASM instance with a SYSDBA connection, the OSDBA group selected for the Grid Infrastructure installation needs to be the same as the OSDBA group selected for the Database installation.
11.2
Specifying Installation Location
Specifying Installation Location The Specify Installation Location page is displayed. In the Oracle Base field, enter the value of ORACLE_BASE for the software owner. The default value is /u01/app/grid, but because this installation is not using a separate grid user, this value should be changed to match the installation user. In the example, this user is oracle. In the Software Location field, enter the value of the ORACLE_HOME for the Grid Infrastructure software. The default value is /u01/app/oracle/product/11.2.0/grid. Click the Next button to proceed with the installation.
11.2
Creating Inventory
Creating Inventory If an Oracle Inventory directory does not exist on the host machine, the "Create Inventory" page is displayed. In the "Inventory Directory" field, enter the desired location for the oraInventory directory. The recommended oraInventory directory should be one level higher than the ORACLE_BASE directory. The directory is /u01/app/oraInventory in the example. Select the oraInventory group name from the selection list. The recommended name is oinstall. Click the Next button to proceed with the installation.
11.2
Performing Prerequisite Checks
Performing Prerequisite Checks The Performing Prerequisite Checks page appears. No action is required on this page unless the checks fail with errors. If errors do occur, they will need to be corrected before proceeding with the installation. If the error is one that is not fixable, you must either fix the problem manually or choose to Ignore All and continue on with the installation (if the failed check is not critical). Note: Not all failures can be fixed by the runfixup.sh script generated by the OUI. In such cases, manual intervention to correct the problem is required before you can reattempt the installation.
11.2
Verifying Installation Summary Data
Verifying Installation Summary Data The Summary page is displayed. You are presented with the option to save the interactive installation questions and answers to a response file. A response file can be used in future installations to perform a silent installation in the same manner in which this installation is being performed. The response file is a text file and can also be edited with a text editing tool to modify it for a different installation. Click the Finish button to proceed with the installation.
11.2
Monitoring Installation Progress
Monitoring Installation Progress The Setup page shows the progress of the installation. This includes preparing for installation, copying files, linking libraries, and creating setup files. No action is required on this page unless the installation fails with errors. If errors do occur, they will need to be corrected before proceeding with the installation.
11.2
Executing root Configuration Scripts
Executing root Configuration Scripts The Execute Configuration scripts dialog box appears, indicating configuration scripts that need to be executed as the root user. The orainstRoot.sh script is executed to change the permission of the Oracle Central Inventory directory by adding read and write permissions for the group, along with removing the read, write, and execute permissions for world. The root.sh script copies files to the /usr/local/bin directory, creates the /etc/oratab file, creates OCR keys for the grid user, starts the ohasd daemon, and modifies the /etc/inittab to automatically start the ohasd daemon when the machine is started. After you execute the root scripts, click the OK button to return to the Setup progress page and proceed with the installation. Note: The ohasd daemon is the Oracle High Availability Services daemon. In an Oracle Restart environment the ohasd daemon manages application resources.
11.2
Executing Configuration Assistants
Executing Configuration Assistants The Oracle Net Configuration Assistant (NETCA) is invoked with a silent installation method to create the network configuration files, followed by the Automatic Storage Management Configuration Assistant (ASMCA) to create the ASM disk group and register ASM components with Oracle Restart.
11.2
Finishing the Installation
Finishing the Installation The Finish page is displayed at the end of the installation. Click the Close button to exit the OUI utility. Note: At this point Grid Infrastructure daemons are running, the ASM instance is started, a single disk group is mounted, and the listener is running.
11.2
Configuring the FRA Disk Group
Configuring the FRA Disk Group Because you can configure only one disk group during the installation of Oracle Grid Infrastructure, the creation of further disk groups must be done manually. In this scenario, the FRA disk group is used for the fast recovery area of the database. The ASM Configuration Assistant (ASMCA) utility provides an intuitive GUI interface allowing you to easily create new or remove existing ASM disk groups.
11.2
Oracle Local Registry

Oracle Clusterware 11g Release 2 includes an Oracle Local Registry (OLR) on each node for node-specific resources. Is installed and configured when Oracle Clusterware is installed Is located at Grid_home/cdata/localhost/$host_name.olr in case of single-instance installations Allows multiple processes on each node simultaneous read and write access to the local OLR of that node Is managed with the local option for the OCRCHECK, OCRDUMP, and OCRCONFIG commands as follows:
$ ocrcheck local $ ocrdump local stdout $ ocrconfig local -manualbackup
Oracle Local Registry Oracle Clusterware 11g Release 2 includes an Oracle Local Registry (OLR) on each individual node of a cluster or single-instance installation for storing node-specific resource information. The OLR can be accessed by all processes on the same node for full simultaneous read and write operation regardless of whether Oracle Clusterware is running or not. It cannot be accessed by remote processes running on other nodes of the cluster. The OLR location for single-instance installation is Grid_home/cdata/localhost/$host_name.olr and is identified by the /etc/oracle/olr.loc file. The OLR is installed and configured when Oracle Clusterware is installed, and should require no additional user configuration upon installation. The OLR is managed by adding the local option to the OCRCHECK, OCRDUMP, and OCRCONFIG commands as shown in the slide. You can define the backup location of the OLR using the ocrconfig local backuploc file_name command. The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR. You should create a new OLR backup each time you modify your Oracle Restart configuration.
Important Instructions To restore the OLR, use the following commands as root:
crsctl stop crs ocrconfig -local -restore file_name ocrcheck local crsctl start crs
Quiz
Before installing Oracle Grid Infrastructure, you must implement user role separation. 1. True 2. False
Answer: 2
Practice 1-1: Overview
In this practice, you install the Oracle Grid Infrastructure for a stand-alone server.
11.2
ASM Files and Volumes

user
ASM Instance ASM Instance

ASM Cluster File System (ACFS) ASM Cluster File System (ACFS) ACFS Snapshots ACFS Snapshots Dynamic Volume Manager Dynamic Volume Manager ASM Device File: /dev/asm/dgbvol1-123
Kernel
OS
ASM Files ASM Disk Group

DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files DB files
Dynamic Volumes
ACFS
3rd Party FS
ASM Files and Volumes The ASM feature of Oracle Database has been extended in Oracle Grid 11g Release 2 to include support for a general purpose cluster file system, ASM Cluster File System (ACFS). To understand the operation of this feature, some terminology needs to be defined and explained. At the OS user level, the ASM instance provides the disk group which is a logical container for physical disk space. The disk group can hold ASM database files and ASM dynamic volume files. The ASM Dynamic Volume Manager (ADVM) presents the volume device file to the operating system as a block device. The mkfs utility can be used to create an ASM file system in the volume device file. Once mounted, general purpose files may be created in the ACFS. There are four OS kernel modules that are loaded in the OS, providing the data service. On Linux they are: oracleasm, the ASM module; oracleadvm, the ASM Dynamic Volume Manager module; oracleoks, the kernel services module; and oracleacfs, the ASM file system module. These modules provide the ASM Cluster File System, ACFS snapshots, the ADVM, and cluster services. The ASM volumes are presented to the OS as a device file at /dev/asm/<volume name>-nnn, where nnn is the disk group number. The volume device file appears as another ASM file to the ASM instance and ASMCMD utility. But to the OS file system commands, the ASM layers are transparent. Only the general purpose files and directories created in the ACFS and the ACFS snapshots are visible to the OS file system commands.
11.2
ASM Dynamic Volume Manager (ADVM) Concepts
File systems issue input/output (I/O) requests to volume devices. ADVM driver maps I/O requests against a volume device to the corresponding volume file located within an ASM disk group.
ASM Dynamic Volume Manager (ADVM) Concepts The ASM Dynamic Volume Manager (ADVM) is an enabler of ACFS. It provides volume management services and a standard disk device driver interface that enables ACFS to utilize the space allocated to an ASM dynamic volume inside an ASM disk group. In Oracle Database 11g Release 2, a new file type for ASM dynamic volumes is introduced. These volumes use the same striping and mirroring policies as other ASM file types, such as archived logs and database data files. Like other ASM files, an ASM volume file must be wholly contained within a disk group, and there can be many volume files in one disk group. ASM dynamic volumes can be created using SQL or by means of the ASMCMD command-line tool or the ASMCA graphical management tool. After a volume is created, it needs to be enabled in order to generate an operating system device node under /dev/asm. ACFS (or another file system such as NTFS) is created over the ASM volume device. Finally, the ADVM driver maps I/O requests against an ASM volume device to the underlying dynamic volume file contained inside an ASM disk group.
ADVM provides volume management services and a standard disk device interface to ACFS and other file systems. Volume is created using an ASM management tool. Volume is a new ASM file type for ACFS. Volume needs to be enabled to generate an OS device. Devices reside at /dev/asm/<volume-name>.
11.2
ASM Dynamic Volume Striping

Disk Group (1MB AU size, Normal Redundancy )
Secondary AU (Mirror) Primary AU Disk A (Failure Group 1) Disk B (Failure Group 2) Disk C (Failure Group 3) Disk D (Failure Group 4)
Data Stripe (Default: 128KB) Allocation Unit (AU) Volume Extent (64MB)
1 5
...
Volume Extent 1
...
Volume Extent 2
...
Volume Extent 3
...
Volume Extent 4
ASM Dynamic Volume (Default: 128KB stripe width, 4 stripe columns)
1 2 3 4 5
ACFS File
(640KB)
ASM Dynamic Volume Striping The diagram in this slide illustrates the relationship between an ASM Dynamic Volume and the ASM structures that underpin it. It also illustrates how files are striped using an ASM Dynamic Volume. A Dynamic Volume is essentially the same as an ASM file. It is made up of units of space known as Allocation Units (AU). These are spread across the available disks in an ASM Disk Group and may be mirrored for data protection purposes. Like any other ASM file, a Dynamic Volume must be wholly contained with a single disk group. Dynamic Volume extents and space allocation differs from regular ASM files. In a disk group with an AU size of 1 MB, each volume extent is 64 MB in size. Volume extents are allocated in groups based on the number of striping columns specified for the volume. The default number of striping columns is 4. The volume extent size multiplied by the number of striping columns determines the volume allocation unit (VAU) for the volume. The default VAU is 256 MB for a volume created in a disk group with a 1 MB AU. The overall size of a volume must be a multiple of the VAU. Volume striping is similar to fine grain ASM striping. The default stripe settings specify a stripe size of 128 KB with four striping columns. In other words, data is written in turn across four allocation units in 128 KB chucks until each group of four AUs is filled. Setting the number of columns on an Oracle ADVM volume to 1 effectively turns off striping for the ADVM volume. Note: To add a volume to an ASM disk group, the COMPATIBLE.ASM and COMPATIBLE.ADVM disk group attributes must be set to 11.2.
11.2
ADVM Restrictions
ADVM Restrictions Although ADVM provides a standard disk device interface for dynamic volumes, the following restrictions should be noted: Device partitions are not supported on Oracle ADVM dynamic volumes. Dynamic volumes supersede traditional device partitioning. Each volume is individually named and may be configured for a single file system. Oracle ADVM volumes may be created on demand from ASM disk group storage and dynamically resized as required. These attributes make Oracle ADVM volumes far more flexible than physical devices and associated partitioning schemes. On Linux platforms, Oracle ADVM volume devices are created as block devices regardless of the configuration of the storage underpinning the ASM disk group. Do not use raw (8) to map Oracle ADVM volume block devices into raw volume devices. You should not create multipath devices over Oracle ADVM volume devices. Multipathing should be applied over the disk devices that are initially consumed by ASM to construct the disk group underpinning an ADVM volume. You should not use ASMLIB over an ADVM volume device. You cannot layer ASM over ASM in a recursive fashion because this serves no useful purpose and is not supported.
Partitioning of dynamic volumes (using fdisk or similar) is not supported. Do not use raw(8) to map ADVM volume block devices into raw volume devices. Do not create multipath devices over ADVM devices. Do not create ASMLIB devices over ADVM devices. ADVM supports all ASM supported storage solutions except NFS and Exadata. ADVM volumes cannot be used as a boot device or a root file system.
11.2
Creating an ASM Dynamic Volume
Creating an ASM Dynamic Volume Perform the following steps to create an ASM dynamic volume: 1. On the Enterprise Manager home page, scroll down to the Instances section. Click the name of one of the ASM instances. 2. On the Automatic Storage Management page, click the ASM Cluster File System tab. 3. On the ASM Cluster File System tab, click Create. 4. On the Create ASM Cluster File System page, click Create ASM Volume.
11.2
Creating an ASM Dynamic Volume
Creating an ASM Dynamic Volume (continued) On the Create ASM Volume page, enter a volume name and size. In this example, a volume named testvol with a size of 1 GB is created. If you click Show SQL, you see the following SQL command:
ALTER DISKGROUP DATA ADD VOLUME TESTVOL SIZE 1G;
Click OK to create the volume. Optionally, you can specify a region of the physical disk in the disk group where the extents should be placed. Optimal Disk Placement is discussed in detail in the ASM Enhancements lesson. The ASMCMD command to add a volume is:
ASMCMD> volcreate -d DATA -s 1G testvol
You can use the ASMCMD and SQL commands to view the volume information as shown below:
ASMCMD> volinfo a SQL> SELECT * FROM v$asm_volume;
11.2
Managing ASM Dynamic Volumes
Managing ASM Dynamic Volumes There are pages in Enterprise Manager that enable you to create, delete, and manage ASM volumes. You can also query the V$ASM_VOLUME dynamic view to obtain information about the ASM volumes.
SQL> SELECT volume_name, volume_device, state, usage, 2 mountpath, size_mb, redundancy 3 FROM v$asm_volume; VOLUME_NAME VOLUME_DEVICE STATE USAGE --------------- ------------------------- -------- -----MOUNTPATH SIZE_MB REDUND ----------------------------------- ---------- -----ACFS_DB1 /dev/asm/acfs_db1-481 ENABLED ACFS /u01/app/oracle/acfsmounts/acfs_db1 6144 UNPROT
11.2
Using SQL to Manage ASM Dynamic Volumes

Add a volume:
SQL> ALTER DISKGROUP DGROUPA ADD VOLUME asmvol1 SIZE 10G;
Resize a volume:
Drop a volume:
SQL> ALTER DISKGROUP DGROUPA DROP VOLUME asmvol1;
Using SQL to Manage ASM Dynamic Volumes There are new SQL commands that enable you to manage ASM volumes. Note that each volume is managed as a part of a disk group. You can create volumes, resize the volume, and drop volumes as shown in the examples in the slide. Note: When you create a volume named asmvol1 in the DGROUPA disk group (as shown in the example in the slide), a device is created in /dev/asm named asmvol1-xxx, where xxx is a number unique to the disk group.
SQL> ALTER DISKGROUP DGROUPA RESIZE VOLUME asmvol1 SIZE 15G;
11.2
Using SQL to Manage ASM Dynamic Volumes

Enable a volume:
SQL> ALTER DISKGROUP DGROUPA ENABLE VOLUME asmvol1;
Disable a volume:
Modify a volume:
SQL> ALTER DISKGROUP DGROUPA MODIFY VOLUME asmvol1 USAGE 'acfs';
Using SQL to Manage ASM Dynamic Volumes (continued) You can enable and disable volume as shown in the slide. The MODIFY VOLUME clause enables you to set the intelligent data placement option [HOT|COLD], the mount point, and the usage name of the volume. Intelligent data placement enables you to specify disk regions on Oracle ASM disks for best performance and is discussed in detail in the lesson titled ASM Enhancements.
SQL> ALTER DISKGROUP ALL DISABLE VOLUME ALL;
11.2
Extending ASMCMD for ASM Dynamic Volumes

volcreate -G diskgroup -s size [--column number] [--width stripe_width] [--redundancy {high|mirror|unprotected}] [--primary {hot|cold}] [--secondary {hot|cold}] volume volresize -G diskgroup -s size [-f] volume voldelete -G diskgroup volume volenable {-a|-G diskgroup -a|-G diskgroup volume} voldisable {-a|-G diskgroup -a|-G diskgroup volume} volset -G diskgroup [--usagestring string] [--mountpath mount_path] [--primary {hot|cold}] [--secondary {hot|cold}] volume volinfo {-a|-G diskgroup -a|-G diskgroup volume} volinfo [--show_diskgroup|--show_volume] volumedevice
Extending ASMCMD for ASM Dynamic Volumes The commands shown in the slide have been added to ASMCMD to allow the ASM volumes to be managed from ASMCMD. The ASMCMD commands allow you to have the same level of control through ASMCMD as you do through SQL*Plus commands or Enterprise Manager. Refer to Oracle Database Storage Administrator's Guide 11g Release 2 (11.2) for detailed information about each command and its options.
11.2
ASM Cluster File System (ACFS)
General purpose scalable file system

Journaling, extent based Single node and cluster
Multi OS platform (Linux and Windows at initial release)

POSIX, X/OPEN file system solution for UNIX/Linux Windows file system solution for Windows platforms
Accessible through NAS protocols (NFS, CIFS) Integrated with Oracle Clusterware for cluster support Integrated with Oracle system management tools
Oracle installation and configuration Enterprise Manager and ASM storage management tools Native OS file system management tools
ASM Cluster File System The ASM Cluster File System (ACFS), extends Automatic Storage Management (ASM) by providing a robust, general purpose, extent-based, and journaling file system. ACFS provides support for files such as Oracle binaries, report files, trace files, alert logs, and other application data files. With the addition of ACFS, ASM becomes a complete storage management solution for both Oracle database and non-database files. ACFS scales from small files to very large files (exabytes) and supports large numbers of nodes in a cluster. ACFS is an extent-based file system to provide high performance and uses a log-based metadata transaction engine for file system integrity and fast recovery. The ACFS on-disk structure supports endian neutral metadata. ACFS systems can be exported to remote clients through industry standard protocols such as network file system (NFS) and Common Internet File Systems (CIFS). ACFS eliminates the need for third-party cluster file system solutions while simplifying all file-type management in a single node, as well as RAC and Grid computing environments. ACFS supports dynamic file system expansion and contraction without any down time. ACFS is highly available, making use of the ASM mirroring and striping features in addition to hardware RAID functionality. ACFS is integrated with the Oracle tools for easy installation and configuration. ACFS can be managed with Enterpriser Manager, SQL*Plus, and ASMCMD. ACFS is integrated with native OS file management tools, so the file system is transparent to users.
11.2
ACFS Architecture
Oracle Database 3rd Party Application ASM Cluster File System Dynamic Volume Manager ASM Instance Database & Clusterware Files Disk Group ACFS Files 3 Party File System Files Dynamic Volume
rd
3rd Party File System
ASM
ACFS Architecture ACFS extends the architecture of ASM. The ACFS architecture introduces a new ASM file type, known as a dynamic volume. A dynamic volume is essentially an ASM file that can be presented as a volume to a file system rather than as a data file to the Oracle database. The ASM Dynamic Volume Manager (ADVM), and associated device driver provides the interface between dynamic volumes and the ASM cluster file system. You can even run other file systems, such as NT File System (NTFS) for example, over an ASM dynamic volume.
11.2
Using Enterprise Manager to Manage ACFS
Using Enterprise Manager to Manage ACFS You can use Enterprise Manager to create and manage an ASM Cluster File System.
11.2
Linux/UNIX File System APIs
Standard POSIX and X/OPEN file system APIs and commands are used to manage ACFS. Administration commands used to manage the ACFS file system include:
Linux/UNIX File System APIs The ACFS file system is integrated with the POSIX and X/OPEN file system APIs and commands. This allows users and administrators to use ACFS transparently. Standard file system access commands are transparently supported with ACFS. Administration commands such as mkfs, fsck, mount, and unmount are used to manage the ACFS file system.
mkfs fsck mount unmount
11.2
Linux/UNIX Extensions
Create an ACFS file system:

$ mkfs -t acfs /dev/asm/asmvol1-216
Mount an ACFS file system:
Unmount an ACFS file system:

$ umount [-v]
Check and repair an ACFS file system:

$ fsck -t acfs /dev/asm/asmvol1-216
Linux/UNIX Extensions The administration commands have extensions to handle the differences between ACFS and other file systems. Most of these extensions use the familiar file system type and file system specific option parameters just as other file systems do. Create an ACFS file system:
mkfs [-vf] -t acfs [-b blksz] [-n name ] device [blocks]

mount [-v] -t acfs [-o options] device dir

umount [-v] device|dir

fsck [-avnf] -t acfs [info] device
The example commands in the gray boxes show the most common usage. Each command is typed on one line. The mount command example is shown with the backslash continuation character to format the command for the slide. Note: The examples assume that the volume that was created was named asmvol1-216, where 216 is a number unique to the disk group.
$ mount -t acfs /dev/asm/asmvol1-216 \ /oracle/cluster1/myacfs
11.2
Windows File System APIs
Windows file management APIs and commands are integrated with the ACFS file system. Additional commands include:
acfschkdsk acfsformat acfsmountvol acfsdismount
Windows File System APIs The Windows file management APIs are integrated with the ACFS file system. A few administration commands have been added as shown in the slide.
11.2
Windows Extensions
Create an ACFS file system:

acfsformat [/vf] [/b blksz] [/n name] device [blocks]

acfsdismount [/v] [/p] [/P] path

acfschkdsk [/a] [/v] [/n] [/f] [info] device
Windows Extensions Create an ACFS file system:

acfsformat [/vf] [/b blksz] [/n name] device [blocks]

acfsmountvol [/all] [/v]

acfsdismount [/v] [/p] [/P] path

acfschkdsk [/a] [/v] [/n] [/f] [info] device
acfsmountvol [/all] [/v]
11.2
ACFS Platform-Independent Commands

Command
acfsutil info
Function
Display new ACFS file and file system features (ACFS, snapshots, registry, size) and information. Create and display ACFS snapshots. Register an ACFS file system with the ACFS mount registry. Remove an ACFS file system. Resize an ACFS file system. View or modify ACFS tuneables.
acfsutil snapshot acfsutil registry
acfsutil rmfs acfsutil size acfsutil tune
ACFS Platform-Independent Commands New ACFS commands for Linux/UNIX and Windows that are not natively supported are listed in the slide.
11.2
ASM Cluster File System Limitations

ACFS: Cannot be used for root file system or bootable partition Cannot be used for the Grid Infrastructure home directory ASM Dynamic Volume Manager (ADVM) Presents a block device called a volume to the OS Uses a device driver
ASM Cluster File System Limitations An ADVM volume is constructed from an ASM file. One or more ADVM volumes may be configured within each ASM disk group. The ADVM Driver maps I/O requests against an ADVM volume to blocks in a corresponding ASM file and disk set located within an ASM disk group. An ADVM volume device exports ASM volume manager features and ensures that volume mirrors remain consistent in the face of abnormal system shutdowns, ASM instance failures, or system crashes. The ADVM volume can be extended dynamically if there is space available in the ASM disk group.
11.2
Creating an ASM Cluster File System
Create an ASM Cluster File System In this example, an ASM Cluster File System is created on the testvol ASM volume that was created previously. Note that a unique number is added to the volume name. This number is system assigned. Complete the fields on the page as follows: Assign a volume label. In this example, it is labeled test. Assign a mount point. The mount point must be an existing directory. Best practice is to place the ACFS mount points in a common directory below the ORACLE_BASE directory. In this example, ORACLE_BASE is /u01/app/oracle. The common directory is acfsdata and the mount point is /u01/app/oracle/acfsdata/test. The mount point directory must be created on all the nodes of the cluster. If you click Show Command, you can view the commands used to make the file system on the ASM volume and to register the volume and mount point. For Linux, the commands are:
$ /sbin/mkfs -t acfs -b 4k /dev/asm/testvol-93 -n "test" $ /sbin/acfsutil registry -f -a /dev/asm/testvol-93 \ /u01/app/oracle/acfsdata/test
Click OK to perform the operations. The file system will be created on the ASM volume and the volume will be registered. The file system is then mounted on all the nodes of the cluster. Note: Automount of ACFS mount points is not supported for single-node installations.
11.2
ACFS Snapshots
Snapshots only consume space for changed data. Snapshot maintenance has very low overhead.
Snapshots can be created on demand to deliver a current, consistent, online view of an active file system.
ACFS Snapshots An Oracle ACFS snapshot is an online, read-only, point-in-time copy of an Oracle ACFS file system. The snapshot copy is initially sparse and merely references the storage allocation information maintained by the file system. Before an Oracle ACFS file extent is modified or deleted, its current value is copied to the snapshot using a copy-on-write (COW) technique to maintain the snapshot's point-in-time view of the file system. Oracle ACFS snapshots are immediately available for use after they are created. They are always online while the file system is mounted. As a result, an Oracle ACFS snapshot can support the online recovery of files that are inadvertently modified or deleted from a file system. With up to 63 snapshot views supported for each file system, flexible online file recovery solutions spanning multiple views can be employed. An Oracle ACFS snapshot can also be used as the source of a file system backup because it can be created on demand to deliver a current, consistent, online view of an active file system. Oracle ACFS snapshot storage is maintained within the file system, eliminating the need to manage separate storage pools for file systems and snapshots. Oracle ACFS file systems can be dynamically resized to accommodate additional file and snapshot storage requirements.
An ACFS snapshot is an online, space-efficient, pointin-time copy of an ACFS file system. Snapshot copy is initially sparse, referencing the storage allocation information maintained by the file system. Snapshot storage is maintained within the file system. Before an ACFS file extent is modified or deleted, a copy is saved to the snapshot (copy-on-write).
11.2
Administering Oracle ACFS Snapshots
Oracle ACFS snapshots are administered by using ACFSUTIL snap commands Create a read-only snapshot of an Oracle ACFS file system:
acfsutil snap create snapshot mount_point
Delete a read-only snapshot of an Oracle ACFS file system:

acfsutil snap delete snapshot mount_point
Administering Oracle ACFS Snapshots To create a read-only snapshot of an Oracle ACFS file system, use the following command:
acfsutil snap create snapshot mount_point
Specify the parameters as follows: snapshot: Snapshot name. The .ACFS/snaps directory itself cannot be snapped. mount_point: The mount point The snapshot appears in .ACFS/snaps/snapshot and is a complete replica of the file system at the time the snapshot command was executed. To delete a read-only snapshot of an Oracle ACFS file system, use the following command:
acfsutil snap delete snapshot mount_point
The command deletes the named snapshot in the Oracle ACFS mounted on the specified mount_point. After successful completion of the command, the representation of the snapshot in the .ACFS/snaps directory is removed. The command fails if any file within the snapshot is open on any cluster node. Note: Administrator privileges are required to use the snap create and snap delete commands, or you must be a member of the Oracle ASM administrator group.
Quiz
ASM Cluster File System (ACFS) provides support for Oracle Database binary files. 1. True 2. False
Answer: 1
Summary
In this lesson, you should have learned how to: Install Oracle Grid Infrastructure for a stand-alone server and create an ASM disk group Use the ASM Configuration Assistant (ASMCA) to create an ASM disk group Create and manage ASM Dynamic Volumes Create and manage an ASM Cluster File System
In this practice, you configure the ASM cluster file system.
Installation Enhancements
Objectives
After completing this lesson, you should be able to: Install Oracle Database 11g Enable Direct NFS Use online patching
11.2
Oracle Database 11g Installation: Changes
Addition of new products to the installation:

Oracle Application Express Oracle Configuration Manager (OCM) SQL Developer Warehouse Builder (server-side pieces) Oracle Database Vault Data Mining OLAP Partitioning Real Application Testing
Default options:
Oracle Database 11g Installation: Changes The following are the new components that are available when you install Oracle Database 11g Release 2: Oracle Application Express is installed with Oracle Database 11g. It was previously named HTML DB and was available as a separate companion CD component. Oracle Configuration Manager is offered during installation. It was previously named Customer Configuration Repository (CCR). It is an optional component for database installation. Oracle Configuration Manager gathers and stores details relating to the configuration of the software stored in Oracle Database home directories. Oracle SQL Developer is installed by default with template-based database installations, such as General Purpose/Transaction Processing and Data Warehousing. It is also installed with database client Administrator, Runtime, and Custom installations. Oracle Warehouse Builder is installed with Oracle Database 11g. Oracle Database Vault is an optional component for installation with Oracle Database 11g. It was previously available as a separate companion CD component.
Move to JDK/JRE 1.5 Removal of certain products and features from the installation:
OEM Java Console Raw storage support for data files Oracle Data Mining Scoring Engine Oracle Workflow iSQL*Plus Oracle Ultra Search Workload Manager
Addition of new prerequisite checks Changes to the default file permissions

Oracle Database 11g Release 2 Installation: Changes (continued) The following components are part of Oracle Database 10g, Release 2 (10.2) but are not available for installation with Oracle Database 11g Release 2: Oracle Enterprise Manager Java Console Oracle Data Mining Scoring Engine Oracle Workflow iSQL*Plus
Support for upgrade of Oracle XE databases directly to Oracle Database 11g Better conformance to OFA in the installation:
Prompt for ORACLE_BASE explicitly Warnings in the alert log when ORACLE_BASE is not set
Oracle Database 11g Installation: Changes (continued) In Oracle Database 11g, Oracle Universal Installer (OUI) prompts you to specify the Oracle base. The Oracle base that you provide during installation is logged in the local inventory. You can share this Oracle base across all of the Oracle homes that you create on the system. Oracle Corporation recommends that you share an Oracle base for all of the Oracle homes created by a user. Oracle Universal Installer has a list box in which you can edit or select the Oracle base. The installer derives the default Oracle home from the Oracle base location that you provide in the list box. However, you can change the default Oracle home by editing the location. The following are changes made in Oracle Database 11g with respect to the Oracle base to make it compliant with Optimal Flexible Architecture (OFA): ORACLE_BASE is a recommended environment variable. In Oracle Database 10g, the default flash recovery area and the data file location are one level above the Oracle home directory. However, in Oracle Database 11g, the Oracle base is the starting point to set the default fast recovery area and the data file location. Oracle Corporation recommends that you keep the fast recovery area and data file location on separate disk groups in ASM.
11.2
Part Two: Installing the Oracle Database Software
Part Two: Installing the Oracle Database Software In this lesson, the installation steps for the Oracle Database software are reviewed. Log on to your computer as a member of the administrative group that is authorized to install the Oracle software, and to create and manage the database. Insert the distribution CD for the database into your CD drive, or navigate to the Oracle database staging location. From that location enter ./runInstaller to start the Oracle Universal Installer (OUI). If desired, enter the email address where you want to be informed of security issues. If you want to receive security updates via My Oracle Support, also include your My Oracle Support password. If you do not enter your email address, a warning message is displayed asking if you are sure you do not want to be informed about critical issues in your configuration. Click Yes in response to this warning to continue with the installation.
11.2
Choosing the Type of Installation
Choosing the Type of Installation The Select Installation Option page is displayed. Choose the type of installation that you want to perform: Create and Configure a Database: This option creates a database after the product is installed. Install Database Software Only: This option installs only the Oracle Database binaries. Upgrade an Existing Database: This option is used to upgrade a database of an earlier release. Click Next.
11.2
Choosing Grid Installation Options
Choosing Grid Installation Options The Grid Installation Options page is displayed. Choose whether this is to be a single instance database installation or an Oracle Real Application Clusters (RAC) database installation on a cluster. Click Next to continue.
11.2
Choosing Language Settings
Choosing Language Settings The Select Product Languages page is next. Here you select all the languages in which your product will run. English is selected by default and cannot be removed from the Selected Languages list. Click Next to continue.
11.2
Choosing the Database Edition
Choosing the Database Edition The Select Database Edition page is displayed. Choose from one of the following three editions: Enterprise Edition: This edition delivers a self-managing database that provides performance, scalability, security, and reliability on a choice of clustered or singleservers. It provides comprehensive features to easily manage the most demanding transaction processing, business intelligence, and content management applications. Standard Edition: This edition provides a full-featured database for servers with up to four sockets. It includes Oracle Real Application Clusters for higher availability, provides enterprise-class performance and security, is simple to manage, and can easily scale as demand increases. It is also upwardly compatible with the Enterprise edition. Standard Edition One: This edition provides a full-featured database for servers with up to two sockets. It provides enterprise-class performance, security, and manageability that can easily scale as demand increases. It is also upwardly compatible with other database editions. Click the Select Options button to further customize what components are installed. Click Next when finished with all selections on the Select Database Edition page.
11.2
Specifying Installation Location
Specifying Installation Location The Specify Installation Location page is displayed next. A suggested Oracle base path appears by default. You can change the path based on your requirement. In the Software Location section, you can accept the default values or enter the Oracle home name and directory path in which you want to install the Oracle components. The directory path should not contain spaces. Click Next to continue the installation process.
11.2
Choosing Operating System Groups
Choosing Operating System Groups The Privileged Operating System Groups page is displayed. Choose the appropriate operating system group for the OSDBA and OSOPER privileges. By default dba is specified for OSDBA and oper is specified for OSOPER. Click Next to continue.
11.2
Performing Prerequisite Checks
Performing Prerequisite Checks The Perform Prerequisite Checks page is displayed. The OUI goes through various prerequisite checks. After all the checks have been performed, the OUI displays a message if any of the tests fail. No action is required on this page unless the checks fail with errors. If errors do occur, they will need to be corrected before proceeding with the installation. In most cases, OUI is able to correct those errors by instructing you to run a script that will correct these issues and then run the checks again. If the error is not fixable, you must either fix the problem manually or choose Ignore All and continue with the installation (if the failed check is not critical). Click Next to continue.
11.2
Installation Summary Page
Installation Summary Page The Summary page is displayed. Review the information presented that is related to the installation answers provided on previous windows. You are presented with the option to save the interactive installation questions and answers to a response file. A response file can be used in future installations to perform a silent installation in the same manner in which this installation is being performed. The response file is a text file and can also be edited with a text editing tool to modify it for a different installation. Click the Finish button to proceed with the installation.
11.2
Install Product Page
Install Product Page Your installation process pauses at this point, requiring you to execute an additional configuration script as the root user. In a separate terminal window, enter:
$ su # password: oracle <root password, does not appear in the window> # /u01/app/oracle/product/11.2.0/dbhome_1/root.sh
Accept the default for the local bin directory during a Linux or UNIX installation. When the script is finished, exit from the root account and close the window. Click OK in the Execute Configuration scripts dialog box to allow the installation to complete.
11.2
Installation Finish Page
Installation Finish Page After all the installation steps are completed, the Finish page is displayed. Click the Close button to exit the OUI utility.
Quiz
During the installation of Oracle Database, you can specify whether you want to receive security updates via My Oracle Support. 1. True 2. False
Answer: 1
In this practice, you install the Oracle Database 11g software.
11.2
Oracle Database 11g Release 2 Upgrade Paths
9.2.0.8 9.2.0.8
10.2.0.2 10.2.0.2
11.2 11.2
11.1.0.6 11.1.0.6
Oracle Database 11g Release 2 Upgrade Paths The path that you must take to upgrade to Oracle Database 11g Release 2 depends on the release number of your current database. It might not be possible to upgrade directly from the current version of the Oracle Database to the latest version. Depending on your current release, you might be required to upgrade through one or more intermediate releases to upgrade to Oracle Database 11g Release 2. For example, if the current database is running release 8.1.6, follow these steps: 1. Upgrade release 8.1.6 to release 8.1.7.4 by using the instructions in Oracle8i Database Migration, Release 3 (8.1.7). 2. Upgrade release 8.1.7.4 to release 10.2.0.4 by using the instructions in Oracle Database Upgrade Guide 10g Release 2 (10.2). 3. Upgrade release 10.2.0.4 to Oracle Database 11g Release 2 by using the latest Upgrade Guide.
10.1.0.5 10.1.0.5
11.2
Deprecated Features in Oracle Database 11g Release 1 and Release 2

Features deprecated in Oracle Database 11g Release 1:
Oracle Ultra Search Java Development Kit (JDK) 1.4 CTXXPATH index
Features deprecated in Oracle Database 11g Release 2:
Deprecated Features in Oracle Database 11g Release 1 and Release 2 The slide lists the Oracle Database features that are deprecated in Oracle Database 11g Release 1 and Release 2. Although they are supported in this release for backward compatibility, Oracle recommends that you migrate away from these deprecated features: Oracle Ultra Search Java Development Kit (JDK) 1.4: Oracle recommends that you use JDK 5.0; however, JDK 1.5 is also fully supported. CTXXPATH index: Oracle recommends that you use XMLIndex instead. Workload Manager
Workload Manager
Initialization Parameter Information
USER_DUMP_DEST DIAGNOSTIC_DEST BACKGROUND_DUMP_DEST CORE_DUMP_DEST UNDO_MANAGEMENT not set implies AUTO mode. CONTROL_MANAGEMENT_PACK_ACCESS
Specifies the Server Manageability Packs that should be active Default is DIAGNOSTIC+TUNING
Initialization Parameter Information The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST, BACKGROUND_DUMP_DEST, and CORE_DUMP_DEST parameters. Starting with Oracle Database 11g, the default location for all trace information is defined by DIAGNOSTIC_DEST, which defaults to $ORACLE_BASE/diag. Old parameters are ignored if specified. For more information about diagnostics, refer to the lesson titled Diagnosability Enhancements. A newly installed Oracle Database 11g instance defaults to automatic undo management mode, and, if the database is created with the DBCA, an undo tablespace is automatically created. A null value for the UNDO_MANAGEMENT initialization parameter now defaults to automatic undo management; in previous releases, it defaulted to manual undo management mode. You must, therefore, be careful when upgrading a previous release to Oracle Database 11g.
Important Initialization Parameter Changes (continued) Note: The CONTROL_MANAGEMENT_PACK_ACCESS initialization parameter controls access to the Oracle Diagnostic Pack and the Oracle Tuning Pack. The Oracle Diagnostic Pack includes AWR, ADDM, and so on. The Tuning pack includes SQL Tuning Advisor, SQL Access Advisor, and so on. Refer to Oracle Database Licensing Information 11g Release 2 for complete information about the packs. The Diagnostic Pack must be enabled before the Tuning Pack can be enabled. The possible values for the CONTROL_MANAGEMENT_PACK_ACCESS parameter: NONE: Diagnostic Pack and Tuning Pack functionality is disabled in the database server. DIAGNOSTIC: Only Diagnostic Pack functionality is enabled in the server. DIAGNOSTIC+TUNING (default): Diagnostic Pack and Tuning Pack functionality is enabled in the database server.
In this practice, you create a database.
In this practice, you use ASM cluster file system snapshots.
Direct NFS Client: Overview

Oracle Database 10g
Oracle RDBMS kernel Specific configuration parameters Specific kernel NFS driver
Optional generic configuration parameters
Oracle Database 11g

Oracle RDBMS kernel
DBA
Variations across platforms Many parameters to tune
NAS Storage
Ease of NFS configuration Fewer parameters to tune
NAS Storage
(NFS V3)
Direct NFS Client: Overview Direct NFS is implemented as a Direct Network File System client as part of the Oracle RDBMS kernel in the Oracle Disk Manager library. NAS-based storage systems use Network File System to access data. In Oracle Database 10g, NAS storage devices are accessed using the operating systemprovided kernel Network File System driver, which requires specific configuration settings to ensure its efficient and correct usage with Oracle Database. The following are the major problems that arise from incorrectly specifying these configuration parameters: NFS clients are very inconsistent across platforms and vary across operating system releases. With more than 20 parameters to tune, manageability is affected. Oracle Direct Network File System implements the NFS version 3 protocol in the Oracle RDBMS kernel. The following are the main advantages of implementing Oracle Direct NFS: It enables complete control over the input/output path to Network File Servers. This results in predictable performance and enables simpler configuration management and a superior diagnosability. Its operations avoid the kernel Network File System layer bottlenecks and resource limitations. However, the kernel is still used for network communication modules.
Specific kernel NFS driver
Direct NFS Client: Overview (continued) It provides a common Network File System interface for Oracle for potential use on all host platforms and supported Network File System servers. It enables improved performance through load balancing across multiple connections to Network File System servers and deep pipelines of asynchronous input/output operations with improved concurrency.
Direct NFS Configuration
Mount all expected mount points using kernel NFS driver.
(Optional) Create an oranfstab file.
Mount points lookup order

$ORACLE_HOME/dbs/oranfstab
/etc/oranfstab
Load balancing and failover
server: MyDataServer1 path: 132.34.35.12 path: 132.34.35.13 export: /vol/oradata1 mount: /mnt/oradata1
/etc/mtab
Direct NFS Configuration By default, Direct NFS attempts to serve mount entries found in /etc/mtab. No other configuration is required. You can optionally use oranfstab to specify additional Oraclespecific options to Direct NFS. For example, you can use oranfstab to specify additional paths for a mount point as shown in the example in the slide. When oranfstab is placed in $ORACLE_HOME/dbs, its entries are specific to a single home. However, when oranfstab is placed in /etc, it is global to all Oracle databases and thus, can contain mount points for all Oracle databases. Direct NFS looks for the mount point entries in the following order: $ORACLE_HOME/dbs/oranfstab, /etc/oranfstab, and /etc/mtab. It uses the first matched entry as the mount point. In all cases, Oracle requires that mount points be mounted by the kernel NFS system even when being served through Direct NFS. Oracle verifies kernel NFS mounts by cross-checking entries in oranfstab with the operating system NFS mount points. If a mismatch exists, Direct NFS logs an informational message and does not serve the NFS server.
mv libodm11.so libodm11.so_stub ln -s libnfsodm11.so libodm11.so
cp libodm11.so libodm11.so_stub ln -s libnfsodm11.so libodm11.so
Use one of the following methods to disable the Direct NFS client: Remove the oranfstab file. Restore the stub libodm11.so file by reversing the process you completed in step 3. Remove the specific NFS server or export paths in the oranfstab file. Note If you remove an NFS path that the Oracle Database is using, you must restart the database for the change to be effective. If Oracle Database is unable to open an NFS server using Direct NFS, it uses the platform operating system kernel NFS client. In this case, the kernel NFS mount options must be set up correctly. Additionally, an informational message is logged in to the Oracle alert and trace files indicating that Direct NFS could not be established. With the current ODM architecture, there can be only one active ODM implementation for each instance at any given time. Using NFS ODM in an instance precludes any other ODM implementation. The Oracle files resident on the NFS server that are served by the Direct NFS Client are also accessible through the operating system kernel NFS client. The usual considerations for maintaining integrity of the Oracle files apply in this situation.
Direct NFS Configuration (continued) Complete the following procedure to enable Direct NFS: 1. Make sure that NFS mount points are mounted by your kernel NFS client. The file systems to be used through ODM NFS should be mounted and available over regular NFS mounts for Oracle to retrieve certain bootstrapping information. The mount options that are used in mounting the file systems are not relevant. 2. (Optional) Create an oranfstab file with the following attributes for each NFS server to be accessed using Direct NFS: - Server: The NFS server name - Path: Up to four network paths to the NFS server, specified either by IP address or by name, as displayed using the ifconfig command. The Direct NFS client performs load balancing across all specified paths. If a specified path fails, Direct NFS reissues I/Os over any remaining paths. - Export: The exported path from the NFS server - Mount: The local mount point for the NFS server 3. Oracle Database uses the ODM library, libnfsodm10.so, to enable Direct NFS. To replace this standard ODM library with the ODM NFS library, complete the following steps: - Change directory to $ORACLE_HOME/lib. - Enter the following commands:
Monitoring Direct NFS

SVR_ID/ ID
V$DNFS_FILES
Join column
V$DNFS_SERVERS
PNUM
V$DNFS_STATS
ID/ SVR_ID
V$DNFS_CHANNELS
Monitoring Direct NFS Use the following views for Direct NFS management: V$DNFS_SERVERS: Shows a table of servers accessed using Direct NFS V$DNFS_FILES: Shows a table of files currently open using Direct NFS V$DNFS_CHANNELS: Shows a table of open network paths (or channels) to servers for which Direct NFS is providing files V$DNFS_STATS: Shows a table of performance statistics for Direct NFS
Online Patching: Overview
Online Patching: Overview Online patching provides the ability to install, enable, and disable a bug fix or diagnostic patch on a live, running Oracle instance. Using online patching is the recommended solution for avoiding down time when applying online patches. Oracle provides the capability to perform online patching with any Oracle database using the opatch command-line utility. Online patches can be provided when the changed code is small in scope and complexity (for example, with diagnostic patches or small bug fixes).
For a bug fix or diagnostic patch on a running Oracle instance, online patching provides the ability to do the following: Install Enable Disable
Installing an Online Patch
opatch query -is_online_patch <patch location> OR opatch query <patch location> -all
Installing an Online Patch Unlike traditional patching mechanisms, applying an online patch does not require instance shutdown or restart. Similar to traditional patching, you can use OPatch to install an online patch. You can determine whether a patch is an online patch by using the following commands:
opatch query -is_online_patch <patch location> or opatch query <patch location> -all
Note: The patched code is shipped as a dynamic/shared library, which is then mapped to memory by each Oracle process.
Applying an online patch does not require instance shutdown, relinking of the Oracle binary, or instance restart. OPatch can be used to install or uninstall an online patch. OPatch detects conflicts between two online patches, as well as between an online patch and a conventional patch. To determine if a patch is an online patch:
Benefits of Online Patching
No down time and no interruption of business Extremely fast installation and uninstallation times Integrated with OPatch:
Conflict detection Listed in patch inventory Works in RAC environment
Persist across instance shutdown and startup
Benefits of Online Patching You do not have to shut down your database instance while you apply the online patch. Unlike conventional patching, online patching enables fast installation and uninstallation. Because online patching uses OPatch, you get all the benefits that you already have with conventional patching that uses OPatch. It does not matter how long or how many times you shut down your databasean online patch always persists across instance shutdown and startup.
Conventional Patching and Online Patching
Conventional Patches
Require down time to apply or remove Installed and uninstalled via OPatch Persist across instance startup and shutdown Take several minutes to install or uninstall
Online Patches
Do not require down time to apply or remove Installed and uninstalled via OPatch
Take only a few seconds to install or uninstall
Conventional Patching and Online Patching Conventional patching basically requires a shutdown of your database instance. Online patching does not require any down time. Applications can keep running while you install an online patch. Similarly, online patches that have been installed can be uninstalled with no down time.
Persist across instance startup and shutdown
Online Patching Considerations
Online patches are supported on the following platforms:

Linux x86 32/64 HP Itanium Sun Sparc Solaris 64 AIX Windows x86 32/64
Some extra memory is consumed.

Exact amount depends on:

Size of patch Number of concurrently running Oracle processes
Minimum amount of memory: Approximately one OS page per running Oracle process
Online Patching Considerations One operating system (OS) page is typically 4 KB on Linux x86 and 8 KB on Solaris SPARC64. With an average of approximately one thousand Oracle processes running at the same time, this represents around 4 MB of extra memory for a small online patch.
Online Patching Considerations
Online Patching Considerations (continued) A vast majority of diagnostic patches are available as online patches. For bug fixes, it really depends on their nature. Not every bug fix or diagnostic patch is available as an online patch. But the long-term goal of the online-patching facility is to provide online-patching capabilities for Critical Patch Updates. Note: You must uninstall the online patch before applying the conventional patch.
There may be a small delay (a few seconds) before every Oracle process installs or uninstalls an online patch. Not all bug fixes and diagnostic patches are available as an online patch. Use online patches in situations when down time is not feasible. When down time is possible, you should install all relevant bug fixes as conventional patches.
Quiz
Answers: 1, 3, and 4
Which of the following statements are true about online patches? 1. Can be installed using OPatch 2. Require down time to apply 3. Persist across instance startup and shutdown 4. Do not require down time to remove
Summary
In this lesson, you should have learned how to: Install Oracle Database 11g Enable Direct NFS Use online patching
In this practice, you use online patching to patch your database.
11.2
Oracle Restart
11.2
Objectives
After completing this lesson, you should be able to use Oracle Restart to manage components.
11.2
Oracle Restart
Oracle Restart implements a high availability solution for stand-alone Oracle databases. Can monitor and restart the following components:
Database instances Oracle Net listener Database services Automatic Storage Management (ASM) instance ASM disk groups Oracle Notification Services (ONS/eONS)
Runs periodic check operations to monitor the health of the components Runs out of the Oracle Grid Infrastructure home, which you install separately from Oracle Database homes
Oracle Restart Oracle Restart is designed to improve the availability of your Oracle Database. It implements a high availability solution for single instance (nonclustered) environments only. For Oracle Real Application Cluster (Oracle RAC) environments, the functionality to automatically restart components is provided by Oracle Clusterware. Oracle Restart can monitor the health and automatically restart the following components: Database instances Oracle Net listener Database services ASM instance ASM disk groups Oracle Notification Services (ONS/eONS): Service for sending Fast Application Notification (FAN) events to integrated clients upon failover. The eONS is used by Oracle Enterprise Manager to receive notification of change in status of components managed by Oracle Restart. Restarting an ASM disk group means mounting it. The ability to restart ONS is applicable only in Oracle Data Guard installations for automatic failover of connections between primary and standby databases through FAN.
Oracle Restart (continued) Oracle Restart ensures that the components are started in the proper order, in accordance with component dependencies. If a component must be shut down, it ensures that the dependent components are cleanly shut down first. Oracle Restart runs out of the Oracle Grid Infrastructure home, which you install separately from Oracle Database homes.
11.2
Oracle Restart Process Startup

Oracle Restart is started by the OS init daemon.
Operating system init daemon init init.ohasd Oracle Restart wrapper script Oracle Restart daemons and processes ohasd.bin oraagent.bin orarootagent.bin diskmon.bin cssdagent ocssd.bin
The Oracle Restart installation modifies the /etc/inittab file to ensure start up every time the machine starts.
# cat /etc/inittab .. h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
Oracle Restart Process Startup During the installation of Oracle Restart, entries to start a wrapper script are placed in the /etc/inittab operating system file. The wrapper script sets up the environment variables and then starts the Oracle Restart daemons and processes. When a command is used to stop Oracle Restart, the daemons will be stopped, but the wrapper script process will remain running. The format of the UNIX /etc/inittab file is as follows: id : run levels : action : process with parameters The wrapper script is started with the respawn action so it will be restarted whenever it is terminated. In addition, the respawn action causes the init process to restart the daemons if they fail. Some of the Oracle Restart daemons will be running under the root user with real-time priority, and others will be running under the Grid Infrastructure owner with user-mode priorities after they are started. On a Windows platform, operating system services are used instead of wrapper initialization scripts and the daemons are executable binaries. Note: Executing the wrapper script directly is not supported.
11.2
Controlling Oracle Restart

The CRSCTL utility can be used to control the state of Oracle Restart. To display the Oracle Restart configuration:
$ crsctl config has
$ crsctl [ enable | disable ] has
To start or stop Oracle Restart:

$ crsctl [ start | stop ] has
Controlling Oracle Restart The CRSCTL utility can be used to control the state of Oracle Restart. It can be used to determine if the autostart capability is enabled or disabled as follows:
$ crsctl config has CRS-4622: Oracle High Availability Services autostart is enabled.
During the installation of Oracle Grid Infrastructure, entries are placed in the /etc/inittab operating system file to start a wrapper script as follows:
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
The wrapper script is responsible for setting up environment variables and then starting the Oracle High Availability Services Daemon (ohas) along with other related processes. The wrapper script is executed as the root user. When the CRSCTL utility is used to disable the automatic restart of the Oracle Grid Infrastructure, the entry in the /etc/inittab file is not removed. The control files for ohas are used to control the state of ohas and determine if automatic restart is enabled or disabled. These are known as SCLS_SCR files. For Linux, the location of the control files is defined to be:
/etc/oracle/scls_scr/$HOST/<Oracle Restart owner> and /etc/oracle/scls_scr/$HOST/root
To enable or disable the automatic restart of Oracle Restart:
Controlling Oracle Restart (continued) If the CRSCTL utility is used to stop Oracle Restart, all components currently managed by Oracle Restart will also be stopped.
$ crsctl stop has CRS-4549: Stopping resources. CRS-2673: Attempting to stop 'ora.diskmon' on 'host01' CRS-2673: Attempting to stop 'ora.DATA.dg' on 'host01' CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'host01' CRS-2677: Stop of 'ora.DATA.dg' on 'host01' succeeded CRS-2673: Attempting to stop 'ora.asm' on 'host01' CRS-2675: Stop of 'ora.diskmon' on 'host01' succeeded CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'host01' succeeded CRS-2677: Stop of 'ora.asm' on 'host01' succeeded CRS-2673: Attempting to stop 'ora.cssd' on 'host01' CRS-2677: Stop of 'ora.cssd' on 'host01' succeeded CRS-2673: Attempting to stop 'ora.diskmon' on 'host01' CRS-2677: Stop of 'ora.diskmon' on 'host01' succeeded CRS-4133: Oracle High Availability Services has been stopped.
In the example above, there is no Oracle Database software installed. If Oracle databases had been registered with Oracle Restart or they had been using ASM, they would have been stopped also. When starting Oracle Restart with the CRSCTL utility, each component that is started is not displayed to standard output.
$ crsctl start has CRS-4123: Oracle High Availability Services has been started.
Note: Invoking the wrapper script directly to start the Oracle Grid Infrastructure processes is not supported.
11.2
Choosing the Correct SRVCTL Utility

Invoke the Server Control (SRVCTL) utility from the Oracle Grid Infrastructure home when working with ASM instances, disk groups, listeners, and ONS.
$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid $ $ORACLE_HOME/bin/srvctl command component options
Invoke the SRVCTL utility from the Oracle Database home when working with the database or database instance.
$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 $ $ORACLE_HOME/bin/srvctl command component options
Choosing the Correct SRVCTL Utility Oracle Restart includes the SRVCTL utility that you use to start, stop, and manage Oracle Restart components. After the Oracle Database software is installed in addition to the Oracle Grid Infrastructure software, there will be a copy of the SRVCTL utility in each ORACLE_HOME location. You need to determine the correct ORACLE_HOME location in which to run the SRVCTL utility. You need to run the SRVCTL utility from the Grid Infrastructure software home directory when managing the ASM instance, ASM disk groups, Oracle Net listeners, and the ONS. You need to run the SRVCTL utility from the Oracle Database software home directory when managing the Oracle database instances. To determine the currently mapped location of the SRVCTL utility, use the which command as follows:
$ which srvctl /u01/app/oracle/product/11.2.0/grid/bin/srvctl
Note: For the Oracle Net listener, the assumption is that Oracle Grid Infrastructure was installed before the Oracle Database software. If Oracle Restart is added to an existing Oracle Database installation, the Oracle Net listener could be running from the Oracle Database home directory. In that case, you should use the SRVCTL utility from the Oracle Database home to manage the Oracle Net listener.
11.2
Oracle Restart Configuration
Oracle utilities will automatically update the Oracle Restart configuration.

Create operations and the Oracle Restart configuration
Create a database with OUI or DBCA Create a database with SQL statement Create an ASM instance with OUI, DBCA, or ASMCA Create a disk group (any method) Add a listener with NETCA Create a database service with SRVCTL Create a database service by modifying SERVICE_NAMES initialization parameter Create a database service with DBMS_SERVICE.CREATE SERVICE
Automatically added to configuration?

YES NO YES YES YES YES NO NO
Oracle Restart Configuration Oracle Restart maintains a list of all the components that it manages, and maintains configuration information for each component. All of this information is collectively known as the Oracle Restart configuration. When Oracle Restart is installed, many operations that create Oracle components using Oracle utilities will automatically add the components to the Oracle Restart configuration. If a component is created manually without using an Oracle utility, then SRVCTL commands can be used to add it to the Oracle Restart configuration if desired. The table in the above slide shows which create operations automatically add the component to the Oracle Restart configuration and which create operations do not update the Oracle Restart configuration. Note: The same principal applies to delete operations.
11.2
Using the SRVCTL Utility

The SRVCTL utility is used to start, stop, and manage Oracle Restart components with the following syntax:
$ srvctl command component options
The following command and components are supported:

Commands Components
add config disable enable getenv modify remove setenv start status stop unsetenv asm db dg filesystem home lsnr serv ons eons
Using the SRVCTL Utility When Oracle Restart is in use, Oracle strongly recommends that you use the SRVCTL utility to start, stop, and manage all Oracle Restart components. The SRVCTL utility is recommended for the following reasons: All dependencies between components are maintained. This enables Oracle Restart to start or to stop any dependent components first. Components are started according to their Oracle Restart configuration. Environment variables stored in the Oracle Restart configuration for the components are set. Oracle Restart components can also be started with other utilities such as the listener control (LSNRCTL) utility or SQL*Plus, but the benefits listed above may not be obtained with other utilities. The SRVCTL utility with Oracle Restart supports 12 commands and 9 components. The options that are allowed vary with each command and component combination. The SRVCTL utility syntax is as follows:
srvctl command component options
where: command is a verb such as start, stop, or remove component is the object on which SRVCTL performs the command, such as a database options extend the use of the preceding command to include additional parameters
11.2
Obtaining Help for the SRVCTL Utility

The SRVCTL utility provides online help for its commands, components, and options. For help with general usage:
$ srvctl -h
$ srvctl command -h
For help on a particular command and component:

$ srvctl command component -h
Obtaining Help for the SRVCTL Utility The SRVCTL utility provides detailed online help for its commands, components, and options. To display the online Help, you use the help (-h) option to display usage information. If the help (-h) option is the only parameter specified, SRVCTL displays a general outline of all commands with the most common options used for each command and component combination. This will not be a complete list of all supported options. For more detailed and complete information, the help (-h) option can be used for a specific command, or for a specific command and component combination.
For help on a particular command:
11.2
Starting Components by Using the SRVCTL Utility

Oracle recommends that the SRVCTL utility be used to start all components. Examples of starting individual components:
$ $ $ $ $ $ $ srvctl srvctl srvctl srvctl srvctl srvctl srvctl start start start start start start start database d PROD o mount listener l crmlistener service d PROD s "service1,service2" diskgroup g "DATA,FRA" asm eons -v ons
Example of starting all Oracle Restart components in a specified Oracle home:

$ srvctl start home o oracle_home s state_file
Starting Components by Using the SRVCTL Utility The SRVCTL utility can be used to start individual components, along with any dependent components that are necessary. For example, the srvctl start database d PROD command may also start the listener, the ASM instance, and multiple disk groups if those components have been defined as being managed by Oracle Restart and are listed as dependent components to the PROD database. The SRVCTL utility can also be used to start all components that are associated with a specified Oracle home and have been configured for Oracle Restart with the following command:
srvctl start home o /u01/app/oracle/product/11.2.0/dbhome_1 s /usr/local/bin/group_state_file
The state file contains the current state information for the components in the Oracle home and is created when the srvctl status home command is executed. It is indicated with the state file option (-s), and must specify the complete path of the state file. The state file can be created in any directory. Note: The options shown in the slide represent the most common options and are not a complete list. You can use the help option (-h) for a complete list of all available options for each command.
11.2
Stopping Components by Using the SRVCTL Utility

Oracle recommends that the SRVCTL utility be used to stop all components. Examples of stopping individual components:
$ $ $ $ $ $ $ srvctl srvctl srvctl srvctl srvctl srvctl srvctl stop stop stop stop stop stop stop database d PROD o transactional listener l crmlistener -f service d PROD s "service1,service2" diskgroup g "DATA,FRA" -f asm o immediate -f eons -v ons
Example of stopping all Oracle Restart components in a specified Oracle home:

$ srvctl stop home o oracle_home s state_file -f
Stopping Components by Using the SRVCTL Utility The SRVCTL utility can be used to stop individual components, along with any dependent components that must be stopped. For example, the srvctl stop diskgroup g "DATA -f" command will force an unmount of the diskgroup even if files are open in it. It will also stop all database instances that depend on the DATA disk group. The SRVCTL utility can also be used to stop all components that are associated with a specified Oracle home and have been configured for Oracle Restart with the following command:
srvctl stop home o /u01/app/oracle/product/11.2.0/dbhome_1 s /usr/local/bin/group_state_file -f
This can be very useful when it is necessary to stop all components such as when you need to apply a patch to the software binaries. Note: The options shown in the slide represent the most common options and are not a complete list. You can use the help option (-h) for a complete list of all available options for each command.
11.2
Viewing Component Status

You can use the status command to view the running status for any component managed by Oracle Restart. Display the running status for a database:
$ srvctl status database -d orcl Database is running.
Display the listener status:

$ srvctl status lsnr Listener LISTENER is enabled Listener LISTENER is running on node(s): host01
Viewing Component Status You can use the SRVCTL utility to view the running status (running or not running) for any component managed by Oracle Restart. Additional information is displayed for some components. The format of the command is as follows:
srvctl status object [options]
object can be one of the following: asm: ASM instance db: Database instance dg: Oracle ASM disk group filesystem: Oracle ASM file system home: Oracle home or Oracle Clusterware home lsnr: Oracle Net listener ons, eons: Oracle Notification Services serv: Database service Refer to the Oracle Database Administrators Guide for a list of options for each of the above objects.
11.2
Displaying the Oracle Restart Configuration for a Component

You can use the config command to display the Oracle Restart configuration of a component. Display the Oracle Restart configuration for a database:
$ srvctl config database d orcl Database unique name: orcl Database name: orcl Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1 Oracle user: oracle Spfile: +DATA/orcl/spfileorcl.ora Domain: example.com Start options: open Stop options: immediate Database role: Management policy: automatic Disk Groups: DATA,FRA Services: east,sales
Displaying the Oracle Restart Configuration for a Component You can use the SRVCTL utility to display the Oracle Restart configuration of a component with the config command. The config command is valid for the database, service, asm, listener, ons, and eons components. The configuration for an Oracle Restart component can be modified with the SRVCTL utility modify command. The following syntax shows an example of how to modify the database with the unique name of orcl to use a different, nonstandard directory for the server parameter file (SPFILE).
srvctl modify database d orcl p /usr/local/oracle/spfileorcl.ora
11.2
Manually Adding Components to the Oracle Restart Configuration

Components can be manually added to the Oracle Restart configuration with the add command. Define a new listener that was not created with NETCA:
$ srvctl add listener l MYLISTENER p TCP:1525 o /u01/app/oracle/product/11.2.0/grid
$ srvctl setenv listener l MYLISTENER t TNS_ADMIN=/usr/local/oracle
Add a database:
$ srvctl add database -d orcl -o /u01/app/oracle/acfsmounts/acfs_db11
Manually Adding Components to the Oracle Restart Configuration The SRVCTL utility can be used to manually add components to the Oracle Restart configuration with the add command. If the component was created with an Oracle utility such as NETCA, DBCA, ASMCA, or OUI, it would have been automatically added to the Oracle Restart configuration and it would not be necessary to manually add it. The slide illustrates manually adding a new listener called MYLISTENER to the Oracle Restart configuration. The listener will use the software binaries of the Grid home installation, but will depend on a nonstandard location for the networking files. For this example, it is assumed that the listener.ora networking file has been created in the /usr/local/oracle directory. The setenv command of the srvctl utility is used to define environment variables that may be needed for specific components. The TNS_ADMIN environment variable is set to the nondefault location of the listener.ora file, and is defined only for the listener named MYLISTENER. This will not have an impact on any other listeners that may already exist and that use different directories for the networking files. The SRVCTL utility includes a remove command to manually delete a component from the Oracle Restart configuration. To delete the listener created above, use the following syntax:
srvctl remove listener l mylistener f
This will also remove the environment variable that was associated with the listener. You can also use Oracle Enterprise Manager Database Control to add database instances and listeners to the Oracle Restart configuration.
Specify a nondefault location for the new listener's networking files:
Quiz
You invoke the SRVCTL utility from the Oracle Grid Infrastructure home when working with: 1. Listeners 2. ASM instances 3. Database instances 4. ASM disk groups
11.2
Summary
In this lesson, you should have learned how to use Oracle Restart to manage components.
11.2
In this practice, you use Oracle Restart to manage components.
ASM Enhancements
Objectives
Note In this lesson, the term ASM data extent is shortened to extent.
After completing this lesson, you should be able to: Set up Automatic Storage Management (ASM) fast mirror resync Use ASM preferred mirror read Describe the scalability and performance enhancements Use the ASMCMD extensions Manage ASM access control lists (ACLs) Use ASM intelligent data placement
Without ASM Fast Mirror Resync

1
ASM redundancy used
Disk access failure
Disk added back: Extents rebalanced
Disk automatically dropped: All dropped extents re-created
Without ASM Fast Mirror Resync ASM offlines a disk whenever it is unable to complete a write to an extent allocated to the disk, while writing at least one mirror copy of the same extent on another disk if the corresponding disk group uses ASM redundancy. With Oracle Database 10g, ASM assumes that an offline disk contains only stale data; therefore, it no longer reads from such disks. Shortly after a disk is put offline, ASM drops it from the disk group by re-creating the extents allocated to the disk on the remaining disks in the disk group using redundant extent copies. This process is a relatively costly operation and can take hours to complete. If the disk failure is only a transient failure (such as failure of cables, host bus adapters, controllers, or disk power supply interruptions), you have to add the disk again after the transient failure is fixed. However, adding the dropped disk back to the disk group incurs the additional cost of migrating the extents back to the disk.
Oracle Database 10g and 11g
Secondary extent
Primary extent
ASM Fast Mirror Resync: Overview

1
ASM redundancy used
Disk access failure
Secondary extent
Primary extent
Oracle Database 11g
Disk again accessible; need only to resync modified extents

4
Failure time < DISK_REPAIR_TIME
ASM Fast Mirror Resync: Overview ASM fast mirror resync significantly reduces the time required to resynchronize a transient failure of a disk. When a disk goes offline following a transient failure, ASM tracks the extents that are modified during the outage. When the transient failure is repaired, ASM can quickly resynchronize only the ASM disk extents that have been affected during the outage. This feature assumes that the content of the affected ASM disks has not been damaged or modified. When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set the DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute determines the duration of disk outage that ASM will tolerate while still being able to resynchronize after you complete the repair. Note: The tracking mechanism uses one bit for each modified extent. This ensures that the tracking mechanism is very efficient.
Using Enterprise Manager to Perform Fast Mirror Resync
Using Enterprise Manager to Perform Fast Mirror Resync When you take an ASM disk offline in Oracle Enterprise Manager, you are asked to confirm the operation. On the Confirmation page, you can override the default disk repair time. Similarly, you can view by failure group and choose a particular failure group to take offline.
Using Enterprise Manager to Perform Fast Mirror Resync
Using Enterprise Manager to Perform Fast Mirror Resync (continued) You can also bring disks online by using Enterprise Manager.
Setting Up ASM Fast Mirror Resync
Enable fast mirror resync:

ALTER DISKGROUP dgroupA SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';
Manually take the ASM disks offline:
Bring the disk group back online:

ALTER DISKGROUP dgroupA ONLINE DISKS IN FAILGROUP contrler2 POWER 2 WAIT;
Drop the failure group if it cannot be repaired:

ALTER DISKGROUP dgroupA DROP DISKS IN FAILGROUP contrl2 FORCE;
Setting Up ASM Fast Mirror Resync You set up this feature on a per disk group basis. You can do so after disk-group creation using the ALTER DISKGROUP command. Use a command similar to the following to enable ASM fast mirror resync: ALTER DISKGROUP SET ATTRIBUTE 'DISK_REPAIR_TIME'='2D4H30M' After you repair the disk, execute the ALTER DISKGROUP ONLINE DISK SQL statement. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy all extents that are marked as stale on their redundant copies. You cannot apply the ONLINE statement to already-dropped disks. You can view the current attribute values by querying the V$ASM_ATTRIBUTE view. You can determine the time left before ASM drops an offlined disk by querying the REPAIR_TIMER column of either V$ASM_DISK or V$ASM_DISK_IOSTAT. In addition, a row corresponding to a disk resync operation appears in V$ASM_OPERATION with the OPERATION column set to SYNC.
ALTER DISKGROUP dgroupA OFFLINE DISKS IN FAILGROUP contrl2 DROP AFTER 5H;
Setting Up ASM Fast Mirror Resync (continued) You can also use the ALTER DISKGROUP OFFLINE DISK SQL statement to manually bring the ASM disks offline for preventive maintenance. With this command, you can specify a timer to override the timer that is defined at the disk-group level. After you complete maintenance, use the ALTER DISKGROUP ONLINE DISK statement to bring the disk online. If you cannot repair a failure group that is in the offline state, you can use the ALTER DISKGROUP DROP DISKS IN FAILGROUP command with the FORCE option. This ensures that data originally stored on these disks is reconstructed from redundant copies of the data and stored on other disks in the same disk group. Note: The time elapses only when the disk group is mounted. Furthermore, changing the value of DISK_REPAIR_TIME does not affect disks previously offlined. The default setting of 3.6 hours for DISK_REPAIR_TIME should be adequate for most environments.
ASM Preferred Mirror Read: Overview

Site A Site B
Site A
Site B
P: Primary AU S: Secondary AU
ASM Preferred Mirror Read: Overview When you configure ASM failure groups in Oracle Database 10g, ASM always reads the primary copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent that is closest to the node, even if it is a secondary extent. This is especially true in extended cluster configurations (when nodes are spread across several sites) where reading from a local copy of an extent provides improved performance. With Oracle Database 11g, you can do this by configuring the preferred mirror read using the new initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS, to specify a list of preferred mirror read names. The disks in those failure groups become the preferred read disks. Thus, every node can read from its local disks. This results in higher efficiency and performance, and reduced network traffic. The setting for this parameter is instance specific.
ASM Preferred Mirror Read: Setup

Setup ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEA ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEB
On first instance
On second instance
Monitor SELECT preferred_read FROM v$asm_disk; SELECT * FROM v$asm_disk_iostat;
ASM Preferred Mirror Read: Setup To configure this feature, set the new ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter. This parameter is a multivalued parameter and should contain a string with a list of failure group names separated by commas. Each failure group name specified should be prefixed with its disk group name and a . character. This parameter is dynamic and can be modified using the ALTER SYSTEM command at any time. An example is shown in the slide. However, this initialization parameter is valid only for ASM instances. With the extended cluster, the failure groups specified in this parameter should contain only those disks that are local to the corresponding instance. The new PREFERRED_READ column has been added to the V$ASM_DISK view. Its format is a single character. If the disk group to which the disk belongs pertains to a preferred read failure group, the value of this column is Y. To identify specific performance issues with the ASM preferred read failure groups, use the V$ASM_DISK_IOSTAT view. This view displays the disk input/output (I/O) statistics for each ASM client. If this view is queried from a database instance, only the rows for this instance are shown.
Enterprise Manager ASM Configuration Page
Enterprise Manager ASM Configuration Page You can specify a set of disks as preferred disks for each ASM instance by using Enterprise Manager. The preferred read attributes are instance specific. In Oracle Database 11g, the Preferred Read Failure Groups field (ASM_PREFERRED_READ_FAILURE_GROUP) is added to the configuration page. This parameter takes effect only before the disk group is mounted or when the disk group is created. It applies only to newly opened files or to a newly loaded extent map for a file.
ASM Preferred Mirror Read: Best Practice

Two sites: Normal redundancy Two sites: High redundancy
S S
S P
Only two failure groups: One for each instance
Max four failure groups: Two for each instance
Three sites: High redundancy
Only three failure groups: One for each instance
ASM Preferred Mirror Read: Best Practice In practice, there are only a limited number of good disk group configurations in an extended cluster. A good configuration takes into account both performance and availability of a disk group in an extended cluster. Here are some possible examples: For a two-site extended cluster, a normal redundancy disk group should have only two failure groups; all disks local to one site should belong to the same failure group. Also, no more than one failure group should be specified as a preferred read failure group by each instance. If there are more than two failure groups, ASM may not mirror a virtual extent across both sites. Furthermore, if the site with more than two failure groups were to go down, it would take the disk group down as well. If the disk group to be created is a high-redundancy disk group, at most two failure groups should be created on each site with its local disks, with both local failure groups specified as preferred read failure groups for the local instance. For a three-site extended cluster, a high redundancy disk group with three failure groups should be used. In this way, ASM can guarantee that each virtual extent has a mirror copy local to each site and that the disk group is protected against a catastrophic disaster on any of the three sites.
Quiz
You can set up the ASM fast mirror resync feature on a per disk group basis. 1. True 2. False
Answer: 1
ASM Scalability and Performance Enhancements
11.2 update
Extent size grows automatically according to file size. ASM supports variable extent sizes to:
Raise the maximum possible file size Reduce memory utilization in the shared pool
There are no administration needs.
ASM Scalability and Performance Enhancements ASM variable size extents is an automated feature that enables ASM to support larger file sizes while improving memory usage efficiency. In Oracle Database 11g Release 2, ASM supports variable sizes for extents of 1, 4, and 16 allocation units (AU). ASM uses a predetermined number of extents of each size. As soon as a file crosses a certain threshold, the next extent size is used. The extent size of a file varies as follows: Extent size is always equal to the disk group AU size for the first 20000 extent sets (0 19999). Extent size is equal to 4*AU size for the next 20000 extent sets (20000 - 39999). Extent size is equal to 16*AU size for the next 20000 and higher extent sets (40000+). With this feature, 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 that are several hundred TB (or even several PB) in size. Note: The management of variable size extents is completely automated and does not require manual administration.
ASM Scalability and Performance Enhancements (continued) However, external fragmentation may occur when a large number of noncontiguous small data extents have been allocated and freed, and no additional contiguous large extents are available. A defragmentation operation is integrated as part of any rebalance operation. As a result, as a DBA, you always have the ability to defragment your disk group by executing a rebalance operation. Nevertheless, this should happen only very rarely because ASM also automatically performs defragmentation during extents allocation if the desired size is unavailable. This can potentially make some allocation operations longer. Note: This feature also enables much faster file opens because of the significant reduction in the amount of memory that is required to store file extents.
ASM Scalability in Oracle Database 11g
External redundancy: 140 PB Normal redundancy: 23 PB High redundancy: 15 PB
ASM Scalability in Oracle Database 11g ASM imposes the following limits: 63 disk groups in a storage system 10,000 ASM disks in a storage system 4 petabytes maximum storage for each ASM disk if using Oracle Exadata storage. 40 exabytes maximum storage for each storage system if using Oracle Exadata storage. 1 million files for each disk group Maximum file size depends on the redundancy type of the disk groups used as well as the AU size. When AU size is 1 MB, the maximum file size is: 140 PB for external redundancy (value currently greater than possible database file size), 23 PB for normal redundancy, and 15 PB for high redundancy. Note: In Oracle Database 10g, the maximum ASM file size for external redundancy is 16 TB.
ASM imposes the following limits: 63 disk groups 10,000 ASM disks 4 petabytes per ASM disk (2 TB if not on Oracle Exadata) 40 exabytes of storage (20 PB if not on Oracle Exadata) 1 million files per disk group Maximum file size:
SYSASM Privilege
11.2 update
Avoids overlap between DBAs and storage administrators by using the SYSASM role to manage ASM instances.
SQL> CONNECT / AS SYSASM SQL> CREATE USER username IDENTIFIED by passwd; SQL> GRANT SYSASM TO username; SQL> CONNECT username/passwd AS SYSASM; SQL> DROP USER username;
SYSDBA privileges are restricted in ASM instances.
SYSASM Privilege Oracle Database 11g includes the SYSASM privilege that is specifically intended for performing ASM administration tasks. Using the SYSASM privilege instead of the SYSDBA privilege improves security by separating ASM administration from database administration. The OSASM group, a new OS-privileged group, is used exclusively for ASM. Members of this group can connect as SYSASM using OS authentication and have full access to ASM. You also have the ability to use the combination of CREATE USER and GRANT SYSASM SQL statements from an ASM instance to create a new SYSASM user. This can be useful for remote or local ASM administration. These commands update the password file of each ASM instance. Similarly, you can revoke the SYSASM role from a user by using the REVOKE command, and you can drop a user from the password file by using the DROP USER command. The V$PWFILE_USERS view includes a new column called SYSASM, which indicates whether the user can connect with SYSASM privileges (TRUE) or not (FALSE).
Using Enterprise Manager to Manage ASM Users
Using Enterprise Manager to Manage ASM Users Oracle Enterprise Manager 11g enables you to manage the users who access the ASM instance through a remote connection (using password file authentication). These users are used exclusively for the ASM instance. However, you have this functionality only when connected as the SYSASM user. It is hidden if you connect as the SYSDBA or SYSOPER user. 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: In Oracle Database 11g the SYSASM role is added to the ASM instance login page.
ASM Disk Group Compatibility

The compatibility of each disk group is separately controllable:
ASM compatibility controls ASM metadata on-disk structure. RDBMS compatibility controls the minimum consumer client level. ADVM compatibility determines if Oracle ASM Dynamic Volume Manager can be used.
11.2 update
Setting disk group compatibility is irreversible.

DB instance ASM disk group ASM instance
COMPATIBLE >= COMPATIBLE.RDBMS <= COMPATIBLE.ASM <= COMPATIBLE >= COMPATIBLE.ADVM

ASM Disk Group Compatibility There are three kinds of compatibility applicable to ASM disk groups, dealing with the persistent data structures that describe a disk group, the capabilities of the clients (consumers of disk groups), and the ability to contain volumes in a disk group. These attributes are called ASM compatibility, RDBMS compatibility, and ADVM compatibility, respectively. The compatibility of each disk group is independently controllable. This is required to enable heterogeneous environments with disk groups from both Oracle Database 10g and Oracle Database 11g. The three compatibility settings are attributes of each ASM disk group: RDBMS compatibility refers to the minimum compatible version of the RDBMS instance that would allow the instance to mount the disk group. This compatibility determines the format of messages that are exchanged between the ASM and database (RDBMS) instances. An ASM instance is capable of supporting different RDBMS clients running at different compatibility settings. The database-compatible version setting of each instance must be greater than or equal to the RDBMS compatibility of all disk groups used by that database. Database instances are typically run from a different Oracle home than the ASM instance. This implies that the database instance may be running a different software version than the ASM instance. When a database instance first connects to an ASM instance, it negotiates the highest version that they both can support.
ASM Disk Group Compatibility (continued) The compatibility parameter setting of the database, the software version of the database and the RDBMS compatibility setting of a disk group determine whether a database instance can mount a given disk group. ASM compatibility refers to the persistent compatibility setting controlling the format of data structures for ASM metadata on disk. The ASM compatibility level of a disk group must always be greater than or equal to the RDBMS compatibility level of the same disk group. ASM compatibility is concerned only with the format of the ASM metadata. The format of the file contents is determined by the database instance. For example, the ASM compatibility of a disk group can be set to 11.0 while its RDBMS compatibility could be 10.1. This implies that the disk group can be managed only by ASM software whose software version is 11.0 or higher, while any database client whose software version is higher than or equal to 10.1 can use that disk group. ADVM compatibility determines whether the disk group can contain Oracle ASM volumes. The value must be set to 11.2 or higher. Before setting this attribute, the COMPATIBLE.ASM value must be 11.2 or higher. Also, the Oracle ADVM volume drivers must be loaded. By default, the value of the COMPATIBLE.ADVM attribute is empty until set. The compatibility of a disk group needs to be advanced only when there is a change to either persistent disk structures or protocol messaging. However, advancing disk group compatibility is an irreversible operation. If you advance the disk group compatibility settings, you cannot change the values back to the previous settings. To revert to the previous values, you must create a new disk group with the old compatibility attribute settings and then restore the database files that were in the disk group to the new disk group. You can set the disk group compatibility by using either the CREATE DISKGROUP command or the ALTER DISKGROUP command. Note: In addition to disk group compatibilities, the COMPATIBLE parameter (database compatible version) determines the features that are enabled. It applies to the database or ASM instance depending on the INSTANCE_TYPE parameter. For example, setting it to 10.1 would preclude use of any new features that are introduced in Oracle Database 11g (disk online/offline, variable extents, and so on).
ASM Disk Group Attributes

Name
au_size compatible.rdbms compatible.asm compatible.advm access_control. enabled access_control. umask sector_size disk_repair_time template.tname. redundancy template.tname. stripe
11.2 update
Property C AC AC AC A A C AC A A
Values 1|2|4|8|16|32|64MB
Valid database version Valid ASM instance version Valid database version TRUE | FALSE {0|2|6}{0|2|6}{0|2|6} 512 | 4096 | 4K 0 M to 232 D UNPROTECT|MIRROR|HIGH
Description
Size of allocation units in the disk group Format of messages exchanged between DB and ASM Format of ASM metadata structures on disk Determines whether the disk group can contain Oracle ASM volumes Determines whether Oracle ASM File Access Control is enabled for a disk group Set the default permission modes for newly created files Make sure sector size of the disks in the disk group are at the specified value Length of time before removing a disk once OFFLINE Redundancy of specified template Striping attribute of specified template
COARSE|FINE
A: ALTER C: CREATE
ASM Disk Group Attributes When you create or alter an ASM disk group, you can change its attributes by using the new ATTRIBUTE clause of the CREATE DISKGROUP or ALTER DISKGROUP commands. These attributes are briefly summarized in the table in the slide: ASM enables the use of different AU sizes that you specify when you create a disk group. The AU size can be 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, or 64 MB. RDBMS compatibility: See the section titled ASM Disk Group Compatibility for more information. ASM compatibility: See the section titled ASM Disk Group Compatibility for more information. You can specify the DISK_REPAIR_TIME in units of minutes (M), hours (H), or days (D). If you omit the unit, the default is H. If you omit this attribute, the default is 3.6H. You can override this attribute with an ALTER DISKGROUP statement. You can specify the redundancy attribute of the specified template. You can specify the striping attribute of the specified template. For a complete reference all attributes, look at the Oracle Database SQL Language Reference. Note: For each defined disk group, you can look at all the defined attributes by using the V$ASM_ATTRIBUTE fixed view.
Using Enterprise Manager to Edit Disk Group Attributes
Using Enterprise Manager to Edit Disk Group Attributes Enterprise Manager provides a simple way to store and retrieve environment settings related to disk groups. You can now set the compatible attributes from both the Create Disk Group page and the Edit Advanced Attributes for Disk Group page. The DISK_REPAIR_TIME attribute is added to only the Edit Advanced Attributes for Disk Group page. Note: For 11g ASM instances, the default ASM compatibility is 11.2.0.0.0 and the default RDBMS compatibility is 10.1.0.0.0.
Enhanced Disk Group Checks
Disk group check syntax is simplified.

CHECK option replaces FILE, DISK and ALL.
Additional checks performed:

Alias Directories
ALTER DISKGROUP DATA CHECK;
Enhanced Disk Group Checks The CHECK disk group command is simplified to check all the metadata directories by default. The CHECK command lets you verify the internal consistency of the ASM disk group metadata. ASM displays summary errors and writes the details of the detected errors in the alert log. In earlier releases, you could specify this clause for ALL, DISK, DISKS IN FAILGROUP, and FILE. Those clauses have been deprecated because they are no longer needed. In the current release, the CHECK keyword performs the following operations: Checks the consistency of the disk (equivalent to CHECK DISK and CHECK DISK IN FAILGROUP in previous releases) Cross-checks all the file extent maps and allocation tables for consistency (equivalent to CHECK FILE in previous releases) Checks that the alias metadata directory and the file directory are linked correctly Checks that the alias directory tree is linked correctly Checks that ASM metadata directories do not have unreachable allocated blocks The REPAIR | NOREPAIR clause enables you to tell ASM whether or not to attempt to repair the errors found during the consistency check. The default is REPAIR. The NOREPAIR setting is useful when you want to be alerted to any inconsistencies, but do not want ASM to take any automatic action to resolve them.
Restricted Mount Disk Group for Fast Rebalance
A disk group can be mounted on a single instance only. No database client or other ASM instance can obtain access. Rebalance can proceed without locking overhead.
2 3 4 5
ALTER DISKGROUP data MOUNT RESTRICT;
Maintenance task: Add/Remove disks

ALTER DISKGROUP data DISMOUNT; ALTER DISKGROUP data MOUNT;
Restricted Mount Disk Group for Fast Rebalance A new mount mode to mount a disk group in Oracle Database 11g is called RESTRICTED. When a disk group is mounted in RESTRICTED mode, clients cannot access the files in a disk group. When an ASM instance knows that there are no clients, the instance improves the performance of the rebalance operation by not attempting to message clients for locking/unlocking extent maps. A disk group mounted in RESTRICTED mode is mounted exclusively on only one node; clients of ASM on that node cannot use that disk group. The RESTRICTED mode allows you to perform all maintenance tasks on a disk group in the ASM instance without external interaction. At the end of the maintenance cycle, you must explicitly dismount the disk group and remount it in normal mode. The ALTER DISKROUP diskgroupname MOUNT command is extended to enable ASM to mount the disk group in RESTRICTED mode. An example is shown in the slide. When you use the RESTRICTED option to start up an ASM instance, all disk groups defined in the ASM_DISKGROUPS parameter are mounted in RESTRICTED mode.
ALTER DISKGROUP data DISMOUNT;
Mount Force Disk Group
By default, MOUNT is NOFORCE:

All disks must be available.
MOUNT with FORCE:

Offlines unavailable disks if quorum exists Fails if all disks are available
ALTER DISKGROUP data MOUNT [FORCE|NOFORCE];
Mount Force Disk Group This feature alters the behavior of ASM when mounting an incomplete disk group. With Oracle Database 10g, as long as there are enough failure groups to mount a disk group, the mount operation succeeds, even when there are missing or damaged failure groups. This behavior has the potential to automatically drop ASM disks, requiring their addition again later after repair, and thus incurring a long rebalance operation. With Oracle Database 11g, such an operation fails unless you specify the new FORCE option when mounting the damaged disk group. You can correct configuration errors (such as setting ASM_DISKSTRING incorrectly) or connectivity issues before trying the mount again. However, disk groups mounted with the FORCE option could potentially have one or more disks offline if they were not available at the time of the mount. You must take corrective action before DISK_REPAIR_TIME expires to restore those devices. Failing to bring those devices online results in the disks being expelled from the disk group and costly rebalancing being required to restore redundancy for all the files in the disk group. Also, if one or more devices are offlined as a result of MOUNT FORCE, some or all files will not be properly protected until the redundancy is restored in the disk group via rebalance. Therefore, MOUNT with FORCE is useful when you know that some of the disks belonging to a disk group are unavailable. The disk group mount succeeds if ASM finds enough disks to form a quorum.
Mount Force Disk Group (continued) MOUNT with NOFORCE is the default option of MOUNT when none is specified. In NOFORCE mode, all disks that belong to a disk group must be accessible for the mount to succeed. Note: Specifying the FORCE option when it is not necessary also results in an error. There is also one special case in a cluster: If an ASM instance is not the first to mount the disk group, MOUNT FORCE fails with an error if disks are determined to be inaccessible locally but accessible by another instance.
Forcing Disk Group Drop
Allows users to drop disk groups that cannot be mounted Fails if disk group is mounted anywhere
DROP DISKGROUP data FORCE INCLUDING CONTENTS;
Forcing Disk Group Drop DROP DISKGROUP FORCE marks the headers of disks belonging to a disk group that cannot be mounted by the ASM instance as FORMER. However, the ASM instance first determines whether the disk group is being used by any other ASM instance using the same storage subsystem. If it is being used, and if the disk group is in the same cluster or on the same node, the statement fails. If the disk group is in a different cluster, the system checks further to determine whether the disk group is mounted by an instance in the other cluster. If the disk group is mounted elsewhere, the statement fails. However, this latter check is not as definitive as the checks for disk groups in the same cluster. You should therefore use this clause with caution. Note: When executing the DROP DISKGROUP command with the FORCE option, you must also specify the INCLUDING CONTENTS clause.
ASMCMD Extensions in Oracle Database 11g Release 1

User-created directories Templates Disk group compatibility Disk group name Disk names and failure groups
md_backup
full
newdg
lsdsk
ASMCMD Extensions in Oracle Database 11g Release 1 ASMCMD is extended to include ASM metadata backup and to restore functionality. This provides the ability to re-create a preexisting ASM disk group with the exact template and alias directory structure. Currently, if an ASM disk group is lost, it is possible to restore the lost files by using RMANbut you must manually re-create the ASM disk group and any required user directories or templates. ASM metadata backup and restore (AMBR) works in two modes: In backup mode, AMBR parses ASM fixed tables and views to gather information about existing disks and failure group configurations, templates, and alias directory structures. It then dumps this metadata information to a text file. In restore mode, AMBR reads the previously generated file to reconstruct the disk group and its metadata. You have the ability to control AMBR behavior in restore mode to do a full, nodg, or newdg restore. The difference among the three submodes is in whether you want to include the disk group creation and change its characteristics. The lsdsk command lists ASM disk information. This command can run in two modes: In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk information. In nonconnected 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.
cp
$ asmcmd help
md_restore
nodg
ASMCMD Extensions in Oracle Database 11g Release 1 (continued) The cp command enables you to copy files between ASM disk groups on local instances and remote instances. Here is a possible usage example:
cp +DATA/ORCL/DATAFILE/TBSJFV.256.629730771 +DATA/ORCL/tbsjfv.bak
In the above example, you copy an existing file locally. However you could specify a connect string to copy the file to a remote ASM disk group. The format of copied files is portable between Little-Endian and Big-Endian systems. You can also use the cp command to copy an ASM file to your operating system. For example:
cp +DATA/ORCL/DATAFILE/TBSJFV.256.629730771 /home/oracle/tbsjfv.dbf
Similarly, you can use the cp command to copy a file from your operating system to an ASM directory. For example:
cp /home/oracle/tbsjfv.dbf +data/jfv
cp +DATA/orcl/datafile/tbsjfv.256.629989893 \sys@edcdr12p1.+ASM2:+D2/jfv/tbsjfv.dbf
Note: For more information about the syntax for each of these commands, see the Oracle Database Storage Administrators Guide.
If you want to copy an ASM file from your local ASM instance to a remote ASM instance, you could use the following syntax:
11.2
ASMCMD Command Extensions
ASMCMD Command Extensions In Oracle Database 11g Release 1, ASMCMD had 18 basic commands. In Oracle Database 11g Release 2, there are 63 UNIX-like commands that enable a storage administrator to manage ASM instances, files, disk groups, file access, templates, and volumes. The ASMCMD commands are basically wrappers around the SQL commands that perform ASM operations. The intention is that every ASM operation that can be performed with a SQL command can also be performed with an ASMCMD command. The ASMCMD commands have a UNIX like syntax that should be familiar to system administrators and storage administrators. These command extensions will prevent the administrators from having to learn SQL to manage the ASM instance and storage. A sampling of the command functionality in each group is shown in the slide. For details about the commands, see Oracle Database Storage Administrators Guide 11g Release 2.
ASMCMD command extensions include commands to manage: The ASM instance (startup, shutdown, disk statistics) ASM file access controls (create and manage user and group access) Disks and disk groups (create, mount, dismount, backup, restore, rebalance, set attributes) ASM files (create and delete aliases, change directories, list files) ASM file templates (create, change, list, remove) ASM volumes (create, remove, resize, report statistics)
ASMCMD Extensions: Example

1
ASMCMD> md_backup b jfv_backup_file -g data Disk group to be backed up: DATA# Current alias directory path: jfv ASMCMD>
Unintentional disk group drop

ASMCMD> md_restore -b jfv_backup_file -t full -g data Disk group to be restored: DATA# ASMCMDAMBR-09358, Option -t newdg specified without any override options. Current Diskgroup being restored: DATA Diskgroup DATA created! User Alias directory +DATA/jfv created! ASMCMD>
Restore disk group files by using RMAN.
ASMCMD Extensions: Example This example describes how to back up ASM metadata by using the md_backup command, and how to restore the data by using the md_restore command. The first statement specifies the b option and the g option of the command. This defines the name of the generated file containing the backup information as well as the disk group that needs to be backed up (jfv_backup_file and data, respectively, in the slide). In step 2, it is assumed that there is a problem in the DATA disk group. As a result, it gets dropped. Before you can restore the database files that the disk group contained, you have to restore the disk group itself. In step 3, you initiate the disk group re-creation as well as restoration of its metadata by using the md_restore command. Here you specify the name of the backup file generated in step 1 as well as the name of the disk group that you want to restore, plus the type of restore that you want. In this example, a full restore of the disk group is done because it no longer exists. After the disk group is re-created, you can restore its database files by using (for example) RMAN.
Quiz
When you execute the CHECK disk group command you can specify whether or not you want ASM to attempt to repair the errors found during the consistency check. 1. True 2. False
Answer: 1
11.2
ASM ACLs
Set permissions at the ASM file level. Permissions are none (0), read (4), or read-write (6). Permissions are available only on Linux and UNIX operating systems.
ASM ACLs ASM ACLs provide optional protection for ASM files. The objective of the ASM access control list is not security, but separation of duties to prevent accidental file damage. Without ACLs, any user with the SYSDBA privilege may access ASM files in the mounted disk group, including removing them. To set up Oracle ASM File Access Control, you must create separate operating system groups for the OSASM, OSDBA for ASM, and OSDBA for database groups. The OSDBA group for the database must be different for each database instance using the same ASM instance. Each ASM file is created by a DBUSER. This DBUSER is usually an owner of a database instance. The ASM files created for that database are owned by that DBUSER. The OS user ID of the database software owner identifies the DBUSER to the ASM instance. Access is limited by the OS effective user ID NUMBER of the DBUSER. The operating system user of a running database instance is automatically added to a disk group when the database instance accesses that disk group and creates files. Each DBUSER can create access control lists. The ASM ACL includes a user group, a list of DBUSERS, but not any passwords. ASM trusts the OS authentication mechanisms. A DBUSER is a member of the OSDBA group for ASM.
11.2
ASM ACLs Prerequisites
Access control lists for ASM files require: Linux or UNIX operating system Job role separation at the OS level Disk group attributes must be set:
ASM ACLs Prerequisites There are certain requirements to use access control lists effectively. Access control lists for ASM are only available on Linux and UNIX operating systems. You must have configured job role separation. Each database and the ASM instance must have different owners. Disk group attributes must be set. COMPATIBLE.ASM and COMPATIBLE.RDBMS must be set to 11.2 or higher. For each disk group that is using ACLs, set ACCESS_CONTROL.ENABLED to TRUE and set ACCESS_CONTROL.UMASK to a mask value. ACCESS_CONTROL.ENABLED must be set to TRUE before ACCESS_CONTROL.UMASK can be set. The umask value removes the permissions from full access of read-write for owner, group, and others. In the permissions, 6 indicates read-write, 4 indicates read, and 0 indicates none. A umask value of 0 removes nothing, 2 removes write privilege, and 6 removes read-write privilege. Concatenating the values gives the permissions for a user, group or others. For example, a umask of 026 will cause files to have permissions of 640, which is read-write for the owner, read for the group, and no access for all other users. Use SQL to set the values as follows:
ALTER DISKGROUP DATA2 SET ATTRIBUTE 'access_control.enabled' = 'true'; ALTER DISKGROUP DATA2 SET ATTRIBUTE 'access_control.umask' = '026';
COMPATIBLE.ASM to 11.2 or higher COMPATIBLE.RDBMS to 11.2 or higher ACCESS_CONTROL.ENABLED to TRUE ACCESS_CONTROL.UMASK to a mask value
ASM ACLs Prerequisites (continued) Equivalent ASMCMD commands are as follows:

ASMCMD> setattr -d data2 access_control_enabled true ASMCMD> setattr -d data2 access_control_umask 026
Attributes of the disk group can also be set with the ASMCA tool.
11.2
Managing ASM ACLs by Using SQL Commands

Manage ASM ACL by using SQL commands:
ALTER ALTER ALTER ALTER ALTER ALTER ALTER ALTER DISKGROUP DISKGROUP DISKGROUP DISKGROUP DISKGROUP DISKGROUP DISKGROUP DISKGROUP ADD USERGROUP ... WITH MEMBER DROP USERGROUP MODIFY USERGROUP ADD MEMBER MODIFY USERGROUP DROP MEMBER ADD USER DROP USER SET PERMISSION SET OWNERSHIP
View information about ACLs:

SELECT * FROM V$ASM_USER SELECT * from V$ASM_USERGROUP
Managing ASM ACL by Using SQL Commands Access control lists in ASM can be managed with the SQL commands shown in the slide. To create a user group, ACL uses the command:
ALTER DISKGROUP ADD USERGROUP groupname WITH MEMBER user [, user]
Each user must already exist. Any user with SYSDBA or SYSASM privilege can create groups. Only the group owner or an ASM administrator can change or drop groups. Only an ASM administrator can add or drop users. Only the owner of a file or an ASM administrator can change the ownership of a file. Users of files are usually the database owners, and users are added automatically as files are created in a disk group. Adding users to a disk group should seldom be needed. An OS user that is not a database owner could be added to a disk group, and a user group. The SET PERMISSION clause modifies permissions of an Oracle ASM file. Note that setting read-only permission to a file that has read/write permission revokes the write permission. Only the file owner or the Oracle ASM administrator can change the permissions of a file. You cannot change the permissions in an open file. You cannot change the ownership in an open file.
11.2
Managing ASM ACLs by Using ASMCMD Commands

Manage ASM ACLs by using ASMCMD commands:
chgrp usergroup list_of_files chmod mode list_of_files chown user[:usergroup ] list_of_files groups diskgroup user grpmod { -a | -d } diskgroup usergroup user1 [user2] lsgrp [-Ha] [ -d diskgroup ] [ pattern_expr ] lsusr [-Ha] [ -d diskgroup ] [ pattern_expr ] mkgrp diskgroup usergroup [user1] [user2]... mkusr diskgroup user passwd user rmgrp diskgroup usergroup rmusr diskgroup user
Managing ASM ACLs by Using ASMCMD Commands The ASMCMD commands enable the storage administrator to perform the same operations as the ones shown with SQL commands, but in a more familiar format. The ASMCMD commands are patterned after UNIX commands. The ASMCMD commands have the same restrictions as the SQL commands. Additional notes: chmod: Modifies permissions of an Oracle ASM file or list of files. Note that setting read-only permission to a file that has read/write permission revokes the write permission. Only the file owner or the Oracle ASM administrator can change the permissions of a file. You cannot change the permissions in an open file. chown: You cannot change the ownership in an open file.
11.2
Managing ASM ACLs by Using Enterprise Manager
Managing ASM ACLs by Using Enterprise Manager The ASM access control lists can be viewed and managed through Enterprise Manager. This slide shows the attributes and permissions associated with each file.
11.2
Managing ASM ACLs by Using Enterprise Manager
Managing ASM ACLs by Using Enterprise Manager (continued) On the Edit File page, permissions and ownership of the ASM file can be modified. The ownership and permissions cannot be changed in an open file.
11.2
ASM Intelligent Data Placement

Outer
ASM Disk Group

JBOD disks
Inner tracks
Greater throughput
tracks
Lesser throughput
mark files
DBA
ASM files
HOT COLD COMPATIBLE.ASM>=11.2 COMPATIBLE.RDBMS>=11.2
ASM Disk Group
ASM Disk Group
ASM without IDP
ASM with IDP
ASM Intelligent Data Placement In earlier releases, ASM attempted to optimize ASM files placement only across ASM disks using striping techniques, treating one ASM disk as one uniform object. However, physical disk regions furthest from the disk spindle, also called outer tracks, have greater throughput than inner tracks. So, with ASM Intelligent Data Placement (IDP), not only ASM stripes files across disks, but it also makes sure that manually marked files are placed in corresponding physical disk regions as shown in the graphic in the slide. That is, ASM allocates extents for a file based on that files preferred region: HOT or COLD. Because ASM does not know anything about physical disk characteristics, IDP is targeted at spanning disk architectures and not high-end storage arrays. The two disk regions, HOT and COLD, are artificially identified each time a new disk group is created or a disk is added to an existing disk group. Using these settings, you can ensure that frequently accessed data is placed on the outermost tracks which have higher bandwidth, and the collocation of such data reduces seek latency. This is especially relevant for applications using a small working set in a large amount of data. The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2 or higher to use Intelligent Data Placement. Note: A disk region is a set of contiguous tracks having similar performance characteristics. Outer tracks are longer and, therefore, contain more sectors than inner tracks. Because the rotational speed is constant, the number of sectors that can be read is greater for outer tracks.
11.2
Managing ASM Intelligent Data Placement Examples

SQL> ALTER DISKGROUP datadg ADD TEMPLATE idptemp 2 ATTRIBUTES (HOT MIRRORHOT);
1
SQL> CREATE TABLESPACE hottbs DATAFILE '+datadg(idptemp)';
SQL> ALTER DISKGROUP datadg ALTER FILE '+datadg.342.3' 2 ATTRIBUTES (HOT MIRRORCOLD);
SQL> ALTER DISKGROUP datadg REBALANCE POWER 8;
Managing ASM Intelligent Data Placement Examples The first statement creates a new template called idptemp in datadg disk group. You can see new template attributes that can be specified to enable ASM Intelligent Data Placement. You can specify the following four attributes: HOT | COLD and MIRRORHOT | MIRRORCOLD. The first two can be used to specify the disk region where to locate primary extents, and the last two can be used to specify the disk region where to locate mirrored (secondary) extents. So, in the case of the first example, the idptemp template can be used to create files with primary and secondary extents in the hot region of the disk group disks. In the second example, you create a new tablepsace called hottbs using the previously created idptemp template. This forces the creation of an ASM file entirely located in the hot region of each ASM disk of the datadg disk group. The third example modifies the IDP attributes of an existing file changing them to HOT and MIRRORCOLD. This SQL statement does not initiate any extent movement. However, new extents are allocated according to the new zones. However, the fourth example initiates a manual rebalance that attempts to move extents of the +datadg.342.3 file to the new zones in addition to normal rebalance activity. Note: If no space is available in the desired region, ASM allocates extents in the other region, but initiates a rebalance to adjust the size of the regions.
11.2
Managing ASM Intelligent Data Placement

Manage ASM Intelligent Data Placement by using ASMCA:
Managing ASM Intelligent Data Placement Oracle ASM Configuration Assistant (ASMCA) supports Intelligent Data Placement with template creation during disk group alterations. On the Configure ASM Disk Groups tab, right-click a selected disk group to display the configuration options menu. Select Manage Templates.
11.2
Managing ASM Intelligent Data Placement
Manage ASM Intelligent Data Placement by using Enterprise Manager:
Managing ASM Intelligent Data Placement (continued) You can manage disk group templates with the Templates tab of the Disk Group page. 1. Access the Oracle Automatic Storage Management Home page. 2. Click the Disk Groups link to display the Disk Groups property page. 3. Click a link in the Name column to select a disk group. 4. Click the Templates tab to display the Templates page. 5. Click Create to add a new template or click Edit to change a template. You can specify extent regions (hot or cold).
11.2
ASM Intelligent Data Placement Best Practices
Read Frequency High High Low Low
Write Frequency High Low High Low
Primary region HOT HOT COLD COLD
Secondary region MIRRORHOT MIRRORCOLD MIRRORCOLD MIRRORHOT
ASM Optimal Disk Placement Best Practices ASM currently cannot determine disk region attributes automatically. As a DBA, you need to determine them depending on files activity. A good indicator is whether those files are accessed because of user-initiated actions. For example, both archive logs and backups are write-once type of files, but backups may be scheduled for off-peak periods where latency is less critical. Archive logs are created by other database activity, and placing them in the inner zones may adversely impact database latency. Likewise, if some tablespaces are only updated during off-peak periods, their mirrored extents can be placed in inner zones. The table in the slide shows how file access patterns should determine primary and secondary regions.
11.2
Viewing ASM Intelligent Data Placement Information

Query V$ASM_DISKGROUP and V$ASM_FILE:
SELECT dg.name AS diskgroup, f.file_number, f.primary_region, f.mirror_region, f.hot_reads, f.hot_writes, f.cold_reads, f.cold_writes FROM V$ASM_DISKGROUP dg, V$ASM_FILE f WHERE dg.group_number = f.group_number and dg.name = 'dg_name';
Query V$ASM_DISKGROUP and V$ASM_TEMPLATE:

SELECT dg.name AS diskgroup, t.name, t.stripe, t.redundancy, t.primary_region, t.mirror_region FROM V$ASM_DISKGROUP dg, V$ASM_TEMPLATE t WHERE dg.group_number = t.group_number and dg.name = 'dg_name' ORDER BY t.name;
Viewing ASM Intelligent Data Placement Information It is possible that inappropriate file policy specification can degrade performance. Measuring the frequency of accesses to each file will be an important tool for diagnoses. Columns have been added to ASM fixed tables that will provide this information. The views listed below include columns providing information about Intelligent Data Placement. V$ASM_DISKGROUP: - HOT_USED_MB: Number of used megabytes in the hot region - COLD_USED_MB: Number of used megabytes in the cold region V$ASM_FILE: - PRIMARY_REGION: Region used for allocating primary extents (HOT|COLD) - MIRROR_REGION: Region for allocating mirrored extents (HOT|COLD) V$ASM_TEMPLATE: - PRIMARY_REGION: Region used for allocating primary extents (HOT|COLD) - MIRROR_REGION: Region for allocating mirrored extents (HOT|COLD) V$ASM_DISK_IOSTAT provides I/O statistics for the hot and cold regions.
Viewing ASM Intelligent Data Placement Information (continued) The columns in V$ASM_FILE will help you to select the files that should be moved to another region and verify that the selection is correct. The V$ASM_DISK and V$ASM_DISK_STAT views have the same statistics as V$ASM_FILE, but aggregated at the disk level. To verify that the change of regions is actually changing the performance, record the AVERAGE_READ_TIME, AVERAGE_WRITE_TIME, PHYSICAL_READS, and PHYSICAL_WRITES from V$FILEMETRIC and V$FILEMETRIC_HISTORY before and after the change, or use AWR reports (especially the File I/O statistics in the I/O statistics section).
Quiz
Answer: 1
Which of the following statements are true about Intelligent Data Placement? Enables placement of primary and mirror extents into different hot or cold regions Enables placement of primary extents only into hot regions Enables placement of mirror extents only into cold regions
Summary
In this lesson, you should have learned how to: Set up Automatic Storage Management (ASM) fast mirror resync Use ASM preferred mirror read Describe the scalability and performance enhancements Use the ASMCMD extensions Manage ASM access control lists Use ASM intelligent data placement
Practice 4: Overview
This practice includes using ASM fast mirror resync.
Storage Enhancements
Objectives
After completing this lesson, you should be able to: Use 4 KB sector disks Employ data compression Create a SQL Access Advisor analysis session using Enterprise Manager Create a SQL Access Advisor analysis session using PL/SQL Use deferred segment creation
11.2
Supporting 4 KB Sector Disks
Emulation mode:
LBA0 LBA1 LBA2 LBA3 LBA4 LBA5 LBA6 LBA7 4096-byte physical sector
LBA0 4096-byte physical sector
Physical sector
Supporting 4 KB Sector Disks Disks, a primary storage medium for databases, currently have predominantly a physical sectorsize of 512 bytes. Larger, 4 KB sector disks are beginning to appear on the market offering higher storage capacity with a lower overhead. Oracle Database servers access the hard disk via a platform specific device driver. The database writer, log writer, and ASM processes can write directly to the disk without going through the operating system (OS). Oracle Database 11g Release 2 detects the disk sector size and uses the high-capacity disks without performance degradation. As illustrated in the slide, 4 KB sector disks have physical sectors (shown in gray) and logical sectors (shown in blue). There are two types of 4 KB sector disks: emulation mode and native mode, also shown in the slide. 4 KB sector disks in emulation mode have eight logical sectors per one physical sector as shown in the slide. They maintain a 512-byte interface to their 4 KB physical sectors; that is, the logical block address (LBA) references 512 bytes on disk. You will incur a significant performance degradation in emulation mode when a redo log write is not aligned with the beginning of the 4 KB physical sector. 4 KB sector disks in native mode have one logical sector per physical sector as shown in the slide. So, there is only the 4 KB interface. In other words, the LBA references 4096 bytes on disk.
Native mode:
Logical sector
11.2
Using 4 KB Sector Disks
Data files
Control files
Online redo log files
Archived log files
Database
Using 4 KB Sector Disks In Oracle Database 11g Release 2, 4 KB sector disks mainly affect the redo log files. This includes online redo logs, standby redo logs, and archived redo logs. Oracle recommends that you create 4 KB block size logs on 4 KB emulation mode disks. On 4 KB native mode disks, you must create 4 KB block size logs. In other words, the redo block size must match the physical disk sector size (for 512-byte and for 4 KB native-mode disks). Otherwise, you receive the ORA-1378 error. For 4 KB emulation-mode disks, the redo block size could be 512 or 4096 bytes. 4 KB is the preferred block size. When you are creating 512-byte blocks on a 4 KB emulation disk, a warning is written to the alert log to indicate that the mismatched block size leads to degraded performance. This also applies to ASM disk groups. The 4 KB sector disks also affect the Oracle Database data file. The Oracle Database server allows you to create 2 KB block size data files on 512 byte sector disks. With 4 KB sector disks, Oracle recommends that you create 4 KB (or larger) block size data files on the 4 KB emulation-mode disks. On 4 KB native-mode disks, you must create 4 KB block (or larger) size logs. The control file block size is already 16 KB. Therefore, the 4 KB sector disks do not affect the control file.
Emulation mode: Native mode: Recommended 4 KB block Mandatory 4 KB block size size for redo logs for redo logs Recommended 4 KB block Mandatory 4 KB block size size (or larger) for data files (or larger) for data files Not affected: Control file block size: 16 KB
11.2
Specifying the Disk Sector Size
Specifying the Disk Sector Size In an Automatic Storage Management (ASM) environment, you can set the SECTOR_SIZE attribute for disk groups. This attribute can be set only at disk group creation time by using the CREATE DISKGROUP command. You can specify the size of the log file with the new BLOCKSIZE clause for the following commands: ALTER DATABASE CREATE DATABASE CREATE CONTROL FILE
Specify the sector size for disk drives with the new SECTOR_SIZE and BLOCKSIZE clauses of the following commands: CREATE DISKGROUP ALTER DATABASE CREATE DATABASE CREATE CONTROL FILE
11.2
Using the SECTOR_SIZE Clause
Create a disk group in ASM with a 4 KB sector size:

CREATE DISKGROUP mydgroup1 NORMAL REDUNDANCY FAILGROUP mycontroller1 DISK '/devices/diska1', '/devices/diska2', '/devices/diska3', '/devices/diska4' FAILGROUP mycontroller2 DISK '/devices/diskb1', '/devices/diskb2', '/devices/diskb3', '/devices/diskb4' ATTRIBUTE 'sector_size'='4096';
Using the SECTOR_SIZE Clause You can manage ASM with three different tools: SQL command line, the ASMCMD utility, and Enterprise Manager. Use the CREATE DISKGROUP clause to name a group of disks and specify that Oracle ASM should manage the group for you. Oracle ASM manages a disk group as a logical unit and evenly spreads each file across the disks to balance I/O. It also automatically distributes database files across all available disks in disk groups and rebalances storage automatically whenever the storage configuration changes. In Oracle Database 11g Release 2, use the optional SECTOR_SIZE clause in the CREATE DISKGROUP command to explicitly specify the sector size value for the disk group. If you do not use this clause, ASM detects the hardware sector size and uses it. The SECTOR_SIZE disk group attribute can be set only during disk group creation. The values for the SECTOR_SIZE can be 512, 4096, or 4K. ASM provides support for 4 KB sector disk drives without negatively affecting performance. For additional information about ASM, refer to the Oracle Database Storage Administrator's Guide.
11.2
Creating a Database with 4 KB Sector Disks
No extra work No GUI change Default sector size based on hardware (not the earlier 512 bytes sectors)
Creating a Database with 4 KB Sector Disks There is no additional work for you when you create a new database on 4 KB sector disks compared to creating a new database on 512 byte disks. There is no change in the GUI environment. You have the option of using the BLOCKSIZE clause in the CREATE DATABASE command as shown in the slide. When you do not specify a block size, the Oracle Database server discovers the underlying disk sector size, and uses the disk sector size as the block size for the redo log creation. So by default, the redo log block size is the disk sector size, not the earlier 512 byte sector size.
CREATE DATABASE sample NORESETLOGS FORCE LOGGING ARCHIVELOG LOGFILE GROUP 1 '$ORACLE_BASE/oradata/sample/redo01.log' SIZE 100M BLOCKSIZE 4096, GROUP 2 '$ORACLE_BASE/oradata/sample/redo02.log SIZE 100M BLOCKSIZE 4096 DATAFILE ...
11.2
Specifying BLOCKSIZE
ALTER DATABASE sample ADD LOGFILE GROUP 3 ('$ORACLE_BASE/oradata/sample/redo03a.log', '$ORACLE_BASE/oradata/sample/redo03b.log') SIZE 500K BLOCKSIZE 4096; CREATE CONTROLFILE REUSE DATABASE sample NORESETLOGS FORCE LOGGING ARCHIVELOG LOGFILE GROUP 1 '$ORACLE_BASE/oradata/sample/redo01.log' SIZE 100M BLOCKSIZE 4096, GROUP 2 '$ORACLE_BASE/oradata/sample/redo02.log ' SIZE 100M BLOCKSIZE 4096 DATAFILE
Specifying BLOCKSIZE Specify BLOCKSIZE to override the operating systemdependent sector size. The example in the slide shows the ALTER DATABASE and the CREATE CONTROLFILE commands. When you add a redo log file to a 512-byte sector disk or to a 4 KB native disk, the block size of the new file must be the original platform base block size. When you add a redo log file to a 4 KB sector disk with 512-byte emulation, then you can specify either 512, 1024 (or 1K), or 4096 (or 4K) as the block size, depending on your platform. All logs within a log group must have the same block size. Two log groups created on separate disks can have different block sizes. However, the mixed configuration introduces overhead at every log switch. Oracle recommends that you create all log files with the same block size. This clause is useful when the 4 KB sector size is in use, and you want to optimize disk space use rather than performance. In such a case, you can override the operating system sector size by specifying BLOCKSIZE 512 or, for HP-UX, BLOCKSIZE 1024. Reminder: Use the CREATE CONTROLFILE command very carefully. Oracle recommends that you perform a full backup of all files in the database before using this command. For more information, see Oracle Database Backup and Recovery User's Guide.
11.2
Determining Your Log File Block Size
Viewing the V$LOG or V$STANDBY_LOG views in the data dictionary New BLOCKSIZE column
SQL> desc v$log Name Null? Type --------------------------------- -------- -----------GROUP# NUMBER THREAD# NUMBER SEQUENCE# NUMBER BYTES NUMBER BLOCKSIZE NUMBER MEMBERS NUMBER ARCHIVED VARCHAR2(3) STATUS VARCHAR2(16) FIRST_CHANGE# NUMBER FIRST_TIME DATE
Determining Your Log File Block Size A new BLOCKSIZE column is added to the V$LOG and the V$STANDBY_LOG views. This column shows the block size of the log file. Valid values are 512, 1024, and 4096.
11.2
Performing an Offline Migration to 4 KB Disks
Premigration (4 KB disks, back up and shut down Oracle Database 11g Release 2) Migration:
1. 2. 3. 4. 5. 6. Move backup files to 4 KB disks. Mount database. Add log file groups on 4 KB disks. Confirm their status. Open the database. Switch logs to 4 KB log group.
Postmigration (Query log file status and drop old log files)
Performing an Offline Migration to 4 KB Disks The offline migration steps include the following. Pre-migration steps: 1. Plug in 4 KB disks. 2. Upgrade Oracle Database to 11.2 and set the COMPATIBILITY parameter to 11.2. 3. Back up the database. 4. Shut down the database. Migration steps: 1. Move your backup files to the 4 KB disks. 2. Mount the database. 3. Add at least two groups of 4 KB block size log files on the 4 KB disks.
ALTER DATABASE sample ADD LOGFILE GROUP 3 '$ORACLE_BASE/oradata/sample/redo4k_03.log', GROUP 4 '$ORACLE_BASE/oradata/sample/redo4k_04.log' SIZE 100M BLOCKSIZE 4096;
Performing an Offline Migration to 4 KB Disks (continued) 4. Query the V$LOG view to ensure that 4 KB block size logs are successfully added.
SQL> SELECT group#, blocksize, sequence#, status FROM v$log; GROUP# BLOCKSIZE SEQUENCE# STATUS ---------- ---------- ---------- ---------------1 512 1 INACTIVE 2 512 2 CURRENT 3 4096 0 UNUSED 4 4096 0 UNUSED
5. Open your database. 6. Switch logs to use the new 4 KB block size logs.
Postmigration steps: 1. Query the V$LOG view to ensure that all 512-byte block size logs have the INACTIVE status.
SQL> SELECT group#, blocksize, sequence#, status FROM v$log; GROUP# BLOCKSIZE SEQUENCE# STATUS ---------- ---------- ---------- ---------------1 512 1 INACTIVE 2 512 2 INACTIVE 3 4096 3 ACTIVE 4 4096 4 CURRENT
2. Drop all 512 block size logs.

SQL> alter database drop logfile group 1; Database altered. SQL> alter database drop logfile group 2; Database altered.
3. Query the V$LOG view to ensure that there are only 4 KB block size logs available for your database.
SQL> SELECT group#, blocksize, sequence#, status FROM v$log; GROUP# BLOCKSIZE SEQUENCE# STATUS ---------- ---------- ---------- ---------------3 4096 3 INACTIVE 4 4096 4 CURRENT
SQL> alter system switch logfile; Database altered.
Quiz
You must use 4 KB log files on 4 KB native mode disks. 1. True 2. False
Answer: 1
Table Compression: Overview
Oracle Database 11g extends compression for OLTP data.

Support for conventional DML operations (INSERT, UPDATE, DELETE)
New algorithm significantly reduces write overhead.
No impact on reads
Reads may actually see improved performance due to fewer I/Os and enhanced memory efficiency.
Table Compression: Overview The Oracle database was the pioneer in terms of compression technology for databases with the introduction of table compression for bulk load operations in Oracle9i. Using this feature, you could compress data at the time of performing bulk load using operations such as direct loads, or CREATE TABLE AS SELECT (CTAS). However, until now, compression was not available for regular data manipulation operations such as INSERT, UPDATE, and DELETE. Oracle Database 11g extends the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload, be it online transaction processing (OLTP) or data warehousing. It is important to mention that table compression enhancements introduced in Oracle database 11g are not just incremental changes. An enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates because any noticeable write time penalty due to compression will not be acceptable in an OLTP environment. As a result, compression technology in Oracle Database 11g is very efficient and could reduce the space consumption by 50 75%. Write performance does not degrade and read performance or queries improve. This is because unlike desktop-based compression techniques where you have to wait for data to be uncompressed, Oracle technology reads the compressed data (less fetches needed) directly and does not require any uncompress operation. Note: Compression technology is completely application transparent. This means that you can use this technology with any homegrown or packaged application such as SAP, Siebel, EBS, and so on.
Batched compression ensures no impact for most OLTP transactions.
Table Compression Concepts
Inserts are again uncompressed.
Compressed data Uncompressed data
PCTFREE reached triggers compression.
Data block
Header
PCTFREE limit
PCTFREE reached triggers compression.
Free space
Inserts are uncompressed.
Table Compression Concepts The slide shows you a data block evolution when that block is part of a compressed table. You should read it from left to right. At the start, the block is empty and available for inserts. When you start inserting into this block, data is stored in an uncompressed format (as for uncompressed tables). However, as soon as the block is filled based on the PCTFREE setting of the block, the data is automatically compressed, potentially reducing the space it originally occupied. This allows for new uncompressed inserts to take place in the same block, until it is once again filled based on the PCTFREE setting. At that point compression is triggered again to reduce the amount of space used in the block. Note: Compression eliminates holes created due to deletions and maximizes contiguous free space in blocks.
Compressing Table Data

Compression Method
Basic compression OLTP table compression
11.2 update
Compression Ratio
High High
CPU Overhead
Minimal Minimal
CREATE and ALTER TABLE Syntax

COMPRESS [BASIC] COMPRESS FOR OLTP
Typical Apps
DSS OLTP, DSS
Compressing Table Data Oracle Database supports two methods of table compression: Basic compression (previously known as DSS table compression) OLTP table compression (introduced in Oracle Database 11g Release 1) The COMPRESS clause of the CREATE TABLE and ALTER TABLE commands has new options that activate the compression methods introduced in Oracle Database 11g. After activation, compression can occur while data is being inserted, updated, or bulk-loaded into a compressed table. These operations include single-row or array inserts and updates, and the following direct-path insert methods: Direct path SQL*Loader CREATE TABLE AS SELECT statements Parallel INSERT statements INSERT statements with an APPEND hint
Compressing Table Data (continued) The TABLE_COMPRESSION clause is valid only for heap-organized tables. Use this clause to instruct the database server whether to compress data segments to reduce disk use. The COMPRESS keyword enables table compression. The NOCOMPRESS keyword disables table compression. NOCOMPRESS is the default. You can specify table compression: For an entire table (in the PHYSICAL_PROPERTIES clause of RELATIONAL_TABLE or OBJECT_TABLE) For partitioned tables, each partition can have a different type or level of compression. For the storage of a nested table (in the NESTED_TABLE_COL_PROPERTIES clause) Table compression has the following restrictions: COMPRESS FOR OLTP and COMPRESS BASIC are not supported for tables with more than 255 columns. Data segments of BasicFile LOBs are not compressed. For information about compression of SecureFile LOBs, see LOB_COMPRESSION_CLAUSE in the Oracle Database SQL Language Reference. You cannot specify table compression for an index-organized table, any overflow segment or partition of an overflow segment, or any mapping table segment of an index-organized table. You cannot specify table compression for external tables or for tables that are part of a cluster. You cannot drop a column from a table that is compressed for direct-load operations, although you can set such a column as unused. All the operations of the ALTER TABLE ... DROP_COLUMN_CLAUSE are valid for tables which are compressed for all operations.
Using OLTP Compression
11.2 changes
Requires database compatibility level at 11.1 or greater New syntax extends the COMPRESS keyword:
COMPRESS [BASIC | FOR OLTP] BASIC is the default: Refers to bulk-load operations from prior releases FOR OLTP: OLTP + direct loads
Enable compression for new tables:

CREATE TABLE t1 COMPRESS FOR OLTP;
Enable compression on an existing table:

ALTER TABLE t2 COMPRESS FOR OLTP;
Does not trigger compression on existing rows

Using OLTP Compression To use the new table compression algorithm, you must flag your table with the COMPRESS FOR OLTP clause. You can do so at table creation or after creation as illustrated in the examples given in the slide. Note that if you enable compression on an existing table, the existing rows in the table are not compressed. If you use the COMPRESS clause without specifying any FOR option, or if you use the COMPRESS BASIC clause, the compression mechanism that was available in releases before Oracle Database 11g is used. You can also enable compression at the partition or tablespace level. For example, you can use the DEFAULT storage clause of the CREATE TABLESPACE command to optionally specify a COMPRESS FOR clause. Note: You can view compression flags for your tables using the COMPRESS and COMPRESS_FOR columns in views such as DBA_TABLES and DBA_TAB_PARTITIONS. In Oracle Database 11g Release 1, the COMPRESS clause options were FOR DIRECT_LOAD OPERATIONS (DSS table compression) and FOR ALL OPERATIONS (OLTP compression). The use of COMPRESS FOR OLTP requires the Advanced Compression option.
11.2
Using the Compression Advisor

A compression advisor helps to determine optimal compression ratios. The DBMS_COMPRESSION package includes the GET_COMPRESSION_RATIO procedure.
BEGIN DBMS_COMPRESSION.GET_COMPRESSION_RATIO ('USERS','SH','SALES', NULL,DBMS_COMPRESSION.COMP_FOR_OLTP, blkcnt_cmp, blkcnt_uncmp, rowcnt_cmp, rowcnt_uncmp, comptype); DBMS_OUTPUT.PUT_LINE('Blk count compressed = ' || blkcnt_cmp); DBMS_OUTPUT.PUT_LINE('Blk count uncompressed = ' || blkcnt_uncmp); DBMS_OUTPUT.PUT_LINE('Row count per block compressed = ' || rowcnt_cmp); DBMS_OUTPUT.PUT_LINE('Row count per block uncompressed = ' || rowcnt_uncmp); DBMS_OUTPUT.PUT_LINE('Compression type = ' || comptype); DBMS_OUTPUT.PUT_LINE('Compression ratio = '||blkcnt_uncmp/blkcnt_cmp||' to 1');
Using the Compression Advisor A compression advisor, provided by the DBMS_COMPRESSION package, helps you to determine the compression ratio that can be expected for a specified table. The advisor analyzes the objects in the database, discovers the possible compression ratios that could be achieved, and recommends optimal compression levels. In addition to the DBMS_COMPRESSION package, the compression advisor can also be used within the existing advisor framework (with the DBMS_ADVISOR package). To determine the compression ratio, the DBMS_COMPRESSION package has the following subprograms: The GET_COMPRESSION_RATIO procedure gives you the possible compression ratio for an uncompressed table. The GET_COMPRESSION_TYPE procedure returns the compression type for a given row. For more details, refer to Oracle Database PL/SQL Packages and Types Reference.
Viewing Table Compression Information
*_TABLES views have new columns: COMPRESSION: Indicates whether table compression is enabled (ENABLED) or not (DISABLED) COMPRESS_FOR: Type of compression
Viewing Table Compression Information The *_TABLES views have the COMPRESSION and COMPRESS_FOR columns which enable you to view compression information.
SQL Access Advisor: Overview

What partitions, indexes, and MVs do I need to optimize my entire workload?
Solution
SQL Access Advisor
DBA Workload
No expertise required Provides implementation script Component of CBO
SQL Access Advisor: Overview Defining appropriate access structures to optimize SQL queries has always been a concern for an Oracle DBA. As a result, there have been many papers and scripts written as well as high-end tools developed to address the matter. In addition, with the development of partitioning and materialized view technology, deciding on access structures has become even more complex. As part of the manageability improvements in Oracle Database 10g and 11g, SQL Access Advisor has been introduced to address this very critical need. SQL Access Advisor identifies and helps resolve performance problems relating to the execution of SQL statements by recommending which indexes, materialized views, materialized view logs, or partitions to create, drop, or retain. It can be run from Database Control or from the command line by using PL/SQL procedures. SQL Access Advisor takes an actual workload as input, or the Advisor can derive a hypothetical workload from the schema. It then recommends the access structures for faster execution path. It provides the following advantages: Does not require you to have expert knowledge Bases decision making on rules that actually reside in the cost-based optimizer Is synchronized with the optimizer and Oracle database enhancements Is a single advisor covering all aspects of SQL access methods Provides simple, user-friendly GUI wizards Generates scripts for implementation of recommendations
SQL Access Advisor: Usage Model

SQL Access Advisor SQL cache Hypothetical STS Filter Options Workload
Indexes
Materialized views
Materialized Partitioned views log objects
SQL Access Advisor: Usage Model SQL Access Advisor takes as input a workload that can be derived from multiple sources: SQL cache, to take the current content of V$SQL Hypothetical, to generate a likely workload from your dimensional model. This option is interesting when your system is being initially designed. SQL Tuning Sets, from the workload repository SQL Access Advisor also provides powerful workload filters that you can use to target the tuning. For example, a user can specify that the advisor should look at only the 30 most resource-intensive statements in the workload, based on optimizer cost. For the given workload, the advisor then does the following: Simultaneously considers index solutions, materialized view solutions, partition solutions, or combinations of all three Considers storage for creation and maintenance costs Does not generate drop recommendations for partial workloads Optimizes materialized views for maximum query rewrite usage and fast refresh Recommends materialized view logs for fast refresh Recommends partitioning for tables, indexes, and materialized views Combines similar indexes into a single index Generates recommendations that support multiple workload queries
Possible Recommendations
Recommendation Add new (partitioned) index on table or materialized view. Drop an unused index. Modify an existing index by changing the index type. Modify an existing index by adding columns at the end. Add a new (partitioned) materialized view. Drop an unused materialized view (log). Add a new materialized view log. Modify an existing materialized view log to add new columns or clauses. Partition an existing unpartitioned table or index. Comprehensive YES YES YES YES YES YES YES YES YES Limited YES NO NO YES YES
YES YES YES
Possible Recommendations SQL Access Advisor carefully considers the overall impact of recommendations and makes recommendations by using only the known workload and supplied information. Two workload analysis methods are available: Comprehensive: With this approach, SQL Access Advisor addresses all aspects of tuning partitions, materialized views, indexes, and materialized view logs. It assumes that the workload contains a complete and representative set of application SQL statements. Limited: Unlike the comprehensive workload approach, a limited workload approach assumes that the workload contains only problematic SQL statements. Thus, advice is sought for improving the performance of a portion of an application environment. When comprehensive workload analysis is chosen, SQL Access Advisor forms a better set of global tuning adjustments, but the effect may be a longer analysis time. As shown in the table, the chosen workload approach determines the type of recommendations made by the advisor. Note: Partition recommendations can work on only those tables that have at least 10,000 rows, and workloads that have some predicates and joins on columns of NUMBER or DATE type. Partitioning advice can be generated only on these types of columns. In addition, partitioning advice can be generated only for single-column interval and hash partitions. Interval partitioning recommendations can be output as range syntax but interval is the default. Hash partitioning is done to leverage only partitionwise joins.
NO
Using SQL Access Advisor
Using SQL Access Advisor You can access the SQL Access Advisor wizard through the Advisor Central link on the Database Home page or through individual alerts or performance pages that may include a link to facilitate solving a performance problem. The SQL Access Advisor wizard consists of several steps during which you supply the SQL statements to tune and the types of access methods you want to use. Use the SQL Access Advisor: Initial Options page to select a template or task from which to populate default options before starting the wizard. You can click Continue to start the wizard or Cancel to go back to the Advisor Central page. Note: The SQL Access Advisor may be interrupted while generating recommendations, thereby allowing the results to be reviewed. For general information about using SQL Access Advisor, see the Overview of the SQL Access Advisor section in the SQL Access Advisor chapter of the Oracle Data Warehousing Guide.
SQL Access Advisor: PL/SQL Procedure Flow

Step 3 Step 1 CREATE_TASK UPDATE_TASK_ATTRIBUTES DELETE_TASK QUICK_TUNE
Task-dependent
Advisor-dependent
SQL Access Advisor task
Report/Scripts SET_TASK_PARAMETER RESET_TASK Step 2

SQL Access Advisor: PL/SQL Procedure Flow The graphic shows the typical operational flow of the SQL Access Advisor procedures from the DBMS_ADVISOR package. You can find a complete description of each of these procedures in the Oracle Database PL/SQL Packages and Types Reference guide. Step 1: Create and manage tasks and data. This step uses a SQL Access Advisor task. Step 2: Prepare tasks for various operations. This step uses SQL Access Advisor parameters. Step 3: Prepare and analyze data. This step uses SQL Tuning Sets and SQL Access Advisor tasks. With Oracle Database 11g, GET_TASK_REPORT can report back using HTML or XML in addition to text. Note: The DBMS_ADVISOR.QUICK_TUNE procedure is a shortcut that performs all the necessary operations to analyze a single SQL statement. The operation creates a task for which all parameters are defaulted. The workload is constituted by the specified statement only. Finally, the task is executed and the results are saved in the repository. You can also instruct the procedure to implement the final recommendations.
ADD_STS_REF DELETE_STS_REF EXECUTE_TASK INTERRUPT/CANCEL_TASK MARK_RECOMMENDATION UPDATE_REC_ATTRIBUTES GET_TASK_REPORT GET_TASK_SCRIPT
SQL Access Advisor: PL/SQL Example
BEGIN dbms_advisor.create_task(dbms_advisor.sqlaccess_advisor,'MYTASK'); END;
BEGIN dbms_advisor.set_task_parameter('MYTASK','ANALYSIS_SCOPE','ALL'); dbms_advisor.set_task_parameter('MYTASK','MODE','COMPREHENSIVE'); END;
BEGIN dbms_advisor.add_sts_ref('MYTASK','SH','MYSTS'); dbms_advisor.execute_task('MYTASK'); dbms_output.put_line(dbms_advisor.get_task_script('MYTASK')); END;
SQL Access Advisor: PL/SQL Example Matching the order shown in the previous slide, the examples in this slide show you a possible SQL Access Advisor tuning session using PL/SQL code. The first PL/SQL block creates a new tuning task called MYTASK. This task uses the SQL Access Advisor. The second PL/SQL block sets SQL Access Advisor parameters for MYTASK. In the example, you set ANALYSIS_SCOPE to ALL, which means you generate recommendations for indexes, materialized views, and partitions. Then, you set MODE to COMPREHENSIVE to include all SQL statements that are part of the SQL Tuning Set associated to a future task. The third PL/SQL block associates a workload to MYTASK. Here, you use an existing SQL Tuning Set called MYSTS. You can now execute the tuning task. After its execution completes, you can generate corresponding recommendation scripts as shown in the third example in the slide. Note: For a complete list of SQL Access Advisor parameters (around 50), refer to the Oracle Database PL/SQL Packages and Types Reference guide.
Temporary Tablespace Shrink
Sort segment extents are managed in memory after being physically allocated. This method can be an issue after big sorts are done. To release physical space from your disks, you can shrink temporary tablespaces:
CREATE TEMPORARY TABLESPACE temp TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m; ALTER TABLESPACE temp SHRINK SPACE [KEEP 200m]; ALTER TABLESPACE temp SHRINK TEMPFILE 'tbs_temp.dbf';
Temporary Tablespace Shrink Huge sorting operations can cause temporary tablespace to grow a lot. For performance reasons, after a sort extent is physically allocated, it is managed in memory to avoid physical deallocation later. As a result, you can end up with a huge tempfile that stays on disk until it is dropped. One possible workaround is to create a new temporary tablespace with smaller size, set this new tablespace as default temporary tablespace for users, and then drop the old tablespace. However, there is a disadvantage that the procedure requires no active sort operations happening at the time of dropping old temporary tablespace. Starting with Oracle Database 11g Release 1, you can use the ALTER TABLESPACE SHRINK SPACE command to shrink a temporary tablespace, or you can use the ALTER TABLESPACE SHRINK TEMPFILE command to shrink one tempfile. For both commands, you can specify the optional KEEP clause that defines the lower bound that the tablespace/tempfile can be shrunk to. If you omit the KEEP clause, then the database attempts to shrink the tablespace/tempfile as much as possible (total space of all currently used extents) as long as other storage attributes are satisfied. This operation is done online. However, if some currently used extents are allocated above the shrink estimation, the system waits until they are released to finish the shrink operation. Note: The ALTER DATABASE TEMPFILE RESIZE command generally fails with ORA-03297 because the tempfile contains used data beyond requested RESIZE value. As opposed to ALTER TABLESPACE SHRINK, the ALTER DATABASE command does not try to deallocate sort extents after they are allocated.
Locally managed temporary tablespaces Online operation
DBA_TEMP_FREE_SPACE
Lists temporary space usage information Central point for temporary tablespace space usage
Column name
TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE
Description
Name of the tablespace Total size of the tablespace, in bytes Total allocated space, in bytes, including space that is currently allocated and used and space that is currently allocated and available for reuse Total free space available, in bytes, including space that is currently allocated and available for reuse and space that is currently unallocated
FREE_SPACE
DBA_TEMP_FREE_SPACE This dictionary view reports temporary space usage information at the tablespace level. The information is derived from various existing views.
Tablespace Option for Creating Temporary Table
Specify which temporary tablespace to use for your global temporary tables. Decide a proper temporary extent size.
CREATE TEMPORARY TABLESPACE temp TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m; CREATE GLOBAL TEMPORARY TABLE temp_table (c varchar2(10)) ON COMMIT DELETE ROWS TABLESPACE temp;
Tablespace Option for Creating Temporary Table Starting with Oracle Database 11g Release 1, it becomes possible to specify a TABLESPACE clause when you create a global temporary table. If no tablespace is specified, the global temporary table is created in your default temporary tablespace. In addition, indexes created on the temporary table are also created in the same temporary tablespace as the temporary table. This possibility allows you to decide a proper extent size that reflects your sort-specific usage, especially when you have several types of temporary space usage. Note: You can find in DBA_TABLES which tablespace is used to store your global temporary tables.
11.2
Segment Creation on Demand
Segment creation is deferred until the first row is inserted. DEFERRED_SEGMENT_CREATION = TRUE (default)
CREATE TABLE Save disk space Improve installation time of applications with large schemas
INSERT INTO
Segment Creation on Demand Oracle Database 11g Release 2 includes a new space allocation method. When you create a nonpartitioned heap table, the table segment creation is deferred to the first row insert. This functionality is enabled by default with the DEFERRED_SEGMENT_CREATION initialization parameter set to TRUE. Advantages of this new space allocation method: A significant amount of disk space can be saved for applications that create hundreds or thousands of tables upon installation, many of which might never be populated. The application installation time is reduced. When you insert the first row into the table, the segments are created for the base table, its LOB columns, and its indexes. During segment creation, cursors on the table are invalidated. These operations have a small additional impact on performance. Note: With this new allocation method, it is essential that you do proper capacity planning so that the database has enough disk space to handle segment creation when tables are populated. For more details, see the Oracle Database Administrator's Guide.
11.2
Creating Tables Without Segments

SQL> SHOW PARAMETERS deferred_segment_creation NAME TYPE VALUE ------------------------------------ ----------- -----deferred_segment_creation boolean TRUE SQL> CREATE TABLE seg_test(c number, d varchar2(500)); Table created. SQL> SELECT segment_name FROM user_segments; no rows selected
Inserting rows and creating segments:

SQL> INSERT INTO seg_test VALUES(1, 'aaaaaaa'); 1 row created. SQL> SELECT segment_name FROM user_segments; SEGMENT_NAME ------------------------------------------------------SEG_TEST
Creating Tables Without Segments This slide shows you how to check the DEFERRED_SEGMENT_CREATION parameter. Then a table is created without segments, which you can verify by querying the USER_SEGMENTS data dictionary view. After inserting a row, you query this view again to verify that the segment now exists. You can also query the SEGMENT_CREATED column of the USER_TABLES, USER_INDEXES, or USER_LOBS views. For non-partitioned tables, indexes and lobs, this column shows YES, if the segment is created.
11.2
Controlling Deferred Segment Creation
With DEFERRED_SEGMENT_CREATION parameter in the: Initialization parameter file ALTER SESSION command ALTER SYSTEM command With SEGMENT CREATION clause: IMMEDIATE DEFERRED (default in Oracle Database 11g Release 2)
CREATE TABLE seg_tab3(c1 NUMBER, c2 NUMBER) SEGMENT CREATION IMMEDIATE TABLESPACE seg_tbs; CREATE TABLE seg_tab4(c1 NUMBER, c2 NUMBER) SEGMENT CREATION DEFERRED;
Note: Indexes inherit table characteristics.

Controlling Deferred Segment Creation Segment creation can be controlled in two ways: With the DEFERRED_SEGMENT_CREATION initialization parameter set to TRUE or FALSE. This parameter can be set in the initialization parameter file. You can also control it via the ALTER SESSION or ALTER SYSTEM commands. Examples:
ALTER SESSION SET DEFERRED_SEGMENT_CREATION = TRUE; ALTER SYSTEM SET DEFERRED_SEGMENT_CREATION = FALSE;
With the SEGMENT CREATION clause of the CREATE TABLE command: - SEGMENT CREATION DEFERRED: If specified, segment creation is deferred until the first row is inserted into the table. This is the default behavior for Oracle Database 11g Release 2. - SEGMENT CREATION IMMEDIATE: If specified, segments are materialized during table creation. This is the default behavior in Oracle databases prior to Oracle Database 11g Release 2. This clause takes precedence over the DEFERRED_SEGMENT_CREATION parameter. It is possible to force creation of segments for an already created table with the ALTER TABLE MOVE command. However, it is not possible to directly control the deferred segment creation for dependant objects like indexes. They inherit this characteristic from their parent object, in this case, the table.
11.2
Restrictions and Exceptions
Restrictions and Exceptions In Oracle Database 11g Release 2, deferred segment creation on demand is restricted to nonpartitioned heap tables and nonpartitioned indexes. IOTs and other special tables are not supported. Segment creation on demand is not supported for tables created in dictionary-managed tablespaces and for clustered tables. An attempt to do so creates segments. If you create a table with deferred segment creation in a locally managed tablespace, it has no segments. If at a later time, you migrate the tablespace to dictionary-managed, any attempt to create segments produces errors. In this case, you must drop the table and re-create it. Segment creation on demand is not supported for clustered tables, global temp tables, sessionspecific temp tables, internal tables, typed tables, AQ tables, SYS-owned tables, external tables, bitmap join indexes, and domain indexes. Tables owned by SYSTEM, PUBLIC, OUTLN, and XDB are also excluded.
Segment creation on demand: Only for nonpartitioned heap tables and nonpartitioned indexes Not for IOTs, clustered tables, or other special tables Not for tables in dictionary-managed tablespaces Note: If you were to migrate a table without segments from a locally managed to a dictionary-managed tablespace, you must drop and re-create it.
11.2
Additional Automatic Functionality
No segments for unusable indexes and index partitions Creating an index without a segment
CREATE INDEX test_i1 ON seg_test(c) UNUSABLE;
Removing any allocated space for an index

ALTER INDEX test_i UNUSABLE; ALTER INDEX test_i REBUILD;
Additional Automatic Functionality Additional enhancements in Oracle Database 11g Release 2 (unrelated to the deferred segment creation) are implemented to save space: all UNUSABLE indexes and index partitions are created without a segment. This functionality is completely transparent. It is enabled by default with the COMPATIBILITY initialization parameter set to 11.2.0.0. Example: If you have a table named DEMO with three partitions and a local index, you see three table and three index segments when executing the following query:
SELECT segment_name, partition_name, segment_type FROM user_segments WHERE segment_name like '%DEMO';
If you execute the same query after you move one table partition to a new tablespace, you see three table segments and only two index segments, because the unusable one is automatically deleted.
Creating the segment for an index:
Quiz
4. Segment creation on demand is available for nonpartitioned tables.
Answer: 2, 4
Which of the following statements are true for Oracle Database 11g Release 2? 1. Deferred segment creation is always enabled. You cannot control it. 2. You can control the deferred segment creation with the SEGMENT CREATION clause of the CREATE TABLE command. 3. Segment creation on demand is available for all types of tables, including those owned by the SYS user.
Summary
In this lesson, you should have learned how to: Use 4 KB sector disks Employ data compression Create a SQL Access Advisor analysis session using Enterprise Manager Create a SQL Access Advisor analysis session using PL/SQL Use deferred segment creation
This practice covers using table compression.
Data Warehouse and Partitioning Enhancements
Objectives
After completing this lesson, you should be able to: Load data that is stored in compressed files Set parameters for the simplified parallelism implementation Implement the new partitioning methods
11.2
Preprocessing Data for ORACLE_LOADER Access Driver in External Tables

New feature: Preprocessing of files for external tables enables Enabling feature: EXECUTE privilege for directory objects
External files
External tables
Preprocessing Data for ORACLE_LOADER Access Driver in External Tables In Oracle Database 11g Release 2, the syntax for the ORACLE_LOADER access driver has been extended to allow specification of a program to preprocess the data files that are read for the external table. (An access driver is the actual mechanism used to read the external data in the table. The ORACLE_LOADER access driver is the one affected by this new feature.) To enable this new feature, another new feature is introduced in Oracle Database 11g Release 2. The EXECUTE privilege has been added for DIRECTORY objects. The ORACLE_LOADER access driver will create a process that runs a user-specified program. That program must live in a directory path specified by a directory object defined in the database. Only a user that has been given the EXECUTE access to the directory object will be allowed to run programs in it. The access parameters can specify the name of a directory object and the name of an executable file in that directory object. When the access driver needs to read data from a file, it will create a process that executes the specified program, passing in the name of the data file. The output from the program will be passed into the access driver which parses the data into records and columns. The user will specify the name of the program used to decompress the file as part of the access parameters. The access driver reads the output of the decompression program.
11.2
Windows Example
[C:\TEMP]type C:\DATA/input.dat hello world Windows uses a batch file [C:\TEMP]type C:\TEMP/bar.bat @cat %1 | tr hw HW rather than shell script to SQL> @ex1 preprocess the data. SQL> connect /as sysdba Connected. SQL> create or replace directory def_dir1 as 'C:\DATA; Directory created. SQL> create or replace directory execdir as 'C:\TEMP ; Directory created. SQL> grant read, write on directory def_dir1 to scott; Grant succeeded. SQL> grant read, write, execute on directory execdir to scott; Grant succeeded. SQL> connect scott/tiger Connected. SQL> drop table ex1; Table dropped. SQL> create table ex1 (recno varchar2(2000)) 2 organization external ( 3 type ORACLE_LOADER 4 default directory def_dir1 5 access parameters ( 6 debug = 3 7 records delimited by newline 8 preprocessor execdir:'bar.bat' Preprocessor 9 fields ( 10 col1 char(2000) 11 )) 12 location ('input.dat')) 13 reject limit unlimited; Table created. SQL> select * from ex1; COL1 ---------------------------------------------------------------Hello World SQL>
Windows Example In this Windows example, the table to be loaded has a single VARCHAR2 column. The batch file will convert the string hello world (the contents of the input data) to Hello World. Windows uses a batch file rather than shell script to preprocess the data. Secondly, note the @ character used in the batch file. This will prevent the preprocessing command from echoing what would then be considered input data. Lastly, note that Windows batch files use the % character rather than the UNIX style $ to provide access to arguments.
11.2
Example of Preprocessing
External CREATE TABLE sales_transactions_ext table (PROD_ID NUMBER, CUST_ID NUMBER, TIME_ID DATE, CHANNEL_ID NUMBER, PROMO_ID NUMBER, QUANTITY_SOLD NUMBER, AMOUNT_SOLD NUMBER(10,2), UNIT_COST NUMBER(10,2), UNIT_PRICE NUMBER(10,2)) ORGANIZATION external (TYPE oracle_loader DEFAULT DIRECTORY data_file_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE CHARACTERSET US7ASCII PREPROCESSOR exec_file_dir:'gunzip' OPTIONS '-C' BADFILE log_file_dir:'sh_sales.bad_xt' LOGFILE log_file_dir:'sh_sales.log_xt' Preprocessor FIELDS TERMINATED BY "|" LDRTRIM invoking the ( PROD_ID, CUST_ID, gunzip TIME_ID DATE(10) "YYYY-MM-DD", compression utility CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, UNIT_COST, UNIT_PRICE)) External file using location ('sh_sales.dat.gz') )REJECT LIMIT UNLIMITED; the GNU zip utility
Example of Preprocessing With Oracle Database 11g Release 2, you can specify a program to be executed (such as zcat) that will process files (such as compressed data files) and enable Oracle Database to use the output (such as uncompressed data files). This enables you to load large amounts of compressed data without first uncompressing it on a disk. This example shows an external table named SALES_TRANSACTIONS_EXT, representing the structure of the complete sales transaction data in the external file sh_sales.dat.gz. The product department is especially interested in a cost analysis on product and time, so a fact table named COSTS is created in the sales history schema. The operational source data is the same as for the SALES fact table. However, because you are not investigating every dimensional information that is provided, the data in the COSTS fact table has a coarser granularity than in the SALES fact table, for example, all different distribution channels are aggregated. You cannot load the data into the COSTS fact table without applying the previously mentioned aggregation of the detailed information, due to the suppression of some of the dimensions. The external table framework offers a solution to solve this. Unlike SQL*Loader, where you would have to load the data before applying the aggregation, you can combine the loading and transformation within a single SQL DML statement, as shown in the following. You do not have to stage the data temporarily before inserting into the target table. Note that the preprocessor file is in a separate directory from the data files and log files.
Example of Preprocessing (continued) Note: gzip (GNU zip) is a compression utility designed to be a replacement for compress. Its main advantages over compress are much better compression and freedom from patented algorithms. It has been adopted by the GNU project and is now relatively popular on the Internet. gzip produces files with a .gz extension. gunzip can decompress files created by gzip, compress or pack.
11.2
EXECUTE Privilege for Directory Objects

CREATE TABLE sales_transactions_ext (PROD_ID NUMBER, CUST_ID NUMBER, TIME_ID DATE, CHANNEL_ID NUMBER, PROMO_ID NUMBER, QUANTITY_SOLD NUMBER, AMOUNT_SOLD NUMBER(10,2), UNIT_COST NUMBER(10,2), UNIT_PRICE NUMBER(10,2)) ORGANIZATION external (TYPE oracle_loader DEFAULT DIRECTORY data_file_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE CHARACTERSET US7ASCII PREPROCESSOR exec_file_dir:'gunzip' OPTIONS '-C' BADFILE log_file_dir:'sh_sales.bad_xt' EXECUTE privilege LOGFILE log_file_dir:'sh_sales.log_xt' for directory object FIELDS TERMINATED BY "|" LDRTRIM ( PROD_ID, CUST_ID, TIME_ID DATE(10) "YYYY-MM-DD", CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, UNIT_COST, UNIT_PRICE)) location ('sh_sales.dat.gz') )REJECT LIMIT UNLIMITED;
EXECUTE Privilege for Directory Objects The object directories must already exist, and point to the directory containing the sh_sales.dat.gz external file as well as the directory containing the bad and log files. The external table can now be used from within the database, accessing some columns of the external data only, grouping the data, and inserting it into the COSTS fact table. For example: INSERT /*+ APPEND */ INTO COSTS (TIME_ID, PROD_ID, UNIT_COST, UNIT_PRICE) SELECT TIME_ID, PROD_ID, AVG(UNIT_COST), AVG(amount_sold/quantity_sold) FROM sales_transactions_ext GROUP BY time_id, prod_id;
11.2
Security Implications
Security Implications To use the preprocessing feature, you must specify the PREPROCESSOR clause in the access parameters of the ORACLE_LOADER access driver. The PREPROCESSOR must be a directory object, and the user accessing the external table must have EXECUTE privileges for the directory object. Because the access driver needs to run the preprocessor that will modify the data in the data files, the database user must be prevented from specifying, either accidentally or maliciously, a program that could damage or corrupt the database or the operating system. Because the program that is being executed is run under the OS credentials of the OS user ORACLE, the preprocessor can also access any files that can be accessed by the OS user ORACLE. By forcing the preprocessor to live in a directory object, the DBA and the OS system manager control who gets to access the preprocessor. The OS system manager needs to create the directory corresponding to the directory object and needs to make sure that the OS user ORACLE has access to the directory. The DBA needs to make sure that only the required database users are allowed access to the directory object associated with the directory path. Although multiple database users can have access to a directory object, only those with the EXECUTE privilege can run a preprocessor in that directory. No existing database user with READ/WRITE privileges to a directory object will be able to use the preprocessing feature. A DBA can prevent preprocessors from ever being used by never granting the EXECUTE privileges to a directory object.
The ORACLE_LOADER access driver will create a process that runs a user-specified program. That preprocessor program must live in a directory path specified by a directory object defined in the database. Only a user that has been given EXECUTE access to the directory object will be allowed to run programs in it. The preprocessor runs as the Oracle software owner user.
Security Implications (continued) Warning: User-written preprocessors can possibly be used to attack the database by accessing or modifying the database files. Because the Oracle user owns and executes the preprocessor and owns the database files there is a possible security hole which must be plugged by assuring that the preprocessor code is safe.
11.2
Securing the ORACLE_LOADER Access Driver
Securing the ORACLE_LOADER Access Driver You should take some precautions when allowing preprocessors to be used with external tables because you may not know what the preprocessor is doing. Follow these guidelines to secure the ORACLE_LOADER access driver. These guidelines are detailed in Oracle Database Security Guide 11g Release 2.
1. Create a separate operating system directory to store the access driver preprocessors. 2. Grant the operating system user ORACLE the correct operating system privileges to run the access driver preprocessor. 3. Grant the EXECUTE privilege to each user who will run the preprocessor program in the directory object. 4. Grant the WRITE privilege sparingly to anyone who will manage directory objects that contain preprocessors. 5. Create a separate operating system directory and directory object for any data files that are required for external tables.
11.2
Securing the ORACLE_LOADER Access Driver
9. Consider auditing the directory object.
6. Create a separate operating system directory and directory object for any files that the access driver generates. 7. Grant the CREATE ANY DIRECTORY and DROP ANY DIRECTORY privileges sparingly. 8. Consider auditing the DROP ANY DIRECTORY privilege.
11.2
Considerations and Usage Notes
Considerations and Usage Notes The PREPROCESSOR clause is not available for databases that use Oracle Database Vault. For UNIX scripts, the fully qualified path name must be specified in the OPTIONS portion of the access parameters. Currently only a single argument may be provided in the OPTIONS portion of the access parameters. The preprocessor uses the output from standard out (stdout) for the external table. Any script or binary executable used as a preprocessor command must ensure that the desired output goes to standard out (as opposed to standard error).
The PREPROCESSOR clause cannot be used with Oracle Database Vault. Specify the fully qualified path name in the OPTIONS portion of the access parameters (UNIX). The OPTIONS portion of the access parameters supports only a single argument. Output must go to standard out.
Quiz
Answer: 1
With Oracle Database 11g Release 2, you can specify a program to be executed that will process files (such as compressed data files) and enable Oracle Database to use the output (such as uncompressed data files). 1. True 2. False
Review: Degree of Parallelism (DOP)
Review: Degree of Parallelism The number of parallel execution servers associated with a single operation is known as the degree of parallelism. Note that the degree of parallelism applies directly only to intraoperation parallelism. If interoperation parallelism is possible, the total number of parallel execution servers for a statement can be twice the specified degree of parallelism. No more than two sets of parallel execution servers can execute simultaneously. Each set of parallel execution servers may process multiple operations. Only two sets of parallel execution servers need to be active to guarantee optimal interoperation parallelism. Oracle Database provides several ways to manage resource utilization in conjunction with parallel execution environments, including: The adaptive multiuser algorithm, which is enabled by default, and which reduces the degree of parallelism as the load on the system increases User resource limits and profiles, which allow you to set limits on the amount of various system resources available to each user as part of a users security domain The Database Resource Manager, which enables you to allocate resources to groups of users Partition granules are used in limited situations such as: Parallel DML accessing more than one table partition and where a local partitioned bitmap index exists. (By definition, the local index has only one index partition per table partition and the first case is ambiguous because it may be interpreted as saying that the local bitmap index accesses more than one partition.)
Degree of parallelism is the number of parallel execution servers used by one parallel operation. DOP applies only to intraoperation parallelism. If interoperation parallelism is used, the number of parallel execution servers can be twice the DOP. No more than two sets of parallel execution servers can be used for one parallelized statement. Partition granules are used for certain operations and may limit the degree of parallelism. When you use partition granules, use a relatively high number of partitions.
Review: Degree of Parallelism (continued) Parallel index range scan that accesses more than one index partition. (The key here is in the index partitions and not the table partitions.) Partition granules may also be used to create partitioned indexes where the number of index partitions to be created limits the DOP.
Review: PARALLEL Clause
CREATE INDEX ord_customer_ix ON oe.orders (customer_id) NOLOGGING PARALLEL; ALTER TABLE customers PARALLEL 5;
ALTER TABLE sales SPLIT PARTITION sales_q4_2000 AT ('15-NOV-2000') INTO (PARTITION sales_q4_1, PARTITION sales_q4_2) PARALLEL 2;
Review: PARALLEL Clause If you created the ORDERS table using a fast parallel load, you may issue the CREATE INDEX statement shown in the first example in the slide to quickly create an index in parallel. (Oracle Database chooses the appropriate degree of parallelism.) Note that in this case, the default degree of parallelism used to create the index is also stored as the dictionary DOP. The second example changes the dictionary DOP of the CUSTOMERS table. The last example splits the SALES_Q4_2000 partition into two new partitions. This operation is performed in parallel with a DOP explicitly set to two. Note: The TO_DATE() function for the last SQL example was omitted for simplicity reasons, and one should never rely on implicit data type conversion with the DATE data type.
11.2
Goal: Simplifying Parallel Execution

Approaches to applying parallelism prior to Oracle Database 11g Release 2:
Mechanisms were manual, and involved trial and error Required intimate knowledge of SQL and the workload No easy way to run a set of queries with different degree of parallelism values
DBAs tended to restrict use of parallelism to very narrow and highly controlled workloads due to:

Difficulty in enabling parallelism Systemwide impact of specifying an objects degree of parallelism
Automatic parallelism in Oracle Database 11g Release 2: Database server compensates for wrong or missing user settings for parallel execution, ensuring more optimal resource consumption and overall system behavior
Goal: Simplifying Parallel Execution In releases prior to 11g Release 2, Oracle provides various mechanisms to enable parallelism for a given SQL command. All of these mechanisms are manual and require intimate knowledge of both the SQL and the workload. It is a burden for the DBA to decide on the degree of parallelism (DOP) of objects such as tables and indexes. This attribute is used to indicate the DOP of any query touching the objects. For a DBA, it is, therefore, very hard to settle on a good DOP that performs well in any circumstances for any queries on any object sizes. Therefore, this DOP is at best a compromise. Because of the difficulty of enabling parallelism and the systemwide impact of specifying a DOP of an object (it affects all the statements touching it), the DBA might restrict the use of parallelism to very narrow and highly controlled workloads. With automatic parallelism in Oracle Database 11g Release 2, the database server compensates for wrong or missing user settings for parallel execution, ensuring more optimal resource consumption and overall system behavior. Note: This new feature automatically determines the DOP for the parallel query execution client. Other clients such as parallel recovery and parallel replication are not affected.
Running every query with a single degree of parallelism value suboptimal in terms of overall response time
11.2
Automatic Degree Of Parallelism Determination

SQL
1 Generate a serial plan.
DOP determination Serial cost plan
Worse No
Compare estimated parallel elapsed time with estimated serial elapsed time.
Better
Use serial plan.
Use parallel plan.
Automatic Degree Of Parallelism Determination This diagram illustrates the high-level design of the automatic DOP determination. Basically, for a potentially parallel statement, two complete compilation passes are done. One purely serial pass is used to evaluate the cost of the statement and to compute the DOP of each operation if they had to be executed in parallel. The second pass uses this DOP to compute the parallel plan. These two plans are then compared to decide which one is the most efficient (has the best response time). In automatic degree of parallelism, a serial plan is first compiled (step 1). During the serial plan compilation, the cost, in terms of estimated execution elapsed time, of the serial plan is obtained. Also, the best DOP for the statement is computed within 2 and the degree limit set by the parameter PARALLEL_DEGREE_LIMIT. If the serial elapsed time is found to be smaller than the threshold (step 2), determined by the parameter PARALLEL_MIN_TIME_THRESHOLD, the statement will be executed in serial immediately. If the serial elapsed time is found to be greater than the threshold (step 2), a parallel plan will be compiled with the DOP computed (step 3). The parallel plan cost, in terms of estimated execution elapsed time, is obtained and is compared with the serial plan estimated elapsed time. If the parallel elapsed time is considered beneficial over the serial elapsed time (step 4), the statement will be executed in parallel with the computed DOP. Otherwise, the statement will be executed in serial.
If estimated elapsed time > threshold
3
Yes
Use DOP to generate a parallel plan.
11.2
Summary of Changes to Parameters
New Parameters PARALLEL_DEGREE_LIMIT PARALLEL_DEGREE_POLICY PARALLEL_FORCE_LOCAL PARALLEL_MIN_TIME_THRESHOLD
Allowable Values Any number > 1, CPU, IO, AUTO MANUAL, LIMITED, AUTO TRUE, FALSE Any number > 0, AUTO
Default CPU MANUAL FALSE AUTO
Changes to Existing Parameters PARALLEL_THREADS_PER_CPU PARALLEL_IO_CAP_ENABLED
New / Equivalent _PARALLEL_THREADS_PER_CPU PARALLEL_DEGREE_LIMIT (= IO)
Summary of Changes to Parameters This page summarizes the new parameters in Oracle Database 11g Release 2 required for implementation of the simplified parallelism new feature, as well as changes to two existing parameters. These new and changed parameters are examined further on the following pages.
11.2
Using PARALLEL_MIN_TIME_THRESHOLD
Automatic degree of parallelism determines the DOP on a per statement basis rather than using a one-size-fitsall policy. It determines that it is not beneficial for some statements to be executed in parallel.
New Parameters PARALLEL_MIN_TIME_THRESHOLD
Allowable Values any number > 0, AUTO
Default AUTO
Using PARALLEL_MIN_TIME_THRESHOLD One new concept related to simplified parallelism is minimum threshold for parallelism. Even if a SQL statement is deemed a candidate for automatic determination of parallelism, does the parallel overhead justify the cost of this SQL going parallel? The PARALLEL_MIN_TIME_THRESHOLD parameter limits parallelism to only SQL statements for which it is worth the effort. Any SQL that has the computed elapsed time below this threshold will execute in serial. This new parameter indicates the threshold (expressed in seconds) that limits the scope of automatic parallel execution. Only if the estimated serial execution elapsed time of a statement is greater than the threshold, will the statement be a candidate for automatic parallel execution. It accepts any numerical value greater than 0 or a keyword AUTO. When it is set to AUTO, the threshold is computed by the system. Note: PARALLEL_MIN_PERCENT works as in past releases if the estimated elapsed time exceeds PARALLEL_MIN_TIME_THRESHOLD.
This improves the response time of the SQL statement while also making parallel resources available to other more demanding statements. If a query does not warrant parallelism, it is downgraded to serial, based on a user specified cut-off time controlled by the PARALLEL_MIN_TIME_THRESHOLD parameter.
11.2
Using PARALLEL_DEGREE_POLICY
New Parameters PARALLEL_DEGREE_POLICY
Allowable Values MANUAL, LIMITED, AUTO
Default MANUAL
Using PARALLEL_DEGREE_POLICY MANUAL Mode: MANUAL mode exists for backward compatibility. In this mode, it is the responsibility of a DBA to specify the degree of parallelism with object properties name value pairs, if a statement is to be executed in parallel. Statements touching objects with parallel properties name value pairs are executed with a DOP derived directly from the properties name value pairs. This mode is enabled when PARALLEL_DEGREE_POLICY is set to MANUAL. MANUAL mode is the default mode. LIMITED Mode: The degree of parallelism is derived from the elapsed time of the most costly operation during the first serial compilation. To derive the DOP, the optimizer uses a unit of work that can be performed by a slave. This unit is expressed in seconds. (The default is 10s and is controlled by an underscore parameter.) To have access to another slave, an operation needs to require at least that unit of work above the threshold. As an example, if the unit is 10s, the threshold is also 10s and the estimated elapsed time of the operation is 43s, the ideal degree of parallelism will be 4. The optimizer still uses response time to compute the best parallel plan. The DOP is derived from the expected response time of a single operation. The unit of work that a slave should have to efficiently cover for its cost is the quotient used to derive the DOP.
DOP = ElapsedTime(operation)/ parallel_time_unit.
This mode is enabled when the PARALLEL_DEGREE_POLICY parameter is set to LIMITED.

Modes of degree of parallelism computation: MANUAL mode: DBA specifies the degree of parallelism with object decoration (object properties name value pairs), if a statement is to be executed in parallel. LIMITED mode: Statements touching objects with parallel decoration set to default are considered for automatic degree of parallelism optimization. The optimizer derives the DOP for these statements and determines if these statements should be parallel. AUTO mode: Enables automatic degree of parallelism, statement queuing, and in-memory parallel execution.
Using PARALLEL_DEGREE_POLICY (continued) Note: Under MANUAL mode, PARALLEL_MIN_TIME_THRESHOLD, PARALLEL_DEGREE_LIMIT, and PARALLEL_FORCE_LOCAL do not have any effect on the compilation or execution of a statement, unless hint is specified in the statement.
11.2
Using PARALLEL_DEGREE_LIMIT
The maximum degree of parallelism for a statement is capped by the default DOP. In some cases, this DOP might be too high. PARALLEL_DEGREE_LIMIT enables you to specify a maximum DOP.
CPU scan CPU scan CPU scan
Maximum DOP?
New Parameters PARALLEL_DEGREE_LIMIT
Allowable Values Any number > 1, CPU, IO, AUTO
Default CPU
Using PARALLEL_DEGREE_LIMIT Another new concept related to simplified parallelism is maximum degree of parallelism. By default, the maximum degree of parallelism for a statement is capped by the default DOP. In some cases, this DOP might be too high. There is a need to have a limit on the maximum degree of parallelism for all parallel statements in the system to prevent overloading of the system. A new parameter, PARALLEL_DEGREE_LIMIT, allows you to specify the maximum DOP. The allowable values for the parameter are any numerical value greater than or equal to 1, CPU, IO, or AUTO. If the parameter is set to CPU, IO, or AUTO, the degree limit will be automatically computed by the system, based on the system resource constraint. Users are also allowed to set the limit to a fixed value, if they want to limit the degree of parallelism below a certain value for whatever reasons. When PARALLEL_DEGREE_LIMIT is set to AUTO, the threshold is derived by the optimizer. When PARALLEL_DEGREE_LIMIT is set to IO, the threshold is derived from I/O resource constraints. The default value for this parameter is CPU, calculated as follows:
threads_per_cpu * total number of CPUs in the cluster
This control is applicable to LIMITED mode only. The DOP derived either from object decoration directly under manual mode or by the optimizer under limited mode would never exceed the degree limit specified in the control.
CPU scan
Using PARALLEL_DEGREE_LIMIT (continued) Note: If PARALLEL_DEGREE_POLICY is set to MANUAL (the default), the maximum DOP a statement can have is limited by PARALLEL_MAX_SERVERS, as in previous releases. If PARALLEL_DEGREE_POLICY is set to AUTO or LIMITED, the maximum DOP a statement can have is limited by PARALLEL_DEGREE_LIMIT. However, when PARALLEL_DEGREE_POLICY is utilized, the maximum DOP that the Oracle server will choose is DEFAULT_DOP, which is the default value for PARALLEL_DEGREE_LIMIT. It is possible to use a hint to force a greater DOP for a statement, even with PARALLEL_DEGREE_POLICY on.
11.2
Using PARALLEL_FORCE_LOCAL
When PARALLEL_FORCE_LOCAL is set to TRUE, it restricts the allocation of parallel server processes to the node to which the query coordinator is connected in a RAC environment.
New Parameters PARALLEL_FORCE_LOCAL
Allowable Values TRUE, FALSE
Default FALSE
Using PARALLEL_FORCE_LOCAL Within a cluster, the instance with the highest number of CPUs is used to determine the degree limit. Example: In a cluster with two 4-CPU machines, one 2-CPU machine and one 8-CPU machine, 8 is the higher number and is used to compute the degree limit with:
threads per cpu * #cpu
You can enable this feature by setting PARALLEL_FORCE_LOCAL to TRUE.
Parallel statements are executed within a particular instance to avoid any interconnection with other instances. If a user connects to a RAC service that encompasses more than one RAC node, PARALLEL_FORCE_LOCAL restricts the allocation of parallel server processes to whichever node the initial connection was mapped.
11.2
Changes to Existing Parameters
Changes to Existing Parameters One existing parameter has been deprecated and remapped: PARALLEL_IO_CAP_ENABLED is deprecated and remapped to PARALLEL_DEGREE_LIMIT set to IO. One existing parameter has become an underscore parameter: PARALLEL_THREADS_PER_CPU is now _PARALLEL_THREADS_PER_CPU
The following existing parameters have changed in Oracle Database 11g Release 2: PARALLEL_IO_CAP_ENABLED is deprecated and remapped to PARALLEL_DEGREE_LIMIT set to IO PARALLEL_THREADS_PER_CPU has become an underscore parameter: _PARALLEL_THREADS_PER_CPU
11.2
Parallel Hints Are Now at the Statement Level
Parallel Hints Are Now at the Statement Level Parallel execution hints instruct the optimizer about whether and how to parallelize operations. In Oracle Database 11g Release 2, the scope of parallel hints is now at the statement level, superseding whatever parallelism might be specified at table and object level.
The scope of parallel hints is now at the statement level, superseding parallelism specified at table and object level. The PARALLEL_DEGREE_POLICY initialization parameter set to MANUAL (default): Hints beginning with PARALLEL indicate the degree of parallelism for a specified object. PARALLEL_DEGREE_POLICY set to LIMITED: The scope of the PARALLEL hint is the statement, not an object.
11.2
Implication of Statement-Level Parallel Hints
Set parallelism on the EMPLOYEES table to 2 and disable parallelism on the DEPARTMENTS table, as follows:
ALTER TABLE employees PARALLEL 2; ALTER TABLE departments NOPARALLEL;
SELECT /*+ PARALLEL(employees 3) */ e.last_name, d.department_name FROM employees e, departments d WHERE e.department_id=d.department_id;
PARALLEL_DEGREE_POLICY is set to LIMITED, so parallel hint is for statement:

SELECT /*+ PARALLEL(4) */ hr_emp.last_name, d.department_name FROM employees hr_emp, departments d WHERE hr_emp.department_id=d.department_id;
Implication of Statement-Level Parallel Hints Using the parallelism settings given at the top of this slide, the implications of statement-level parallel hints are compared to object-level hints. In the example where PARALLEL_DEGREE_POLICY is set to MANUAL (the default), the parallel hint specifies a degree of parallelism of 3 for EMPLOYEES. The parallel hint applies to the object. This setting overrides the degree of parallelism of 2 specified in the EMPLOYEES table definition. In the example where PARALLEL_DEGREE_POLICY is set to LIMITED, the scope of the parallel hint is the statement, not an object. In this case, the parallel hint forces the statement to execute in parallel. In this example, PARALLEL(4) forces the query of the EMPLOYEES and DEPARTMENTS tables to execute with a degree of parallelism of 4, overriding the parallelism setting defined on the tables. In contrast to most hints, the parallel statement-level hints take precedence over object-level hints.
PARALLEL_DEGREE_POLICY is set to MANUAL, so parallel hint is for object:
11.2
EXPLAIN PLAN Enhancements
EXPLAIN PLAN is modified to show the computed degree of parallelism that the optimizer used. New notes are introduced:
Computed degree of parallelism is <DOP>. Computed degree of parallelism is <DOP> derived from scan of <object name>. Computed degree of parallelism is <DOP> because of degree limit. Computed degree of parallelism is 1 because of parallel threshold. Computed degree of parallelism is 1 because of parallel overhead. Degree of parallelism is <DOP> because of hint.
EXPLAIN PLAN Enhancements In Oracle Database 11g Release 2, the EXPLAIN PLAN output is enhanced to show the computed degree of parallelism that the optimizer used. This computed degree of parallelism is stored by the optimizer as a statement-level annotation (similar to other statement level annotation such as dynamic sampling used or cost-based transformation used) and exposed as a note of the EXPLAIN PLAN. Six new EXPLAIN PLAN notes are introduced.
11.2
Enhanced Explain Plan Example
Parallel hint
Enhanced Explain Plan Example In this example using SQL Developer, the note in the EXPLAIN PLAN output shows the computed degree of parallelism used by the optimizer. Autotrace is enabled, and the note appears in the Script Output tab after executing the script in SQL Developer. In this example, the computed degree of parallelism is 2. It has been derived from a scan of the SCOTT.EMP table.
11.2
In-Memory Parallel Query
In-Memory Parallel Query In some cases, the database server can cache parallel query data in the buffer cache instead of performing direct reads into the PGA. This configuration may be appropriate when the database servers have a large amount of memory. With Oracles new automatic parallelization capabilities (minimal effort parallel execution), the instancewide buffer cache can be used to store and reuse the clusterwide data cache for a single parallel operation, thus minimizing or even completely eliminating the physical I/O for a parallel operation. Parallel Data Cache enables the clusterwide usage of the buffer cache for parallel operations, scaling out the available memory for data caching with the number of nodes in a cluster. This new functionality optimizes the physical I/O requirements, speeding up the processing of large parallel operations. See the Oracle Database Data Warehousing Guide 11g Release 2 for more details about In Memory Parallel Query. See the Oracle Database VLDB and Partitioning Guide 11g Release 2 to learn more about using parallel execution.
New automatic parallelization capabilities enable the instancewide buffer cache to store and reuse the clusterwide data cache for a single parallel operation. Minimizes or even completely eliminates the physical I/O for a parallel operation. Parallel Data Cache enables the clusterwide usage of the buffer cache for parallel operations, scaling out the available memory for data caching with the number of nodes in a cluster. Parallel Data Cache optimizes the physical I/O requirements, speeding up the processing of large parallel operations.
Quiz
Answer: 1
Goals of simplified parallelism include removing the burden of identifying the ideal degree of parallelism for each statement and improving the overall system resource utilization. 1. True 2. False
Oracle Partitioning
Core functionality Performance
Static partition pruning Partitionwise joins Dynamic pruning
Manageability
Basic maintenance operations: add, drop, exchange Merge operation Global index maintenance
Oracle8
Range partitioning Global range indexes Hash and composite range-hash partitioning List partitioning Composite range-list partitioning Global hash indexes 1M partitions per table
More composite choices REF Partitioning Virtual Column Partitioning
Oracle8i Oracle9i Oracle9i R2 Oracle10g Oracle10g R2 Oracle Database 11g
Fast partition split Local Index maintenance Multidimensional pruning Fast drop table Interval Partitioning Partition Advisor
Oracle Partitioning The slide summarizes the ten years of partitioning development at Oracle. Note: REF partitioning enables pruning and partitionwise joins against child tables. While performance seems to be the most visible improvement, do not forget about the rest. Partitioning must address all business-relevant areas of performance, manageability, and availability.
Partitioning Enhancements
Interval partitioning System partitioning Composite partitioning enhancements Virtual column-based partitioning Reference partitioning
Partitioning Enhancements Partitioning is an important tool for managing large databases. Partitioning allows the DBA to employ a divide and conquer methodology for managing database tables, especially as those tables grow. Partitioned tables allow a database to scale for very large data sets while maintaining consistent performance, without unduly impacting administrative or hardware resources. Partitioning enables faster data access within an Oracle database. Whether a database has 10 GB or 10 TB of data, partitioning can speed up data access by orders of magnitude. Oracle Database 11g includes the following partitioning enhancements: Addition of interval partitioning Addition of system partitioning Composite partitioning enhancements Addition of virtual column-based partitioning Addition of reference partitioning
Interval Partitioning
Interval Partitioning Before the introduction of interval partitioning, the DBA was required to explicitly define the range of values for each partition. The problem with this approach is that explicitly defining the bounds for each partition does not scale as the number of partitions grow. Interval partitioning is an extension of range partitioning, which instructs the database server to automatically create partitions of a specified interval when data inserted into the table exceeds all of the range partitions. You must specify at least one range partition. The range partitioning key value determines the high value of the range partitions, which is called the transition point, and the database server creates interval partitions for data beyond that transition point. Interval partitioning fully automates the creation of range partitions. Managing the creation of new partitions can be a cumbersome and highly repetitive task. This is especially true for predictable additions of partitions covering small ranges, such as adding new daily partitions. Interval partitioning automates this operation by creating partitions on demand. When using interval partitioning, consider the following restrictions: You can specify only one partitioning key column, and it must be of NUMBER or DATE type. Interval partitioning is not supported for index-organized tables. You cannot create a domain index on an interval-partitioned table.
Interval partitioning is an extension of range partitioning. Partitions of a specified interval are created when inserted data exceeds all of the range partitions. At least one range partition must be created. Interval partitioning automates the creation of range partitions.
Interval Partitioning: Example

CREATE TABLE SH.SALES_INTERVAL PARTITION BY RANGE (time_id) INTERVAL (NUMTOYMINTERVAL(1,'month')) STORE IN (tbs1,tbs2,tbs3,tbs4) ( PARTITION P1 values less than (TO_DATE('1-1-2002','dd-mm-yyyy')), PARTITION P2 values less than (TO_DATE('1-1-2003','dd-mm-yyyy')), PARTITION P3 values less than (TO_DATE('1-1-2004','dd-mm-yyyy'))) AS SELECT * FROM SH.SALES WHERE TIME_ID < TO_DATE('1-1-2004','dd-mm-yyyy');
Automatically created when you insert data
P1
P2
Range section
P3
Pi1
Pin
Interval section
Transition point
Interval Partitioning: Example Consider the example in the slide, which illustrates the creation of an interval-partitioned table. The original CREATE TABLE statement specifies four partitions with varying widths. This portion of the table is range-partitioned. It also specifies that above the transition point of 1-1-2004, partitions are created with a width of one month. These partitions are interval-partitioned. Partition Pi1 is automatically created using this information when a row with a value corresponding to January 2004 is inserted into the table. The high bound of partition P3 represents a transition point. P3 and all partitions below it (P1 and P2 in this example) are in the range section, while all partitions above it fall into the interval section. The only argument to the INTERVAL clause is a constant of the interval type. Currently, you can specify only one partitioning key column, and it must be of DATE or NUMBER type. You can use the optional STORE IN clause of the INTERVAL clause to specify one or more tablespaces into which the database server will store interval partition data in a round-robin fashion.
Moving the Transition Point: Example

PREVIOUS
< 01/01/07
Transition point
INSERT INTO orders_interval ();
PREVIOUS
< 01/01/07
Not yet materialized Transition point
SYS_Px
< 01/08/07
SYS_Py
< 01/11/07
SYS_Pz
< 01/12/07
SYS_Pt
< 01/03/08
alter table orders_interval merge partitions for(TO_DATE('15-10-2007','dd-mm-yyyy')),for(TO_DATE('15-11-2007','dd-mm-yyyy')) into partition sys_p5z;
PREVIOUS
< 01/01/07
SYS_Px
< 01/08/07
SYS_P5z
< 01/12/07
Transition point
SYS_Pt
< 01/03/08
Moving the Transition Point: Example The graphic in the slide shows you a typical Information Lifecycle Management (ILM) scenario where after one year of automated partition creation, you merge the created partitions (SYS_Py and SYS_Pz in the example) to move the transition point. You can then move the resulting partitions to a different storage for ILM purposes. The example assumes that you created a table called ORDERS_INTERVAL that initially has one range partition called PREVIOUS, which holds orders from before 2007. The interval is defined to be one month. Then during the years 2007 and 2008, some orders are inserted, and it is assumed that four partitions are created. They are shown on the graphic. They are automatically named according to system rules. Then you decide to merge the last two partitions of the year 2007 using the ALTER TABLE statement shown in the slide. You must merge two adjacent partitions. Note the new extended partition syntax that can be used to designate a partition without knowing its name. The syntax uses an expression that must represent a possible value for the partition in question. This syntax works for all cases when you have to reference a partition, whether it be range, list, interval, or hash. It supports all operations such as drop, merge, split, and so on. As a result of your MERGE operation, you can see that the transition point moved. The bottom part of the graphic shows you the new range section that now contains three partitions.
Moving the Transition Point: Example (continued) When you split an interval partition, the operation will also move the transition point to the uppermost endpoint of the new partition created from the split operation. If you drop an interval partition, an insert of data within that interval will recreate the partition. The transition point is unaffected. You can force the creation of an interval partition by locking the partition:
LOCK TABLE orders_interval PARTITION FOR(TO_DATE('14-FEB-2008','dd-mm-yyyy') IN SHARE MODE;
Existing range-partitioned and range-* composite partitioned tables can be migrated to interval partitioned tables by using:
ALTER TABLE table_name SET INTERVAL (interval_value);
Using ALTER TABLE ... SET INTERVAL (); will disable future partitions and turn all partitions into range partitions with their existing endpoints intact. Note: You can change the interval of an interval-partitioned table; the existing intervals remain unaffected.
System Partitioning
System Partitioning System partitioning enables application-controlled partitioning for arbitrary tables. This is mainly useful when you develop your own partitioned domain indexes. The database simply provides the ability to break down a table into meaningless partitions. All other aspects of partitioning are controlled by the application. System partitioning provides the well-known benefits of partitioning (scalability, availability, and manageability), but the partitioning and actual data placement are controlled by the application. The most fundamental difference between system partitioning and other methods is that system partitioning does not have any partitioning keys. Consequently, the distribution or mapping of the rows to a particular partition is not implicit. Instead, the user specifies the partition to which a row maps by using partition-extended syntax when inserting a row. Because system-partitioned tables do not have a partitioning key, the usual performance benefits of partitioned tables are not available for system-partitioned tables. Specifically, there is no support for traditional partition pruning, partitionwise joins, and so on. Partition pruning is achieved by accessing the same partitions in the system-partitioned tables as those that were accessed in the base table. System-partitioned tables provide the manageability advantages of equipartitioning. For example, a nested table can be created as a system-partitioned table that has the same number of partitions as the base table. A domain index can be backed up by a system-partitioned table that has the same number of partitions as the base table.
System partitioning: Enables application-controlled partitioning for selected tables Provides the benefits of partitioning but the partitioning and data placement are controlled by the application Does not employ partitioning keys like other partitioning methods Does not support partition pruning in the traditional sense
System Partitioning: Example
CREATE TABLE PARTITION BY ( PARTITION PARTITION PARTITION PARTITION );
systab (c1 integer, c2 integer) SYSTEM p1 p2 p3 p4 TABLESPACE TABLESPACE TABLESPACE TABLESPACE tbs_1, tbs_2, tbs_3, tbs_4
INSERT INTO systab PARTITION (p1) VALUES (4,5); INSERT INTO systab PARTITION (p2) VALUES (150,2);
alter table systab merge partitions p1,p2 into partition p1;
System Partitioning: Example The syntax in the slide example creates a table with four partitions. Each partition can have different physical attributes. INSERT and MERGE statements must use partition-extended syntax to identify a particular partition that a row should go into. For example, the value (4,5) can be inserted into any one of the four partitions given in the example. Deletes and updates do not require the partition-extended syntax. However, because there is no partition pruning, if the partition-extended syntax is omitted, the entire table is scanned to execute the operation. Again, this example highlights the fact that there is no implicit mapping from rows to any partition.
System Partitioning: Guidelines
INSERT INTO <table_name> PARTITION(<partition-name>) <subquery>
System Partitioning: Guidelines The following operations are supported for system-partitioned tables: Partition maintenance operations and other DDL operations (see exceptions below) Creation of local indexes Creation of local bitmapped indexes Creation of global indexes All DML operations INSERT SELECT with partition-extended syntax. Because of the peculiar requirements of system partitioning, the following operations are not supported for system partitioning: Unique local indexes are not supported because they require a partitioning key. CREATE TABLE AS SELECT is not supported because there is no partitioning method. It is not possible to distribute rows to partitions. Instead, you should first create the table and then insert rows into each partition. SPLIT PARTITION operations
The following operations are supported for systempartitioned tables: Partition maintenance operations and other DDL operations Creation of local indexes Creation of local bitmapped indexes Creation of global indexes All DML operations INSERT SELECT with partition-extended syntax:
11.2
System-Managed Indexes for List Partitioning
System-managed local domain indexes are now supported for list partitioned tables. *_INDEXTYPES views include the PARTITIONING column with values of Y or N, indicating whether or not the indextype supports local domain indexes.
ALTER INDEXTYPE [<schema>.]<indextype_name> WITH LOCAL [RANGE] PARTITION WITH SYSTEM MANAGED STORAGE TABLES
System-Managed Indexes for List Partitioning Domain indexes enable you to define your own domain-specific indexing schemes and plug them into the Oracle Database using Oracles Extensibility Framework. In Oracle Database 11g Release 2, system-managed local domain indexes are supported for list-partitioned tables. An indextype is an object that specifies the routines that manage a domain (application-specific) index. Indextypes reside in the same namespace as tables, views, and other schema objects. The CREATE INDEXTYPE statement binds the indextype name to an implementation type, which in turn specifies and refers to user-defined index functions and procedures that implement the indextype. If you define an indextype with the WITH LOCAL PARTITION and the WITH SYSTEM MANAGED STORAGE TABLES clauses, it can support local domain indexes on range- and list- partitioned tables. The RANGE keyword is no longer required and will be deprecated in a future release. The *_INDEXTYPES family of views has been modified to include the PARTITIONING column with values of Y or N, indicating whether or not the indextype can support local domain indexes.
CREATE INDEXTYPE [<schema>.]<indextype_name> using_type_clause WITH LOCAL [RANGE] PARTITION WITH SYSTEM MANAGED STORAGE TABLES
Virtual ColumnBased Partitioning
Virtual column values are derived by the evaluation of a function or expression. Virtual columns can be defined within a CREATE or ALTER table operation.
Virtual column values are not physically stored in the table row on disk, but are evaluated on demand. Virtual columns can be indexed, and used in queries, DML, and DDL statements like other table column types. Tables and indexes can be partitioned on a virtual column and even statistics can be gathered upon them.
Virtual ColumnBased Partitioning Columns of a table whose values are derived by computation of a function or an expression are known as virtual columns. These columns can be specified during a CREATE or ALTER table operation. Virtual columns share the same SQL namespace as other real table columns and conform to the data type of the underlying expression that describes it. These columns can be used in queries like any other table columns, thereby providing a simple, elegant, and consistent mechanism of accessing expressions in a SQL statement. The values for virtual columns are not physically stored in the table row on disk, rather they are evaluated on demand. The functions or expressions describing the virtual columns should be deterministic and pure, meaning the same set of input values should return the same output values. Virtual columns can be used like any other table columns. They can be indexed, and used in queries, DML, and DDL statements. Tables and indexes can be partitioned on a virtual column and even statistics can be gathered upon them. You can use virtual column partitioning to partition key columns defined on virtual columns of a table. Frequently, business requirements to logically partition objects do not match existing columns in a one-to-one manner. With the introduction of Oracle Database 11g, partitioning has been enhanced to allow a partitioning strategy defined on virtual columns, thus enabling a more comprehensive match of the business requirements.
CREATE TABLE employees (employee_id number(6) not null, total_compensation as (salary *( 1+commission_pct))
Virtual ColumnBased Partitioning: Example
Virtual Column-Based Partitioning: Example Consider the example in the slide. The EMPLOYEES table is created using the standard CREATE TABLE syntax. The TOTAL_COMPENSATION column is a virtual column calculated by multiplying the value of SALARY by the COMMISSION_PCT plus one. The next statement declares TOTAL_COMPENSATION (a virtual column) to be the partitioning key of the EMPLOYEES table. Partition pruning takes place for virtual column partition keys when the predicates on the partitioning key are of the following types: Equality or Like List Range Partition-extended names Given a join operation between two tables, the optimizer recognizes when a partitionwise join (full or partial) is applicable, decides whether to use it or not, and annotates the join properly when it decides to use it. This applies to both serial and parallel cases. In order to recognize full partitionwise joins, the optimizer relies on the definition of equipartitioning of two objects; this definition includes the equivalence of the virtual expression on which the tables were partitioned.
CREATE TABLE employees (employee_id number(6) not null, first_name varchar2(30), last_name varchar2(40) not null, emailvarchar2(25), phone_number varchar2(20), hire_date date not null, job_id varchar2(10) not null, salary number(8,2), commission_pct number(2,2), manager_id number(6), department_id number(4), total_compensation as (salary *( 1+commission_pct)) ) PARTITION BY RANGE (total_compensation) ( PARTITION p1 VALUES LESS THAN (50000), PARTITION p2 VALUES LESS THAN (100000), PARTITION p3 VALUES LESS THAN (150000), PARTITION p4 VALUES LESS THAN (MAXVALUE) );
Reference Partitioning
Reference Partitioning Reference partitioning provides the ability to partition a table based on the partitioning scheme of the table referenced in its referential constraint. The partitioning key is resolved through an existing parent/child relationship, which is enforced by active primary key and foreign key constraints. The benefit of this is that tables with a parent/child relationship can be logically equipartitioned by inheriting the partitioning key from the parent table without duplicating the key columns. The logical dependency also automatically cascades partition maintenance operations, making application development easier and less error prone.
A table can now be partitioned based on the partitioning method of a table referenced in its referential constraint. The partitioning key is resolved through an existing parent/child relationship. The partitioning key is enforced by active primary key and foreign key constraints. Tables with a parent/child relationship can be equipartitioned by inheriting the partitioning key from the parent table without duplicating the key columns. Partitions are automatically maintained.
Reference Partitioning: Benefit

Without using reference partitioning Reference partitioning
Range(ORDER_DATE) Primary key (ORDER_ID)
Table ORDERS
Table ORDER_ITEMS
Range(ORDER_DATE) Foreign key (ORDER_ID)
Redundant storage/maintenance of ORDER_DATE
Partition key inherited through PK/FK relationship
Reference Partitioning: Benefit As illustrated in the slide, you can see the benefit of using reference partitioning. The left part of the graphic shows you the situation where you have two tables, ORDERS and ORDER_ITEMS, that are equipartitioned on the ORDER_DATE column. In that case, both tables need to define the ORDER_DATE column. However, defining ORDER_DATE in the ORDER_ITEMS table is redundant because there is a primary key/foreign key relationship between the two tables. The right part of the graphic shows you the situation where you use reference partitioning. This time, you no longer need to define the ORDER_DATE column in the ORDER_ITEMS table. The partition key of the ORDER_ITEMS table is automatically inherited from the primary key/foreign key relationship that exists. When used for pruning and partitionwise joins, reference partitioning has the benefit that query predicates can be different and partitionwise joins still workfor example, partitioning on ORDER_DATE and search on ORDER_ID. With previous releases, both partitioning and predicates had to be identical for a partitionwise join to work. Note: This partitioning method can be useful for nested table partitioning.
Reference Partitioning: Example

CREATE TABLE orders ( order_id NUMBER(12) , order_date DATE, order_mode VARCHAR2(8), customer_id NUMBER(6), order_status NUMBER(2) , order_total NUMBER(8,2), sales_rep_id NUMBER(6) , promotion_id NUMBER(6), CONSTRAINT orders_pk PRIMARY KEY(order_id) ) PARTITION BY RANGE(order_date) (PARTITION Q105 VALUES LESS THAN (TO_DATE('1-4-2005','DD-MM-YYYY')), PARTITION Q205 VALUES LESS THAN (TO_DATE('1-7-2005','DD-MM-YYYY')), PARTITION Q305 VALUES LESS THAN (TO_DATE('1-10-2005','DD-MM-YYYY')), PARTITION Q405 VALUES LESS THAN (TO_DATE('1-1-2006','DD-MM-YYYY'))); CREATE TABLE order_items ( order_id NUMBER(12) NOT NULL, line_item_id NUMBER(3) NOT NULL, product_id NUMBER(6) NOT NULL, unit_price NUMBER(8,2), quantity NUMBER(8), CONSTRAINT order_items_fk FOREIGN KEY(order_id) REFERENCES orders(order_id) ) PARTITION BY REFERENCE(order_items_fk);
Reference Partitioning: Example The example in the slide creates two tables: ORDERS: Range-partitioned table partitioned on ORDER_DATE. It is created with four partitions, Q105, Q205, Q305, and Q405. ORDER_ITEMS: Reference-partitioned child table: - This table is created with four partitionsQ105, Q205, Q305, and Q405with each containing rows corresponding to ORDERS in the respective parent partition. - If partition descriptors are provided, the number of partitions described must be exactly equal to the number of partitions or subpartitions in the referenced table. - If the parent table is a composite-partitioned table, then the table will have one partition for each subpartition of its parent. - Partition bounds cannot be specified for the partitions of a reference-partitioned table. The partitions of a reference-partitioned table can be named unless there is a conflict with inherited names. In this case, the partition will have a system-generated name. - Partitions of a reference-partitioned table will collocate with the corresponding partition of the parent table, if no explicit tablespace is specified. As with other partitioned tables, you can specify object-level default attributes, and partition descriptors that override objectlevel defaults. - It is not possible to disable the foreign key constraint of a reference-partitioned table. - It is not permitted to add or drop partitions of a reference-partitioned table. However, performing partition maintenance operations on the parent table is automatically cascaded to the child table.
Composite Partitioning Enhancements
Range top level

Range-Range
List top level

List-List List-Hash List-Range
SP1 SP1
RANGE, LIST, INTERVAL

SP1
SP1
SP1
Interval top level

Interval-Range Interval-List Interval-Hash
SP3
SP3
SP3
SP3
SP3
SP4
SP4
SP4
SP4
SP4
LIST, RANGE, HASH
Composite Partitioning Enhancements Before the release of Oracle Database 11g, the only composite partitioning methods supported were range-list and range-hash. With this new release, list partitioning can be a top-level partitioning method for composite partitioned tables giving us list-list, list-hash, list-range, and range-range composite methods. With the introduction of interval partitioning, interval-range, interval-list, and interval-hash are now supported composite partitioning methods. Range-Range Partitioning Composite range-range partitioning enables logical range partitioning along two dimensions; for example, range partition by ORDER_DATE and range subpartition by SHIPPING_DATE. List-Range Partitioning Composite list-range partitioning enables logical range subpartitioning within a given list partitioning strategy; for example, list partition by COUNTRY_ID and range subpartition by ORDER_DATE. List-Hash Partitioning Composite list-hash partitioning enables hash subpartitioning of a list-partitioned object; for example, to enable partitionwise joins. List-List Partitioning Composite list-list partitioning enables logical list partitioning along two dimensions; for example, list partition by COUNTRY_ID and list subpartition by SALES_CHANNEL.
SP2
SP2
SP2
SP2
SP2
Range-Range Partitioning: Example

CREATE TABLE sales ( prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL, time_id DATE NOT NULL, channel_id char(1) NOT NULL, promo_id NUMBER (6) NOT NULL, quantity_sold NUMBER(3) NOT NULL, amount_sold NUMBER(10,2) NOT NULL ) PARTITION BY RANGE (time_id) SUBPARTITION BY RANGE (cust_id) SUBPARTITION TEMPLATE ( SUBPARTITION sp1 VALUES LESS THAN (50000), SUBPARTITION sp2 VALUES LESS THAN (100000), SUBPARTITION sp3 VALUES LESS THAN (150000), SUBPARTITION sp4 VALUES LESS THAN (MAXVALUE) ) ( PARTITION VALUES LESS THAN (TO_DATE('1-4-2007','DD-MM-YYYY')), PARTITION VALUES LESS THAN (TO_DATE('1-7-2007','DD-MM-YYYY')), PARTITION VALUES LESS THAN (TO_DATE('1-8-2007','DD-MM-YYYY')), PARTITION VALUES LESS THAN (TO_DATE('1-1-2008','DD-MM-YYYY')) );
Composite Range-Range Partitioning: Example Composite range-range partitioning enables logical range partitioning along two dimensions. In the example in the slide, the SALES table is created and range-partitioned on TIME_ID. Using a subpartition template, the SALES table is subpartitioned by range using CUST_ID as the subpartition key. Because of the template, all partitions have the same number of subpartitions with the same bounds as defined by the template. If no template is specified, a single default partition bound by MAXVALUE (range) or DEFAULT value (list) is created. Although the example illustrates the range-range methodology, the other new composite partitioning methods use similar syntax and statement structure. All of the composite partitioning methods fully support the existing partition pruning methods for queries involving predicates on the subpartitioning key.
Summary
In this lesson, you should have learned how to: Load data that is stored in compressed files Set parameters for the simplified parallelism implementation Implement the new partitioning methods
This practice covers the following topics: Using new partitioning schemes Getting partitioning advice with SQL Access Advisor
Oracle SecureFiles
Objectives
After completing this lesson, you should be able to: Describe how SecureFiles enhances the performance of large object (LOB) data types Use SQL and PL/SQL APIs to access SecureFiles
Managing Enterprise Information

Organizations need to efficiently and securely manage many types of data: Structured: Simple data, object-relational data Semistructured: XML documents, Word-processing documents Unstructured: Media, medical data, imaging
F PD
Structured
Semistructured
Unstructured
Managing Enterprise Information Today, applications must deal with many kinds of data, broadly classified as structured, semistructured, and unstructured data. The features of large objects (LOBs) allow you to store all these kinds of data in the database as well as in operating system (OS) files that are accessed from the database. The simplicity and performance of file systems have made it attractive to store file data in file systems, while keeping object-relational data in a relational database.
Issues with Existing LOB Implementation

Limitations in LOB sizing Considered mostly write once, read many times data Offered low concurrency of DMLs User-defined version control Uniform CHUNK size:
Scalability issues with Oracle Real Application Clusters (RAC)
Issues with Existing LOB Implementation In Oracle8i, LOB design decisions were made with the following assumptions: LOB instantiation was expected to be several megabytes in size. LOBs were considered mostly write once, read many times type of data. Updates would be rare; therefore, you could version entire chunks for all kinds of updateslarge or small. Few batch processes were expected to stream data. An online transaction processing (OLTP) kind of workload was not anticipated. The amount of undo retained is user-controlled with two parameters PCTVERSION and RETENTION. This is an additional management burden. The CHUNK size is a static parameter under the assumption that LOB sizes are typically uniform. There is an upper limit of 32 KB on CHUNK size. High concurrency writes in Oracle RAC was not anticipated. Since their initial implementation, business requirements have dramatically changed. LOBs are now being used in a manner similar to that of relational data, storing semistructured and unstructured data of all possible sizes. The size of the data can vary from a few kilobytes for an HTML link to several terabytes for streaming video. Oracle file systems that store all the file system data in LOBs experience OLTP-like high concurrency access. As Oracle RAC is being more widely adopted, the scalability issues of Oracle RAC must be addressed. The existing design of LOB space structures does not cater to these new requirements.
Affecting fragmentation Upper size limit
Oracle SecureFiles
Oracle SecureFiles rearchitects the handling of unstructured (file) data, offering entirely new: Disk format
Variable chunk size
Network protocol Versioning and sharing mechanisms Redo and undo algorithms
No user configuration
Space and memory enhancements
Oracle SecureFiles Oracle Database 11g completely reengineers the LOB data type as Oracle SecureFiles, dramatically improving the performance, manageability, and ease of application development. The new implementation also offers advanced, next-generation functionality such as intelligent compression and transparent encryption. With SecureFiles, chunks vary in size from Oracle data block size up to 64 MB. The Oracle Database server attempts to colocate data in physically adjacent locations on disk, thereby minimizing internal fragmentation. By using variable chunk sizes, SecureFiles avoids versioning of large, unnecessary blocks of LOB data. SecureFiles also offer a new client/server network layer allowing for high-speed data transfer between the client and server supporting significantly higher read and write performance. SecureFiles automatically determines the most efficient way for generating redo and undo, eliminating user-defined parameters. SecureFiles automatically determines whether to generate redo and undo for only the change, or create a new version by generating a full redo record. SecureFiles is designed to be intelligent and self-adaptable as it maintains different in-memory statistics that help in efficient memory and space allocation. This provides for easier manageability due to lower number of tunable parameters that are harder to tune with unpredictable loads. Note: LOB implementation available in prior database versions is now referred to as BasicFiles.
Improved input/output
Enabling SecureFiles Storage

Use the DB_SECUREFILE initialization parameter to specify whether or not to treat LOB files as SecureFiles: ALWAYS: Attempts to create all LOBs as SecureFile LOBs but creates any LOBs not in ASSM tablespaces as BasicFile LOBs FORCE: Forces all LOBs created going forward to be SecureFile LOBs PERMITTED: Allows SecureFiles to be created (default) NEVER: Disallows SecureFiles from being created going forward IGNORE: Disallows SecureFiles and ignores any errors that would otherwise be caused by forcing BasicFiles with SecureFiles options
Enabling SecureFiles Storage The DB_SECUREFILE initialization parameter allows database administrators (DBAs) to determine the usage of SecureFiles, where valid values are: ALWAYS: Attempts to create all LOBs as SecureFile LOBs but creates any LOBs not in Automatic Segment Space Management (ASSM) tablespaces as BasicFile LOBs FORCE: Forces all LOBs created going forward to be SecureFile LOBs PERMITTED: Allows SecureFiles to be created (default) NEVER: Disallows SecureFiles from being created going forward IGNORE: Disallows SecureFiles and ignores any errors that would otherwise be caused by forcing BasicFiles with SecureFiles options If NEVER is specified, any LOBs that are specified as SecureFiles are created as BasicFiles. All SecureFiles-specific storage options and features (for example, compression, encryption, and deduplication) cause an exception if used against BasicFiles. BasicFiles defaults are used for any storage options not specified. If ALWAYS is specified, all LOBs created in the system are created as SecureFiles. The LOB must be created in an ASSM tablespace, otherwise an error occurs. Any BasicFiles storage options specified are ignored. The SecureFiles defaults for all storage can be changed using the ALTER SYSTEM command as shown in the slide. You can also use Enterprise Manager to set the parameter from the Server tab > Initialization Parameters link.
SecureFiles: Storage Options

MAXSIZE: Specifies the maximum LOB segment size RETENTION: Specifies the retention policy to use
MAX: Keep old versions until MAXSIZE is reached. MIN: Keep old versions at least MIN seconds. AUTO: Default NONE: Reuse old versions as much as possible.
The following storage clauses do not apply to SecureFiles:

CHUNK, PCTVERSION, FREEPOOLS, FREELISTS, and FREELIST GROUPS
SecureFiles: Storage Options MAXSIZE is a new storage clause governing the physical storage attribute for SecureFiles. MAXSIZE specifies the maximum segment size related to the storage clause level. RETENTION signifies the following for SecureFiles: MAX is used to start reclaiming old versions after segment MAXSIZE is reached. MIN keeps old versions for the specified least amount of time. AUTO is the default setting, which is basically a trade-off between space and time. This is automatically determined. NONE reuses old versions as much as possible. Altering the RETENTION with the ALTER TABLE statement affects the space created only after the statement is executed. For SecureFiles, you no longer need to specify CHUNK or PCTVERSION. Because SecureFiles are stored in ASSM tablespaces FREEPOOLS, FREELISTS, and FREELIST GROUPS cannot be specified. For compatibility with existing scripts, these clauses are parsed but not interpreted.
SecureFiles: Advanced Features

Oracle SecureFiles offers the following advanced capabilities:
Intelligent LOB compression (requires Advanced Compression Option) Deduplication (requires Advanced Compression Option) Transparent encryption (requires Advanced Security Option)
These capabilities leverage the security, reliability, and scalability of the database.
SecureFiles: Advanced Features Oracle SecureFiles implementation also offers advanced, next-generation functionality such as intelligent compression and transparent encryption. Compression enables you to explicitly compress SecureFiles. SecureFiles transparently uncompresses only the required set of data blocks for random read or write access, automatically maintaining the mapping between uncompressed and compressed offsets. If the compression level is changed from MEDIUM to HIGH, the mapping is automatically updated to reflect the new compression algorithm. Deduplication automatically detects duplicate SecureFile LOB data and conserves space by storing only one copyimplementing disk storage, I/O, and redo logging savings. Deduplication can be specified at the table level or partition level and does not span across partitioned LOBs. Deduplication requires the Advanced Compression Option. Encrypted LOB data is now stored in place and is available for random reads and writes offering enhanced data security. SecureFile LOBs can be encrypted only on a per-column basis (same as Transparent Data Encryption). All partitions within a LOB column are encrypted using the same encryption algorithm. BasicFiles data cannot be encrypted. SecureFiles supports the industrystandard encryption algorithms: 3DES168, AES128, AES192 (default), and AES256. Encryption is part of the Advanced Security Option. Note: The COMPATIBLE initialization parameter must be set to 11.0.0.0.0 or later to use SecureFiles. The BasicFiles (previous LOB) format is still supported under 11.1.0.0.0 compatibility. There is no downgrade capability after 11.0.0.0.0 is set.
Creating SecureFiles
CREATE TABLE func_spec( id number, doc CLOB ENCRYPT USING 'AES128' ) LOB(doc) STORE AS SECUREFILE (DEDUPLICATE LOB CACHE NOLOGGING); CREATE TABLE test_spec ( id number, doc CLOB) LOB(doc) STORE AS SECUREFILE (COMPRESS HIGH KEEP_DUPLICATES CACHE NOLOGGING); CREATE TABLE design_spec (id number, doc LOB(doc) STORE AS SECUREFILE (ENCRYPT); CLOB)
CREATE TABLE design_spec (id number, doc CLOB ENCRYPT) LOB(doc) STORE AS SECUREFILE;
Creating SecureFiles You create SecureFiles with the storage keyword SECUREFILE in the CREATE TABLE statement with a LOB column. When you add a LOB column to a table, you can specify whether it should be created as SecureFiles or BasicFiles. If you do not specify the storage type, the LOB is created as BasicFiles to ensure backward compatibility. In the first example in the slide, you create a table called FUNC_SPEC to store documents as SecureFiles. Here you are specifying that you do not want duplicates stored for the LOB, that the LOB should be cached when read, and that redo should not be generated when updates are performed to the LOB. In addition, you are specifying that the documents stored in the DOC column should be encrypted using the AES128 encryption algorithm. KEEP_DUPLICATES is the opposite of DEDUPLICATE, and can be used in an ALTER statement. In the second example you are creating a table called TEST_SPEC that stores documents as SecureFiles. For this table you have specified that duplicates may be stored, and that the LOBs should be stored in compressed format and should be cached but not logged. Additional information on compression is provided later in the lesson. The third and fourth examples above affect the same result: creating a table with a SecureFiles LOB column using the default AES192 encryption.
Creating SecureFiles Using Enterprise Manager
Creating SecureFiles Using Enterprise Manager You can use Enterprise Manager to create SecureFiles from the Schema tab > Tables link. After you click the Create button, you can click the Advanced Attributes button against the column you are storing as a SecureFile, to enter any SecureFiles options. The LOB implementation available in prior versions is still supported for backward compatibility reasons and is now referred to as BasicFiles. If you add a LOB column to a table, you can specify whether it should be created as a SecureFile or a BasicFile. If you do not specify the storage type, the LOB is created as a BasicFile to ensure backward compatibility. You can select the following as values for the Cache option: CACHE: Oracle places LOB pages in the buffer cache for faster access. NOCACHE: As a parameter in the STORE AS clause, NOCACHE specifies that LOB values are not brought into the buffer cache. CACHE READS: LOB values are brought into the buffer cache only during read and not during write operations. NOCACHE is the default for both SecureFile and BasicFile LOBs.
Shared I/O Pool
LOB Cache
Direct I/O Buffer Cache Shared I/O Pool
Block-size buffers Shared I/O Pool buffers
Memory Allocation
Shared I/O Pool The Shared I/O Pool memory component is added in Oracle Database 11g to support large I/Os from shared memory, as opposed to Program Global Area (PGA), for direct path access. This is only when SecureFiles are created as NOCACHE (the default). The Shared I/O Pool defaults to zero in size and, only if there is SecureFiles NOCACHE workload, the system increases its size to 4% of cache. Because this is a shared resource, it may get used by large concurrent SecureFiles workloads. Unlike other pools, such as the large pool or shared pool, the user process will not generate a ORA-04031 error but will fall back to the PGA temporarily until more shared I/O pool buffers get freed. The LOB Cache is a new component in the SecureFiles architecture, improving LOB access performance by gathering and batching data as well as overlapping network and disk I/O. The LOB Cache borrows memory from the buffer cacheeither regular buffers or memory from the Shared I/O Pool. Because memory borrowed from buffer cache buffers is naturally suitable for doing database I/Os as well as suitable for injecting back into the buffer cache after I/Os have been done, unnecessary copying of memory can be avoided. In multi-instance Oracle Real Application Clusters, the LOB Cache holds one single lock for each of the LOB accessed.
Altering SecureFiles
ALTER TABLE t1 MODIFY LOB(a) ( KEEP_DUPLICATES ); ALTER TABLE t1 MODIFY LOB(a) ( DEDUPLICATE LOB );
Disable deduplication. Enable deduplication.
Enable partition ALTER TABLE t1 deduplication. MODIFY PARTITION p1 LOB(a) ( DEDUPLICATE LOB );
ALTER TABLE t1 MODIFY LOB(a) ( NOCOMPRESS ); ALTER TABLE t1 MODIFY LOB(a) (COMPRESS HIGH);
Disable compression. Enable compression.
ALTER TABLE t1 MODIFY PARTITION p1 LOB(a) ( COMPRESS HIGH );
Enable encryption using 3DES168. ALTER TABLE t1 MODIFY ( a CLOB ENCRYPT USING '3DES168');
ALTER TABLE t1 MODIFY PARTITION p1 ( LOB(a) ( ENCRYPT );
Enable encryption on partition. Enable encryption and build the encryption key using a password.
ALTER TABLE t1 MODIFY ( a CLOB ENCRYPT IDENTIFIED BY ghYtp);
Altering SecureFiles Using the DEDUPLICATE option, you can specify that LOB data that is identical in two or more rows in a LOB column should share the same data blocks. The opposite of this is KEEP_DUPLICATES. Oracle uses a secure hash index to detect duplication and combines LOBs with identical content into a single copy, reducing storage and simplifying storage management. The LOB keyword is optional and is for syntactic clarity only. The COMPRESS or NOCOMPRESS keywords enable or disable LOB compression, respectively. All LOBs in the LOB segment are altered with the new compression setting. Additional information on compression is provided later in the lesson. The ENCRYPT or DECRYPT keyword turns on or off LOB encryption using Transparent Data Encryption (TDE). All LOBs in the LOB segment are altered with the new setting. A LOB segment can be altered only to enable or disable LOB encryption. That is, ALTER cannot be used to update the encryption algorithm or the encryption key. The encryption algorithm or encryption key can be updated using the ALTER TABLE REKEY syntax. Encryption is done at the block level allowing for better performance (smallest encryption amount possible) when combined with other options. Note: For a full description of the options available for the ALTER TABLE statement, see the Oracle Database SQL Reference.
Enable compression on SecureFiles within a single partition.
Quiz
Which of the following are features of SecureFiles? 1. Chunks vary in size from Oracle data block size up to 64 MB. 2. Versioning of large, unnecessary blocks of LOB data is required. 3. Oracle Database server attempts to co-locate data in physically adjacent locations on disk. 4. All LOBs are created as SecureFile LOBs.
Answers: 1 and 3
What Is SecureFile Compression?

SecureFile Compression provides maximized storage utilization by compressing unstructured data stored within the database. Benefits: Lowers total cost of ownership; less disk space needed Reduced I/O; compression performed on server side Reduced CPU utilization when enabled along with encryption
What Is SecureFile Compression? SecureFile Compression is one of the advanced options available with SecureFiles. It provides the capability to maximize storage utilization by compressing unstructured data stored within the database. SecureFile Compression is performed on the server, is transparent to the user and provides efficient random access. Although disk costs are on the downward spiral, server disk space is not inexpensive. Compression can reduce total cost of ownership (TCO) significantly. Compression also provides intangible benefits such as reduced I/O and reduced CPU utilization when enabled along with encryption. SecureFile Compression is available with the Oracle Database 11g Advanced Compression option. This option includes a comprehensive set of compression capabilities to help you maximize resource utilization and reduce costs for all types of datarelational, unstructured, and backup data.
11.2
Compression Modes
In Oracle Database 11g Release 1, two modes for SecureFile compression:
MEDIUM (Default) HIGH
Faster performance during writes Faster performance during reads Lower compression compared to other modes
Compression Modes In Oracle Database 11g Release 1, there were two modes of SecureFile compression: HIGH and MEDIUM. HIGH compression provides maximum compression. It is useful for databases that are CPU intensive and have a relatively higher latency. MEDIUM compression mode provides lower compression than HIGH mode. It is useful for databases that have a lower latency compared to HIGH mode databases. MEDIUM compression is the default compression mode if not specified. In Oracle Database 11g Release 2, a new mode of SecureFile compression is introduced: LOW. This mode of compression is recommended for customers who want faster performance during reads and writes.
In Oracle Database 11g Release 2, a new SecureFile compression mode, LOW, is available. LOW mode is recommended for customers who want:
11.2
Creating a SecureFile LOB with LOW Compression

Create a tablespace for the LOB data:
CREATE TABLESPACE tbs1 DATAFILE 'tbs1.dbf' SIZE 1500M REUSE AUTOEXTEND ON NEXT 200M MAXSIZE 3000M SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLE profiles (id NUMBER, first_name VARCHAR2 (40), last_name VARCHAR2 (80), profile_info BLOB) LOB(profile_info) STORE AS SECUREFILE (TABLESPACE tbs1 COMPRESS LOW);
Creating a SecureFile LOB with LOW Compression To create a column to hold a LOB that is a SecureFile, you: Create a tablespace to hold the data Define a table that contains a LOB column data type that is used to store the data in the SecureFile format Specify the COMPRESS LOW option In the example shown in the slide: 1. The TBS1 tablespace is defined. This tablespace stores the LOB data in the SecureFile format. When you define a column to hold SecureFile data, you must have Automatic Segment Space Management (ASSM) enabled for the tablespace in order to support SecureFiles. 2. The PROFILES table is created. The PROFILE_INFO column holds the LOB data in the SecureFile format. The COMPRESS LOW option indicates the data will be compressed more quickly when data is written and also decompressed more quickly when read.
Create a table to hold the LOB data with COMPRESS LOW:
11.2
Configuration Parameters
To force the I/O to go to disk and avoid file system buffering, use the FILESYSTEMIO_OPTIONS parameter:
ALTER SESSION SET filesystemio_options=setall;
Configuration Parameters To optimize performance, you can force the I/O to be written to disk and avoid file system buffering by setting the FILESYSTEMIO_OPTIONS parameter to SETALL.
Quiz
Which of the following tasks would you need to perform to write LOB data into the database? 1. Create a table with a LOB column. 2. Create a procedure that selects the LOB column information. 3. Set the FILESYSTEMIO_OPTIONS parameter. 4. Use DBMS_LOB.LOADFROMFILE to insert the LOB data.
Answer: 4
Accessing SecureFiles Metadata

The data layer interface is the same as with BasicFiles.
DBMS_LOB
GETOPTIONS() SETOPTIONS
SecureFiles
DBMS_SPACE.SPACE_USAGE
Accessing SecureFiles Metadata DBMS_LOB package: LOBs inherit the LOB column settings for deduplication, encryption, and compression, which can also be configured on a per-LOB level using the LOB locator API. However, the LONG API cannot be used to configure these LOB settings. You must use the following DBMS_LOB package additions for these features: DBMS_LOB.GETOPTIONS: Settings can be obtained using this function. An integer corresponding to a predefined constant based on the option type is returned. DBMS_LOB.SETOPTIONS: This procedure sets features and allows the features to be set on a per-LOB basis, overriding the default LOB settings. It incurs a round-trip to the server to make the changes persistent. DBMS_SPACE.SPACE_USAGE: The existing SPACE_USAGE procedure is overloaded to return information about LOB space usage. It returns the amount of disk space in blocks used by all the LOBs in the LOB segment. This procedure can be used only on tablespaces created with ASSM and does not treat LOB chunks belonging to BasicFiles as used space. Note: For further details, see the Oracle Database PL/SQL Packages and Types Reference.
Migrating to SecureFiles
Use online redefinition.
SecureFiles
Migrating to SecureFiles A superset of LOB interfaces allows easy migration from BasicFile LOBs. The two recommended methods for migration to SecureFiles are partition exchange and online redefinition. Partition Exchange Needs additional space equal to the largest of the partitions in the table Can maintain indexes during the exchange Can spread the workload out over several smaller maintenance windows Requires that the table or partition needs to be offline to perform the exchange Online Redefinition (recommended practice) No need to take the table or partition offline Can be done in parallel Requires additional storage equal to the entire table and all LOB segments to be available Requires that any global indexes be rebuilt These solutions generally mean using twice the disk space used by the data in the input LOB column. However, using partitioning and taking these actions on a partition-by-partition basis may help lower the disk space required.
SecureFiles Migration: Example

create table tab1 (id number not null, c clob) partition by range(id) (partition p1 values less than (100) tablespace tbs1 lob(c) store as lobp1, partition p2 values less than (200) tablespace tbs2 lob(c) store as lobp2, partition p3 values less than (300) tablespace tbs3 lob(c) store as lobp3);
Insert your data.

create table tab1_tmp (id partition by range(id) (partition p1 values less partition p2 values less partition p3 values less number not null, c clob)
begin dbms_redefinition.start_redef_table('scott','tab1','tab1_tmp','id id, c c'); dbms_redefinition.copy_table_dependents('scott','tab1','tab1_tmp',1, true,true,true,false,error_count); dbms_redefinition.finish_redef_table('scott','tab1','tab1_tmp'); end;
SecureFiles Migration: Example The example in the slide can be used to migrate BasicFile LOBs to SecureFile LOBs. First, you create your table using BasicFiles. The example uses a partitioned table. Then, you insert data in your table. Following this, you create a transient table that has the same number of partitions but this time using SecureFiles. Note that this transient table has the same columns and types. The last section demonstrates the redefinition of your table using the previously created transient table with the DBMS_REDEFINITION procedure.
than (100) tablespace tbs1 lob(c) store as securefile, than (200) tablespace tbs2 lob(c) store as securefile, than (300) tablespace tbs3 lob(c) store as securefile);
SecureFiles Monitoring
The following views have been modified for showing SecureFiles usage: *_SEGMENTS *_LOBS *_LOB_PARTITIONS *_PART_LOBS
SQL> 2 3 4 5 SELECT segment_name, segment_type, segment_subtype FROM dba_segments WHERE tablespace_name = 'SECF_TBS2' AND segment_type = 'LOBSEGMENT' / SEGMENT_SU ---------SECUREFILE
SEGMENT_NAME SEGMENT_TYPE ---------------------------- -----------------SYS_LOB0000071583C00004$$ LOBSEGMENT
Summary
In this lesson, you should have learned how to use: SecureFiles to improve LOB performance SQL and PL/SQL APIs to access SecureFiles
This practice covers exploring the advantages of using SecureFiles for compression, data encryption, and performance.
Security and Networking Enhancements

Objectives
After completing this lesson, you should be able to: Configure the password file to use case-sensitive passwords Explain default auditing Encrypt a tablespace Configure fine-grained access to network services Explain how Oracle Net supports IPv6
Secure Password Support
Passwords in Oracle Database 11g:

Are case-sensitive Contain multibyte characters without being enclosed in quotation marks Use more secure hash algorithm Use salt in the hash algorithm
Usernames are still Oracle identifiers (up to 30 characters, non-case-sensitive).
Secure Password Support You must use more secure passwords to meet the demands of compliance with various security and privacy regulations. Passwords that are very short and passwords that are formed from a limited set of characters are susceptible to brute force attacks. Longer passwords with additional allowed characters make the password much more difficult to guess or find. In Oracle Database 11g, the password is handled differently than in previous versions: Passwords are case-sensitive. Uppercase and lowercase characters are now different characters when used in a password. A password may contain multibyte characters without it being enclosed in quotation marks. A password must be enclosed in quotation marks if it contains any special characters apart from $, _, or #. Passwords are always passed through a hash algorithm, and then stored as a user credential. When the user presents a password, it is hashed and then compared to the stored credential. In Oracle Database 11g, the hash algorithm is SHA-1 of the public algorithm used in previous versions of the database. SHA-1 is a stronger algorithm using a 160-bit key. Passwords always use salt. A hash function always produces the same output, given the same input. Salt is a unique (random) value that is added to the input to ensure that the output credential is unique.
Automatic Secure Configuration
Default password profile Default auditing Built-in password complexity checking
Automatic Secure Configuration Oracle Database 11g is installed with and the database is created with certain security features recommended by the Center for Internet Security (CIS) benchmark. The CIS recommended configuration is more secure than the 10gR2 default installation; yet open enough to allow the majority of applications to be successful. Many customers have adopted this benchmark already. There are some recommendations of the CIS benchmark that may be incompatible with some applications.
Password Configuration
By default:
Default password profile is enabled Account is locked after 10 failed login attempts
In upgrade:
On creation:
Passwords are case-sensitive
Secure Default Configuration When creating a custom database using the Database Configuration Assistant (DBCA), you can specify the Oracle Database 11g default security configuration. By default, if a user tries to connect to an Oracle instance multiple times using an incorrect password, the instance delays each login after the third try. This protection applies for attempts made from different IP addresses or multiple client connections. Later, it gradually increases the time before the user can try another password, up to a maximum of about ten seconds. The default password profile is enabled with these settings at database creation:
PASSWORD_LIFE_TIME 180 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1 PASSWORD_VERIFY_FUNCTION NULL
When an Oracle Database 10g database is upgraded, passwords are not case-sensitive until the ALTER USER command is used to change the password. When the database is created, the passwords will be case-sensitive by default.
Passwords are not case-sensitive until changed Passwords become case-sensitive when the ALTER USER command is used
Enable Built-in Password Complexity Checker
Execute the utlpwdmg.sql script to create the password verify function and alter the default profile:
SQL> CONNECT / as SYSDBA SQL> @?/rdbms/admin/utlpwdmg.sql
Enable Built-in Password Complexity Checker VERIFY_FUNCTION_11G is a sample PL/SQL function that can be easily modified to enforce the password complexity policies at your site. This function does not require special characters to be embedded in the password. Both VERIFY_FUNCTION_11G and the older VERIFY_FUNCTION are included in the utlpwdmg.sql file. To enable the password complexity checking, create a verification function owned by SYS. Use one of the supplied functions or modify one of them to meet your requirements. The example shows how to use the utlpwdmg.sql script. If there is an error in the password complexity check function named in the profile or it does not exist, you cannot change passwords nor can you create users. The solution is to set the PASSWORD_VERIFY_FUNCTION to NULL in the profile, until the problem is solved. The VERIFY_FUNCTION_11G function checks that the password contains at least eight characters; contains at least one number and one alphabetic character; and differs from the previous password by at least three characters. The function also checks that the password is not a username or username appended with any number 1100; a username reversed; a server name or server name appended with 1100; or one of a set of well-known and common passwords such as welcome1, database1, oracle123, or oracle (appended with 1100), and so on.
Managing Default Audits
Review audit logs: Default audit options include important security privileges. Archive audit records:
Export Copy to another table
Managing Default Audits Review the audit logs. By default, auditing is enabled in Oracle Database 11g for certain privileges that are very important to security. The audit trail is recorded in the database AUD$ table by default; the AUDIT_TRAIL parameter is set to DB. These audits should not have a large impact on database performance, for most sites. Oracle recommends the use of OS audit trail files. Archive audit records. To retain audit records, export them using Oracle Data Pump Export, or use the SELECT statement to capture a set of audit records into a separate table. Remove archived audit records. Remove audit records from the SYS.AUD$ table after reviewing and archiving them. Audit records take up space in the SYSTEM tablespace. If the SYSTEM tablespace cannot grow, and there is no more space for audit records, errors will be generated for each audited statement. Because CREATE SESSION is one of the audited privileges, no new sessions may be created except by a user connected as SYSDBA. Archive the audit table with the export utility, using the QUERY option to specify the WHERE clause with a range of dates or SCNs. Then delete the records from the audit table by using the same WHERE clause. When AUDIT_TRAIL=OS, separate files are created for each audit record in the directory specified by AUDIT_FILE_DEST. All files as of a certain time can be copied, and then removed. Note: The SYSTEM tablespace is created with the autoextend on option. So the SYSTEM tablespace grows as needed until there is no more space available on the disk.
Remove archived audit records.
Audited Privileges
Privileges that are audited for all users ON SUCCESS and FAILURE, and BY ACCESS:
CREATE EXTERNAL JOB ALTER/DROP PROFILE ALTER/CREATE/DROP USER CREATE SESSION
CREATE ANY JOB
ALTER/CREATE/DROP ANY PROCEDURE ALTER DATABASE
GRANT ANY OBJECT PRIVILEGE EXEMPT ACCESS POLICY CREATE ANY LIBRARY
AUDIT SYSTEM
GRANT ANY ROLE
ALTER SYSTEM
CREATE PUBLIC DATABASE LINK ALTER/CREATE/DROP ANY TABLE
SYSTEM AUDIT
GRANT ANY PRIVILEGE
ROLE
Audited Privileges The privileges listed on the slide are audited for all users ON SUCCESS and FAILURE, and BY ACCESS.
Setting Security Parameters
Use case-sensitive passwords:

SEC_CASE_SENSITIVE_LOGON
Protect against DoS attacks:

SEC_PROTOCOL_ERROR_FURTHER_ACTION SEC_PROTOCOL_ERROR_TRACE_ACTION SEC_MAX_FAILED_LOGIN_ATTEMPTS
Setting Security Parameters A set of new initialization parameters has been added to Oracle Database 11g to enhance the default security of the database. These parameters are systemwide and static. Use Case-Sensitive Passwords to Improve Security A new parameter, SEC_CASE_SENSITIVE_LOGON, allows you to set the case-sensitivity of user passwords. Oracle recommends that you retain the default setting of TRUE. You can specify noncase-sensitive passwords for backward compatibility by setting this parameter to FALSE:
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE
Note: Disabling case-sensitivity increases vulnerability to brute force attacks. Protect Against Denial of Service (DoS) Attacks The two parameters listed in the slide specify the actions to be taken when the database receives bad packets from a client. The assumption is that the bad packets are from a possible malicious client. The SEC_PROTOCOL_ERROR_FURTHER_ACTION parameter specifies what action is to be taken with the client connection: continue, drop the connection, or delay accepting requests. The other parameter, SEC_PROTOCOL_ERROR_TRACE_ACTION, specifies a monitoring action: NONE, TRACE, LOG, or ALERT. These parameters are applicable for Oracle Call Interface (OCI) clients.
Protect against brute force attacks:
Setting Security Parameters (continued) Protect Against Brute Force Attacks You can set limits on the number of times an unauthorized user attempts to log in to Oracle Call Interface (OCI) applications by using the SEC_MAX_FAILED_LOGIN_ATTEMPTS initialization parameter. SEC_MAX_FAILED_LOGIN_ATTEMPTS, which has a default setting of 10, causes a connection to be automatically dropped after the specified number of attempts. This parameter is enforced even when the password profile is not enabled. This parameter prevents a program from making a database connection and then attempting to authenticate by trying hundreds or thousands of passwords. You can set limits on the number of times an unauthorized user (possibly an intruder) attempts to log in to Oracle Call Interface (OCI) applications by using the SEC_MAX_FAILED_LOGIN_ATTEMPTS initialization parameter.
Setting Database Administrator Authentication
Use password file with case-sensitive passwords. Enable strong authentication for administrator roles:
Grant the administrator role in OID. Use Kerberos tickets. Use certificates with SSL.
Setting Database Administrator Authentication The database administrator must always be authenticated. In Oracle Database 11g, there are new methods that make administrator authentication more secure and centralize the administration of these privileged users. Case-sensitive passwords have also been extended to remote connections for privileged users. You can override this default behavior with the following command:
orapwd file=orapworcl entries=5 ignorecase=Y
If your concern is that the password file might be vulnerable or that the maintenance of many password files is a burden, then strong authentication can be implemented: Grant SYSDBA, or SYSOPER enterprise role in Oracle Internet Directory (OID). Use Kerberos tickets Use certificates over SSL To use any of the strong authentication methods, the LDAP_DIRECTORY_SYSAUTH initialization parameter must be set to YES. Set this parameter to NO to disable the use of strong authentication methods. Authentication through OID or through Kerberos also can provide centralized administration or single sign-on. If the password file is configured, it is checked first. The user may also be authenticated by the local OS by being a member of the OSDBA or OSOPER groups. For more information, see the Oracle Database Advanced Security Administrators Guide.
Set LDAP_DIRECTORY_SYSAUTH to YES to use any of the strong authentication methods.
Quiz
Which of the following statements are true about secure password support in Oracle Database 11g? 1. Passwords always use salt. 2. Passwords are case-sensitive. 3. Passwords containing $, _, or # must be enclosed within quotation marks. 4. Passwords containing multibyte characters do not need to be enclosed within quotation marks.
Transparent Data Encryption
Transparent Data Encryption Several new features enhance the capabilities of Transparent Data Encryption (TDE), and build on the same infrastructure. The changes in LogMiner to support TDE provide the infrastructure for change capture engines used for logical standby databases, Streams, and Asynchronous Change Data Capture. For LogMiner to support TDE, it must be able to access the encryption wallet. To access the wallet, the instance must be mounted and the wallet open. LogMiner does not support Hardware Security Module (HSM) or user-held keys. For logical standby databases, the logs may be mined either on the source or the target database, thus the wallet must be the same for both databases. Encrypted columns are handled the same way in both Streams and the Streams-based Change Data Capture. The redo records are mined at the source, where the wallet exists. The data is transmitted unencrypted to the target and encrypted using the wallet at the target. The data can be encrypted in transit by using Advanced Security Option to provide network encryption.
New features in TDE include: Tablespace Encryption Support for LogMiner Support for logical standby databases Support for Streams Support for Asynchronous Change Data Capture Hardware-based master key protection
Hardware Security Module
Encrypt and decrypt operations are performed on the hardware security module.
Hardware Security Module
Encrypted data
Client
Database server
Hardware Security Module Hardware Security Module (HSM) is a physical device that provides secure storage for encryption keys. It also provides secure computational space (memory) to perform encryption and decryption operations. HSM is a more secure alternative to the Oracle wallet. Transparent Data Encryption (TDE) can use an HSM to provide enhanced security for sensitive data. An HSM is used to store the master encryption key used for TDE. The key is secure from unauthorized access attempts because the HSM is a physical device and not an operating system file. All encryption and decryption operations that use the master encryption key are performed inside the HSM. This means that the master encryption key is never exposed in insecure memory. There are several vendors that provide Hardware Security Modules. The vendor must also supply the appropriate libraries.
Using Tablespace Encryption
Create an encrypted tablespace. 1. Create the key in the encryption wallet:

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "welcome1";
2. Create a tablespace with the encryption keywords:

SQL> 2> 3> 4> CREATE TABLESPACE encrypt_ts DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100M ENCRYPTION USING '3DES168' DEFAULT STORAGE (ENCRYPT);
Tablespace Encryption Tablespace encryption is based on block-level encryption that encrypts on write and decrypts on read. The data is not encrypted in memory. The only encryption penalty is associated with I/O. The SQL access paths are unchanged and all data types are supported. To use tablespace encryption, the encryption wallet must be open. The CREATE TABLESPACE command has an ENCRYPTION clause that sets the encryption properties, and an ENCRYPT storage parameter that causes the encryption to be used. You specify USING 'encrypt_algorithm' to indicate the name of the algorithm to be used. Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES128. You can view the properties in the V$ENCRYPTED_TABLESPACES view. The encrypted data is protected during operations such as JOIN and SORT. This means that the data is safe when it is moved to temporary tablespaces. Data in undo and redo logs is also protected. Encrypted tablespaces are transportable if the platforms have same endianess and the same wallet. Restrictions Temporary and undo tablespaces cannot be encrypted. (Selected blocks are encrypted.) Bfiles and external tables are not encrypted. Transportable tablespaces across different endian platforms are not supported.
11.2
Tablespace Encryption New Features

Tablespace Encryption Features Tablespace Master Key Pre-11.2.0 TDE tablespace encryption master key is separate from TDE column encryption master key Not possible 11.1.0.6: Wallet ONLY; 11.1.0.7: TDE tablespace encryption MK created and stored in HSM 11.2.0 Unified Master Key *
Regenerate Master key ESM use
Use ALTER SYSTEM Store Master key in HSM or wallet
* Master key for 11.1.0 encrypted tablespaces will be converted to a unified key with the ALTER SYSTEM SET ENCRYPTION KEY command.
Tablespace Encryption New Features Oracle Database 11g Release 2 uses a unified master encryption key for TDE. When the compatibility is set to 11.2.0 or above, regenerating the master key causes a single master key for both the tablespace and column encryption to be generated. One key is used for both. Prior to 11.2.0, the tablespace master key was a separate key from the column master key. Also, regenerating the tablespace master key was not possible before 11.2.0. If you were using tablespace encryption in Oracle Database 11g Release 1 and have upgraded the database to 11g Release 2, when you issue the ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key will be created for column encryption and tablespace encryption. When you reset the master encryption key for either, the master encryption key is reset for both. In Oracle Database 11g Release 1 (11.1.0.7), the master key for tablespace encryption could be created and stored in an HSM. Prior to Release 11.1.0.7, the tablespace master key could be stored only in a wallet. For security reasons, a tablespace cannot be encrypted with the NO SALT option. You cannot encrypt an existing tablespace. However, you can import data into an encrypted tablespace using the Oracle Data Pump utility. You can also use SQL commands such as CREATE TABLE AS SELECT or ALTER TABLE MOVE to move data into an encrypted tablespace. The CREATE TABLE AS SELECT command enables you to create a table from an existing table. The ALTER TABLE MOVE command enables you to move a table into the encrypted tablespace.
11.2
Tablespace Master Key Re-Key
Regenerating the master key: Creates a new master key in wallet or HSM Keeps retired master keys
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<password>";
Tablespace Master Key Re-Key In Oracle Database 11g Release 2, Oracle Advanced Security enables customers to change the master key used to protect the tablespace encryption keys. In a normal operation, you need to regenerate the master key only if it has been compromised. Changing the master periodically may be required by regulation. Change the master key with the following command: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<password>"; where password is the wallet password. The master key is generated using a random number generator. Regenerating the master key does not cause the data to be reencrypted. The master key is used to encrypt table keys, used for column encryption, and tablespace keys. The table keys are used to encrypt column data. Tablespace keys are used to encrypt tablespace blocks. Changing the master key will cause the table and tablespace keys to be reencrypted, which is a relatively quick operation, but the column data and the tablespace blocks are not reencrypted. The wallet is the default External Security Module (ESM). An ESM is either a wallet or a Hardware Security Module (HSM). All past master keys are held in the wallet or HSM, and the prior keys are available if the old data is recovered from a backup or if database is recovered to a point in time before the key was regenerated. Note: If the master key is regenerated, offline tablespaces will be re-keyed the next time they are brought online.
Quiz
In Oracle Database 11g Release 2, you can regenerate the master key for tablespace encryption by using the ALTER SYSTEM command. 1. True 2. False
Answer: 1
Enterprise Manager Security Management
Virtual Private Database Application Context Oracle Label Security
Enterprise User Security pages added TDE pages added

Enterprise Manager Security Management Security management has been integrated into Enterprise Manager. The Policy Manager Java consolebased tool has been superseded. Oracle Label Security, Application Context, and Virtual Private Database previously administered through the Oracle Policy Manager tool are now managed through the Enterprise Manager. The Oracle Policy Manager tool is still available. The Enterprise Manager Security tool has been superseded by Enterprise Manager features. Enterprise User Security is also now managed though Enterprise Manager. The menu item for Enterprise Manager appears as soon as the ldap.ora file is configured. See the Enterprise User Administrators Guide for configuration details. The Enterprise Security Manager tool is still available. TDE can now be managed through Enterprise Manager, including wallet management. You can create, open, and close the wallet from Enterprise Manager pages.
Manage security through Enterprise Manager. Policy Manager replaced for:
Using RMAN Security Enhancements
Configure backup shredding:

RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON;
Use backup shredding:
Using RMAN Security Enhancements Backup shredding is a key management feature that allows the DBA to delete the encryption key of transparent encrypted backups, without physical access to the backup media. The encrypted backups are rendered inaccessible if the encryption key is destroyed. This does not apply to passwordprotected backups. Configure transparent encrypted backups with:
CONFIGURE ENCRYPTION FOR DATABASE ON;
or
SET ENCRYPTION ON;
The default setting is OFF, and backup shredding is not enabled. To shred a backup use the DELETE FORCE command.
RMAN> DELETE FORCE NOPROMPT BACKUPSET TAG weekly_bkup;
Managing Fine-Grained Access to External Network Services

1. Create an ACL and its privileges:
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'us-oracle-com-permissions.xml', description => 'Permissions for oracle network', principal => 'SCOTT', is_grant => TRUE, privilege => 'connect'); END;
Managing Fine-Grained Access to External Network Services The network utility family of PL/SQL packages, such as UTL_TCP, UTL_INADDR, UTL_HTTP, UTL_SMTP, and UTL_MAIL, allow Oracle users to make network callouts from the database using raw TCP or using higher-level protocols built on raw TCP. A user either did or did not have the EXECUTE privilege on these packages and there was no control over which network hosts were accessed. The new package DBMS_NETWORK_ACL_ADMIN allows fine-grained control using access control lists (ACL) implemented by XML DB. 1. Create an access control list (ACL). The ACL is a list of users and privileges held in an XML file. The XML document named in the acl parameter is relative to the /sys/acl/ folder in XML DB. In the example given in the slide, SCOTT is granted connect. The username is case-sensitive in the ACL and must match the username of the session. There are only resolve and connect privileges. The connect privilege implies resolve. Optional parameters can specify a start and end time stamp for these privileges. To add more users and privileges to this ACL, use the ADD_PRIVILEGE procedure.
Managing Fine-Grained Access to External Network Services

2. Assign an ACL to one or more network hosts:
BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'us-oracle-com-permissions.xml', host => '*.us.oracle.com', lower_port => 80, upper_port => null); END
Managing Fine-Grained Access to External Network Services (continued) 2. Assign an ACL to one or more network hosts. The ASSIGN_ACL procedure associates the ACL with a network host and, optionally, a port or range of ports. In the example, the host parameter allows wildcard characters for the host name to assign the ACL to all the hosts of a domain. The use of wildcard characters affects the order of precedence for the evaluation of the ACL. Fully qualified host names with ports are evaluated before hosts with ports. Fully qualified host names are evaluated before partial domain names, and subdomains are evaluated before the top-level domains. Multiple hosts can be assigned to the same ACL and multiple users can be added to the same ACL in any order after the ACL has been created.
11.2
Supporting IPv6 Address Notification
Oracle Net supports IPv4 and IPv6. IPv6 address notation:

128-bit address 16-bit for each group Single colon (:) as group separator
2001:0DB8:0000:0000:0000:0000:200C:417A
Double colon (::) to suppress zeros

2001:0DB8:0:0::200C:417A 2001:DB8::200C:417A
Supporting IPv6 Address Notification Transmission Control Protocol/Internet Protocol (TCP/IP) is the standard communication protocol suite used for client/server communication over a network. TCP is the transport protocol that manages the exchange of data between hosts. IP is a network layer protocol for packet-switched networks. Oracle Net supports IP in two versions: IP version 4 (IPv4) and IP version 6 (IPv6). The benefit of the IPv6 version is a large address space derived from the use of 128-bit addresses. A 128-bit IP address is generally represented as 8 groups of 4 hexadecimal digits, with the colon (:) symbol as the group separator. For example, the following address is in a valid IPv6 format: Each hexadecimal digit in the address represents 4 bits, so each group in the address represents 16 bits. The following addresses represent the first and last hosts in the 2001:0DB8:0000:0000 subnet: In shorthand notation, consecutive zero fields can be compressed with a double colon (::) separator, as shown in the following equivalent notations:
2001:0DB8:0:0::200C:417A 2001:0DB8::200C:417A 2001:DB8::200C:417A 2001:0DB8:0000:0000:0000:0000:0000:0000 2001:0DB8:0000:0000:FFFF:FFFF:FFFF:FFFF 2001:0DB8:0000:0000:0000:0000:200C:417A
IPv6 is expected to gradually replace IPv4, with the two coexisting during the transition period. For more details, see the Oracle Database Net Services Administrator's Guide.
11.2
Connecting to the Oracle Database

host01= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp) x(HOST=host01-server) (PORT=1521)) (CONNECT_DATA= (SID=host01) (SERVICE_NAME=host01.example.com) (INSTANCE_NAME=host01)))
IPv6 address: 2001:0DB8::200C:417A
IPv4 address: 192.168.2.213
Oracle Net attempts to connect to all IP addresses returned by DNS name resolution until a successful connection is established or all addresses have been attempted.
Connecting to the Oracle Database A host can use the IPv4 and IPv6 interfaces. IPv6 addresses and host names that resolve to IPv6 addresses are usable in the HOST parameter of a connect address, which can be obtained through any of the supported Oracle Net naming methods. End-to-end connectivity with IPv6 in Oracle Database 11g Release 2 requires the following configuration: The client connect address must connect to the Oracle Net Listener on the IPv6 endpoint. The database instance Oracle Net Listener configuration must listen for connection requests on IPv6 endpoints. Assume that in the example in the slide, the host01-server host is an IPv4-only host that is accepting client connections. Domain Name Server (DNS) maps host01-server to the following IP addresses: 1. IPv6 address: 2001:0DB8::200C:417A 2. IPv4 address: 192.168.2.213 Oracle Net first tries to connect on the IPv6 address, because it is first in the DNS list. Because the host01-server (in this example) does not support IPv6 connectivity, the attempt to connect fails. Then Oracle Net proceeds to connect to the IPv4 address, which succeeds.
11.2
IPv6 Supported in Java Interfaces
IPv6 Support for JDBC Thin Clients

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A
IPv6 Support for JVM and Java Debuggers
IPv6 Supported in Java Interfaces Complete IPv6 Support for JDBC Thin Clients JDBC supports IPv6 style addresses in the JDBC URL and host names that resolve to IPv6 addresses. For example:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A
A JDBC URL looks like the following:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210])(PORT=5521)) (CONNECT_DATA=(SERVICE_NAME=host02.example.com)))
This provides Java interoperability with IPv6. Complete IPv6 Support for JVM and Java Debuggers The IPv6 support for the database resident Java Virtual Machine (JVM) allows Java applications running in the Oracle database to connect and accept connections from both IPv4 and IPv6 hosts. For more details see the Oracle Database Java Developer's Guide.
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210])(PORT=5521)) (CONNECT_DATA=(SERVICE_NAME=host02.example.com)))
Summary
In this lesson, you should have learned how to: Configure the password file to use case-sensitive passwords Explain default auditing Encrypt a tablespace Configure fine-grained access to network services Explain how Oracle Net supports IPv6
This practice covers the following topics: Changing the use of case-sensitive passwords Implementing a password complexity function Encrypting a tablespace
SQL Performance Analyzer

Objectives
After completing this lesson, you should be able to: Identify the benefits of using SQL Performance Analyzer Describe the SQL Performance Analyzer workflow phases Use SQL Performance Analyzer to ascertain performance gains following a database change
Challenges Faced by DBAs When Performing Changes

Maintaining service-level agreements through changes to hardware or software configurations Offering production-level workload environment for testing purposes Effectively forecasting and analyzing impact on SQL performance
Challenges Faced by DBAs When Performing Changes Large business-critical applications are complex and have highly varying load and usage patterns. At the same time, these business systems are expected to provide certain service-level guarantees in terms of response time, throughput, uptime, and availability. Any change to a system (such as upgrading the database or modifying the configuration) often necessitates extensive testing and validation before these changes can make it to the production system. To be confident before moving to a production system, the database administrator (DBA) must expose a test system to a workload very similar to the workload to be experienced in a production environment. It is also beneficial for the DBA to have an effective way to analyze the impact of system-level changes on the overall SQL performance so that any required tuning changes can be performed before production.
Change Is the Only Constant

Change is the most common cause of instability. Enterprise production systems are complex. Actual workloads are difficult to simulate.
possible!
Realistic testing before production is impossible. Reluctance to make changes Inability to adopt new competitive technologies Preserve order amid change.
Change Is the Only Constant Oracle Database 11g is designed for data center environments that are rapidly evolving and changing to keep up with business demands, enabling DBAs to manage change effectively and efficiently. Building on the self-managing capabilities of Oracle Database 10g, Oracle Database 11g offers significant advances in the areas of automatic diagnostics, supportability, and change management. Oracle DBAs and information technology managers are leading the key initiatives in data centers today. Some of these data center initiatives are moving to low-cost computing platforms (such as Oracle Enterprise Linux) and simplifying storage management by using ASM. DBAs need to test the databases by using realistic workloads with new operating systems or storage platforms to ensure that migration is successful. Todays enterprises must make significant investments in hardware and software to perform the infrastructure changes. For example, if the DBA wants to test the storage management of data files for a database, from file systembased to ASM for a typical J2EE application, the enterprise would need to invest in duplicate hardware for the entire application stack, including the Web server, application server, and database. The organization would also need to invest in expensive testing software to capture the end-user workload. These purchases make it very expensive for any organization to evaluate and implement changes to their data center infrastructure. Oracle Database 11g addresses this issue with a collection of solutions under the umbrella of Change Management.
Change Management in Oracle Database 11g
SQL Performance Analyzer SQL Plan Management Database Replay
Change Management in Oracle Database 11g SQL Performance Analyzer automates the process of assessing the overall effect of a change on the full SQL workload by identifying performance divergence for each SQL statement. Additional information about SQL Performance Analyzer is presented in this lesson. SQL Plan Management is a new feature introduced with Oracle Database 11g that enables the system to automatically control SQL plan evolution by maintaining SQL plan baselines. SQL Plan Management is discussed in detail in the next lesson. Database Replay enables you to test the impact of a system change by replaying a real-world workload on the test system before it is exposed to a production system. Database Replay is discussed in detail in a later lesson.
Lifecycle of Change Management

Test (Database Replay or SQL Performance Analyzer) Make change Diagnose and resolve problems
(advisors)
Set up test environments

(snapshot standby databases)
Patches and workarounds
Diagnose problems
Realistic testing
Lifecycle of Change Management Oracle Database 11g supports realistic testing through the use of snapshot standby databases to set up and test the physical environment. You can open a physical standby database temporarily (that is, activated) for read and write activities such as reporting and testing. Once testing is completed, you can then simply revert to the physical standby mode to allow catch-up to the primary site. This functionality preserves zero data loss and is similar to storage snapshots, but allows for disaster recovery and offers a single copy of storage at the time of testing. Refer to the Oracle Database 11g: New Features for Data Guard Seminar for detailed information on snapshot standby databases. For enterprises to be able to perform an accurate test of a database environment, it is vital that they be able to reproduce the production scenarios accurately. Database Replay provides further support for realistic testing in Oracle Database 11g. Database Replay is designed to capture client requests on a given database to be reproduced on other copies of production databases. Oracle Enterprise Manager provides an easy-to-use set of steps to set up the capture of a workload. Some of the changes that a DBA deals with are database upgrades, new tuning recommendations, schema changes, statistics collection, and changes in operating system and hardware. DBAs can use SQL Performance Analyzer to track and forecast SQL performance changes caused by these changes. If SQL performance has regressed in some of the cases, the DBA can then run the SQL Tuning Advisor to tune the SQL statements.
Provision for production
Lifecycle of Change Management

Test Make change Diagnose and resolve problems
Set up test environments
(rolling upgrades)
(Enterprise Manager)
Patches and workarounds
(ADR/Support Workbench)
Diagnose problems
Provisioning automation
Lifecycle of Change Management (continued) When upgrading from Oracle Database 11g, Release 1, you can use the rolling upgrade functionality to ensure that various versions of the software can still communicate with each other. This allows independent nodes of an ASM cluster to be migrated or patched without affecting the availability of the database, thereby providing higher uptime and problem-free migration to new releases. ASM offers further system capacity planning and workload change enhancements (Fast Disk Resync, Preferred Mirror Read). Numerous enhancements to the online functionality (online index reorganization and online table redefinition) further support application change. Automatic Diagnostic Repository (ADR) is a new system-managed repository for storing and organizing trace files and other error diagnostic data. You get a comprehensive view of all the serious errors encountered by the database, and the relevant data needed for problem diagnosis and eventual resolution. You can also use EM Support Workbench, which provides a simple workflow interface to view and diagnose incident data, and package it for Oracle Support. The Data Recovery Advisor tool can be used to automatically diagnose data failures and report on the appropriate repair option. Oracle Database 11g Enterprise Manager supports end-to-end automation of patch application on single-instance database homes and rolling patches on clusterware. You no longer need to perform manual steps for shutting down your system, invoking OPatch, applying SQL, and other such bestpractice steps in the patching procedure.
Provision for production
SQL Performance Analyzer: Overview
SQL Performance Analyzer: Overview The Oracle Real Application Testing option includes SQL Performance Analyzer, which gives you an exact and accurate assessment of the impact of change on the SQL statements that make up the workload. SQL Performance Analyzer helps you forecast the impact of a potential change on the performance of a SQL query workload. This capability provides DBAs with detailed information about the performance of SQL statements, such as before-and-after execution statistics, and statements with performance improvement or degradation. This enables you (for example) to make changes in a test environment to determine whether the workload performance will be improved through a database upgrade.
Targeted users: DBAs, QAs, application developers Helps predict the impact of system changes on SQL workload response time Builds different versions of SQL workload performance (that is, SQL execution plans and execution statistics) Executes SQL serially (concurrency not honored) Analyzes performance differences Offers fine-grained performance analysis on individual SQL Is integrated with SQL Tuning Advisor to tune regressions
SQL Performance Analyzer: Use Cases
SQL Performance Analyzer: Use Cases SQL Performance Analyzer can be used to predict and prevent potential performance problems for any database environment change that affects the structure of the SQL execution plans. The changes can include (but are not limited to) any of the following: Database upgrades Implementation of tuning recommendations Schema changes Statistics gathering Database parameter changes OS and hardware changes You can use SQL Performance Analyzer to predict SQL performance changes that result from changes for even the most complex environments. As applications evolve through the development lifecycle, database application developers can test changes to schemas, database objects, and rewritten applications to mitigate any potential performance impact. SQL Performance Analyzer also enables the comparison of SQL performance statistics.
SQL Performance Analyzer is beneficial in the following use cases: Database upgrades Implementation of tuning recommendations Schema changes Statistics gathering Database parameter changes OS and hardware changes
Using SQL Performance Analyzer
Using SQL Performance Analyzer 1. Gather SQL: In this phase, you collect the set of SQL statements that represent your SQL workload on the production system. 2. Transport: You must transport the resultant workload to the test system. The STS is exported from the production system and the STS is imported into the test system. 3. Compute before-version performance: Before any changes take place, you execute the SQL statements, collecting baseline information that is needed to assess the impact that a future change might have on the performance of the workload. 4. Make a change: After you have the before-version data, you can implement your planned change and start viewing the impact on performance. 5. Compute after-version performance: This step takes place after the change is made in the database environment. Each statement of the SQL workload runs under a mock execution (collecting statistics only), collecting the same information as captured in step 3. 6. Compare and analyze SQL Performance: After you have both versions of the SQL workload performance data, you can carry out the performance analysis by comparing the after-version data with the before-version data. 7. Tune regressed SQL: At this stage, you have identified exactly which SQL statements may cause performance problems when the database change is made. Here, you can use any of the database tools to tune the system. After implementing any tuning action, you should repeat the process to create a new after-version and analyze the performance differences to ensure that the new performance is acceptable.
1. 2. 3. 4. 5. 6. 7.
Capture SQL workload on production. Transport the SQL workload to a test system. Build before-change performance data. Make changes. Build after-change performance data. Compare results from steps 3 and 5. Tune regressed SQL.
Step 1: Capture SQL Workload
SQL Tuning Set (STS) is used to store SQL workload. Includes:

SQL Text Bind variables Execution plans Execution statistics
Cursor cache
Incremental capture
Database Instance
Production database
Step 1: Capture SQL Workload The first step to using SQL Performance Analyzer is to capture the SQL statements that represent your workload. You can use SQL Tuning Sets or Automatic Workload Repository (AWR) to capture the information to transport. Because AWR essentially captures high-load SQL statements, you should consider modifying the default AWR snapshot settings and captured Top SQL to ensure that AWR captures the maximum number of SQL statements. This ensures more complete SQL workload capture.
Incremental capture is used to populate STS from cursor cache over a period of time. STSs filtering and ranking capabilities filter out undesirable SQL.
Step 2: Transport to a Test System
Cursor cache
Database instance
Database instance
Production database
Test database
Copy SQL Tuning Set to staging table (pack). Transport staging table to test system (data pump, DB link, etc). Copy SQL Tuning Set from staging table (unpack).
Step 2: Transport to a Test System The second step is to transport these SQL statements to a similar system that is being tested. Here, STS can be exported from production and then imported into a test system.
Step 3: Build Before Change Performance Data

Before change, SQL performance version is the SQL workload performance baseline. SQL performance = execution plans + execution statistics Test/execute SQL in STS:
Produce execution plans and statistics. Execute SQL serially (no concurrency). Every SQL is executed at least twice. Skip DDL/DML effects.
Test database
Test/execute
11.2 update
Before changes
Explain plan SQL in STS generates only SQL plans.
Step 3: Build Before Change Performance Data The third step is to capture a baseline of the test system performance consisting of the execution plan and execution statistics. The information collected in this stage represents a snapshot of the current state of the system workload. The performance data includes: Execution plans (for example, generated by explain plan) Execution statistics (for example, includes elapsed time, buffer gets, disk reads, and rows processed) In Oracle Database 11g Release 2, each SQL statement is executed at least twice, for as many times as possible until the execution times out (up to a maximum of 10 times). The first execution is used to warm the buffer cache. All subsequent executions are then used to calculate the run-time execution statistics for the SQL statement based on their averages.
Database instance
Step 4: Implement Planned Change and Step 5: Build After-Change Performance Data
Manually implement the planned change:
Database upgrade Implementation of tuning recommendations Schema changes Statistics gathering Database parameter changes OS and hardware changes Test/execute SQL in STS to generate SQL execution plans and statistics. Explain plan SQL in STS to generate SQL plans.
After changes implemented
Reexecute SQL after change:
Test database
Step 4: Implement Planned Change and Step 5: Build After-Change Performance Data The fourth step is to make the changes to the test system. Rerun the SQL statements to assess the impact of the changes on the SQL performance as step five.
After changes
Database instance
Step 6: Compare and Analyze Performance and Step 7: Tune Regressed SQL
Rely on user-specified metric to compare SQL performance:
ELAPSED_TIME, BUFFER_GETS, DISK_READS, ...
Improvement Regression
SQL Tuning Advisor
Calculate impact of change on individual SQLs and SQL workload:

Overall impact on workload Net SQL impact on workload
Compare analysis
Use SQL execution frequency to define a weight of importance. Detect improvements, regressions, and unchanged performance. Detect changes in execution plans. Recommend running SQL Tuning Advisor to tune regressed SQLs. Analysis results can be used to seed SQL Plan Management baselines.
Database instance
Test database
Step 6: Compare and Analyze Performance and Step 7: Tune Regressed SQL The comparison is based on the execution statistics, such as elapsed time, CPU time, and buffer gets. Enterprise Manager provides the tools to make a full comparison of performance data, including execution statistics such as elapsed time, CPU time, and buffer gets. If the SQL performance has regressed in some of the cases, you must then run SQL Tuning Advisor to tune the SQL statements either immediately or at a scheduled time. As with any tuning strategy, it is recommended that only one change be implemented at a time and retested before making further changes. You can use SQL Tuning Advisor or Access Advisor against the identified statements and then implement those recommendations. Alternatively, you can seed SQL Plan Management (SPM) with plans captured in step 3 to guarantee that the plans remain the same.
Quiz
Which of the following does SQL Performance Analyzer perform? 1. Tunes regressions 2. Provides before-and-after execution statistics 3. Executes SQL statements serially 4. Builds different versions of SQL workload performance
Accessing SQL Performance Analyzer
Use Enterprise Manager Use the DBMS_SQLPA package
Accessing SQL Performance Analyzer You can access SQL Performance Analyzer through Enterprise Manager or by using the DBMS_SQLPA package.
Using Enterprise Manager to Access SQL Performance Analyzer

Access SQL Performance Analyzer on the Software and Support tab. Select one of the five types of workflows:
Upgrade from 9i or 10.1 Upgrade from 10.2 or 11g Parameter Change Exadata Simulation Guided Workflow
Tune regressing statements by invoking SQL Tuning Advisor. Prevent regressions by using SQL plan baselines.
Using Enterprise Manager to Access SQL Performance Analyzer You access SQL Performance Analyzer from the Software and Support tab of Database Control. Alternatively, select Database Instance > Advisor Central > Advisors > SQL Performance Analyzer. SQL Performance Analyzer offers three workflows for you to test different scenarios: Upgrade from 9i or 10.1: Test and analyze the effects of database upgrade from 9i or 10.1 on SQL Tuning Set performance. Upgrade from 10.2 or 11g: Test and analyze the effects of database upgrade from 10.2 or 11g on SQL Tuning Set performance. Parameter Change: Test and compare an initialization parameter change on SQL Tuning Set performance. A SQL Performance Analyzer task is created and an initial trial run is performed with the parameter set to the base value. A second trial run is performed with the parameter set to the changed value. A replay trial comparison report is then run for the two trials. Exadata Simulation: Simulate the effects of an Exadata Storage Server installation on SQL Tuning Set performance. Guided Workflow: Create a SQL Performance Analyzer task and execute custom experiments by using manually created replay trials. You can directly tune all regressing statements by invoking SQL Tuning Advisor. Instead of using SQL Tuning Advisor to tune your regressing statements, you can also prevent regressions by using the SQL plan baselines.
SQL Performance Analyzer: PL/SQL Example
Create the tuning task:

exec :tname:= dbms_sqlpa.create_analysis_task( sqlset_name => 'MYSTS', task_name => 'MYSPA');
Execute the task to build the before-change performance data:

exec dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'TEST EXECUTE', execution_name => 'before');
Produce the before-change report:

SELECT dbms_sqlpa.report_analysis_task(task_name => :tname, type=>'text', section=>'summary') FROM dual;
SQL Performance Analyzer: PL/SQL Example The example in the slide shows you how to use the DBMS_SQLPA package to invoke SQL Performance Analyzer to access the SQL performance impact of some changes. You could easily adapt this example to run your own analysis. 1. Create the tuning task to run SQL Performance Analyzer. 2. Execute the task once to build the before-change performance data, and produce the beforechange report (special settings for report: set long 100000, longchunksize 100000, and linesize 90). With this call, you can specify various parameters, some of which are: - Set the EXECUTION_TYPE parameter as follows: EXPLAIN PLAN to generate explain plans for all SQL statements in the SQL workload. TEST EXECUTE to execute all SQL statements in the SQL workload. The procedure executes only the query part of the DML statements to prevent side-effects to the database or user data. When TEST EXECUTE is specified, the procedure generates execution plans and execution statistics. COMPARE [PERFORMANCE] to analyze and compare two versions of SQL performance data. CONVERT SQLSET to read the statistics captured in a SQL Tuning Set and model them as a task execution. - Specify execution parameters by using the execution_params parameter that needs to be specified as dbms_advisor.arglist(name,value,). The time_limit parameter specifies the global time limit to process all SQL statements in a SQL Tuning Set before timing out. The local_time_limit parameter specifies the time limit to process each SQL statement in a SQL Tuning Set before timing out.
SQL Performance Analyzer: PL/SQL Example

After making your changes: Create the after-change performance data:
EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'TEST EXECUTE', execution_name => 'after');
Generate the after-change report:
Compare the task executions:

EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'COMPARE PERFORMANCE');
Generate the analysis report:

SQL Performance Analyzer: PL/SQL Example (continued) 3. Make your changes. 4. Execute the task again after making the changes, and generate the after-changes report. 5. Compare the two executions and generate the analysis report. Using different execution parameters, you can execute the following command:
EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'COMPARE PERFORMANCE');
Note: For more information about the DBMS_SQLPA package, see the Oracle Database PL/SQL Packages and Types Reference Guide.
11.2
Tuning Regressed SQL Statements
To tune regressed SQL statements reported by SQL Performance Analyzer, create a SQL tuning task for the SQL Performance Analyzer execution by using the DBMS_SQLTUNE.CREATE_TUNING_TASK function:
Tuning Regressed SQL Statements After reviewing the SQL Performance Analyzer report, you should tune any regressed SQL statements that are identified after comparing the SQL performance. If there are a large number of SQL statements that appear to have regressed, try to identify the root cause and make system-level changes to rectify the problem. If only a few SQL statements have regressed, consider using the SQL Tuning Advisor to implement a point solution for them. Create a SQL tuning task for the SQL Performance Analyzer execution by using the DBMS_SQLTUNE.CREATE_TUNING_TASK function. The CREATE_TUNING_TASK function has the following parameters: SPA_TASK_NAME: Name of the SQL Performance Analyzer task SPA_TASK_OWNER: Owner of the specified SQL Performance Analyzer task. If unspecified, this parameter will default to the current user. SPA_COMPARE_EXEC: Execution name of the compare performance trial for the specified SQL Performance Analyzer task. If unspecified, this parameter defaults to the most recent execution of the COMPARE PERFORMANCE type for the given SQL Performance Analyzer task. After tuning the regressed SQL statements, test your changes by using SQL Performance Analyzer. Run a new SQL trial on the test system, followed by a second comparison (between this new SQL trial and the first SQL trial) to validate your results. After SQL Performance Analyzer shows that performance has stabilized, you can implement the changes.
BEGIN DBMS_SQLTUNE.CREATE_TUNING_TASK( spa_task_name => 'MYSPA', spa_compare_exec => 'MYCOMPEXEC'); END; /
Testing Database Upgrades: Oracle9i Database and Oracle Database 10g Release 1
SQL Performance Analyzer supports testing database upgrades of Oracle9i and Oracle Database 10g Release 1, to Oracle Database 10g Release 2 and later releases. Execute the SQL tuning set on the upgraded database remotely over a database link. The production system which you are upgrading from should be running Oracle9i or Oracle Database 10g Release 1. The test system which you are upgrading to should be running Oracle Database 10g Release 2 (10.2.0.2) or a newer release. Set up a separate system for SQL Performance Analyzer: Oracle Database 11g Release 1 (11.1.0.7) or a later release.
Testing Database Upgrades: Oracle9i Database and Oracle Database 10g Release 1 SQL Performance Analyzer supports testing database upgrades of Oracle9i and Oracle Database 10g Release 1, to Oracle Database 10g Release 2 and later releases by executing the SQL tuning set on the upgraded database remotely over a database link. Because SQL Performance Analyzer only accepts a set of SQL statements stored in a SQL tuning set as its input source, and SQL tuning sets are not supported in Oracle9i, a SQL tuning set must be constructed so that it can be used as an input source for SQL Performance Analyzer if you are upgrading from Oracle9i. The production system which you are upgrading from should be running Oracle9i or Oracle Database 10g Release 1. The test system which you are upgrading to should be running Oracle Database 10g Release 2 (10.2.0.2) or a newer release. If you are upgrading to Oracle Database 10g Release 10.2.0.2, 10.2.0.3, or 10.2.0.4, you will also need to install a one-off patch before proceeding. Set up a separate system for SQL Performance Analyzer running Oracle Database 11g Release 1 (11.1.0.7) or a later release. Use this system to build a SQL tuning set and to run SQL Performance Analyzer. You do not need your production data or schema on this system, because the SQL tuning set will be built using statistics stored in the SQL trace files from the production system. SQL Performance Analyzer tasks will be executed remotely on the test system to generate the execution plan and statistics for the SQL trial over a database link that you specify. The database link must be a public database link that connects to a user with the EXECUTE privilege for the DBMS_SQLPA package and the ADVISOR privilege on the test system. You should also drop any existing PLAN_TABLE from the users schema on the test system.
To use SQL Performance Analyzer in a database upgrade from Oracle9i or Oracle Database 10g Release 1 to a newer release, perform the following steps: 1. Enable the SQL Trace facility on the production system. 2. On the production system, create a mapping table. 3. Move the SQL trace files and the mapping table from the production system to the SQL Performance Analyzer system. 4. On the SQL Performance Analyzer system, construct a SQL tuning set by using the SQL trace files.
Testing Database Upgrades: Oracle9i Database and Oracle Database 10g Release 1 (continued) To use SQL Performance Analyzer in a database upgrade from Oracle9i or Oracle Database 10g Release 1 to a later release, perform the following steps: 1. Enable the SQL Trace facility on the production system. Consider enabling SQL Trace for only a subset of the sessions, for as long as required, to capture all important SQL statements at least once. 2. On the production system, create a mapping table that will be used to convert the user and object identifier numbers in the SQL trace files to their string equivalents. 3. Move the SQL trace files and the mapping table from the production system to the SQL Performance Analyzer system. 4. On the SQL Performance Analyzer system, construct a SQL tuning set by using the SQL trace files. The SQL tuning set will contain the SQL statements captured in the SQL trace files, along with their relevant execution context and statistics.
5. On the SQL Performance Analyzer system:
Use SQL Performance Analyzer to create a SQL Performance Analyzer task and convert the contents in the SQL tuning set into a preupgrade SQL trial that will be used as a baseline for comparison. Remotely test execute the SQL statements on the test system over a database link to build a postupgrade SQL trial.
6. Compare SQL performance and fix regressed SQL statements.
Testing Database Upgrades: Oracle9i Database and Oracle Database 10g Release 1 (continued) 5. On the SQL Performance Analyzer system, use SQL Performance Analyzer to create a SQL Performance Analyzer task and convert the contents in the SQL tuning set into a preupgrade SQL trial that will be used as a baseline for comparison. Remotely test execute the SQL statements on the test system over a database link to build a postupgrade SQL trial. You can access the SQL Performance Analyzer through Enterprise Manager or by using the DBMS_SQLPA package. 6. Compare SQL performance and fix any regressed SQL statements. Repeat the process of executing the SQL tuning set and comparing its performance to a previous execution to test any changes made until you are satisfied with the results.
Testing Database Upgrades: Oracle Database 10g Release 2 and Later Releases
SQL Performance Analyzer supports testing database upgrades of Oracle Database 10g Release 2 or a later release to any later release. Capture a SQL tuning set on the production system, then execute it twice remotely over a database link on a test system. The production system which you are upgrading from should be running Oracle Database 10g Release 2 or a later release. The test system which you are upgrading to initially should be running the same release as the production system. Set up a separate system for running SQL Performance Analyzer: Oracle Database 11g Release 1 (11.1.0.7) or a later release.
Testing Database Upgrades: Oracle Database 10g Release 2 and Later Releases You can use SQL Performance Analyzer to test the impact on SQL response time of a database upgrade from Oracle Database 10g Release 2 or a later release to any later release by capturing a SQL tuning set on the production system, then executing it twice remotely over a database link on a test systemfirst to create a pre-change SQL trial, and then again to create a postchange SQL trial. The production system which you are upgrading from should be running Oracle Database 10g Release 2 or a later release. Initially, the test system should also be running the same release. To ensure that the analysis made by SQL Performance Analyzer is accurate, the test system should contain an exact copy of the production data found on the production system. The hardware configuration on the test system should be as similar to the production system as possible. Set up a separate system for SQL Performance Analyzer running Oracle Database 11g Release 1 (11.1.0.7) or a later release. Use this system to build a SQL tuning set and to run SQL Performance Analyzer. You do not need your production data or schema on this system, because the SQL tuning set will be built using statistics stored in the SQL trace files from the production system. SQL Performance Analyzer tasks will be executed remotely on the test system to generate the execution plan and statistics for the SQL trial over a database link that you specify. The database link must be a public database link that connects to a user with the EXECUTE privilege for the DBMS_SQLPA package and the ADVISOR privilege on the test system. You should also drop any existing PLAN_TABLE from the users schema on the test system.
Perform the following steps to use SQL Performance Analyzer in a database upgrade from Oracle Database 10g Release 2 and later releases to a newer release: 1. On the production system, capture the SQL workload that you intend to analyze and store it in a SQL tuning set. 2. Set up the test system so that it matches the production environment as closely as possible. 3. Transport the SQL tuning set to the SQL Performance Analyzer system. 4. On the SQL Performance Analyzer system, create a SQL Performance Analyzer task using the SQL tuning set as its input source.
Testing Database Upgrades: Oracle Database 10g Release 2 and Later Releases (continued) To use SQL Performance Analyzer in a database upgrade from Oracle Database 10g Release 2 and later releases to a newer release, perform the following steps: 1. On the production system, capture the SQL workload that you intend to analyze and store it in a SQL tuning set. 2. Set up the test system so that it matches the production environment as closely as possible. 3. Transport the SQL tuning set to the SQL Performance Analyzer system 4. On the SQL Performance Analyzer system, create a SQL Performance Analyzer task using the SQL tuning set as its input source. Remotely test execute the SQL statements in the SQL tuning set on the test system over a database link to build a preupgrade SQL trial that will be used as a baseline for comparison.
5. Upgrade the test system. 6. Remotely test execute the SQL statements a second time on the upgraded test system over a database link to build a postupgrade SQL trial. 7. Compare SQL performance and fix regressed SQL statements.
Testing Database Upgrades: Oracle Database 10g Release 2 and Later Releases (continued) 5. Upgrade the test system. 6. Remotely test execute the SQL statements a second time on the upgraded test system over a database link to build a postupgrade SQL trial. 7. Compare SQL performance and fix any regressed SQL statements. Repeat the process of executing the SQL tuning set and comparing its performance to a previous execution to test any changes made until you are satisfied with the results.
SQL Performance Analyzer: Data Dictionary Views

Modified views in Oracle Database 11g:
DBA{USER}_ADVISOR_TASKS: Displays details about the analysis task DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for task execution DBA{USER}_ADVISOR_SQLPLANS: Displays the list of SQL execution plans DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL compilation and execution statistics
SQL Performance Analyzer: Data Dictionary Views Modified views in Oracle Database 11g: DBA{USER}_ADVISOR_TASKS: Displays details about the advisor task created to perform an impact analysis of a system environment change DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings. The advisor generates four types of findings: performance regression, symptoms, errors, and informative messages. New views in Oracle Database 11g: DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for a task execution. SQL Performance Analyzer creates a minimum of three executions to perform a change impact analysis on a SQL workload: one execution to collect performance data for the before-change version of the workload, the second execution to collect data for the after-change version of the workload, and a final execution to perform the actual analysis. DBA{USER}_ADVISOR_SQLPLANS: Displays the list of all SQL execution plans (or those owned by the current user) DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL compilation and execution statistics (or those owned by the current user)
New views in Oracle Database 11g:
Summary
In this lesson, you should have learned how to: Identify the benefits of using SQL Performance Analyzer Describe the SQL Performance Analyzer workflow phases Use SQL Performance Analyzer to determine performance gains following a database change
This practice covers the following topics: Capturing SQL Tuning Sets Migrating SQL Tuning Sets from Oracle Database 10g to Oracle Database 11g Using SQL Performance Analyzer in an upgrade scenario
SQL Plan Management

Objectives
After completing this lesson, you should be able to: Set up SQL Plan Management Set up various SQL Plan Management scenarios Migrate stored outlines to SQL Plan baselines
SQL Plan Management: Overview
SQL Plan Management is automatically controlled SQL plan evolution. Optimizer automatically manages SQL plan baselines.
Only known and verified plans are used.
Plan changes are automatically verified. Can preseed critical SQL with SQL Tuning Set (STS) from SQL Performance Analyzer Main benefit is the performance stability of the system through the avoidance of plan regressions.
SQL Plan Management: Overview Potential performance risk occurs when the SQL execution plan changes for a SQL statement. A SQL plan change can occur due to a variety of reasons such as optimizer version, optimizer statistics, optimizer parameters, schema definitions, system settings, and SQL profile creation. Various plan control techniques (such as stored outlines and SQL profiles) have been introduced in past versions of Oracle Database to address performance regression due to plan changes. However, these techniques are reactive processes that require manual intervention. SQL Plan Management is a new feature introduced with Oracle Database 11g that enables the system to automatically control SQL plan evolution by maintaining SQL plan baselines. With this feature enabled, a newly generated SQL plan can integrate a SQL plan baseline only if it has been proven that doing so will not result in performance regression. During execution of a SQL statement, only a plan that is part of the corresponding SQL plan baseline can be used. As described later in this lesson, SQL plan baselines can be automatically loaded or can be seeded using SQL Tuning Sets. Various scenarios are covered later in this lesson. The main benefit of the SQL Plan Management feature is the performance stability of the system through the avoidance of plan regressions. In addition, it saves the DBA time that is often spent in identifying and analyzing SQL performance regression and finding workable solutions.
Only comparable or better plans are used going forward.
SQL Plan Baseline: Architecture

SYSAUX SQL Management Base Statement log Plan history
Plan baseline
GB HJ GB HJ HJ
Plan history
GB HJ HJ GB HJ HJ GB HJ HJ
Plan baseline
GB HJ HJ
Plan History
Plan baseline
GB HJ HJ GB HJ HJ
GB HJ HJ
Automatic SQL Tuning task Plan verification before integration to baseline
SQL Plan Baseline: Architecture The SQL Plan Management (SPM) feature introduces necessary infrastructure and services in support of plan maintenance and performance verification of new plans. For SQL statements that are executed more than once, the optimizer maintains a history of plans for individual SQL statements. The optimizer recognizes a repeatable SQL statement by maintaining a statement log. A SQL statement is recognized as repeatable when it is parsed or executed again after it has been logged. After a SQL statement is recognized as repeatable, various plans generated by the optimizer are maintained as a plan history containing relevant information (such as SQL text, outline, bind variables, and compilation environment) that is used by the optimizer to reproduce an execution plan. As an alternative or complement to the automatic recognition of repeatable SQL statements and the creation of their plan history, manual seeding of plans for a set of SQL statements is also supported. A plan history contains different plans generated by the optimizer for a SQL statement over time. However, only some of the plans in the plan history may be accepted for use. For example, a new plan generated by the optimizer is not normally used until it has been verified not to cause a performance regression. Plan verification is done out of the box as part of Automatic SQL Tuning running as an automated task in a maintenance window.
Repeatable SQL statement
HJ
SQL profile
SQL Plan Baseline: Architecture (continued) An Automatic SQL Tuning task targets only high-load SQL statements. For them, it automatically implements actions such as making a successfully verified plan an accepted plan. A set of acceptable plans constitutes a SQL plan baseline. The very first plan generated for a SQL statement is obviously acceptable for use; therefore, it forms the original plan baseline. Any new plans subsequently found by the optimizer are part of the plan history but not part of the plan baseline initially. The statement log, plan history, and plan baselines are stored in the SQL Management Base (SMB), which also contains SQL profiles. The SMB is part of the database dictionary and is stored in the SYSAUX tablespace. The SMB has automatic space management (for example, periodic purging of unused plans). You can configure the SMB to change the plan retention policy and set space size limits. Note: With Oracle Database 11g, if the database instance is up but the SYSAUX tablespace is OFFLINE, the optimizer is unable to access SQL management objects. This can affect performance on some of the SQL workload.
Loading SQL Plan Baselines

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
DBMS_SPM
Plan history
load_plans_from_cursor_cache
an Pl
Plan history 1
an Pl
ba
GB HJ HJ
GB HJ HJ
GB
ALTER_SQL_PLAN_BASELINE
HJ HJ
load_plans_from_sqlset
ba
se lin
se lin
*_STGTAB_BASELINE
GB HJ HJ
Cursor cache Plan history

an Pl
Staging table
ba
GB HJ HJ
se lin
DBA
Loading SQL Plan Baselines You can load SQL plan baselines as follows: On the fly capture: Uses automatic plan capture by setting the initialization parameter OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE. This parameter is set to FALSE by default. Setting it to TRUE turns on automatic recognition of repeatable SQL statements and automatic creation of plan history for such statements. This is illustrated in the left graphic in the slide, where you can see the first generated SQL plan automatically integrated into the original SQL plan baseline. Bulk loading: Uses the DBMS_SPM package, which enables you to manually manage SQL plan baselines. With this package, you can load SQL plans into a SQL plan baseline directly from the cursor cache or from an existing SQL Tuning Set (STS). For a SQL statement to be loaded into a SQL plan baseline from an STS, the SQL statement needs to store its SQL plan in the STS. DBMS_SPM enables you to change the status of a baseline plan from accepted to not accepted (and from not accepted to accepted). It also enables you to export baseline plans from a staging table, which can then be used to load SQL plan baselines on other databases. Migrate from stored outlines: Use the DBMS_SPM.MIGRATE_STORED_OUTLINE function to migrate stored outlines for one or more SQL statements to plan baselines in the SQL management base (SMB). Additional information is provided later in this lesson.
Evolving SQL Plan Baselines

variable report clob exec :report:=DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(sql_handle=>'SYS_SQL_593bc74fca8e6738'); Print report
Plan history Automatic SQL Tuning

an Pl
ba
GB HJ HJ
se lin
GB HJ HJ
>?
SQL Tuning Advisor
Evolving SQL Plan Baselines During the SQL plan baseline evolution phase, Oracle Database routinely evaluates the performance of new plans and integrates plans with better performance into SQL plan baselines. When the optimizer finds a new plan for a SQL statement, the plan is added to the plan history as a nonaccepted plan. The plan is then verified for performance relative to the SQL plan baseline performance. When it is verified that a nonaccepted plan does not cause a performance regression (either manually or automatically), the plan is changed to an accepted plan and integrated into the SQL plan baseline. Successful verification of a nonaccepted plan consists of comparing its performance to that of one plan selected from the SQL plan baseline and ensuring that it delivers better performance. There are two ways to evolve SQL plan baselines: By using the DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE function. An invocation example is shown in the slide. The function returns a report that tells you whether some of the existing history plans were moved to the plan baseline. You can also specify specific plans in the history to be tested. By running SQL Tuning Advisor: SQL plan baselines can be evolved by manually or automatically tuning SQL statements using SQL Tuning Advisor. When SQL Tuning Advisor finds a tuned plan and verifies its performance to be better than a plan chosen from the corresponding SQL plan baseline, it makes a recommendation to accept a SQL profile. When the SQL profile is accepted, the tuned plan is added to the corresponding SQL plan baseline.
DBA
Viewing Important Baseline SQL Plan Attributes

Plan history
an Pl
ba
GB HJ HJ
Enabled but not accepted
GB HJ HJ
se lin
Enabled and accepted
SELECT signature, sql_handle, sql_text, plan_name, origin, enabled, accepted, fixed, autopurge FROM dba_sql_plan_baselines; SIGNATURE SQL_HANDLE SQL_TEXT PLAN_NAME ORIGIN ENA ACC FIX AUT --------- ------------ -------- ---------------- ------------ --- --- --- --8.062E+18 SYS_SQL_6fe2 select.. SYS_SQL_PLAN_1ea AUTO-CAPTURE YES NO NO YES 8.062E+18 SYS_SQL_6fe2 select.. SYS_SQL_PLAN_4be AUTO-CAPTURE YES YES NO YES exec :cnt := dbms_spm.alter_sql_plan_baseline(sql_handle => 'SYS_SQL_37e0168b03efe', plan_name => 'SYS_SQL_PLAN_8dfc352f359901ea', attribute_name => 'ENABLED', attribute_value => 'NO');
Viewing Important Baseline SQL Plan Attributes You can look at each plans attributes by using the DBA_SQL_PLAN_BASELINES view, as shown in the slide. You can then use the DBMS_SPM.ALTER_SQL_PLAN_BASELINE function to change some of them. You can also remove plans or a complete plan history by using the DBMS_SPM.DROP_SQL_PLAN_BASELINE function. The example shown in the slide changes the ENABLED attribute of SYS_SQL_PLAN_8DFC352F359901EA to NO. Additional information on the attributes is presented on the next page. Note: The DBA_SQL_PLAN_BASELINES view contains additional columns that enable you to determine when each plan was last used and whether a plan will be automatically purged.
Important Baseline SQL Plan Attributes
ORIGIN:
AUTO-CAPTURE: Automatically captured MANUAL-LOAD: Manually evolved MANUAL-SQLTUNE: Automatically evolved by SQL Tuning Advisor AUTO-SQLTUNE: Automatically evolved by Automatic SQL Tuning
ENABLED: Plan is enabled for use by optimizer ACCEPTED: Plan validated as a good plan FIXED: Optimizer considers only those plans
Important Baseline SQL Plan Attributes When a plan enters the plan history, it is associated with a number of important attributes: SIGNATURE, SQL_HANDLE, SQL_TEXT, and PLAN_NAME are important identifiers for search operations. ORIGIN allows you to determine whether the plan was automatically captured (AUTOCAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTOSQLTUNE). ENABLED and ACCEPTED: The ENABLED attribute means that the plan is enabled for use by the optimizer. If ENABLED is not set, the plan is not considered. The ACCEPTED attribute means that the plan was validated as a good plan, either automatically by the system or manually when the user changes it to ACCEPTED. When a plan changes to ACCEPTED, it will become not ACCEPTED only when DBMS_SPM.ALTER_SQL_PLAN_BASELINE() is used to change its status. An ACCEPTED plan can be temporarily disabled by removing the ENABLED setting. A plan must be ENABLED and ACCEPTED for the optimizer to consider using it. FIXED means that the optimizer considers only those plans and not other plans. For example, if you have 10 baseline plans and three of them are marked FIXED, the optimizer uses only the best plan from these three, ignoring all the others. A SQL plan baseline is said to be FIXED if it contains at least one enabled fixed plan. If new plans are added to a fixed SQL plan baseline, these new plans cannot be used until they are manually declared as FIXED.
SQL Plan Selection

DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE
GB HJ HJ
OPTIMIZER_USE_SQL_ PLAN_BASELINES=TRUE?
Yes
Plan part of history?
No
Yes No
GB GB HJ HJ HJ
Plan history
Plan baseline
GB HJ HJ
GB HJ HJ
No
Select baseline plan with lowest best-cost
GB
DBMS_XPLAN.DISPLAY(,'BASIC +NOTE) or PLAN_TABLE(other_xml)
HJ HJ
Yes
GB HJ HJ
GB
>
HJ HJ
No
GB HJ HJ
SQL Plan Selection If you are using automatic plan capture, the first time that a SQL statement is recognized as repeatable, its best-cost plan is added to the corresponding SQL plan baseline. That plan is then used to execute the statement. The optimizer uses a comparative plan selection policy when a plan baseline exists for a SQL statement and the OPTIMIZER_USE_SQL_PLAN_BASELINES initialization parameter is set to TRUE (default value). Each time a SQL statement is compiled, the optimizer first uses the traditional cost-based search method to build a best-cost plan. Then it tries to find a matching plan in the SQL plan baseline. If a match is found, it proceeds as usual. If no match is found, it first adds the new plan to the plan history, then costs each of the accepted plans in the SQL plan baseline, and picks the one with the lowest cost. The accepted plans are reproduced using the outline that is stored with each of them. So the effect of having a SQL plan baseline for a SQL statement is that the optimizer always selects one of the accepted plans in that SQL plan baseline. With SQL Plan Management, the optimizer can produce a plan that could be either a best-cost plan or a baseline plan. This information is dumped in the OTHER_XML column of the PLAN_TABLE upon EXPLAIN PLAN.
Yes
Plan part of baseline?
HJ
SQL Plan Selection (continued) In addition, you can use the new DBMS_XPLAIN.DISPLAY_SQL_PLAN_BASELINE function to display one or more execution plans for the specified sql_handle of a plan baseline. If PLAN_NAME is also specified, the corresponding execution plan is displayed. Note: To preserve backward compatibility, if a stored outline for a SQL statement is active for the user session, the statement is compiled using the stored outline. In addition, a plan generated by the optimizer using a stored outline is not stored in the SMB even if automatic plan capture has been enabled for the session.
Quiz
In which of the following ways can SQL Plan baselines be loaded? 1. Automatically by setting OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE
4. Automatically by default
2. From SQL Performance Analyzer SQL Tuning Set (STS) by using the DBMS_SPM package 3. From the cursor cache by using the DBMS_SPM package
Possible SQL Plan Manageability Scenarios

Database Upgrade
Oracle Database 11g
Plan History ba s an Pl GB eline
HJ HJ
New Application Deployment

Production database
Plan History ba s an Pl GB eline
HJ HJ
GB HJ HJ
GB HJ HJ
No plan regressions
No plan regressions
DBA
DBA
GB
Plan history ba s an Pl GB eline

HJ HJ
Welltuned plan
GB HJ HJ
HJ HJ
Well-tuned plan
Baseline plans staging table
Oracle Database 10g
Development database
Possible SQL Plan Manageability Scenarios Database upgrade: Bulk SQL plan loading is especially useful when the system is being upgraded from an earlier version to Oracle Database 11g. For this, you can capture plans for a SQL workload into a SQL Tuning Set (STS) before the upgrade, and then load these plans from the STS into the SQL plan baseline immediately after the upgrade. This strategy can minimize plan regressions resulting from the use of the new optimizer version. New application deployment: The deployment of a new application module means the introduction of new SQL statements into the system. The software vendor can ship the application software along with the appropriate SQL plan baselines for the new SQL being introduced. Because of the plan baselines, the new SQL statements will initially run with the plans that are known to give good performance under a standard test configuration. However, if the customer system configuration is very different from the test configuration, the plan baselines can be evolved over time to produce better performance. In both scenarios, you can use the automatic SQL plan capture after manual loading to make sure that only better plans will be used for your applications in the future. Note: In all scenarios in this lesson, assume that OPTIMIZER_USE_SQL_PLAN_BASELINES is set to TRUE.
SQL Performance Analyzer and SQL Plan Baseline Scenario

Before change
Oracle Database 11g

O_F_E=10
Plan History ba se an lin Pl GB e
HJ HJ
GB HJ HJ
Regressing statements After change
No plan regressions
O_F_E=11
optimizer_features_enable
GB HJ HJ
GB HJ HJ
GB HJ HJ
Oracle Database 10g
Welltuned plans
SQL Performance Analyzer and SQL Plan Baseline Scenario A variation of the first method described in the previous slide is through the use of SQL Performance Analyzer as follows: 1. You can capture preOracle Database 11g plans in an STS and import them into Oracle Database 11g. 2. Then set the OPTIMIZER_FEATURES_ENABLE initialization parameter to 10.2 to make the optimizer behave as if this were a 10g Oracle database. 3. Next run SQL Performance Analyzer for the STS. 4. When that is complete, set the OPTIMIZER_FEATURES_ENABLE initialization parameter back to 11.2 and rerun SQL Performance Analyzer for the STS. SQL Performance Analyzer produces a report that lists a SQL statement whose plan has regressed from 10g to 11g. For those SQL statements that are shown by SQL Performance Analyzer to incur performance regression due to the new optimizer version, you can capture their plans using an STS and then load them into the SMB. This method represents the best form of the plan-seeding process because it helps prevent performance regressions while preserving performance improvements upon database upgrade.
Loading a SQL Plan Baseline Automatically

Oracle Database 11g
Plan history Plan baseline
GB HJ HJ
No plan regressions
Oracle Database 11g

New plan waiting verification
GB HJ HJ
No plan regressions

GB HJ HJ
GB HJ HJ
GB HJ HJ
OPTIMIZER_FEATURES_ENABLE=10.2.0.2 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
Oracle Database 11g

GB GB HJ HJ GB HJ HJ GB HJ HJ GB HJ HJ
Better plans
Welltuned plans
HJ HJ
Oracle Database 10g
Loading a SQL Plan Baseline Automatically: Scenario Another upgrade scenario involves using the automatic SQL plan capture mechanism. In this case, set the OPTIMIZER_FEATURES_ENABLE initialization parameter to the preOracle Database 11g version value for an initial period of time such as a quarter, and execute your workload after upgrade by using the automatic SQL plan capture. During this initial time period, because of the OPTIMIZER_FEATURES_ENABLE parameter setting, the optimizer is able to reproduce preOracle Database 11g plans for a majority of the SQL statements. Because automatic SQL plan capture is also enabled during this period, the preOracle Database 11g plans produced by the optimizer are captured as SQL plan baselines. When the initial time period ends, you can remove the setting of OPTIMIZER_FEATURES_ENABLE to take advantage of the new optimizer version while incurring minimal or no plan regressions due to the plan baselines. Regressed plans will use the previous optimizer version; nonregressed statements will benefit from the new optimizer version.
Purging SQL Management Base Policy

SQL> exec dbms_spm.configure('SPACE_BUDGET_PERCENT',20); SQL> exec dbms_spm.configure('PLAN_RETENTION_WEEKS',105);
DBA_SQL_MANAGEMENT_CONFIG time 105

SQL Management Base
Alert log
53
1%
10%
20%
50%
space
SQL> exec :cnt := dbms_spm.drop_sql_plan_baseline('SYS_SQL_37e0168b04e73efe');
Purging SQL Management Base Policy The space occupied by the SQL Management Base (SMB) is checked weekly against a defined limit. A limit based on the percentage size of the SYSAUX tablespace is defined. By default, the space budget limit for the SMB is set to 10 percent of SYSAUX size. However, you can configure SMB and change the space budget to a value between 1 percent and 50 percent by using the DBMS_SPM.CONFIGURE procedure. If SMB space exceeds the defined percent limit, warnings are written to the alert log. Warnings are generated weekly until the SMB space limit is increased, the size of SYSAUX is increased, or the size of SMB is decreased by purging some of the SQL management objects (such as SQL plan baselines or SQL profiles). The space management of SQL plan baselines is done proactively using a weekly purging task. The task runs as an automated task in the maintenance window. Any plan that has not been used for more than 53 weeks is purged. However, you can configure SMB and change the unused plan retention period to a value between 5 weeks and 523 weeks (a little more than 10 years). To do so, use the DBMS_SPM.CONFIGURE procedure. You can look at the current configuration settings for the SMB by examining the DBA_SQL_MANAGEMENT_CONFIG view. In addition, you can manually purge the SMB by using the DBMS_SPM.DROP_SQL_PLAN_BASELINE function (as shown in the example in the slide).
SYSAUX
Enterprise Manager and SQL Plan Baselines
Enterprise Manager and SQL Plan Baselines Access the SQL Plan Control page by clicking SQL Plan Control in the Query Optimizer region of the Server page. Use the SQL Plan Control page to manage SQL profiles, SQL patches, and SQL plan baselines from one location rather than separate locations in Enterprise Manager. You can also enable, disable, drop, pack, unpack, load, and evolve selected baselines. From this page, you can also configure the various SQL plan baseline settings.
11.2
Using the MIGRATE_STORED_OUTLINE Functions
Specify stored outlines to be migrated based on outline name, SQL text, or outline category, or migrate all stored outlines in the system to SQL plan baselines:
DBMS_SPM.MIGRATE_STORED_OUTLINE ( attribute_name IN VARCHAR2, attribute_value IN CLOB, fixed IN VARCHAR2 := 'NO') RETURN CLOB;
Specify one or more stored outlines to be migrated:

DBMS_SPM.MIGRATE_STORED_OUTLINE ( outln_list IN DBMS_SPM.NAME_LIST, fixed IN VARCHAR2 := 'NO') RETURN CLOB;
Using the MIGRATE_STORED_OUTLINE Functions You can use the DBMS_SPM.MIGRATE_STORED_OUTLINE function to migrate stored outlines for one or more SQL statements to plan baselines in the SQL management base (SMB). Specify which stored outlines to migrate based on the outline name, SQL text, or outline category. You can also migrate all stored outlines in the system to SQL plan baselines. Parameters are as follows: attribute_name: Specifies the type of parameter used in attribute_value to identify the migrated stored outlines. Values (case-sensitive) are outline_name, sql_text, category, and all. attribute_value: Based on the value specified in attribute_name. NULL if attribute_name is all. fixed: Values of NO (default) and YES. Specifies the fixed status of the plans generated during migration. By default, plans are generated as non-fixed plans. The second overload of the function is used to migrate stored outlines for one or more SQL statements to plan baselines in the SQL management base (SMB) given one or more outline names. Parameters are as follows: outln_list: List of outline names to be migrated fixed: Values of NO (default) and YES. Specifies the fixed status of the plans generated during migration. By default, plans are generated as non-fixed plans. A CLOB is returned containing a formatted report describing the statistics during the migration.
Summary
In this lesson, you should have learned how to: Set up SQL Plan Management Set up various SQL Plan Management scenarios Migrate stored outlines to SQL Plan baselines
This practice covers the use of SQL Plan Management.
Database Replay
Objectives
After completing this lesson, you should be able to: Identify the benefits of using Database Replay List the steps involved in Database Replay Use Enterprise Manager to record and replay workloads
Why Use Database Replay?
Despite expensive testing, success rates are low:

Many issues go undetected. Changes can negatively affect system availability and performance. Inability to properly test with real-world production workloads, with many issues going undetected.
Cause of low success rate:
The Database Replay feature makes it possible to do real-world testing.

Why Use Database Replay? Large business-critical applications are complex and experience highly varying load and usage patterns. At the same time, these business systems are expected to provide certain service-level guarantees in terms of response time, throughput, uptime, and availability. Often any change to a system, such as upgrading the database or modifying the configuration, necessitates extensive testing and validation before these changes can make it to the production system. To be confident before moving to a production system, the database administrator (DBA) needs to expose a test system to a workload very similar to the workload that is expected in the production environment. It is also beneficial for the DBA to have an effective means of analyzing the impact of system-level changes on overall SQL performance so that any tuning changes required can be performed before production. Note: Database Replay is part of the Oracle Real Application Testing option.
System changes (such as hardware and software upgrades) are a fact of life. Customers want to identify the full impact of changes before going live. Extensive testing and validation can be expensive in terms of time and money.
Using Database Replay

Re-create actual production database workload in test environment. Identify and analyze potential instabilities before making changes to production. Capture workload in production:
Capture full production workload with real load & concurrency Move the captured workload to test system Make the desired changes in test system Replay workload with production load & concurrency Honor commit ordering
Analyze and report:

Errors Data divergence Performance divergence
Using Database Replay A useful application of Database Replay is to test the performance of a new server configuration. Consider a customer who is utilizing a single instance database and wants to move to a RAC setup. The customer records the workload of an interesting period and then sets up a RAC test system for replay. During replay, the customer is able to monitor the performance benefit of the new configuration by comparing the performance to the recorded system. This can also help convince the customer to move to a RAC configuration after seeing the benefits of using the Database Replay functionality. Another application is debugging. You can record and replay sessions emulating an environment to make bugs more reproducible. Manageability feature testing is another benefit. Self-managing and self-healing systems need to implement this advice automatically (autonomic computing model). Multiple replay iterations allow testing and fine-tuning of the control strategies effectiveness and stability. Note: Database Replay supports workload capture on a system running Oracle Database 10g Release 2 (10.2.0.4) and later releases. Workload replay is only supported on systems running Oracle Database 11g Release 1 and later releases.
Replay workload in test:
The Big Picture

Prechange production system
Clients/app servers
Postchange test system Capture directory Process capture files Shadow capture file Shadow capture file Shadow capture file
Replay system
Production database
Database backup Can use Snapshot Standby as test system
Database restore
The Big Picture Database Replay allows you to test the impact of a system change by replaying a real-world workload on the test system before it is exposed to a production system. The production workload (including transaction concurrency and dependency) of the database server is recorded over an illustrative period of time (for example, a peak period). This recorded data is used to replay the workload on a test system that has been appropriately configured. You gain a high degree of confidence in the overall success of the database change by subjecting the database server in a test system to a workload that is practically indistinguishable from a production workload. Many Oracle customers have expressed strong interest in the change-assurance functionality offered by Database Replay. The database administrator, or a user with special privileges granted by the DBA, initiates the record-and-replay cycle and has full control over the entire procedure.
Production system
Shadow capture file
Test system with changes
System Architecture: Capture
Capture directory Shadow Shadow Shadow Shadow Shadow capture file Shadow capture file Recording infrastructure Database stack Shadow capture file
Background
Background
Database backup Production database
System Architecture: Capture On this page you see an illustration of a system that is being recorded. You should always record a workload that spans an interesting period in a production system. Typically, the replay of the recording is used to determine whether it is safe to upgrade to a new version of the RDBMS server. A special recording infrastructure built into the RDBMS records data about all external client requests while the production workload is running on the system. External requests are any SQL queries, PL/SQL blocks, PL/SQL remote procedure calls, DML statements, DDL statements, Object Navigation requests, or Oracle Call Interface (OCI) calls. During the recording, background jobs and, in general, all internal clients continue their work without being recorded. The end product is a workload recording containing all necessary information for replaying the workload as seen by the RDBMS in the form of external requests. The recording infrastructure imposes minimal performance overhead (extra CPU, memory, and input/output) on the recording system. You should, however, plan to accommodate the additional disk space needed for the actual workload recording. RAC Note: Instances in a RAC environment have access to the common database files. However, they do not need to share a common general-purpose file system. In such an environment, the workload recording is written on each instances file system during recording. For preprocessing and replay, all parts of the workload recording need to be manually copied into a single directory.
Shadow capture file
System Architecture: Preprocessing the Workload

Capture directory Preprocess capture files Shadow capture file Shadow capture file Shadow capture file
Database stack
Background
Background
Database backup Production database
Preprocess capture
System Architecture: Preprocessing the Workload The workload capture data is preprocessed and new workload replay-specific metadata files are created that are required for the replay of the given workload capture. Only new files are created; no files are modified that were created during the workload capture. Because of this, you can run the preprocess multiple times on the same capture directory (for example, when the procedure encounters unexpected errors or is canceled). External client connections are remapped at this stage. Any replay parameters that affect the replay outcome can be modified. Note: Because preprocessing the workload capture data can be relatively expensive, the best practice is to perform that operation on a system other than the production database system.
Shadow capture file
System Architecture: Replay

Replay system
Replay client Replay client
Preprocess capture files
Capture directory Shadow capture file Shadow capture file Shadow capture file
Shadow
Shadow
Shadow
Shadow
Database stack
Background
Background
Database backup
Test system with changes
Test database
System Architecture: Replay Before replaying the workload on the replay system, be sure to do the following: 1. Restore the replay database on a test system to match the capture database at the start of the workload capture. 2. Make changes (such as performing an upgrade) to the test system as needed. 3. Copy the workload to the test system. The workload recording is consumed by a special application called the replay driver, which sends requests to the RDBMS on which the workload is replayed. The RDBMS on which the workload is replayed is usually a test system. It is assumed that the database of the replay system is suitable for the replay of the workload that was recorded. The internal RDBMS clients are not replayed. The replay driver is a special client that consumes the workload recording and sends appropriate requests to the test system to make it behave as if the external requests were sent by the clients used during the recording of the workload (see previous example). The use of a special driver that acts as the sole external client to the RDBMS enables the record-and-replay infrastructure to be client agnostic. The replay driver consists of one or more clients that connect to the replay system and the replay driver sends requests based on the workload capture. The replay driver equally distributes the workload capture streams among all the replay clients based on the network bandwidth, CPU, and memory capability.
Shadow capture file
Prechange Production System

Changes not supported
Clients/app servers
Production system
Production database
Prechange Production System Database Replay focuses on recording and replaying the workload that is directed to the RDBMS. Therefore, recording the workload is done at the point indicated in the diagram in the slide. Recording at the RDBMS in the software stack makes it possible to exchange anything below this level and test the new setup using the record-and-replay functionality. While replaying the workload, the RDBMS performs the actions observed during recording. In other words, during the replay phase the RDBMS code is exercised in a way that is very similar to the way it was exercised during the recording phase. This is achieved by re-creating all external client requests to the RDBMS. External client requests include all the requests by all possible external clients of the RDBMS.
Supported changes: Database upgrades, patches Schema, parameters RAC nodes, interconnect OS platforms, OS upgrades CPU, memory Storage
Supported Workloads
Supported:
11.2 update
Limitations:
Direct path load of data from external files using utilities Advanced replication streams Non-PL/SQL-based Advanced Queuing (AQ) Flashback queries Oracle Call Interface (OCI)based object navigations Non-SQL-based object access Distributed transactions
Supported Workloads The slide shows supported and nonsupported database operations. The following types of client requests are not captured in a workload: Direct path load of data from external files using utilities such as SQL*Loader Advanced replication streams Non-PL/SQL-based Advanced Queuing (AQ) Flashback queries Oracle Call Interface (OCI)based object navigations Non-SQL-based object access Distributed transactions (any distributed transactions that are captured will be replayed as local transactions) Note: SQL-based XML manipulations are also captured. The system only captures explicit SQL statements (SQL statements issued by clients). Implicit calls generated by the database itself are not captured. For example, auditing is implicit, like background processes activity is implicit.
All SQL (DML, DDL, PL/SQL) with practically all types of binds Full LOB functionality (cursor-based and direct OCI) Local transactions Logins and logoffs Session switching Limited PL/SQL RPCs
Capture Considerations
Planning: Adequate disk space for captured workload (binary files) Database restart:
Only way to guarantee authentic replay

Startup restrict Capture will un-restrict
May not be necessary depending on the workload
A way to restore database for replay purposes:
Filters can be specified to capture subset of the workload. SYSDBA or SYSOPER privileges and appropriate OS privileges
Overhead: Performance overhead for TPCC is 4.5% Memory overhead : 64 KB per session Disk space
Capture Considerations You perform the following tasks in the planning phase of the workload recording: Check the database backup strategy, ensuring that the database can be restored to StartSCN when the recording starts. Plan the capture period by selecting it based on the application and the peak periods. You can use existing manageability features such as Automatic Workload Repository (AWR) and Active Session History (ASH) to select an appropriate period based on workload history. The starting time for capture should be carefully planned because it is recommended that you shut down and restart the database before starting the capture. Specify the location of the workload capture data. You must set up a directory that is to be used to store the workload capture data. You should provide ample disk space because the recording stops if there is insufficient disk space. However, everything captured up to that point is usable for replay. Define capture filters for user sessions that are not to be captured. You can specify a recording filter to skip sessions that should not be captured. No new privileges or user roles are introduced with the Database Replay functionality. The recording user and replay user must have either the SYSDBA or SYSOPER privilege. This is because only a user having SYSOPER or SYSDBA can start up or shut down the database to start the recording. Correct operating system (OS) privileges should also be assigned so that the user is able to access the recording, replay directories, and manipulate the files under those directories.
Physical restore (scn/time provided) Logical restore of application data Flashback/snapshot standby
Replay Considerations
Preprocess captured workload:

One-time action On same DB version as the replay system On a system other than the production server (recommendation) Can be performed anywhere if versions match
Restore database, and then perform the change:

Upgrade Schema changes OS change Hardware change Add instance
Replay Considerations The preprocess phase is a once-only required action for the specified database version. After the necessary metadata has been created, you can replay the workload as many times as required. You must restore the replay database to match the capture database at the start of the workload capture. A successful replay depends on the application transactions accessing the application data identical to that on the capture system. You can choose to restore the application data using point-intime recovery, flashback, and import/export.
Replay Considerations
Manage external interactions

Remap connection strings to be used for the workload:

One-to-one: For simple instance-to-instance remapping Many-to-one: Use of load balancer (e.g., single node to RAC)
Set up one or more replay clients

Multithreaded clients that can each drive multiple workload sessions
Replay Considerations (continued) A captured workload may contain references to external systems that are meaningful only in the capture environment. Replaying a workload with unresolved references to external systems may cause unexpected problems in the production environment. A replay should be performed in a completely isolated test environment. You should make sure that all references to external systems have been resolved in the replay environment such that replaying a workload will cause no harm to your production environment. You can make one-to-one or many-to-one remappings. For example, database links in a captured production environment may reference external production databases that should not be referenced during replay. Therefore, you should modify any external references that could jeopardize the production environment during replay. The replay client (an executable named wrc) submits a captured sessions workload. You should install one or more replay clients, preferably on systems other than the production host. Each replay client must be able to access the directory that holds the preprocessed workload. You can also modify the replay parameters to change the behavior of the replay.
Modify DB Links and directory objects that point to production systems
Replay Options
11.2 update
Synchronized replay:
Ensures minimal data divergence Commit-based synchronization
Unsynchronized replay:
Useful for load/stress testing Original commit ordering not honored High data divergence
Login time options

Percentage (default is 100%)
Replay Options The following replay options can be modified while replaying your workload: The SYNCHRONIZATION parameter determines whether synchronization will be used during workload replay. - If this parameter is set to SCN, the COMMIT order in the captured workload will be preserved during replay and all replay actions will be executed only after all dependent COMMIT actions have completed. SCN is the default. - If this parameter is set to OBJECT_ID, all replay actions will be executed only after all relevant COMMIT actions have completed. Relevant COMMIT actions are COMMIT actions that are issued before the given action in the workload capture, and that modify at least one of the database objects for which the given action is referencing either implicitly or explicitly. - If this parameter is set to OFF, the option is disabled and the replay will likely yield significant data divergence. This may be acceptable if the workload consists primarily of independent transactions. The CONNECT_TIME_SCALE parameter scales the elapsed time from when the workload capture started to when the session connects with the specified value; it is interpreted as a percentage. Use this option to manipulate the session connect time during replay. The default value is 100.
Replay Options
11.2 update
Think time options:

Auto (default) Adjust think time to maintain the captured request rate:

Workload scale-up during replay:

Replay captured session concurrently for specified number of times. Only one session in each set of identical replay sessions will execute both queries and updates.
Replay Options (continued) The THINK_TIME_SCALE parameter scales the elapsed time between two successive user calls from the same session; it is interpreted as a percentage value. Use this parameter to increase or decrease the replay speed. Setting this parameter to 0 will send user calls to the database as fast as possible during replay. The default value is 100. The THINK_TIME_AUTO_CORRECT parameter corrects the think time (based on the THINK_TIME_SCALE parameter) between calls, when user calls take longer to complete during replay than during capture. Its value can be TRUE or FALSE. Note: During workload capture, elapsed time is measured by user time and user think time. User time is the elapsed time of a user call to the database. User think time is the elapsed time while the user waits between issuing calls. During workload replay, elapsed time is measured by user time, user think time, and synchronization time. The SCALE_UP_MULTIPLIER parameter defines the number of times the workload is scaled up during replay. Each captured session will be replayed concurrently for as many times as specified by this parameter. However, only one session in each set of identical replay sessions will execute both queries and updates. The rest of the sessions will only execute queries.
0%: No think time (highest possible request rate) <100%: Higher request rate 100%: Exact think time >100%: Lower request rate
11.2
Workload Replay Filters

Use workload filters to specify which database calls to include in or exclude from the workload. Types of workload replay filters:
Inclusion filter: Specifies database calls that will be replayed Exclusion filter: Specifies database calls that will not be replayed
Create and use workload replay filters as follows:

1. Use DBMS_WORKLOAD_REPLAY.ADD_FILTER to define the workload replay filters. 2. Use DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET to add the workload replay filters to a replay filter set. 3. Use DBMS_WORKLOAD_REPLAY.USE_FILTER_SET to filter the replay.
Workload Replay Filters You can use workload filters to specify which database calls to include in or exclude from the workload during workload replay. There are two types of workload filters: inclusion filters and exclusion filters. Inclusion filters enable you to specify database calls that will be replayed. Exclusion filters enable you to specify database calls that will not be replayed. You can use either inclusion filters or exclusion filters in a workload replay, but not both. To use workload replay filters, perform the following steps: 1. Define the workload replay filters by using DBMS_WORKLOAD_REPLAY.ADD_FILTER. ADD_FILTER includes the following parameters: - FNAME: Specifies the name of the filter that will be added - FATTRIBUTE: Specifies the attribute on which the filter will be applied. Valid values include PROGRAM, MODULE, ACTION, SERVICE, USER, and CONNECTION_STRING. - FVALUE: Specifies the value for the corresponding attribute on which the filter will be applied 2. Add the workload replay filters to a replay filter set by using DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET. When you create a replay filter set, all workload replay filters that were added since the previous replay filter set was created will be used.
Workload Replay Filters (continued) CREATE_FILTER_SET includes the following parameters: - REPLAY_DIR: Specifies the directory where the replay to be filtered is stored - FILTER_SET: Specifies the name of the filter set to create - DEFAULT_ACTION: Specifies whether every captured database call should be replayed and whether the workload replay filters should be considered as inclusion (INCLUDE) or exclusion (EXCLUDE) filters. INCLUDE is the default. 3. After the replay is initialized, you can use the replay filter set to filter the replay in the replay_dir directory. To use a replay filter set, use the DBMS_WORKLOAD_REPLAY.USE_FILTER_SET procedure and specify the filter set name.
Replay Analysis
Data divergence
Number of rows compared for each call (queries, DML)
Error divergence:
New errors Mutated errors Errors that have disappeared
Performance:
Capture and Replay report ADDM report ASH report for skew analysis AWR report
Replay Analysis There may be some divergence of the replay compared to what was recorded. For example, when replaying on a newer version of the RDBMS, a new algorithm may cause specific requests to be faster, resulting in divergence appearing as a faster execution. This is considered a desirable divergence. Another example of a divergence is when a SQL statement returns fewer rows during replay than those returned during recording. This is clearly undesirable. For data divergence, the result of an action can be considered as: The result set of SQL query An update to persistent database state A return code or error code Performance divergence is useful in determining how new algorithms introduced in the replay system may affect overall performance. There are numerous factors that can cause replay divergence. Though some of them cannot be controlled, others can be mitigated. It is the task of the DBA to understand the workload run-time operations and take the necessary actions to reduce the level of record-and-replay divergence. Online divergence should aid the decision to stop a replay that has diverged significantly. The results of the replay before the divergence may still be useful, but further replay would not produce reliable conclusions. Offline divergence reporting is used to determine how successful the replay was after the replay has finished.
Replay Analysis (continued) Data divergence of the replay encompasses the results of both queries and errors. That is, errors that occurred during recording are considered proper results and any change during replay is reported. You can use existing tools such as ADDM to measure performance differences between the recording system and the replay system. Additionally, error comparison reports during the replay report on the following: Errors that did not happen during recording Errors that were not reproduced during replay Difference in error type
Quiz
You can preprocess the workload capture data multiple times because the files that are created during the workload capture are not modified during the preprocess. 1. True 2. False
Answer: 1
Database Replay Workflow in Enterprise Manager
Database Replay Workflow in Enterprise Manager The following are the typical steps to perform Database Replay: 1. Capture the workload on a database by using the Enterprise Manager Capture Workload wizard. 2. Optionally export the AWR data after capturing the workload. The wizard prompts you to export the data after you stop your workload capture. 3. Restore the replay database on a test system to match the capture database at the start of the workload capture. 4. Make changes (such as performing an upgrade) to the test system as required. 5. Copy the generated workload files to the test system. 6. Preprocess the captured workload on the test system by using the Enterprise Manager Preprocess Captured Workload wizard. 7. Configure the test system for the replay. 8. Replay the workload on the restored database by using the Replay Workload wizard.
1. Capture the workload on a database by using the Capture Workload wizard. 2. Optionally export the AWR data by using the Capture Workload wizard. 3. Restore the replay database on a test system. 4. Make changes to the test system as required. 5. Copy the workload to the test system. 6. Preprocess the captured workload by using the Preprocess Captured Workload wizard. 7. Configure the test system for the replay. 8. Replay the workload on the restored database by using the Replay Workload wizard.
Accessing Database Replay
Accessing Database Replay Enterprise Manager provides you with a user interface to manage each component in the Database Replay process. The workflow and user interface applies to both Enterprise Manager Database Control and Enterprise Manager Grid Control. You access Database Replay on the Software and Support tab of Database Control. On the Database Replay page, you can perform the following named tasks: Capture Workload Preprocess Capture Workload Replay Workload View Workload Capture History: Click this link to view or delete the history of all workload captures. Active Capture and Replay: If a capture or replay is currently in progress, this table appears at the bottom of the page even if there are no rows. To view the status of the capture or replay, select the name and click View, or just click the Name link. RAC Note: When an instance goes down during capture of a RAC system, the capture continues normally and is not aborted. The sessions that died as a result of an instance going down will be replayed up to the point at which the instance died. When a dead instance is repaired and comes up again during capture, all new sessions are recorded normally. During replay, the death of instances is not replayed.
Packages and Procedures
11.2 update
DBMS_WORKLOAD_CAPTURE
START_CAPTURE FINISH_CAPTURE ADD_FILTER DELETE_FILTER DELETE_CAPTURE_INFO GET_CAPTURE_INFO() EXPORT_AWR IMPORT_AWR() REPORT()
DBMS_WORKLOAD_REPLAY
PROCESS_CAPTURE INITIALIZE_REPLAY PREPARE_REPLAY START_REPLAY CANCEL_REPLAY DELETE_REPLAY_INFO REMAP_CONNECTION EXPORT_AWR IMPORT_AWR GET_REPLAY_INFO REPORT COMPARE_PERIOD_REPORT
Packages and Procedures You need the EXECUTE privilege on the capture and replay packages to execute these packages. These privileges are usually assigned by the DBA. Note: For further details about the DBMS_WORKLOAD packages, see the Oracle Database PL/SQL Packages and Types Reference 11g.
Database Replay: PL/SQL Example

exec DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname => 'sessfilt',fattribute => USER ,fvalue => 'JFV'); exec DBMS_WORKLOAD_CAPTURE.START_CAPTURE(name => 'june_peak',dir => 'jun07');
Execute your workload

exec DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE(); exec DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => 'jun07'); wrc userid=system password=oracle replaydir=/dbreplay exec DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_name => 'j_r' ,replay_dir => 'jun07');
Database Replay: PL/SQL Example In this example, the ADD_FILTER procedure adds a filter named sessfilt that will filter out all sessions belonging to the user name JFV. To start the workload capture, use the START_CAPTURE procedure. In this example, a capture named june_peak is captured and stored in a directory named jun07. Because the duration parameter is not specified, the workload capture continues until the FINISH_CAPTURE procedure is called. At this point, you can run your workload. To stop the workload capture, use the FINISH_CAPTURE procedure. This procedure finalizes the workload capture and returns the database to a normal state. You can now generate a capture report by using the REPORT function. To preprocess a captured workload, use the PROCESS_CAPTURE procedure. In this example, the captured workload stored in the jun07 directory is preprocessed. When finished, you can start your replay clients. To initialize replay data, use the INITIALIZE_REPLAY procedure. Initializing replay data loads the necessary metadata into tables required by the workload replay. For example, captured connection strings are loaded into a table where they can be remapped for replay. In this example, the INITIALIZE_REPLAY procedure loads preprocessed workload data from the jun07 directory into the database.
Database Replay: PL/SQL Example

exec DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION(connection_id => 101,replay_connection => 'edlin44:3434/bjava21'); exec DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => TRUE,think_time_scale=> 2); exec DBMS_WORKLOAD_REPLAY.START_REPLAY ();
Database Replay: PL/SQL Example (continued) To remap connections, use the REMAP_CONNECTION procedure. In this example, the connection that corresponds to the connection ID 101 will use the new connection string defined by the replay_connection parameter. To prepare workload replay on the replay system, use the PREPARE_REPLAY procedure. In this example, the PREPARE_REPLAY procedure prepares the j_r replay to preserve the COMMIT order in the workload capture. To start a workload replay, use the START_REPLAY procedure. To stop a workload replay, use the REPLAY_CANCEL procedure To generate a workload replay report, use the REPORT function as shown in the slide.
DECLARE cap_id NUMBER; rep_id NUMBER; rep_rpt CLOB; BEGIN cap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO(dir => 'jun07'); /* Get the latest replay for that capture */ SELECT max(id) INTO rep_id FROM dba_workload_replays WHERE capture_id = cap_id; rep_rpt := DBMS_WORKLOAD_REPLAY.REPORT(replay_id => rep_id, format => DBMS_WORKLOAD_REPLAY.TYPE_TEXT); END;
Data Dictionary Views: Database Replay
Data Dictionary Views: Database Replay For information about these views, see the Oracle Database Reference.
DBA_WORKLOAD_CAPTURES: Lists all the workload captures performed in the database DBA_WORKLOAD_FILTERS: Lists all the workload filters defined in the database DBA_WORKLOAD_REPLAYS: Lists all the workload replays that have been performed in the database DBA_WORKLOAD_REPLAY_DIVERGENCE: Is used to monitor workload divergence DBA_WORKLOAD_CONNECTION_MAP: Is used to review all connection strings that are used by workload replays V$WORKLOAD_REPLAY_THREAD: Monitors the status of external replay clients
Calibrating Replay Clients

$ wrc system/oracle@orcl mode=calibrate replaydir=/dbreplay Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Copyright (c) 1982, 2007, Oracle. All rights reserved. Report for Workload in: /dbreplay ----------------------Recommendation: Consider using at least 1 clients divided among 1 CPU(s). Workload Characteristics: - max concurrency: 4 sessions - total number of sessions: 11 Assumptions: - 1 client process per 50 concurrent sessions - 4 client process per CPU - think time scale = 100 - connect time scale = 100 - synchronization = TRUE $
Calibrating Replay Clients Because one replay client can initiate multiple sessions with the database, it is not necessary to start a replay client for each session that was captured. The number of replay clients that need to be started depends on the number of workload streams, the number of hosts, and the number of replay clients for each host. For example, suppose that a workload capture has 1,000 streams, that the number of average active sessions from the workload capture is about 60, and that one host can drive only 50 concurrent connections to the database. You should use two hosts, each with a replay client. To estimate the number of replay clients and hosts that are required to replay a particular workload, run the wrc executable in calibrate mode. In calibration mode, the wrc executable accepts the following parameters: replaydir specifies the directory that contains the preprocessed workload capture that you want to replay. If unspecified, it defaults to the current directory. process_per_cpu specifies the maximum number of client processes that can run for each CPU. The default value is 4. threads_per_process specifies the maximum number of threads that can run in a client process. The default value is 50. The example in the slide shows how to run the wrc executable in the calibrate mode. In this example, the wrc executable is executed to estimate the number of replay clients and hosts that are required to replay the workload capture stored in the directory named replay. Note: To list the hosts that participated in the capture, use the list_hosts mode.
Summary
In this lesson, you should have learned how to: Identify the benefits of using Database Replay List the steps involved in Database Replay Use Enterprise Manager to record and replay workloads
This practice covers using Database Replay with Enterprise Manager in the following scenarios: Replaying in synchronous mode without changes Replaying in synchronous mode after changes are applied Replaying in nonsynchronous mode without changes
Automatic SQL Tuning

Objectives
After completing this lesson, you should be able to: Set up and modify Automatic SQL Tuning Use the PL/SQL interface to perform fine tuning View and interpret reports generated by Automatic SQL Tuning
SQL Tuning in Oracle Database 10g
Workload 1
Accept profiles
Automatic
High load
SQL Tuning Advisor

Generate SQL profiles
2 ADDM 3
DBA
Run SQL Tuning Advisor
SQL Tuning in Oracle Database 10g Oracle Database 10g introduced SQL Tuning Advisor to help DBAs and application developers improve the performance of SQL statements. The advisor targets the problem of poorly written SQL, in which SQL statements have not been designed in the most efficient fashion. It also targets the (more common) problem in which a SQL statement is performing poorly because the optimizer generated a poor execution plan due to a lack of accurate and relevant data statistics. In all cases, the advisor makes specific suggestions for speeding up SQL performance, but it leaves the responsibility of implementing the recommendations to the user. In addition to SQL Tuning Advisor, Oracle Database 10g has an automated process to identify highload SQL statements in your system. This is done by the Automatic Database Diagnostic Monitor (ADDM), which automatically identifies high-load SQL statements that are good candidates for tuning. However, major issues still remain: Although it is true that ADDM identifies some SQL that should be tuned, users must manually look at ADDM reports and run SQL Tuning Advisor on those reports for tuning.
Automatic SQL Tuning in Oracle Database 11g

AWR
2
p To L SQ
Workload
Auto matic
3 1
SQL Tuning
ep R ts or
DBA
Automatic SQL Tuning in Oracle Database 11g Oracle Database 11g further automates the SQL Tuning process by identifying problematic SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL profile recommendations to tune the statement without requiring user intervention. Automatic SQL Tuning uses the AUTOTASK framework through a new task called Automatic SQL Tuning that runs every night by default. Here is a brief description of the automated SQL tuning process in Oracle Database 11g: Step 1: Based on the AWR Top SQL identification (SQLs that were top in four different time periods: the past week, any day in the past week, any hour in the past week, or single response time), Automatic SQL Tuning targets statements for automatic tuning. Steps 2 and 3: While the Automatic SQL Tuning task is executing during the maintenance window, the previously identified SQL statements are automatically tuned by invoking SQL Tuning Advisor. As a result, SQL profiles will be created for them if needed. However, before making any decision, the new profile is carefully tested. Step 4: At any point in time, you can request a report about these automatic tuning activities. You then have the option of checking the tuned SQL statements to validate or remove the automatic SQL profiles that were generated. The Oracle Tuning Pack includes the Automatic SQL Tuning feature.
Summary of Automation in Oracle Database 11g

Task runs automatically (AUTOTASK framework) Workload automatically chosen (no SQL Tuning Set) SQL profiles automatically tested SQL profiles can be configured for automatic implementation SQL statements automatically retuned if they regress Reporting available over any time period
Summary of Automation in Oracle Database 11g More information is provided on these points in the lesson.
Selecting Potential SQL Statements for Tuning
AWR
Weekly Daily Hourly Avrg execution
1. Pull the top queries from the past week into four buckets: Top for the past week Top for any day in the past week Top in any single hour Top by average single execution 2. Combine four buckets into one (assigning weights). 3. Cap at 150 queries per bucket.
Selecting Potential SQL Statements for Tuning Oracle Database 11g analyzes the statistics in the AWR and generates a list of potential SQL statements that are eligible for tuning. These statements include repeating high-load statements that have a significant impact on the system. Only SQL statements that have an execution plan with a high potential for improvement will be tuned. Recursive SQL and statements that have been tuned recently (in the last month) are ignored, as are parallel queries, DMLs, DDLs, and SQL statements with performance problems that are caused by concurrency issues. The SQL statements that are selected as candidates are then ordered based on their performance impact. The performance impact of a SQL statement is calculated by summing the CPU time and the I/O times captured in the AWR for that SQL statement in the past week.
Candidate list
Maintenance Window Timeline

Automatic SQL Tuning task
Pick candidate SQL
Tune S1
Test P1
Accept P1
Tune S2
One hour maximum (by default)
Maintenance window
Maintenance Window Timeline The Automatic SQL Tuning process takes place during the maintenance window. Furthermore, it runs as part of a single AUTOTASK job on a single instance to avoid concurrency issues. This is portrayed in the slide for one scenario. In this scenario, at some time after the beginning of the maintenance window, AUTOTASK starts the Automatic SQL Tuning job (SYS_AUTO_SQL_TUNING_TASK). The first thing that the job does is to generate a list of candidate SQL for tuning, according to the AWR source. When the list is complete, the job tunes each statement in order of importance, one after another, considering only one statement at a time. In this scenario, it first tunes S1, which has a SQL profile recommendation (P1) generated for it by SQL Tuning Advisor. After P1 has been successfully tested, it is accepted and the job moves on to the next statement, S2. By default, Automatic SQL Tuning runs for at most one hour during a maintenance window. You can change this setting by using a call similar to the following: DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER('SYS_AUTO_SQL_TUNING_TASK', 'TIME_LIMIT', 7200); Note: The widths of boxes in the slide do not indicate relative execution times. Tuning and test execution should be the most expensive processes by far, with all the others completing relatively quickly.
Automatic Tuning Process

Not considered for auto implementation Restructure SQL New SQL profile Considered for auto implementation
Indexes
Existing profile?
3X benefit? N
Accept profile
Y 3X benefit? Y Replace profile

GATHER_STATS_JOB
Ignore new profile
Stale stats
Automatic Tuning Process With the list of candidate SQL statements already built and ordered, the statements are then tuned using SQL Tuning Advisor. During the tuning process, all the recommendation types are considered and reported, but only SQL profiles can be implemented automatically (when the ACCEPT_SQL_PROFILES task parameter is set to TRUE). Otherwise, only the recommendation to create a SQL profile will be reported in the automatic SQL tuning reports. In Oracle Database 11g, the performance improvement factor has to be at least three before a SQL profile is implemented. As we have already mentioned, the Automatic SQL Tuning process implements only SQL profile recommendations automatically. Other recommendations (to create new indexes, refresh stale statistics, or restructure SQL statements) are generated as part of the SQL tuning process but are not implemented. These are left for the DBA to review and implement manually, as appropriate. Here is a short description of the general tuning process: Tuning is performed on a per-statement basis. Because only SQL profiles can be implemented, there is no need to consider the effect of such recommendations on the workload as a whole. For each statement (in order of importance), the tuning process carries out each of the following steps: 1. Tune the statement by using SQL Tuning Advisor. Look for a SQL profile and, if it is found, verify that the base optimizer statistics are current for it.
Automatic Tuning Process (continued) 2. If a SQL profile is recommended, perform the following: - Test the new SQL profile by executing the statement with and without it. - When a SQL profile is generated and it causes the optimizer to pick a different execution plan for the statement, the advisor must decide whether to implement the SQL profile. It makes its decision as described on the flowchart in the slide. Although the benefit thresholds here apply to the sum of CPU and I/O time, SQL profiles are not accepted when there is degradation in either statistic. So the requirement is that there is a three-times improvement in the sum of CPU and I/O time, with neither statistic becoming worse. In this way, the statement runs faster than it would without the profile, even with contention in CPU or I/O. 3. If stale or missing statistics are found, make this information available to GATHER_STATS_JOB. Automatic implementation of tuning recommendations is limited to SQL profiles because they have fewer risks. It is easy for a DBA to revert the implementation. Note: All SQL profiles are created in the standard EXACT mode. They are matched and tracked according to the current value of the CURSOR_SHARING parameter. DBAs are responsible for setting CURSOR_SHARING appropriately for their workload.
Controlling the Automatic SQL Tuning Task
Autotask configuration:
On/off switch Maintenance windows running tuning task CPU resource consumption of tuning task
Task parameters:
Controlling the Automatic SQL Tuning Task You can set parameters for the Automatic SQL Tuning task by using the DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER procedure. An example is presented on the next page.
SQL profile implementation automatic/manual switch Global time limit for tuning task Per-SQL time limit for tuning task Test-execute mode disabled to save time Maximum number of SQL profiles automatically implemented per execution as well as overall Task execution expiration period
Example: Controlling the Automatic SQL Tuning Task
Example: Controlling the Automatic SQL Tuning Task Here is a PL/SQL control example for the Automatic SQL Tuning task:
BEGIN dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'LOCAL_TIME_LIMIT', 1400); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE'); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_SQL_PROFILES_PER_EXEC', 50); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_AUTO_SQL_PROFILES', 10002); END;
The last three parameters in this example are supported only for the Automatic SQL Tuning task. You can also use parameters such as LOCAL_TIME_LIMIT, or TIME_LIMIT, which are valid parameters for the traditional SQL tuning tasks. One important example is to disable test-execute mode (to save time) and to use only execution plan costs to decide about the performance by using the TEST_EXECUTE parameter. In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources that it is allowed to use. You can view the parameter values by querying DBA_ADVISOR_PARAMETERS.
BEGIN dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'LOCAL_TIME_LIMIT', 1400); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE'); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_SQL_PROFILES_PER_EXEC', 50); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_AUTO_SQL_PROFILES', 10002); END;
Automatic SQL Tuning Task
Automatic SQL Tuning Task As has already been mentioned, Automatic SQL Tuning is implemented as an automated maintenance task that is itself called Automatic SQL Tuning. You can see some high-level information about the last runs of the Automatic SQL Tuning task by going to the Automated Maintenance Tasks page: On your Database Control home page, click the Server tab and, when you are on the Server page, click the Automated Maintenance Tasks link in the Tasks section. On the Automated Maintenance Tasks page, you see the predefined tasks. You then access each task by clicking the corresponding link to get more information about the task itself (illustrated in the slide). When you click either the Automatic SQL Tuning link or the latest execution icon (the green area on the timeline), you go to the Automatic SQL Tuning Result Summary page.
Configuring Automatic SQL Tuning
Configuring Automatic SQL Tuning You can configure various Automatic SQL Tuning parameters by using the Automatic SQL Tuning Settings page. To get to that page, click the Configure button on the Automated Maintenance Tasks page. This takes you to the Automated Maintenance Tasks Configuration page, where you can see the various maintenance windows that are delivered with Oracle Database 11g. By default, Automatic SQL Tuning executes on all predefined maintenance windows in the MAINTENANCE_WINDOW_GROUP. You can disable it for specific days in the week. On this page, you can also edit each Window to change its characteristics. You can do so by clicking Edit Window Group. To get to the Automatic SQL Tuning Settings page, click the Configure button on the line corresponding to Automatic SQL Tuning in the Task Settings section. On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the slide. By default, Automatic Implementation of SQL Profiles is deactivated. Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop Automatic SQL Tuning.
Automatic SQL Tuning Result Summary
Automatic SQL Tuning Result Summary In addition, the Automatic SQL Tuning Result Summary page contains various summary graphs so that you can control the Automatic SQL Tuning task. An example is given in the slide. The first chart in the Overall Task Statistics section shows you the breakdown by finding types for the designated period of time. You can control the period of time for which you want the report to be generated by selecting a value from the Time Period list. In the example, Customized is used; it shows you the latest run. You can choose All to cover all executions of the task so far. Users can request it for any time period over the past month, since that is the amount of time for which the advisor persists its tuning history. You then generate the report by clicking View Report. On the Breakdown by Finding Type chart, you can clearly see that only SQL profiles can be implemented. Although many more profiles were recommended, not all of them were automatically implemented for the reasons that we already explained. Similarly, recommendations for index creation and other types are not implemented. However, the advisor keeps historical information about all the recommendations if you want to implement them later. In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart, which shows you the before-and-after DB Time for implemented profiles and other recommendations.
Quiz
Automatic SQL Tuning includes: 1. Automatic execution of the SQL Tuning Advisor for identified SQL statements 2. Generation of SQL profiles 3. Identification of problematic SQL statements by Oracle Database server 4. Generation of revised SQL statements
Automatic SQL Tuning: Fine Tune
Use the DBMS_SQLTUNE PL/SQL package to control various aspects of SYS_AUTO_SQL_TUNING_TASK: SET_TUNING_TASK_PARAMETER
ACCEPT_SQL_PROFILES REPLACE_USER_SQL_PROFILES MAX_SQL_PROFILES_PER_EXEC MAX_AUTO_SQL_PROFILES EXECUTION_DAYS_TO_EXPIRE
EXECUTE_TUNING_TASK: Used to manually run a new execution of the task in the foreground REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions
Automatic SQL Tuning: Fine Tune You can use the DBMS_SQLTUNE PL/SQL package to control various aspects of SYS_AUTO_SQL_TUNING_TASK. SET_TUNING_TASK_PARAMETERS: The following parameters are supported for the automatic tuning task only: ACCEPT_SQL_PROFILES: TRUE/FALSE whether the system should accept SQL profiles automatically REPLACE_USER_SQL_PROFILES: TRUE/FALSE whether the task should replace SQL profiles created by the user MAX_SQL_PROFILES_PER_EXEC: Maximum number of SQL profiles to create for each run MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL profiles allowed on the system in total EXECUTION_DAYS_TO_EXPIRE: Specifies the number of days to save the task history in the advisor framework schema. By default, the task history is saved for 30 days before it expires. EXECUTE_TUNING_TASK function: Used to manually run a new execution of the task in the foreground (behaves in the same way that it runs in the background) REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions
Automatic SQL Tuning: Fine Tune
Use DBMS_AUTO_TASK_ADMIN to enable and disable SYS_AUTO_SQL_TUNING_TASK:

ENABLE DISABLE
DBA_ADVISOR_EXECUTIONS DBA_ADVISOR_SQLSTATS DBA_ADVISOR_SQLPLANS
Automatic SQL Tuning: Fine Tune (continued) You can enable and disable SYS_AUTO_SQL_TUNING_TASK by using the DBMS_AUTO_TASK_ADMIN PL/SQL package. You can also access Automatic SQL Tuning information through the dictionary views listed in the slide: DBA_ADVISOR_EXECUTIONS: Get data about each execution of the task DBA_ADVISOR_SQLSTATS: See the test-execute statistics generated while testing the SQL profiles DBA_ADVISOR_SQLPLANS: See the plans encountered during test-execute
Use dictionary views access Automatic SQL Tuning information :
Using the PL/SQL Interface to Generate Reports

SQL> variable my_rept CLOB; SQL> BEGIN 2 :my_rept :=DBMS_SQLTUNE.REPORT_AUTO_TUNING_TASK(begin_exec=>NULL, 3 end_exec=>NULL, type=>'TEXT', level=>'TYPICAL', section=>'ALL', 4 object_id=>NULL, result_limit=>NULL); END; / SQL> print :my_rept
MY_REPT -------------------------------------------------------------------------------GENERAL INFORMATION SECTION Tuning Task Name : SYS_AUTO_SQL_TUNING_TASK Tuning Task Owner : SYS Workload Type : Automatic High-Load SQL Workload Scope : COMPREHENSIVE Global Time Limit(seconds) : 3600 Per-SQL Time Limit(seconds) : 1200 Number of SQLs with Statistic Findings : 1 Number of SQLs with SQL profiles recommended : 2 Number of SQLs with SQL profiles implemented : 2 Number of SQLs with Index Findings : 1 Number of SQLs with Errors : 1
Using the PL/SQL Interface to Generate Reports The example in the slide shows how to generate a text report to display all SQL statements that were analyzed in the most recent execution, including recommendations that were not implemented. All sections of the report are included. Depending on the sections that were included in the report, you can view information about the automatic SQL tuning task in the following sections of the report: The general information section provides a high-level description of the automatic SQL tuning task, including information about the inputs given for the report, the number of SQL statements tuned during the maintenance, and the number of SQL profiles that were created. The summary section lists the SQL statements (by their SQL identifiers) that were tuned during the maintenance window and the estimated benefit of each SQL profile, or their actual execution statistics after test-executing the SQL statement with the SQL profile. The Tuning findings section gives you all findings and statistics that are associated with each SQL statement, as well as whether profiles were accepted (and why). The Explain plans section shows the old and new explain plans used by each SQL statement analyzed by SQL Tuning Advisor. The Errors section lists all errors encountered by the Automatic SQL Tuning task. Note: Obtain the execution list by using the following command:
select execution_name,status,execution_start,execution_end from dba_advisor_executions where task_name='SYS_AUTO_SQL_TUNING_TASK'; Oracle Database 11g: New Features for Administrators 12 - 18
Automatic SQL Tuning Considerations
SQL not considered for Automatic SQL Tuning:

Ad hoc or rarely repeated SQL Parallel queries Long-running queries after profiling Recursive SQL statements DML and DDL
These statements can still be manually tuned by using SQL Tuning Advisor.
Automatic SQL Tuning Considerations Automatic SQL Tuning does not seek to solve every SQL performance issue occurring on a system. It does not consider the following types of SQL. Ad hoc or rarely repeated SQL: If a SQL is not executed multiple times in the same form, the advisor ignores it. SQL that do not repeat within a week are also not considered. Parallel queries. Long-running queries (post-profile): If a query takes too long to run after being SQL profiled, it is not practical to test-execute and, therefore, it is ignored by the advisor. Note that this does not mean that the advisor ignores all long-running queries. If the advisor can find a SQL profile that causes a query that once took hours to run in minutes, it could be accepted because testexecution is still possible. The advisor would execute the old plan just long enough to determine that it is worse than the new one, and then would terminate test-execution without waiting for the old plan to finish, thereby switching the order of execution. Recursive SQL statements. (Additional statements issued by the Oracle server which are needed to execute a SQL statement issued by a user.) DMLs such as INSERT SELECT or CREATE TABLE AS SELECT With the exception of truly ad hoc SQL, these limitations apply to Automatic SQL Tuning only. Such statements can still be tuned by manually running SQL Tuning Advisor.
Summary
In this lesson, you should have learned how to: Set up and modify Automatic SQL Tuning Use the PL/SQL interface to perform fine tuning View and interpret reports generated by Automatic SQL Tuning
This practice covers using Automatic SQL Tuning.
Intelligent Infrastructure Enhancements

Objectives
After completing this lesson, you should be able to: Create Automatic Workload Repository (AWR) baselines for future time periods Control automated maintenance tasks Use Resource Manager enhancements
11.2
Using New and Enhanced Automatic Workload Repository Views

DBA_HIST_DB_CACHE_ADVICE DBA_HIST_DISPATCHER DBA_HIST_DYN_REMASTER_STATS DBA_HIST_IOSTAT_DETAIL DBA_HIST_SHARED_SERVER_SUMMARY
Using New Automatic Workload Repository Views The following new AWR statistics views are available in Oracle Database 11g Release 2: DBA_HIST_DB_CACHE_ADVICE: Displays historical predictions of the number of physical reads for the cache size corresponding to each row DBA_HIST_DISPATCHER: Displays historical information for each dispatcher process at the time of the snapshot DBA_HIST_DYN_REMASTER_STATS: Displays statistical information about the dynamic remastering process DBA_HIST_IOSTAT_DETAIL: Displays historical I/O statistics aggregated by file type and function DBA_HIST_SHARED_SERVER_SUMMARY: Displays historical information for shared servers, such as shared server activity, common queues, and dispatcher queues
Comparative Performance Analysis with AWR Baselines

Performance
Actual
AWR Baseline contains a set of AWR snapshots for an interesting or reference period of time Baseline is key for performance tuning to:
Normal
AWR Baseline
time
Comparative Performance Analysis with AWR Baselines What is the proper threshold to set for a performance metric? What is it that you want to detect? If you want to know that the performance metric value indicates that the server is nearing capacity, an absolute value is correct. But if you want to know that the performance is different today than it was at this time last week, or last month, the current performance must be compared to a baseline. A baseline is a set of snapshots taken over a period of time. These snapshots are grouped statistically to yield a set of baseline values that vary over time. For example, the number of transactions per second in a certain database varies depending on the time of the day. The values for transactions per second are higher during working hours and lower during nonworking hours. The baseline records this variation and can be set to alert you if the current number of transactions per second is significantly different from the baseline values. Oracle Database 11g baselines provide the data required to calculate time-varying thresholds based on the baseline data. The baseline allows a real-time comparison of performance metrics with baseline data and can be used to produce AWR reports that compare two periods.
Guide setting of alert thresholds Monitor performance Compare advisor reports
Automatic Workload Repository Baselines
Automatic Workload Repository Baselines Oracle Database 11g consolidates the various concepts of baselines in Oracle (specifically in Enterprise Manager and RDBMS) into the single concept of the Automatic Workload Repository (AWR) baseline. Oracle Database 11g AWR baselines provide powerful capabilities for defining dynamic and future baselines, and considerably simplify the process of creating and managing performance data for comparison purposes. Oracle Database 11g introduces the concept of moving window baseline. By default, a systemdefined moving window baseline is created that corresponds to all the AWR data within the AWR retention period. Oracle Database 11g provides the ability to collect two kinds of baselines: moving window and static baselines. Static baselines can be either single or repeating. A single AWR baseline is collected over a single time period. A repeating baseline is collected over a repeating time period (for example, every Monday in June). In Oracle Database 11g, baselines are enabled by default if STATISTICS_LEVEL=TYPICAL or ALL.
Oracle Database 11g further enhances the Automatic Workload Repository baselines: Out-of-the-box moving window baseline from which you can specify adaptive thresholds Schedule the creation of a baseline by using baseline templates. Rename baselines. Set expiration dates for baselines.
Moving Window Baseline
There is one moving window baseline:

SYSTEM_MOVING_WINDOW: A moving window baseline that corresponds to the last eight days of AWR data Created out-of-the-box in 11g
Moving Window Baseline Oracle Database automatically maintains a system-defined moving window baseline. The default window size for the system-defined moving window baseline is the current AWR retention period, which by default is eight days. If you are planning to use adaptive thresholds, consider using a larger moving window (such as 30 days) to accurately compute threshold values. You can resize the moving window baseline by changing the number of days in the moving window to a value that is equal to or less than the number of days in the AWR retention period. Therefore, to increase the size of a moving window, you first need to increase the AWR retention period accordingly. This system-defined baseline provides a default out-of-the-box baseline for Enterprise Manager performance pages to compare the performance with the current database performance. Note: The default retention period for snapshot data has been changed from seven days to eight days in Oracle Database 11g to ensure the capture of an entire week of performance data.
By default, the adaptive thresholds functionality computes statistics on this baseline.
Baseline Display Options
Baseline Display Options The data for any defined baseline in the past is available in Oracle Database 11g. The baseline data may be displayed on the Performance page of Enterprise Manager. You have three display options: Do not show baseline information. Show the information from a specified static baseline. Show the information from the system moving baseline. Note: The system moving window baseline becomes valid after sufficient data has been collected and the statistics calculation occurs. By default, the statistics calculation is scheduled for every Saturday at midnight.
Baseline Templates
Templates enable you to schedule the creation of baselines for any time period(s) of interest in the future:
Single time period in the future Repeating schedule A known holiday weekend Every Monday morning from 10 AM to 2 PM
When the end time for a baseline template changes from future to past, MMON detects the change and creates the baseline.
Baseline Templates Creating baselines for future time periods allows you to mark time periods that you know will be interesting. For example, you may want the system to automatically generate a baseline for every Monday morning for the whole year, or you can ask the system to generate a baseline for an upcoming holiday weekend if you suspect that it is a high-volume weekend. Previously, you could create baselines only on snapshots that already existed. With Oracle Database 11g, a nightly MMON task goes through all the templates for baseline generation and checks to see if any time ranges have changed from the future to the past within the last day. For the relevant time periods, the MMON task then creates a baseline for the time period.
Examples
Creating AWR Baselines
Creating AWR Baselines You can create two types of AWR baselines: single and repeating. The Create Baseline: Baseline Interval Type page gives the following explanations. The single type of baseline has a single and fixed time interval: for example, from Jan 1, 2007, at 10:00 AM, to Jan 1, 2007, at 12:00 PM. The repeating type of baseline has a time interval that repeats over a time period: for example, every Monday from 10:00 AM to 12:00 PM for the year 2007. To view the AWR Baseline page, click the AWR Baselines link on the Server tab of the Database Instance page. On the Baseline page, click Create and follow the wizard to create your baseline. Note: Before you can set up AWR baseline metric thresholds for a particular baseline, you must compute the baseline statistics. Select Schedule Statistics Computation from the actions menu to compute the baseline statistics. There are several other actions available.
DBMS_WORKLOAD_REPOSITORY Package
The following procedures have been added:

CREATE_BASELINE_TEMPLATE RENAME_BASELINE MODIFY_BASELINE_WINDOW_SIZE DROP_BASELINE_TEMPLATE
SELECT_BASELINE_METRIC
DBMS_WORKLOAD_REPOSITORY Package The slide shows the set of PL/SQL interfaces offered by Oracle Database 11g in the DBMS_WORKLOAD_REPOSITORY package for administration and filtering. MODIFY_BASELINE_WINDOW_SIZE enables you to modify the size of the SYSTEM_MOVING_WINDOW.
The following function has been added:
Generate a Baseline Template for a Single Time Period

Interesting time period
.. T4
T5
T6
..
Tx
Ty
Tz
BEGIN DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE ( start_time => to_date('21-JUN-2010','DD-MON-YYYY'), end_time => to_date('21-SEP-2010','DD-MON-YYYY'), baseline_name => 'FALL10', template_name => 'FALL10', expiration => NULL ) ; END;
Generate a Baseline Template for a Single Time Period In Oracle Database 11g you can create a template for how baselines are to be created for different time periods in the future, for predictable schedules. If any part of the period is in the future, use the CREATE_BASELINE_TEMPLATE procedure. For the baseline template, when the end time becomes a time in the past, a task using these inputs automatically creates a baseline for the specified time period when the time comes. The example creates a baseline template that creates a baseline when 0:0:0 21-Sep-2010 is in the past. Using time-based definitions in baseline creation does not require the start-snapshot and endsnapshot identifiers. For the CREATE_BASELINE_TEMPLATE procedure, you can also now specify an expiration duration for the baseline that is created from the template. The expiration duration, specified in days, represents the number of days you want the baselines to be maintained. A value of NULL means that the baselines never expire. To create a baseline over a period in the past, use the CREATE_BASELINE procedure (as in Oracle Database 10g). The CREATE_BASELINE procedure has one new parameter: expiration duration. Expiration duration has the same meaning as it does for CREATE_BASELINE_TEMPLATE.
Creating a Repeating Baseline Template
Creating a Repeating Baseline Template Use the CREATE_BASELINE_TEMPLATE procedure to generate baseline templates that automatically create baselines for a contiguous time period based on a repeating time schedule. You can also specify whether you want the baseline to be automatically removed after a specified expiration interval (expiration). The example in the slide generates a template that creates a baseline for a period that corresponds to each SATURDAY_MAINTENANCE_WINDOW for a year. The baseline is created over a 20-hour period (duration) that starts at 6:00 AM (hour_in_day) each Saturday (day_of_week). The baseline is named SAT_MAINT_WIN with time information appended to make the name unique. The template is named SAT_MAINT_WIN, and each baseline will be kept for 90 days (expiration). This template is created for the local database ( dbid => NULL ). Use this baseline to compare the resources that are used each Saturday during the maintenance window.
BEGIN DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE ( day_of_week => 'SATURDAY', hour_in_day => 6, duration => 20, start_time => to_date('21-JUN-2007','DD-MON-YYYY'), end_time => to_date('21-JUN-2008','DD-MON-YYYY'), baseline_name_prefix => 'SAT_MAINT_WIN' template_name => 'SAT_MAINT_WIN', expiration => 90, dbid => NULL ); END;
Baseline Views
Data dictionary support for baselines: Modified DBA_HIST_BASELINE New DBA_HIST_BASELINE_DETAILS New DBA_HIST_BASELINE_TEMPLATE
Baseline Views The data dictionary views supporting the AWR baselines have changed. DBA_HIST_BASELINE: Modified View DBA_HIST_BASELINE has been modified to support the SYSTEM_MOVING_WINDOW baseline and the baselines generated from templates. Additional information includes the date created, time of last statistics calculation, and type of baseline. DBA_HIST_BASELINE_DETAILS: New View DBA_HIST_BASELINE_DETAILS displays information that allows you to determine the validity of a given baseline, such as whether there was a shutdown during the baseline period and the percentage of the baseline period that is covered by the snapshot data. DBA_HIST_BASELINE_TEMPLATE: New View DBA_HIST_BASELINE_TEMPLATE holds the baseline templates. This view provides the information needed by MMON to determine when a baseline will be created from a template and when the baseline should be removed. For details, see Oracle Database Reference 11g.
Quiz
Answers: 1 and 2
Which of the following are true about moving window baseline functionality? 1. The moving window baseline is created out of the box. 2. The default window size is the default AWR retention period. 3. The window size cannot be changed.
Performance Monitoring and Baselines
Performance alert thresholds are difficult to determine:

Expected metric values vary by workload type. Expected metric values vary by system load.
Baselines can capture metric value statistics:
Performance Monitoring and Baselines When they are properly set, alert thresholds provide a valuable servicean alertby indicating a performance metric that is at an unexpected value. Unfortunately, in many cases the expected value varies with the workload type, system load, time of day, or day of the week. Baselines associated with certain workload types or days of the week capture the metric values of that period. The baseline can then be used to set the threshold values when similar conditions exist. Baselines capture metric values. The statistics for baselines are computed to place a minimal load on the system; statistics for static baselines are manually computed. You can schedule statistics computation on the AWR Baselines page. Statistics for the system moving window are automatically computed according to the BSLN_MAINTAIN_STATS_SCHED schedule. By default, this schedule starts the job every week at noon on Saturday.
Automatically computed over the system moving window Manually computed over static baselines
Performance Monitoring and Baselines
Baseline metric statistics determine alert thresholds Three methods of comparison:

Significance level thresholds: Unusual values versus baseline data Percentage of maximum thresholds: Close or exceeding peak value over baseline data Fixed values: Manually set by the DBA
Performance Monitoring and Baselines (continued) Metric statistics computed over a baseline enable you to set thresholds that compare the baseline statistics to the current activity. There are three methods of comparison: significance level, percentage of maximum, and fixed values. Thresholds based on significance level use statistical relevance to determine which current values are unusual. In simple terms, if the significance level is set to .99 for a critical threshold, the threshold is set where 1% of the baseline values fall outside this value and any current values that exceed this value trigger an alert. A higher significance level of .999 or .9999 causes fewer alerts to be triggered. Thresholds based on percentage of maximum are calculated based on the maximum value captured by the baseline. Threshold values based on fixed values are set by the DBA. No baseline is required.
Defining Alert Thresholds Using Static Baseline
Defining Alert Thresholds Using Static Baseline After AWR baseline statistics are computed for a particular baseline, you can set metric thresholds specific to your baseline. Compute baseline statistics directly from the Baselines page (as previously discussed). Then go to the AWR Baseline Metric Thresholds page and select the type of metrics that you want to set. When done, select a specific metric and click the icon in the Edit Thresholds column. On the corresponding Edit AWR Baseline Metric Thresholds page, specify your thresholds in the Thresholds Settings section, and then click Apply Thresholds. You can specify thresholds based on the statistics computed for your baseline. In addition to Significance Level, the other possibilities are Percentage of Maximum and Fixed Values. Note: After a threshold is set using Baseline Metric Thresholds, the previous threshold values are forgotten forever and the statistics from the associated baseline are used to determine the threshold values until they are cleared (by using the Baseline Metric Threshold UI or PL/SQL interface).
Using Enterprise Manager to Quickly Configure Adaptive Thresholds
Using Enterprise Manager to Quickly Configure Adaptive Thresholds Oracle Database 11g Enterprise Manager provides significant usability improvements in the selection of adaptive thresholds for database performance metrics, with full integration with AWR baselines as the source for the metric statistics. Enterprise Manager offers a quick configuration option in a one-click starter set of thresholds based on OLTP or Data Warehouse workload profiles. Make the selection of the appropriate workload profiles from the subsequent pop-up window. By making this simple selection, the system automatically configures and evolves adaptive thresholds based on the SYSTEM_MOVING_WINDOW baseline for the group of metrics that best correspond to the chosen workload.
This practice covers creating AWR baselines: Creating a baseline over a past time interval Applying the baseline to the performance page graphs Creating a repeating period baseline over periods in the future
Maintenance Windows
10 p.m. 2 a.m. Mon to Fri
6 a.m. 2 a.m. Sat to Sun
Maintenance Windows Oracle Database 10g introduced the execution of automated maintenance tasks during a maintenance window. The automated tasks are statistics collection, segment advisor, and Automatic SQL Tuning. With Oracle Database 11g, the Automated Maintenance Tasks feature relies on the Resource Manager being enabled during the maintenance windows. Thus the resource plan associated with the window is automatically enabled when the window opens. The goal is to prevent maintenance work from consuming excessive amounts of system resources. Each maintenance window is associated with a resource plan that specifies how the resources will be allocated during the window duration. In Oracle Database 11g, WEEKNIGHT_WINDOW and WEEKEND_WINDOW (defined in Oracle Database 10g) are replaced with daily maintenance windows. Automated tasks are assigned to specific windows. All daily windows belong to MAINTENANCE_WINDOW_GROUP by default. You may define other maintenance windows as well as change start times and durations for the daily maintenance windows. Likewise, any maintenance windows that are deemed unnecessary can be disabled or removed. The operations can be performed by using Enterprise Manager or Scheduler interfaces.
Default Maintenance Plan

SQL> SELECT name FROM V$RSRC_PLAN 2 WHERE is_top_plan = 'TRUE'; NAME -------------------------------DEFAULT_MAINTENANCE_PLAN
Default Maintenance Plan When a maintenance window opens, the DEFAULT_MAINTENANCE_PLAN in the Resource Manager is automatically set to control the amount of CPU used by the automated maintenance tasks. To be able to give different priorities to each possible task during a maintenance window, various consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between groups and plans is shown in the slide. For high-priority tasks: Optimizer Statistics Gathering automatic task is assigned to the ORA$AUTOTASK_STATS_GROUP consumer group Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP consumer group Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP consumer group Note: If necessary, you can manually change the percentage of CPU resources allocated to the various automated maintenance task consumer groups inside ORA$AUTOTASK_HIGH_SUB_PLAN.
Automated Maintenance Task Priorities
Run Job1 with urgent priority
Run Job2 with urgent priority
Run Job3 with high priority
Run Job3 with medium priority
Run Job4 with medium priority
MMON
Stats
high medium
Maintenance window
Space
ABP
SQL
Job1
Jobn
DBA_AUTOTASK_TASK
Automated Maintenance Task Priorities The Automated Maintenance Tasks feature is implemented by Autotask Background Process (ABP). ABP functions as an intermediary between automated tasks and the Scheduler. Its main purpose is to translate automated tasks into AUTOTASK jobs for execution by the Scheduler. Just as important, ABP maintains a history of execution of all tasks. ABP stores its private repository in the SYSAUX tablespace; you view the repository through DBA_AUTOTASK_TASK. ABP is started by MMON at the start of a maintenance window. There is only one ABP required for all instances. The MMON process monitors ABP and restarts it if necessary. ABP determines the list of jobs that need to be created for each maintenance task. This list is ordered by priority: urgent, high, and medium. Within each priority group, jobs are arranged in the preferred order of execution. ABP creates jobs in the following manner: all urgent-priority jobs are created first, all high-priority jobs are created next, and all medium-priority jobs are created last. ABP assigns jobs to various Scheduler job classes. These job classes map the job to a consumer group based on priority. Note: With Oracle Database 11g, there is no job that is permanently associated with a specific automated task. Therefore, it is not possible to use DBMS_SCHEDULER procedures to control the behavior of automated tasks. Use the DBMS_AUTO_TASK_ADMIN procedures instead.
urgent
Controlling Automatic Maintenance Tasks
Controlling Automatic Maintenance Tasks The Automatic Maintenance Tasks feature determines whenand in what ordertasks are performed. As a DBA, you can control the following: If the maintenance window turns out to be inadequate for the maintenance workload, adjust the duration and start time of the maintenance window. Control the resource plan that allocates resources to the automated maintenance tasks during each window. Enable or disable individual tasks in some or all maintenance windows. In a RAC environment, shift maintenance work to one or more instances by mapping maintenance work to a service. Enabling the service on a subset of instances shifts maintenance work to these instances. As shown in the slide, Enterprise Manager is the preferred way to control Automatic Maintenance Tasks. However, you can also use the DBMS_AUTO_TASK_ADMIN package.
Quiz
In Oracle Database 11g, you should use the procedures in which of the following packages to control the behavior of automated tasks: 1. DBMS_AUTO_TASK_ADMIN 2. DBMS_SCHEDULER
Answer: 1
Important I/O Metrics for Oracle Databases

Disk bandwidth Channel bandwidth
Metric = IOPS and latency

Need high RPM and fast seek time
Metric = MBPS
Need large I/O channel
OLTP
(Small random I/O)
DW/OLAP
(Large sequential I/O)
Important I/O Metrics for Oracle Databases The following provides a summary of the types of I/O issued by the Oracle Database processes. The database I/O workload typically consists of small random I/O and large sequential I/O. Small random I/O is more prevalent in an OLTP application environment in which each foreground reads a data block into the buffer cache for updates and the changed blocks are written in batches by the DBWn process. Large sequential I/O is common in an OLAP application environment. The OLTP application performance depends on how fast a small I/O is serviced, which depends on how fast the disk can spin and find the data. Large I/O performance depends on the capacity of the I/O channel that connects the server to the storage array; large I/O throughput is better when the capacity of the channel is larger. IOPS (I/O per second): This metric represents the number of small random I/O that can be serviced in a second. The IOPS rate mainly depends on how fast the disk media can spin. The IOPS rate from a storage array can be increased either by adding more disk drives or by using disk drives with a higher RPM (rotations per minute) rate. MBPS (megabytes per second): The rate at which data can be transferred between the computing server node and the storage array depends on the capacity of the I/O channel that is used to transfer data. More data can be transferred through a wider pipe.
Important I/O Metrics for Oracle Databases (continued) The throughput of a streaming data application depends on how fast this data can be transferred. Throughput is measured by using the MBPS metric. Even though the disks themselves have an upper limit on the amount of sequential data that they can transfer, it is often channel capacity that limits the overall throughput of the system. For example, a host connected to an NAS server through a GigE switch is limited by a transfer capacity of 128 MBPS. There are usually multiple disks in the NAS that can together provide more than 128 MBPS. The channel resource becomes the limiting resource. I/O latency: Latency is another important metric that is used in measuring the performance of an I/O subsystem. Traditionally, latency is simply the time for the disk to access a particular sector on the disk. But from the database point of view, latency represents all the time it takes for a submitted I/O request to be serviced by the storage. In other words, it represents the overhead before the first byte of a transfer arrives after an I/O request has been submitted. Latency values are more commonly used for small random I/O when tuning a system. If there are too many I/O requests queued up against a disk, the latency increases as the wait time in the queue increases. To improve the latency of I/O requests, data is usually striped across multiple spindles so that all I/O requests to a file do not go to the same disk. A higher latency usually indicates an overloaded system. Other than the main resources mentioned above, there are also other storage array components that can affect I/O performance. Array vendors provide caching mechanisms to improve read throughput, but their real benefit is questionable in a database environment because Oracle Database uses caches and read-ahead mechanisms so that data is available directly from RAM rather than from the disks.
I/O Calibration and Enterprise Manager
I/O Calibration and Enterprise Manager To determine the previously discussed I/O metrics, you can use the I/O Calibration tool from the Enterprise Manager Performance page or PL/SQL. I/O Calibration is a modified version of the ORION tool and is based on the asynchronous I/O library. Because calibration requires issuing enough I/O to saturate the storage system, any performance-critical sessions will be negatively impacted. Thus, you should run I/O calibration only when there is little activity on your system. I/O Calibration takes approximately 10 minutes to run. You can launch an I/O Calibration task directly from Enterprise Manager by clicking the Performance tab. On the Performance page, you can click the I/O tab and then the I/O Calibration button. On the I/O Calibration page, specify the approximate number of physical disks attached to your database storage system as well as the maximum tolerable latency for a single-block I/O request. Then, in the Schedule section of the I/O Calibration page, specify when to execute the calibration operation. Click the Submit button to create a corresponding Scheduler job. On the Scheduler Jobs page, you can see the amount of time it takes for the calibration task to run. When finished, view the results of the calibration operation on the I/O Calibration page: maximum I/O per second, maximum megabytes per second, and average actual latency metrics.
I/O Calibration and the PL/SQL Interface

SQL> exec dbms_resource_manager.calibrate_io( num_disks=>1, max_latency=>10, max_iops=>:max_iops, max_mbps=>:max_mbps, actual_latency=>:actual_latency); PL/SQL procedure successfully completed. SQL> SELECT max_iops, max_mbps, max_pmbps, latency 2 FROM DBA_RSRC_IO_CALIBRATE; MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY ---------- ---------- ---------- ---------137 12 6 64
I/O Calibration and the PL/SQL Interface You can run the I/O Calibration task by using the DBMS_RESOURCE_MANAGER.CALIBRATE_IO procedure. This procedure calibrates the I/O capabilities of the storage. The calibration status and results are available from the V$IO_CALIBRATION_STATUS and DBA_RSRC_IO_CALIBRATE views. Here is a brief description of the parameters you can specify for the CALIBRATE_IO procedure: NUM_DISKS: Approximate number of physical disks in the database storage MAX_LATENCY: Maximum tolerable latency (in milliseconds) for database-block-sized I/O requests MAX_IOPS: Maximum number of I/O requests per second that can be sustained. The I/O requests are randomly distributed, database-block-sized reads. MAX_MBPS: Maximum throughput of I/O that can be sustained (in megabytes per second). The I/O requests are randomly distributed 1 MB reads. ACTUAL_LATENCY: Average latency of database-block-sized I/O requests at MAX_IOPS rate (in milliseconds)
I/O Calibration and the PL/SQL Interface (continued) The query of the DBA_RSRC_IO_CALIBRATE view shows the following: MAX_IOPS: Maximum number of data block read requests that can be sustained per second MAX_MBPS: Maximum megabytes per second of maximum-sized read requests that can be sustained MAX_PMBPS: Maximum megabytes per second of large I/O requests that can be sustained by a single process LATENCY: Latency for data block read requests Usage notes: Only users with the SYSDBA privilege can run this procedure. Only one calibration can run at a time. If another calibration is initiated at the same time, it fails. For a RAC database, the workload is simultaneously generated from all instances. The latency time is computed only when the TIMED_STATISTICS initialization parameter is set to TRUE (which is set when STATISTICS_LEVEL is set to TYPICAL or ALL).
I/O Statistics: Overview
V$IOSTAT_FUNCTION
AWR and EM
V$IOSTAT_FILE
V$IOSTAT_CONSUMER_GROUP
I/O Statistics: Overview To give a consistent set of statistics for all I/O issued from an Oracle instance, Oracle Database 11g introduces a set of virtual views that collect I/O statistics in three dimensions: RDBMS components: Components are grouped by their functionality into 12 categories (shown in the slide). When Resource Management is enabled, I/O statistics are collected for all consumer groups that are part of the currently enabled resource plan. I/O statistics are also collected for the individual files that have been opened. Each dimension has statistics for read and write operations. Since read/write can occur in single block or multiblock operations, they are separated into four different operations (as shown in the slide). For each operation type, the number of corresponding requests and the amount of megabytes are cumulated. In addition to these, the total I/O wait time in milliseconds and the number of total waits are also cumulated for both component and consumer group statistics. For file statistics, total service time in microseconds is accumulated, in addition to statistics for single block reads.
I/O Statistics: Overview (continued) Virtual views show cumulative values for statistics. Component and consumer group statistics are transformed into AWR metrics that are sampled regularly and stored in the AWR repository. You can retrieve those metrics across a timeline directly on the Performance page of Enterprise Manager. Note: V$IOSTAT_NETWORK collects network I/O statistics that are related to accessing files on a remote database instance.
I/O Statistics and Enterprise Manager
I/O Statistics and Enterprise Manager You can retrieve I/O statistics directly on the Performance page in Enterprise Manager. On the Performance page, click the I/O subtab located under the Average Active Session graph. On the I/O subpage, you see a breakdown of I/O statistics on three possible dimensions: I/O Function, I/O Type, and Consumer Group. Select one of the options to look at the corresponding dimension graphs. The slide shows the two graphs corresponding to the I/O function dimension: I/O Megabytes per Second (by RDBMS component) I/O Requests per Second (by RDBMS component) Note: The Others RDBMS component category corresponds to everything that is not directly issued from SQL (for example, PL/SQL and Java).
I/O Statistics and Enterprise Manager
I/O Statistics and Enterprise Manager (continued) From the I/O Function statistic graphs, you can drill down to a specific component by clicking that component. In the example in the slide, you drill down to the Buffer Cache Reads component. This takes you to the I/O Rates by I/O Function page, where you can see three important graphs for that particular component: MBPS, IOPS, and wait time.
Practices 13-2 and 13-3: Overview
These practices cover the following topics: Monitoring the performance of AUTOTASK jobs Adjusting the resources and windows for AUTOTASK jobs Calibrating I/O resources
11.2
Resource Manager Enhancements
The new features in Oracle Database 11g Release 2 enable you to use Oracle Database Resource Manager for: Database consolidation Server consolidation
Resource Manager Enhancements Oracle Database Resource Manager (the Resource Manager) enables you to optimize resource allocation among concurrent database sessions. The new features in Oracle Database 11g Release 2 enable you to use the Resource Manager for database consolidation and server consolidation.
11.2
Resource Manager Enhancements: Database Consolidation

Database consolidation requirements: Isolate applications from each other
Surge in one applications workload should not affect another application. Need a minimum, guaranteed amount of CPU per application
Consistent performance
Applications performance should be consistent, even if all other applications are idle. Need a way to limit CPU utilization
Resource Manager Enhancements: Database Consolidation In Oracle Database 11g Release 2, you can use Oracle Database Resource Manager for database consolidation. Database consolidation requires that applications are isolated from each other. If one application experiences an increase in workload, that increase should not affect other applications. In addition, the performance of each application should be consistent.
11.2
Fixed Policy CPU Resource Management
CPU directives can be used to:

Specify a minimum CPU allocation for each application Designate how unused allocations should be redistributed
Set per consumer group using the MAX_UTILIZATION_LIMIT attribute Imposes an absolute upper limit on CPU utilization for a resource consumer group which overrides any redistribution of CPU within a plan.
Good candidate: Automated maintenance tasks

Fixed Policy CPU Resource Management The MAX_UTILIZATION_LIMIT attribute of resource plan directives enables you to impose an absolute upper limit on CPU utilization for a resource consumer group. This absolute limit overrides any redistribution of CPU within a plan. Note: Good candidate applications for Database consolidation are automated maintenance tasks because currently these applications can take up to 100% of the server CPU resources. You can set a maximum limit for each auto-task consumer group.
In Oracle Database 11g Release 2, the maximum utilization limit directive limits the CPU consumption of an application.
11.2
Limiting CPU Utilization

Specify minimum and maximum CPU utilization limits
DB Consolidation Plan #1
Cons Group App_1 App_2 App_3 App_4 CPU Allocation 50% 20% 20% 10% Maximum Utilization Limit 60% 30% 30% 20% Cons Group App_1 App_2 App_3 App_4
Specify maximum CPU utilization limits only

DB Consolidation Plan #2
CPU Allocation null null null null Maximum Utilization Limit 50% 20% 10% 20%
exec dbms_resource_manager.create_plan_directive( plan => 'db_consolidation_plan', group_or_subplan => 'App_1', mgmt_p1 => 50, max_utilization_limit => 60);
Limiting CPU Utilization The maximum utilization limit directive limits the CPU consumption of an application. You can set minimum and maximum boundaries, as shown in the slide. The PL/SQL example in the slide specifies a minimum value percentage (50%) for the CPU allocation resource at level 1 for consumer group APP_1. This example also specifies an absolute maximum CPU utilization percentage (60%) permitted for that same consumer group. The example uses a plan called DB_CONSOLIDATION_PLAN. Similar commands can be executed for each consumer group show in the tables. Note: In previous releases, the implicit maximum utilization limit was set to 100%.
11.2
Resource Manager Enhancements: Server Consolidation

Many test, development, and small production databases do not fully utilize todays powerful servers. Server consolidation solution: Run multiple database instances on the same server Server consolidation issues:
Resource Manager Enhancements: Server Consolidation Because many test, development, and small production databases are unable to fully utilize the servers they are on, server consolidation provides a possible alternative. With server consolidation, resources are more fully utilized by running multiple database instances on the server. However, this may bring about CPU contention and adverse impact due to workload surges on one instance.
Contention for CPU, memory, and I/O Unexpected workload surges on one instance can wreak havoc on other databases
11.2
Instance Caging
Instance caging is the method for managing CPU allocations on a multi-CPU server with multiple database instances. Instance caging limits the amount of CPU an instance consumes by using these features:
Two approaches:
Over-provisioning: The sum of the CPU limit for each instance exceeds the actual number of CPUs. Partitioning: The sum of the CPU limit for each instance equals the actual number of CPUs.
Instance Caging Instance caging is a method that uses the CPU_COUNT initialization parameter to limit the number of CPUs that an instance can use. In addition, Oracle Database Resource Manager is employed to allocate the CPUs for the database sessions based on the instance resource plan. Instance caging approaches are as follows: Over-provisioning: With this approach, the sum of the CPU limit for each instance exceeds the actual number of CPUs on the server. This approach is appropriate for noncritical databases and low-load, non-critical production systems. Although the instances impact each other's performance, at any given time one or more of the instances may be idle or experiencing a low load. Partitioning: With this approach, CPU limits are set such that the sum for all instances equals the number of CPUs on the server. This approach is appropriate for critical product systems. It prevents the instances from interfering with each other and provides predictable performance.
Database Resource Manager limits the amount of CPU that the database instance consumes. The CPU_COUNT initialization parameter specifies the limit.
11.2
Instance Caging Examples

One database instance can still impact the others.
Sum of CPU_COUNTS settings = 32 32 24 16 8 Instance A Instance D Instance C Instance B Total Number of CPUs = 16
One database instance cannot impact the others.

Sum of CPU_COUNTS = 16 16 12 8 4 Total Number of CPUs = 16
Instance D Instance C Instance B
Instance A
Over-provisioning approach: With all four instances active, one instance can get 8/(8+8+8+8)=25% of CPU.
Partitioning approach: Each instance has a dedicated number of CPUs.
Instance Caging Examples Over-provisioning approach: When a server is over-provisioned, the database instances can impact each others performance. However, instance caging limits their impact and helps to provide predictable performance. In the example on the left, where all four instances have CPU_COUNT set to 8, the maximum percentage of CPU that a database instance can consume at any point in time is its own limit divided by the sum of the limits for all active databases. In this example, one instance will be able to consume 8 / (8 + 8 + 8 + 8) = 25% of the CPU. If only two instances are active, one instance will be able to consume 8 / (8 + 8) = 50% of the CPU. Partitioning approach: Instance caging can partition the CPU resources by ensuring that the sum of all CPU limits does not exceed the total number of CPUs. In the example on the right, if four database instances share a 16-CPU server, their limits can be set to 8, 4, 2, and 2. By dedicating CPU resources to a database instance, partitioning provides two advantages: One database instances CPU load cannot affect another instances CPU load. Each database instances CPU resources is fixed, leading to more predictable performance.
11.2
Enabling Instance Caging
Set the CPU_COUNT parameter to specify the maximum number of CPUs the instance can use at any time:
ALTER SYSTEM SET cpu_count = 4;
ALTER SYSTEM SET resource_manager_plan = 'default_plan';

Any resource plan with CPU directives
Enabling Instance Caging You can configure instance caging as follows: The CPU_COUNT parameter specifies the maximum (the limit), not actual amount of CPU the database instance can use at any time. The Resource Manager limits the amount of CPU that the database instance consumes. Because instance caging is simple to configure and does not require any new software to be licensed or installed, it is an excellent alternative to other server consolidation tools, such as virtualization and OS workload managers. By default, the CPU Resource Manager assumes that the database instance can use all CPUs on a server. To enable instance caging, any resource plan with CPU directives can be used. Note: For case studies, see the Oracle White Paper: Database Instance Caging: A Simple Approach to Server Consolidation.
Set the RESOURCE_MANAGER_PLAN parameter to enable any CPU resource plan:
11.2
Monitoring Instance Caging
View value of CPU_COUNT parameter:

SELECT value FROM v$parameter WHERE name = 'cpu_count' AND (isdefault = 'FALSE' OR ismodified != 'FALSE');
Determine Resource Manager status:
Monitor throttling:
SELECT begin_time, consumer_group_name, cpu_consumed_time, cpu_wait_time FROM v$rsrcmgrmetric_history ORDER BY begin_time; SELECT name, consumed_cpu_time, cpu_wait_time FROM v$rsrc_consumer_group;
Monitoring Instance Caging If CPU_COUNT has not been set, no value is returned by the first query in the slide. If no rows are returned by the second query in the slide, the Resource Management is off or the Resource Manager is on, but not managing CPU. If a row is returned, it indicates the plan being used. Instance caging limits the CPU consumption of the foreground processes by throttling them. A foreground process is throttled when it is waiting on the resmgr:cpu quantum wait event. You can monitor the amount of throttling in two ways: The V$RSRCMGRMETRIC_HISTORY view shows the amount of CPU consumption and throttling for each minute in the past hour. For each consumer group, the CPU_CONSUMED_TIME parameter specifies the number of milliseconds of CPU was consumed and the CPU_WAIT_TIME parameter specifies the number of milliseconds that its processes were throttled. The V$RSRC_CONSUMER_GROUP view shows the amount of CPU consumption and throttling since CPU Resource Management was enabled. CONSUMED_CPU_TIME and CPU_WAIT_TIME measure time in milliseconds.
SELECT name FROM v$rsrc_plan WHERE is_top_plan = 'TRUE' AND cpu_managed = 'ON';
Quiz
Answers: 1 and 3
Which of the following are true about instance caging? 1. The CPU_COUNT initialization parameter specifies the CPU limit. 2. Database Resource Manager is not employed to enable instance caging. 3. Database Resource Manager limits the amount of CPU that the database instance consumes.
Resource Manager: Changes to DBMS_RESOURCE_MANAGER

For the CREATE_PLAN_DIRECTIVE procedure: MGMT_Pn parameter replaces CPU_Pn SWITCH_FOR_CALL parameter replaces SWITCH_TIME_IN_CALL
Resource Manager: Changes to DBMS_RESOURCE_MANAGER The DBMS_RESOURCE_MANAGER PL/SQL interface has some deprecated and new parameters. For example, you should no longer use CPU_Pn parameters of the CREATE_PLAN_DIRECTIVE procedure, but replace them by MGMT_Pn parameters. Use the new SWITCH_FOR_CALL parameter instead of SWITCH_TIME_IN_CALL parameter of the CREATE_PLAN_DIRECTIVE procedure. For more information refer to the Oracle Database Administrators Guide.
Resource Manager: New Enterprise Manager Interface
Resource Manager: New Enterprise Manager Interface Using Enterprise Manager, you can access the Resource Manager section from the Server page. The Resource Manager section is organized in the same way as the Database Resource Manager. Clicking the Getting Started link takes you to the Getting Started with Database Resource Manager page, which provides a brief description of each step as well as the links to the corresponding pages.
Resource Plans Created by Default
Resource Plans Created by Default When you create an Oracle 11g database, the Resource Plans (shown in the slide) are created by default. However, none of these plans are active by default.
Default Plan
Default Plan The slide shows the properties of DEFAULT_PLAN. Note that there are no limits for its thresholds. As you can see, Oracle Database 11g introduces two new I/O limits that you can define as thresholds in a Resource Plan.
I/O Resource Limit Thresholds
I/O Resource Limit Thresholds When you create a Resource Plan directive, you can specify the I/O resource limits. The example in the slide shows how to do this in both Enterprise Manager and PL/SQL. You can specify the following two arguments: switch_io_reqs: Specifies the number of I/O requests that a session can issue before an action is taken. Default is NULL, which means unlimited. switch_io_megabytes: Specifies the amount of I/O (in MB) that a session can issue before an action is taken. Default is NULL, which means unlimited.
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_plan(plan=>'TESTJFV',comment =>'', ); dbms_resource_manager.create_plan_directive( plan => 'TESTJFV', group_or_subplan => 'OTHER_GROUPS', comment => '', mgmt_p1 => 60, mgmt_p2 => NULL, mgmt_p3 => NULL, mgmt_p4 => NULL, mgmt_p5 => NULL, mgmt_p6 => NULL, mgmt_p7 => NULL, mgmt_p8 => NULL , parallel_degree_limit_p1 => NULL , switch_io_reqs => 20000 , switch_io_megabytes => 5000000, ); dbms_resource_manager.submit_pending_area(); END;
Resource Manager Statistics
Resource Manager Statistics You can also look at the Resource Manager Statistics page, which displays statistics for only the current active plan.
Summary
In this lesson, you should have learned how to: Create AWR baselines for future time periods Control automated maintenance tasks Use Resource Manager enhancements

Oracle New Features - sg1

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Oracle New Features - sg1

Hochgeladen von

Copyright:

Verfügbare Formate

Oracle Database 11g: New Features for Administrators

Volume I Student Guide

D50081GC21 Edition 2.1 October 2009 D63697

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Technical Contributors and Reviewers

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Setting the email_sender Attribute B-8

Oracle Internal & Oracle Academy Use Only

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 2

Oracle Internal & Oracle Academy Use Only

Oracle Database Innovation

Oracle Database 11g

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 3

Oracle Internal & Oracle Academy Use Only

Enterprise Grid Computing

RAC clusters for availability

Grids of low-cost hardware and storage

Managing change across the enterprise

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 4

Oracle Internal & Oracle Academy Use Only

Oracle Database 11g: Focus Areas

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 5

Oracle Internal & Oracle Academy Use Only

Oracle Database 11g: Focus Areas

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 6

Oracle Internal & Oracle Academy Use Only

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 7

Oracle Internal & Oracle Academy Use Only

Self-Managing Database: The Next Generation

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 8

Oracle Internal & Oracle Academy Use Only

Manage performance and resources

Suggested Additional Courses

Copyright 2009, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators I - 9

Oracle Internal & Oracle Academy Use Only

Oracle By Example series: Oracle Database 11g