Oracle11g New Features Vol2

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2013, Oracle and/or its affiliatesฺ
ble
fe r a
ans
n - t r
a no
Oracle Database
h a s 11g:ฺ New
r ) e
Features
m uid
ฺa forGAdministrators
n ฺ co ent
@ ao Stud
z i l le thVolume
is II • Student Guide
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
Marc
D50081GC21
Edition 2.1
September 2010
D63698
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
and Reviewers
the documentation on behalf of the United States Government, the following notice is
ble
applicable:
fe r a
Maqsood Alam U.S. GOVERNMENT RIGHTS
an s
Kalyan Bitra
John Boyle n - t r
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
o
an
license agreement and/or the applicable U.S. Government contract.
Harald Van Breederode
Sharath Bhujani Trademark Notice s
ha deฺ
Immanuel Chan
Timothy Chien
r )
ฺa Gui
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
Edward Choi m
co ent
may be trademarks of their respective owners.
n ฺ
Jacco Draaijer
Al Flournoy
@ ao Stud
Steve Fogel
z i l le this
Andy Fortunak
c e loฺ use
Gerlinde Frenzen
a r to
Greg Gagnon m e
GP Gongloor
i l l e ( icens Technical Contributors
oZ
Joel Goodman
e l
Hansen Han
l and Reviewers
arc
Tim Shetler
Uwe Hesse Eric Siglin
M 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 ble
Suggested Additional Courses I-9 fe r a
ans
Further Information I-10
n - t r
Suggested Schedule I-11 o
s an
1 Oracle Grid Infrastructure r ) ha deฺ
Objectives 1-2 m ฺa Gui
Oracle Grid Infrastructure 1-3 n ฺ co ent
Automatic Storage Management Technology
@ ao Stack S tud1-4
z
Oracle Grid Infrastructure and i l le Database
Oracle t h is Installation: System
Requirements 1-5cel
oฺ use
a r System
to 1-6
Preparing the Operating
m e
l l e ( iceVariables
Setting iEnvironment ns 1-7
Z l
lo the System Requirements 1-8
r c eChecking
Ma 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
ble
ASM Cluster File System (ACFS) 1-39 fe r a
ACFS Architecture 1-40 ans
n - t r
Using Enterprise Manager to Manage ACFS 1-41 o
Linux/UNIX File System APIs 1-42
s an
Linux/UNIX Extensions 1-43
r ) ha deฺ
Windows File System APIs 1-44
m ฺa Gui
Windows Extensions 1-45
n ฺ co ent
ao Stud
ACFS Platform-Independent Commands 1-46
@
i l le this
ASM Cluster File System Limitations 1-47
z
c e loฺ use
Creating an ASM Cluster File System 1-48
a
ACFS Snapshots 1-49r to
m e
i l l e ( icens
Administering Oracle ACFS Snapshots 1-50
e oZ
Quiz 1-51
l l
Marc 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
ble
Installing an Online Patch 2-31 fe r a
Benefits of Online Patching 2-32 ans
n - t r
Conventional Patching and Online Patching 2-33 o
Online Patching Considerations 2-34
s an
Quiz 2-36
r ) ha deฺ
Summary 2-37
m ฺa Gui
n ฺ co ent
@ ao Stud
3 Oracle Restart
z i l le this
Objectives 3-2
c e loฺ use
Oracle Restart 3-3 a r to
m e
Oracle Restart
i l l e ( Process
i c e s
nStartup 3-5
l o Z
Controlling l
Oracle Restart 3-6
e
rc Choosing the Correct SRVCTL Utility 3-8
Ma 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 ble
ASM Disk Group Compatibility 4-19 fe r a
ASM Disk Group Attributes 4-21 ans
n - t r
Using Enterprise Manager to Edit Disk Group Attributes 4-22 o
Enhanced Disk Group Checks 4-23
s an
Restricted Mount Disk Group for Fast Rebalance 4-24
r ) ha deฺ
Mount Force Disk Group 4-25 m ฺa Gui
Forcing Disk Group Drop 4-27 n ฺ co ent
ao Stud
ASMCMD Extensions in Oracle Database 11g Release 1 4-28
@
ASMCMD Command Extensions 4-30
z i l le this
c e loฺ use
ASMCMD Extensions: Example 4-31
Quiz 4-32 a r to
m e
l e ( icens
ASM ACLs 4-33
i l
e oZ l
ASM ACLs Prerequisites 4-34
l
Marc 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 ble
Using the Compression Advisor 5-18 fe r a
ans
Viewing Table Compression Information 5-19
n - t r
SQL Access Advisor: Overview 5-20 o
SQL Access Advisor: Usage Model 5-21 s an
Possible Recommendations 5-22
r ) ha deฺ
Using SQL Access Advisor 5-23 m ฺa Gui
ฺ co ent
SQL Access Advisor: PL/SQL Procedure Flow 5-24
n
ao Stud
SQL Access Advisor: PL/SQL Example 5-25
@
i
Temporary Tablespace Shrink 5-26
z l le this
e
DBA_TEMP_FREE_SPACE 5-27
c loฺ use
a r to
Tablespace Option for Creating Temporary Table 5-28
m e
l l e ( icens
Segment Creation on Demand 5-29
i
e loZ l
Creating Tables Without Segments 5-30
Marc 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 ble
fe r a
Parallel Hints Are Now at the Statement Level 6-27 s
Implication of Statement-Level Parallel Hints 6-28
- t r an
EXPLAIN PLAN Enhancements 6-29 o n
Enhanced Explain Plan Example 6-30 s an
In-Memory Parallel Query 6-31 r ) ha deฺ
Quiz 6-32 m ฺa Gui
Oracle Partitioning 6-33 n ฺ co ent
Partitioning Enhancements 6-34 @ ao Stud
Interval Partitioning 6-35 z i l le this
c e loฺ use
Interval Partitioning: Example 6-36
a r to
m e
Moving the Transition Point: Example 6-37
i l l e ( icens
System Partitioning 6-39
e loZ l
System Partitioning: Example 6-40
Marc System Partitioning: Guidelines 6-41

System-Managed Indexes for List Partitioning 6-42
Virtual Column–Based Partitioning 6-43
Virtual Column–Based 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
ble
Creating a SecureFile LOB with LOW Compression 7-16 fe r a
Configuration Parameters 7-17 ans
n - t r
Quiz 7-18 o
Accessing SecureFiles Metadata 7-19
s an
Migrating to SecureFiles 7-20
r ) ha deฺ
SecureFiles Migration: Example 7-21 m ฺa Gui
SecureFiles Monitoring 7-22 n ฺ co ent
Summary 7-23
@ ao Stud
z i l le this
c e loฺ use
a
8 Security and Networkingr to
Enhancements
m
( ens e
Objectives
i l l e 8-2
o Z PasswordlicSupport 8-3
Secure
l
rceAutomatic Secure Configuration 8-4
Ma 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
ble
Lifecycle of Change Management 9-6 fe r a
SQL Performance Analyzer: Overview 9-8 ans
n - t r
SQL Performance Analyzer: Use Cases 9-9 o
Using SQL Performance Analyzer 9-10
s an
Step 1: Capture SQL Workload 9-11
r ) ha deฺ
Step 2: Transport to a Test System 9-12
m ฺa Gui
ฺ co ent
Step 3: Build Before Change Performance Data 9-13
n
ao Stud
Step 4: Implement Planned Change and Step 5: Build After-Change
@
Performance Data 9-14
z i l le this
c e loฺ use
Step 6: Compare and Analyze Performance and Step 7: Tune Regressed SQL 9-15
Quiz 9-16 a r to
m e
i l l e ( icens
Accessing SQL Performance Analyzer 9-17
e oZ l
Using Enterprise Manager to Access SQL Performance Analyzer 9-18
l
Marc 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
Practice 10: Overview 10-20 ble
fe r a
11 Database Replay ans
n - t r
Objectives 11-2 o
Why Use Database Replay? 11-3
s an
Using Database Replay 11-4
r ) ha deฺ
The Big Picture 11-5 m ฺa Gui
System Architecture: Capture 11-6 n ฺ co ent
ao Stud
System Architecture: Preprocessing the Workload 11-7
@
i
System Architecture: Replay 11-8
z l le this
c e loฺ use
Prechange Production System 11-9
a r
Supported Workloads 11-10 to
m e
l e ( icens
Capture Considerations 11-11
i l
e oZ l
Replay Considerations 11-12
l
Marc 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
ble
Using the PL/SQL Interface to Generate Reports 12-18 fe r a
Automatic SQL Tuning Considerations 12-19 ans
n - t r
Summary 12-20 o
s an
r ) ha deฺ
13 Intelligent Infrastructure Enhancements
m ฺa Gui
Objectives 13-2
n ฺ co ent
Using New and Enhanced Automatic Workload
@ tud Views 13-3
ao SRepository
Comparative Performance Analysis
z i l le withtAWR
h is Baselines 13-4
c e loฺ Baselines
Automatic Workload Repository
u se 13-5
a r
Moving Window Baseline to
13-6
m e
i l e ( iOptions
Baseline Display
l c e ns 13-7
Z Templates
Baseline
l o l 13-8
e
Marc 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
ble
Enabling Instance Caging 13-42 fe r a
Monitoring Instance Caging 13-43 ans
n - t r
Quiz 13-44 o
Resource Manager: Changes to DBMS_RESOURCE_MANAGER 13-45
s an
Resource Manager: New Enterprise Manager Interface 13-46
r ) ha deฺ
Resource Plans Created by Default 13-47 m ฺa Gui
Default Plan 13-48 n ฺ co ent
I/O Resource Limit Thresholds 13-49
@ ao Stud
i
Resource Manager Statistics 13-50
z l le this
Summary 13-51
c e loฺ use
a r to
m e
i l l
14 Diagnosabilitye ( Enhancements
c e ns
o Z 14-2li
Objectives
l
rceOracle Database 11g Fault Management 14-3
Ma 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 ble
Using SQL Repair Advisor from PL/SQL: Example 14-38 fe r a
ans
Using the SQL Test Case Builder 14-39
n - t r
Quiz 14-40 o
Summary 14-41 s an
r ) ha deฺ
m ฺa Gui
15 Real-Time SQL Monitoring n ฺ co ent
Objectives 15-2
@ ao Stud
SQL Monitoring 15-3 z i l le this
ฺ
loDatabase e Release 2 15-5
s11g
SQL Monitoring in Oracle
c e
r Enterprise u
SQL Monitoring with
m a e to Manager Database Control 15-6
Monitored
i l l eSQL( Executions
c e ns 15-7
SQL
l o Z
Monitoring li 15-8
List
e
Marc 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
ble
Quiz 16-24 fe r a
DB Smart Flash Cache Overview 16-25 ans
n - t r
Using DB Smart Flash Cache 16-26 o
DB Smart Flash Cache Architecture Overview 16-27
s an
Configuring DB Smart Flash Cache 16-28
r ) ha deฺ
Sizing DB Smart Flash Cache 16-30
m ฺa Gui
ฺ co ent
Specifying DB Smart Flash Cache for a Table 16-31
n
Statistic Preferences: Overview 16-32
@ ao Stud
i l le this
Using New Statistic Preferences Features 16-33
z
c e loฺ use
Setting Global Preferences with Enterprise Manager 16-34
a r to
Partitioned Tables and Incremental Statistics: Overview 16-35
m e
i l l e ( icens
Hash-Based Sampling for Column Statistics 16-37
e oZ l
Multicolumn Statistics: Overview 16-39
l
Marc 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 ble
Using Table Annotation to Control Result Caching 17-22 fe r a
Using the DBMS_RESULT_CACHE Package 17-23 ans
n - t r
Viewing SQL Result Cache Dictionary Information 17-24
SQL Query Result Cache: Considerations 17-25 a no
h a s ฺ
Quiz 17-27
OCI Client Query Cache 17-28 ฺ a r) uide
Using Client-Side Query Cache 17-29 ฺ c om ent G
PL/SQL Function Cache 17-30 a on tud
l l e@ is S
i
ฺz se th
Using PL/SQL Function Cache 17-31
l o
rce to u
PL/SQL Function Cache: Considerations 17-32
a
PL/SQL and Java Native Compilation Enhancements 17-33
(m ense
l e
Setting Up and Testing PL/SQL Native Compilation 17-34
i l
oZ lic
Recompiling the Entire Database for PL/SQL Native Compilation
l 17-35
e
Marc 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 ble
fe r a
Using RMAN to Create Archival Backups 18-25
ans
Managing Archival Database Backups 18-26
n - t r
o
an
Creating Archival Backups 18-27
Easier Recovery from Loss of Server Parameter File 18-28s
ha deฺ
TSPITR Enhancements and Modifications 18-29 r )
ฺa Gui
m
Identifying Relationships that Span Recovery Set Boundaries 18-30
co ent
n ฺ
Using Image Copies for Faster TSPITR Performance 18-31
Quiz 18-32 @ ao Stud
z i
Managing Recovery Catalogs 18-33l le this
c e loฺ use
The IMPORT CATALOG Command 18-35
a r to
m e
Creating and Using Virtual Private Catalogs 18-37
i l l e ( icens
Using RMAN Virtual Private Catalogs 18-38
e loZ
Quiz 18-40
l
Marc 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 ble
Quiz 19-29 fe r a
Flashback Database Enhancements 19-30 ans
n - t r
Using LogMiner 19-31 o
Review: Data Pump Export and Import 19-32
s an
Migration with Data Pump Legacy Mode 19-33
r ) ha deฺ
Data Pump Legacy Mode 19-34 m ฺa Gui
Managing File Locations 19-36 n ฺ co ent
Quiz 19-37
@ ao Stud
Summary 19-38
z i l le this
c e loฺ use
Practice 19: Overview Using Flashback Technology 19-39
a r to
m e
i l l
20 Data Recovery e ( Advisor
c e ns
o Z 20-2li
Objectives
l
rceRepairing Data Failures 20-3
Ma 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 ble
Using REMOVE_JOB_EMAIL_NOTIFICATION B-11 fe r a
ans
Email Notification: New Dictionary Views B-12
n - t r
Scheduler File Watcher: Overview B-13
a no
Creating a File Watcher and an Event-Based Job B-14
h a s ฺ
Step 1: Creating a Scheduler Credential Object B-15
ฺ a r) uide
Step 2: Creating a File Watcher B-16
ฺ c om ent G
on tud
Using DBMS_SCHEDULER.CREATE_FILE_WATCHER B-17
a
l l e@ is S
Step 3: Creating a Scheduler Program Object B-18
i
ฺz se th
Using the SCHEDULER_FILEWATCHER_RESULT Object Type B-20
l o
a rce to u
Using the SCHEDULER_FILEWATCHER_REQUEST Object Type B-21
l e n se Job that References the File Watcher B-22

(man eEvent-Based
Step 4: Creating
Z l
Step 5: iEnabling ithe
l c Objects B-23
l o
Enabling File Arrival Events from Remote Systems B-24
rce
Ma 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 ble
fe r a
Oracle Database Backup in the Cloud C-3 s
Introducing Oracle Secure Backup Cloud Module C-4
- t r an
Advantages of Backing Up to the Cloud C-5 o n
What Is Amazon Simple Storage Service (S3)? C-6 s an
r
Installing the Oracle Secure Backup Cloud Module C-7) ha deฺ
Summary C-8 m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
Marc
xx
Diagnosability Enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
r c e o u© Oracle. All rights reserved.
a t
l e (m ense
i l lic
el oZ
Marc
Objectives
After completing this lesson, you should be able to:

• Set up Automatic Diagnostic Repository (ADR)
• Use Support Workbench
• Run health checks
• Use SQL Repair Advisor
• Use SQL Test Case Builder ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Oracle Database 11g: New Features for Administrators 14 - 2

Oracle Database 11g Fault Management
Goal: Reduce Time to Resolution
Change assurance
and Automatic Proactive
Intelligent
Diagnostic patching
automatic health resolution
checks
Workflow
ble
fe r a
t r a ns
Diagnostic Solution
o n- Delivery
s an
Prevention Resolution
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
Zi 11glicFault Management
Oracle Database
l o
e of the fault diagnosability infrastructure are the following:
The
a rcgoals
M • Detecting problems proactively
• Limiting damage and interruptions after a problem is detected
• Reducing problem diagnostic time
• Reducing problem resolution time
• Simplifying customer interaction with Oracle Support

Ease Diagnosis: Automatic Diagnostic Workflow
Automatic
Critical Diagnostic
Error Repository
DBA
Alert DBA
Auto incident creation
1 2 Targeted health checks
First failure capture Assisted SR filling
ble
fe r a
No Known
ans
DBA -
bug?
n t r
a no
h a s ฺ Yes
EM Support Workbench:
ฺ a r) uide
4 Package incident info EM Support m nt G
coWorkbench:
Data Repair ฺ
Applynpatch/Data
o derepair 3
@ a S t u DBA
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Ease Diagnosis:
l
Zi Automaticlic Diagnostic Workflow
e l o
An
a rcalways-on, in-memory tracing facility enables database components to capture diagnostic
Mdata upon first failure for critical errors. A special repository, called Automatic Diagnostic
Repository, is automatically maintained to hold diagnostic information about critical error
events. This information can be used to create incident packages to be sent to Oracle Support
Services for investigation.
Here is a possible workflow for a diagnostic session:
1. Incident causes an alert to be raised in Enterprise Manager.
2. The DBA can view the alert via the Enterprise Manager Alert page.
3. The DBA can drill down to incident and problem details.
4. DBA or Oracle Support Services can decide or ask for that information to be packaged
and sent to Oracle Support Services via My Oracle Support. The DBA can add files to the
data to be packaged automatically.

Automatic Diagnostic Repository
DIAGNOSTIC_DEST
Support Workbench
$ORACLE_BASE BACKGROUND_DUMP_DEST
CORE_DUMP_DEST
USER_DUMP_DEST
$ORACLE_HOME/log
ADR
Base
diag
rdbms
DB
ble
Name
fe r a
ADR metadata
ans
Home
SID
n - t r
a no
alert cdump incpkg incident hm trace
h s ฺ
(others)
a
incdir_1 … incdir_n ฺ a r) uide
ADRCI ฺ c om ent G
log.xml
a on tud alert_SID.log
V$DIAG_INFO
l l e@ is S
i
ฺz se th
l o
a rce Copyright
t o u© 2009, Oracle. All rights reserved.
l e (m ense
Automatic Z i l
Diagnostic lic Repository (ADR)
l o
ADR
a rceis a file-based repository for database diagnostic data such as traces, incident dumps and
M packages, the alert log, Health Monitor reports, core dumps, and more. It has a unified
directory structure across multiple instances and multiple products stored outside of any
database. It is, therefore, available for problem diagnosis when the database is down.
Beginning with Oracle Database 11g Release 1, the database server, Automatic Storage
Management (ASM), Cluster Ready Services (CRS), and other Oracle products or components
store all diagnostic data in ADR. Each instance of each product stores diagnostic data
underneath its own ADR home directory. For example, in a Real Application Clusters
environment with shared storage and ASM, each database instance and each ASM instance has
a home directory within ADR. ADR’s unified directory structure uses consistent diagnostic
data formats across products and instances. A unified set of tools enable customers and Oracle
Support to correlate and analyze diagnostic data across multiple instances.

Automatic Diagnostic Repository (ADR) (continued)
Within the ADR base, there can be multiple ADR homes, where each ADR home is the root
directory for all diagnostic data for a particular instance of a particular Oracle product or
component. The location of an ADR home for a database is shown in the graphic given in the
preceding slide.
Also, two alert files are now generated. One is textual, exactly like the alert file used with
previous releases of the Oracle database and is located under the trace directory of each
ADR home. In addition, an alert message file conforming to the XML standard is stored in the
alert subdirectory inside the ADR home. You can view the alert log in text format (with the
XML tags stripped) with Enterprise Manager and with the ADR Command Interpreter
(ADRCI) utility.
The graphic in the slide shows you the directory structure of an ADR home. The incident
directory contains multiple subdirectories, where each subdirectory is named for a particularle
incident, and where each contains dumps pertaining only to that incident. r a b
sf e
The hm directory contains the checker run reports generated by the Health Monitor. a n
There is also a metadata directory that contains important files for the o n -tr itself. You
repository
a n using ADRCI.
can compare this to a database dictionary. This dictionary can besqueried
In addition, you can use V$DIAG_INFO to list some important r ) haADR d e ฺ
locations.
aฺ u i
o m t G
o n ฺc den
@ a Stu
z i l l e t h is
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

ADRCI: The ADR Command-Line Tool
• Allows interaction with ADR from OS prompt

• Can invoke Incident Package Service (IPS) with
command line instead of Enterprise Manager
• Advantages of using the Enterprise Manager Support
Workbench:
– Leverages same toolkit/libraries that ADRCI is built upon le
r a b
– Easy to follow GUI sfe n
ADRCI> show incident
n - tra
o
an
ADR Home = /u01/app/oracle/product/11.1.0/db_1/log/diag/rdbms/orcl/orcl:
*****************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME s
ha deฺ
r
ฺa Gui)
------------ -------------------------------------- ---------------------------------
1681 ORA-600_dbgris01:1,_addr=0xa9876541
m
17-JAN-07 09.17.44.843125000…
co ent
1682 ORA-600_dbgris01:12,_addr=0xa9876542
n ฺ
18-JAN-07 09.18.59.434775000…
2 incident info records fetched
ADRCI>
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
ADRCI: The
l
i Command-Line
ZADR lic Tool
l o
rce is a command-line tool that is part of the fault diagnosability infrastructure introduced
ADRCI
a
Min Oracle Database Release 11g. ADRCI enables you to:
• View diagnostic data within Automatic Diagnostic Repository (ADR).
• Package incident and problem information into a zip file for transmission to Oracle
Support. This is done using a service called Incident Package Service (IPS).
ADRCI has a rich command set, and can be used in interactive mode or within scripts. In
addition, ADRCI can execute scripts of ADRCI commands in the same way that SQL*Plus
executes scripts of SQL and PL/SQL commands.
There is no need to log in to ADRCI, because the data in ADR is not intended to be secure.
ADR data is secured only by operating system permissions on the ADR directories.
The easiest way to package and otherwise manage diagnostic data is with the Support
Workbench of Oracle Enterprise Manager. ADRCI provides a command-line alternative to
most of the functionality of Support Workbench, and adds capabilities such as listing and
querying trace files.
The slide example shows you an ADRCI session listing all open incidents stored in ADR.
Note: For more information about ADRCI, refer to the Oracle Database Utilities guide.

V$DIAG_INFO
SQL> SELECT * FROM V$DIAG_INFO;
NAME VALUE
------------------- ---------------------------------------------------------------
Diag Enabled TRUE
ADR Base /u01/app/oracle
ADR Home /u01/app/oracle/diag/rdbms/orcl/orcl
Diag Trace /u01/app/oracle/diag/rdbms/orcl/orcl/trace
Diag Alert /u01/app/oracle/diag/rdbms/orcl/orcl/alert
ble
Diag Incident
Diag Cdump
/u01/app/oracle/diag/rdbms/orcl/orcl/incident
/u01/app/oracle/diag/rdbms/orcl/orcl/cdump
fe r a
Health Monitor /u01/app/oracle/diag/rdbms/orcl/orcl/hm
ans
Default Trace File /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_11424.trc
n - t r
Active Problem Count 3
o
Active Incident Count 8
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
V$DIAG_INFO Zi l lic
e l o
The
a rcV$DIAG_INFO view lists all important ADR locations including:
M • ADR Base: Path of ADR base
• ADR Home: Path of ADR home for the current database instance
• Diag Trace: Location of the text alert log and background/foreground process trace files
• Diag Alert: Location of an XML version of the alert log
• Default Trace File: Path to the trace file for your session. SQL Trace files are written
here.

Location for Diagnostic Traces
Diagnostic Data Previous Location ADR Location

Foreground process USER_DUMP_DEST $ADR_HOME/trace

traces
Background process BACKGROUND_DUMP_DEST $ADR_HOME/trace

traces
Alert log data BACKGROUND_DUMP_DEST $ADR_HOME/alert&trace
ble
Core dumps CORE_DUMP_DEST $ADR_HOME/cdump
fe r a
ans
Incident dumps USER|BACKGROUND_DUMP_DEST
n - t r
$ADR_HOME/incident/incdir_n
a no
h a s ฺ
ฺ a r) uide
ADR trace = Oracle Database ฺ c om e n
10g trace t –G critical error trace
n
ao Stud
l @
le this
ฺ z i
e loCopyright u e
s2009,
a r c t o © Oracle. All rights reserved.
l e (m ense
Locationofor
l
ZiDiagnostic
lic Traces
l
e shown in the slide describes the different classes of trace data and dumps that reside
The
a rctable
M both in Oracle Database 10g and in Oracle Database 11g.
With Oracle Database 11g, there is no distinction between foreground and background trace
files. Both types of files go into the $ADR_HOME/trace directory.
All nonincident traces are stored inside the trace subdirectory. This is the main difference
compared with previous releases where critical error information is dumped into the
corresponding process trace files instead of incident dumps. Incident dumps are placed in files
separated from the normal process trace files starting with Oracle Database 11g.
Note: The main difference between a trace and a dump is that a trace is more of a continuous
output such as when SQL tracing is turned on, and a dump is a one-time output in response to
an event such as an incident. Also, a core dump is a binary memory dump that is port specific.
In the slide, $ADR_HOME is used to denote the ADR home directory. However, there is no
official environment variable called ADR_HOME.

Viewing the Alert Log Using Enterprise Manager
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o
l
i Log
theZAlert lic Using Enterprise Manager
l
e view the alert log with a text editor, with Enterprise Manager, or with the ADRCI
You
a rccan
M utility. To view the alert log with Enterprise Manager:
1. Access the Database Home page in Enterprise Manager.
2. Under Related Links, click Alert Log Contents.
The View Alert Log Contents page appears.
3. Select the number of entries to view, and then click Go.

Viewing the Alert Log Using ADRCI
adrci> set homepath diag/rdbms/orcl/orcl

adrci> show alert –tail
ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:

*************************************************************************
2007-04-16 22:10:50.756000 -07:00
ORA-1654: unable to extend index SYS.I_H_OBJ#_COL# by 128 in tablespace
SYSTEM
2007-04-16 22:21:20.920000 -07:00
Thread 1 advanced to log sequence 400
Current log# 3 seq# 400 mem# 0: +DATA/orcl/onlinelog/group_3.266.618805031
…
ble
Thread 1 advanced to log sequence 401
fe r a
ans
-
n t r
DIA-48223: Interrupt Requested - Fetch Aborted - Return Code [1]
a no
adrci> SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%'"
h a s ฺ
ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl: ฺar
)
u ide
c om ent G
*************************************************************************
ฺ
adrci>
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o
l
i Log
theZAlert lic Using ADRCI
l
e also use ADRCI to view the contents of your alert log file. Optionally, you can
You
a rccan
Mchange the current ADR home. Use the SHOW HOMES command to list all ADR homes, and
the SET HOMEPATH command to change the current ADRCI homepath.
If the ADRCI homepath is not set, some commands such as SHOW ALERT will prompt you for
the ADR home. Other commands such as SHOW ALERT -tail or SHOW ALERT -tail -f
will fail if the ADRCI homepath is not set.
Ensure that operating system environment variables such as ORACLE_HOME are set properly,
and then enter the following command at the operating system command prompt: adrci.
The utility starts and displays its prompt as shown in the slide.
To see the contents of the alert log, use the SHOW ALERT command to display the alert log in
the default editor. Use the -TAIL num option to display the last num entries in the alert log. If
you omit num, the last ten entries are displayed.
If you want to perform live monitoring of the alert log, use SHOW ALERT -TAIL -F. This
displays the last ten records of the alert log and waits for more messages to arrive. As each
message arrives, it is appended to the display. Press Ctrl + C to break out of this command and
return to the ADRCI prompt.

Viewing the Alert Log Using ADRCI (continued)
You can also filter the output of the SHOW ALERT command as shown in the bottom example
in the slide, where you want to display only those alert log messages that contain the string
ORA-600.
Note: ADRCI allows you to spool the output to a file exactly like in SQL*Plus.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e l oZ l
M arc

Quiz
The Automatic Diagnostic Repository is maintained

automatically and contains diagnostic information about
critical error events.
1. True
2. False
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer:o 1 Zi
l lic
l
a rce
M

Problems and Incidents
Problem ID
Critical
Problem
Error
Problem
Aut Key Incident Status
o ma
tica Collecting
Flood lly
control Automatic
Ready
Incident transition
Tracking
l ly Incident ID
nua Data-Purged
Ma
DBA Closed
ble
fe r a
Traces
ans
-
ADR
MMON Auto-purge
n t r
a no
h a s ฺ
Non-critical
Error ฺ a r) uide
Package to be
ฺ c om ent G
sent to
Oracle Support a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Problems and
l
Zi Incidents
lic
l o
To
a ce diagnosis and resolution of critical errors, the fault diagnosability infrastructure
rfacilitate
M introduces two concepts for the Oracle database: problems and incidents.
• A problem is a critical error in the database. Problems are tracked in ADR. Each problem
is identified by a unique problem ID and has a problem key, which is a set of attributes
that describe the problem. The problem key includes the ORA error number, error
parameter values, and other information. Here is a possible list of critical errors:
- All internal Errors – ORA-60x errors
- All system access violations – (SEGV, SIGBUS)
- ORA-4020 (Deadlock on library object), ORA-8103 (Object no longer exists),
ORA-1410 (Invalid ROWID), ORA-1578 (Data block corrupted), ORA-29740
(Node eviction), ORA-255 (Database is not mounted), ORA-376 (File cannot be
read at this time), ORA-4030 (Out of process memory), ORA-4031 (Unable to
allocate more bytes of shared memory), ORA-355 (The change numbers are out of
order), ORA-356 (Inconsistent lengths in change description), ORA-353 (Log
corruption), ORA-7445 (Operating System exception)
• An incident is a single occurrence of a problem. When a problem occurs multiple times,
as is often the case, an incident is created for each occurrence. Incidents are tracked in
ADR. Each incident is identified by a numeric incident ID, which is unique within an
ADR home.
Problems and Incidents (continued)
When an incident occurs, the database server makes an entry in the alert log, gathers
diagnostic data about the incident (a stack trace, the process state dump, and other dumps of
important data structures), tags the diagnostic data with the incident ID, and stores the data in
an ADR subdirectory created for that incident. Each incident has a problem key and is mapped
to a single problem. Two incidents are considered to have the same root cause if their problem
keys match. Large amounts of diagnostic information can be created very quickly if a large
number of sessions stumble across the same critical error. Having the diagnostic information
for more than a small number of the incidents is not required. That is why ADR provides flood
control so that only a certain number of incidents under the same problem can be dumped in a
given time interval. Note that flood-controlled incidents still generate incidents; they only skip
the dump actions. By default, only five dumps per hour for a given problem are allowed.
You can view a problem as a set of incidents that are perceived to have the same symptoms.
The main reason to introduce this concept is to make it easier for users to manage errors a onbl
e
their systems. For example, a symptom that occurs 20 times should be reported to Oracle s f er only
once. Mostly, you will manage problems instead of incidents, using IPS to package - t r an a problem
to be sent to Oracle Support. Most commonly incidents are automatically n n
ocreated when a
critical error occurred. However, you are also allowed to createaan a
s incident manually, via the
h ฺ
GUI provided by the Enterprise Manager Support Workbench.
ฺ a u ide incident creation is
r) Manual
mostly done when you want to report problems that
ฺ c om n t G
are not accompanied by critical errors
raised inside the Oracle code.
a on tude
As time goes by, more and more incidents
l l e@ willisbeSaccumulated in ADR. A retention policy
allows you to specify how long
i
ฺtoz keepsthe h
tdiagnostic data. ADR incidents are controlled by
e l o u e
two different policies:ar c to
m
• The incident metadata s e
( enretention policy controls how long the metadata is kept around.
i l l e c
l o Z has alidefault setting of one year.
This policy
e incident files and dumps retention policy controls how long generated dump files are
• cThe
r kept
M a around. This policy has a default setting of one month.
You can change these settings by using the Incident Package Configuration link on the
Enterprise Manager Support Workbench page. Inside the RDBMS component, MMON is
responsible for purging automatically expired ADR data.

Problems and Incidents (continued)
The status of an incident reflects the state of the incident. An incident can be in any one of the
following states:
• Collecting: The incident has been newly created and is in the process of collecting
diagnostic information. In this state, the incident data can be incomplete and should not be
packaged, and should be viewed with discretion.
• Ready: The data collection phase has completed. The incident is now ready to be used for
analysis, or to be packaged to be sent to Oracle Support.
• Tracking: The DBA is working on the incident, and prefers the incident to be kept in the
repository indefinitely. You have to manually change the incident status to this value.
• Closed: The incident is now in a done state. In this state, ADR can elect the incident to be
purged after it passes its retention policy.
• Data-Purged: The associated files have been removed from the incident. In some cases,
even if the incident files may still be physically around, it is not advisable for users to ble
era
look at them because they can be in an inconsistent state. Note that the incidentsfmetadata
itself for the incident is still valid for viewing.
- t r an
You can view an incident status by using either ADRCI (show incident n on -mode
a
detail), or directly in Support Workbench.
h as ฺ e twice its retention
If an incident has been in either the Collecting or the Ready ฺ a r) stateufor
idover
length, the incident automatically moves to the Closed
ฺ c om state.
n t G can manually purge incident
You
files. a on tude
l e S
@ ismaintained
For simplicity, problem metadata is
ฺ z i l internally
t h by ADR. Problems are
automatically created whenethe e
lo first uincident
s (of the problem key) occurs. The Problem
metadata is removed after r c
a its last o
t incident is removed from the repository.
( m n s e
e
Note: It is notillpossible edisable
to automatic incident creation for critical errors.
l o Z lic
rce
Ma

Incident Packaging Service (IPS)
• Uses rules to correlate all relevant dumps and traces

from ADR for a given problem and allow you to
package them to ship to Oracle Support
• Rules can involve files that were generated around the
same time, and associated with the same client, same
error codes, and so on.
a b le
• DBAs can explicitly add/edit or remove files before fer
packaging. t r a ns
o n -
a n or
• Access IPS through either Enterprise Manager
s
ADRCI. ha ฺ r) uide
ฺ a
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Incident o Zi l
Packaging ic
lService
l
rcethe Incident Packaging Service (IPS), you can automatically and easily gather all
With
a
M diagnostic data (traces, dumps, health check reports, SQL test cases, and more) pertaining to a
critical error and package the data into a zip file suitable for transmission to Oracle Support.
Because all diagnostic data relating to a critical error are tagged with that error’s incident
number, you do not have to search through trace files, dump files, and so on to determine the
files that are required for analysis; the Incident Packaging Service identifies all required files
automatically and adds them to the package.

Incident Packages
ORA600HAH_20070818131159_COM_1.zip
• An incident package is a logical

structure inside ADR representing ADR
one or more problems. Base
• A package is a zip file containing diag
dump information related to an rdbms
incident package. DB
a b le
• By default, only the first and last er
Name
s f
three incidents of each
ADR
Home
SID
- t r an metadata
problem are included to n on

alert cdump incpkg a
an incident package. a s
h deฺ
incident hm trace (others)
r )
• You can generate complete mฺapkg_1 …ui pkg_n
G
or incremental zip files. nฺco ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Incident o Zi l
Packages lic
l
ce diagnostic data to Oracle Support Services, you first collect the data in an incident
To
a rupload
M package. When you create an incident package, you select one or more problems to add to the
incident package. The Support Workbench then automatically adds to the incident package the
incident information, trace files, and dump files associated with the selected problems.
Because a problem can have many incidents (many occurrences of the same problem), by
default only the first three and last three incidents for each problem are added to the incident
package. You can change this default number on the Incident Packaging Configuration page
accessible from the Support Workbench page.
After the incident package is created, you can add any type of external file to the incident
package, remove selected files from the incident package, or edit selected files in the incident
package to remove sensitive data. An incident package is a logical construct only, until you
create a physical file from the incident package contents. That is, an incident package starts
out as a collection of metadata in ADR. As you add and remove incident package contents,
only the metadata is modified. When you are ready to upload the data to Oracle Support
Services, you invoke either a Support Workbench or an ADRCI function that gathers all the
files referenced by the metadata, places them into a zip file, and then uploads the zip to My
Oracle Support.

Incident Packages (continued)
Note: ADRCI generates packages in your current directory by default. Enterprise Manager
Support Workbench generates them in the
/u01/app/oracle/product/11.1.0/db_1/<hostname_dbname>/
sysman/emd/state directory by default.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e l oZ l
M arc

Enterprise Manager Support Workbench:
Overview
• Wizard that guides you through the process of

handling problems
• You can perform the following tasks with the Support
Workbench:
– View details on problems and incidents.
– Run health checks. le
a b
– Generate additional diagnostic data.
s f er
– Run advisors to help resolve problems. - t r an
n
noOracle
– Create and track service requests throughaMy
Support. h a s ฺ
– Generate incident packages. mฺa
r) uide
ฺ c o ent G
on
– Close problems when resolved. d a Stu
l l e@ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Enterprise i l
ZManager c
liSupport Workbench: Overview
e l o
The
a rcSupport Workbench is an Enterprise Manager wizard that helps you through the process
M of handling critical errors. It displays incident notifications, presents incident details, and
enables you to select incidents for further processing. Further processing includes running
additional health checks, invoking the IPS to package all diagnostic data about the incidents,
adding SQL test cases and selected user files to the package, filing a service request (SR) with
Oracle Support, shipping the packaged incident information to Oracle Support, and tracking
the SR through its life cycle.
You can perform the following tasks with the Support Workbench:
• View details on problems and incidents.
• Manually run health checks to gather additional diagnostic data for a problem.
• Generate additional dumps and SQL test cases to add to the diagnostic data for a problem.
• Run advisors to help resolve problems.
• Create and track a service request through My Oracle Support, and add the service request
number to the problem data.
• Collect all diagnostic data relating to one or more problems into an incident package and
then upload the incident package to Oracle Support Services.
• Close the problem when the problem is resolved.

Enterprise Manager Support Workbench
Roadmap
View critical
1 error alerts in
Enterprise Manager.
7 Close incidents. View problem

2 details.
ble
6 Track the SR and 3
Gather additional
diagnostic
fe r a
implement repairs.
information.
an s
n - t r
a no
4 h a s ฺ
Package and upload
diagnostic data ฺ a r) request.
Create a
u ide
to Oracle Support.
ฺ c om ent Gservice
5 a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Enterprise i l
ZManager c
liSupport Workbench Roadmap
l o
e gives a summary of the tasks that you complete to investigate, report, and in some
The
a rcgraphic
M cases, resolve a problem using Enterprise Manager Support Workbench:
1. Start by accessing the Database Home page in Enterprise Manager and reviewing critical
error alerts. Select an alert for which to view details.
2. Examine the problem details and view a list of all incidents that were recorded for the
problem. Display findings from any health checks that were automatically run.
3. Optionally, run additional health checks and invoke the SQL Test Case Builder, which
gathers all required data related to a SQL problem and packages the information in a way
that enables the problem to be reproduced by Oracle Support. The type of information that
the SQL Test Case Builder gathers includes query being executed, table and index
definitions (but no data), optimizer statistics, and initialization parameter settings.
4. Create a service request with My Oracle Support and optionally record the service request
number with the problem information.
5. Invoke a wizard that automatically packages all gathered diagnostic data for a problem
and uploads the data to Oracle Support. Optionally, edit the data to remove sensitive
information before uploading.
6. Optionally, maintain an activity log for the service request in the Support Workbench.
Run Oracle advisors to help repair SQL failures or corrupted data.
7. Set status for one, some, or all incidents for the problem to Closed.
View Critical Error Alerts in Enterprise Manager
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
View Critical
l
ZiError Alerts
lic in Enterprise Manager
l o
e the process of investigating problems (critical errors) by reviewing critical error
You
a rcbegin
Malerts on the Database Home page. To view critical error alerts, access the Database Home
page in Enterprise Manager. From the Home page, you can look at the Diagnostic Summary
section from where you can click the Active Incidents link if there are incidents. You can also
use the Alerts section and look for critical alerts flagged as Incidents.
When you click the Active Incidents link, you access the Support Workbench page on which
you can retrieve details about all problems and corresponding incidents. From there, you can
also retrieve all Health Monitor checker run and created packages.

Package and Upload Diagnostic Data to
Oracle Support
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Packageoand
l
Zi UploadlicDiagnostic Data to Oracle Support
e l
The
a rcSupport Workbench provides two methods for creating and uploading an incident
M package: the Quick Packaging method and the Custom Packaging method. The example in the
slide shows you how to use Quick Packaging.
Quick Packaging is a more automated method with a minimum of steps. You select a single
problem, provide an incident package name and description, and then schedule the incident
package upload, either immediately or at a specified date and time. The Support Workbench
automatically places diagnostic data related to the problem into the incident package, finalizes
the incident package, creates the zip file, and then uploads the file. With this method, you do
not have the opportunity to add, edit, or remove incident package files or add other diagnostic
data such as SQL test cases. To package and upload diagnostic data to Oracle Support:
1. On the Problem Details page, in the Investigate and Resolve section, click Quick Package.
The Create New Package page of the Quick Packaging wizard appears.
2. Enter a package name and description.
3. Enter the service request number to identify your problem.
4. Click Next, and then proceed with the remaining pages of the Quick Packaging wizard.
Click Submit on the Review page to upload the package.

Track the SR and Implement Repairs
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Track theoSR
l
Zi and Implement
lic Repairs
l
rceuploading diagnostic information to Oracle Support, you may perform various activities
After
a
Mto track the service request and implement repairs. Among these activities are the following:
Add an Oracle bug number to the problem information. To do so, on the Problem Details page,
click the Edit button that is adjacent to the Bug# label. This is for your reference only.
Add comments to the problem activity log. To do so, complete the following steps:
1. Access the Problem Details page for the problem.
2. Click Activity Log to display the Activity Log subpage.
3. In the Comment field, enter a comment, and then click Add Comment. Your comment is
recorded in the activity log.
Respond to a request by Oracle Support to provide additional diagnostics. Your Oracle
Support representative may provide instructions for gathering and uploading additional
diagnostics.

Creating User-Reported Problems
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
CreatingoUser-Reportedlic Problems
l
rce errors generated internally to the database are automatically added to Automatic
Critical
a
M Diagnostic Repository (ADR) and tracked in the Support Workbench. However, there may be
a situation in which you want to manually add a problem that you noticed to the ADR so that
you can put that problem through the Support Workbench workflow. An example of such a
situation would be if the performance of the database or of a particular query suddenly
noticeably degraded. The Support Workbench includes a mechanism for you to create and
work with such a user-reported problem.
To create a user-reported problem, open the Support Workbench page and click the Create
User-Reported Problem link in the Related Links section. This takes you to the Create User-
Reported Problem page from where you are asked to run a corresponding advisor before
continuing. This is necessary only if you are not sure about your problem. However, if you
already know exactly what is going on, select the issue that describes most the type of problem
you are encountering and click “Continue with Creation of Problem.”
By clicking this button, you basically create a pseudo-problem inside the Support Workbench.
This allows you to manipulate this problem using the previously seen Support Workbench
workflow for handling critical errors. So, you end up on a Problem Details page for your issue.
Note that at first the problem does not have any diagnostic data associated with it. At this
point, you need to create a package and upload necessary trace files by customizing that
package.
11.2
Enterprise Manager Support Workbench for ASM

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Enterprise i l
ZManager c
liSupport Workbench for ASM
l o
rceEnterprise Manager has been enhanced to help diagnose and package incidents to
Oracle
a
M Oracle Support Services for Oracle ASM instances.
Oracle Enterprise Manager provides Oracle ASM Support Workbench to monitor Oracle ASM
alerts and incidents.
To access Support Workbench for Oracle ASM:
1. Click the Software and Support tab on the database home page.
2. Click Support Workbench in the Support section of the Software and Support page.
3. Click Support Workbench (ASM_instance_name) under the Related Links section on the
Support Workbench page.
You can view information about current and past problems on the Problems page.
To create a package to send to Oracle Support Services, select an incident and click Package
on the Support Workbench Problems page. Support Workbench then guides you through the
packaging process.

Invoking IPS Using ADRCI
IPS SET CONFIGURATION INCIDENT

PROBLEM | PROBLEMKEY
IPS CREATE PACKAGE

SECONDS | TIME
INCIDENT
Ø
NEW INCIDENTS IPS ADD
FILE
IN FILE
IPS COPY
ble
OUT FILE
fe r a
INCIDENT
an s
IPS REMOVE
n - t r
no
FILE
a
s ฺ
IPS FINALIZE PACKAGE h a
ฺ a r) uide
ฺ c om ent G
IPS GENERATE
a onPACKAGE tud
@
le this S
ฺ z i l
e loCopyright u e
s2009,
l e (m ense
Invoking IPS
l
Zi Using lADRCI
ic
l o
rce a package is a two-step process: you first create the logical package, and then
Creating
a
M generate the physical package as a zip file. Both steps can be performed using ADRCI
commands. To create a logical package, the IPS CREATE PACKAGE command is used.
There are several variants of this command that allow you to choose the contents:
• IPS CREATE PACKAGE creates an empty package.
• IPS CREATE PACKAGE PROBLEMKEY creates a package based on problem key.
• IPS CREATE PACKAGE PROBLEM creates a package based on problem ID.
• IPS CREATE PACKAGE INCIDENT creates a package based on incident ID.
• IPS CREATE PACKAGE SECONDS creates a package containing all incidents
generated from seconds ago until now.
• IPS CREATE PACKAGE TIME creates a package based on the specified time range.
It is also possible to add contents to an existing package. For instance:

• IPS ADD INCIDENT PACKAGE adds an incident to an existing package.
• IPS ADD FILE PACKAGE adds a file inside ADR to an existing package.

Invoking IPS Using ADRCI (continued)
IPS COPY copies files between ADR and the external file system. It has two forms:
• IN FILE, to copy an external file into ADR, associating it with an existing package, and
optionally an incident
• OUT FILE, to copy a file from ADR to a location outside ADR.
IPS COPY is essentially used to COPY OUT a file, edit it, and COPY IN it back into ADR.
IPS FINALIZE is used to finalize a package for delivery, which means that other
components, such as the Health Monitor, are called to add their correlated files to the package.
Recent trace files and log files are also included in the package. If required, this step is run
automatically when a package is generated.
To generate the physical file, the IPS GENERATE PACKAGE command is used. The syntax
is:
IPS GENERATE PACKAGE IN [COMLPETE | INCREMENTAL]
a b le
It generates a physical zip file for an existing logical package. The file name containsfe r
either
COM for complete or INC for incremental, followed by a sequence number thatra
s
isnincremented
- t
each time a zip file is generated.
n on
IPS SET CONFIGURATION is used to set IPS rules. s a
) a
h deฺ about ADRCI.
Note: Refer to the Oracle Database Utilities guide for more r
ฺa Gui information
m
co ent
n ฺ
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
l o Z l
a rce
M

Quiz
Which of the following statements are true about the

Incident Packaging Service (IPS)?
1. All diagnostic data relating to a critical error is tagged
with that error’s incident number.
2. You must search through trace files, dump files, and
so on to determine the files that are required for
a b le
analysis and submit them to the IPS. s f er
t r n
aand
3. The IPS identifies all required files automatically -
adds them to the package. n on
s a
4. You can explicitly add/edit or remove ) a
h files e ฺbefore
ฺa r u i d
packaging. om t G ฺc den
o
a Stun
l l e@ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Answers: Z3,
1,
l
i and 4lic
l o
a rce
M

Health Monitor: Overview
V$HM_CHECK DB-offline
Critical
DB Structure Integrity Check
error ADRCI
Data Block Integrity Check V$HM_RUN
Redo Integrity Check DBMS_HM EM
hm
(reports)
Reactive
ADR
Manual Health
ble
EM or DBMS_HM Monitor
fe r a
ans
V$HM_CHECK
DB-online
n - t r
DBA
no
Transaction Integrity Check
a
h a s ฺ
Undo Segment Integrity Check
Dictionary Integrity Check
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Overview
Health Monitor: lic
l o
rce with Release 11g, the Oracle database server includes a framework called Health
Beginning
a
MMonitor for running diagnostic checks on various components of the database.
Health Monitor checkers examine various components of the database, including files,
memory, transaction integrity, metadata, and process usage. These checkers generate reports of
their findings as well as recommendations for resolving problems. Health Monitor checks can
be run in two ways:
• Reactive: The fault diagnosability infrastructure can run Health Monitor checks
automatically in response to critical errors.
• Manual: As a DBA, you can manually run Health Monitor checks by using either the
DBMS_HM PL/SQL package or the Enterprise Manager interface.
In the slide, you can see some of the checks that Health Monitor can run. For a complete
description of all possible checks, look at V$HM_CHECK. These health checks fall into one of
two categories:
• DB-online: These checks can be run while the database is open (that is, in OPEN mode or
MOUNT mode).
• DB-offline: In addition to being “runnable” while the database is open, these checks can
also be run when the instance is available and the database itself is closed (that is, in
NOMOUNT mode).
Health Monitor: Overview (continued)
After a checker has run, it generates a report of its execution. This report contains information
about the checker’s findings, including the priorities (low, high, or critical) of the findings,
descriptions of the findings and their consequences, and basic statistics about the execution.
Health Monitor generates reports in XML and stores the reports in ADR. You can view these
reports by using V$HM_RUN, DBMS_HM, ADRCI, or Enterprise Manager.
Note: There are around 20 checks that can be run:

SQL> select name,offline_capable,description,internal_check from
v$hm_check;
NAME O DESCRIPTION I
--------------------- - ------------------------------------------- -
HM Test Check Y Check for health monitor functionality Y
DB Structure Integrity Check Y Checks integrity of all database files N
Y Checks integrity of a control file block ab N
le
er N
CF Block Integrity Check
s f
Data Block Integrity Check Y Checks integrity of a data file block
- t r an
Redo Integrity Check Y Checks integrity of redo log content
o n N
N Checks logical content of na block
Logical Block Check
s a Y
Transaction Integrity Check N Checks a transaction
r ) ha fordecorruptions
ฺ N
Undo Segment Integrity Check N Checks integrity
m ฺa ofGanui undo segment N
No Mount CF Check
ฺ co efile
Y Checks control
n n t in NOMOUNT mode Y
Mount CF Check ao control
Y Checks
@ S tud file in mount mode Y
CF Member Check
z i l lYe Checks
t h isa multiplexed copy of the control Y
All Datafiles Check
c e loฺ YusChecks e all datafiles in the database Y
a
Single Datafile Check r o
t Y Checks a data file Y
( m s e
Z i lle lCheck
Tablespace Check
i c en Y Checks a tablespace Y
e l o Check
Log Group Y Checks all members of a log group Y
arcGroup Member Check

Log
MArchived
Y Checks a particular member of a log group Y
Log Check Y Checks an archived log Y
Redo Revalidation Check Y Checks redo log content Y
IO Revalidation Check Y Checks file accessibility Y
Block IO Revalidation Check Y Checks file accessibility Y
Txn Revalidation Check N Revalidate corrupted transaction Y
Failure Simulation Check Y Creates dummy failures Y
Dictionary Integrity Check N Checks dictionary integrity N
ASM Mount Check Y Diagnose mount failure Y
ASM Allocation Check Y Diagnose allocation failure N
ASM Disk Visibility Check Y Diagnose add disk failure Y
ASM File Busy Check Y Diagnose file drop failure Y
27 rows selected.
SQL>

Running Health Checks Manually:
Enterprise Manager Example
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
RunningoHealth
l
Zi Checks lic Manually: Enterprise Manager Example
l
rce Manager provides an interface for running Health Monitor checkers. You can find
Enterprise
a
M this interface in the Checkers tab on the Advisor Central page. The page lists each checker
type, and you can run a checker by clicking it and then OK on the corresponding checker page
after you have entered the parameters for the run. The slide shows how you can run the Data
Block Checker manually.
After a check is completed, you can view the corresponding checker run details by selecting
the checker run from the Results table and clicking Details. Checker runs can be reactive or
manual.
On the Findings subpage you can see the various findings and corresponding recommendations
extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION.
If you click View Report on the Runs subpage, you can view the run report in XML format.
Viewing the XML report in Enterprise Manager generates the report for the first time if it is
not yet generated in your ADR. You can then view the report using ADRCI without needing to
generate it.

Running Health Checks Manually:
PL/SQL Example
SQL> exec dbms_hm.run_check('Dictionary Integrity Check',
'DicoCheck',0,'TABLE_NAME=tab$');
SQL> set long 100000

SQL> select dbms_hm.get_run_report('DicoCheck') from dual;
DBMS_HM.GET_RUN_REPORT('DICOCHECK')
--------------------------------------------------------------------------------
Basic Run Information (Run Name,Run Id,Check Name,Mode,Status)
Input Paramters for the Run
TABLE_NAME=tab$
ble
CHECK_MASK=ALL
Run Findings And Recommendations
fe r a
Finding
ans
Finding Name : Dictionary Inconsistency
n - t r
Finding ID
Type
: 22
: FAILURE a no
Status : OPEN
h a s ฺ
Priority : CRITICAL
ฺ a r) uide
om ent G
Message : SQL dictionary health check: invalid column number 8 on
object TAB$ failed
ฺ c
Message
on tud
: Damaged rowid is AAAAACAABAAAS7PAAB - description: Object
a
l l e@ is S
SCOTT.TABJFV is referenced
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Checks
RunningoHealth lic Manually: PL/SQL Example
l
e use the DBMS_HM.RUN_CHECK procedure for running a health check. To call
You
a rccan
M RUN_CHECK, supply the name of the check found in V$HM_CHECK, the name for the run
(this is just a label used to retrieve reports later), and the corresponding set of input parameters
for controlling its execution. You can view these parameters by using V$HM_CHECK_PARAM.
In the example in the slide, you want to run a Dictionary Integrity Check for the TAB$ table.
You call this run DICOCHECK, and you do not want to set any timeout for this check.
After DICOCHECK is executed, you execute the DBMS_HM.GET_RUN_REPORT function to
get the report extracted from V$HM_RUN, V$HM_FINDING, and
V$HM_RECOMMENDATION. The output clearly shows you that a critical error was found in
TAB$. This table contains an entry for a table with an invalid number of columns.
Furthermore, the report gives you the name of the damaged table in TAB$.
When you call the GET_RUN_REPORT function, it generates the XML report file in the HM
directory of your ADR. For this example, the file is called HMREPORT_DicoCheck.hm.
Note: Refer to the Oracle Database PL/SQL Packages and Types Reference for more
information about DBMS_HM.

Viewing HM Reports Using the ADRCI Utility
adrci> show hm_run
…
ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:
*************************************************************************
HM RUN RECORD 1
**********************************************************
RUN_ID 1
RUN_NAME HM_RUN_1
CHECK_NAME DB Structure Integrity Check
NAME_ID 2
MODE 2
START_TIME 2007-07-02 17:31:54.271917 +07:00
RESUME_TIME <NULL>
END_TIME 2007-07-02 17:31:57.579834 +07:00
ble
MODIFIED_TIME 2007-07-02 17:31:57.579834 +07:00
fe r a
TIMEOUT 0
ans
FLAGS
STATUS
0
5
n - t r
SRC_INCIDENT_ID 0
a no
NUM_INCIDENTS
ERR_NUMBER
0
0 h a s ฺ
REPORT_FILE <NULL>
ฺ a r) uide
…
ฺ c om ent G
on tud
adrci> create report hm_run HM_RUN_1
Adrci> show report hm_run HM_RUN_1
… a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Viewing HM i l
ZReports licUsing the ADRCI Utility
l o
e create and view Health Monitor checker reports using the ADRCI utility. To do that,
You
a rccan
M ensure that operating system environment variables such as ORACLE_HOME are set properly,
and then enter the following command at the operating system command prompt: adrci.
The utility starts and displays its prompt as shown in the slide. Optionally, you can change the
current ADR home. Use the SHOW HOMES command to list all ADR homes, and the SET
HOMEPATH command to change the current ADR home.
You can then enter the SHOW HM_RUN command to list all the checker runs registered in
ADR and visible from V$HM_RUN. Locate the checker run for which you want to create a
report and note the checker run name using the corresponding RUN_NAME field. The
REPORT_FILE field contains a file name if a report already exists for this checker run.
Otherwise, you can generate the report using the CREATE REPORT HM_RUN command as
shown in the slide. To view the report, use the SHOW REPORT HM_RUN command.

SQL Repair Advisor: Overview
SQL Generate
statement Execute Statement incident in ADR
crashes
automatically
Trace files
DBA run DBA gets

SQL Repair Advisor
SQL Repair Advisor alerted

DBA
investigates
bl e
DBA accept Statement
fe r
executes
a
SQL patch
ans
successfully
n - t r again
Execute
a no
h a s ฺ
ฺ a r) uide
SQL patch
ฺ c om ent G
generated
a on patched
SQL statement
tud
@
le this S
ฺ z i l
e loCopyright u e
s2009,
l e (m ense
SQL Repair i l
ZAdvisor: licOverview
l o
e the SQL Repair Advisor after a SQL statement fails with a critical error that generates
You
a rcrun
Ma problem in ADR. The advisor analyzes the statement and in many cases recommends a patch
to repair the statement. If you implement the recommendation, the applied SQL patch
circumvents the failure by causing the query optimizer to choose an alternate execution plan
for future executions. This is done without changing the SQL statement itself.
Note: In case no workaround is found by the SQL Repair Advisor, you are still able to
package the incident files and send the corresponding diagnostic data to Oracle Support.

Accessing the SQL Repair Advisor Using
Enterprise Manager
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Accessing Zthel
i SQLlRepair
ic Advisor Using Enterprise Manager
l o
e easily access the SQL Repair Advisor from Enterprise Manager when you get alerted
You
a rccan
M in the Diagnostic Summary section of the database home page. Following a SQL statement
failure that generates an incident in ADR, you are automatically alerted through the Active
Incidents field. You can click the corresponding link to get to the Support Workbench
Problems page from where you can click the corresponding problem ID link. This takes you to
the Problem Details page from where you can click the SQL Repair Advisor link in the
“Investigate and Resolve” section of the page.

Viewing, Disabling, or Removing a SQL Patch
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Viewing,oDisabling, ic Removing a SQL Patch
lor
l
rceyou apply a SQL patch with the SQL Repair Advisor, you may want to view it to
After
a
M confirm its presence, disable it, or remove it. One reason to remove a patch is if you install a
later release of the Oracle database that fixes the problem that caused the failure in the
nonpatched SQL statement.
To view, disable/enable, or remove a SQL Patch, access the Server page in Enterprise
Manager and click the SQL Plan Control link in the Query Optimizer section of the page. This
takes you to the SQL Plan Control page. On this page, click the SQL Patch tab.
From the resulting SQL Patch subpage, locate the desired patch by examining the associated
SQL statement. Select it, and perform the corresponding task: Disable, Enable, or Delete.

Using SQL Repair Advisor from PL/SQL: Example
declare
rep_out clob;
t_id varchar2(50);
begin
t_id := dbms_sqldiag.create_diagnosis_task(
sql_text => 'delete from t t1 where t1.a = ''a'' and rowid <> (select max(rowid)
from t t2 where t1.a= t2.a and t1.b = t2.b and t1.d=t2.d)',
task_name => 'sqldiag_bug_5869490',
problem_type => DBMS_SQLDIAG.PROBLEM_TYPE_COMPILATION_ERROR);
dbms_sqldiag.set_diagnosis_task_parameter(t_id,'_SQLDIAG_FINDING_MODE',
dbms_sqldiag.SQLDIAG_FINDINGS_FILTER_PLANS);
ble
dbms_sqldiag.execute_diagnosis_task (t_id);
fe r a
rep_out := dbms_sqldiag.report_diagnosis_task (t_id, DBMS_SQLDIAG.TYPE_TEXT);
ans
dbms_output.put_line ('Report : ' || rep_out);
n - t r
no
end;
/
a
s ฺ
h a
ฺ a r) uide
execute dbms_sqldiag.accept_sql_patch(task_name => 'sqldiag_bug_5869490',
task_ownerm
ฺ c o => e'SCOTT',
n t G replace => TRUE);
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using the
l
Zi Repair
SQL lic Advisor from PL/SQL: Example
l o
e also invoke the SQL Repair Advisor directly from PL/SQL.
You
a rccan
M After you get alerted about an incident SQL failure, you can execute a SQL Repair Advisor
task by using the DBMS_SQLDIAG.CREATE_DIGNOSIS_TASK function as illustrated in
the slide. You need to specify the SQL statement for which you want the analysis to be done,
as well as a task name and a problem type you want to analyze (possible values are
PROBLEM_TYPE_COMPILATION_ERROR and PROBLEM_TYPE_EXECUTION_ERROR).
You can then give the created task parameters by using the
DBMS_SQLDIAG.SET_DIAGNOSIS_TASK_PARAMETER procedure.
When you are ready, you can execute the task by using the
DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASK procedure.
Finally, you can get the task report by using the
DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASK function.
In the example given in the slide, it is assumed that the report asks you to implement a SQL
Patch to fix the problem. You can then use the DBMS_SQLDIAG.ACCEPT_SQL_PATCH
procedure to implement the SQL Patch.

Using the SQL Test Case Builder
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using the
l
Zi TestliCase
SQL c Builder
l o
e Test Case Builder automates the somewhat difficult and time-consuming process of
rcSQL
The
a
Mgathering as much information as possible about a SQL-related problem and the environment
in which it occurred, so that the problem can be reproduced and tested by Oracle Support
Services. The information gathered by the SQL Test Case Builder includes the query being
executed, table and index definitions (but not the actual data), PL/SQL functions, procedures
and packages, optimizer statistics, and initialization parameter settings.
From the Support Workbench page, to access the SQL Test Case Builder:
1. Click the corresponding Problem ID to open the problem details page.
2. Click the Oracle Support tab.
3. Click “Generate Additional Dumps and Test Cases.”
4. On the “Additional Dumps and Test Cases” page, click the icon in the Go To Task
column to run the SQL Test Case Builder against your particular Incident ID.
The output of the SQL Test Case Builder is a SQL script that contains the commands required
to re-create all the necessary objects and the environment.
Note: You can also invoke the SQL Test Case Builder by using the
DBMS_SQLDIAG.EXPORT_SQL_TESTCASE_DIR_BY_INC function. This function takes
the incident ID as well as a directory object. It generates its output for the corresponding
incident in the specified directory.
Quiz
Which of the following statements are true about the SQL

Repair Advisor?
1. You execute it after a SQL statement fails with a
critical error that generates a problem in ADR.
2. It analyzes the failed SQL statement.
3. It can recommend a patch to repair the statement. a b le
4. It applies the patch automatically. s f er
n a
o n -tr
na
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answers: Z2,
1,
l
i and 3lic
l o
a rce
M

Summary
In this lesson, you should have learned how to:

• Set up Automatic Diagnostic Repository
• Use the Support Workbench
• Run health checks
• Use the SQL Repair Advisor
• Use SQL Test Case Builder ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Practice 14: Overview
This practice covers the following topics:

• Using the Support Workbench
• Using the SQL Repair Advisor
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Real-Time SQL Monitoring
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Describe SQL Monitoring concepts
• Use Enterprise Manager to monitor SQL commands
• View long-running SQL commands
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

SQL Monitoring
STATISTICS_LEVEL=TYPICAL|ALL
+
CONTROL_MANAGEMENT_PACK_ACCESS=DIAGNOSTIC+TUNING
Every
SQL monitoring second V$SQL_MONITOR
V$SQL_PLAN_MONITOR
bl e
fe r a
ns
>5sec MONITOR
(CPU|IO) Parallel
hint
- t r a
o n
DBMS_SQLTUNE.REPORT_SQL_MONITOR
s an
r ) ha deฺManager
Enterprise
V$SQL
V$SQL_PLAN mฺ
a Gui Grid
co ent Control
NO_MONITOR
hint
n ฺ
V$ACTIVE_SESSION_HISTORY
ao
V$SESSION_LONGOPS
@ V$SESSIONS
tud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi
SQL Monitoring
l lic
e l o
a rcreal-time
The SQL monitoring feature on Oracle Database 11g enables you to monitor the
Mperformance of SQL statements while they are executing.
The real-time SQL monitoring feature is enabled by default when the STATISTICS_LEVEL
initialization parameter is either set to ALL or to TYPICAL, which is the default value.
Additionally, the CONTROL_MANAGEMENT_PACK_ACCESS parameter must be set to
DIAGNOSTIC+TUNING (the default value) because real-time SQL monitoring is a feature of
the Oracle Database Tuning Pack.
By default, real-time SQL monitoring is started when a SQL command runs in parallel, or
when it has consumed at least five seconds of the CPU or I/O time in a single execution.
As mentioned, real-time SQL monitoring is active by default. However, two command-level
hints are available to force or prevent a SQL command from being monitored. To force real-
time SQL monitoring, use the MONITOR hint. To prevent the hinted SQL command from
being monitored, use the NO_MONITOR hint.

SQL Monitoring (continued)
You can monitor the statistics for SQL command execution using the V$SQL_MONITOR and
V$SQL_PLAN_MONITOR views.
After monitoring is initiated, an entry is added to the V$SQL_MONITOR dynamic
performance view. This entry tracks key performance metrics collected for the execution,
including the elapsed time, CPU time, number of reads and writes, I/O wait time, and various
other wait times. These statistics are refreshed in near real time as the command executes,
generally once every second.
After the execution ends, monitoring information is not deleted immediately, but is kept in the
V$SQL_MONITOR view for at least one minute. The entry is eventually deleted so its space
can be reclaimed as new commands are monitored.
The V$SQL_MONITOR and V$SQL_PLAN_MONITOR views can be used in conjunction with
the following views to get additional information about the execution that is monitored: ble
f e raand
V$SQL, V$SQL_PLAN, V$ACTIVE_SESSION_HISTORY, V$SESSION_LONGOPS,
V$SESSION t r a ns
n -
o of accessing the
You can use the SQL monitoring report to view SQL monitoring data n
instead
a
views. as
) h deฺ
r
ฺa Gui
m
co ent
n ฺ
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e l oZ l
M arc

11.2
SQL Monitoring in Oracle Database 11g Release 2

ble
... fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
SQL Monitoring
l
Zi in Oracle
lic Database 11g Release 2
l o
In
a ce Database 11g Release 2, you can access the SQL Monitoring feature in Enterprise
rOracle
MManager Database Control by clicking the Performance tab. You can choose from Real Time
and Historical Settings. Scroll down to the Additional Monitoring Links area and click SQL
Monitoring, as shown in the slide.
Note: The COMPATIBLE initialization parameter must be set to 11.2.0.0 (or higher) to use
this feature.

11.2
SQL Monitoring with

Enterprise Manager Database Control
Monitored
SQL Execution
SQL Execution e
Details r a bl
s fe
- t r an
n no
a
s ฺ
h a
Session ฺ a
SQL
r) Details
u ide
Details ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi withlicEnterprise Manager Database Control
SQL Monitoring
l o
e shows just one possible work flow in Enterprise Manager Database Control. You
rcslide
This
a
Mcan navigate through the following pages:
• Monitored SQL Execution
• SQL Execution Details
• Session Details
• SQL Details

11.2
Monitored SQL Executions
For each long-running SQL execution:

Status: Session ID, where the CPU Disk Start (and end)
ble
Executing SQL is executing time reads of execution
fe r a
Done
an s
Error Execution duration Degree of parallelism - t r
SQL command
n
(wall clock time)
no
being executed
a
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Monitored Z
SQL
l
i Executions
lic
l o
rceyou move the cursor over the values or symbols of each SQL execution, a relevant hint
When
a
M appears. The slide shows the actual SQL command being executed with the cursor on the SQL
ID link.
When you click the link that shows the SQL ID, you navigate to the Monitored SQL Execution
Details page, as shown in the following slide.

11.2
SQL Monitoring List
1
ble
fe r a
ans
n - t r
3
a no
h a s ฺ
ฺ 4r
a )
u ide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Listlic
SQL Monitoring
l o
e shows another example of monitored SQL executions.
rcslide
This
a
M 1. In the top left section, you see for each long-running SQL, the completion status (which
can be executing, done, or error), execution duration (wall clock time), SQL ID, and
Session ID where the SQL was executed.
2. Here you see the database time by wait class, and I/O read and write operations.
3. This detail shows you the degree of parallelism: the number of instances that are involved
in this parallel execution.
4. Here you see that the execution of the SQL command is completed.

11.2
Monitored SQL Execution Details

Currently executing
Basic execution
attributes 4.5 minutes, mainly Little I/O Read/ write buffer gets
CPU time (green) time (blue) Wait event breakdown
bl e
ASH data on timeline
fe r a
an s
n - t r
a no
h a s ฺ
ฺ a r) uide
Current join operation produced 18,000 ฺ c omso e
rows farnt
G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Monitored Z
SQL
l
i Execution
lic Details
l o
e of the SQL execution are displayed on three different tabbed pages:
The
a rcdetails
M • Plan Statistics, as shown in the bottom part of the slide
• Parallel, displaying the distribution of work across the parallel servers (not part of the
example in the slide)
• Activity, displaying ASH data on a time line
When you click the Session link, you navigate to the Session Details page.
When you click the SQL ID link, you navigate to the SQL Details page.

11.2
SQL Execution Details for Parallel Queries

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
SQL Execution
l
Zi Detailslic for Parallel Queries
l o
e shows you the Plan Statistics tabbed page for the SQL execution of parallel queries.
rcslide
This
a
M

11.2
Details for Parallel Execution

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Details for Z i l
Parallel lic
Execution
l o
e shows you monitored SQL execution details for parallel queries (on the Parallel
rcslide
This
a
Mtabbed page).

11.2
Activity Details for Parallel Execution

bl e
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Activity Details
l
Zi for Parallel
lic Execution
e l o
a rcActivity
This tabbed page displays the activity graphs for parallel queries. You see the
Moscillation of CPU and direct reads over time.

11.2
Viewing Session Details

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o
l
Zi Details
Session lic
l
e shows you the session details for the MONI user, divided into the following sections:
rcpage
This
a
M • Server
• Client
• Application
• Contention
• Wait
• Other
When you click the Current SQL link, you navigate to the SQL Details page, as shown in the
following slide.

11.2
SQL Details
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
SQL Details Zi l lic
l o
rceyou click the SQL Monitoring tab, you navigate to the Monitored SQL Execution page.
When
a
M

11.2
Viewing the SQL Monitoring Report

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o
l
i Monitoring
theZSQL lic Report
l
e Monitoring Report shows the same information as the previous slides, but this time
The
a rcSQL
M in a textual, rather than a graphic way. It begins with the SQL Text, followed by global
information, and then the SQL Plan Monitoring details, which also indicates the current
operation with an arrow.
When you see the new Save and Mail buttons, you can also save the report in HTML format
and email the Active Report—for example, to a SQL Tuning expert, if your organization has
such a division of work.

Quiz
Select all the prerequisites that are mandatory for SQL

Monitoring to be activated:
1. The STATISTICS_LEVEL initialization parameter must
be set either to ALL or to TYPICAL.
2. The session must have access to the Oracle Database
Tuning Pack. le
a b
3. The session must be initiated from Enterprise Manager s f er
Grid Control. - t r an
non
4. The execution must be short (less than 3aseconds).
has5dseconds).
5. The execution must be long (morer)than eฺ
ฺa Gu i
c o m n t
n ฺ e
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answers:
l
i 5 lic
1,Z2,
l o
a rce
M

Summary

• Describe SQL Monitoring concepts
• Use Enterprise Manager to monitor SQL commands
• View long-running SQL commands
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Practice 15-1: Overview
In this practice, you use Enterprise Manager to monitor

SQL commands.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Performance Enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Use the new features of the Automatic Database
Diagnostic Monitor (ADDM)
• Use Automatic Memory Management
• Use statistics enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Using the DBMS_ADDM Package
• A database ADDM task is created and executed:
SQL> var tname varchar2(60);

SQL> BEGIN
SQL> :tname := 'my database ADDM task';
SQL> dbms_addm.analyze_db(:tname, 282, 284);
SQL> END;
ble
fe r a
• GET_REPORT procedure for seeing the result: ans
n - t r
a no
SQL> SELECT dbms_addm.get_report(:tname) s FROM DUAL;
) h a e ฺ
r
ฺa Gu i d
c o m n t
n ฺ e
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Using the DBMS_ADDM c
liPackage
l o
a ce
TherDBMS_ADDM package eases the ADDM management. It consists of the following procedures
Mand functions:
• ANALYZE_DB: Creates an ADDM task for analyzing the database globally
• ANALYZE_INST: Creates an ADDM task for analyzing a local instance
• ANALYZE_PARTIAL: Creates an ADDM task for analyzing a subset of instances
• DELETE: Deletes a created ADDM task (of any kind)
• GET_REPORT: Gets the default text report of an executed ADDM task
• Parameters 282,284: Start and end snapshot

• Create an ADDM directive that filters “Undersized SGA”

findings:
SQL> var tname varchar2(60);
SQL> BEGIN
2 dbms_addm.insert_finding_directive (NULL,
3 'My undersized SGA directive',
4 'Undersized SGA',
ble
5 2,
fe r a
6 10);
ans
7 :tname := 'my instance ADDM task';
n - t r
8 dbms_addm.analyze_inst(:tname, 1, 2);
a no
9 END;
h a s ฺ
10
SQL>
/
SELECT dbms_addm.get_report(:tname) from dual; ฺ a r) uide
ฺ c om ent G
a on tud
• Possible findings ine@ S
DBA_ADVISOR_FINDING_NAMES
i l l h i s
e l oฺz use t
a rc Copyright
t o © 2009, Oracle. All rights reserved.
l e (m ense
Zi l
liPackage (continued)
l o
e use possible finding names to query the findings repository to get all occurrences of that
Yourccan
a
Mspecific finding.
In the slide, you see the creation of an instance ADDM task with a finding directive. When the task
name is NULL, it applies to all subsequent ADDM tasks. The finding name (“Undersized SGA”)
must exist in the DBA_ADVISOR_FINDING_NAMES view (which lists all the findings) and is case-
sensitive. The result of DBMS_ADDM.GET_REPORT shows the “Undersized SGA” finding only if
the finding is responsible for at least two (min_active_sessions) average active sessions
during the analysis period. This is at least 10% (min_perc_impact) of the total database time
during that period.

• Procedures to add directives:

– INSERT_FINDING_DIRECTIVE
– INSERT_SQL_DIRECTIVE
– INSERT_SEGMENT_DIRECTIVE
– INSERT_PARAMETER_DIRECTIVE
• Procedures to delete directives: ble
– DELETE_FINDING_DIRECTIVE fe r a
ans
– DELETE_SQL_DIRECTIVE
n - t r
– DELETE_SEGMENT_DIRECTIVE a no
h a s ฺ
– DELETE_PARAMETER_DIRECTIVE
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
liPackage (continued)
l o
rce PL/SQL directive procedures:
Additional
a
M • INSERT_FINDING_DIRECTIVE: Creates a directive to limit reporting of a specific finding
type
• INSERT_SQL_DIRECTIVE: Creates a directive to limit reporting of actions on specific SQL
• INSERT_SEGMENT_DIRECTIVE: Creates a directive to prevent ADDM from creating actions
to “run Segment Advisor” for specific segments
• INSERT_PARAMETER_DIRECTIVE: Creates a directive to prevent ADDM from creating
actions to alter the value of a specific system parameter
• Directives are reported if you specify ALL.
Note: For a complete description of the available procedures, see the Oracle Database 11g PL/SQL
References and Types documentation.

Advisor Named Findings and Directives
• Advisor results are now classified and named:

– Exist in the DBA{USER}_ADVISOR_FINDINGS view
• You can query all finding names from the
DBA_ADVISOR_FINDING_NAMES view:
SQL> select finding_name from dba_advisor_finding_names;

FINDING_NAME
a b le
----------------------------------------
s f er
Top Segments by I/O
- t r an
Top SQL by "Cluster" Wait
n on
. . . s a
Undersized Redo Log Buffer ) a
h deฺ
r
ฺa Gui
Undersized SGA m
co ent
Undersized Shared Pool n ฺ
Undersized Streams Pool ao tud @ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Advisor Named
l
Zi Findings lic and Directives
l o
rceDatabase 10g introduced the advisor framework and various advisors to help DBAs manage
Oracle
a
Mdatabases efficiently. These advisors provide feedback in the form of findings. Oracle Database 11g
now classifies these findings so that you can query the advisor views to understand how often a given
type of finding is recurring in the database. A FINDING_NAME column has been added to the
following advisor views:
• DBA_ADVISOR_FINDINGS
• USER_ADVISOR_FINDINGS
A new DBA_ADVISOR_FINDING_NAMES view displays all the finding names.

Modified Advisor Views
New column Description

FILTERED ‘Y’ means that the row in the view

was filtered out by a directive (or a
combination of directives).
‘N’ means that the row was not
filtered.
Found in:
a b le
• DBA_ADVISOR_FINDINGS er
s f
• USER_ADVISOR_FINDINGS - t r an
• DBA_ADVISOR_RECOMMENDATIONS n on
s a
• USER_ADVISOR_RECOMMENDATIONS ) a
h deฺ
r
ฺa Gui
• DBA_ADVISOR_ACTIONS m
co ent
n ฺ
ao
• USER_ADVISOR_ACTIONS tud @ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
l
Zi Views
Modified Advisor lic
l o
ce containing advisor findings, recommendations, and actions have been enhanced by adding
Therviews
a
Mthe FILTERED column.

New ADDM Views
• DBA{USER}_ADDM_TASKS: Displays every executed

ADDM task; extensions of the corresponding advisor
views
• DBA{USER}_ADDM_INSTANCES: Displays instance-level
information for ADDM tasks that completed
• DBA{USER}_ADDM_FINDINGS: Extensions of the le
a b
corresponding advisor views
s f er
• DBA{USER}_ADDM_FDG_BREAKDOWN: Displays the - t r an
n on
contribution for each finding from the different
s a
instances for database and partial ADDM
h a ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
New ADDM ViewsZi l lic
e l o
Forraccomplete description of the available views, see the Oracle Database 11g documentation set.
M a

Quiz
Views containing advisor findings, recommendations, and

actions include a FILTERED column so that you can
determine if the row in the view was filtered out by a
directive.
1. True
2. False e
r a bl
s fe
- t r an
o n
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer: 1 Zi
l lic
l o
a rce
M

Review: Oracle Database 10g SGA Parameters
• With Automatic Shared Memory Management, five

important SGA components can be automatically tuned.
• Special buffer pools are not auto-tuned.
• Log buffer is a static component but has a good default.
Auto-tuned Manual Manual

parameters dynamic parameters static parametersable
fe r
DB_KEEP_CACHE_SIZE a
LOG_BUFFERn s
SHARED_POOL_SIZE
o n -tr
a nSGA_MAX_SIZE
DB_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
s
ha deฺ
DB_nK_CACHE_SIZEr)
STREAMS_POOL_SIZE
m ฺa Gui
n ฺ co ent
@ a o
SGA_TARGETS tud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Review: Oracle
l
Zi Database
lic 10g SGA Parameters
l o
ce most important pools are automatically tuned when Automatic Shared Memory
Therfive
a
MManagement (ASMM) is activated. These parameters are called auto-tuned parameters.
Manual dynamic parameters are parameters that can be manually resized without having to shut
down the instance but are not automatically tuned by the system.
Manual static parameters include parameters that are fixed in size and cannot be resized without first
shutting down the instance.

Review: Oracle Database 10g PGA Parameters
• PGA_AGGREGATE_TARGET:
– Specifies the target aggregate amount of PGA memory
available to the instance
– Can be dynamically modified at the instance level
– Examples: 100,000 KB, 2,500 MB, 50 GB
– Default: 10 MB or 20% of SGA size (whichever is greater) e
• WORKAREA_SIZE_POLICY: r a bl
ns fe
– Optional
n - tra
– Can be dynamically modified at the instance o session
nor
a
s ฺ
level h a
– Enables fallback to static SQLmmemory ide
ฺar) Gumanagement for a
o t
particular session nฺc en
ao Stud
l @
le this
ฺ z i
e loCopyright u e
s2009,
l e (m ense
Review: Oracle
l
Zi Database
lic 10g PGA Parameters
l o
rce
PGA_AGGREGATE_TARGET
a specifies the target aggregate PGA memory that is available to all
Mserver processes attached to the instance.
Setting PGA_AGGREGATE_TARGET to a nonzero value automatically sets the
WORKAREA_SIZE_POLICY parameter to AUTO. This means that the SQL working areas used by
memory-intensive SQL operators are automatically sized. A nonzero value for this parameter is the
default because, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever
is greater.
Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY
parameter to MANUAL. This means that the SQL work areas are sized using the *_AREA_SIZE
parameters.
Keep in mind that PGA_AGGREGATE_TARGET is not a fixed value. It is used to help the system
better manage PGA memory, but the system will exceed this setting if necessary.
WORK_AREA_SIZE_POLICY can be altered per database session, allowing manual memory
management on a per-session basis if needed. For example, suppose that a session loads a large
import file and a rather large SORT_AREA_SIZE is needed. A logon trigger could be used to set
WORK_AREA_SIZE_POLICY for the account doing the import. If WORK_AREA_SIZE_POLICY
is AUTO and PGA_AGGREGATE_TARGET is set to 0, an ORA-04032 external error is returned at
startup.

Oracle Database 10g PGA Parameters (continued)
Note: Until Oracle 9i Database, Release 2, PGA_AGGREGATE_TARGET controlled the sizing of
work areas for all dedicated server connections. But it had no effect on the shared server connections,
and the *_AREA_SIZE parameters took precedence in this case. Beginning with Oracle Database
10g, PGA_AGGREGATE_TARGET controls work areas allocated by dedicated and shared
connections.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Oracle Database Memory Advisors
• Buffer Cache Advice (introduced in 9i Release 1):

– V$DB_CACHE_ADVICE
– Predicts physical read times for different cache sizes
• Shared Pool Advice (in 9i Release 2):
– V$SHARED_POOL_ADVICE
– Predicts parse times for different sizes of shared pool ble
fe r a
• Java Pool Advice (in 9i Release 2): s
– V$JAVA_POOL_ADVICE - t r an
n o n
h s a sizes
– Predicts Java class load time for Java pool
a eฺ
• Streams Pool Advice (10g Release
a r )
2)
ฺ id
– V$STREAMS_POOL_ADVICEco m G u
ฺ e n t
n
– Predicts spill and unspill
@ ao activity
S tud time for various sizes
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Oracle Database
l
Zi Memory lic Advisors
l o
rceyou size the most important SGA components, the following advisors were introduced in
To help
a
Mprevious releases of Oracle Database:
• V$DB_CACHE_ADVICE contains rows that predict the number of physical reads and time for
the cache size corresponding to each row.
• V$SHARED_POOL_ADVICE displays information about the estimated parse time in the shared
pool for different pool sizes.
• V$JAVA_POOL_ADVICE displays information about the estimated class load time into the
Java pool for different pool sizes.
• V$STREAMS_POOL_ADVICE displays information about the estimated count of spilled or
unspilled messages, and the associated time spent in the spill or unspill activity for different
streams pool sizes.
Note: For more information about these views, see the Oracle Database Reference.

Oracle Database Memory Advisors
• SGA Target Advice (introduced in 10g Release 2):

– V$SGA_TARGET_ADVICE view
– Estimates the DB time for different SGA target sizes
based on current size
• PGA Target Advice (introduced in 9i Release 1):
– V$PGA_TARGET_ADVICE view e
r a bl
– Predicts the PGA cache hit ratio for different PGA sizesfe
s
– ESTD_TIME time column added in 11g Release 1-tran
• For all advisors, STATISTICS_LEVEL must n
beonset to at
s a
least TYPICAL. ) a
h deฺ
r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Oracle Database
l
Zi Memory lic Advisors (continued)
l o
a ceOracle Database 10g, the SGA Advisor shows the improvement in DB time that can be
• rIn
M achieved for a particular setting of the total SGA size. This advisor allows you to reduce trial
and error in setting the SGA size. The advisor data is stored in the V$SGA_TARGET_ADVICE
view.
• V$PGA_TARGET_ADVICE predicts how the PGA cache hit percentage displayed by the
V$PGASTAT performance view is impacted when the value of the
PGA_AGGREGATE_TARGET parameter is changed. The prediction is performed for various
values of the PGA_AGGREGATE_TARGET parameter, selected around its current value. The
advice statistic is generated by simulating the past workload run by the instance. In 11g, a new
column (ESTD_TIME) is added, corresponding to the CPU and I/O time required to process the
bytes.

Automatic Memory Management: Overview
10g&11g 11g
Untunable Untunable Memory target Untunable

PGA PGA PGA
PGA memory
Free targe
t
Free PGA target PGA
SQL areas
SQL areas
SQL areas
SGA targ
et Buffer cache
SGA target
Buffer cache
Buffer cache
Large pool
Large pool ble
fe r a
SGA memory
Large pool
t r a ns
Shared pool Shared pool o
Sharedn - pool
a n
Java pool Java pool
h s
a eJavaฺ pool
r )
Streams pool Streams pool a
m ฺ G uidStreams pool
Other SGA OthernSGAฺ co ent Other SGA
a o t u d
OLTP
l l e@ is S
BATCH BATCH
i h
e l oฺz use t
a rc Copyright
l e (m ense
Automatic Memory
l
Zi Management:
lic Overview
e l o
With
a rcAutomatic Memory Management, the system causes an indirect transfer of memory from SGA
Mto PGA (and vice versa). It automates the sizing of PGA and SGA according to your workload.
This indirect memory transfer relies on the OS mechanism of freeing shared memory. After memory
is released to the OS, the other components can allocate memory by requesting memory from the OS.
Currently, this is implemented on Linux, Solaris, HP-UX, AIX, and Windows. Set your memory
target for the database instance and the system then tunes to the target memory size, redistributing
memory as needed between the system global area (SGA) and the aggregate program global area
(PGA).
The slide displays the differences between the Oracle Database 10g mechanism and the new
Automatic Memory Management with Oracle Database 11g.

Automatic Memory Management: Overview
11g 11g
350 MB 350 MB
Memory Memory
max target max target
300 MB
Memory target
250 MB
Memory target
ble
ALTER SYSTEM SET fe r a
ans
MEMORY_TARGET=300M;
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Automatic Memory
l
Zi Management:
lic Overview (continued)
l o
ce way to manage memory is to allow the database server to automatically manage and
Thersimplest
a
Mtune it for you. To do so (on most platforms), you have to set only a target memory size initialization
parameter (MEMORY_TARGET) and a maximum memory size initialization parameter
(MEMORY_MAX_TARGET). Because the target memory initialization parameter is dynamic, you can
change the target memory size at any time without restarting the database. The maximum memory
size serves as an upper limit so that you do not accidentally set the target memory size too high.
Because certain SGA components either cannot easily shrink or must remain at a minimum size, the
database also prevents you from setting the target memory size too low.

Oracle Database 11g Memory Parameters
MEMORY_MAX_TARGET
SGA_MAX_SIZE
MEMORY_TARGET
SGA_TARGET PGA_AGGREGATE_TARGET
SHARED_POOL_SIZE
Others
ble
DB_CACHE_SIZE
fe r a
LARGE_POOL_SIZE
ans
JAVA_POOL_SIZE
n - t r
STREAMS_POOL_SIZE
a no
DB_KEEP_CACHE_SIZE h a s ฺ
DB_RECYCLE_CACHE_SIZE ฺ a u ide
r) LOG_BUFFER
DB_nK_CACHE_SIZE om t G
ฺ c n
RESULT_CACHE_MAX_SIZE
a on tude
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Oracle Database
l
Zi 11g lMemory
ic Parameters
l o
ce displays the memory initialization parameters hierarchy. Although you have to set only
Therslide
a
MMEMORY_TARGET to trigger Automatic Memory Management, you still have the ability to set
lower-bound values for various caches. So if the child parameters are set by the user, they will be the
minimum values below which that component is not auto-tuned.

Automatic Memory Parameter Dependency
N Y Y
MT>0 MMT=0 MMT=MT
N
MT=0 MMT>0
Y
ST>0 & PAT>0 ST+PAT<=MT<=MMT
Y
MT can be N
Minimum possible values
MT=0 dynamically
changed later. Y
ST>0 & PAT=0 PAT=MT-ST
SGA and PGA N bl e

ST>0
Y
are separately
fe r a
auto-tuned. ST=0 & PAT>0
Y
ans
ST=min(MT-PAT,SMS)
N
n - t r
Only PGA N
a no
ST=60%MT has
is auto-tuned.
r ) d e ฺ
SGA and PGA cannot PAT=40%MT
ฺa Gu i
grow and shrink automatically.
c o m n t
n ฺ e
d PGA can grow and shrink automatically.
@ aoBothSSGA tuand
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Automatic Memory
l
Zi Parameter
lic Dependency
l o
ce illustrates the relationships among the various memory sizing parameters.
Therslide
a
M If MEMORY_TARGET is set to a nonzero value:
• If SGA_TARGET and PGA_AGGREGATE_TARGET are set, they will be considered to be
minimum values for the sizes of SGA and PGA, respectively. MEMORY_TARGET can take
values from SGA_TARGET + PGA_AGGREGATE_TARGET to MEMORY_MAX_TARGET.
• If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, you still auto-tune both the
parameters. PGA_AGGREGATE_TARGET is initialized to a value of
(MEMORY_TARGET - SGA_TARGET).
• If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not set, you still auto-tune both the
parameters. SGA_TARGET is initialized to a value of min(MEMORY_TARGET -
PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will auto-tune
subcomponents.
• If neither is set, they are auto-tuned without minimum or default values. There is a policy of
distributing the total server memory in a fixed ratio to the SGA and PGA during initialization.
The policy is to distribute 60% to SGA and 40% to PGA at startup.

Automatic Memory Parameter Dependency (continued)
If MEMORY_TARGET is not set, or if it is explicitly set to 0 (default value is 0 for 11g):
• If SGA_TARGET is set, the system auto-tunes only the sizes of the subcomponents of the SGA.
PGA is auto-tuned independently of whether it is explicitly set or not. However, the whole SGA
(SGA_TARGET) and PGA (PGA_AGGREGATE_TARGET) are not auto-tuned (do not grow or
shrink automatically). If neither SGA_TARGET nor PGA_AGGREGATE_TARGET is set, the
same policy is followed as present now: PGA is auto-tuned and the SGA is not auto-tuned, and
parameters for some of the subcomponents must be set explicitly (for SGA_TARGET).
• If only MEMORY_MAX_TARGET is set, MEMORY_TARGET defaults to 0 in manual setup using
the text initialization file. Auto-tuning defaults to 10g Release 2 behavior for SGA and PGA.
• If SGA_MAX_SIZE is not user set, it is set internally to MEMORY_MAX_TARGET if user sets
MEMORY_MAX_TARGET (independent of SGA_TARGET being user set).
In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a
value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value
a b le
of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for er
MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup,
a n sf you can
then dynamically change MEMORY_TARGET to a nonzero value if it does not exceed
o n -tr the value of
MEMORY_MAX_TARGET.
s an
If MEMORY_MAX_TARGET is not set and you want to change MEMORY_TARGET
r ) ha deฺ when using a
ฺa i
server parameter file, you must restart the instance to set MEMORY_MAX_TARGET.
u
m G
coabbreviations
n t to parameter names:
n ฺ
Legend: In the slide, use the following list to translate e
• MT = MEMORY_TARGET
@ ao Stud
• MMT = MEMORY_MAX_TARGETlle is
z i t h
• ST = SGA_TARGET
c e loฺ use
r
• PAT = PGA_AGGREGATE_TARGET
a to
(
• SMS = SGA_MAX_SIZEm ns e
ill e
lo Z lice
rc e
Ma

Enabling Automatic Memory Management
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Enabling Automatic lic
Memory Management
l o
e enable Automatic Memory Management by using Enterprise Manager, as shown in the
Yourccan
a
Mslide.
From the Database home page, click the Server tab. On the Server page, click the Memory Advisors
link in the Database Configuration section. This takes you to the Memory Advisors page. On this
page, you can click the Enable button to enable Automatic Memory Management.
The value in the “Total Memory Size for Automatic Memory Management” field is set by default to
the current SGA + PGA size. You can set it to anything more than this but less than the value in
Maximum Memory Size.
Note: On the Memory Advisors page, you can also specify the Maximum Memory Size. If you
change this field, the instance must be restarted for your change to take effect.

Monitoring Automatic Memory Management
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Monitoring Automatic licMemory Management
l o
When
a rceAutomatic Memory Management is enabled, you see a new graphical representation of the
Mhistory of your memory size components in the Allocation History section of the Memory Parameters
page. The green part in the first graphic represents the PGA and the brownish orange part is all of the
SGA. The dark blue below in the lower histogram is the Shared Pool size; light blue corresponds to
Buffer Cache.
The change in the slide displays the possible repartition of memory after the execution of the various
demanding queries. Both SGA and PGA might therefore shrink. Note that with SGA shrink, its
subcomponents also shrink around the same time.
On this page, you can also access the memory target advisor by clicking the Advice button. This
advisor gives you the possible DB time improvement for various total memory sizes.
Note: V$MEMORY_TARGET_ADVICE displays the tuning advice for the MEMORY_TARGET
initialization parameter.

Monitoring Automatic Memory Management
If you want to monitor the decisions made by Automatic

Memory Management from the command line:
• V$MEMORY_DYNAMIC_COMPONENTS has the current
status of all memory components
• V$MEMORY_RESIZE_OPS has a circular history buffer of
the last 800 completed memory resize requests le
a b
• V$MEMORY_CURRENT_RESIZE_OPS has current memory s f er
resize operations - t r an
n
• All SGA and PGA equivalents are still in place
onfor
s a
backward compatibility )h a eฺ
ฺ a r uid
co entm G
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Monitoring Automatic licMemory Management (continued)
l o
a ce
Therfollowing views provide information about dynamic resize operations:
M • V$MEMORY_DYNAMIC_COMPONENTS displays information about the current sizes of all
dynamically tuned memory components, including the total sizes of the SGA and PGA.
• V$MEMORY_RESIZE_OPS displays information about the last 800 completed memory resize
operations (both automatic and manual). This does not include in-progress operations.
• V$MEMORY_CURRENT_RESIZE_OPS displays information about the memory resize
operations (both automatic and manual) that are currently in progress.
• V$SGA_CURRENT_RESIZE_OPS displays information about SGA resize operations that are
currently in progress. An operation can be a grow or a shrink of a dynamic SGA component.
• V$SGA_RESIZE_OPS displays information about the last 800 completed SGA resize
operations. This does not include operations currently in progress.
• V$SGA_DYNAMIC_COMPONENTS displays information about the dynamic components in
SGA. This view summarizes information based on all completed SGA resize operations since
startup.
• V$SGA_DYNAMIC_FREE_MEMORY displays information about the amount of SGA memory
that is available for future dynamic SGA resize operations.

DBCA and Automatic Memory Management
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
DBCA and Automatic c
liMemory Management
l o
e Database 11g, DBCA has new options to accommodate Automatic Memory
rcOracle
With
a
MManagement (AMM). Use the Memory tab of the Initialization Parameters page to set the
initialization parameters that control how the database manages its memory usage. You can choose
from two basic approaches to memory management:
• Typical: Requires very little configuration and allows the database server to manage how it uses
a percentage of your overall system memory. Select Typical to create a database with minimal
configuration or user input. This option is sufficient for most environments and for DBAs who
are inexperienced with advanced database creation procedures. Enter a value in megabytes in the
Memory Size field. To use AMM, select the corresponding option in the Typical section of the
page. Click Show Memory Distribution to see how much memory the DBCA assigns to both
SGA and PGA when you do not select the AMM option.
• Custom (uses ASMM or not): Requires more configuration but provides you with more control
over how the database server uses available system memory. To allocate specific amounts of
memory to the SGA and PGA, select Automatic. To customize how the SGA memory is
distributed among the SGA memory structures (buffer cache, shared pool, and so on), select
Manual and enter specific values for each SGA subcomponent. Review and modify these
initialization parameters later in DBCA.
Note: When you use DBUA or manual DB creation, the MEMORY_TARGET parameter defaults to 0.

Quiz
Which of the following parameters must you set for

Automatic Memory Management?
1. MEMORY_TARGET
2. SGA_TARGET
3. MEMORY_MAX_TARGET
4. PGA_AGGREGATE_TARGET ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer: 1 Zi
l lic
l o
a rce
M

11.2
DB Smart Flash Cache Overview

• DB Smart Flash Cache is an extension of the buffer

cache that resides on a flash disk
• DB Smart Flash Cache has the following advantages:
– Large capacity and cheaper compared to DRAM
– Faster throughput and latency compared to disks
– Performance improvements at moderate cost le
a b
• A flash disk must have write IOPs comparable to read s f er
IOPs to be used as a flash cache - t r an
n on
s a
) a
h deฺ
r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
DB Smart Flash
l
Zi CachelicOverview
l o
ceSmart Flash Cache feature is conceptually an extension of the buffer cache that resides on a
TherDB
a
Mflash disk. The concept is similar to the hierarchical caching system in modern CPU design, where
most frequently accessed data resides in Level 1 cache (here in memory) and less frequently accessed
data resides in a larger Level 2 cache (here on flash disk). This allows you to have a buffer cache
larger than the memory on the server.
A flash disk is a solid state device (SSD) made of flash memory, like those in the modern MP3
devices. A regular disk has spinning magnetic media. With a flash disk, random I/O is very fast
because disk seek time is eliminated. Flash devices appear in different forms from the low-end USB
sticks to the high-end PCIExpress cards.
Flash disks take advantage of the large capacity of flash devices compared to DRAM, and the faster
throughput and latency compared to disks. In addition, flash disk are cheaper than memory.
This can result in enormous performance improvements at moderate cost. A lot more data blocks
could be cached in the system in either memory or flash disk, providing higher IOPs and lower read
latency.
However, there are many varieties of flash disks and some have very low write performance
compared to read performance. To be used as a flash cache, the flash disk must have write IOPs
comparable to read IOPs.

11.2
Using DB Smart Flash Cache

• Benefits
– Better performance for the same price
– Easy to setup
– Fine-tune object-level granularity control of the LRU
mechanism
• Mainly for read-intensive OLTP workloads e
r a bl
s fe
- t r an
n no
a
s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using DB Smart
l
Zi FlashlicCache
l o
e helps you to get better performance. In a database system when the buffer cache memory
Thisrc
feature
a
Mis maxed out and the I/O starts thrashing, your only option is to buy more memory. But the GB/$
ratio on main memory is not cheap and the system might not have enough DRAM slots. So you may
be forced to upgrade the machine.
Flash disks are the perfect middle ground in this situation. For the same price as main memory, you
can acquire 5X-10X flash disk in size. Using the flash cache feature, the flash disk can be configured
with the main memory buffer cache to provide a much larger combined buffer cache. If the whole
working set of the database can fit into the flash cache, after the flash cache has been warmed up,
there is very little cache I/Os to the magnetic disk besides for checkpoint writes and direct I/Os. The
response time and overall throughput for read-intensive OLTP workloads are expected to improve in
a system with the same amount of main memory but additional SSD flash devices configured.
The feature is also easy to use because only two initialization parameters need to be specified before
startup.
This feature also provides you with an interface to fine-tune the object-level granularity control of
the LRU in the flash cache. If needed, you can also specify object-level control over the flash cache
LRU mechanism by specifying two storage clause keywords.

11.2
DB Smart Flash Cache Architecture Overview

In memory buffers area Buffer Cache (2GB)

Flash buffer area
LRU chain
DEFAULT flash KEEP flash

LRU chain LRU chain
bl e
fe r a
an s
Magnetic Disk
-
Flash Cache (20GB)
n t r
a no
(1 ms access time)
h a s ฺ
ฺ a r) uide
Buffer header
ฺ c om ent G Block content
on tud
Pointer
(10 ms access time) a

@ is S
Database Writer
Foreground
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
DB SmartoFlash
l
Zi CachelicArchitecture Overview
l
When
a rcea process tries to access a block and the block does not exist in the buffer cache, it will first be
Mread from disk into the memory (physical read). After the in-memory buffer cache is getting full,
eventually a buffer will get evicted out of the memory based on an LRU mechanism.
With DB Flash Cache, when a clean in-memory buffer is aged out, the buffer content is written to the
flash cache in the background by the Database Writer (DBWR), and the buffer header is kept in
memory as metadata in either the flash DEFAULT or KEEP LRU list, depending on the value of the
FLASH_CACHE object attribute. The flash KEEP LRU list is used to maintained the buffer headers
on a separate list to prevent the regular buffer headers from replacing them. Therefore, the flash
buffer headers belonging to an object specified as KEEP tend to stay longer in the flash cache. If the
FLASH_CACHE object attribute is set to NONE, the system does not retain the corresponding buffers
in the flash cache or in memory.
When a buffer already aged out of memory is accessed again, the system checks to see whether the
buffer is in the flash cache. If so, it reads it back from the flash cache instead of reading it from the
disk, which takes only a fraction of the time. The consistency of flash cache buffers across RAC
clusters is maintained in the same way as by Cache Fusion. Because the flash cache is an extended
cache and direct I/O totally bypasses the buffer cache, this feature does not support direct I/O.
Note that the system does not put dirty buffers in flash cache because it may have to read buffers into
memory in order to checkpoint them because writing to flash cache does not count for checkpoint.
Note: A physical read from the magnetic disk typically takes about 10 MS, while flash cache has a
typical access time of 1MS.
11.2
Configuring DB Smart Flash Cache

• Two initialization parameters:

– DB_FLASH_CACHE_FILE specifies the OS file/disk path
and name for the flash cache.
– DB_FLASH_CACHE_SIZE represents the size of the flash
cache.
• Nonstandard block size is not supported with DB Smart
Flash Cache a b le
s f er
• All standard block size buffers use the same flash
- t r an
cache n on
s a
• DB Smart Flash Cache is not auto-tuned
h a ฺ
db_flash_cache_file = '/dev/foa1' ฺ a r) uide
db_flash_cache_file =
ฺ c om ent G
'/work/flash_cache.dbf'
db_flash_cache_file =
a on tud
'+FLASH_DG/flash_cache'
db_flash_cache_size
l l e@ is S
= 5G
i
ฺz se th
l o
a rce Copyright
l e (m ense
ConfiguringZDB l
i SmartlicFlash Cache
Yourc
l o
e to set two initialization parameters to use the DB Smart Flash Cache feature:
need
a
M • DB_FLASH_CACHE_FILE specifies the OS file/disk path and name for the flash cache. The
file specified in the parameter must live on a flash disk. The file does not have to exist and the
database will create a new file with this name during startup, with the size specified in
DB_FLASH_CACHE_SIZE. The first example could be used if using a raw device, while the
second could be used if using a file system mounted on the device. The third example could be
used when creating a disk group first (FLASH_DG in this case) where all physical disks in the
disk group are flash drives/cards, and where FLASH_CACHE is an alias to an actual ASM file
named automatically. If the file exists, the database server will reuse the same file and validate
the size. In this release, the old content on the same file will be discarded.
The flash cache file/disk must be private to a particular instance of a particular database and
cannot be shared between instances or databases. This parameter has to be specified before
startup and cannot be modified after the instance has been started up.
• DB_FLASH_CACHE_SIZE specifies the size of the flash cache. This parameter can only be
specified before startup and DB_FLASH_CACHE_FILE must be specified. After the database is
started, it can be modified but only to a value of 0 (which disables the flash cache). When it is
disabled, it can be reenabled again but has to be set back to the original value when the database
was first started up. Dynamic resizing of DB_FLASH_CACHE_SIZE or reenabling to a
different size is not supported.

Configuring DB Smart Flash Cache (continued)
Nonstandard block sizes are not supported in flash cache. All standard block size buffers from
different buffer pools will use the same flash cache.
Note: The tuning between DB_CACHE_SIZE and DB_FLASH_CACHE_SIZE cannot be done
automatically because DB_FLASH_CACHE_SIZE is not auto-tuned in the MEMORY_TARGET
feature.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

11.2
Sizing DB Smart Flash Cache

• Size flash cache to be between 2-10 times the size of
the buffer cache
• With automatic shared memory management, make

flash cache between 2-10 times the size of SGA_TARGET
• Add 100-200 bytes to buffer cache for each block
moved to flash cache
• You can use:
– ALTER SYSTEM to set DB_FLASH_CACHE_SIZE to zero to
a b le
disable flash cache s f er
r
– ALTER SYSTEM to set flash cache back to its original
- t ansize
to re-enable it non a
• Dynamically changing the size of the a s
hflash cache
ฺ is not
r ) i d e
supported m ฺa Gu
o
ฺc auto-tuned e n t
• DB Smart Flash Cache aison not
@ S tud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
Zi FlashlicCache
Sizing DB Smart
l o
e rule, size flash cache to be between two times and ten times the size of the buffer cache.
As arc
general
a
MAny multiplier less than two will not provide any benefit.
If you are using automatic shared memory management, make flash cache between two times and ten
times the size of SGA_TARGET. Using 80 percent of the size of SGA_TARGET instead of the full
size would also suffice for this calculation.
For each database block moved from the buffer cache to flash cache, a small amount of metadata
about the block is kept in the buffer cache. For a single instance database, the metadata consumes
approximately 100 bytes. For an Oracle Real Application Clusters (Oracle RAC) database, it is closer
to 200 bytes.
You must, therefore, take this extra memory requirement into account when adding flash cache:
• If you are managing memory manually, increase the size of the buffer cache by approximately
an amount equal to the number of database blocks that fit into flash cache multiplied by 100 (or
200 for Oracle RAC).
• If you are using automatic memory management, increase the size of MEMORY_TARGET using
the algorithm described above. You may first have to increase the size of
MEMORY_MAX_TARGET.
• If you are using automatic shared memory management, increase the size of SGA_TARGET.
Note: The tuning between DB_CACHE_SIZE and DB_FLASH_CACHE_SIZE cannot be done
automatically as DB_FLASH_CACHE_SIZE is not auto-tuned in the MEMORY_TARGET feature.

11.2
Specifying DB Smart Flash Cache for a Table
create table mycache

tablespace tbs_1
storage (FLASH_CACHE KEEP|NONE|DEFAULT);
*_TABLES
*_INDEXES
FLASH_CACHE
*_CLUSTERS
…
ble
fe r a
ans
n - t r
V$SQL –> OPTIMIZED_PHY_READ_REQUESTS
V$SQLAREA –> OPTIMIZED_PHY_READ_REQUESTS a no
V$FILESTAT –> OPTIMIZED_PHYBLKRD h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Specifying DB
l
Zi SmartlFlash
ic Cache for a Table
l o
The
a ce clause now has a new option: FLASH_CACHE. This option allows you to specify the
rstorage
Mfollowing attributes:
• DEFAULT: In-memory buffers for this object are put on the flash cache after they are aged out
of the main memory and become flash buffers. Such flash buffers are kept on a flash LRU list
and might be aged out with a standard LRU algorithm.
• KEEP: In-memory buffers for this object are put on the flash cache after they are aged out of the
main memory. Flash buffers for this object are kept on a separate LRU list from the other flash
buffers, and are not aged out of the flash cache as long as the flash cache size is large enough.
• NONE: In-memory buffers for this object are not put on the flash cache when they are aged out
of memory.
The slide shows you a CREATE TABLE example using the new storage clause option.
In addition, the slide shows you some of the dictionary views that have new columns to reflect the
flash information.
Note: For consistency, the system counts flash I/Os as physical I/O for all type of statistics. It also
provides corresponding flash-specific statistics to differentiate flash I/Os from disk I/Os. AWR
reports are updated to reflect these new statistics and wait events. Flash-related statistics are also
added to V$SESSTAT.

Statistic Preferences: Overview
Optimizer Statement level
statistics
Table level
gathering DBA_TAB_STAT_PREFS
task Schema level
Database level
Global level
CASCADE DEGREE
ESTIMATE_PERCENT METHOD_OPT
NO_INVALIDATE GRANULARITY
PUBLISH INCREMENTAL
STALE_PERCENT
ble
set_global_prefs
fe r a
DB
ans
set_database_prefs
se
t|
MS
_S
TA
n - t r
no
TS
ex get
po | d
set_schema_prefs
rt | ele a
s ฺ
im te
set_table_prefs
h apo
rt
gather_*_stats ฺa
r) uide DBA
co entm G
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Statistic Preferences: c
liOverview
l o
a ce
Therautomated statistics-gathering feature was introduced in Oracle Database 10g, Release 1 to
Mreduce the burden of maintaining optimizer statistics. However, there were cases where you had to
disable it and run your own scripts instead. One reason was the lack of object-level control.
Whenever you found a small subset of objects for which the default gather statistics options did not
work well, you had to lock the statistics and analyze them separately by using your own options. For
example, the feature that automatically tries to determine adequate sample size
(ESTIMATE_PERCENT=AUTO_SAMPLE_SIZE) does not work well against columns that contain
data with very high frequency skews. The only way to get around this issue was to manually specify
the sample size in your own script.
Note: You can describe all the effective statistics preference settings for all relevant tables by using
the DBA_TAB_STAT_PREFS view.

Using New Statistic Preferences Features
• PUBLISH: Used to decide whether to publish the

statistics to the dictionary or to store them in a
pending area before.
• STALE_PERCENT: Used to determine the threshold level
at which an object is considered to have stale
statistics. The value is a percentage of rows modified
since the last statistics gathering. a b le
s f er
• INCREMENTAL: Used to gather global statistics on
- t r an
partitioned tables in an incremental way. non
s a
) a
h deฺ
exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13'); r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Using New Statistic lic
Preferences Features
l o
ce Preferences feature in Oracle Database 11g introduces flexibility so that you can rely
TherStatistic
a
Mmore on the automated statistics-gathering feature to maintain the optimizer statistics when some
objects require settings that are different from the database default.
This feature allows you to associate the statistics-gathering options that override the default behavior
of the GATHER_*_STATS procedures and the automated Optimizer Statistics Gathering task at the
object or schema level. You can use the DBMS_STATS package to manage the gathering statistics
options.
You can set, get, delete, export, and import those preferences at the table, schema, database, and
global levels. Global preferences are used for tables that do not have preferences, whereas database
preferences are used to set preferences on all tables.
The following options are available as of Oracle Database 11g Release 1:
• PUBLISH is used to decide whether to publish the statistics to the dictionary or to store them in
a pending area before.
• STALE_PERCENT is used to determine the threshold level at which an object is considered to
have stale statistics. The value is a percentage of rows modified since the last statistics
gathering. The example changes the 10 percent default to 13 percent for SH.SALES only.
• INCREMENTAL is used to gather global statistics on partitioned tables in an incremental way.

Setting Global Preferences
with Enterprise Manager
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Setting Global
l
Zi Preferences
lic with Enterprise Manager
l o
ce to control global preference settings by using Enterprise Manager. You do so on the
It isrpossible
a
MManage Optimizer Statistics page, which you access from the Database home page by clicking the
Server tab, then the Manage Optimizer Statistics link, and then the Global Statistics Gathering
Options link.
On the Global Statistics Gathering Options page, change the global preferences in the Gather
Optimizer Statistics Default Options section. When finished, click the Apply button.
Note: To change the statistics gathering options at the object level or schema level, click the Object
Level Statistics Gathering Preferences link on the Manage Optimizer Statistics page.

Partitioned Tables and Incremental Statistics:
Overview
GRANULARITY=GLOBAL% & INCREMENTAL=FALSE

Global
statistics
… … …
Q1 1970 Q2 1970 Q1 2007 Q1 1970 Q2 1970 Q1 2007 Q1 1970 Q2 1970 Q1 2007
bl e
fe r a
ans
n - t r
n o
… … a
s …ฺ
) h a e Global
Q1 1970 Q2 1970 Q1 2007 Q1 1970 Q2 1970 Q1 2007
r
ฺa Guid
Q1 1970 Q2 1970
statistics
Q1 2007
m
o ent
cINCREMENTAL=TRUE
n&ฺ
GRANULARITY=GLOBAL%
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Partitioned Tables
l
Zi and licIncremental Statistics: Overview
e l o
Forracpartitioned table, the system maintains both the statistics on each partition and the overall
a
Mstatistics for the table. Generally, if the table is partitioned using a date range value, very few
partitions go through data modifications (DML). For example, suppose you have a table that stores
the sales transactions. You partition the table on sales date with each partition containing transactions
for a quarter. Most of the DML activity happens on the partition that stores the transactions of the
current quarter. The data in other partitions remains unchanged. The system currently keeps track of
DML monitoring information at the table and (sub)partition levels. Statistics are gathered only for
those partitions (in the example in the slide, the partition for the current quarter) that have
significantly changed (current threshold is 10%) since the last statistics gathering. However, global
statistics are gathered by scanning the entire table, which makes global statistics very expensive on
partitioned tables—especially when some partitions are stored in slow devices and not modified
often.
Oracle Database 11g can expedite the gathering of certain global statistics, such as the number of
distinct values. In contrast to the traditional way of scanning the entire table, there is a new
mechanism to define global statistics by scanning only those partitions that have been changed and
still make use of the statistics gathered before for those partitions that are unchanged. In short, these
global statistics can be maintained incrementally.

Partitioned Tables and Incremental Statistics: Overview (continued)
The DBMS_STATS package currently allows you to specify the granularity on a partitioned table.
For example, you can specify auto, global, global and partition, all, partition, and subpartition. If the
granularity specified includes GLOBAL and the table is marked as INCREMENTAL for its gathering
options, the global statistics are gathered using the incremental mechanism. Moreover, statistics for
changed partitions are gathered as well, whether you specified PARTITION in the granularity or not.
Note: The new mechanism does not incrementally maintain histograms and density global statistics.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Hash-Based Sampling for Column Statistics
• Computing column statistics is the most expensive

step in statistics gathering.
• The row-sampling technique gives inaccurate results
with skewed data distribution.
• A new approximate counting technique is used when
ESTIMATE_PERCENT is set to AUTO_SAMPLE_SIZE. e
– You are encouraged to use AUTO_SAMPLE_SIZE. r a bl
ns fe
traused.
• Otherwise, the previous row sample technique -is
n on
s a
) a
h deฺ
r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Hash-BasedZ i l
Sampling licfor Column Statistics
l o
ce optimization, it is essential to have a good estimate of the number of distinct values. By
Forrquery
a
Mdefault, and without histograms, the optimizer uses the number of distinct values to evaluate the
selectivity of a predicate of a column. The algorithm used in Oracle Database 10g computes the
number of distinct values with a SQL statement counting the number of distinct values found on a
sample of the underlying table. With Oracle Database 10g, you have two choices when gathering
column statistics:
1. Use a small sample size, which leads to less accurate results but a short execution time.
2. Use a large sample or full scan, which leads to very accurate results but a very long execution
time.
In Oracle Database 11g, there is a new method for gathering column statistics that provides accuracy
similar to a scan with the execution time of a small sample (1% to 5%). This new technique is used
when you invoke a procedure from DBMS_STATS with the ESTIMATE_PERCENT gathering option
set to AUTO_SAMPLE_SIZE, which is the default value. The row sampling–based algorithm is used
for the collection of a number of distinct values if you specify any value other than
AUTO_SAMPLE_SIZE. This preserves the previous behavior when you specify sampling
percentage.

Hash-Based Sampling for Column Statistics (continued)
Note: With Oracle Database 11g, you are encouraged to use AUTO_SAMPLE_SIZE. The new
evaluation mechanism fixes the following most encountered issues in Oracle Database 10g:
• The auto option stops too early and generates inaccurate statistics, and the user would specify a
higher sample size than the one used by auto.
• The auto option stops too late and the performance is bad, and the user would specify a lower
sample size than the one used by auto.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Multicolumn Statistics: Overview
VEHICLE
MAKE MODEL
S(MAKE Λ MODEL)=S(MAKE)xS(MODEL)
select
dbms_stats.create_extended_stats('jfv','vehicle','(make,model)') from
dual; 2
exec dbms_stats.gather_table_stats('jfv','vehicle',- bl e
r
fe 3a
method_opt=>'for all columns size 1 for columns (make,model) size 3');
an s
n - t r
DBA_STAT_EXTENSIONS VEHICLE a no
SYS_STUF3GLKIOP5F4B0BTTCFTMX0W
MAKE MODEL h a s ฺ
ฺ a r) uid4 e
ฺ c om ent G
S(MAKE Λ@ aon)=S(SMAKE,MODEL
MODEL tud )
l l e i s
l o ฺzi se th
a rce Copyright
l e (m ense
i l
MulticolumnZStatistics: licOverview
l o
e Database 10g, the query optimizer takes into account correlation between columns when
rcOracle
With
a
Mcomputing the selectivity of multiple predicates in the following limited cases:
• If all the columns of a conjunctive predicate match all the columns of a concatenated index key,
and the predicates are equalities used in equijoins, then the optimizer uses the number of distinct
keys (NDK) in the index for estimating selectivity, as 1/NDK.
• When DYNAMIC_SAMPLING is set to level 4, the query optimizer uses dynamic sampling to
estimate the selectivity of complex predicates involving several columns from the same table.
However, the sample size is very small and increases parsing time. As a result, the sample is
likely to be statistically inaccurate and may cause more harm than good.
In all other cases, the optimizer assumes that the values of columns used in a complex predicate are
independent of each other. It estimates the selectivity of a conjunctive predicate by multiplying the
selectivity of individual predicates. This approach always results in under-estimation of the
selectivity. To circumvent this issue, Oracle Database 11g allows you to collect, store, and use the
following statistics to capture functional dependency between two or more columns (also called
groups of columns): number of distinct values, number of nulls, frequency histograms, and density.

Multicolumn Statistics: Overview (continued)
For example, consider a VEHICLE table in which you store information about cars. Columns MAKE
and MODEL are highly correlated in that MODEL determines MAKE. This is a strong dependency, and
both columns should be considered by the optimizer as highly correlated. You can signal that
correlation to the optimizer by using the CREATE_EXTENDED_STATS function as shown in the
example in the slide, and then compute the statistics for all columns (including the ones for the
correlated groups that you created).
Note
• The CREATE_EXTENDED_STATS function returns a virtual hidden column name such as
SYS_STUW_5RHLX443AN1ZCLPE_GLE4.
• Based on the example in the slide, the name can be determined by using the following SQL:
select
dbms_stats.show_extended_stats_name('jfv','vehicle','(make,model
)') from dual
a b le
• After creation, you can retrieve the statistics extensions by using the
s f er
ALL|DBA|USER_STAT_EXTENSIONS views.
a n
o n -tr
a n
a s
h deฺ
r )
ฺa Gui
m
co ent
n ฺ
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Expression Statistics: Overview
CREATE INDEX upperidx ON VEHICLE(upper(MODEL))

VEHICLE
MODEL
VEHICLE
MODEL Still possible
Recommended
VEHICLE DBA_STAT_EXTENSIONS
bl e
S(upper( MODEL))=0.01 MODEL fe r a
an s
- t r
SYS_STU3FOQ$BDH0S_14NGXFJ3TQ50
n
a no
h a s ฺ
a r) uide
select dbms_stats.create_extended_stats('jfv','vehicle','(upper(model))')
ฺ
from
om ent G
dual;
ฺ c
on1 for tcolumns
exec dbms_stats.gather_table_stats('jfv','vehicle',-
method_opt=>'for all columns a
@
size
S ud (upper(model)) size 3');
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Expression Statistics: licOverview
l o
rce involving expressions on columns are a significant issue for the query optimizer. When
Predicates
a
Mcomputing selectivity on predicates of the form function(Column) = constant, the optimizer
assumes a static selectivity value of 1 percent. Obviously, this approach is wrong and causes the
optimizer to produce suboptimal plans.
The query optimizer has been extended to better handle such predicates in limited cases where
functions preserve the data distribution characteristics of the column and thus allow the optimizer to
use the columns statistics. An example of such a function is TO_NUMBER.
Further enhancements have been made to evaluate built-in functions during query optimization to
derive better selectivity using dynamic sampling. Finally, the optimizer collects statistics on virtual
columns created to support function-based indexes.
However, these solutions are either limited to a certain class of functions or work only for
expressions used to create function-based indexes. By using expression statistics in Oracle Database
11g, you can use a more general solution that includes arbitrary user-defined functions and does not
depend on the presence of function-based indexes. As shown in the example in the slide, this feature
relies on the virtual column infrastructure to create statistics on expressions of columns.

Deferred Statistics Publishing: Overview
OPTIMIZER_USE_PENDING_STATISTICS=TRUE
PROD
OPTIMIZER_USE_PENDING_STATISTICS=FALSE
Dictionary
Pending statistics
statistics
PUBLISH=FALSE
+
GATHER_*_STATS
DBA_TAB_PENDING_STATS
bl e
IMPORT_TABLE_STATS
fe r a
expdp/impdp
an s
- t r
PUBLISH_PENDING_STATS
n
a no
EXPORT_PENDING_STATS
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud TEST
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Publishing:
Deferred Statistics lic Overview
l o
ce the statistics-gathering operation automatically stores the new statistics in the data
By rdefault,
a
Mdictionary each time it completes the iteration for one object (table, partition, subpartition, or index).
The optimizer sees them as soon as they are written to the data dictionary, and these new statistics
are called current statistics. This automatic publishing can be frustrating to the DBA, who is never
sure of the aftermath of the new statistics—days or even weeks later. In addition, the statistics used
by the optimizer can be inconsistent if, for example, table statistics are published before the statistics
of its indexes, partitions or subpartitions.
To avoid these potential issues, in Oracle Database 11g Release 1, you can separate the gathering
step from the publication step for optimizer statistics. There are two benefits in separating the two
steps:
• Supports the statistics gathering operation as an atomic transaction. The statistics of all tables
and dependent objects (indexes, partitions, subpartitions) in a schema will be published at the
same time. This new model has two beneficial properties: The optimizer will always have a
consistent view of the statistics, and if for some reason the gathering step fails during the
gathering process, it will be able to resume from where it left off when it is restarted by using the
DBMS_STAT.RESUME_GATHER_STATS procedure.
• Allows DBAs to validate the new statistics by running all or part of the workload using the
newly gathered statistics on a test system and, when satisfied with the test results, to proceed to
the publishing step to make them current in the production environment.

Deferred Statistics Publishing: Overview (continued)
When you specify the PUBLISH to FALSE gather option, gathered statistics are stored in the
pending statistics tables instead of being current. These pending statistics are accessible from a
number of views: {ALL|DBA|USER}_{TAB|COL|IND|TAB_HISTGRM}_PENDING_STATS.
To test the pending statistics, you have two options:
• Transfer the pending statistics to your own statistics table by using the new
DBMS_STAT.EXPORT_PENDING_STATS procedure, export your statistics table to a test

system from where you can import it back, and then render the pending statistics current by
using the DBMS_STAT.IMPORT_TABLE_STATS procedure.
• Enable session-pending statistics by altering your session initialization parameter
OPTIMIZER_USE_PENDING_STATISTICS to TRUE. By default, this new initialization
parameter is set to FALSE. This means that in your session, you parse SQL statements by using
the current optimizer statistics. By setting it to TRUE in your session, you switch to the pending
statistics instead.
a b le
When you have tested the pending statistics and are satisfied with them, you can publish them
s f er as
current in your production environment by using the new
- t r an
DBMS_STAT.PUBLISH_PENDING_STATS procedure.
n on
Note: For more information about the DBMS_STATS package, see the s a
PL/SQL Packages and Types
Reference. ) h a e ฺ
ฺ a r uid
m
co ent G
n ฺ
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Deferred Statistics Publishing: Example
exec dbms_stats.set_table_prefs('SH','CUSTOMERS','PUBLISH','false'); 1
exec dbms_stats.gather_table_stats('SH','CUSTOMERS'); 2
alter session set optimizer_use_pending_statistics = true; 3
bl e
fe r a
ans
Execute your workload from the same session.
n - t r 4
a no
h a s ฺ
exec dbms_stats.publish_pending_stats('SH','CUSTOMERS'); ฺ a r) uide 5
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Publishing:
Deferred Statistics lic Example
l o
a ce the SET_TABLE_PREFS procedure to set the PUBLISH option to FALSE. This prevents
1.rUse
M the next statistics gathering operation from automatically publishing statistics as current.
According to the first statement, this is true for the SH.CUSTOMERS table only.
2. Gather statistics for the SH.CUSTOMERS table in the pending area of the dictionary.
3. Test the new set of pending statistics from your session by setting the
OPTIMIZER_USE_PENDING_STATISTICS to TRUE.
4. Issue queries against SH.CUSTOMERS.
5. If you are satisfied with the test results, use the PUBLISH_PENDING_STATS procedure to
render the pending statistics for SH.CUSTOMERS current.
Note: To analyze the differences between the pending statistics and the current ones, you could
export the pending statistics to your own statistics table and then use the new
DBMS_STAT.DIFF_TABLE_STATS function.

Quiz
The Statistic Preferences feature enables you to:

1. Associate statistics-gathering options that override
the default behavior of the GATHER_*_STATS
procedures
2. Associate statistics-gathering options that override
the automated Optimizer Statistics Gathering task le
a b
3. Specify the statistics-gathering options at the object s f er
or schema level - t r an
4. Specify the statistics-gathering options a
on
atnthe
database level h a s ฺ
) e r
m ฺ a G uid
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
2,i 3, and l4ic
Answers: 1, Z
l o
a rce
M

Locking Enhancements
• DDL commands can now wait for DML locks to be

released
• DDL_LOCK_TIMEOUT initialization parameter: Set time
limit in seconds
• New WAIT [<timeout>] clause for the LOCK TABLE
command le
a b
• The following commands will no longer acquire s f er
r
exclusive locks (X), but will acquire shared exclusive
- t an
locks (SX): n on
a
s ฺ
– CREATE INDEX ONLINE h a
ar) Guide
– CREATE MATERIALIZED VIEWmฺLOG
o t
nฺc den NOVALIDATE
– ALTER TABLE ENABLEoCONSTRAINT
a Stu
l l e@ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Zi l
Locking Enhancements lic
l o
ce can limit the time that DDL commands wait for DML locks before failing by setting the
• rYou
a
M DDL_LOCK_TIMEOUT parameter at the system or session level. This initialization parameter is
set by default to 0, that is NOWAIT, which ensures backward compatibility. The range of values
is 0–1,000,000 (in seconds).
• The LOCK TABLE command has new syntax that you can use to specify the maximum number
of seconds the statement should wait to obtain a DML lock on the table. Use the WAIT clause to
indicate that the LOCK TABLE statement should wait up to the specified number of seconds to
acquire a DML lock. There is no limit on the value of the integer.
• In highly concurrent environments, the requirement of acquiring an exclusive lock—for
example, at the end of an online index creation and rebuild—could lead to a spike of waiting
DML operations and, therefore, a short drop and spike of system usage. While this is not an
overall problem for the database, this anomaly in system usage could trigger operating system
alarm levels. The commands listed in the slide no longer require exclusive locks.

Identify Foreground and Background Process
Events
New columns report foreground-only statistics:

• V$SYSTEM_EVENT:
– TOTAL_WAITS_FG
– TOTAL_TIMEOUTS_FG
– TIME_WAITED_FG
– e
AVERAGE_WAIT_FG
r a bl
– TIME_WAITED_MICRO_FG s fe
• V$SYSTEM_WAIT_CLASS: - t r an
n no
– TOTAL_WAITS_FG a
h a s ฺ
– TIME_WAITED_FG r) uide
ฺ a
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Foreground Z i l
Statistics lic
l o
e have been added to the V$SYSTEM_EVENT and the V$SYSTEM_WAIT_CLASS
Newrccolumns
a
Mviews that allow you to easily identify events that are caused by foreground or background processes.
V$SYSTEM_EVENT has five new NUMBER columns that represent the statistics from purely
foreground sessions:
• TOTAL_WAITS_FG
• TOTAL_TIMEOUTS_FG
• TIME_WAITED_FG
• AVERAGE_WAIT_FG
• TIME_WAITED_MICRO_FG
V$SYSTEM_WAIT_CLASS has two new NUMBER columns that represent the statistics from purely
foreground sessions:
• TOTAL_WAITS_FG
• TIME_WAITED_FG

Summary

• Use the new features of ADDM
• Use Automatic Memory Management
• Use statistics enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc


• Using Automatic Memory Management
• Using deferred optimizer statistics
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Marc
le
oZ
i l l l
m a r c e
e ( icens
e
z i
to
l @
loฺ use
n
le this
ฺ
m
ao Stud
r )
co ent
s
ฺa Gui
ha deฺ
an
on - t r an
s
fe r a bl
e
Application Performance Enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Describe online redefinition for tables with materialized
views and view logs
• Create and use invisible indexes
• Describe Adaptive Cursor Sharing
• Use the SQL query result cache a b le
• Use the PL/SQL function cache s f er
n a
o n -tr
n a
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

11.2
update
Online Redefinition Enhancements
• Online table redefinition supports the following:

– Tables with materialized views and view logs
– Triggers with ordering dependency
• Online redefinition does not systematically invalidate
dependent objects.
bl e
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Online Redefinition lic
Enhancements
l o
rceDatabase 11g supports online redefinition for tables with materialized views and view logs. In
Oracle
a
Maddition, online redefinition supports triggers with the FOLLOWS clause, which establishes an
ordering dependency between the triggers. In Oracle Database 11g Release 2, the PRECEDES clause,
used to indicate that the trigger being created must fire before the specified triggers, is also
supported.
In previous database versions, all directly and indirectly dependent views and PL/SQL packages
would be invalidated after an online redefinition or other DDL operations. These views and PL/SQL
packages would automatically be recompiled whenever they are next invoked. If there are many
dependent PL/SQL packages and views, the cost of the revalidation or recompilation can be
significant.
In Oracle Database 11g, views, synonyms, and other table-dependent objects (with the exception of
triggers) that are not logically affected by the redefinition, are not invalidated. So, for example, if
referenced column names and types are the same after the redefinition, they are not invalidated. This
optimization is “transparent,” that is, it is turned on by default.
Another example: If the redefinition drops a column, only those procedures and views that reference
the column are invalidated. The other dependent procedures and views remain valid. Note that all
triggers on a table being redefined are invalidated (as the redefinition can potentially change the
internal column numbers and data types), but they are automatically revalidated with the next DML
execution against the table.
Fine-Grained Dependency Management
Adding a column to a table no longer affects dependent

views and does not invalidate the dependent objects.
• Dependencies are tracked automatically.
• This mechanism requires no configuration.
ble
fe r a
CREATE VIEW NEW_EMPLOYEES Dependent unit
t r a ns
AS SELECT LAST_NAME Cross-unit reference
o n -
FROM EMPLOYEES Parent unit s a
n
a eฺ
WHERE EMPLOYEE_ID > 20; r) h reference
Cross-unit d ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l
Fine-GrainedZDependency lic Management
l o
rce Database 11g, you now have access to records that describe more precise dependency
In Oracle
a
Mmetadata. This is called fine-grained dependency and enables you to see when dependent objects are
not invalidated without logical requirement.
Oracle Database 11g dependencies are tracked at the element level within a unit. Element-based
dependency tracking covers the following:
• Dependency of a single-table view on its base table
• Dependency of a PL/SQL program unit (package specification, package body, or subprogram)
on the following:
- Other PL/SQL program units
- Tables
- Views
A cross-unit reference creates a dependency from the unit making the reference (the dependent
unit—for example, the NEW_EMPLOYEES view above) to the unit being referenced (the parent
unit—for example, the EMPLOYEES table). Dependencies are always tracked automatically by
PL/SQL and SQL compilers. This mechanism is available without any configuration.
Reducing the invalidation of dependent objects in response to changes to the objects on which they
depend increases application availability, both in the development environment and during online
application upgrade.

Minimizing Dependent Recompilations
• Adding a column to a table does not invalidate its

dependent objects.
• Adding a PL/SQL unit to a package does not invalidate
dependent objects.
• Fine-grain dependencies are tracked automatically.
• No configuration is required. ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Minimizing Dependent licRecompilations
l o
rce the invalidation of dependent objects in response to changes to the objects on which they
Reducing
a
Mdepend increases application availability, both in the development environment and during online
application upgrade.

More Precise Dependency Metadata
Recording additional, fine-grained dependency

management increases application availability.
• Prior to Oracle Database 11g, adding column D to table
T invalidated the dependent objects.
• In Oracle Database 11g, adding column D to table T
does not affect view V and does not invalidate the le
a b
dependent objects. fer s
- t r an
n no
a
s ฺ
h a
ฺ a r) uide
c m nt PG Function F
oProcedure
Table T View V ฺ
on tude
Add column D
Column A Column A a
@B is S
Column B l l
Column
i e
l o ฺz se th
a rce Copyright
l e (m ense
More Precise i l
ZDependency lic Metadata
l o
rceOracle Database releases record dependency metadata—for example, that PL/SQL unit P
Earlier
a
Mdepends on PL/SQL unit F, or that view V depends on table T—with the precision of the whole
object. This means that dependent objects are sometimes invalidated without logical requirement. For
example, if view V depends only on columns A and B in table T, and column D is added to table T,
the validity of view V is not logically affected. Nevertheless the view V was invalidated by the
addition of column D to table T. Now, in Oracle Database Release 11g, adding column D to table T
does not invalidate view V. Similarly, if procedure P depends only on elements E1 and E2 within a
package, adding element E99 to the package does not invalidate procedure P.

Managing Dependencies
CREATE TABLE t (col_a NUMBER, col_b NUMBER, col_c NUMBER);

1
CREATE VIEW v AS SELECT col_a, col_b FROM T;

SELECT ud.name, ud.type, ud.referenced_name,
ud.referenced_type, uo.status
FROM user_dependencies ud, user_objects uo
WHERE ud.name = uo.object_name AND ud.name = 'V';
NAME TYPE REFERENCED_NAME REFERENCED_TYPE STATUS
---------------- ---------- ---------------- ----------------- -------
V VIEW T TABLE VALID
ble
fe r a
2
ALTER TABLE t ADD (col_d VARCHAR2(20));
ans
SELECT ud.name, ud.type, ud.referenced_name,
n - t r
ud.referenced_type, uo.status
a no
FROM user_dependencies ud, user_objects uo
h a s ฺ
r) uide
WHERE ud.name = uo.object_name AND ud.name = 'V';
NAME TYPE REFERENCED_NAME ฺ a
m -----------------
G
REFERENCED_TYPE STATUS
ฺ c o e n t
---------------- ---------- ----------------
V VIEW T o
a Stun d TABLE
-------
VALID
l l e @ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Zi l
Example of Dependency lic of a Single-Table View on Its Base Table
l o
e example in the slide, table T is created with three columns, COL_A, COL_B, and COL_C.
rcfirst
In the
a
MA view named V is created based on columns COL_A and COL_B of table T. The dictionary views
are queried; view V is dependent on table T and its status is valid.
In the second example in the slide, table T is altered. A new column named COL_D is added. The
dictionary views still report that the view V is dependent because element-based dependency tracking
realizes that the columns COL_A and COL_B are not modified and, therefore, the view does not need
to be invalidated.

Managing Dependencies
CREATE PACKAGE pkg
IS
PROCEDURE p1;
END pkg;
/
CREATE PROCEDURE p
IS
BEGIN
pkg.p1();
END;
/
CREATE OR REPLACE PACKAGE pkg
ble
IS
fe r a
PROCEDURE p1;
ans
PROCEDURE unheard_of;
END pkg; n - t r
/
a no
SELECT status FROM user_objects
h a s ฺ
WHERE object_name = 'P';
ฺ a r) uide
STATUS
ฺ c om ent G
--------
a on tud
VALID
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Example of Dependency lic of a PL/SQL Program Unit on a PL/SQL Program Unit
e l o
a rcexample
In the in the slide, you create a package named PKG that has a call to procedure P1. Another
Mprocedure named P invokes PKG.P1. The definition of the package PKG is modified and another
subroutine is added to the package declaration. When you query the USER_OBJECTS dictionary
view for the status of the P package, it is still valid because the element you added to the definition
of PKG is not referenced through procedure P.

Usage Guidelines to Reduce Invalidation
Original: Partial invalidation:

CREATE OR REPLACE PACKAGE CREATE OR REPLACE PACKAGE

PACK1 IS PACK1 IS
FUNCTION FUN1 RETURN VARCHAR2; FUNCTION FUN1 RETURN VARCHAR2;
FUNCTION FUN2 RETURN VARCHAR2; FUNCTION FUN2 RETURN VARCHAR2;
PROCEDURE PR1 (V1 VARCHAR2); FUNCTION FUN3
FUNCTION FUN3 RETURN
RETURN VARCHAR2;
VARCHAR2;
END; PROCEDURE PR1 (V1 VARCHAR2);
PROCEDURE PR2 (V1 VARCHAR2);
ble
No invalidation: END;
fe r a
ans
CREATE OR REPLACE PACKAGE
n - t r
no
PACK1 IS
FUNCTION FUN1 RETURN VARCHAR2; a
s ฺ
h a
FUNCTION FUN2 RETURN VARCHAR2;
ฺ a r) uide
om ent G Insert at the end.
PROCEDURE PR1 (V1 VARCHAR2);
PROCEDUREPR2
PR2(V1
(V1VARCHAR2);
VARCHAR2); ฺ c Recommended:
on tud
PROCEDURE
END; a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
l
Zi to Reduce
Usage Guidelines lic Invalidation
l o
ce items to the end of a package to avoid changing slot numbers or entry point numbers of
• rAdd
a
M existing top-level elements.
• Avoid SELECT *, table%rowtype, and INSERT with no column names in PL/SQL units
to allow for the ADD COLUMN functionality without invalidation.
• Use views or synonyms to provide a layer of indirection between PL/SQL code and tables. The
CREATE OR REPLACE VIEW command does not invalidate views and PL/SQL dependents if
the view’s new rowtype matches the old rowtype (this behavior is available in Oracle
Database 10g Release 2).
• Likewise, the CREATE OR REPLACE SYNONYM command does not invalidate PL/SQL
dependents if the old table and the new table have the same rowtype and privilege grants.
Views and synonyms enable you to evolve tables independent of code in your application.

Invisible Index: Overview
Use index Do not use index

Optimizer view point
VISIBLE INVISIBLE
Index Index
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE
ble
fe r a
ans
Data view point n - t r
a no
h a s ฺ
ฺ a r) uide
Update index
ฺ c om eindex
Update
n tG
Update table
a on tud Update table
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Invisible Index:
l
Zi Overviewlic
l o
rce with Release 11g, you can create invisible indexes. An invisible index is an index that is
Beginning
a
Mignored by the optimizer unless you explicitly set the OPTIMIZER_USE_INVISIBLE_INDEXES
initialization parameter to TRUE at the session or system level. The default value for this parameter is
FALSE.
Making an index invisible is an alternative to making it unusable or dropping it. Using invisible
indexes, you can do the following:
• Test the removal of an index before dropping it.
• Use temporary index structures for certain operations or modules of an application without
affecting the overall application.
Unlike unusable indexes, an invisible index is maintained during DML statements.

Invisible Indexes: Examples
• Index is altered as not visible to the optimizer:

ALTER INDEX ind1 INVISIBLE;
• Optimizer does not consider this index:

SELECT /*+ index(TAB1 IND1) */ COL1 FROM TAB1 WHERE …;
ble
fe r a
• Optimizer will always consider the index:
ans
n - t r
ALTER INDEX ind1 VISIBLE;
a no
h a s ฺ
• Creating an index as invisible initially: ฺ a r) uide
ฺ c om ent G
CREATE INDEX IND1 ON TAB1(COL1)
a on tINVISIBLE;
ud
@
le this S
ฺ z i l
e loCopyright u e
s2009,
l e (m ense
l
Zi Examples
Invisible Indexes: lic
l o
When
a rcean index is invisible, the optimizer generates plans that do not use the index. If there is no
Mdiscernible drop in performance, you can then drop the index. You can also create an index initially
as invisible, perform testing, and then determine whether to make the index visible.
You can query the VISIBILITY column of the *_INDEXES data dictionary views to determine
whether the index is VISIBLE or INVISIBLE.
Note: For all the statements given in the slide, it is assumed that
OPTIMIZER_USE_INVISIBLE_INDEXES is set to FALSE.

Adaptive Cursor Sharing: Overview
• Adaptive Cursor Sharing allows for intelligent cursor

sharing only for statements that use bind variables.
• Adaptive Cursor Sharing is used to compromise
between cursor sharing and optimization.
• Adaptive Cursor Sharing benefits:
– Automatically detects when different executions would le
a b
benefit from different execution plans
s f er
– Limits the number of generated child cursors to -atran
minimum n on
s a off
– Automated mechanism that cannot be h aturned
ฺ
ui values
a allGbind r) de
mฺfor
One plan not always appropriate
co ent
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Adaptive Cursor
l
Zi Sharing:lic Overview
e l o
a rcvariables
Bind were designed to allow the Oracle database server to share a single cursor for multiple
MSQL statements to reduce the amount of shared memory used to parse SQL statements. However,
cursor sharing and SQL optimization are two conflicting goals. Writing a SQL statement with literals
provides more information for the optimizer and naturally leads to better execution plans, while
increasing memory and CPU overhead caused by excessive hard parses. Oracle9i Database was the
first attempt to introduce a compromising solution by allowing similar SQL statements using
different literal values to be shared. For statements using bind variables, Oracle9i also introduced the
concept of bind peeking. Using bind peeking, the optimizer looks at the bind values the first time the
statement is executed. It then uses these values to determine an execution plan that will be shared by
all other executions of that statement. To benefit from bind peeking, it is assumed that cursor sharing
is intended and that different invocations of the statement are supposed to use the same execution
plan. If different invocations of the statement would significantly benefit from different execution
plans, then bind peeking is of no use in generating good execution plans.
To address this issue as much as possible, Oracle Database 11g introduces Adaptive Cursor Sharing.
This feature is a more sophisticated strategy designed to not share the cursor blindly, but generate
multiple plans per SQL statement with bind variables if the benefit of using multiple execution plans
outweighs the parse time and memory usage overhead. However, because the purpose of using bind
variables is to share cursors in memory, a compromise must be found regarding the number of child
cursors that need to be generated.
Adaptive Cursor Sharing: Architecture
Bind-sensitive cursor
System 1
observes SELECT * FROM emp WHERE sal = :1 and dept = :2
statement
for a while. Bind-aware cursor

Initial selectivity cube Same selectivity cube No need
Initial plan
for new plan
GB S
o GB
HJ f
t HJ
HJ
0.0025 . P
a
0.003 . HJ 2
r
s
e
0.15 0.18
ble
:1=A & :2=B ⇒ S(:1)=0.15 ∧ S(:2)=0.0025 :1=C & :2=D ⇒ S(:1)=0.18 ∧ S(:2)=0.003
fe r a
an s
Merged selectivity cubes No need
for new plan
Second selectivity cube
- t r
Need new plan
n
H
a GB GB H
a 0.009 .a no GB GB
r
d
.
HJ HJ
r
d
h a s ฺ 3
HJ HJ
4 P 0.004 HJ HJ
P
r ) i d e HJ HJ
a
r
s Cubes merged
m ฺa Gu
a
r
s
e
ฺ c o e
e n t
n
tud& :2=F ⇒ S(:1)=0.3 ∧ S(:2)=0.009
0.28 0.3
ao S:1=E
:1=G & :2=H ⇒ S(:1)=0.28 ∧ S(:2)=0.004
@
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Adaptive Cursor
l
Zi Sharing: lic Architecture
l o
rceAdaptive Cursor Sharing, the following steps take place in the scenario illustrated in the slide:
Using
a
M 1. The cursor starts its life with a hard parse, as usual. If bind peeking takes place, and a histogram
is used to compute selectivity of the predicate containing the bind variable, then the cursor is
marked as a bind-sensitive cursor. In addition, some information is stored about the predicate
containing the bind variables, including the predicate selectivity. In the slide example, the
predicate selectivity that would be stored is a cube centered around (0.15,0.0025). Because of
the initial hard parse, an initial execution plan is determined using the peeked binds. After the
cursor is executed, the bind values and the execution statistics of the cursor are stored in that
cursor.
During the next execution of the statement when a new set of bind values is used, the system
performs a usual soft parse, and finds the matching cursor for execution. At the end of
execution, execution statistics are compared with the ones currently stored in the cursor. The
system then observes the pattern of the statistics over all previous runs (see V$SQL_CS_…
views on next slide) and decides whether or not to mark the cursor as bind-aware.
2. On the next soft parse of this query, if the cursor is now bind-aware, bind-aware cursor matching
is used. Suppose that the selectivity of the predicate with the new set of bind values is now
(0.18,0.003). Because selectivity is used as part of bind-aware cursor matching, and because the
selectivity is within an existing cube, the statement uses the existing child cursor’s execution
plan to run.

Adaptive Cursor Sharing: Architecture (continued)
3. On the next soft parse of this query, suppose that the selectivity of the predicate with the new set
of bind values is now (0.3,0.009). Because that selectivity is not within an existing cube, no
child cursor match is found. So the system does a hard parse, which generates a new child cursor
with a second execution plan in that case. In addition, the new selectivity cube is stored as part
of the new child cursor. After the new child cursor executes, the system stores the bind values
and execution statistics in the cursor.
4. On the next soft parse of this query, suppose that the selectivity of the predicate with the new set
of bind values is now (0.28,0.004). Because that selectivity is not within one of the existing
cubes, the system does a hard parse. Suppose that this time, the hard parse generates the same
execution plan as the first one. Because the plan is the same as the first child cursor, both child
cursors are merged. That is, both cubes are merged into a new bigger cube, and one of the child
cursors is deleted. The next time there is a soft parse, if the selectivity falls within the new cube,
the child cursor will match. e
a bl
f e r
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Adaptive Cursor Sharing Views
The following views provide information about Adaptive

Cursor Sharing usage:
V$SQL Two new columns show whether a
cursor is bind-sensitive or bind-
aware.
Shows the distribution of the

V$SQL_CS_HISTOGRAM
bl e
execution count across the execution
history histogram. fe r a
t r a ns
V$SQL_CS_SELECTIVITY Shows the selectivity cubes
o n - stored for
every predicate containing
a n a bind
variable and whose s
a eselectivity
hsharing ฺ is used
r )
ฺa Guid
in the cursor checks.
cShowsm
o eexecution n t
V$SQL_CS_STATISTICS
o n ฺ d
statistics of a cursor
@ a Stu using different bind sets.
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Adaptive Cursor
l
Zi Sharing lic Views
l o
rceviews determine whether a query is bind-aware or not, and is handled automatically, without
These
a
Many user input. However, information about what is going on is exposed through V$ views so that the
DBA can diagnose any problems. Two new columns have been added to V$SQL:
• IS_BIND_SENSITIVE: Indicates if a cursor is bind-sensitive; value YES | NO. A query for
which the optimizer peeked at bind variable values when computing predicate selectivities and
where a change in a bind variable value may lead to a different plan is called bind-sensitive.
• IS_BIND_AWARE: Indicates if a cursor is bind-aware; value YES | NO. A cursor in the cursor
cache that has been marked to use bind-aware cursor sharing is called bind-aware.
V$SQL_CS_HISTOGRAM: Shows the distribution of the execution count across a three-bucket
execution history histogram.
V$SQL_CS_SELECTIVITY: Shows the selectivity cubes or ranges stored in a cursor for every
predicate containing a bind variable and whose selectivity is used in the cursor sharing checks. It
contains the text of the predicates and the selectivity range low and high values.
V$SQL_CS_STATISTICS: Adaptive Cursor Sharing monitors execution of a query and collects
information about it for a while, and uses this information to decide whether to switch to using bind-
aware cursor sharing for the query. This view summarizes the information that it collects to make this
decision: for a sample of executions, it keeps track of rows processed, buffer gets, and CPU time.
The PEEKED column has the value YES if the bind set was used to build the cursor, and NO
otherwise.
Interacting with Adaptive Cursor Sharing
• CURSOR_SHARING:
– If CURSOR_SHARING <> EXACT, then statements
containing literals may be rewritten using bind variables.
– If statements are rewritten, Adaptive Cursor Sharing may
apply to them.
• SQL Plan Management (SPM):
le
– If OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is set toerab
TRUE, then only the first generated plan is used. ans
f
– As a workaround, set this parameter to FALSE, o n -tr run
and
your application until all plans are loaded s ainnthe cursor
cache. r ) ha deฺ
m ฺa Gui
– Manually load the cursor cache
n ฺ co into
e n t the corresponding
plan baseline. ao tud
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
l
Zi Adaptive
Interacting with lic Cursor Sharing
l o
ce Cursor Sharing is independent of the CURSOR_SHARING parameter. The setting of
• rAdaptive
a
M this parameter determines whether literals are replaced by system-generated bind variables. If
they are, then Adaptive Cursor Sharing behaves just as it would if the user supplied binds to
begin with.
• When using the SPM automatic plan capture, the first plan captured for a SQL statement with
bind variables is marked as the corresponding SQL plan baseline. If another plan is found for
that same SQL statement (which may be the case with Adaptive Cursor Sharing), it is added to
the SQL statements plan history and marked for verification: It will not be used. So even though
Adaptive Cursor Sharing has come up with a new plan based on a new set of bind values, SPM
does not let it be used until the plan has been verified. Thus reverting back to10g behavior, only
the plan generated based on the first set of bind values will be used by all subsequent executions
of the statement. One possible workaround is to run the system for some time with automatic
plan capture set to false, and after the cursor cache has been populated with all of the plans a
SQL statement with bind will have, load the entire plan directly from the cursor cache into the
corresponding SQL plan baseline. By doing this, all the plans for a single SQL statement are
marked as SQL baseline plans by default.

SQL Query Result Cache: Overview
• Cache the result of a query or query block for future

reuse.
• Cache is used across statements and sessions unless
it is stale.
• Benefits:
– Scalability e
r a bl
– Reduction of memory usage s fe
• Good candidate statements: - t r an
SQL
nno
– Access many rows Query Result a
Cache
h a s ฺ
– Return few rows r) ui3de
2
SELECT ฺ a SELECT
Session 1
ฺ c…
om ent G … Session 2
a on tud 1
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Cache:
SQL Query Result lic Overview
l o
ce query result cache enables explicit caching of query result sets and query fragments in
TherSQL
a
Mdatabase memory. A dedicated memory buffer stored in the shared pool can be used for storing and
retrieving the cached results. The query results stored in this cache become invalid when data in the
database objects being accessed by the query is modified.
Although the SQL query cache can be used for any query, good candidate statements are the ones
that need to access a very high number of rows to return only a fraction of them. This is mostly the
case for data warehousing applications.
In the graphic shown in the slide, if the first session executes a query, it retrieves the data from the
database and then caches the result in the SQL query result cache. If a second session executes the
exact same query, it retrieves the result directly from the cache instead of using the disks.
Note
• Each node in a RAC configuration has a private result cache. Results cached on one instance
cannot be used by another instance. However, invalidations work across instances. To handle all
synchronization operations between RAC instances related to the SQL query result cache, the
special RCBG process is used on each instance.
• With parallel query, an entire result can be cached (in RAC it is cached on query coordinator
instance) but individual parallel query processes cannot use the cache.

Setting Up SQL Query Result Cache
Set at database level using the RESULT_CACHE_MODE

initialization parameter. Values:
• MANUAL: Use the RESULT_CACHE hint to specify results
to be stored in the cache.
• FORCE: All results are stored in the cache.
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi QuerylicResult Cache
Setting Up SQL
l o
ce optimizer manages the result cache mechanism depending on the settings of the
Therquery
a
MRESULT_CACHE_MODE parameter in the initialization parameter file.
You can use this parameter to determine whether or not the optimizer automatically sends the results
of queries to the result cache. You can set the RESULT_CACHE_MODE parameter at the system, and
session levels. The possible parameter values are MANUAL and FORCE:
• When set to MANUAL (the default), you must specify, by using the RESULT_CACHE hint, that a
particular result is to be stored in the cache.
• When set to FORCE, all results are stored in the cache.
Note: For the FORCE setting, if the statement contains a [NO_]RESULT_CACHE hint, then the hint
takes precedence over the parameter setting.

Managing the SQL Query Result Cache
Use the following initialization parameters:

• RESULT_CACHE_MAX_SIZE
– It sets the memory allocated to the result cache.

– Result cache is disabled if you set the value to 0.
– Default is dependent on other memory settings:
— 0.25% of MEMORY_TARGET or
— 0.5% of SGA_TARGET or
1% of SHARED_POOL_SIZE
—
ble
– Cannot be greater than 75% of shared pool
fe r a
• RESULT_CACHE_MAX_RESULT ans
n - t r
– Sets maximum cache memory for a single result o
n
– Defaults to 5% sa ha deฺ
• ar)
RESULT_CACHE_REMOTE_EXPIRATION
m ฺ G u i
– Sets the expiry time for cached
n ฺ coresults e n t
depending on remote
database objects
@ ao Stud
– Defaults to 0
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Managing the
l
ZiSQL Querylic Results Cache
l o
e alter various parameter settings in the initialization parameter file to manage the SQL query
Yourccan
a
Mresult cache of your database.
By default, the database server allocates memory for the result cache in the Shared Pool inside the
SGA. The memory size allocated to the result cache depends on the memory size of the SGA as well
as the memory management system. You can change the memory allocated to the result cache by
setting the RESULT_CACHE_MAX_SIZE parameter. The result cache is disabled if you set its value
to 0. The value of this parameter is rounded to the largest multiple of 32 KB that is not greater than
the specified value. If the rounded value is 0, then the feature is disabled.
Use the RESULT_CACHE_MAX_RESULT parameter to specify the maximum amount of cache
memory that can be used by any single result. The default value is 5%, but you can specify any
percentage value between 1 and 100. This parameter can be implemented at the system and session
level.
Use the RESULT_CACHE_REMOTE_EXPIRATION parameter to specify the time (in number of
minutes) for which a result that depends on remote database objects remains valid. The default value
is 0, which implies that results using remote objects should not be cached. Setting this parameter to a
nonzero value can produce stale answers: for example, if the remote table used by a result is
modified at the remote database.

Using the RESULT_CACHE Hint
EXPLAIN PLAN FOR
SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)
FROM employees
GROUP BY department_id;
--------------------------------------------------------------
| Id | Operation | Name |Rows
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 11
| 1 | RESULT CACHE | 8fpza04gtwsfr6n595au15yj4y | bl e
| 2 | HASH GROUP BY | fe
| s11
r a
a n
| 3 | TABLE ACCESS FULL| EMPLOYEES
o n -tr | 107
--------------------------------------------------------------
s an
SELECT /*+ NO_RESULT_CACHE */ department_id, r ) haAVG(salary)
d e ฺ
ฺa Gu i
FROM employees
c o m n t
n ฺ e
GROUP BY department_id;
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Using the Result_Cache lic Hint
l o
rcewant to use the query result cache and the RESULT_CACHE_MODE initialization parameter is
If you
a
Mset to MANUAL, you must explicitly specify the RESULT_CACHE hint in your query. This introduces
the ResultCache operator into the execution plan for the query. When you execute the query, the
ResultCache operator looks up the result cache memory to check whether the result for the query
already exists in the cache. If it exists, then the result is retrieved directly out of the cache. If it does
not yet exist in the cache, then the query is executed, the result is returned as output, and is also
stored in the result cache memory.
If the RESULT_CACHE_MODE initialization parameter is set to FORCE, and you do not want to store
the result of a query in the result cache, you must then use the NO_RESULT_CACHE hint in your
query. For example, when the RESULT_CACHE_MODE value equals FORCE in the initialization
parameter file, and you do not want to use the result cache for the EMPLOYEES table, then use the
NO_RESULT_CACHE hint.
Note: Use of the [NO_]RESULT_CACHE hint takes precedence over the parameter settings.

In-Line View: Example
SELECT prod_subcategory, revenue

FROM (SELECT /*+ RESULT_CACHE */ p.prod_category,
p.prod_subcategory,
sum(s.amount_sold) revenue
FROM products p, sales s
WHERE s.prod_id = p.prod_id and
s.time_id BETWEEN to_date('01-JAN-2006','dd-MON-yyyy')
and
ble
to_date('31-DEC-2006','dd-MON-yyyy')
fe r a
GROUP BY ROLLUP(p.prod_category, p.prod_subcategory))
ans
WHERE prod_category = 'Women';
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
i l
In-Line View:ZExample lic
e l o
a rcexample
In the given in the slide, the RESULT_CACHE hint is used in the in-line view. In this case,
Mthe following optimizations are disabled: view merging, predicate push-down, and column
projection. This is at the expense of the initial query, which might take a longer time to execute.
However, subsequent executions will be much faster because of the SQL query cache. The other
benefit in this case is that similar queries (queries using a different predicate value for
PROD_CATEGORY in the last WHERE clause) will also be much faster.

11.2
Using Table Annotation to Control Result Caching

• Use the RESULT_CACHE clause to control result

caching:
– MODE DEFAULT
– MODE FORCE
• Statement hints can be used to override the setting
• RESULT_CACHE column of the DBA_, ALL_, and e
r a bl
USER_TABLES displays result cache mode. fe
ans
n - t r
n o
CREATE TABLE sales (...) RESULT_CACHE (MODE DEFAULT); a
s ฺ
h a
ALTER TABLE sales RESULT_CACHE (MODE FORCE);
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using TableZ i l
Annotation lic to Control Result Caching
l o
rce Database 11g Release 2, you can use table annotations to control result caching. Table
In Oracle
a
Mannotations are in effect only for the whole query, not for query segments. The primary benefit of
this feature is eliminating the need of adding result cache hints to queries at the application level.
RESULT_CACHE table annotation values are as follows:
• DEFAULT: If at least one table in a query is set to DEFAULT, result caching is not enabled at the
table level for this query, unless the RESULT_CACHE_MODE initialization parameter is set to
FORCE or the RESULT_CACHE hint is specified. This is the default value.
• FORCE: If all the tables of a query are marked as FORCE, the query result is considered for
caching. The FORCE table annotation takes precedence over the RESULT_CACHE_MODE
parameter value of MANUAL set at the session level.
A table annotation has a lower precedence than a SQL hint. You can override table and session
settings by using hints at the query level.
Query the RESULT_CACHE column of the DBA_, ALL_, and USER_TABLES data dictionary views
to determine the result cache mode of the table.

Using the DBMS_RESULT_CACHE Package
Use the DBMS_RESULT_CACHE package to:

• Manage memory allocation for the query result cache
• View the status of the cache:
SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;
• Retrieve statistics on the cache memory usage:
EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT; ble
fe r a
s
ran
• Remove all existing results and clear cache memory:
n -t
o
an
EXECUTE DBMS_RESULT_CACHE.FLUSH;
• Invalidate cached results dependinghon s
a specified
ฺ
r ) i d e
object: m ฺa Gu
ฺ c o e n t
n
ao Stud
EXEC DBMS_RESULT_CACHE.INVALIDATE('JFV','MYTAB');
l @
le this
ฺ z i
e loCopyright u e
s2009,
l e (m ense
Zi l lic
Using the DBMS_RESULT_CACHE Package
l o
a ce
TherDBMS_RESULT_CACHE package provides statistics, information, and operators that enable you
Mto manage memory allocation for the query result cache. You can use the DBMS_RESULT_CACHE
package to perform various operations such as viewing the status of the cache (OPEN or CLOSED),
retrieving statistics on the cache memory usage, and flushing the cache. For example, to view the
memory allocation statistics, use the following SQL procedure:
SQL> set serveroutput on
SQL> execute dbms_result_cache.memory_report
R e s u l t C a c h e M e m o r y R e p o r t
[Parameters]
Block Size = 1024 bytes
Maximum Cache Size = 720896 bytes (704 blocks)
Maximum Result Size = 35840 bytes (35 blocks)
[Memory]
Total Memory = 46284 bytes [0.036% of the Shared Pool]
... Fixed Memory = 10640 bytes [0.008% of the Shared Pool]
... State Object Pool = 2852 bytes [0.002% of the Shared Pool]
... Cache Memory = 32792 bytes (32 blocks) [0.025% of the Shared Pool]
....... Unused Memory = 30 blocks
....... Used Memory = 2 blocks
........... Dependencies = 1 blocks
........... Results = 1 blocks
............... SQL = 1 blocks
Note: For more information, refer to the PL/SQL Packages and Types Reference Guide.
Viewing SQL Result Cache Dictionary Information
The following views provide information about the query

result cache:
(G)V$RESULT_CACHE_STATISTICS Lists the various cache settings and
memory usage statistics
(G)V$RESULT_CACHE_MEMORY Lists all the memory blocks and the

corresponding statistics
ble
fe r a
(G)V$RESULT_CACHE_OBJECTS Lists all the objects (cached results
ans
t
and dependencies) along with their
n - r
attributes
a no
(G)V$RESULT_CACHE_DEPENDENCY Lists the dependency h a s ฺdetails between
the cached a r) results e dependencies
idand
ฺ u
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Note Zi l lic
l o
ce information, see the Oracle Database Reference guide.
Forrfurther
a
M

SQL Query Result Cache: Considerations
• Result cache is disabled for queries containing:

– Temporary or dictionary tables
– Nondeterministic PL/SQL functions
– Sequence CURRVAL and NEXTVAL
– SQL functions CURRENT_DATE, SYSDATE, SYS_GUID, and
so on
• DML/DDL on remote database does not expire cached rabl
e
results. n s fe
• Flashback queries can be cached. n - tra
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
Note
el oZ
Anyrcuser-written function used in a function-based index must have been declared with the
a
MDETERMINISTIC keyword to indicate that the function will always return the same output value
for any given set of input argument values.

SQL Query Result Cache: Considerations
• Result cache does not automatically release memory.

– It grows until maximum size is reached.
– DBMS_RESULT_CACHE.FLUSH purges memory.
• Bind variables
– Cached result is parameterized with variable values.
– Cached results can only be found for the same variable
a b le
values. fer s
• Cached result will not be built if: - t r an
no(read n
– Query is built on a noncurrent version of data
a
consistency enforcement) h a s ฺ
– Current session has outstanding ฺ a r) uide on tables in
transaction
query ฺ c om ent G
n d ao Stu
l @
le this
ฺ z i
e loCopyright u e
s2009,
l e (m ense
i l lic
Note
oZ
elpurge works only if the cache is not in use; disable (close) the cache for flush to succeed.
c
• rThe
Ma• With bind variables, cached result is parameterized with variable values. Cached results can be
found only for the same variable values. That is, different values or bind variable names cause
cache miss.
• The result cache is also flushed when you flush the shared pool.

Quiz
Choose from the following types of SQL statements the

one that is a good candidate for SQL query cache:
1. Accesses a very high number of rows and returns a
large number of them
2. Accesses a very high number of rows and returns a
small number of them le
a b
3. Accesses a very high number of rows and returns all s f er
n
of them -tra on
a n
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer: 2 Zi
l lic
l o
a rce
M

OCI Client Query Cache
• Extends server-side query caching to client-side

memory
• Ensures better performance by eliminating round-trips
to the server
• Leverages client-side memory
• Improves server scalability by saving server CPU
a b le
resources s f er
t r n
aset
• Result cache automatically refreshed if the result
n - is
o
changed on the server
s an
• Particularly good for lookup tablesr) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
Zi Cache
OCI Client Query lic
l o
e enable caching of query result sets in client memory with Oracle Call Interface (OCI) Client
Yourc
can
a
MQuery Cache in Oracle Database 11g.
The cached result set data is transparently kept consistent with any changes done on the server side.
Applications leveraging this feature see improved performance for queries that have a cache hit.
Additionally, a query serviced by the cache avoids round-trips to the server for sending the query and
fetching the results. Server CPU, which would have been consumed for processing the query, is
reduced thus improving server scalability.
Before using client-side query cache, determine whether your application will benefit from this
feature. Client-side caching is useful when you have applications that produce repeatable result sets,
small result sets, static result sets, or frequently executed queries.
Client and server result caches are autonomous; each can be enabled/disabled independently.
Note: You can monitor the client query cache using the CLIENT_RESULT_CACHE_STATS$ view
or V$CLIENT_RESULT_CACHE_STATS view.

Using Client-Side Query Cache
• You can use client-side query caching by:

– Setting initialization parameters
— CLIENT_RESULT_CACHE_SIZE
— CLIENT_RESULT_CACHE_LAG
– Using the client configuration file
OCI_RESULT_CACHE_MAX_SIZE
—
ble
— OCI_RESULT_CACHE_MAX_RSET_SIZE
fe r a
— OCI_RESULT_CACHE_MAX_RSET_ROWS
ans
n - t r
• Client result cache is then used dependingnon:
o
Tables result cache mode s ฺ a
—
h a
— r) ide
RESULT CACHE hints in your SQLastatements
ฺ u
o m t G
o n ฺc den
@ a Stu
z i l l e t h is
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
Zi Query
Using Client-Side lic Cache
l o
a ce
Therfollowing two parameters can be set in your initialization parameter file:
M • CLIENT_RESULT_CACHE_SIZE: A nonzero value enables the client result cache. This is the
maximum size of the client per-process result set cache in bytes. All OCI client processes get
this maximum size and can be overridden by the OCI_RESULT_CACHE_MAX_SIZE
parameter.
• CLIENT_RESULT_CACHE_LAG: Maximum time (in milliseconds) since the last round-trip to
the server, before which the OCI client query executes a round-trip to get any database changes
related to the queries cached on client.
A client configuration file is optional and overrides the cache parameters set in the server
initialization parameter file. Parameter values can be part of a sqlnet.ora file. When parameter
values shown in the slide are specified, OCI client caching is enabled for OCI client processes using
the configuration file. OCI_RESULT_CACHE_MAX_RSET_SIZE/ROWS denotes the maximum
size of any result set in bytes/rows in the per-process query cache. OCI applications can use
application hints to force result cache storage. This overrides the deployment time settings of ALTER
TABLE/ALTER VIEW. The application hints can be:
• SQL hints /*+ result_cache */, and /*+ no_result_cache */
• OCIStmtExecute() modes. These override SQL hints.
Note: To use this feature, your applications must be relinked with Release 11.1 or higher client
libraries and be connected to a Release 11.1 or higher server.

PL/SQL Function Cache
• Stores function results in cache, making them available

to other sessions
• Uses the Query Result Cache
Cached
exec Calculate(…);
results
First ble
fe r a
query
ans
n - t r
no
BEGIN
exec Calculate(…); exec Calculate(…);
… a
s ฺ
SELECT … h a
FROM table; ฺ a r) uide
…
c m nt G
oSubsequent
END; ฺ
on tuqueries de
a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
PL/SQL Function
l
Zi Cache lic
l o
rcein Oracle Database 11g, you can use the PL/SQL cross-section function result caching
Starting
a
Mmechanism. This caching mechanism provides you with a language-supported and system-managed
means for storing the results of PL/SQL functions in a shared global area (SGA), which is available
to every session that runs your application. The caching mechanism is both efficient and easy to use,
and it relieves you of the burden of designing and developing your own caches and cache
management policies.
Oracle Database 11g provides the ability to mark a PL/SQL function to indicate that its result should
be cached to allow lookup, rather than recalculation, on the next access when the same parameter
values are called. This function result cache saves significant space and time. This is done
transparently using the input parameters as the lookup key. The cache is instancewide so that all
distinct sessions invoking the function benefit. If the result for a given set of parameters changes, you
can use constructs to invalidate the cache entry so that it will be properly recalculated on the next
access. This feature is especially useful when the function returns a value that is calculated from data
selected from schema-level tables. For such uses, the invalidation constructs are simple and
declarative. You can include syntax in the source text of a PL/SQL function to request that its results
be cached and, to ensure correctness, that the cache be purged when any of a list of tables
experiences DML. When a particular invocation of the result-cached function is a cache hit, then the
function body is not executed; instead, the cached value is returned immediately.

11.2
update
Using PL/SQL Function Cache
Include the RESULT_CACHE option in the function

declaration section of a package or function definition.
CREATE OR REPLACE FUNCTION productName

(prod_id NUMBER, lang_id VARCHAR2)
RETURN NVARCHAR2
RESULT_CACHE
IS
bl e
result VARCHAR2(50);
fe r a
BEGIN
ans
SELECT translated_name INTO result
n - t r
no
FROM product_descriptions
WHERE product_id = prod_id AND language_id = lang_id;
a
s ฺ
RETURN result;
h a
END;
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using PL/SQL
l
Zi Function
lic Cache
e l o
a rcexample
In the shown in the slide, the PRODUCTNAME function has result caching enabled through
Mthe RESULT_CACHE option in the function declaration.
Usage Notes
• If function execution results in an unhandled exception, the exception result is not stored in the
cache.
• The body of a result-cached function executes:
- The first time a session on this database instance calls the function with these parameter
values
- When the cached result for these parameter values is invalid.
- When the cached result for these parameter values has aged out. If the system needs
memory, it might discard the oldest cached values.
- When the function bypasses the cache
• The function should not have any side effects.
• The function should not depend on session-specific settings.
• The function should not depend on session-specific application contexts.
Note: In Oracle Database 11g Release 2, the RELIES_ON_CLAUSE (used to specify the data
sources on which the results of the function depend) is deprecated because the database server detects
all data sources that are queried while a result-cached function is running.

PL/SQL Function Cache: Considerations
PL/SQL Function Cache cannot be used when:

• The function is defined in a module that has the
invoker’s rights or in an anonymous block.
• The function is a pipelined table function.
• The function has OUT or IN OUT parameters.
• The function has IN parameter of the following types:
a b le
BLOB, CLOB, NCLOB, REF CURSOR, collection, object, or s f er
record. - t r an
n on
• The function’s return type is: BLOB, CLOB, s aNCLOB, REF
CURSOR, object, record, or collection ) a
hwithdone
e ฺ of the
ฺa r u i
preceding unsupported return omtypes.t G ฺc den
o
a Stun
l l e@ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
i l lic
el oZ
Marc

PL/SQL and Java Native Compilation
Enhancements
• PL/SQL
– PLSQL_CODE_TYPE parameter: NATIVE/INTERPRETED
– No need for C compiler
– No file system DLLs
• Java
– JAVA_JIT_ENABLED parameter: TRUE/FALSE
ble
– JIT “on the fly” compilation fe r a
t r a ns
– Transparent to user (asynchronous, in background)
n -
o
– Code stored to avoid recompilations an s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
PL/SQL andZ
l
i Native
Java lic Compilation Enhancements
l o
rce Native Compilation (PLSQL_CODE_TYPE initialization parameter): The Oracle
PL/SQL
a
Mexecutable generates native dynamic linked libraries (DLLs) directly from the PL/SQL source code
without needing to use a third-party C compiler. In Oracle Database 10g, the DLL is stored
canonically in the database catalog. In Oracle Database 11g, when it is needed, the Oracle executable
loads it directly from the catalog without needing to stage it first on the file system.
The execution speed of natively compiled PL/SQL programs will never be slower than in Oracle
Database 10g and may be improved in some cases by as much as an order of magnitude. The
PL/SQL native compilation is automatically available with Oracle Database 11g. No third-party
software (neither a C compiler nor a DLL loader) is needed.
Java Native Compilation (JAVA_JIT_ENABLED initialization parameter): Enabled by default and
similar to the Java Development Kit JIT (just-in-time), this feature compiles Java in the database
natively and transparently without the need of a C compiler.
The JIT runs as an independent session in a dedicated Oracle server process. There is at most one
compiler session per database instance; it is Oracle RAC-aware and amortized over all Java sessions.
This feature brings two major benefits to Java in the database: increased performance of pure Java
execution in the database and ease of use as it is activated transparently, without the need of an
explicit command, when Java is executed in the database.
As this feature removes the need for a C compiler, there are cost and license savings.

Setting Up and Testing PL/SQL
Native Compilation
1. Set PLSQL_CODE_TYPE to NATIVE:

– ALTER SYSTEM | ALTER SESSION | ALTER … COMPILE
2. Compile your PL/SQL units (example):
CREATE OR REPLACE PROCEDURE hello_native AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Hello world.');
END hello_native; bl e
/
fe r a
t r a ns
ALTER PROCEDURE hello_native COMPILE PLSQL_CODE_TYPE=NATIVE;
o n -
a n
3. Make sure you succeeded: s
ha deฺ
SELECT plsql_code_type
r
ฺa Gui)
FROM all_plsql_object_settings ฺco m n t
n e
WHERE name = 'HELLO_NATIVE'; o
@ a Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Setting Up and
l
Zi Testing licPL/SQL Native Compilation
l o
rceup and test one or more program units through native compilation:
To set
a
M 1. Set up the PLSQL_CODE_TYPE initialization parameter. This parameter determines whether
PL/SQL code is natively compiled or interpreted. The default setting is INTERPRETED, which
is recommended during development. To enable PL/SQL native compilation, set the value of
PLSQL_CODE_TYPE to NATIVE. Make sure that the PLSQL_OPTIMIZE_LEVEL
initialization parameter is not less than 2 (which is the default). You can set
PLSQL_CODE_TYPE at the system, session, or unit level. A package specification and its body
can have different PLSQL_CODE_TYPE settings.
2. Compile one or more program units, using one of these methods:
- Use CREATE OR REPLACE to create or recompile the program unit.
- Use the various ALTER <PL/SQL unit type> COMPILE commands as shown in the slide
example.
- Run one of the SQL*Plus scripts that creates a set of Oracle-supplied packages.
- Create a database using a preconfigured initialization file with
PLSQL_CODE_TYPE=NATIVE.
3. To be sure that the process worked, query the data dictionary to see that a program unit is
compiled for native execution. You can use ALL|USER_PLSQL_OBJECT_SETTINGS views.
The PLSQL_CODE_TYPE column has a value of NATIVE for program units that are compiled
for native execution, and INTERPRETED otherwise.

Recompiling the Entire Database for
PL/SQL Native Compilation
1. Set PLSQL_CODE_TYPE to NATIVE.

2. Shut down the database instance.
3. Start up the database in UPGRADE mode.
4. Execute the dbmsupgnv.sql script.
5. Shut down/start up your database in restricted mode.
6. Execute the utlrp.sql script. ble
fe r a
7. Disable restricted mode. ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
RecompilingZthe
l
i Entire licDatabase for PL/SQL Native Compilation
l o
rcehave DBA privileges, you can recompile all PL/SQL modules in an existing database to
If you
a
MNATIVE or INTERPRETED, using the dbmsupgnv.sql and dbmsupgin.sql scripts,
respectively. To recompile all PL/SQL modules to NATIVE, perform the following steps:
1. Shut down application services, the listener, and the database in NORMAL or IMMEDIATE
mode. The first two are used to make sure that all of the connections to the database have been
terminated.
2. Set PLSQL_CODE_TYPE to NATIVE in the initialization parameter file. The value of
PLSQL_CODE_TYPE does not affect the conversion of the PL/SQL units in these steps.
However, it does affect all subsequently compiled units and it should be explicitly set to the
compilation type that you want.
3. Start up the database in UPGRADE mode, using the UPGRADE option. It is assumed that there
are no invalid objects at this point.
4. Run the $ORACLE_HOME/rdbms/admin/dbmsupgnv.sql script as the SYS user to
update the PLSQL_CODE_TYPE setting to NATIVE in the dictionary tables for all PL/SQL
units. This process also invalidates the units. Use TRUE with the script to exclude package
specifications; FALSE to include the package specifications. The script is guaranteed to
complete successfully or roll back all the changes. Package specifications seldom contain
executable code, so the run-time benefits of compiling to NATIVE are not measurable.

Recompiling the Entire Database for PL/SQL Native Compilation (continued)
5. Shut down the database and restart in NORMAL mode. Oracle recommends that no other sessions
be connected to avoid possible problems. You can ensure this with the following statement:
ALTER SYSTEM ENABLE RESTRICTED SESSION;
6. Run the $ORACLE_HOME/rdbms/admin/utlrp.sql script as the SYS user. This script
recompiles all the PL/SQL modules using a default degree of parallelism.
7. Disable the restricted session mode for the database, and then start the services that you
previously shut down. To disable restricted session mode, use the following statement:
ALTER SYSTEM DISABLE RESTRICTED SESSION;
Note: During the conversion to native compilation, TYPE specifications are not recompiled to
NATIVE because these specifications do not contain executable code.
bl e
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Summary

• Describe online redefinition for tables with materialized
views and view logs
• Create and use invisible indexes
• Describe Adaptive Cursor Sharing
• Use the SQL query result cache a b le
• Use the PL/SQL function cache s f er
n a
o n -tr
n a
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

This practice covers using the result cache.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Backup and Recovery Enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Describe the new and enhanced RMAN features in
Oracle Database 11g
• Duplicate databases directly over the network (without
backups)
• Back up large files in multiple sections
a b le
• Create archival backups for long-term storage s f er
- t r an
• Manage the recovery catalog on
a n
• Describe the use of virtual private catalogs
as
r ) h deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

11.2
Using New SET NEWNAME Clauses
• The new SET NEWNAME clauses enable you to specify a

default name format for all files in a database or in a

named tablespace.
• The default name is used for DUPLICATE, RESTORE, and
SWITCH commands in the RUN block.
• The new SET NEWNAME clauses enable you to set file le
a b
names with a single command rather than setting each
s f er
file name individually. tran n -
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Using New SET l
Zi NEWNAMElic Clauses
l o
rce releases of Oracle Database, you could use the SET NEWNAME command to specify a
In previous
a
Mnew name for a named data file. In Oracle Database 11g Release 2, you can use SET NEWNAME to
specify the default name format for all data files in a named tablespace and all data files in the
database.
The order of precedence for the SET NEWNAME command is as follows:
1. SET NEWNAME FOR DATAFILE and SET NEWNAME FOR TEMPFILE
2. SET NEWNAME FOR TABLESPACE
3. SET NEWNAME FOR DATABASE

11.2
Substitution Variables for SET NEWNAME
Syntax Description
Element
%b Specifies the filename without the directory path *NEW*
%f Specifies the absolute file number of the datafile for which the
new name is generated
%I Specifies the DBID

ble
%N Specifies the tablespace name
fe r a
ans
%U Specifies a system-generated file name of the format: n - t r
data-D-%d_id-%I_TS-%N_FNO-%f
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
i l
SubstitutionZVariables licfor SET NEWNAME
l o
rceissuing SET NEWNAME FOR DATABASE or SET NEWNAME FOR TABLESPACE, you must
When
a
Mspecify substitution variables in the TO <filename> clause to avoid name collisions. Specify at
least one of the following substitution variables: %b, %f, and %U. %I and %N are optional variables.

11.2
Using SET NEWNAME FOR DATABASE

SET NEWNAME FOR DATABASE

TO {NEW|'formatSpec'};
RUN
{
SET NEWNAME FOR DATABASE TO
ble
'/u01/app/oracle/oradata/dupldb/%b';
fe r a
DUPLICATE TARGET DATABASE TO dupldb
ans
LOGFILE
n - t r
GROUP 1 ('/u01/app/oracle/oradata/dupldb/redo01a.log',
a no
'/u01/app/oracle/oradata/dupldb/redo01b.log') SIZE 50M REUSE,
h a s ฺ
'/u01/app/oracle/oradata/dupldb/redo02b.log') SIZE 50M REUSE,ฺ a r) uide
ฺ c om ent G
on tud
'/u01/app/oracle/oradata/dupldb/redo03b.log') SIZE 50M REUSE;
a
}
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Using SET NEWNAME lic DATABASE
FOR
l o
ceSET NEWNAME FOR DATABASE command to set default names for all datafiles in the
Userthe
a
Mdatabase.
Note: You cannot use this command to set default names for temporary datafiles (tempfiles).

11.2
Using SET NEWNAME FOR TABLESPACE

SET NEWNAME FOR TABLESPACE tablespace_name

TO {NEW|'formatSpec'};
RUN
{ ble
SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf'; fe r a
SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf'; ans
SET NEWNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf'; n - t r
SET NEWNAME FOR DATAFILE 4 TO '/oradata4/users01.dbf';
a no
SET NEWNAME FOR TABLESPACE example TO '/oradata5/%b';
h a s ฺ
DUPLICATE TARGET DATABASE TO dupldb;
ฺ a r) uide
}
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi
Using SET NEWNAMEl lic TABLESPACE
FOR
l o
ceSET NEWNAME FOR TABLESPACE command to set default names for all datafiles in the
Userthe
a
Mspecified tablespace.

Performance Enhancements
• Fast incremental backups on physical standby

• Improved block media recovery
Target
Data files database Image copies
Backup pieces ble

fe r a
Change
Backup data
ans
tracking
file
n - t r
Flash Recovery Area
a no
h a s ฺ
ฺ a r) uide
Auxiliary ฺ c om enManager
Recovery t G (RMAN)
database a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
i l
PerformanceZEnhancements lic
l o
rceand recovery operations are a critical part of securing the availability of information, when
Backup
a
Man organization needs it, despite various levels of potential failures and errors. With Oracle Database
11g, the Recovery Manager (RMAN) enhancements provide the following benefits:
Fast Incremental Backups on Physical Standby Database
You can enable block change tracking on a physical standby database (use the existing ALTER
DATABASE ENABLE/DISABLE BLOCK CHANGE TRACKING SQL statement). RMAN will
then track changed blocks during standby managed recovery. This allows the off-loading of block
tracking to the standby database and allows the same fast incremental backups to use the change
tracking files that have been available on the primary. This feature enables faster incremental
backups on a physical standby database than in previous releases.
Note: This feature is part of the Oracle Active Data Guard option.
Improved Block Media Recovery Performance
You can use the RECOVER command (formerly the BLOCKRECOVER command) to recover
individual data blocks. If flashback logging is enabled and contains older, uncorrupted blocks,
RMAN can use these blocks, thereby speeding up block media recovery.

Improved Block Corruption Detection
• Improved protection by enhanced block corruption

detection
• Use V$DATABASE_BLOCK_CORRUPTION to view live
block corruptions
• Enhancements to VALIDATE command:
– VALIDATE … BLOCK e
r a bl
– VALIDATE DATABASE
s fe
- t r an
n no
a
s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Improved Block
l
Zi Corruption
lic Detection
l o
rce to the RMAN-detected block corruptions, Oracle Database 11g also records live block
In addition
a
Mcorruptions that can seen in the V$DATABASE_BLOCK_CORRUPTION view. The Oracle database
automatically updates this view when block corruptions are detected or repaired.
The VALIDATE command is enhanced with many new options such as VALIDATE ... BLOCK
and VALIDATE DATABASE.

11.2
Using New Settings for Binary Compression

CONFIGURE COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/DEFAULT'
run {
SET COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/DEFAULT';
ble
..
fe r a
}
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Using New Settings licBinary Compression of Backup Sets
for
l o
rce Database 11g Release 2, the values for the COMPRESSION ALGORITHM clause have
In Oracle
a
Mchanged to HIGH, MEDIUM, LOW, and DEFAULT. Additional information about each is provided on
the following page.
Note: In Oracle Database 11g Release 1, ZLIB and BZIP2 were the supported algorithms for binary
compression of backup sets. The algorithm names were supplied via the COMPRESSION
ALGORITHM clause.

11.2
Using New Compression Algorithm Settings
Setting Description Requires Advanced

Compression Option
LOW Less compression than MEDIUM
Consumes the least CPU
MEDIUM Less compression than HIGH

Consumes less CPU than HIGH
HIGH Best compression ratio

ble
Consumes the most CPU fe r a
ans
DEFAULT Compression ratio between
n - t r
MEDIUM and HIGH
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Using New Compression lic Algorithm Settings
l o
rce Database 11g Release 2, binary compression of backup sets is supported with the algorithm
In Oracle
a
Msettings as shown above. All modes except DEFAULT require the Oracle Advanced Compression
Database option.
Choose the appropriate mode for your configuration by performing comparative testing.
Compression ratio and performance can vary depending on factors such as data type, available CPU
resources, and network bandwidth.

Optimized Backups
• Optimized undo backup for automatically reduced

backup time and storage
• Flexibility to use VSS-enabled software
– Allows the database server to participate in snapshots
coordinated by VSS-compliant backup management tools and
storage products
– Database automatically recovered upon snapshot restore via
a b le
r
RMAN sfe n
n - tra
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Optimized Backups lic
l o
rce Undo Backup
Optimized
a
M Undo data that is not needed for transaction recovery (for example, for committed transactions), is
not backed up. The benefit is reduced overall backup time and storage by not backing up undo that
applies to committed transactions. This optimization is automatically enabled.
Integration with VSS-Enabled Applications
The Volume Shadow Copy Service (VSS) is an infrastructure on Windows. The Oracle VSS Writer
is integrated with VSS-enabled applications. So you can use VSS-enabled software and storage
systems to back up and restore an Oracle database. A key benefit is the ability to make a shadow
copy of an open database. You can also use the BACKUP INCREMENTAL LEVEL 1 ... FROM SCN
command in RMAN to make an incremental backup of a VSS shadow copy.

Optimized Backups
• Simplified archive log management in a multiple-

component environment
• Increased availability by failover of backup to optional
destinations
Target ble
Data files database Image copies
fe r a
ans
Archive X
Backup pieces
n - t r
Redundant
log files
Backup dataa no
archive log
h a s ฺ
files
r) uidArea
Flash Recovery
a e
ฺ
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Optimized Backups lic
(continued)
l o
rce Archive Log Management in a Multiple-Component Environment
Simplified
a
MThis feature simplifies archive log management when used by multiple components. It also increases
availability when backing up archive logs, when an archive log in the Flash Recovery Area is
missing or inaccessible.
Enhanced Configuration of Deletion Policies
Archived redo logs are eligible for deletion only when not needed by any required components such
as Data Guard, Streams, Flashback Database, and so on.
In a Data Guard environment, all standby destinations are considered (instead of just mandatory
destinations), before marking archive logs to be deleted. This configuration is specified using the
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY command.
When you configure an archived log deletion policy, the configuration applies to all archiving
destinations, including the Flash Recovery Area. Both BACKUP ... DELETE INPUT and DELETE...
ARCHIVELOG use this configuration, as does the Flash Recovery Area.
When you back up the recovery area, RMAN can fail over to other archived redo log destinations if
the archived redo log in the Flash Recovery Area is inaccessible or corrupted.

Parallel Backup and Restore for Very Large Files
Multisection backups of a single file:

• Are created by RMAN, with your specified size value
• Are processed independently (serially or in parallel)
• Produce multipiece backup sets
• Improve performance of the backup
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Parallel Backup
l
Zi and Restore
lic for Very Large Files
l o
rcedata files can be up to 128 TB in size. In prior versions, the smallest unit of RMAN backup
Oracle
a
Mwas an entire file. This is not practical with such large files. In Oracle Database 11g, the workload for
each file is distributed among multiple parallel server processes. RMAN can break up a single large
file into sections and back up and restore these sections independently, if you specify the SECTION
SIZE option. In other words, RMAN can use multiple channels per file. Each channel backs up one
file section.
Each file section is a contiguous range of blocks in a file. Each file section can be processed
independently, either serially or in parallel. Backing up a file in separate sections can both improve
the performance and allow large file backups to be restarted.
A multisection backup job produces a multipiece backup set. Each piece contains one section of the
file. All sections of a multisection backup, except perhaps for the last section, are of the same size.
There are a maximum of 256 sections per file.
Tip: You should not apply large values of parallelism to back up a large file that resides on a small
number of disks.
This feature is built into RMAN. No installation is required beyond the normal installation of the
Oracle Database 11g. COMPATIBLE must be set to at least 11.0, because earlier releases cannot
restore multisection backups.

Using RMAN Multisection Backups
The BACKUP and VALIDATE DATAFILE commands option:
SECTION SIZE <integer> [K|M|G]
Channel 1
Section 1
ble
Channel 2 fe r a
Section 2 ans
n - t r
Channel 3 a no
Section 3
h a s ฺ
Channel ฺ a r4) uide
Section 4
ฺ c om ent G
One large data a on tud
file
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
i l
Using RMANZMultisection lic Backups
l o
ce and VALIDATE DATAFILE commands accept a new option:
TherBACKUP
a
M SECTION SIZE <integer> [K|M|G]
Specify your planned size for each backup section. The option is both a backup-command and
backup-spec level option, so that you can apply different section sizes to different files in the same
backup job.
Viewing metadata about your multisection backup:
• The V$BACKUP_SET and RC_BACKUP_SET views have a MULTI_SECTION column, which
indicates whether this is a multisection backup or not.
• The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views have a SECTION_SIZE
column, which specifies the number of blocks in each section of a multisection backup. Zero
means a whole-file backup.

Quiz
In Oracle Database 11g Release 2, you can use SET

NEWNAME to specify the default name format for which of

the following:
1. All datafiles in the specified tablespace
2. All datafiles in the database
3. A named datafile
a b le
4. All of the above s f er
n a
o n -tr
na
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer: 4 Zi
l lic
l o
a rce
M

Duplicating a Database
• With network (no backups required)

• Including customized SPFILE
• Via Enterprise Manager or RMAN command line
ble
fe r a
Destination or
t r a ns
on-
AUXILIARY database
TCP/IP
s an
r ) ha deฺ
m ฺa Gui
Active source databaseonฺ
co ent
@ a Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Duplicating Z i l
a Database lic
l o
rctoeOracle Database 11g, you could create a database for testing or a standby database by using
Prior
a
Mthe RMAN duplicate database feature. It required the source database, a copy of a backup on the
destination system, and the destination database itself.
Oracle Database 11g greatly simplifies this process. You can instruct the source database server to
perform online image copies and archived log copies directly to the auxiliary instance, by using
Enterprise Manager or the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE
command. Preexisting backups are no longer needed.
The database files are copied from the source to a destination or AUXILIARY instance via an inter-
instance network connection. RMAN then uses a “memory script” (one that is contained only in
memory) to complete recovery and open the database.

Performing Active Database Duplication
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Database
Performing Active lic Duplication
l o
rceNotes for Active Database Duplication
Usage
a
M • Oracle Net must be aware of the source and destination databases. The FROM ACTIVE
DATABASE clause implies network action.
• If the source database is open, it must have archive logging enabled.
• If the source database is in mounted state (and not a standby), the source database must have
been shut down cleanly.
• Availability of the source database is not affected by active database duplication. But the source
database instance provides CPU cycles and network bandwidth.
Enterprise Manager Interface
In Enterprise Manager, select Data Movement > Clone Database.

The RMAN DUPLICATE Command
DUPLICATE TARGET DATABASE

TO dbtest
FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '/u01', '/u02'
SET SGA_MAX_SIZE = '200M'
SET SGA_TARGET = '125M'
ble
SET LOG_FILE_NAME_CONVERT = '/u01','/u02'
fe r a
ans
SET DB_FILE_NAME_CONVERT = '/u01','/u02';
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
The RMAN DUPLICATE licCommand
l o
ce assumes that you have previously connected to both the source and the destination
Therexample
a
Minstances, which have a common directory structure but different top-level disks. The destination
instance uses automatically configured channels.
• This RMAN DUPLICATE command duplicates an open database.
• The FROM ACTIVE DATABASE clause indicates that you are not using backups (it implies
network action), and that the target is either open or mounted.
• The SPFILE clause indicates that the server parameter file (SPFILE) will be restored and
modified before opening the database.
• The repeating SET clause essentially issues an ALTER SYSTEM SET param = value
SCOPE=SPFILE command. You can provide as many of these as necessary.
Prerequisites
• The AUXILIARY instance is at the NOMOUNT state having been started with a minimal text
initialization parameter file (PFILE).
• The PFILE requires only the DB_NAME and REMOTE_LOGIN_PASSWORFILE parameters.
• The password file must exist and have the same SYS user password as the target.
• The directory structure must be in place with the proper permission.
• Connect to AUXILIARY by using the net service name as the SYS user.

Creating a Standby Database
with the DUPLICATE Command
DUPLICATE TARGET DATABASE

FOR STANDBY FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '/u01', '/u02'
SET "DB_UNIQUE_NAME"="FOO"
SET SGA_MAX_SIZE = "200M"
SET SGA_TARGET = "125M"
a b le
s f er
an
SET LOG_FILE_NAME_CONVERT = '/u01','/u02'
n
SET DB_FILE_NAME_CONVERT = '/u01','/u02'; - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Duplicating Z i l
a Standby licDatabase
l o
ce in the slide assumes that you are connected to the target and auxiliary instances and that
Therexample
a
Mthe two environments have the same disk and directory structure.
The FOR STANDBY FROM ACTIVE DATABASE clause initiates the creation of a standby
database without using backups.
The example uses u01 as the disk of the source and u02 as the top-level destination directory. All
parameter values that match your choice (with the exception of the DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT parameters) are replaced in the SPFILE.
If PARAMETER_VALUE_CONVERT sets the file name specified by a parameter, and if SET sets the
file name specified by the same parameter, then the SET value overrides the
PARAMETER_VALUE_CONVERT setting.
If the DB_FILE_NAME_CONVERT clause is specified in the DUPLICATE command, then its file
name settings override competing settings specified by SPFILE SET.

11.2
Enhancements to Database Duplication

• Connection to a target database is no longer required.

• Enhancements to DUPLICATE … [SKIP] TABLESPACE
ensure that the operation completes successfully.
• Database duplication attempts to resume from the
point-of-failure upon reexecution.
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Enhancements
l
Zi and Modifications
lic to Database Duplication
l o
e perform database duplication without connecting to the target database. This is beneficial in
Yourccan
a
Msituations where a network connection to the target database is unstable or unavailable. Additional
information about this feature, known as targetless duplication is provided later in this lesson.
Enhancements to DUPLICATE … [SKIP] TABLESPACE ensure that the command completes
successfully. Additional information about these enhancements is provided later in this lesson.
In previous releases of Oracle Database, if the DUPLICATE DATABASE command failed, you had to
complete the database duplication manually or remove the auxiliary database files and restart the
duplication. In Oracle Database 11g Release 2, you can reexecute the DUPLICATE DATABASE and
the duplication process attempts to resume from the point-of-failure.

11.2
Targetless DUPLICATE
Datafile backups
Archived
redo log files
ble
Auxiliary instance
fe
Recovery Catalog r a
n s
Target database n - tra
a no
CONNECT AUXILIARY ha
s ฺCONNECT CATALOG
ฺ a r) uide
ฺ c om ent G
a on tud RMAN client
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Targetless DUPLICATE lic
l o
e use the DUPLICATE command without connecting to the target database. This feature is
Yourccan
a
Mapplicable for backup-based duplication. To use the targetless DUPLICATE feature, you must
connect to a recovery catalog and the auxiliary instance.

11.2
Using Targetless DUPLICATE
• Start the auxiliary instance in NOMOUNT mode with a

server parameter file.

• Establish a connection to the auxiliary instance and the
recovery catalog.
• Execute DUPLICATE command with the DATABASE
clause. e
r a bl
s fe
RMAN> CONNECT AUXILIARY sys@dupldb
- t r an
RMAN> CONNECT CATALOG rcuser@rcdb n no
RMAN> DUPLICATE DATABASE orcl TO dupldb
a
s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi DUPLICATE
Using Targetless lic
l o
e start the auxiliary instance in NOMOUNT mode by using a server parameter file so that
Yourc
must
a
MRMAN can modify the initialization parameters, start up, and shut down the auxiliary instance as
necessary.
Note: The DBID parameter must also be specified when you duplicate without a TARGET
connection to the source database and the database name in the recovery catalog is not unique.

11.2
Using New DUPLICATE Command Options
Option Purpose
NOREDO Signals RMAN that the application of redo logs should be

suppressed during recovery
Must be used with targetless DUPLICATE when target
database is in NOARCHIVELOG mode at backup time
Can also be used to explicitly state that no archived redo
log files should be applied
Must be specified when target database is not open and ble

UNDO TABLESPACE
there is no recovery catalog connection so that RMAN fe r a
does not check the tablespace for SYS-owned objects ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Using New DUPLICATE licCommand Options
l o
a ce
Therfollowing are new Oracle Database 11g Release 2 options for the DUPLICATE command:
M • NOREDO: The NOREDO option is used to signal RMAN that redo logs should not be applied
during the recovery phase of the duplication operation. This option should be specified when the
database was in NOARCHIVELOG mode at the time of the backup or when the archived redo log
files are not available for use during the duplication operation. This option is appropriate if a
database that is currently in ARCHIVELOG mode is being duplicated to a point-in-time when it
was in NOARCHIVELOG mode.
If you are performing a targetless DUPLICATE and the database is in NOARCHIVELOG mode,
you must use this option to inform RMAN about the database mode. Without a connection to the
target database, RMAN cannot determine the mode.
• UNDO TABLESPACE: RMAN checks that there are no objects belonging to the SYS user in any
of the duplicated tablespaces during partial database duplication. The SYSTEM, SYSAUX, and
undo segment tablespaces are excluded from this check. However, if the target database is not
open and a recovery catalog is not being used during the duplication, RMAN cannot obtain the
undo tablespace names. So you must use the UNDO TABLESPACE option to provide the names
of undo segment tablespaces.

11.2
DUPLICATE … [SKIP] TABLESPACE

Enhancements
• Automatic checks are performed to determine if

excluded tablespaces contain SYS-owned objects.
• DBMS_TTS.TRANSPORT_SET_CHECK is executed to
determine if the set of tablespaces is self-contained to
ensure that DUPLICATE will be successful.
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Enhancements l
Zi to DUPLICATE
lic … [SKIP] TABLESPACE
l o
ce TABLESPACE tablespace_name option can be used to exclude the named tablespace
TherSKIP
a
Mfrom the database duplication. You can also use the TABLESPACE option to specifically name the
tablespaces that should be duplicated.
In Oracle Database 11g Release 2, RMAN automatically checks to determines if the set of
tablespaces specified is self-contained. RMAN executes the
DBMS_TTS.TRANSPORT_SET_CHECK procedure with the FULL option to ensure that the
database duplication will be successful. If rows are returned when RMAN queries
TRANSPORT_SET_VIOLATIONS, the duplication is stopped.

Using RMAN to Create Archival Backups
• Specifying the KEEP clause, when the database is

online includes both data file and archive log backup

sets:
KEEP {FOREVER | UNTIL TIME [=] ' date_string '}
NOKEEP
[RESTORE POINT rsname]
ble
fe r a
• List all restore points known to the RMAN repository:
ns
-tr a
LIST RESTORE POINT ALL;
n o n
• Display a specific restore point: s a
) a
h deฺ
LIST RESTORE POINT 'rsname'; r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Using RMANZto
l
i CreatelicArchival Backups
l o
rctoeOracle Database 11g, if you needed to preserve an online backup for a specified amount of
Prior
a
Mtime, RMAN assumed you might want to perform point-in-time recovery for any time within that
period and RMAN retained all the archived logs for that time period unless you specified NOLOGS.
However, you may have a requirement to simply keep the backup (and what is necessary to keep it
consistent and recoverable) for a specified amount of time.
With Oracle Database 11g, you can use the KEEP option to generate archival database backups that
satisfy business or legal requirements. The KEEP option is an attribute of the backup set (not
individual of the backup piece) or copy. The KEEP option overrides any configured retention policy
for this backup. You can retain archival backups, so that they are considered obsolete after a
specified time (KEEP UNTIL) or never (KEEP FOREVER). The KEEP FOREVER clause requires
the use of a recovery catalog.
The RESTORE POINT clause creates a “consistency” point in the control file. It assigns a name to a
specific SCN. The SCN is captured just after the data file backup completes. The archival backup can
be restored and recovered for this point in time, enabling the database to be opened. In contrast, the
UNTIL TIME clause specifies the date until which the backup must be kept.
RMAN includes the data files, archived log files (only those needed to recover an online backup), the
relevant autobackup files, and spfiles. All these files must go to the same media family (or group of
tapes) and have the same KEEP attributes.

Managing Archival Database Backups
• Archiving a database backup:

CONNECT TARGET /
CONNECT CATALOG rman/rman@catdb
CHANGE BACKUP TAG 'consistent_db_bkup'
KEEP FOREVER;
• Changing the status of a database copy: ble

fe r a
ans
CHANGE COPY OF DATABASE CONTROLFILE NOKEEP;
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Database
Managing Archival lic Backups
l o
ce command changes the exemption status of a backup or copy in relation to the
TherCHANGE
a
Mconfigured retention policy. For example, you can specify CHANGE ... NOKEEP, to make a
backup that is currently exempt from the retention policy eligible for the OBSOLETE status.
The first example in the slide changes a consistent backup into an archival backup, which you plan to
store offsite. Because the database is consistent and, therefore, requires no recovery, you do not need
to save archived redo logs with the backup.
The second example specifies that any long-term image copies of data files and control files should
lose their exempt status and so become eligible to be obsolete according to the existing retention
policy:
Deprecated clauses: KEEP [LOGS | NOLOGS]
Preferred syntax: KEEP RESTORE POINT <rsname>
Note: The RESTORE POINT option is not valid with CHANGE.
You cannot use CHANGE ... UNAVAILABLE or KEEP for files stored in the Flash Recovery
Area.

Creating Archival Backups
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi Backups
Creating Archival lic
l o
rce a backup for a longer period of time, perform the following steps in Enterprise Manager:
To keep
a
M 1. Select Availability > Schedule Backup > Schedule Customized Backup.
2. Follow the steps of the Schedule Customized Backup wizard until you are on the Settings page.
3. Click Override Current Settings > Policy. In the Override Retention Policy section, you can
select to keep a backup for a specified number of days. A restore point is generated based on the
backup job name.

Easier Recovery from Loss of Server Parameter
File
The FROM MEMORY clause allows the creation of current

systemwide parameter settings.
CREATE PFILE [= 'pfile_name' ]

FROM { { SPFILE [= 'spfile_name'] } | MEMORY } ;
ble
fe r a
an s
CREATE SPFILE [= 'spfile_name' ]
- t r
}n;
FROM { { PFILE [= 'pfile_name' ] } | MEMORY o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Easier Recovery l
Zi fromliLoss
c of Server Parameter File
l o
rce Database 11g, the FROM MEMORY clause creates a text initialization parameter file
In Oracle
a
M(PFILE) or server parameter file (SPFILE) using the current systemwide parameter settings. In a
RAC environment, the created file contains the parameter settings from each instance.
During instance startup, all parameter settings are logged to the alert.log file. As of Oracle
Database 11g, the alert.log parameter dump text is written in valid parameter syntax. This
facilitates cutting and pasting of parameters into a separate file, and then using as a PFILE for a
subsequent instance. The name of the PFILE or SPFILE is written to the alert.log at instance
startup time. In cases when an unknown client-side PFILE is used, the alert log indicates this as well.
To support this additional functionality, the COMPATIBLE initialization parameter must be set to
11.0.0.0 or higher.

11.2
TSPITR Enhancements and Modifications

• TSPITR uses transportable tablespaces and Data

Pump, providing the following new capabilities and
features:
– TSPITR can be used to recover a dropped tablespace.
– TSPITR can be performed repeatedly to points-in-time
before the tablespace was brought online without
requiring a recovery catalog. ble
fe r a
• DBMS_TTS.TRANSPORT_SET_CHECK procedure: Used
t r a ns to
determine if the tablespaces in the recovery o n
set- are
self-contained s an
) h a eฺ
• SET NEWNAME replaces CONFIGURE r uid for
ฺa AUXNAME
m G
recovery set datafiles. ฺco ent on tud
a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Enhancements
l
Zi and Modifications
lic to Tablespace Point-in-Time Recovery (TSPITR)
l o
rceOracle Database 11g Release 2, TSPITR used export and import for processing. TSPITR now
Before
a
Muses transportable tablespaces and Data Pump. Because of this change to the underlying technology,
TSPITR can be used to recover a dropped tablespace. In addition, TSPITR can be performed
repeatedly to different points in time without the need for a recovery catalog.
Additional information is provided about the new DBMS_TTS.TRANSPORT_SET_CHECK
procedure and the use of SET NEWNAME on the following pages.

11.2
Identifying Relationships that Span Recovery Set

Boundaries
SELECT *
FROM SYS.TS_PITR_CHECK
WHERE (
TS1_NAME IN ('USERS','EXAMPLE')
AND TS2_NAME NOT IN ('USERS','EXAMPLE'))
OR (
TS1_NAME NOT IN ('USERS','EXAMPLE')
AND TS2_NAME IN ('USERS','EXAMPLE')); bl e
fe r a
t r a ns
Use DBMS_TTS.TRANSPORT_SET_CHECK to ensuren-that
TSPITR will be successful: a no
h a s ฺ
ฺ a r) uide
DBMS_TTS.TRANSPORT_SET_CHECK ('USERS',
c o m nt G 'EXAMPLE');
SELECT * FROM TRANSPORT_SET_VIOLATIONS;
a onฺ tude
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Identifying Relationships lic Between Objects that Span the Recovery Set Boundaries
l o
rceperforming TSPITR, you must determine the recovery set. If objects in the tablespaces you
Before
a
Mneed to recover have relationships with objects in other tablespaces, you need to make provisions for
those objects.
Prior to Oracle Database 11g Release 2, you used the SYS.TS_PITR_CHECK view to identify
relationships between objects that span the recovery set boundaries. Now, you should use the
DBMS_TTS.TRANSPORT_SET_CHECK procedure and query the
TRANSPORT_SET_VIOLATIONS view.
Note: RMAN TSPITR automatically executes the DBMS_TTS.TRANSPORT_SET_CHECK
procedure for the recovery set tablespaces and verifies that the query against
TRANSPORT_SET_VIOLATIONS returns no rows. If the query returns rows, RMAN stops TSPITR
processing and any tablespace containment violations must be resolved before TSPITR can proceed.
You can execute the procedure and query the view as described above as a precautionary measure.

11.2
Using Image Copies for Faster TSPITR

Performance
CONFIGURE AUXNAME FOR DATAFILE
'$ORACLE_BASE/oradata/orcl/users01.dbf'
TO '/backup/users01.dbf';
RECOVER TABLESPACE users UNTIL SEQUENCE 1300 THREAD 1;
CONFIGURE AUXNAME is replaced by SET NEWNAME for

recovery set datafiles: ble
fe r a
ns
RUN
{
- t r a
o n
an
SET NEWNAME FOR DATAFILE
s
'$ORACLE_BASE/oradata/orcl/users01.dbf'
a eฺ
TO '/backup/users01.dbf'; r) h ฺa Guid
m
coSEQUENCE n t 1300 THREAD 1;
RECOVER TABLESPACE users UNTIL n ฺ e
}
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i
Using ImageZCopies
l lic Faster RMAN TSPITR Performance
for
l o
e improve TSPITR performance by directing RMAN to use existing image copies of the
Yourccan
a
Mrecovery set and auxiliary set datafiles. This technique enables RMAN to skip restoring the datafiles
from a backup.
Prior to Oracle Database 11g Release 2, you used the following techniques to specify the existence of
an image copy of a datafile:
• CONFIGURE AUXNAME command for image copies of recovery set datafiles or auxiliary set
datafiles
• SET NEWNAME command for image copies of auxiliary set datafiles
Now you should use the CONFIGURE AUXNAME command only with image copies of auxiliary set
datafiles. You should use the SET NEWNAME command for image copies of recovery set datafiles or
auxiliary set datafiles.

Quiz
In Oracle Database 11g Release 2, TSPITR uses

transportable tablespaces and Data Pump, providing which
of the following new capabilities and features:
1. You must use a recovery catalog to perform TSPITR
repeatedly to points-in-time before the tablespace was
brought online.
a b le
2. You do not need a recovery catalog to perform TSPITR
s f er
repeatedly to points-in-time before the tablespace t r n
awas
brought online. on -
a n
3. You can use TSPITR to recover a dropped
h a s tablespace.
ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
l
Zi 3 lic
Answers: 2 and
l o
a rce
M

Managing Recovery Catalogs
Managing recovery catalogs:

1. Create the recovery catalog.
2. Register your target databases in the recovery catalog.
3. If desired, merge recovery catalogs using the new
IMPORT CATALOG command.
4. If needed, catalog any older backups. a b le
r
5. If needed, create new virtual recovery catalogs for nsfe
specific users. n - tra
a no
6. Protect the recovery catalog. as
r ) h deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l
Managing Recovery lic
Catalogs
l o
ce workflow of managing recovery catalogs is not new. However, it has been enhanced by
Therbasic
a
Mtwo important features: the consolidation of RMAN repositories and virtual private catalogs, which
allow a separation of responsibilities.
1. Create the recovery catalog.
2. Register your target databases in the recovery catalog. This step enables RMAN to store
metadata for the target databases in the recovery catalog.
3. If desired, you can also use the IMPORT CATALOG command to merge recovery catalogs (new
in Oracle Database 11g).
4. If needed, catalog any older backups, whose records are no longer stored in the target control
file.
5. If needed, create virtual recovery catalogs for specific users and determine the metadata to
which they are permitted access (new in Oracle Database 11g).
6. Protect the recovery catalog by including it in your backup and recovery strategy.

Managing Recovery Catalogs (continued)
The recovery catalog contains metadata about RMAN operations for each registered target database.
The catalog includes the following types of metadata:
• Data file and archived redo log backup sets and backup pieces
• Data file copies
• Archived redo logs and their copies
• Tablespaces and data files on the target database

• Stored scripts, which are named user-created sequences of RMAN commands
• Persistent RMAN configuration settings
The enrolling of a target database in a recovery catalog for RMAN use is called registration. The
recommended practice is to register all your target databases in a single recovery catalog. For
example, you can register the prod1, prod2, and prod3 databases in a single catalog owned by
the catowner schema in the catdb database.
The owner of a centralized recovery catalog, which is also called the base recovery catalog, can b
a le
grant
erbase
or revoke restricted access to the catalog to other database users. All metadata is stored in fthe
s
catalog schema.
- t r an
Each restricted user has full read-write access to his or her own metadata, n onwhich is called a
virtual private catalog. saha ฺ
The recovery catalog obtains crucial RMAN metadata fromathe
ฺ r) control
u idfilee of each registered target
database. The resynchronization of the recovery catalog
ฺ c omensures
n t G the metadata that RMAN
that
obtains from the control files is current.
a on tude
You can use a stored script as an alternative
l e@to a command
i s S file for managing frequently used
sequences of RMAN commands. The i l
ฺz script h
iststored in the recovery catalog rather than on the file
e l o s e
u with the target database to which RMAN is connected
system. A local stored script
a r cis associated
t o
l e (mcanicbe
when the script is created,
A global storedilscript e nruneagainst
andscan be executed only when you are connected to this target database.
any database registered in the recovery catalog.
Z l
o a recovery catalog in an environment in which you use or have used different versions
You can
r c eluse
Mofathe database. As a result, your environment can have different versions of the RMAN client,
recovery catalog database, recovery catalog schema, and target database. In Oracle Database 11g,
you can merge one recovery catalog (or metadata for specific databases in the catalog) into
another recovery catalog for ease of management.

The IMPORT CATALOG Command
1. Connecting to the destination recovery catalog:

CONNECT CATALOG cat111/oracle@destdb;
2. Importing metadata for all registered databases:
IMPORT CATALOG cat102/oracle@srcdb;
3. Importing metadata for two registered databases:
IMPORT CATALOG cat92/oracle@catdb DBID=1423241, 1423242; rab
le
sfe
4. Importing metadata from multiple catalogs: tr a n
o n -
IMPORT CATALOG cat102/rman@srcdb;
s an
IMPORT CATALOG cat101/rman@srcdb;
r ) ha deฺ
IMPORT CATALOG cat92/rman@srcdb m
a Gui
NOฺ UNREGISTER;
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l
The IMPORTZCATALOG licCommand
l o
e IMPORT CATALOG command, you can import the metadata from one recovery catalog
With
a rcthe
Mschema into a different catalog schema. If you created catalog schemas of different versions to store
metadata for multiple target databases, then this command enables you to maintain a single catalog
schema for all databases.
IMPORT CATALOG <connectStringSpec>
[DBID = <dbid> [, <dbid>,…]]
[DB_NAME=<dbname>[, <dbname,…]]
[ NO UNREGISTER ];
<connectStringSpec> is the source recovery catalog connect string. The version of the source
recovery catalog schema must be equal to the current version of the RMAN executable. If needed,
upgrade the source catalog to the current RMAN version.
DBID: You can specify the list of database IDs whose metadata should be imported from the source
catalog schema. When not specified, RMAN merges metadata for all database IDs from the source
catalog schema into the destination catalog schema. RMAN issues an error if the database whose
metadata is merged is already registered in the recovery catalog schema.

The IMPORT CATALOG Command (continued)
DB_NAME: You can specify the list of database names whose metadata should be imported. If the
database name is ambiguous, RMAN issues an error.
NO UNREGISTER: By default, the imported database IDs are unregistered from the source recovery
catalog schema after a successful import. By using the NO UNREGISTER option, you can force
RMAN to keep the imported database IDs in the source catalog schema.
Import Example (as shown on the slide)

1. RMAN must be connected to the destination recovery catalog—for example, the cat111
schema—which is the catalog into which you want to import catalog data. This is the first step
in all examples given in the slide.
2. In this example, the cat102 user owns an RMAN catalog (version 10.2) in the srcdb
database. You want RMAN to import all registered databases and unregister them in the source
catalog.
3. The cat92 user owns an RMAN catalog (version 9.2) in the srcdb database. You want ble
RMAN to import the databases with the DBID 1423241 and 1423242, and unregister f e a in
rthem
the source catalog. t r a ns
4. The srcdb database contains three different recovery catalogs. RMANo n - metadata for all
imports
n
database IDs (registered in these catalogs) into the cat111 schemaain the destdb database.
All imported target databases are unregistered from their source
s
ha catalogsฺ except for the
r ) i d e
databases registered in the cat92 schema. ฺa u
Additional Usage Details
om ฺ c e
Gn t
n
aoin both udsource catalog schema and the destination
• Ensure that no target database is registered
@ S tthe
catalog schema. If a target database
z i l leis registered
t h is in both schemas, then unregister this database
from the source catalog and ฺ thesimport.
loretry e
c e
r the middle u
• If the operation failsain
m e to of the import, then the import is rolled back. There is never a
state of partial
l ( ens
e import.
i l
Z scriptslicin the source and destination catalog schemas have name conflicts, RMAN
• When stored
l o
ce the stored script of the source catalog schema.
rrenames
Ma

Creating and Using Virtual Private Catalogs
Databases registered in RMAN catalog

RMAN Enhancing security

base by restricting access
ble
catalog to metadata fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
Virtual l e@ iscatalogs
private S (VPC)
ฺ z i l t h
e loCopyright u e
s2009,
l e (m ense
i
Creating andZUsing
l lic Private Catalogs (VPCs)
Virtual
l o
e allows a consolidation of RMAN repositories and maintains a separation of
Thisrc
feature
a
Mresponsibilities, which is a basic security requirement.
The RMAN catalog has been enhanced to create virtual private RMAN catalogs for groups of
databases and users. The catalog owner creates the base catalog and grants the
RECOVERY_CATALOG_OWNER privilege to the owner of the virtual catalog. The catalog owner can
either grant access to a registered database or grant the REGISTER privilege to the virtual catalog
owner. The virtual catalog owner can then connect to the catalog for a particular target or register a
target database. After this configuration, the VPC owner uses the virtual private catalog just like a
standard base catalog.
As catalog owner, you can access all the registered database information in the catalog. You can list
all databases registered with the SQL*Plus command:
SELECT DISTINCT db_name FROM DBINC;
As virtual catalog owner, you can see only the databases to which you have been granted access.

Using RMAN Virtual Private Catalogs
1. Create an RMAN base catalog:

RMAN> CONNECT CATALOG catowner/oracle@catdb

RMAN> CREATE CATALOG;
2. Grant RECOVERY_CATALOG_OWNER to VPC owner:

SQL> CONNECT SYS/oracle@catdb AS SYSDBA
SQL> GRANT RECOVERY_CATALOG_OWNER to vpcowner;
3a. For previously registered databases, grant CATALOG erab

le
FOR DATABASE to the VPC owner: a n sf
r n -t
RMAN> CONNECT CATALOG catowner/oracle@catdb n o
s a
RMAN> GRANT CATALOG FOR DATABASE db10g TO
) a
h deฺ vpcowner;
r
ฺa REGISTER ui
3b. For unregistered databases, m grant G
DATABASE to the VPC owner: n ฺ co ent
ao S d
tuvpcowner;
RMAN> GRANT REGISTER DATABASE
l @
le this TO
ฺ z i
e loCopyright u e
s2009,
l e (m ense
i l
Using RMANZVirtual lic Catalogs
Private
l o
e virtual private RMAN catalogs for groups of databases and users.
Yourc
create
a
M 1. The catalog owner creates the base catalog.
2. The DBA on the catalog database creates the user that will own the virtual private catalog (VPC)
and grants him or her the RECOVERY_CATALOG_OWNER privilege.
3. The base catalog owner can grant access for previously registered databases to the VPC owner
by using the GRANT CATALOG command:
GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;
The GRANT CATALOG command can also be used as follows when there is more than one
database with the same name registered in the catalog:
GRANT CATALOG FOR DATABASE integer TO vpcowner;
where integer is the DBID.
If the database is not registered in the catalog, grant REGISTER DATABASE to the VPC owner
as follows:
GRANT REGISTER DATABASE TO vpcowner;
When you grant REGISTER DATABASE, RMAN implicitly grants CATALOG FOR DATABASE
for any database registered by the user.

Using RMAN Virtual Private Catalogs
4a. Create a virtual catalog for 11g clients:

RMAN> CONNECT CATALOG vpcowner/oracle@catdb
RMAN> CREATE VIRTUAL CATALOG;
4b. OR Create a virtual catalog for pre-11g clients:

SQL> CONNECT vpcowner/oracle@catdb
SQL> exec catowner.dbms_rcvcat.create_virtual_catalog;
ble
fe r a
5. Register a new database in the catalog: ans
n - t r
no
RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb
a
RMAN> REGISTER DATABASE; s ha deฺ
r
ฺa Gui)
6. Use the virtual catalog: m
n ฺ covpcowner/oracle@catdb;
e n t
o tud
RMAN> CONNECT TARGET / CATALOG
RMAN> BACKUP DATABASE; @a S
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l
Using RMANZVirtual lic Catalogs (continued)
Private
l o
a ce a virtual private catalog.
4.rCreate
M a. If the target database is an Oracle Database 11g database and the RMAN client is an 11g
client, you can use the RMAN command:
CREATE VIRTUAL CATALOG;
b. If the target database is Oracle Database 10g Release 2 or earlier (using a compatible
client), you must execute the supplied procedure from SQL*Plus:
BASE_CATALOG_OWNER.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
5. Connect to the catalog using the VPC owner login, and use it as a normal catalog.
6. The virtual catalog owner can see only those databases that privileges have been granted for. For
most RMAN operations, you additionally need the SYSDBA or SYSOPER privileges on the
target database.

Quiz
After you grant REGISTER DATABASE to the VPC owner,

you must grant CATALOG FOR DATABASE so that the VPC

owner can access the databases he/she registers.
1. True
2. False
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer: 2 Zi
l lic
l o
a rce
M

Summary

• Describe the new and enhanced RMAN features in
Oracle Database 11g
• Duplicate active databases by using the Oracle network
(without backups)
• Back up large files in multiple sections
a b le
• Create archival backups for long-term storage s f er
- t r an
• Manage the recovery catalog on
a n
• Describe the use of virtual private catalogs
as
r ) h deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Using RMAN Enhancements

• Duplicating an active database
• Merging catalogs
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Flashback Technology, LogMiner, and Data

Pump Enhancements
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Use Flashback Data Archive to create, protect, and use
history data
– Prepare your database
– Create, change, and drop a flashback data archive
– View flashback data archive metadata e
r a bl
• Use Flashback Transaction Backout s fe
– Set up Flashback Transaction prerequisites - t r an
no n
– Query transactions with and without dependencies
a
hastransactions
– Choose backout options and flashr)back deฺ ฺa Gu i
• Use Enterprise Manager LogMiner c o m n t
n ฺ e
• Use Data Pump legacy amode
@
o
S tud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l lic
l o
rce
Ma

Flashback Data Archive: Overview
Transparently tracks historical changes to all Oracle data

in a highly secure and efficient manner:
• “Secure”
– No possibility to modify historical data
– Retained according to your specifications
– Automatically purged based on your retention policy e
r a bl
• “Efficient” fe ns
– Special kernel optimizations to minimize performance - t r a
o n
overhead of capturing historical data
s an
– Stored in compressed form in tablespaces
r ) ha detoฺ minimize
storage requirements m ฺa Gui
o ent
ฺcapplications
– Completely transparentoto
a n ud
– Easy to set up lle @ S t
z i t h is
ฺ
loCopyright e
s2009,
r c e o u © Oracle. All rights reserved.
a t
l e (m ense
Flashback Z l
i Archive:
Data lic Overview
l o
rcedatabase object, a flashback data archive is a logical container for storing historical
Aanew
M information. It is stored in one or more tablespaces and tracks the history for one or more
tables. You specify a retention duration for each flashback data archive. You can group the
historical table data by your retention requirements in a flashback data archive. Multiple tables
can share the same retention and purge policies.
With the Oracle Total Recall option, Oracle Database 11g has been specifically enhanced to
track history with minimal performance impact and to store historical data in compressed
form. This efficiency cannot be duplicated by your own triggers, which also cost time and
effort to set up and maintain.
Operations that invalidate history or prevent historical capture are not allowed, for example,
dropping or truncating a table.

Flashback Data Archive: Overview
For retention requirements exceeding undo

Undo data
Original
data in
buffer cache
DML operations
bl e
fe r a
ans
FBDA
n - t r
a no
h a s flashback
Example: Three
ฺ
data
a r)
archives e
with retention
1 year uid
of:
ฺ
ฺ c om e2 nyears tG
Flashback data archives
stored in tablespaces a
on tud 5 years
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Flashback Z l
i Archive:
Data lic Overview (continued)
l o
rce data archive is a historical data store. Oracle Database 11g automatically tracks
Aaflashback
M and archives the data in tables enabled for Flashback Data Archive with a new Flashback Data
Archive background process, FBDA. You use this feature to satisfy retention requirements that
exceed the undo retention. Flashback data archives ensure that flashback queries obtain SQL-
level access to the versions of database objects without getting a "snapshot too old error."
A flashback data archive consists of one or more tablespaces or parts thereof. You can have
multiple flashback data archives. Each is configured with a specific retention duration. Based
on your retention duration requirements, you should create different flashback data archives—
for example, one for all records that must be kept for one year, another for all records that
must be kept for two years, and so on.
FBDA asynchronously collects and writes original data to a flashback data archive. It does not
include the original indexes, because your retrieval pattern of historical information might be
quite different than your retrieval pattern of current information.
Note: You might want to create appropriate indexes just for the duration of historical queries.

Flashback Data Archive: Architecture
DML changes
used by FBDA
Old values
Undo
Buffer cache
1 2
ble
fe r a
FBDA
ans
n - t r
3 a no
History or archive tables: h a s ฺ
- Compressed storage ฺ a r) uide
- With automatic digital ฺ c om ent G
shredding a on tud
l l e@ is S Flashback data archives
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Flashback Z l
i Archive:
Data lic Architecture
e l o
a rcFlashback
The Data Archive background process, FBDA, starts with the database.
M 1. FBDA operates first on the undo in the buffer cache.
2. In case the undo has already left the buffer cache, FBDA could also read the required
values from the undo segments.
3. FBDA consolidates the modified rows of flashback archive–enabled tables and writes
them into the appropriate history tables, which make up the flashback data archive.
You can find the internally assigned names of the history tables by querying the
*_FLASHBACK_ARCHIVE_TABLES view. History tables are compressed and internally
partitioned.
The database automatically purges all historical information on the day after the retention
period expires. (It deletes the data, but does not destroy the flashback data archive.) For
example, if the retention period is 10 days, then every day after the tenth day, the oldest
information is deleted; thus leaving only 10 days of information in the archive. This is a way
to implement digital shredding.

Preparing Your Database
• Create one or more tablespaces for data archives and

grant QUOTA on the tablespaces.
• Grant the FLASHBACK ARCHIVE ADMINISTER system
privilege to create and maintain flashback archives to
the archive administrator.
• Grant the FLASHBACK ARCHIVE object privilege (to le
enable history tracking for specific tables in the givenfer a b
flashback archives) to the archive user. t r a ns
• Grant FLASHBACK and SELECT privileges tonquery on-
s a
specific objects as necessary. h a ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Preparing
l
Zi Database
Your lic
l o
To
a ce Flashback Data Archive features, ensure that the following tasks are performed:
renable
M • Create one or more tablespaces for the data archives and grant access and the appropriate
quota to your “archive administrator.”
• Grant the FLASHBACK ARCHIVE ADMINISTER system privilege to your archive
administrator, to allow execution of the following statements:
• CREATE FLASHBACK ARCHIVE
• ALTER FLASHBACK ARCHIVE
• DROP FLASHBACK ARCHIVE
To allow a specific user the use of a specific flashback data archive, grant the FLASHBACK
ARCHIVE object privilege on that flashback data archive to the archive user. The archive user
can then enable flashback archive on tables, by using the specific flashback data archive.
Example executed as archive administrator:
GRANT FLASHBACK ARCHIVE ON FLA1 TO HR;
Most likely, your users will use other Flashback functionality. To allow access to specific
objects during queries, grant the FLASHBACK and SELECT privileges on all objects involved
in the query.

Preparing Your Database (continued)
If your users need access to the DBMS_FLASHBACK package, then you need to grant them the
SELECT privilege for this package. Users can then use the DBMS_FLASHBACK.ENABLE and
DBMS_FLASHBACK.DISABLE procedures to enable and disable the flashback data archives.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e l oZ l
M arc

Preparing Your Database
• Configuring undo:
– Create an undo tablespace (default: automatically
extensible tablespace)
– Enable Automatic Undo Management (11g default) e
r a bl
– Understand automatic tuning of undo:
ns fe
—
n - tra
Fixed-size tablespace: Automatic tuning for best retention
—
a no
Automatically extensible undo tablespace: Automatic tuning
for longest-running query as h eฺ
– Recommendation for Flashback:
ฺ a r) uid undo
Fixed-size
m nt G
tablespace ฺco on tude
a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Preparing
l
Zi Database
Your lic (continued)
l o
rceDatabase 11g uses the following defaults database initialization parameters:
Oracle
a
M • UNDO_MANAGEMENT='AUTO'
• UNDO_TABLESPACE='UNDOTBS1'
• UNDO_RETENTION=900
In other words, Automatic Undo Management is now enabled by default. If needed, enable
Automatic Undo Management, as explained in the Oracle Database Administrator’s Guide.
An automatically extensible undo tablespace is created upon database installation.
• For a fixed-size undo tablespace, the Oracle database automatically tunes the system to
give the undo tablespace the best possible undo retention.
• For an automatically extensible undo tablespace (default), the Oracle database retains
undo data to satisfy at a minimum, the retention periods needed by the longest-running
query and the threshold of undo retention, specified by the UNDO_RETENTION
parameter.
Automatic tuning of undo retention generally achieves better results with a fixed-size
undo tablespace. If you want to change the undo tablespace to fixed size for this or other
reasons, the Undo Advisor can help you determine the proper fixed size to allocate.

Preparing Your Database (continued)
If you are uncertain about your space requirements and you do not have access to the Undo
Advisor, follow these steps:
1. You can start with an automatically extensible undo tablespace.
2. Observe it through one business cycle (for example, this could be 1 or 2 days, or longer).
3. Collect undo block information with the V$UNDO_STAT view, calculate your space
requirements, and use them to create an appropriately sized fixed undo tablespace. (The
calculation formula is given in the Oracle Database Administrator’s Guide.)
4. You can query V$UNDOSTAT.TUNED_UNDORETENTION to determine the amount of
time for which undo is retained for the current undo tablespace. Setting the
UNDO_RETENTION parameter does not guarantee that unexpired undo data is not
overwritten. If the system needs more space, the Oracle database can overwrite unexpired
undo with more recently generated undo data.
a b le
- Specify the RETENTION GUARANTEE clause for the undo tablespace to ensure
s f er that
unexpired undo data is not discarded.
- t r an
on create a
- To satisfy long-retention requirements that exceed the undo retention,
n
flashback data archive. sa
ha deฺ
r )
ฺa Gui
m
co ent
n ฺ
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e loZ l
M arc

Flashback Data Archive: Workflow
1. Create the flashback data archive.

2. Optionally, specify the default flashback data archive.
3. Enable the flashback data archive.
4. View flashback data archive data.
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Flashback Z l
i Archive:
Data lic Workflow
l o
e step is to create a flashback data archive. A flashback data archive consists of one or
rcfirst
The
a
M more tablespaces. You can have multiple flashback data archives.
Second, you can optionally specify a default flashback data archive for the system. A
flashback data archive is configured with retention time. Data archived in the flashback data
archive is retained for the retention time.
Third, you can enable flashback archiving (and then disable it again) for a table. While
flashback archiving is enabled for a table, some DDL statements are not allowed on that table.
By default, flashback archiving is off for any table.
Fourth, when you query data past your possible undo retention, your query is transparently
rewritten to use historical tables in the flashback data archive.

Using Flashback Data Archive
1. Create the flashback data archive:

CREATE FLASHBACK ARCHIVE fla1
TABLESPACE tbs1 QUOTA 10G RETENTION 5 YEAR;
2. Enable history tracking for a table in the archive:
ALTER TABLE inventory FLASHBACK ARCHIVE fla1;

ble
fe r a
3. View the historical data: ans
n - t r
SELECT product_number, product_name, count no
s a
FROM inventory a
AS OF TIMESTAMP TO_TIMESTAMP
r) hHH24:MI:SS');
('2007-01-01 00:00:00', 'YYYY-MM-DD ide
ฺ
ฺa Gu
c o m n t
n ฺ e
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Flashback Z l
i Archive:
Data lic Scenario
l o
e a flashback data archive with the CREATE FLASHBACK ARCHIVE statement.
rccreate
You
a
M • You can optionally specify the default flashback data archive for the system. If you omit
this option, you can still make this flashback data archive the default later.
• You need to provide the name of the flashback data archive.
• You need to provide the name of the first tablespace of the flashback data archive.
• You can identify the maximum amount of space that the flashback data archive can use in
the tablespace. The default is unlimited. Unless your space quota on the first tablespace is
unlimited, you must specify this value, or else an ORA-55621 will ensue.
• You need to provide the retention time (number of days that flashback data archive data
for the table is guaranteed to be stored).
Create and use a flashback data archive as in the following example:
1. The archive administrator creates a flashback data archive named FLA1, which uses up to
10 GB of the TBS1 tablespace, and includes data that will be retained for five years.
2. In the second step, the archive user enables the Flashback Data Archive. If Automatic
Undo Management is disabled, you receive an ORA-55614 error when you try to modify
the table.
3. The third step shows the access of historical data with an AS OF query.

Configuring a Default Flashback Data Archive
Using a default flashback archive:

1. Create a default flashback data archive:
CREATE FLASHBACK ARCHIVE DEFAULT fla2
TABLESPACE tbs1 QUOTA 10G RETENTION 2 YEAR;
2. Enable history tracking for a table:

ble
ALTER TABLE stock_data FLASHBACK ARCHIVE; fe r a
ans
n - t r
Note: The name of the flashback data archive is not n o
needed
a
because the default one is used. as ) h deฺ
3. Disable history tracking: r
ฺa Gui
m
ALTER TABLE stock_data NO o n ฺco denARCHIVE; t
@ a Stu
FLASHBACK
z i l l e t h is
ฺ
loCopyright e
s2009,
a t
l e (m ense
Configuring
l
Zia DefaultlicFlashback Data Archive
l o
In
a ceFLASHBACK ARCHIVE clause, you can specify the flashback data archive where the
rthe
M historical data for the table will be stored. By default, the system has no flashback data
archive. In the preceding example, the default flashback data archive is specified for the
system.
You can create a default flashback archive in one of two ways:
• Specify the name of an existing flashback data archive in the SET DEFAULT clause of the
ALTER FLASHBACK ARCHIVE statement.
• Include DEFAULT in the CREATE FLASHBACK ARCHIVE statement when you create a
flashback data archive.
You enable and disable flashback archiving for a table with the ALTER TABLE command.
You can assign the internal archive table to a specific flashback data archive by specifying the
flashback data archive name. If the name is omitted, the default flashback data archive is used.
Specify NO FLASHBACK ARCHIVE to disable archiving of a table.

Filling the Flashback Data Archive Space
What happens when your flashback data archive gets full?

• 90% space usage
• Raising of errors:
– ORA-55623 "Flashback Archive \"%s\" is
blocking and tracking on all tables is
suspended"
a b le
– ORA-55617 "Flashback Archive \"%s\" runs outfer
s
ran
of space and tracking on \"%s\" is suspended"
n -t
• Generating alert log entry o
s an
• Suspending tracking
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Filling the Zi l
Flashback licData Archive Space
l o
When
a rceyou are out of space in a flashback data archive, the FBDA and also all foreground
Mprocesses (that generate tracked undo) raise either an ORA-55617 or an ORA-55623 error.
An alert log entry is added, stating that “Flashback archive fla1 is full, and archiving is
suspended.\n.” By default, this occurs when 90% of the assigned space has been used.
Examples:
• 55623, 00000, "Flashback Archive \"%s\" is blocking and tracking on all
tables is suspended"
// *Cause: Flashback archive tablespace has run out of space.
// *Action: Add tablespace or increase tablespace quota for the
flashback archive.
//
• 55617, 00000, "Flashback Archive \"%s\" runs out of space and tracking
on \"%s\" is suspended“
// *Cause: Flashback archive tablespace quota is running out.
// *Action: Add tablespace or increase tablespace quota for the
flashback archive.
Note: After that, new transactions are blocked as FBDA cannot archive those operations. There
will be no gaps in the tracked data due to missed operations. Increasing the quota or extending
the allocated tablespaces would cause FBDA to process un-archived transactions first and then
process ongoing or new transactions.
Maintaining Flashback Data Archives
• Adding space:
ALTER FLASHBACK ARCHIVE fla1
ADD TABLESPACE tbs3 QUOTA 5G;
• Changing retention time:
ALTER FLASHBACK ARCHIVE fla1 MODIFY RETENTION 2 YEAR;
• Purging data: e
r a bl
ALTER FLASHBACK ARCHIVE fla1 PURGE BEFORE
s fe
TIMESTAMP(SYSTIMESTAMP - INTERVAL '1' day);
- t r an
n no
• Dropping a flashback data archive: a
h a s ฺ
DROP FLASHBACK ARCHIVE fla1;
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Maintaining i l
ZFlashback lic Data Archives
l o
rce 1 adds up to 5 GB of the TBS3 tablespace to the FLA1 flashback data archive. (The
Example
a
M archive administrator cannot exceed tablespace quota granted by the DBA.)
Example 2 changes the retention time for the FLA1 flashback data archive to two years.
Example 3 purges all historical data older than one day from the FLA1 flashback data archive.
Normally, purging is done automatically, on the day after your retention time expires. You can
also override this for ad hoc clean-up.
Example 4 drops the FLA1 flashback data archive and historical data, but not its tablespaces.
With the ALTER FLASHBACK ARCHIVE command, you can:
• Change the retention time of a flashback data archive
• Purge some or all of its data
• Add, modify, and remove tablespaces
Note: Removing all tablespaces of a flashback data archive causes an error.

Flashback Data Archive: Examples
• To enforce digital shredding:

CREATE FLASHBACK ARCHIVE tax7_archive
TABLESPACE tbs1 RETENTION 7 YEAR;
• To access historical data:

SELECT symbol, stock_price FROM stock_data
AS OF TIMESTAMP TO_TIMESTAMP ('2006-12-31 23:59:00', ble
'YYYY-MM-DD HH24:MI:SS') fe r a
ans
n - t r
• To recover data:
a no
INSERT INTO employees h a s ฺ
SELECT * FROM employees AS OF TIMESTAMP ฺ a r) uide
TO_TIMESTAMP('2007-06-12 11:30:00','YYYY-MM-DD
ฺ c om ent G HH24:MI:SS')
WHERE name = 'JOE';
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Flashback Z l
i Archive:
Data lic Examples
l o
a rce
Organizations require historical data stores for several purposes. Flashback Data Archive
M provides seamless access to historical data with “as of” queries. You can use Flashback Data
Archive for compliance reporting, audit reports, data analysis, and decision support.
You want to set up your database so that information in the TAX7_ARCHIVE is automatically
deleted, the day after seven years are complete. To do this, you just specify a command as
shown in example 1.
To retrieve the stock price at the close of business on December 31, 2006, use a query as
shown in example 2.
You discover that JOE’s employee record was deleted by error, and that it still existed at 11:30
on the 12th of June 2007. You can insert it again as shown in example 3.

Flashback Data Archive: DDL Restrictions
Using any of the following DDL statements on a table

enabled for Flashback Data Archive causes an ORA-55610
error:
• ALTER TABLE statement that does any of the following:
– Performs partition or subpartition operations (moves or
exchanges)
a b le
– Converts a LONG column to a LOB column er
s f
– Includes an UPGRADE TABLE clause, with or without
- t r anan
INCLUDING DATA clause non a
• DROP TABLE statement a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Flashback Z l
i Archive:
Data lic DDL Restrictions
l o
rcthee sake of security and legal compliance, the preceding restrictions ensure that data in a
For
a
M flashback data archive cannot be invalidated.

11.2
Flashback Data Archive: Supporting Transparent

Schema Evolution
• Additional DDL supported:

– DROP, RENAME, and MODIFY column
– DROP and TRUNCATE partition
– RENAME and TRUNCATE table Flashback Version
Query
X Y Add Column Z
X e
bl
Add
Y
fe r a
Column
Z ans
Drop
Column
o n -tr
time
time
s an
r ) ha deฺ
• Flashback queries work across DDL
m ฺa changes:
G ui Output is
presented accordingly. nฺc o e n t
o
a Stu supported d
• All other DDL not automatically
l l e@ is
ฺ z i t h
e loCopyright u e
s2009,
l e (m ense
Flashback Z l
i Archive:
Data lic Supporting Transparent Schema Evolution
l o
a rce TABLE ADD COLUMN was supported in Oracle Database 11g Release 1. In Oracle
ALTER
MDatabase 11g Release 2, the following DDL operations are supported:
• Dropping of columns and partitions
• Modifying and renaming columns
• Renaming tables
• Truncating tables and partitions
When a schema has evolved in any of these ways, Flashback Data Archive automatically
keeps track of the changes and Oracle Flashback Query will appropriately return the row or
rows with the corresponding schema.

11.2
Flashback Data Archive: Supporting Full Schema

Evolution
• DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA and
DBMS_FLASHBACK_ARCHIVE.REASSOCIATE_FBA
• Disables Flashback Data Archive on specified tables,
allowing more complex DDL (upgrades, split tables)
• Enforces schema integrity after association
– Base table and history table schemas must be the same.
• Requires the FLASHBACK ARCHIVE ADMINISTER ble
fe r a
privilege
ans
n - t r
1 2
a no table
Base
DISASSOCIATE ALTER SCHEMA
h a s ฺ
History table
ฺ a r) uide History table
ASSOCIATE
c o m nt G ALTER SCHEMA
4 ฺ
on tude 3
a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Flashback Z l
i Archive:
Data lic Supporting Full Schema Evolution
l o
rcechanges not automatically supported by Flashback Data Archive may be accommodated
DDL
a
M through the DBMS_FLASHBACK_ARCHIVE PL/SQL package. The DISASSOCIATE_FBA
procedure can be used to disassociate the archive from the base table so that changes can be
made to both the base table and the corresponding archive. Use the REASSOCIATE_FBA
procedure to associate the table with the archive. The schemas must be the same for the base
table and the history table. Flashback Data Archive will validate that the schemas are the same
upon association.
Note: This operation should be used with the understanding that the archive can no longer be
guaranteed to be immutable, because the history could have been altered during the time of
disassociation.

Viewing Flashback Data Archives
Viewing the results:

View Name Description
*_FLASHBACK_ARCHIVE Displays information about flashback

data archives
*_FLASHBACK_ARCHIVE_TS Displays tablespaces of flashback data
archives ble
fe r a
*_FLASHBACK_ARCHIVE_TABLES Displays information about tables that
ans
are enabled for flashback archiving
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o Zi l
Flashback ic Archives
lData
l
e use the data dictionary views to view tracked tables and flashback data archive
You
a rccan
M metadata. To access the USER_FLASHBACK views, you need table ownership privileges. For
the others, you need SYSDBA privileges.
Examples:
• Query the time when the flashback data archive(s) have been created:
SELECT FLASHBACK_ARCHIVE_NAME, CREATE_TIME, STATUS
FROM DBA_FLASHBACK_ARCHIVE;
• To list the tablespace(s), which are used for flashback data archives:
SELECT *
FROM DBA_FLASHBACK_ARCHIVE_TS;
• To list the archive table name for a specific table:
SELECT ARCHIVE_TABLE_NAME
FROM USER_FLASHBACK_ARCHIVE_TABLES
WHERE TABLE_NAME = 'EMPLOYEES';
You cannot retrieve past data from a dynamic performance (V$) view. A query on such a view
always returns current data. However, you can perform queries on past data in static data
dictionary views, such as *_TABLES.

Guidelines and Usage Tips
• COMMIT or ROLLBACK before querying past data

• Use of current session settings
• Obtain SCN with the
DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER
function.
• Compute a past time with: ble
fe r a
(SYSTIMESTAMP - INTERVAL '10' MINUTE)
t r a ns
• Use System Change Number (SCN) where precision o n - is
needed (time stamps have a three-second n
a granularity).
a
h deฺs
r
ฺa Gui)
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Guidelines
l
i Usage
Zand lic Tips
l o
e ensure database consistency, always perform a COMMIT or ROLLBACK operation
a•rcTo
M before querying past data.
• Remember that all flashback processing uses the current session settings, such as national
language and character set, not the settings that were in effect at the time being queried.
• To obtain an SCN to use later with a flashback feature, you can use the
DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER function.
• To compute or retrieve a past time to use in a query, use a function return value as a time
stamp or an SCN argument. For example, add or subtract an INTERVAL value to the
value of the SYSTIMESTAMP function.
• To query past data at a precise time, use an SCN. If you use a time stamp, the actual time
queried might be up to 3 seconds earlier than the time you specify. The Oracle database
server uses SCNs internally and maps them to time stamps at a granularity of 3 seconds.

Quiz
Which of the following are characteristics of a flashback

data archive?
1. A flashback data archive consists of one or more
tablespaces or parts thereof.
2. A flashback data archive consists of only one
tablespace. le
a b
3. You can have only one flashback data archive in each s f er
database. - t r an
n
4. You can have multiple flashback data archives
on in each
s a
database. )h a eฺ
ฺ a r uid
co entm G
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answers:
l
i 4 lic
1Zand
l o
a rce
M

Flashback Transaction Backout
• Logical recovery option to roll back a specific

transaction and all its dependent transactions
– Using redo logs and supplemental logging
– Creating and executing compensating transactions
– You finalize changes with commit or roll back.
• Faster and easier than laborious manual approach e
r a bl
s fe
- t r an
n no
a
s ฺ
h a e
ฺ a r) uidtransactions
Dependent include:
ฺ c om ent primary G
Write-after-write (WAW),
a on tud and foreign key constraints key constraints,
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Flashback Z i l
Transaction lic Backout
l o
rce Transaction Backout is a logical recovery option to roll back a specific transaction
Flashback
a
M and dependent transactions while the database remains online. A dependent transaction is
related by a write-after-write (WAW) relationship, in which a transaction modifies the same
data that was changed by the target transaction, or a primary key constraint relationship, in
which a transaction reinserts the same primary key value that was deleted by the target
transaction. Flashback Transaction utilizes the redo generated for undo blocks to create and
execute a compensating transaction for reverting the affected data back to its original state.

11.2
update
Prerequisites
bl e
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
… and database must be in ARCHIVELOG ฺ c om enmode tG
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
PrerequisitesZi l lic
l o
In
a ce to use this functionality, supplemental logging must be enabled and the correct
rorder
M privileges established. For example, the HR user in the HR schema decides to use Flashback
Transaction for the REGIONS table. The SYSDBA ensures that the database is in archive log
mode and performs the following setup steps in SQL*Plus:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
GRANT EXECUTE ON dbms_flashback TO hr;
GRANT select any transaction TO hr;
The HR user needs to either own the tables (as is the case in the preceding example) or have
the SELECT, UPDATE, DELETE, and INSERT privileges, to allow execution of the
compensating undo SQL code.
Note: In Oracle Database 11g Release 2, you can also track foreign key dependencies by
enabling foreign key supplemental logging:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;
If you have a number of foreign key constraints, consider the performance impact before
enabling foreign key supplemental logging.

Flashing Back a Transaction
• You can flash back a transaction by using Enterprise

Manager or the command line.
• Enterprise Manager uses the Flashback Transaction
Wizard, which calls the
DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure
with the NOCASCADE option.
ble
• If the PL/SQL call finishes successfully, it means thatfera
the transaction does not have any dependenciestra ns a
and
o n -
single transaction is backed out successfully.
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
FlashingoBack
l
Zi a Transaction
lic
l
rce Privileges
Security
a
M To flash back or back-out a transaction, that is, to create a compensating transaction, you must
have the SELECT, FLASHBACK and DML privileges on all affected tables.
Conditions of Use
• Transaction Backout is not supported across conflicting DDL.
• Transaction Backout inherits data type support from LogMiner. See the Oracle Database
11g documentation for supported data types.
Recommendation
• When you discover the need for a transaction backout, start the backout operation as soon
as possible for better performance. Large redo logs and high transaction rates result in
slower transaction backout operations.
• Provide a transaction name for the backout operation to facilitate later auditing. If you do
not provide a transaction name, it will be automatically generated for you.

Using the Flashback Transaction Wizard
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Using the Zi l
Flashback licTransaction Wizard
l o
In
a ce
rEnterprise Manager, select Schema > Tables > <table>, then select “Flashback
MTransaction” from the Actions drop-down list, and click Go. This invokes the Flashback
Transaction Wizard for your selected table. The Flashback Transaction: Perform Query page is
displayed.
Select the appropriate time range and add query parameters. (The more specific you can be,
the shorter is the search of the Flashback Transaction Wizard.)
In Enterprise Manager, Flashback Transaction and LogMiner are seamlessly integrated (as this
page demonstrates).

Using the
DBMS_FLASHBACK.TRANSACTION_BACKOUT
Procedure
CREATE TYPE XID_ARRAY AS VARRAY(100) OF RAW(8);

CREATE OR REPLACE PROCEDURE TRANSACTION_BACKOUT(
numberOfXIDs NUMBER, -- number of transactions passed as
input
xids XID_ARRAY, -- the list of transaction ids
options NUMBER default NOCASCADE, -- back out dependent
a b le
txn timeHint TIMESTAMP default MINTIME -- time hint on the txner
a n sf
start
o n -tr
);
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Zi l lic
Using the DBMS_FLASHBACK.TRANSACTION_BACKOUT Procedure
l o
As
a cealternative to using the Flashback Transaction Wizard, you can use the
ran
MDBMS_FLASHBACK.TRANSACTION_BACKOUT procedure. Refer to the PL/SQL Packages
and Types Reference for additional information.
Essentially, you take an array of transaction IDs as the starting point of your dependency
search. For example:
CREATE TYPE XID_ARRAY AS VARRAY(100) OF RAW(8);
CREATE OR REPLACE PROCEDURE TRANSACTION_BACKOUT(
numberOfXIDs NUMBER, -- number of transactions passed as input
xids XID_ARRAY, -- the list of transaction ids
options NUMBER default NOCASCADE, -- back out dependent
txn timeHint TIMESTAMP default MINTIME -- time hint on the txn
start
);

Viewing a Dependency Report
After choosing your backout option, the dependency

report is visible in the DBA_FLASHBACK_TXN_STATE and
DBA_FLASHBACK_TXN_REPORT views.
• Review the dependency report that shows all
transactions which were backed out.
• Commit the changes to make them permanent. e
r a bl
• Roll back to discard the changes. s fe
- t r an
n no
a
s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Viewing o Zi l
a Dependency lic Report
e l
The
a rcDBA_FLASHBACK_TXN_STATE view contains the current state of a transaction:
M whether it is alive in the system or effectively backed out. This table is atomically maintained
with the compensating transaction. For each compensating transaction, there could be multiple
rows, where each row provides the dependency relation between the transactions that have
been compensated by the compensating transaction.
The DBA_FLASHBACK_TXN_REPORT view provides detailed information about all
compensating transactions that have been committed in the database. Each row in this view is
associated with one compensating transaction.
For a detailed description of these tables, see the Oracle Database Reference.

Viewing Flashback Transaction Metadata
View Name Description
*_FLASHBACK_TXN_REPORT Displays related XML information
*_FLASHBACK_TXN_STATE Displays the transaction identifiers for

backed-out transactions
ble
fe r a
ans
n - t r
no
SQL> SELECT * FROM DBA_FLASHBACK_TXN_STATE;
COMPENSATING_XID XID DEPENDENT_XID a
s ฺ
BACKOUT_MODE USERNAME
h a
---------------- ---------------- ----------------
ฺ a r) uide ------------ --------
06001D00930C0000 03001300970C0000 0A001E00EE0B0000
c o m nt GCASCADE SYS
02000500D70D0000 02001A00D40D0000 o
a nฺ ude CASCADE
09001C00D40D0000 SYS
@ is S t
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Viewing o Zi l
Flashback ic
lTransaction Metadata
l
e use the data dictionary views to view information about Flashback Transaction
You
a rccan
M Backouts.
Sample content of DBA_FLASHBACK_TXN_REPORT (formatted for legibility):
COMPENSATING_XID COMPENSATING_TXN_NAME COMMIT_TIME
---------------- --------------------- -------------- -----------
02000500D70D0000 _SYS_COMP_TXN_3473453_TIM_1255423650 13-OCT-09
XID_REPORT
---------------------------------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?> <COMP_XID_REPORT
XID="02000500D70D00
USERNAME
--------
SYS

Quiz
Flashback Transaction Backout enables you to roll back a

specific transaction and dependent transactions while the
database remains online.
1. True
2. False
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer:o 1 Zi
l lic
l
a rce
M

11.2
Flashback Database Enhancements

• Enable Flashback Database while the database is open

• Monitor Flashback Database by using the SOFAR and
TOTALWORK columns of V$SESSION_LONGOPS
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Flashback Z i l
Database licEnhancements
l o
In
a ce Database 11g Release 2 you can enable Flashback Database while the database is
rOracle
M open. In previous releases, the database had to be in MOUNT mode to enable Flashback
Database.
You can monitor Flashback Database progress by using the V$SESSION_LONGOPS view.
Progress percentage can be found by querying the SOFAR and TOTALWORK columns.

Using LogMiner
• Powerful audit tool for Oracle databases

• Direct access to redo logs
• User interfaces:
– SQL command line
– Graphical user interface (GUI)
• Integrated with Enterprise Manager ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi
Using LogMiner
l lic
l o
rce is a powerful audit tool for Oracle databases, which allows you to easily locate
LogMiner
a
Mchanges in the database, enabling sophisticated data analyses, and providing undo capabilities
to roll back logical data corruptions or user errors. LogMiner directly accesses the Oracle redo
logs, which are complete records of all activities performed on the database, and the associated
data dictionary. The tool offers two interfaces: SQL command line and a GUI interface.
Enterprise Manager Database Control now has an interface for LogMiner. In prior releases,
administrators were required to install and use the stand-alone Java Console for LogMiner.
With this new interface, administrators have a task-based, intuitive approach to using
LogMiner. This improves the manageability of LogMiner. In Enterprise Manager, select
Availability > View and Manage Transactions.
LogMiner supports the following activities:
• Specifying query parameters
• Stopping the query and showing partial results, if the query takes a long time
• Partial querying, then showing the estimated complete query time
• Saving the query result
• Re-mining or refining the query based on initial results
• Showing transaction details, dependencies, and compensating “undo” SQL script
• Flashing back and committing the transaction
Review: Data Pump Export and Import
expdp Database
client link
Source Target
Data Pump Server

job process
Database Database
Master Dump Dump Master
table file set file set table ble
fe r a
ans
“Network mode”
n - t r
a no
Server
h a s Pump
Data
ฺ
process r ) job e
ฺa Gu i d
c o m n t
o n ฺ d e
a
@ is S t u impdp
client
i l l e h
e l oฺz use t
a rc Copyright
l e (m ense
Review: o Data
l
Zi PumpliExport
c and Import
l
a rce
Data Pump Export is a utility for unloading data and metadata into a set of operating system
M files called “dump file sets.” Data Pump Import is used to load metadata and data stored in an
export dump file set into a target system.
The Data Pump API accesses its files on the server rather than on the client.
These utilities can also be used to export from a remote database directly to a dump file set, or
to load the target database directly from a source database with no intervening files. This is
known as network mode. This mode is particularly useful when exporting data from a read-
only source database.
At the center of every Data Pump operation is the master table (MT), which is a table created
in the schema of the user running the Data Pump job. The MT maintains all aspects of the job.
The MT is built during a file-based export job and is written to the dump file set as the last
step. Conversely, loading the MT into the current user’s schema is the first step of a file-based
import operation and is used to sequence the creation of all objects imported.
Note: The MT is the key to Data Pump’s restart capability in the event of a planned or
unplanned stopping of the job. The MT is dropped when the Data Pump job finishes normally.

11.2
Migration with Data Pump Legacy Mode
• Assistance in transitioning from imp and exp utilities to

impdp and expdp utilities

• Data Pump in legacy mode:
1. Encounters unique imp or exp parameter and enters
legacy mode
2. Attempts to map the old syntax to the new syntax
a b le
3. Displays new syntax
s f er
4. Exits legacy mode tran n -
o
Best practice tip: Oracle strongly recommends
s a nthat you
view the new syntax and make script changes
r ) ha deas ฺ time
permits. ฺa Gu i
c o m n t
n ฺ e
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Migration
l
Zi DataliPump
with c Legacy Mode
l o
rce of the extensive use of import and export scripts, Oracle Database 11g Release 2 is
Because
a
Mproviding migration assistance with Data Pump legacy mode. The Data Pump utilities:
1. Enter legacy mode if a parameter unique to exp/imp is present, either on the command
line or in a script
2. Map the old parameter to the equivalent expdp or impdp parameter (if possible)
3. Display the converted command, so that you can view the new syntax and make script
changes, as your time permits
4. Exit legacy mode, if a mix of old and new parameters are present (Mixing a Data Pump
parameter with an original export or import parameter causes Data Pump to exit without
performing the desired task.)
For additional new features, see Oracle Database Utilities 11g Release 2.

11.2
Data Pump Legacy Mode

The Data Pump export and import utilities:

• Read and write files only in Data Pump format
• Accept exp and imp utility commands in legacy mode
• Legacy mode parameters:
– Can be identical to the new syntax:
FILESIZE=integer[B | K | M | G]
ble
– Can be similar: fe r a
ans
QUERY= query_clause
n - t r
no by Data
– Are ignored, when the command is superceded
a
Pump defaults. as ) h deฺ
BUFFER=integer r
ฺa Gui
COMPRESS={y|n} m
co ent
n ฺ
DIRECT={y|n}
@ ao Stud
– Cause an error iwhen
z l le old t h isand new syntax is mixed.
ฺ
loCopyright e
s2009,
a t
l e (m ense
Data Pump i l
ZLegacy ic
lMode
l o
e Pump utilities operate only with files in the Data Pump format. (Files created by the
rcData
The
a
Mexp utility must be read by the imp utility.) The Data Pump legacy mode allows you to
continue the use of your existing scripts with the Data Pump utilities. But you must use the
new Data Pump syntax, if you want to access new features of the database.
When the utilities find unique exp or imp parameters, they enter legacy mode.
• Identical parameters are used unchanged. Example: The FILESIZE=integer[B | K
| M | G] parameter specifies the maximum size of a dump file.
• The QUERY=query_clause parameter does not cause any conversion, but note that
the expdp utility handles queries less restrictive than the deprecated export utility. So
your query results may be a little different.
• Some parameters are ignored, because they are superceded by new defaults. Examples:
- The BUFFER=integer parameter is ignored, because the expdp utility has no
conventional path mode.
- The COMPRESS={y|n} parameter is ignored, because the expdp utility has no
equivalent parameter.
- The DIRECT={y|n} parameter is ignored, because the expdp utility determines if
the requested export should use direct path or external table mode
• A mixture of exp/imp and Data Pump parameters causes a job to fail.
11.2
Data Pump Legacy Mode

• Legacy mode parameters (continued):

– Are mapped to Data Pump parameters, if possible:
consistent={y|n} -> FLASHBACK_TIME
GRANTS=n -> EXCLUDE=GRANTS
INDEXES=n -> EXCLUDE=INDEX
LOG=filename -> LOGFILE=filename
FILE=filename -> dumpfile=directory-object:filename
ble
– Can be similar, but not identical: fe r a
ans
FEEDBACK=integer -> STATUS
n - t r
o Pump:
– Cause an error when incompatible with newnData
s a
VOLSIZE=integer
) a
h deฺ
r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l
Data PumpZLegacy ic (continued)
lMode
l o
e Data Pump legacy mode to transition deprecated scripts to the current version. Several
rcthe
Use
a
Mparameters can be mapped to the new syntax:
• Data Pump knows the current time and maps the CONSISTENT={y|n} parameter to the
FLASHBACK_TIME parameter.
• The GRANTS=n parameter is remapped to EXCLUDE=GRANT.
• The INDEXES=n parameter is remapped to EXCLUDE=INDEX.
• The LOG=filename parameter is remapped to LOGFILE=filename. The contents of
the log file (informational and error messages) are in expdp format.
• The FILE=filename parameter is remapped to dumpfile=directory-
object:filename. But if the expdp utility cannot find the path to an existing
directory object, it aborts.
A parameter can be mapped, but the new functionality is different. The
FEEDBACK=integer parameter is remapped to STATUS. It is not a direct mapping because
the status of the export job, not just the number of processed rows, is returned.
A parameter can cause the job to abort, because it is incompatible with Data Pump: The
VOLSIZE=integer parameter of the exp utility specifies the tape volume size. Data Pump
does not work with tape drives; Oracle Secure Backup manages tapes.
For a complete mapping of exp and imp parameters to the Data Pump utilities, see Oracle
Database Utilities 11g Release 2.

11.2
Managing File Locations
• Original exp and imp utilities: Fully qualified file names

• Data Pump directory object for file locations

– Default (in prior versions): DATA_PUMP_DIR parameter
– New optional DATA_PUMP_DIR_schema-name directory
object
– Managed with the CREATE DIRECTORY and GRANT SQL le
a b
commands
s f er
tran
– Default location (independent of legacy mode), when:
-
— Command line without DIRECTORY parameternon
a
—
as
User without EXP_FULL_DATABASE privilege
) h deฺ
r
ฺa Gui
co entm
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Managing
l
Zi Locations
File lic
e l o
The
a rcoriginal and the Data Pump utilities differ in their handling of file locations, because the
M original utilities were client based (all file names were fully qualified).
The Data Pump utilities are server based. They require that a directory object is used when
specifying file locations. The directory object must be accessible to the schema. The default
location in prior versions was set by the DATA_PUMP_DIR initialization parameter.
This functionality does not introduce new mandatory DBA tasks. It introduces an optional
DATA_PUMP_DIR_<schema-name> directory object. If you choose to create this directory
object with the CREATE DIRECTORY and GRANT SQL commands, you allow the specified
schemas the ability to use Data Pump export or import (which will have an impact on the usual
server resources such as CPU, memory usage, and disk usage).
The Data Pump utilities use this directory object when none is specified in the command line
and when the user does not have the EXP_FULL_DATABASE privilege. This is independent
of the legacy mode.

Quiz
Parameters, mapped in Data Pump legacy mode, always

initiate the same functionality as the deprecated exp and
imp parameters.
1. True
2. False
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answer:o 2 Zi
l lic
l
a rce
M

Summary

• Describe new and enhanced features for Flashback
and LogMiner
• Prepare your database for flashback
• Create, change, and drop a flashback data archive
• View flashback data archive metadata a b le
• Set up Flashback Transaction prerequisites s f er
- t r an
• Query transactions with and without dependencies n on
• Choose backout options and flash back s a
transactions
) a
h deฺ
• Use Enterprise Manager LogMiner r
ฺa Gui
m
co ent
• Use Data Pump legacy modeo n ฺ d
@ a Stu
z i l l e t h is
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Using Flashback Technology

• Using Flashback Data Archive
• Using Flashback Transaction Backout
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Marc
le
oZ
i l l l
m a r c e
e ( icens
e
z i
to
l @
loฺ use
n
le this
ฺ
m
ao Stud
r )
co ent
s
ฺa Gui
ha deฺ
an
on - t r an
s
fe r a bl
e
Data Recovery Advisor
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc
Objectives

• Describe your options for repairing data failure
• Use the new RMAN data repair commands to:
– List failures
– Receive a repair advice
– Repair failures ble
fe r a
• Perform proactive failure checks s
- t r an
• Query the Data Recovery Advisor views o n
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Repairing Data Failures
• Data Recovery Advisor, a new feature in Oracle

Database 11g, analyzes failures based on symptoms
and determines repair strategies:
– Aggregating multiple failures for efficient repair
– Presenting a single, recommended repair option
– Performing repairs at your request
a b le
• Flashback technology protects the life cycle of a row fer
and assists in repairing logical problems. t r a ns
o n -
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Repairing
l
Zi Failures
Data lic
l o
rce failure” is a missing, corrupted, or inconsistent data, log, control, or other file, whose
Aa“data
Mcontent the Oracle instance cannot access. When your database has a problem, analyzing the
underlying cause and choosing the correct solution is often the biggest component of down
time. Oracle Database 11g offers several new and enhanced tools for analyzing and repairing
database problems.
Data Recovery Advisor is a built-in tool that automatically diagnoses data failures and reports
the appropriate repair option. If, for example, the Data Recovery Advisor discovers many bad
blocks, it recommends restoring the entire file, rather than repairing individual blocks.
Therefore, it assists you to perform the correct repair for a failure. You can either repair a data
failure manually or request the Data Recovery Advisor to execute the repair for you. This
decreases the amount of time to recover from a failure.
You can use Flashback technology to repair logical problems.
• Flashback Archive maintains persistent changes of table data for a specified period of
time, allowing you to access the archived data.
• Flashback Transaction allows you to back out of a transaction and all conflicting
transactions with a single click. For more details, see the lesson titled “Flashback
Technology, LogMiner, and Data Pump Enhancements.”

• Fast detection, analysis, and repair of failures

• Minimizing disruptions for users
• Down-time and run-time failures
• User interfaces:
– Enterprise Manager
(several paths) ble
fe r a
– RMAN command line
an s
• Supported database configurations: n - t r
a no
– Single-instance s ฺ
h a
– Not RAC ฺ a r) uide
– Supporting failover to standby, ฺ c om but n t G analysis and
not
repair of standby databases a on tude
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
FunctionalityZi l lic
e l o of the Data Recovery Advisor
arcData Recovery Advisor automatically gathers data failure information when an error is
The
Mencountered. In addition, it can proactively check for failures. In this mode, it can potentially
detect and analyze data failures before a database process discovers the corruption and signals
an error. (Note that repairs are always under human control.)
Data failures can be very serious. For example, if your current log files are missing, you
cannot start your database. Some data failures (such as block corruptions in data files) are not
catastrophic, in that they do not take the database down or prevent you from starting the Oracle
instance. The Data Recovery Advisor handles both cases: the one when you cannot start up the
database (because some required database files are missing, inconsistent, or corrupted) and the
one when file corruptions are discovered during run time.

User Interfaces
The Data Recovery Advisor is available from Enterprise Manager Database Control and Grid
Control. When failures exist, there are several ways to access the Data Recovery Advisor. The
following examples all begin on the Database Instance home page:
• Availability tabbed page > Perform Recovery > Advise and Recover
• Active Incidents link > on the Support Workbench “Problems” page: Checker Findings
tabbed page > Launch Recovery Advisor

• Database Instance Health > click the specific link, for example, ORA 1578 in the
Incidents section > Support Workbench, Problems Detail page > Data Recovery Advisor
• Database Instance Health > Related Links section: Support Workbench > Checker
Findings tabbed page: Launch Recovery Advisor
• Related Link: Advisor Central > Advisors tabbed page: Data Recovery Advisor
• Related Link: Advisor Central > Checkers tabbed page: Details > Run Detail tabbed page:
Launch Recovery Advisor a b le
You can also use it via the RMAN command-line. For example: s f er
n a
rman target / nocatalog
o n -tr
rman> list failure all; n a
Supported Database Configurations a s
h deฺ
r )
In the current release, the Data Recovery Advisor supports m G ui
ฺa single-instance databases. Oracle
c o n t
Real Application Clusters (RAC) databases are
a onฺnot tsupported.
u de
The Data Recovery Advisor cannot use@ blocks orS files transferred from a standby database to
i l l e h i s
tyou cannot use the Data Recovery Advisor to
l o ฺz Also,
repair failures on a primary database.
s e
diagnose and repair failurese
rc on atstandby
o u database. However, the Data Recovery Advisor does
support failover to(am a e
standbysdatabase as a repair option (as mentioned above).
l l e e n
l o Zi lic
a rce
M

Reducing down time by eliminating confusion:
1. Assess data failures. Health Monitor
2. List failures by severity.

Data
Recovery
ble
3. Advise on repair. Advisor
fe r a
ans
n - t r
4. Choose and execute repair.
a no
h a s ฺ
5. Perform proactive checks. ฺ a r) uDBA ide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Data Recovery
l
Zi Advisor lic
e l o
a rcautomatic
The diagnostic workflow in Oracle Database 11g performs as follows. With the
MData Recovery Advisor, you only need to initiate an advice and a repair.
1. The Health Monitor automatically executes checks, and logs failures and their symptoms
as “findings” into Automatic Diagnostic Repository (ADR).
2. The Data Recovery Advisor consolidates findings into failures. It lists the results of
previously executed assessments with failure severity (critical or high).
3. When you ask for repair advice on a failure, the Data Recovery Advisor maps failures to
automatic and manual repair options, checks basic feasibility, and presents you with the
repair advice.
4. You can choose to manually execute a repair or request the Data Recovery Advisor to do
it for you.
5. In addition to the automatic, primarily “reactive” checks of the Health Monitor and Data
Recovery Advisor, Oracle recommends to additionally use the VALIDATE command as a
“proactive” check.

Assessing Data Failures
1 Database Instance Health

...
2 error link
3 Problem Details
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Assessing
l
i Failures
ZData lic
l o
e illustrates different access routes, which you can use to navigate between the Health
rcslide
This
a
M Monitor and the Data Recovery Advisor. It also demonstrates the interaction of Health
Monitor and Data Recovery Advisor.

Data Failures
ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi
Data Failures
l lic
e l o
a rcfailures
Data are detected by checks, which are diagnostic procedures that assess the health of
Mthe database or its components. Each check can diagnose one or more failures, which are
mapped to a repair.
Checks can be reactive or proactive. When an error occurs in the database, “reactive checks”
are automatically executed. You can also initiate “proactive checks”, for example, by
executing the VALIDATE DATABASE command.
In Enterprise Manager, select Availability > Perform Recovery, or click the Perform Recovery
button, if you find your database in a “down” or “mounted” state.

Data Failure: Examples
• Not accessible components, for example:

– Missing data files at the OS level
– Incorrect access permissions
– Offline tablespace, and so on
• Physical corruptions, such as block checksum failures
or invalid block header field values le
a b
• Logical corruptions, such as inconsistent dictionary, s f er
corrupt row piece, corrupt index entry, or corrupt - t r an
transaction n on
s a
• Inconsistencies, such as control file ) a
his older e ฺ or newer
r
ฺa logs u i d
than the data files and onlineoredom G
c theenumber
ฺon n t
• I/O failures, such as a limit
a o n u d of open files
t
exceeded, channels lle@ is S
inaccessible, network or I/O error
l o ฺzi se th
a rce Copyright
l e (m ense
Data Failure:
l
Zi Examples lic
l o
e Recovery Advisor can analyze failures and suggest repair options for issues, as
rcData
The
a
Moutlined in the slide.

RMAN Command-Line Interface
RMAN Command Action

LIST FAILURE Lists previously executed failure assessment
ADVISE FAILURE Displays recommended repair option
Repairs and closes failures (after ADVISE in the

REPAIR FAILURE
ble
same RMAN session)
fe r a
Changes or closes one or more failures ans
CHANGE FAILURE
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Data Recovery
l
Zi Advisor:
lic RMAN Command-Line Interface
l o
rcesuspect or know that a database failure has occurred, then use the LIST FAILURE
Ifayou
Mcommand to obtain information about these failures. You can list all or a subset of failures and
restrict output in various ways. Failures are uniquely identified by failure numbers. Note that
these numbers are not consecutive, so gaps between failure numbers have no significance.
The ADVISE FAILURE command displays a recommended repair option for the specified
failures. It prints a summary of the input failure and implicitly closes all open failures that are
already fixed. The default behavior when no option is used is to advise on all the CRITICAL
and HIGH priority failures that are recorded in ADR.
The REPAIR FAILURE command is used after an ADVISE FAILURE command within the
same RMAN session. By default, the command uses the single, recommended repair option of
the last ADVISE FAILURE execution in the current session. If none exists, the REPAIR
FAILURE command initiates an implicit ADVISE FAILURE command. After completing the
repair, the command closes the failure.
The CHANGE FAILURE command changes the failure priority or closes one or more failures.
You can change a failure priority only for HIGH or LOW priorities. Open failures are closed
implicitly when a failure is repaired. However, you can also explicitly close a failure.

Listing Data Failures
The RMAN LIST FAILURE command lists previously

executed failure assessment.
• Including newly diagnosed failures
• Removing closed failures (by default)
Syntax: ble
fe r a
LIST FAILURE
ans
n - t r
[ ALL | CRITICAL | HIGH | LOW | CLOSED |
a no
failnum[,failnum,…] ]
h a s ฺ
[ EXCLUDE FAILURE failnum[,failnum,…]
ฺ a r) ] uide
ฺ c om ent G
on tud
[ DETAIL ]
a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Listing Data
l
ZiFailureslic
l o
e LIST FAILURE command lists failures. If the target instance uses a recovery
The
a rcRMAN
Mcatalog, it can be in STARTED mode, otherwise it must be in MOUNTED mode. The LIST
FAILURE command does not initiate checks to diagnose new failures; rather, it lists the
results of previously executed assessments. Repeatedly executing the LIST FAILURE
command revalidates all existing failures. If the database diagnoses new ones (between
command executions), they are displayed. If a user manually fixes failures, or if transient
failures disappear, then the Data Recovery Advisor removes these failures from the LIST
FAILURE output.
The following is a description of the syntax:
• failnum: Number of the failure to display repair options for
• ALL: List failures of all priorities.
• CRITICAL: List failures of CRITICAL priority and OPEN status. These failures require
immediate attention, because they make the whole database unavailable (for example, a
missing control file).
• HIGH: List failures of HIGH priority and OPEN status. These failures make a database
partly unavailable or unrecoverable; so they should be repaired quickly (for example,
missing archived redo logs).

Listing Data Failures (continued)
• LOW: List failures of LOW priority and OPEN status. Failures of a low priority can wait
until more important failures are fixed.
• CLOSED: List only closed failures.
• EXCLUDE FAILURE: Exclude the specified list of failure numbers from the list.
• DETAIL: List failures by expanding the consolidated failure. For example, if there are
multiple block corruptions in a file, the DETAIL option lists each one of them.
See the Oracle Database Backup and Recovery Reference for details of the command syntax.
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
c e loฺ use
a r to
m e
i l l e ( icens
e l oZ l
M arc

Advising on Repair
The RMAN ADVISE FAILURE command:

• Displays a summary of input failure list
• Includes a warning, if new failures appeared in ADR
• Displays a manual checklist
• Lists a single recommended repair option
• Generates a repair script (for automatic or manual a b le
repair) s f er
n a
o n -tr
. . .
a n
Repair script: a s
h deฺ
r )
ฺa Gui
/u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2979
128860.hm m
co ent
RMAN> o n ฺ d
@ a Stu
z i l l e t h is
ฺ
loCopyright e
s2009,
a t
l e (m ense
l
ZiRepairlic
Advisingoon
l
e ADVISE FAILURE command displays a recommended repair option for the
The
a rcRMAN
Mspecified failures. The ADVISE FAILURE command prints a summary of the input failure.
The command implicitly closes all open failures that are already fixed.
The default behavior (when no option is used) is to advise on all the CRITICAL and HIGH
priority failures that are recorded in Automatic Diagnostic Repository (ADR). If a new failure
has been recorded in ADR since the last LIST FAILURE command, this command includes
a WARNING before advising on all CRITICAL and HIGH failures.
Two general repair options are implemented: no-data-loss and data-loss repairs.
When the Data Recovery Advisor generates an automated repair option, it generates a script
that shows you how RMAN plans to repair the failure. If you do not want the Data Recovery
Advisor to automatically repair the failure, then you can use this script as a starting point for
your manual repair. The operating system (OS) location of the script is printed at the end of
the command output. You can examine this script, customize it (if needed), and also execute it
manually if, for example, your audit trail requirements recommend such an action.
Syntax
ADVISE FAILURE
[ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] ]
[ EXCLUDE FAILURE failnum [,failnum,…] ]

Executing Repairs
The RMAN REPAIR FAILURE command:

• Follows the ADVISE FAILURE command
• Repairs the specified failure
• Closes the repaired failure
REPAIR FAILURE ble

fe r a
[USING ADVISE OPTION integer]
ans
n - t r
[NOPROMPT | PREVIEW]
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Executing Zi l
Repairs lic
e l o
a rccommand
This should be used after an ADVISE FAILURE command in the same RMAN
M session. By default (with no option), the command uses the single, recommended repair option
of the last ADVISE FAILURE execution in the current session. If none exists, the REPAIR
FAILURE command initiates an implicit ADVISE FAILURE command.
By default, you are asked to confirm the command execution, because you may be requesting
substantial changes, that take time to complete. During execution of a repair, the output of the
command indicates what phase of the repair is being executed.
After completing the repair, the command closes the failure.
You cannot run multiple concurrent repair sessions. However, concurrent REPAIR …
PREVIEW sessions are allowed.
The REPAIR FAILURE command accepts the following input:
• USING ADVISE OPTION integer: Specifies a repair option by its option number
• NOPROMPT: Suppresses a confirmation prompt
• PREVIEW: Do not execute the repair(s); instead, display the previously generated RMAN
script with all repair actions and comments.

Classifying (and Closing) Failures
The RMAN CHANGE FAILURE command:

• Changes the failure priority (except for CRITICAL)
• Closes one or more failures
Example:
RMAN> change failure 5 priority low;
List of Database Failures ble
fe r a
=========================
ans
Failure ID Priority Status Time Detected Summary
n - t r
---------- -------- --------- ------------- -------
a no
5 HIGH OPEN 20-DEC-06 one or more
h a s ฺ
datafiles are missing
ฺ a r) uide
ฺ c om ent G
Do you really want to change the above failures (enter YES or
on tud
NO)? yes
changed 1 failures to LOW priority a
@ is S
i l l e
l o ฺz se th
a rce Copyright
l e (m ense
Classifying
l
i Closing)
Z(and lic Failures
e l o
The
a rcCHANGE FAILURE command is used to change the failure priority or close one or more
M failures.
Syntax
CHANGE FAILURE
{ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] }
[ EXCLUDE FAILURE failnum[,failnum,…] ]
{ PRIORITY {CRITICAL | HIGH | LOW} |
CLOSE } – change status of the failure(s) to closed
[ NOPROMPT ] – do not ask user for a confirmation
A failure priority can be changed only from HIGH to LOW and from LOW to HIGH. It is an
error to change the priority level of CRITICAL. (One reason why you may want to change a
failure from HIGH to LOW is to avoid seeing it on the default output list of the LIST
FAILURE command. For example, if a block corruption has HIGH priority, you may want to
temporarily change it to LOW if the block is in a little-used tablespace.)
Open failures are closed implicitly when a failure is repaired. However, you can also explicitly
close a failure. This involves a reevaluation of all other open failures, because some of them
may become irrelevant as the result of the closure of the failure.
By default, the command asks the user to confirm a requested change.
Quiz
Which of the following statements are true about the Data

Recovery Advisor?
1. Data Recovery Advisor automatically diagnoses data
failures.
2. Data Recovery Advisor reports the appropriate repair
option for diagnosed failures. le
a b
3. Data Recovery Advisor cannot execute the suggested s f er
repair. - t r an
n on
4. Data Recovery Advisor can execute the suggested
s a
repair. )h a eฺ
ฺ a r uid
co entm G
n ฺ
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
Answers: Z2,
1,
l
i and 4lic
l o
a rce
M

Data Recovery Advisor Views
Querying dynamic data dictionary views:

• V$IR_FAILURE: List of all failures, including closed
ones (result of the LIST FAILURE command)
• V$IR_MANUAL_CHECKLIST: List of manual advice
(result of the ADVISE FAILURE command)
• V$IR_REPAIR: List of repairs (result of the ADVISE b le
FAILURE command) f er a
an s
• V$IR_FAILURE_SET: Cross-reference of failure - t r
and
advice identifiers n on
a s ฺ
h a
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Data Recovery
l
Zi Advisorlic Views
l o
e Oracle Database Reference for details of the dynamic data dictionary views that the
rcthe
See
a
MData Recovery Advisor uses.

Best Practice: Proactive Checks
Invoking proactive health check of the database and its

components:
• Health Monitor or RMAN VALIDATE DATABASE
command
• Checking for logical and physical corruption
• Findings logged in ADR ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Best Practice:
l
Zi Proactive
lic Checks
l o
e important databases, you may want to execute additional proactive checks (possibly
rcvery
For
a
Mdaily during low peak interval periods). You can schedule periodic health checks through the
Health Monitor or by using the RMAN VALIDATE command. In general, when a reactive
check detects failure(s) in a database component, you may want to execute a more complete
check of the affected component.
The RMAN VALIDATE DATABASE command is used to invoke health checks for the
database and its components. It extends the existing VALIDATE BACKUPSET command. Any
problem detected during validation is displayed to you. Problems initiate the execution of a
failure assessment. If a failure is detected, it is logged into ADR as a finding. You can use the
LIST FAILURE command to view all failures recorded in the repository.
The VALIDATE command supports validation of individual backup sets and data blocks. In a
physical corruption, the database does not recognize the block at all. In a logical corruption,
the contents of the block are logically inconsistent. By default, the VALIDATE command
checks for physical corruption only. You can specify CHECK LOGICAL to check for logical
corruption as well.
Block corruptions can be divided into interblock corruption and intrablock corruption. In
intrablock corruption, the corruption occurs within the block itself and can be either physical
or logical corruption. In interblock corruption, the corruption occurs between blocks and can
be only logical corruption. The VALIDATE command checks for intrablock corruptions only.
Setting Parameters to Detect Corruption
Prevent memory and data corruption
...
Detect I/O storage, disk corruption
ble
fe r a
ans
n - t r
...
a
Detect non-persistent writes on physical standby
no
h a s ฺ
New
ฺ a r) uide
... om ent G
Specify ฺ c
n udfor corruption detection
a odefaults t Parameters
Enterprise Manager > Server e @ S
> Initialization
s
ฺ z ill t hi
eloCopyright e
u©s2009, Oracle. All rights reserved.
a r c t o
l e (m ense
Zi l
Setting Parameters ic Detect Corruption
lto
l o
e use the DB_ULTRA_SAFE parameter for easy manageability. It affects the default
You
a rccan
M values of the following parameters:
• DB_BLOCK_CHECKING, which initiates checking of database blocks. This check can
often prevent memory and data corruption (default: FALSE, recommended: FULL).
• DB_BLOCK_CHECKSUM, which initiates the calculation and storage of a checksum in the
cache header of every data block when writing it to disk. Checksums assist in detecting
corruption caused by underlying disks, storage systems, or I/O systems (default:
TYPICAL, recommended: TYPICAL).
• DB_LOST_WRITE_PROTECT, which initiates checking for “lost writes.” Data block lost
writes occur on a physical standby database, when the I/O subsystem signals the
completion of a block write, which has not yet been completely written in persistent
storage. Of course, the write operation has been completed on the primary database
(default: TYPICAL, recommended: TYPICAL).
If you set any of these parameters explicitly, your values remain in effect. The
DB_ULTRA_SAFE parameter (which is new in Oracle Database 11g) changes only the default
values for these parameters.

Setting Parameters to Detect Corruption
DB_ULTRA_SAFE OFF DATA_ONLY DATA_AND_INDEX
DB_BLOCK_CHECKING OFF or MEDIUM FULL or TRUE

FALSE
DB_BLOCK_CHECKSUM TYPICAL FULL FULL
DB_LOST_WRITE_PROTECT TYPICAL TYPICAL TYPICAL

ble
fe r a
ans
n - t r
a no
h a s ฺ
ฺ a r) uide
ฺ c om ent G
a on tud
l l e@ is S
i
ฺz se th
l o
a rce Copyright
l e (m ense
Zi l
Setting Parameters ic Detect Corruption (continued)
lto
l o
rce on your system’s tolerance for block corruption, you can intensify the checking for
Depending
a
Mblock corruption. Enabling the DB_ULTRA_SAFE parameter (default: OFF) results in
increased system overhead, because of these more intensive checks. The amount of overhead
is related to the number of blocks changed per second; so it cannot be easily quantified. For a
“high-update” application, you can expect a significant increase in CPU, likely in the ten to
twenty percent range, but possibly higher.
• When the DB_ULTRA_SAFE parameter is set to DATA_ONLY, the
DB_BLOCK_CHECKING parameter is set to MEDIUM. This checks that data in a block
are logically self-consistent. Basic block header checks are performed after block contents
change in memory (for example, after UPDATE or INSERT commands, on-disk reads, or
inter-instance block transfers in Oracle RAC). This level of checks includes semantic
block checking for all non-index-organized table blocks.
• When the DB_ULTRA_SAFE parameter is set to DATA_AND_INDEX, the
DB_BLOCK_CHECKING parameter is set to FULL. In addition to the preceding checks,
semantic checks are executed for index blocks (that is, blocks of subordinate objects that
can actually be dropped and reconstructed when faced with corruption).
• When the DB_ULTRA_SAFE parameter is set to DATA_ONLY or DATA_AND_INDEX,
the DB_BLOCK_CHECKSUM parameter is set to FULL and the
DB_LOST_WRITE_PROTECT parameter is set to TYPICAL.
Summary

• Describe your options for repairing data failure
• Use the new RMAN data repair commands to:
– List failures
– Receive a repair advice
– Repair failures ble
fe r a
• Perform proactive failure checks s
- t r an
• Query the Data Recovery Advisor views o n
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Repairing Failures

• Repairing a database by using Enterprise Manager
• Repairing block corruption by using Enterprise
Manager
• Repairing a database by using RMAN
ble
fe r a
ans
n - t r
o
s an
r ) ha deฺ
m ฺa Gui
n ฺ co ent
@ ao Stud
z i l le this
ฺ
loCopyright e
s2009,
a t
l e (m ense
i l lic
el oZ
Marc

Oracle11g New Features Vol2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Oracle11g New Features Vol2

Încărcat de

Drepturi de autor:

Formate disponibile

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2013, Oracle and/or its affiliatesฺ

Christian Bauwens Disclaimer

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

ASM Dynamic Volume Manager (ADVM) Concepts 1-30

Initialization Parameter Information 2-21

Enterprise Manager ASM Configuration Page 4-11

Specifying BLOCKSIZE 5-8

Marc Controlling Deferred Segment Creation 5-31

6 Data Warehouse and Partitioning Enhancements

Goal: Simplifying Parallel Execution 6-17

Marc System Partitioning: Guidelines 6-41

Creating SecureFiles 7-9

Practice 8: Overview 8-27

9 SQL Performance Analyzer

10 SQL Plan Management

SQL Performance Analyzer and SQL Plan Baseline Scenario 10-14

12 Automatic SQL Tuning

Controlling the Automatic SQL Tuning Task 12-10

Resource Manager Enhancements 13-35

Oracle Database Memory Advisors 16-13

17 Application Performance Enhancements

Adaptive Cursor Sharing Views 17-15

18 Backup and Recovery Enhancements

The RMAN DUPLICATE Command 18-18

19 Flashback Technology, LogMiner, and Data Pump Enhancements

Flashback Transaction Backout 19-22

Appendix B: Scheduler Enhancements

Lightweight Jobs B-3

l e n se Job that References the File Watcher B-22

Using REMOVE_GROUP_MEMBER B-44

Appendix C: Oracle Secure Backup Cloud Module

After completing this lesson, you should be able to:

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

Goal: Reduce Time to Resolution

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

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

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

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

• Allows interaction with ADR from OS prompt

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

SQL> SELECT * FROM V$DIAG_INFO;

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

Diagnostic Data Previous Location ADR Location

Foreground process USER_DUMP_DEST $ADR_HOME/trace

Background process BACKGROUND_DUMP_DEST $ADR_HOME/trace

Alert log data BACKGROUND_DUMP_DEST $ADR_HOME/alert&trace

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

Oracle Database 11g: New Features for Administrators 14 - 10

adrci> set homepath diag/rdbms/orcl/orcl

ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:

Oracle Database 11g: New Features for Administrators 14 - 11

Oracle Database 11g: New Features for Administrators 14 - 12

The Automatic Diagnostic Repository is maintained

Oracle Database 11g: New Features for Administrators 14 - 13

Oracle Database 11g: New Features for Administrators 14 - 15

Oracle Database 11g: New Features for Administrators 14 - 16

• Uses rules to correlate all relevant dumps and traces

Oracle Database 11g: New Features for Administrators 14 - 17

• An incident package is a logical

• A package is a zip file containing diag

dump information related to an rdbms

problem are included to n on

Oracle Database 11g: New Features for Administrators 14 - 18

Oracle Database 11g: New Features for Administrators 14 - 19