D50081GC21 sg1

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D63697
Edition 2.1
D50081GC21
September 2010
Volume I Student Guide
Oracle Database 11g: New
Features for Administrators
Oracle University and Aspect Software Inc use only

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Authors Copyright 2009, 2010, Oracle and/or it affiliates. All rights reserved.
Christian Bauwens Disclaimer

Maria Billings
This document contains proprietary information and is protected by copyright and
Mark Fuller other intellectual property laws. You may copy and print this document solely for your
Peter Fusek own use in an Oracle training course. The document may not be modified or altered in
Richard Green any way. Except where your use constitutes "fair use" under copyright law, you may
Christine Jeal 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
Donna Keesling express authorization of Oracle.
Deidre Matishak
James Spiller The information contained in this document is subject to change without notice. If you
Jenny Tsai 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
Jean-Francois Verrier warranted to be error-free.
James Womack

Marcie Young Restricted Rights Notice
If this documentation is delivered to the United States Government or anyone using

Technical Contributors the documentation on behalf of the United States Government, the following notice is
and Reviewers applicable:
Maqsood Alam U.S. GOVERNMENT RIGHTS

Kalyan Bitra The U.S. Governments rights to use, modify, reproduce, release, perform, display, or
John Boyle disclose these training materials are restricted by the terms of the applicable Oracle
license agreement and/or the applicable U.S. Government contract.
Harald Van Breederode
Sharath Bhujani Trademark Notice
Immanuel Chan
Timothy Chien Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Edward Choi
Jacco Draaijer
Al Flournoy
Steve Fogel
Andy Fortunak
Gerlinde Frenzen
Greg Gagnon
GP Gongloor Technical Contributors
Joel Goodman and Reviewers
Hansen Han Tim Shetler
Uwe Hesse Eric Siglin
Sunil Hingorani Ranbir Singh
Magnus Isaksson Jeff Skochil
Susan Jang George Spears
Martin Jensen Kesavan Srinivasan
Dominique Jeunot Birgitte Taagholt
Pete Jones Glenn Tripp
Yash Kapani Branislav Valny
Pierre Labrousse Anthony Woodell
Richard.W.Lewis
Hakan Lindfors Editors
Russ Lowenthal
Aju Kumar
Kurt Lysy
Amitha Narayan
Isabelle Marchand
Silvia Marrone
Publishers
Heejin Park
Srinivas Putrevu Sujatha Nagendra
Jagannath Poosarla Michael Sebastian Almeida
Surya Rekha Jobi Varghese
Contents
I 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
1 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
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
2 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
Installation Finish Page 2-16

Quiz 2-17
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
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
3 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
4 ASM Enhancements
Objectives 4-2
Without ASM Fast Mirror Resync 4-3
v
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
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
7 Oracle SecureFiles
Objectives 7-2
Managing Enterprise Information 7-3
viii
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
8 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
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
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
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
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
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
12 Automatic SQL Tuning

Objectives 12-2
SQL Tuning in Oracle Database 10g 12-3
xi
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
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
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
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
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
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
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
16 Performance Enhancements
Objectives 16-2
Using the DBMS_ADDM Package 16-3
Advisor Named Findings and Directives 16-6
xiv
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
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
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 17-35
Summary 17-37
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
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
Using New DUPLICATE Command Options 18-23
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
xvii
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
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
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
Setting the email_sender Attribute B-8
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
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
continuing with
Platform Portability
Commercial SQL Implementation 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 RAC Managing
Grids of
dominance clusters change
low-cost
for hardware and across the
availability storage 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

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.

Information management
Content management
XML
Oracle Text

Spatial
Multimedia and medical imaging
Application development
PL/SQL
.NET
PHP
SQL Developer
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
Recovery
Replication
RAC
Memory
Schema
Apps/SQL
Backup
Storage
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.

Self-Managing Database: The Next Generation
Manage performance and resources

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

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
http://www.oracle.com/education/library
A comprehensive series of self-paced online courses
covering all new features in detail
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

Suggested Schedule
Topic Lessons Days
Installation I, 1 - 3 1
Manage Storage 4-7 2

Manage Security 8 3
Manage Change 9 - 11 3
Manage Performance and Resources 12 - 17 3, 4 and 5
Manage Availability 18 - 20 5
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
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
Oracle Database 11g: New Features for Administrators 1 - 2

11.2
Standardized infrastructure Applications

software
Eliminates need for third- Middleware
party solutions
Includes:
Database

Automatic Storage
Management (ASM) EM
ASM Cluster File System Oracle Grid Infrastructure
(ACFS)
ACFS Snapshots
Oracle Clusterware
Oracle Restart

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.

11.2
Automatic Storage Management

Technology Stack
Previous Releases Oracle Database 11g
of ASM Release 2 ASM
Application Application
Application 3rd Party

Database Database ACFS FS
Database
ASM
ASM/ADVM
ASM
Operating System
Operating System
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:

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)
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.
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
of interaction with a particular instance.
NLS_LANG: Optional environment variable that controls language, territory, and client
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.
11.2
update
Checking the System Requirements
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
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.

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:

# /etc/init.d/oracleasm configure
..
Default user to own the driver interface []: grid
Default group to own the driver interface []: asmadmin
..
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.

11.2
Installation Scenario
The installation scenario being presented in this course is

divided into two parts:
Part One: Install Oracle Grid Infrastructure for stand-
alone 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


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


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
ASMInstance
Instance
Kernel ASM
ASMCluster
ClusterFile
FileSystem
System(ACFS)
(ACFS)
OS ACFS Snapshots
ACFS Snapshots
Dynamic
DynamicVolume
VolumeManager
Manager

ASM Device File: /dev/asm/dgbvol1-123
ASM Files Dynamic Volumes

ASM
DB
DB files
files
DB
DB files
files
Disk DB
DB files
files
DB
DB files
files
DB files ACFS 3rd Party
Group DBDB
DB
files
files
files
DB
DB files
files FS
DB
DBfilesfiles
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
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>.
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.

11.2
ASM Dynamic Volume Striping
Disk Group (1MB AU size, Normal Redundancy )

Disk A Disk B Disk C Disk D
Secondary (Failure Group 1) (Failure Group 2) (Failure Group 3) (Failure Group 4)
AU (Mirror)
Primary
AU

Data Stripe 1 2 3 4
(Default: 128KB) 5
Allocation
Unit (AU)
Volume Extent
... ... ... ...
Volume Extent 1 Volume Extent 2 Volume Extent 3 Volume Extent 4
(64MB)
ASM Dynamic Volume (Default: 128KB stripe width, 4 stripe columns)
1
2
3 ACFS File
4 (640KB)
5
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
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.
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.

11.2
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 (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

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

11.2
Using SQL to Manage

ASM Dynamic Volumes
Add a volume:
SQL> ALTER DISKGROUP DGROUPA
ADD VOLUME asmvol1 SIZE 10G;
Resize a volume:

RESIZE VOLUME asmvol1 SIZE 15G;
Drop a volume:
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.

11.2
Using SQL to Manage

ASM Dynamic Volumes
Enable a volume:
ENABLE VOLUME asmvol1;
Disable a volume:

SQL> ALTER DISKGROUP ALL
DISABLE VOLUME ALL;
Modify a volume:
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.

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 3rd Party 3rd Party

Database Application File System
ASM ASM Cluster

File System

Dynamic Volume Manager
ASM Instance
rd
Database & 3 Party
ACFS
Clusterware File System
Files
Files Files
Disk Group Dynamic Volume
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:

mkfs
fsck
mount
umount
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 umount are used to manage the
ACFS file system.

11.2
Linux/UNIX Extensions
Create an ACFS file system:

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

$ mount -t acfs /dev/asm/asmvol1-216 \
/oracle/cluster1/myacfs
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.
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.

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

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

acfsmountvol [/all] [/v]

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

acfschkdsk [/a] [/v] [/n] [/f] [info] device
Windows Extensions
acfsformat [/vf] [/b blksz] [/n name] device [blocks]
acfsmountvol [/all] [/v]
acfsdismount [/v] [/p] [/P] path
acfschkdsk [/a] [/v] [/n] [/f] [info] device

11.2
ACFS Platform-Independent
Commands
Command Function
acfsutil info Display new ACFS file and file system features
(ACFS, snapshots, registry, size) and information.
acfsutil snapshot Create and display ACFS snapshots.

acfsutil registry Register an ACFS file system with the ACFS mount
registry.
acfsutil rmfs Remove an ACFS file system.
acfsutil size Resize an ACFS file system.
acfsutil tune View or modify ACFS tuneables.
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
An ACFS snapshot is an online, space-efficient, point-

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

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

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
Default options:
Data Mining
OLAP
Partitioning
Real Application Testing

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


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


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

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:
Workload Manager
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

Initialization Parameter Information
USER_DUMP_DEST
BACKGROUND_DUMP_DEST DIAGNOSTIC_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 Database 11g

Optional generic
configuration
parameters
Oracle Oracle
RDBMS RDBMS
kernel kernel
Specific
configuration

parameters DBA
Specific Specific
kernel kernel
NFS driver NFS driver
Variations across platforms

Many parameters to tune
NAS NAS
Ease of NFS configuration
Storage Fewer parameters to tune
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.

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
1 Mount all expected mount points using kernel NFS driver.
2 (Optional) Create an oranfstab file.

mv libodm11.so libodm11.so_stub
3 ln -s libnfsodm11.so libodm11.so
Mount points lookup order

server: MyDataServer1
$ORACLE_HOME/dbs/oranfstab Load balancing path: 132.34.35.12
and path: 132.34.35.13
failover export: /vol/oradata1 mount: /mnt/oradata1
/etc/oranfstab
/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 Oracle-
specific 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.

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

Monitoring Direct NFS
SVR_ID/ V$DNFS_FILES
ID
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
For a bug fix or diagnostic patch on a running Oracle

instance, online patching provides the ability to do the
following:
Install

Enable
Disable
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).

Installing an Online Patch
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:
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.

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 Online Patches

Require down time to apply Do not require down time to apply
or remove or remove
Installed and uninstalled Installed and uninstalled

via OPatch via OPatch
Persist across instance startup Persist across instance startup
and shutdown and shutdown
Take several minutes to install Take only a few seconds to install
or uninstall 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.

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

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.

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

Quiz
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
Answers: 1, 3, and 4

Summary

Install Oracle Database 11g
Enable Direct NFS
Use online patching


In this practice, you use online patching to patch your

database.


Oracle Restart

11.2

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 Oracle Restart Oracle Restart

init daemon wrapper script daemons and processes
init ohasd.bin
init.ohasd 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

To enable or disable the automatic restart of Oracle
Restart:
$ 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

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 Automatically added to
configuration configuration?
Create a database with OUI or DBCA YES

Create a database with SQL statement NO
Create an ASM instance with OUI, DBCA, or ASMCA YES
Create a disk group (any method) YES

Add a listener with NETCA YES
Create a database service with SRVCTL YES
Create a database service by modifying NO
SERVICE_NAMES initialization parameter
Create a database service with NO
DBMS_SERVICE.CREATE SERVICE
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 add config disable enable getenv modify

remove setenv start status stop unsetenv
Components 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

For help on a particular command:
$ 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.

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 start database d PROD o mount
$ srvctl start listener l crmlistener

$ srvctl start service d PROD s "service1,service2"
$ srvctl start diskgroup g "DATA,FRA"
$ srvctl start asm
$ srvctl start eons -v
$ srvctl start 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 stop database d PROD o transactional
$ srvctl stop listener l crmlistener -f

$ srvctl stop service d PROD s "service1,service2"
$ srvctl stop diskgroup g "DATA,FRA" -f
$ srvctl stop asm o immediate -f
$ srvctl stop eons -v
$ srvctl stop 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

Specify a nondefault location for the new listener's
networking files:
$ 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.

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

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
Note
In this lesson, the term ASM data extent is shortened to extent.

Without ASM Fast Mirror Resync

1 ASM redundancy used 2 Disk access failure
Secondary
Primary
extent
extent

Oracle Database 10g and 11g
4 Disk added back: 3 Disk automatically dropped:

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

ASM Fast Mirror Resync: Overview

1 ASM redundancy used 2 Disk access failure
Secondary
Primary
extent
extent

Oracle Database 11g
Disk again accessible;

4
3 Failure time < DISK_REPAIR_TIME
need only to resync modified extents
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.


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.


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:

ALTER DISKGROUP dgroupA
OFFLINE DISKS IN FAILGROUP contrl2 DROP AFTER 5H;
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.

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
P S

Site A Site B
P P: Primary AU S
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
On first instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEA
On second instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEB

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
P S P S S S S P
Only two failure groups: One for each instance Max four failure groups: Two for each instance

Three sites: High redundancy
P S S
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

11.2
update
ASM Scalability and Performance
Enhancements
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
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:
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.

11.2
update
SYSASM Privilege
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.

11.2
update
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.
Setting disk group compatibility is irreversible.
DB ASM disk ASM

instance group 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).

11.2
update
ASM Disk Group Attributes
Name Property Values Description
au_size C 1|2|4|8|16|32|64MB Size of allocation units in the disk group
compatible.rdbms AC Valid database version Format of messages exchanged between DB

and ASM
compatible.asm AC Valid ASM instance Format of ASM metadata structures on disk
version
compatible.advm AC Valid database version Determines whether the disk group can
contain Oracle ASM volumes

access_control. A TRUE | FALSE Determines whether Oracle ASM File Access
enabled Control is enabled for a disk group
access_control. A {0|2|6}{0|2|6}{0|2|6} Set the default permission modes for newly
umask created files
sector_size C 512 | 4096 | 4K Make sure sector size of the disks in the
disk group are at the specified value
disk_repair_time AC 0 M to 232 D Length of time before removing a disk once
OFFLINE
template.tname. A UNPROTECT|MIRROR|HIGH Redundancy of specified template
redundancy
template.tname. A COARSE|FINE Striping attribute of specified template

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

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.

1 ALTER DISKGROUP data DISMOUNT;
2 ALTER DISKGROUP data MOUNT RESTRICT;
3 Maintenance task: Add/Remove disks
4 ALTER DISKGROUP data DISMOUNT;
5 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.

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 md_backup
Disk group name full
Disk names and failure groups

cp $ asmcmd help md_restore nodg
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.
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
If you want to copy an ASM file from your local ASM instance to a remote ASM instance, you
could use the following syntax:
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.

11.2
ASMCMD Command Extensions
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 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 Extensions: Example

ASMCMD> md_backup b jfv_backup_file -g data
Disk group to be backed up: DATA#
1
Current alias directory path: jfv
ASMCMD>
2 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.
3 Current Diskgroup being restored: DATA
Diskgroup DATA created!
User Alias directory +DATA/jfv
created!
ASMCMD>
4 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:

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

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

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 DISKGROUP ADD USERGROUP ... WITH MEMBER
ALTER DISKGROUP DROP USERGROUP
ALTER DISKGROUP MODIFY USERGROUP ADD MEMBER

ALTER DISKGROUP MODIFY USERGROUP DROP MEMBER
ALTER DISKGROUP ADD USER
ALTER DISKGROUP DROP USER
ALTER DISKGROUP SET PERMISSION
ALTER DISKGROUP 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

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

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

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
ASM Disk Group

Outer
JBOD Inner
Greater throughput disks Lesser throughput
tracks
tracks
mark files
ASM files

DBA
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

1
2 ATTRIBUTES (HOT MIRRORHOT);
SQL> CREATE TABLESPACE hottbs DATAFILE '+datadg(idptemp)'; 2

SQL> ALTER DISKGROUP datadg ALTER FILE '+datadg.342.3'
3
2 ATTRIBUTES (HOT MIRRORCOLD);
SQL> ALTER DISKGROUP datadg REBALANCE POWER 8; 4
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
Manage ASM Intelligent Data Placement by using ASMCA:


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
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 Write Primary Secondary

Frequency Frequency region region
High High HOT MIRRORHOT

High Low HOT MIRRORCOLD
Low High COLD MIRRORHOT
Low Low COLD MIRRORCOLD
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
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
Answer: 1

Summary

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

Use 4 KB sector disks
Employ data compression
Create a SQL Access Advisor analysis session using

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

Native mode: Logical 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.

11.2
Using 4 KB Sector Disks
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
Control Online redo Archived

Data files files log files 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.

11.2
Specifying the Disk Sector Size
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
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

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)

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

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. Move backup files to 4 KB disks.

2. Mount database.
3. Add log file groups on 4 KB disks.
4. Confirm their status.
5. Open the database.
6. 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 (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.
SQL> alter system switch logfile;
Database altered.
Postmigration steps:
1. Query the V$LOG view to ensure that all 512-byte block size logs have the INACTIVE 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.
---------- ---------- ---------- ----------------
3 4096 3 INACTIVE
4 4096 4 CURRENT

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.
Batched compression ensures no impact for most OLTP
transactions.
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.

Table Compression Concepts
Inserts are again

uncompressed.
Compressed
data
PCTFREE reached

triggers compression.
Uncompressed
data
Data block PCTFREE reached

triggers compression.
Header
PCTFREE
limit
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.

11.2
update
Compressing Table Data
Compression Compression CPU CREATE and Typical

Method Ratio Overhead ALTER TABLE Apps
Syntax
Basic High Minimal COMPRESS DSS
compression [BASIC]

OLTP table High Minimal COMPRESS FOR OLTP,
compression 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.

11.2
changes
Using OLTP Compression
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 SQL
to optimize Solution Access
my entire Advisor
workload?

DBA
No expertise
required Component
Workload of CBO
Provides
implementation
script
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
Workload
Hypothetical

STS
Filter
Options
Indexes Materialized Materialized Partitioned

views 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 Comprehensive Limited

Add new (partitioned) index on table or materialized view. YES YES
Drop an unused index. YES NO
Modify an existing index by changing the index type. YES NO
Modify an existing index by adding columns at the end. YES YES

Add a new (partitioned) materialized view. YES YES
Drop an unused materialized view (log). YES NO
Add a new materialized view log. YES YES
Modify an existing materialized view log to add new YES YES
columns or clauses.
Partition an existing unpartitioned table or index. 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.

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
ADD_STS_REF
Step 1
DELETE_STS_REF
CREATE_TASK EXECUTE_TASK
UPDATE_TASK_ATTRIBUTES INTERRUPT/CANCEL_TASK
DELETE_TASK MARK_RECOMMENDATION

QUICK_TUNE UPDATE_REC_ATTRIBUTES
GET_TASK_REPORT
Task-dependent GET_TASK_SCRIPT
SQL
Access Advisor
Advisor-dependent 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.

SQL Access Advisor: PL/SQL Example
BEGIN 1
dbms_advisor.create_task(dbms_advisor.sqlaccess_advisor,'MYTASK');
END;
BEGIN
dbms_advisor.set_task_parameter('MYTASK','ANALYSIS_SCOPE','ALL');
2

dbms_advisor.set_task_parameter('MYTASK','MODE','COMPREHENSIVE');
END;
BEGIN 3
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:
Locally managed temporary tablespaces
Online operation
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.
DBA_TEMP_FREE_SPACE
Lists temporary space usage information

Central point for temporary tablespace space usage
Column name Description

TABLESPACE_NAME Name of the tablespace
TABLESPACE_SIZE Total size of the tablespace, in bytes
ALLOCATED_SPACE Total allocated space, in bytes, including space that is currently

allocated and used and space that is currently allocated and
available for reuse
FREE_SPACE Total free space available, in bytes, including space that is

currently allocated and available for reuse and space that is
currently unallocated
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 INSERT INTO
Save disk space

Improve installation time
of applications with
large schemas
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
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.
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, session-
specific 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.

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;
Creating the segment for an index:
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.

Quiz
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.
4. Segment creation on demand is available for
nonpartitioned tables.
Answer: 2, 4

Summary

Use 4 KB sector disks
Employ data compression

Enterprise Manager
PL/SQL
Use deferred segment creation


This practice covers using table compression.


Data Warehouse and Partitioning Enhancements

Objectives

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
[C:\TEMP]type C:\TEMP/bar.bat
Windows uses a batch file
@cat %1 | tr hw HW rather than shell script to
SQL> @ex1
SQL> connect /as sysdba preprocess the data.
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
CREATE TABLE sales_transactions_ext External

(PROD_ID NUMBER, CUST_ID NUMBER, table
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'
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))
location ('sh_sales.dat.gz') External file using
)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'
BADFILE log_file_dir:'sh_sales.bad_xt'
EXECUTE privilege
LOGFILE log_file_dir:'sh_sales.log_xt'
FIELDS TERMINATED BY "|" LDRTRIM for directory object
( 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
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
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.

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

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.

11.2
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.
9. Consider auditing the directory object.

11.2
Considerations and Usage Notes
The PREPROCESSOR clause cannot be used with Oracle

Database Vault.
Output must go to standard out.

Considerations and Usage Notes

The PREPROCESSOR clause is not available for databases that use Oracle Database Vault.
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).

Quiz
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
Answer: 1

Review: Degree of Parallelism (DOP)
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

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

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

Running every query with a single degree of parallelism value
suboptimal in terms of overall response time
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.

11.2
Automatic Degree Of Parallelism Determination

SQL
1 DOP determination
Generate a serial plan.
Serial cost plan

If 3 Use DOP to generate
estimated elapsed Yes a parallel plan.
2
time > threshold
4 Compare
Worse
estimated parallel
elapsed time with estimated
No 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.
11.2
Summary of Changes to Parameters
New Parameters Allowable Values Default

PARALLEL_DEGREE_LIMIT Any number > 1, CPU, IO, CPU
AUTO
PARALLEL_DEGREE_POLICY MANUAL, LIMITED, AUTO MANUAL

PARALLEL_FORCE_LOCAL TRUE, FALSE FALSE
PARALLEL_MIN_TIME_THRESHOLD Any number > 0, AUTO AUTO
Changes to Existing Parameters New / Equivalent

PARALLEL_THREADS_PER_CPU _PARALLEL_THREADS_PER_CPU
PARALLEL_IO_CAP_ENABLED 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-fits-
all policy.
It determines that it is not beneficial for some

statements to be executed in parallel.
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.
PARALLEL_MIN_TIME_THRESHOLD any number > 0, AUTO 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.

11.2
Using PARALLEL_DEGREE_POLICY
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.
PARALLEL_DEGREE_POLICY MANUAL, LIMITED, AUTO 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.
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
CPU scan
Maximum DOP?

PARALLEL_DEGREE_LIMIT Any number >= 1, CPU, IO, CPU
AUTO
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.
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.

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.
PARALLEL_FORCE_LOCAL TRUE, FALSE 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.

11.2
Changes to Existing Parameters
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
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

11.2
Parallel Hints Are Now at the Statement 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.
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.

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;

PARALLEL_DEGREE_POLICY is set to MANUAL, so
parallel hint is for object:
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.

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

Quiz
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
Answer: 1

Oracle Partitioning
Core functionality Performance Manageability

Oracle8 Range partitioning Static partition Basic maintenance
Global range indexes pruning operations: add,
drop, exchange
Oracle8i Hash and composite Partitionwise joins Merge operation

range-hash partitioning Dynamic pruning

Oracle9i List partitioning Global index
maintenance
Oracle9i R2 Composite range-list Fast partition split

partitioning
Oracle10g Global hash indexes Local Index

maintenance
Oracle10g R2 1M partitions per table Multidimensional Fast drop table

pruning
Oracle More composite choices Interval Partitioning

REF Partitioning Partition Advisor
Database 11g
Virtual Column Partitioning
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 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
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: 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 P3 Pi1 Pin
Range section 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 INSERT INTO orders_interval ();
Transition point
Not yet
PREVIOUS materialized
SYS_Px SYS_Py SYS_Pz SYS_Pt

< 01/01/07 < 01/08/07 < 01/11/07 < 01/12/07 < 01/03/08
Transition point
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 SYS_Px SYS_P5z SYS_Pt

< 01/01/07 < 01/08/07 < 01/12/07 < 01/03/08
Transition point
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 upper-
most 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:
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
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: Example
CREATE TABLE systab (c1 integer, c2 integer)

PARTITION BY SYSTEM
(
PARTITION p1 TABLESPACE tbs_1,

PARTITION p4 TABLESPACE 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
The following operations are supported for system-

partitioned 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:
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

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.
CREATE INDEXTYPE [<schema>.]<indextype_name>

using_type_clause
WITH LOCAL [RANGE] PARTITION
WITH SYSTEM MANAGED STORAGE TABLES
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.

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.

CREATE TABLE employees
(employee_id number(6) not null,

total_compensation as (salary *( 1+commission_pct))
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.

Virtual ColumnBased Partitioning: Example
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 p4 VALUES LESS THAN (MAXVALUE)
);
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.

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

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 object-
level 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
RANGE, LIST, INTERVAL
List top level
SP1 SP1 SP1 SP1
List-List SP1

List-Hash
SP2 SP2 SP2 SP2 SP2
List-Range
Interval top level SP3 SP3 SP3
SP3 SP3
Interval-Range
Interval-List SP4 SP4 SP4 SP4 SP4
Interval-Hash
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.

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

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

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:
Affecting fragmentation
Upper size limit
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.

Oracle SecureFiles
Oracle SecureFiles rearchitects the handling of

unstructured (file) data, offering entirely new:
Disk format
Variable chunk size
Network protocol

Improved input/output
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.

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 industry-
standard 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 CLOB)

LOB(doc) STORE AS SECUREFILE (ENCRYPT);
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 Shared I/O

Cache Pool
Block-size buffers Memory Allocation

Shared I/O Pool buffers
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 Disable deduplication.
MODIFY LOB(a) ( KEEP_DUPLICATES );
ALTER TABLE t1 Enable deduplication.
MODIFY LOB(a) ( DEDUPLICATE LOB );
ALTER TABLE t1 Enable partition
deduplication.
MODIFY PARTITION p1 LOB(a) ( DEDUPLICATE LOB );
ALTER TABLE t1 Disable compression.
MODIFY LOB(a) ( NOCOMPRESS );

Enable compression.
ALTER TABLE t1
MODIFY LOB(a) (COMPRESS HIGH); Enable compression on SecureFiles
ALTER TABLE t1 within a single partition.
MODIFY PARTITION p1 LOB(a) ( COMPRESS HIGH );
ALTER TABLE t1 MODIFY Enable encryption using 3DES168.

( a CLOB ENCRYPT USING '3DES168');
Enable encryption on partition.
ALTER TABLE t1 MODIFY PARTITION p1
( LOB(a) ( ENCRYPT );
Enable encryption and build
ALTER TABLE t1 MODIFY the encryption key using a
( a CLOB ENCRYPT IDENTIFIED BY ghYtp); password.
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.

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
In Oracle Database 11g Release 2, a new SecureFile

compression mode, LOW, is available.
LOW mode is recommended for customers who want:
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.

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 1
MAXSIZE 3000M

SEGMENT SPACE MANAGEMENT AUTO;
Create a table to hold the LOB data with COMPRESS LOW:

CREATE TABLE profiles
(id NUMBER,
first_name VARCHAR2 (40),
last_name VARCHAR2 (80),
profile_info BLOB) 2
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.

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
SecureFiles

GETOPTIONS()
SETOPTIONS
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 number not null, c clob)
partition by range(id)
(partition p1 values less than (100) tablespace tbs1 lob(c) store as securefile,
partition p2 values less than (200) tablespace tbs2 lob(c) store as securefile,
partition p3 values less than (300) tablespace tbs3 lob(c) store as securefile);
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.

SecureFiles Monitoring
The following views have been modified for showing

SecureFiles usage:
*_SEGMENTS
*_LOBS
*_LOB_PARTITIONS

*_PART_LOBS
SQL> SELECT segment_name, segment_type, segment_subtype
2 FROM dba_segments
3 WHERE tablespace_name = 'SECF_TBS2'
4 AND segment_type = 'LOBSEGMENT'
5 /
SEGMENT_NAME SEGMENT_TYPE SEGMENT_SU

---------------------------- ------------------ ----------
SYS_LOB0000071583C00004$$ LOBSEGMENT SECUREFILE

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

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:

Passwords are not case-sensitive until changed
Passwords become case-sensitive when the ALTER USER
command is used
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.

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
Remove archived audit records.
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.

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 ANY JOB ALTER/CREATE/DROP CREATE SESSION
ANY PROCEDURE
GRANT ANY OBJECT ALTER DATABASE AUDIT SYSTEM

PRIVILEGE
EXEMPT ACCESS GRANT ANY ROLE ALTER SYSTEM

POLICY
CREATE ANY LIBRARY CREATE PUBLIC SYSTEM AUDIT

DATABASE LINK
GRANT ANY PRIVILEGE ALTER/CREATE/DROP ROLE

ANY TABLE
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
Protect against brute force attacks:
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 non-
case-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.

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.
Set LDAP_DIRECTORY_SYSAUTH to YES to use any of
the strong authentication methods.
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.

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

Hardware Security Module
Encrypt and decrypt operations

are performed on the Hardware
hardware security module. 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> CREATE TABLESPACE encrypt_ts

2> DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100M
3> ENCRYPTION USING '3DES168'
4> 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 Pre-11.2.0 11.2.0

Features
Tablespace Master Key TDE tablespace encryption Unified Master Key *

master key is separate from
TDE column encryption
master key

Regenerate Master key Not possible Use ALTER SYSTEM
ESM use 11.1.0.6: Wallet ONLY; Store Master key in

11.1.0.7: TDE tablespace HSM or wallet
encryption MK created and
stored in HSM
* 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
Manage security through Enterprise

Manager.
Policy Manager replaced for:
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.

Using RMAN Security Enhancements
Configure backup shredding:

RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON;
Use backup shredding:

RMAN> DELETE FORCE NOPROMPT BACKUPSET TAG weekly_bkup;
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 password-
protected 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.

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:
2001:0DB8:0000:0000:0000:0000:200C:417A
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:
2001:0DB8:0000:0000:0000:0000:0000:0000
2001:0DB8:0000:0000:FFFF:FFFF:FFFF:FFFF
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
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= 1 IPv6 address:
(ADDRESS=(PROTOCOL=tcp) 2001:0DB8::200C:417A
x(HOST=host01-server)
(PORT=1521))

(CONNECT_DATA=
(SID=host01)
(SERVICE_NAME=host01.example.com) 2 IPv4 address:
(INSTANCE_NAME=host01))) 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

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

Summary

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


Changing the use of case-sensitive passwords
Implementing a password complexity function
Encrypting a tablespace




SQL Performance Analyzer

Objectives

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)

Diagnose and
Make change resolve problems
(advisors)
Set up test

environments
(snapshot standby Provision for
databases) production
Patches and Diagnose problems

workarounds
Realistic testing

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.

Test
Diagnose and
Make change resolve problems
Set up test

environments
Provision for
production
(rolling upgrades)
Patches and Diagnose problems

(ADR/Support Workbench)
workarounds
(Enterprise Manager)
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 best-
practice steps in the patching procedure.

SQL Performance Analyzer: Overview
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: 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.

SQL Performance Analyzer: Use Cases
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
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
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.

Using SQL Performance Analyzer
1. Capture SQL workload on production.

2. Transport the SQL workload to a test system.
3. Build before-change performance data.
4. Make changes.

5. Build after-change performance data.
6. Compare results from steps 3 and 5.
7. Tune regressed SQL.
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.
Step 1: Capture SQL Workload
SQL Tuning Set (STS) is used to

store SQL workload. Includes:
SQL Text
Bind variables
Cursor cache Execution plans

Incremental capture
Execution statistics
Incremental capture is used to
Database Instance
populate STS from cursor cache
over a period of time.
STSs filtering and ranking
capabilities filter out undesirable
SQL.
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.

Step 2: Transport to a Test System
Cursor cache
Database instance Database instance

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

11.2
update
Step 3: Build Before Change
Performance Data
Before change, SQL performance Test/execute

version is the SQL workload
performance baseline.
SQL performance = execution plans
+ execution statistics

Test/execute SQL in STS: Before
changes
Produce execution plans and Database instance
statistics.
Execute SQL serially
(no concurrency).
Every SQL is executed at least
twice.
Skip DDL/DML effects.
Explain plan SQL in STS generates Test
only SQL plans. database
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.

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 After
changes Database instance
Database parameter changes After changes
implemented
Reexecute SQL after change:
Test/execute SQL in STS to
generate SQL execution plans and
statistics.
Explain plan SQL in STS to Test
generate SQL plans. 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.

Step 6: Compare and Analyze Performance and

Step 7: Tune Regressed SQL
Rely on user-specified metric to SQL Tuning Advisor
compare SQL performance:
ELAPSED_TIME, BUFFER_GETS,
DISK_READS, ...
Calculate impact of change on
individual SQLs and SQL workload: Improvement Regression

Overall impact on workload
Compare
Net SQL impact on workload analysis
Database instance
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. Test
Analysis results can be used to seed database
SQL Plan Management baselines.
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;

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

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:

BEGIN
DBMS_SQLTUNE.CREATE_TUNING_TASK(
spa_task_name => 'MYSPA',
spa_compare_exec => 'MYCOMPEXEC');
END;
/
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.

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.
(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.
(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.
(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.
(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
New views in Oracle Database 11g:
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)

Summary

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


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

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.
Only comparable or better plans are used going forward.
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.

SQL Plan Baseline: Architecture

SYSAUX
SQL Management Base
Statement log
Plan history
Plan history
Plan
baseline Plan
GB
GB baseline
GB GB
GB SQL

HJ HJ HJ
HJ HJ
GB
HJ HJ profile
Repeatable HJ HJ HJ
HJ HJ
SQL
statement
Plan History
Plan
baseline
GB
GB GB
HJ HJ HJ
HJ
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.

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
Plan history ba
an se
Pl
load_plans_from_cursor_cache
lin
ba GB e
an se
Pl lin
load_plans_from_sqlset
1 e HJ
HJ
GB
HJ
HJ

GB ALTER_SQL_PLAN_BASELINE
HJ
2
HJ
*_STGTAB_BASELINE
GB
HJ 3
HJ Staging
Cursor table
cache
Plan history
ba
an se
Pl GB lin
e 4
HJ
HJ
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
ba
an se
Automatic Pl lin
e

GB
SQL Tuning HJ
HJ
DBA 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.
Viewing Important Baseline SQL Plan Attributes
Plan history
ba
an se
GB
Pl lin
e
GB
Enabled but HJ
Enabled and
HJ
not accepted HJ HJ
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 (AUTO-
CAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning
Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTO-
SQLTUNE).
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 OPTIMIZER_USE_SQL_ Plan part

HJ PLAN_BASELINES=TRUE? Yes of history? No
HJ
Plan history
Yes
Plan
No
baseline
GB
GB GB

GB
HJ HJ HJ
Plan part HJ HJ
HJ
HJ
Yes of baseline?
HJ
No
Select baseline plan

with lowest best-cost
GB GB GB GB
Yes No
DBMS_XPLAN.DISPLAY(,'BASIC +NOTE) HJ HJ > HJ HJ
or HJ HJ HJ HJ
PLAN_TABLE(other_xml)
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.

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

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
4. Automatically by default

Possible SQL Plan Manageability Scenarios

Database Upgrade New Application Deployment
Oracle Database 11g Production database
Plan History Plan History
ba ba
an s an s
GB Pl GB eline GB Pl GB eline
HJ HJ HJ HJ
HJ HJ HJ HJ
No plan No plan
regressions regressions

DBA
DBA Plan history

ba
an s
GB Pl GB eline
GB HJ HJ
Well-
tuned HJ HJ HJ
plan HJ Well-tuned Baseline
plan 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 Oracle Database 11g

change O_F_E=10
Plan History
ba
an se
Pl GB lin
e GB
HJ HJ
HJ HJ
Regressing

statements No plan
regressions
After
change
O_F_E=11
optimizer_features_enable
GB GB GB
HJ HJ HJ
HJ HJ HJ Well-
tuned
plans
Oracle Database 10g
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 No plan Oracle Database 11g No plan
regressions regressions
Plan history New plan Plan history
waiting
Plan verification Plan
baseline baseline
GB GB
GB GB GB
HJ HJ
HJ HJ HJ
HJ HJ
HJ HJ HJ

OPTIMIZER_FEATURES_ENABLE=10.2.0.2 OPTIMIZER_FEATURES_ENABLE=11.1.0.1
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
Oracle Database 11g Better

plans
Plan history
Plan baseline
GB GB GB
GB
GB Well- HJ HJ HJ
HJ tuned
HJ HJ HJ HJ
HJ plans
HJ
Oracle Database 10g OPTIMIZER_FEATURES_ENABLE=11.1.0.1

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
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 Alert log

105 SQL Management SYSAUX
Base
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).

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

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

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?
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.
Despite expensive testing, success rates are low:
Many issues go undetected.
Changes can negatively affect system availability and performance.
Cause of low success rate:
Inability to properly test with real-world production workloads, with
many issues going undetected.
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.

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
Replay workload in test:
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.

The Big Picture

Prechange production system Postchange test system
Clients/app servers
Capture directory Replay
system
Process capture files

Shadow capture file
Shadow capture file

Shadow capture file
Test
Production Shadow capture file system
system with
changes
Production Database Database

database backup restore
Can use Snapshot Standby as test system
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.

System Architecture: Capture
Capture directory
Shadow capture file

Shadow Shadow Shadow Shadow
Shadow capture file

Recording infrastructure

Database stack Shadow capture file
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.

System Architecture: Preprocessing the

Workload
Capture directory
Preprocess capture files

Shadow capture file
Shadow capture file

Shadow capture file

Database
backup
Production
Preprocess
database 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.

System Architecture: Replay

Replay
system Replay Replay
client client
Capture directory
Preprocess capture files

Shadow Shadow Shadow Shadow
Shadow capture file
Shadow capture file

Shadow capture file

Test
system
with
Database changes
backup
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.

Prechange Production System
Changes not supported

Clients/app servers

Supported changes:
Database upgrades, patches
Production
Schema, parameters system
RAC nodes, interconnect

OS platforms, OS upgrades
CPU, memory Production
Storage 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.

11.2
update
Supported Workloads
Supported:
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
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.

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:
Physical restore (scn/time provided)
Logical restore of application data
Flashback/snapshot standby
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.
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
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-in-
time recovery, flashback, and import/export.

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)

Modify DB Links and directory objects that point to
production systems
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.

11.2
update
Replay Options
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.

11.2
update
Replay Options
Think time options:

Auto (default)
Adjust think time to maintain the captured request rate:
0%: No think time (highest possible request rate)

<100%: Higher request rate
100%: Exact think time
>100%: Lower 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.

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

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.

11.2
update
Packages and Procedures
DBMS_WORKLOAD_CAPTURE DBMS_WORKLOAD_REPLAY
START_CAPTURE PROCESS_CAPTURE
FINISH_CAPTURE INITIALIZE_REPLAY
ADD_FILTER PREPARE_REPLAY


DELETE_FILTER START_REPLAY
DELETE_CAPTURE_INFO CANCEL_REPLAY
GET_CAPTURE_INFO() DELETE_REPLAY_INFO
EXPORT_AWR REMAP_CONNECTION
IMPORT_AWR() EXPORT_AWR
REPORT() 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');

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.

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

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

Data Dictionary Views: Database Replay
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
Data Dictionary Views: Database Replay

For information about these views, see the Oracle Database Reference.

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

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

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

Accept profiles
SQL Tuning
Automatic High load Advisor 4
Generate
SQL profiles
2
ADDM
DBA
3
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 high-
load 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
To
p
SQ
L
Workload Auto matic

3
SQL Tuning
R
ep
or
4
ts 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

Candidate list
1. Pull the top queries from the past week into four buckets:
y Top for the past week
y Top for any day in the past week
y Top in any single hour
y 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.

Maintenance Window Timeline
Automatic SQL Tuning task
Pick
candidate
Tune Test Accept Tune
S1 P1 P1 S2
SQL

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
Considered for
auto implementation
Restructure New
SQL SQL profile
Existing N 3X Y

benefit? Accept profile
Indexes profile?
N
Y
3X N
Ignore new profile
benefit?
Stale
stats
Y
Replace profile
GATHER_STATS_JOB
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:
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
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.

Example: Controlling the Automatic SQL Tuning

Task
BEGIN
dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK',
'LOCAL_TIME_LIMIT', 1400);

'ACCEPT_SQL_PROFILES', 'TRUE');
'MAX_SQL_PROFILES_PER_EXEC', 50);
'MAX_AUTO_SQL_PROFILES', 10002);
END;
Example: Controlling the Automatic SQL Tuning Task

Here is a PL/SQL control example for the Automatic SQL Tuning task:
BEGIN
'LOCAL_TIME_LIMIT', 1400);
'ACCEPT_SQL_PROFILES', 'TRUE');
'MAX_SQL_PROFILES_PER_EXEC', 50);
'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.

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

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

Use DBMS_AUTO_TASK_ADMIN to enable and disable

SYS_AUTO_SQL_TUNING_TASK:
ENABLE
DISABLE

Use dictionary views access Automatic SQL Tuning
information :
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

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';
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 test-
execution 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

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.


Enhancements

Intelligent Infrastructure

Objectives

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
AWR Baseline contains a set of AWR
snapshots for an interesting or
Actual
reference period of time
Baseline is key for performance
tuning to:

Guide setting of alert thresholds
Monitor performance
Compare advisor reports
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.

Automatic Workload Repository Baselines
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.
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 system-
defined 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.

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

By default, the adaptive thresholds functionality
computes statistics on this baseline.
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.

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

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
The following function has been added:
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.

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 end-
snapshot 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
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;
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.

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
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.
Answers: 1 and 2

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:

Automatically computed over the system moving window
Manually computed over static 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.

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 Run Job2 Run Job3 Run Job3 Run Job4
with with with with with
urgent urgent high medium medium
priority priority priority priority priority

urgent MMON
Stats high
Maintenance medium
window ABP
Space
Job1 Jobn
SQL
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.
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 Metric = MBPS

and latency
Need large
Need high RPM and
I/O channel
fast seek time

OLTP DW/OLAP
(Small random I/O) (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


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

In Oracle Database 11g Release 2, the maximum
utilization limit directive limits the CPU consumption
of an application.
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.

11.2
Limiting CPU Utilization
Specify minimum and Specify maximum CPU

maximum CPU utilization limits utilization limits only
DB Consolidation Plan #1 DB Consolidation Plan #2
Cons CPU Maximum Cons CPU Maximum

Group Allocation Utilization Limit Group Allocation Utilization Limit

App_1 50% 60% App_1 null 50%
App_2 20% 30% App_2 null 20%
App_3 20% 30% App_3 null 20%
App_4 10% 20% App_4 null 10%
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:
Contention for CPU, memory, and I/O
Unexpected workload surges on one instance can wreak
havoc on other databases
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.

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:
Database Resource Manager limits the amount of CPU
that the database instance consumes.
The CPU_COUNT initialization parameter specifies the
limit.
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 non-
critical 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.

11.2
Instance Caging Examples
One database instance One database instance

can still impact the others. cannot impact the others.
Sum of CPU_COUNTS settings = 32 Sum of CPU_COUNTS = 16
32 16 Total Number
Instance D of CPUs = 16
Instance D
24 12 Instance C

Instance C Instance B
16 Total Number 8
of CPUs = 16
Instance B
8 4 Instance A
Instance A
Over-provisioning approach: Partitioning approach:

With all four instances active, Each instance has a
one instance can get dedicated number of CPUs.
8/(8+8+8+8)=25% of CPU.
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;

Set the RESOURCE_MANAGER_PLAN parameter to enable
any CPU resource plan:
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.

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:

SELECT name FROM v$rsrc_plan
WHERE is_top_plan = 'TRUE' AND cpu_managed = 'ON';
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.

Quiz
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.
Answers: 1 and 3

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

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

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

Create AWR baselines for future time periods
Control automated maintenance tasks
Use Resource Manager enhancements



D50081GC21 sg1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

D50081GC21 sg1

Transféré par

Droits d'auteur :

Formats disponibles

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Oracle University and Aspect Software Inc use only

Christian Bauwens Disclaimer

Oracle University and Aspect Software Inc use only

If this documentation is delivered to the United States Government or anyone using

Maqsood Alam U.S. GOVERNMENT RIGHTS

Oracle University and Aspect Software Inc use only

1 Oracle Grid Infrastructure

Configuring the FRA Disk Group 1-24

Oracle University and Aspect Software Inc use only

Installation Finish Page 2-16

Oracle University and Aspect Software Inc use only

ASM Fast Mirror Resync: Overview 4-4

Oracle University and Aspect Software Inc use only

Using 4 KB Sector Disks 5-4

Oracle University and Aspect Software Inc use only

6 Data Warehouse and Partitioning Enhancements

Considerations and Usage Notes 6-12

Oracle University and Aspect Software Inc use only

Issues with Existing LOB Implementation 7-4

Oracle University and Aspect Software Inc use only

8 Security and Networking Enhancements

Managing Fine-Grained Access to External Network Services 8-21

9 SQL Performance Analyzer

Oracle University and Aspect Software Inc use only

10 SQL Plan Management

Viewing Important Baseline SQL Plan Attributes 10-8

Oracle University and Aspect Software Inc use only

12 Automatic SQL Tuning

Automatic SQL Tuning in Oracle Database 11g 12-4

Oracle University and Aspect Software Inc use only

13 Intelligent Infrastructure Enhancements

I/O Calibration and Enterprise Manager 13-27

Oracle University and Aspect Software Inc use only

Track the SR and Implement Repairs 14-24

Oracle University and Aspect Software Inc use only

15 Real-Time SQL Monitoring

Modified Advisor Views 16-7

Oracle University and Aspect Software Inc use only

17 Application Performance Enhancements

Usage Guidelines to Reduce Invalidation 17-9

Oracle University and Aspect Software Inc use only

18 Backup and Recovery Enhancements

Parallel Backup and Restore for Very Large Files 18-13

Oracle University and Aspect Software Inc use only

19 Flashback Technology, LogMiner, and Data Pump Enhancements

Flashback Data Archive: Supporting Transparent Schema Evolution 19-17

Oracle University and Aspect Software Inc use only

20 Data Recovery Advisor

Appendix A: Practices and Solutions

Appendix B: Scheduler Enhancements

Oracle University and Aspect Software Inc use only

Using Destination Groups for Multiple Destination Jobs B-40

Oracle University and Aspect Software Inc use only

Copyright 2009, Oracle. All rights reserved.

Oracle University and Aspect Software Inc use only

This course focuses on those features of Oracle

Oracle University and Aspect Software Inc use only

Copyright 2009, Oracle. All rights reserved.

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

Oracle Database Innovation

Oracle University and Aspect Software Inc use only